검색

2.3. 서비스 메시 업그레이드

download PDF

Red Hat OpenShift Service Mesh의 최신 기능에 액세스하려면 현재 버전 2.6.1로 업그레이드하십시오.

2.3.1. 버전 관리 이해

Red Hat은 제품 릴리스에 의미 체계 버전 관리를 사용합니다. 의미 체계 버전 지정은 X.Y.Z 형식의 3 구성 요소 번호입니다.

  • X는 주요 버전을 나타냅니다. 주요 릴리스는 일반적으로 아키텍처 변경, API 변경, 스키마 변경 및 유사한 주요 업데이트 등 일종의 중단 변경 사항을 나타냅니다.
  • Y는 마이너 버전을 나타냅니다. 마이너 릴리스에는 이전 버전과의 호환성을 유지하면서 새로운 기능 및 기능이 포함되어 있습니다.
  • Z는 Patch 버전 ( z-stream 릴리스라고도 함)을 나타냅니다. 패치 릴리스는 CVE(Common Vulnerabilities and Exposures) 및 릴리스 버그 수정을 해결하는 데 사용됩니다. 새로운 기능 및 기능은 일반적으로 패치 릴리스의 일부로 릴리스되지 않습니다.

2.3.1.1. 버전 관리에서 Service Mesh 업그레이드에 미치는 영향

수행 중인 업데이트 버전에 따라 업그레이드 프로세스가 다릅니다.

  • 패치 업데이트 - 패치 업그레이드는 OLM(Operator Lifecycle Manager)에 의해 관리됩니다. Operator를 업데이트할 때 자동으로 수행됩니다.
  • 마이너 업그레이드 - 마이너 업그레이드에서는 최신 Red Hat OpenShift Service Mesh Operator 버전으로 업데이트하고 ServiceMeshControlPlane 리소스의 spec.version 값을 수동으로 수정해야 합니다.
  • 주요 업그레이드 - 주요 업그레이드에서는 최신 Red Hat OpenShift Service Mesh Operator 버전으로 업데이트하고 ServiceMeshControlPlane 리소스의 spec.version 값을 수동으로 수정해야 합니다. 주요 업그레이드에는 이전 버전과 호환되지 않는 변경 사항이 포함될 수 있으므로 추가 수동 변경이 필요할 수 있습니다.

2.3.1.2. Service Mesh 버전 이해

시스템에 배포한 Red Hat OpenShift Service Mesh의 버전을 이해하려면 각 구성 요소 버전을 관리하는 방법을 이해해야 합니다.

  • Operator 버전 - 최신 Operator 버전은 2.6.1입니다. Operator 버전 번호는 현재 설치된 Operator의 버전만 나타냅니다. Red Hat OpenShift Service Mesh Operator는 여러 버전의 Service Mesh Control Plane을 지원하므로 Operator의 버전은 배포된 ServiceMeshControlPlane 리소스의 버전을 확인하지 않습니다.

    중요

    최신 Operator 버전으로 업그레이드하면 패치 업데이트가 자동으로 적용되지만 Service Mesh Control Plane을 최신 마이너 버전으로 자동으로 업그레이드하지는 않습니다.

  • ServiceMeshControlPlane 버전 - ServiceMeshControlPlane 버전은 사용 중인 Red Hat OpenShift Service Mesh의 버전을 결정합니다. ServiceMeshControlPlane 리소스의 spec.version 필드 값은 Red Hat OpenShift Service Mesh를 설치하고 배포하는 데 사용되는 아키텍처 및 구성 설정을 제어합니다. Service Mesh Control Plane을 생성할 때 다음 두 가지 방법 중 하나로 버전을 설정할 수 있습니다.

    • 양식 보기에서 구성하려면 컨트롤 플레인 버전 메뉴에서 버전을 선택합니다.
    • YAML 보기에서 구성하려면 YAML 파일에서 spec.version 값을 설정합니다.

OLM(Operator Lifecycle Manager)은 Service Mesh Control Plane 업그레이드를 관리하지 않으므로 SMCP를 수동으로 업그레이드하지 않는 한 Operator 및 ServiceMeshControlPlane (SMCP)의 버전 번호가 일치하지 않을 수 있습니다.

2.3.2. 업그레이드 고려 사항

maistra.io/ 레이블 또는 주석은 Red Hat OpenShift Service Mesh Operator에서 리소스를 생성하고 관리해야 함을 나타내기 때문에 사용자가 생성한 사용자 정의 리소스에서 사용해서는 안 됩니다.

주의

Operator는 업그레이드 중에 Operator에서 리소스를 관리하는 것을 나타내는 다음 라벨 또는 주석이 포함된 리소스로 파일 삭제 또는 교체를 포함한 변경을 수행합니다.

업그레이드하기 전에 다음 라벨 또는 주석을 포함하는 사용자가 생성한 사용자 정의 리소스를 확인합니다.

  • maistra.io/app.kubernetes.io/managed-by 레이블을 maistra-istio-operator (Red Hat OpenShift Service Mesh)로 설정합니다.
  • Kiali.io/ (Kiali)
  • Jaegertracing.io/ (Red Hat OpenShift distributed tracing platform (Jaeger))
  • logging.openshift.io/ (Red Hat Elasticsearch)

업그레이드하기 전에 사용자가 생성한 사용자 정의 리소스에 Operator 관리임을 나타내는 레이블 또는 주석이 있는지 확인합니다. Operator에서 관리하지 않으려는 사용자 정의 리소스에서 레이블 또는 주석을 제거합니다.

버전 2.0으로 업그레이드할 때 Operator는 SMCP와 동일한 네임스페이스에 이러한 라벨이 있는 리소스만 삭제합니다.

버전 2.1으로 업그레이드할 때 Operator는 모든 네임스페이스에서 이러한 라벨을 사용하여 리소스를 삭제합니다.

2.3.2.1. 업그레이드에 영향을 줄 수 있는 알려진 문제

업그레이드에 영향을 줄 수 있는 알려진 문제는 다음과 같습니다.

  • Operator를 업그레이드할 때 Jaeger 또는 Kiali의 사용자 정의 구성이 되돌릴 수 있습니다. Operator를 업그레이드하기 전에 Service Mesh 프로덕션 배포에서 Jaeger 또는 Kiali 오브젝트에 대한 사용자 정의 구성 설정을 기록하여 다시 생성할 수 있습니다.
  • Red Hat OpenShift Service Mesh는 명시적으로 문서화된 경우를 제외하고 EnvoyFilter 구성 사용을 지원하지 않습니다. 이는 기본 Envoy API와 밀접하게 결합되므로 이전 버전과의 호환성을 유지할 수 없습니다. Envoy 필터를 사용 중이고 Istio에서 생성한 구성이 ServiceMeshControlPlane 을 업그레이드하여 도입된 Envoy의 마지막 버전으로 인해 변경된 경우 구현되었을 수 있는 EnvoyFilter 를 중단할 가능성이 있습니다.
  • OSSM-1505 ServiceMeshExtension 은 OpenShift Container Platform 버전 4.11에서 작동하지 않습니다. ServiceMeshExtension 이 Red Hat OpenShift Service Mesh 2.2에서 더 이상 사용되지 않기 때문에 이 알려진 문제는 해결되지 않으며 WasmPluging으로 확장을 마이그레이션해야 합니다.
  • OSSM-1396 ServiceMeshControlPlane 을 업데이트할 때 게이트웨이 리소스에 spec.externalIPs 설정이 포함된 경우 게이트웨이가 제거되고 다시 생성되지 않습니다.
  • OSSM-1052 Service Mesh Control Plane에서 ingressgateway에 대한 서비스 ExternalIP 를 구성할 때 서비스가 생성되지 않습니다. SMCP의 스키마에 서비스에 대한 매개변수가 누락되어 있습니다.

    해결방법: SMCP 사양에서 게이트웨이 생성을 비활성화하고 게이트웨이 배포를 완전히 수동으로 관리합니다(서비스, 역할 및 RoleBinding 포함).

2.3.3. Operator 업그레이드

최신 보안 수정, 버그 수정 및 소프트웨어 업데이트로 서비스 메시를 패치하려면 Operator를 계속 업데이트해야 합니다. Operator를 업그레이드하여 패치 업데이트를 시작합니다.

중요

Operator 버전은 서비스 메시의 버전을 확인하지 않습니다. 배포된 서비스 메시 컨트롤 플레인의 버전에 따라 서비스 메시 버전이 결정됩니다.

Red Hat OpenShift Service Mesh Operator는 Service Mesh Control Plane의 여러 버전을 지원하므로 Red Hat OpenShift Service Mesh Operator를 업데이트해도 배포된 ServiceMeshControlPlanespec.version 값을 업데이트하지 않습니다. 또한 spec.version 값은 두 자리 숫자(예: 2.2)이며 패치 업데이트(예: 2.2.1)는 SMCP 버전 값에 반영되지 않습니다.

OLM(Operator Lifecycle Manager)은 클러스터에서 Operator의 설치, 업그레이드, RBAC(역할 기반 액세스 제어)를 제어합니다. OLM은 OpenShift Container Platform에서 기본적으로 실행됩니다. 사용 가능한 Operator 및 설치된 Operator의 업그레이드에 대한 OLM 쿼리입니다.

Operator 업그레이드 작업을 수행해야 하는지 여부는 설치할 때 선택한 설정에 따라 다릅니다. 각 Operator를 설치할 때 업데이트 채널승인 전략을 선택했습니다. 이 두 설정의 조합은 Operator가 업데이트되는 시기와 방법을 결정합니다.

표 2.3. 업데이트 채널 및 승인 전략의 상호 작용
 버전이 지정된 채널"stable" 또는 "Preview" 채널

자동

해당 버전의 마이너 릴리스 및 패치 릴리스에 대해서만 Operator를 자동으로 업데이트합니다. 다음 주요 버전으로 자동 업데이트되지 않습니다(즉, 버전 2.0에서 3.0으로). 다음 주요 버전으로 업데이트하려면 Operator 서브스크립션을 수동으로 변경해야 합니다.

모든 주요, 마이너 및 패치 릴리스에 대해 Operator를 자동으로 업데이트합니다.

수동

지정된 버전의 마이너 및 패치 릴리스에 필요한 수동 업데이트 다음 주요 버전으로 업데이트하려면 Operator 서브스크립션을 수동으로 변경해야 합니다.

모든 주요, 마이너 및 패치 릴리스에 수동 업데이트가 필요합니다.

Red Hat OpenShift Service Mesh Operator를 업데이트하면 OLM(Operator Lifecycle Manager)이 이전 Operator Pod를 제거하고 새 Pod를 시작합니다. 새 Operator Pod가 시작되면 조정 프로세스는 ServiceMeshControlPlane (SMCP)을 확인하고 서비스 메시 컨트롤 플레인 구성 요소에 사용 가능한 업데이트된 컨테이너 이미지가 있는 경우 해당 Service Mesh Control Plane Pod를 새 컨테이너 이미지를 사용하는 포드로 대체합니다.

Kiali 및 Red Hat OpenShift distributed tracing Platform(Jaeger) Operator를 업그레이드할 때 OLM 조정 프로세스는 클러스터를 검사하고 관리 인스턴스를 새 Operator의 버전으로 업그레이드합니다. 예를 들어 Red Hat OpenShift distributed tracing Platform(Jaeger) Operator를 버전 1.30.2에서 버전 1.34.1로 업데이트하는 경우 Operator는 분산 추적 플랫폼(Jaeger)의 인스턴스를 실행하고 1.34.1로 업그레이드합니다.

Red Hat OpenShift Service Mesh의 특정 패치 버전을 유지하려면 자동 업데이트를 비활성화하고 해당 특정 버전의 Operator에서 유지되어야 합니다.

Operator 업그레이드에 대한 자세한 내용은 Operator Lifecycle Manager 설명서를 참조하십시오.

2.3.4. 컨트롤 플레인 업그레이드

마이너 릴리스 및 주요 릴리스의 경우 컨트롤 플레인을 수동으로 업데이트해야 합니다. 커뮤니티 Istio 프로젝트는 카나리아 업그레이드를 권장합니다. Red Hat OpenShift Service Mesh는 인플레이스 업그레이드만 지원합니다. Red Hat OpenShift Service Mesh를 사용하려면 각 마이너 릴리스에서 순서대로 다음 마이너 릴리스로 업그레이드해야 합니다. 예를 들어 버전 2.0에서 버전 2.1으로 업그레이드한 다음 버전 2.2로 업그레이드해야 합니다. Red Hat OpenShift Service Mesh 2.0에서 2.2로 직접 업데이트할 수 없습니다.

서비스 메시 컨트롤 플레인을 업그레이드하면 게이트웨이와 같은 모든 Operator 관리 리소스도 업그레이드됩니다.

동일한 클러스터에 여러 버전의 컨트롤 플레인을 배포할 수 있지만 Red Hat OpenShift Service Mesh는 서비스 메시의 카나리아 업그레이드를 지원하지 않습니다. 즉, spec.version 에 대해 다른 값을 사용하여 다른 SCMP 리소스를 보유할 수 있지만 동일한 메시를 관리할 수는 없습니다.

확장 기능에 대한 자세한 내용은 ServiceMeshExtension에서 WasmPlugin 리소스로 마이그레이션을 참조하십시오.

2.3.4.1. 버전 2.5에서 버전 2.6으로 업그레이드

2.3.4.1.1. Red Hat OpenShift distributed tracing platform (Jaeger) 기본 설정 변경

이번 릴리스에서는 ServiceMeshControlPlane 리소스의 새 인스턴스에 대해 기본적으로 Red Hat OpenShift distributed tracing Platform (Jaeger)을 비활성화합니다.

ServiceMeshControlPlane 리소스의 기존 인스턴스를 Red Hat OpenShift Service Mesh 버전 2.6로 업데이트할 때 분산 추적 플랫폼(Jaeger)은 기본적으로 활성화되어 있습니다.

Red Hat OpenShift Service Mesh 2.6은 Red Hat OpenShift distributed tracing Platform (Jaeger) 및 OpenShift Elasticsearch Operator에 대한 지원이 포함된 마지막 릴리스입니다. 다음 릴리스에서 분산 추적 플랫폼(Jaeger) 및 OpenShift Elasticsearch Operator가 모두 제거됩니다. 현재 분산 추적 플랫폼(Jaeger) 및 OpenShift Elasticsearch Operator를 사용하는 경우 Red Hat OpenShift distributed tracing Platform(Tempo) 및 Red Hat build of OpenTelemetry로 마이그레이션해야 합니다.

2.3.4.1.2. Envoy 사이드카 컨테이너 기본 설정 변경

Pod 시작 시간을 개선하기 위해 이제 Istio에 기본적으로 사이드카 컨테이너에 startupProbe 가 포함됩니다. Envoy 사이드카가 시작될 때까지 Pod의 준비 상태 프로브가 시작되지 않습니다.

2.3.4.2. 버전 2.4에서 버전 2.5로 업그레이드

2.3.4.2.1. Istio OpenShift Routing (IOR) 기본 설정 변경

Istio OpenShift Routing (IOR)의 기본 설정이 변경되었습니다. 이제 설정이 기본적으로 비활성화되어 있습니다.

ServiceMeshControlPlane 리소스의 spec.gateways.openshiftRoute 사양에서 enabled 필드를 true 로 설정하여 IOR을 사용할 수 있습니다.

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
spec:
  gateways:
    openshiftRoute:
      enabled: true
2.3.4.2.2. Istio 프록시 동시성 구성 개선 사항

배포 간 일관성을 위해 이제 Istio는 프록시 컨테이너에 할당된 CPU 제한을 기반으로 동시성 매개변수를 구성합니다. 예를 들어, 2500m의 제한은 concurrency 매개변수를 3으로 설정합니다. concurrency 매개변수를 값으로 설정하면 Istio는 해당 값을 사용하여 CPU 제한을 사용하는 대신 프록시가 실행되는 스레드 수를 구성합니다.

이전에는 매개변수의 기본 설정은 2입니다.

2.3.4.3. 버전 2.3에서 버전 2.4로 업그레이드

Service Mesh Control Plane을 버전 2.3에서 2.4로 업그레이드하면 다음과 같은 동작 변경 사항이 추가되었습니다.

  • Istio OpenShift Routing (IOR)에 대한 지원은 더 이상 사용되지 않습니다. IOR 기능은 여전히 활성화되어 있지만 향후 릴리스에서 제거될 예정입니다.
  • 다음 암호화 제품군은 더 이상 지원되지 않으며 클라이언트 및 서버 측 TLS 협상에 사용되는 암호 목록에서 제거되었습니다.

    • ECDHE-ECDSA-AES128-SHA
    • ECDHE-RSA-AES128-SHA
    • AES128-GCM-SHA256
    • AES128-SHA
    • ECDHE-ECDSA-AES256-SHA
    • ECDHE-RSA-AES256-SHA
    • AES256-GCM-SHA384
    • AES256-SHA

      이러한 암호화 제품군 중 하나를 사용하는 서비스에 액세스해야 하는 애플리케이션은 프록시가 TLS 연결을 시작할 때 연결할 수 없습니다.

2.3.4.4. 버전 2.2에서 버전 2.3으로 업그레이드

버전 2.2에서 2.3으로 Service Mesh Control Plane을 업그레이드하면 다음과 같은 동작 변경 사항이 추가되었습니다.

  • 이 릴리스에서는 WasmPlugin API를 사용해야 합니다. 2.2에서 더 이상 사용되지 않는 ServiceMeshExtension API에 대한 지원이 제거되었습니다. ServiceMeshExtension API를 사용하는 동안 업그레이드하려고 하면 업그레이드가 실패합니다.

2.3.4.5. 버전 2.1에서 버전 2.2로 업그레이드

Service Mesh Control Plane을 버전 2.1에서 2.2로 업그레이드하면 다음과 같은 동작 변경 사항이 추가되었습니다.

  • istio-node DaemonSet은 업스트림 Istio의 이름과 일치하도록 istio-cni-node 로 이름이 변경됩니다.
  • Istio 1.10은 기본적으로 lo 가 아닌 eth0 을 사용하여 트래픽을 애플리케이션 컨테이너로 전송하도록 Envoy를 업데이트했습니다.
  • 이 릴리스에는 WasmPlugin API에 대한 지원이 추가되어 ServiceMeshExtension API를 더 이상 사용하지 않습니다.

2.3.4.6. 버전 2.0에서 버전 2.1으로 업그레이드

Service Mesh Control Plane을 버전 2.0에서 2.1으로 업그레이드하면 다음과 같은 아키텍처 및 동작 변경 사항이 추가되었습니다.

아키텍처 변경

Mixer는 Red Hat OpenShift Service Mesh 2.1에서 완전히 제거되었습니다. Mixer가 활성화된 경우 Red Hat OpenShift Service Mesh 2.0.x 릴리스에서 2.1으로 업그레이드가 차단됩니다.

v2.0에서 v2.1로 업그레이드할 때 다음 메시지가 표시되면 .spec.version 필드를 업데이트하기 전에 기존 컨트롤 플레인 사양의 기존 Mixer 유형을 Istiod 유형으로 업데이트합니다.

An error occurred
admission webhook smcp.validation.maistra.io denied the request: [support for policy.type "Mixer" and policy.Mixer options have been removed in v2.1, please use another alternative, support for telemetry.type "Mixer" and telemetry.Mixer options have been removed in v2.1, please use another alternative]”

예를 들면 다음과 같습니다.

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
spec:
  policy:
    type: Istiod
  telemetry:
    type: Istiod
  version: v2.6

동작 변경

  • AuthorizationPolicy 업데이트:

    • PROXY 프로토콜에서 ipBlocksnotIpBlocks 를 사용하여 원격 IP 주소를 지정하는 경우 대신 remoteIpBlocksnotRemoteIpBlocks 를 사용하도록 구성을 업데이트합니다.
    • 중첩된 JSON 웹 토큰(JWT) 클레임에 대한 지원이 추가되었습니다.
  • EnvoyFilter 변경 사항 중단>

    • entered _config를사용해야 합니다.
    • XDS v2는 더 이상 지원되지 않음
    • 더 이상 사용되지 않는 필터 이름
  • 프록시의 이전 버전은 최신 프록시에서 1xx 또는 204 상태 코드를 수신할 때 503 상태 코드를 보고할 수 있습니다.

2.3.4.7. Service Mesh Control Plane 업그레이드

Red Hat OpenShift Service Mesh를 업그레이드하려면 Red Hat OpenShift Service Mesh ServiceMeshControlPlane v2 리소스의 version 필드를 업데이트해야 합니다. 그런 다음 구성 및 적용되면 애플리케이션 pod를 다시 시작하여 각 사이드카 프록시 및 해당 구성을 업데이트합니다.

사전 요구 사항

  • OpenShift Container Platform 4.9 이상을 실행 중입니다.
  • 최신 Red Hat OpenShift Service Mesh Operator가 있습니다.

프로세스

  1. ServiceMeshControlPlane 리소스가 포함된 프로젝트로 전환합니다. 이 예에서 istio-system 은 Service Mesh Control Plane 프로젝트의 이름입니다.

    $ oc project istio-system
  2. v2 ServiceMeshControlPlane 리소스 구성을 확인하여 유효한지 확인합니다.

    1. 다음 명령을 실행하여 ServiceMeshControlPlane 리소스를 v2 리소스로 확인합니다.

      $ oc get smcp -o yaml
      작은 정보

      Service Mesh Control Plane 구성을 백업합니다.

  3. .spec.version 필드를 업데이트하고 구성을 적용합니다.

    예를 들면 다음과 같습니다.

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    metadata:
      name: basic
    spec:
      version: v2.6

    또는 명령줄을 사용하는 대신 웹 콘솔을 사용하여 Service Mesh Control Plane을 편집할 수 있습니다. OpenShift Container Platform 웹 콘솔에서 프로젝트를 클릭하고 방금 입력한 프로젝트 이름을 선택합니다.

    1. Operators 설치된 Operators를 클릭합니다.
    2. ServiceMeshControlPlane 인스턴스를 찾습니다.
    3. 이전 예와 같이 YAML 파일의 YAML 보기를 선택하고 텍스트를 업데이트합니다.
    4. 저장을 클릭합니다.

2.3.4.8. Red Hat OpenShift Service Mesh를 버전 1.1에서 버전 2.0으로 마이그레이션

버전 1.1에서 2.0으로 업그레이드하려면 워크로드와 애플리케이션을 새 버전을 실행하는 Red Hat OpenShift Service Mesh의 새 인스턴스로 마이그레이션하는 수동 단계가 필요합니다.

사전 요구 사항

  • Red Hat OpenShift Service Mesh 2.0으로 업그레이드하려면 OpenShift Container Platform 4.7로 업그레이드해야 합니다.
  • Red Hat OpenShift Service Mesh 버전 2.0 operator가 있어야 합니다. 자동 업그레이드 경로를 선택한 경우 Operator는 최신 정보를 자동으로 다운로드합니다. 하지만 Red Hat OpenShift Service Mesh 버전 2.0에서 기능을 사용하려면 몇 가지 단계를 거쳐야 합니다.
2.3.4.8.1. Red Hat OpenShift Service Mesh 업그레이드

Red Hat OpenShift Service Mesh를 업그레이드하려면 새 네임스페이스에 Red Hat OpenShift Service Mesh ServiceMeshControlPlane v2 리소스 인스턴스를 생성해야 합니다. 구성되면 이전 메시에서 새로운 서비스 메시로 마이크로 서비스 애플리케이션과 워크로드를 이동하십시오.

프로세스

  1. v1 ServiceMeshControlPlane 리소스 구성을 점검하여 유효한지 확인합니다.

    1. 다음 명령을 실행하여 ServiceMeshControlPlane 리소스를 v2 리소스로 확인합니다.

      $ oc get smcp -o yaml
    2. 유효하지 않은 필드에 대한 정보는 출력의 spec.techPreview.errored.message 필드를 확인합니다.
    3. v1 리소스에 유효하지 않은 필드가 있으면 리소스가 조정되지 않고 v2 리소스로 편집할 수 없습니다. v2 필드에 대한 모든 업데이트는 원래 v1 설정으로 덮어씁니다. 유효하지 않은 필드를 수정하려면 리소스의 v1 버전을 교체, 패치 또는 편집할 수 있습니다. 또한 수정하지 않고 리소스를 삭제할 수도 있습니다. 리소스가 수정된 후 조정할 수 있으며, v2 버전의 리소스를 수정하거나 볼 수 있습니다.
    4. 파일을 편집하여 리소스를 수정하려면 oc get를 사용하여 리소스를 검색하고, 로컬로 텍스트 파일을 편집한 다음, 편집한 파일로 리소스를 교체합니다.

      $ oc get smcp.v1.maistra.io <smcp_name> > smcp-resource.yaml
      #Edit the smcp-resource.yaml file.
      $ oc replace -f smcp-resource.yaml
    5. 패치를 사용하여 리소스를 수정하려면 oc patch를 사용합니다.

      $ oc patch smcp.v1.maistra.io <smcp_name> --type json --patch '[{"op": "replace","path":"/spec/path/to/bad/setting","value":"corrected-value"}]'
    6. 명령줄 도구로 리소스를 수정하려면 oc edit를 사용합니다.

      $ oc edit smcp.v1.maistra.io <smcp_name>
  2. Service Mesh Control Plane 구성을 백업합니다. ServiceMeshControlPlane 리소스가 포함된 프로젝트로 전환합니다. 이 예에서 istio-system 은 Service Mesh Control Plane 프로젝트의 이름입니다.

    $ oc project istio-system
  3. 다음 명령을 입력하여 현재 구성을 검색할 수 있습니다. <smcp_name>은 ServiceMeshControlPlane 리소스의 메타데이터에 지정됩니다(예: basic-install 또는 full-install).

    $ oc get servicemeshcontrolplanes.v1.maistra.io <smcp_name> -o yaml > <smcp_name>.v1.yaml
  4. ServiceMeshControlPlane을 구성에 대한 정보를 시작점으로 포함하는 v2 컨트롤 플레인 버전으로 변환합니다.

    $ oc get smcp <smcp_name> -o yaml > <smcp_name>.v2.yaml
  5. 프로젝트를 생성합니다. OpenShift Container Platform 콘솔 프로젝트 메뉴에서 New Project를 클릭하고 프로젝트 이름(예: istio-system-upgrade)을 입력합니다. 또는 CLI에서 이 명령을 실행할 수 있습니다.

    $ oc new-project istio-system-upgrade
  6. v2 ServiceMeshControlPlanemetadata.namespace 필드를 새 프로젝트 이름으로 업데이트합니다. 이 예제에서는 istio-system-upgrade를 사용합니다.
  7. 1.1에서 2.0으로 version 필드를 업데이트하거나 v2 ServiceMeshControlPlane에서 제거합니다.
  8. 새 네임스페이스에서 ServiceMeshControlPlane을 생성합니다. 명령줄에서 다음 명령을 실행하여 검색한 ServiceMeshControlPlane의 v2 버전을 사용하여 컨트롤 플레인을 배포합니다. 이 예제에서 ‘<smcp_name.v2>’를 파일 경로로 바꿉니다.

    $ oc create -n istio-system-upgrade -f <smcp_name>.v2.yaml

    또는 콘솔을 사용하여 Service Mesh Control Plane을 생성할 수 있습니다. OpenShift Container Platform 웹 콘솔에서 프로젝트를 클릭합니다. 그런 다음, 방금 입력한 프로젝트 이름을 선택합니다.

    1. Operators 설치된 Operator를 클릭합니다.
    2. ServiceMeshControlPlane 만들기를 클릭합니다.
    3. YAML 보기를 선택하고, 검색한 YAML 파일의 텍스트를 필드에 붙여넣습니다. apiVersion 필드가 maistra .io/v2로 설정되어 있는지 확인하고 새 네임스페이스를 사용하도록 metadata.namespace 필드를 수정합니다(예: istio-system-upgrade).
    4. 생성을 클릭합니다.
2.3.4.8.2. 2.0 ServiceMeshControlPlane 구성

Red Hat OpenShift Service Mesh 버전 2.0에서 ServiceMeshControlPlane 리소스가 변경되었습니다. ServiceMeshControlPlane 리소스의 v2 버전을 생성한 후 새 기능을 활용하고 배포에 적합하게 수정합니다. ServiceMeshControlPlane 리소스를 수정할 때 Red Hat OpenShift Service Mesh 2.0의 사양 및 동작에 대해 다음과 같은 변경 사항을 고려하십시오. 또한 사용하는 기능에 대한 새로운 정보는 Red Hat OpenShift Service Mesh 2.0 제품 문서를 참조하십시오. v2 리소스는 Red Hat OpenShift Service Mesh 2.0 설치에 사용해야 합니다.

2.3.4.8.2.1. 아키텍처 변경

이전 버전에서 사용하는 아키텍처 단위는 Istiod로 교체되었습니다. 2.0에서는 Service Mesh Control Plane 구성 요소 Mixer, Pilot, Citadel, Galley, 사이드카 인젝터 기능이 단일 구성 요소 Istiod로 결합되었습니다.

Mixer는 더 이상 컨트롤 플레인 구성 요소로 지원되지 않지만, Mixer 정책 및 Telemetry 플러그인은 이제 Istiod의 WASM 확장을 통해 지원됩니다. 레거시 Mixer 플러그인을 통합해야 하는 경우 정책 및 Telemetry에 대해 Mixer를 활성화할 수 있습니다.

SDS(Secret Discovery Service)는 Istiod에서 직접 사이드카에 인증서와 키를 배포하는 데 사용됩니다. Red Hat OpenShift Service Mesh 버전 1.1에서는 Citadel에 의해 시크릿이 생성되었으며, 이는 프록시가 클라이언트 인증서와 키를 검색하는 데 사용되었습니다.

2.3.4.8.2.2. 주석 변경

v2.0에서는 다음과 같은 주석이 더 이상 지원되지 않습니다. 이러한 주석 중 하나를 사용하는 경우 v2.0 Service Mesh 컨트롤 플레인으로 이동하기 전에 워크로드를 업데이트해야 합니다.

  • sidecar.maistra.io/proxyCPULimitsidecar.istio.io/proxyCPULimit로 교체되었습니다. 워크로드에서 sidecar.maistra.io 주석을 사용 중인 경우 대신 동등한 sidecar.istio.io를 사용하도록 해당 워크로드를 수정해야 합니다.
  • sidecar.maistra.io/proxyMemoryLimitsidecar.istio.io/proxyMemoryLimit로 교체됨
  • sidecar.istio.io/discoveryAddress는 더 이상 지원되지 않습니다. 또한 기본 검색 주소는 pilot.<control_plane_namespace>.svc:15010(또는 mtls가 활성화된 경우 포트 15011)에서 istiod-<smcp_name>.<control_plane_namespace>.svc:15012로 이동했습니다.
  • 상태 포트는 더 이상 구성할 수 없으며 15021로 하드 코딩됩니다. * 사용자 정의 상태 포트(예: status.sidecar.istio.io/port )를 정의하는 경우 워크로드를 v2.0 Service Mesh 컨트롤 플레인으로 이동하기 전에 재정의를 제거해야 합니다. 상태 포트를 0 으로 설정하여 준비 상태 점검을 비활성화할 수 있습니다.
  • Kubernetes 시크릿 리소스는 더 이상 사이드카에 대한 클라이언트 인증서를 배포하는 데 사용되지 않습니다. 인증서는 이제 Istiod의 SDS 서비스를 통해 배포됩니다. 마운트된 보안에 의존하는 경우 v2.0 Service Mesh 컨트롤 플레인의 워크로드에 더 오래 사용할 수 있습니다.
2.3.4.8.2.3. 동작 변경

Red Hat OpenShift Service Mesh 2.0의 일부 기능은 이전 버전과 다르게 작동합니다.

  • 게이트웨이의 준비 상태 포트는 15020에서 15021로 이동했습니다.
  • 대상 호스트 가시성에는 VirtualService 및 ServiceEntry 리소스가 포함됩니다. 사이드카 리소스를 통해 적용된 모든 제한을 포함합니다.
  • 자동 상호 TLS는 기본적으로 활성화되어 있습니다. 프록시 간 통신은 글로벌 PeerAuthentication 정책에 관계없이 mTLS를 사용하도록 자동 구성됩니다.
  • 보안 연결은 spec.security.controlPlane.mtls 설정에 관계없이 프록시가 서비스 메시 컨트롤 플레인과 통신할 때 항상 사용됩니다. spec.security.controlPlane.mtls 설정은 Mixer Telemetry 또는 정책에 대한 연결을 구성할 때만 사용됩니다.
2.3.4.8.2.4. 지원되지 않는 리소스에 대한 마이그레이션 세부 정보

정책(authentication.istio.io/v1alpha1)

v2.0 Service Mesh 컨트롤 플레인, PeerAuthentication 및 RequestAuthentication과 함께 사용하려면 정책 리소스를 새 리소스 유형으로 마이그레이션해야 합니다. 정책 리소스의 특정 구성에 따라 동일한 효과를 달성하기 위해 여러 리소스를 구성해야 할 수 있습니다.

상호 TLS

상호 TLS 적용은 security.istio.io/v1beta1 PeerAuthentication 리소스를 사용하여 수행됩니다. 레거시 spec.peers.mtls.mode 필드는 새로운 리소스의 spec.mtls.mode 필드에 직접 매핑됩니다. 선택 기준이 spec.targets[x].name의 서비스 이름 지정에서 spec.selector.matchLabels의 레이블 선택기로 변경되었습니다. PeerAuthentication에서 레이블은 대상 목록에 이름이 지정된 서비스의 선택기와 일치해야 합니다. 모든 포트별 설정은 spec.portLevelMtls에 매핑되어야 합니다.

인증

spec.origins에 지정된 추가 인증 방법은 security.istio.io/v1beta1 RequestAuthentication 리소스에 매핑되어야 합니다. spec.selector.matchLabels는 PeerAuthentication의 동일한 필드와 유사하게 구성되어야 합니다. spec.origins.jwt 항목의 JWT 주체와 관련된 구성은 spec.rules 항목의 유사한 필드에 매핑됩니다.

  • 정책에 지정된 spec.origins[x].jwt.triggerRules는 하나 이상의 security.istio.io/v1beta1 AuthorizationPolicy 리소스에 매핑되어야 합니다. spec.selector.labels는 RequestAuthentication의 동일한 필드와 유사하게 구성되어야 합니다.
  • spec.origins[x].jwt.triggerRules.excludedPaths.excludedPaths 는 spec.action이 ALLOW로 설정된 AuthorizationPolicy에 매핑되고, spec.rules[x].to.operation.path 항목이 제외된 경로와 일치해야 합니다.
  • spec.origins[x].jwt.triggerRules.includedPathsspec.actionALLOW로 설정된 별도의 AuthorizationPolicy에 매핑되고, spec.rules[x].to.operation.path 항목이 제외된 경로와 일치하며, spec.rules.[x].from.source.requestPrincipals 항목이 정책 리소스의 specified spec.origins[x].jwt.issuer와 일치해야 합니다

ServiceMeshPolicy(maistra.io/v1)

ServiceMeshPolicy는 v1 리소스에서 spec.istio.global.mtls.enabled 또는 v2 리소스 설정의 spec.security.dataPlane.mtls 를 통해 서비스 메시 컨트롤 플레인에 대해 자동으로 구성됩니다. v2 컨트롤 플레인의 경우 설치 중에 기능적으로 동일한 PeerAuthentication 리소스가 생성됩니다. 이 기능은 Red Hat OpenShift Service Mesh 버전 2.0에서 더 이상 사용되지 않습니다.

RbacConfig, ServiceRole, ServiceRoleBinding (rbac.istio.io/v1alpha1)

이러한 리소스는 security.istio.io/v1beta1 AuthorizationPolicy 리소스로 교체되었습니다.

RbacConfig 동작을 모방하려면 RbacConfig에 지정된 spec.mode에 따라 설정이 달라지는 기본 AuthorizationPolicy를 작성해야 합니다.

  • spec.modeOFF로 설정되면 AuthorizationPolicy가 요청에 적용되지 않는 한 기본 정책은 ALLOW이므로 리소스가 필요하지 않습니다.
  • spec.mode가 ON으로 설정된 경우 spec: {}를 설정합니다. 메시의 모든 서비스에 대해 AuthorizationPolicy 정책을 생성해야 합니다.
  • spec.modeON_WITH_INCLUSION으로 설정되며, 포함된 각각의 네임스페이스에 spec: {}을 사용하여 AuthorizationPolicy를 생성해야 합니다. 개별 서비스 포함은 AuthorizationPolicy에서 지원되지 않습니다. 그러나 서비스의 워크로드에 적용되는 AuthorizationPolicy가 생성되면 명시적으로 허용되지 않는 다른 모든 요청이 거부됩니다.
  • spec.modeON_WITH_EXCLUSION으로 설정된 경우 AuthorizationPolicy에서 지원되지 않습니다. 글로벌 DENY 정책을 생성할 수 있지만, 네임스페이스 또는 워크로드에 적용할 수 있는 허용된 정책이 없기 때문에 메시의 모든 워크로드에 대해 AuthorizationPolicy를 생성해야 합니다.

AuthorizationPolicy에는 ServiceRoleBinding이 제공하는 기능과 유사한 구성이 적용되는 선택기와 ServiceRole이 제공하는 기능과 유사하며 적용되어야 하는 규칙에 대한 구성이 모두 포함됩니다.

ServiceMeshRbacConfig (maistra.io/v1)

이 리소스는 Service Mesh 컨트롤 플레인의 네임스페이스에 빈 spec.selector가 있는 security.istio.io/v1beta1 AuthorizationPolicy 리소스를 사용하여 교체됩니다. 이 정책은 메시의 모든 워크로드에 적용되는 기본 권한 부여 정책이 됩니다. 특정 마이그레이션 세부 사항은 위의 RbacConfig를 참조하십시오.

2.3.4.8.2.5. Mixer 플러그인

Mixer 구성 요소는 버전 2.0에서 기본적으로 비활성화되어 있습니다. 워크로드에 Mixer 플러그인을 사용하는 경우 Mixer 구성 요소를 포함하도록 버전 2.0 ServiceMeshControlPlane을 구성해야 합니다.

Mixer 정책 구성 요소를 활성화하려면 ServiceMeshControlPlane에 다음 스니펫을 추가합니다.

spec:
  policy:
    type: Mixer

Mixer telemetry 구성 요소를 활성화하려면 ServiceMeshControlPlane에 다음 스니펫을 추가합니다.

spec:
  telemetry:
    type: Mixer

또한 레거시 mixer 플러그인은 WASM으로 마이그레이션하고 새로운 ServiceMeshExtension(maistra.io/v1alpha1) 사용자 정의 리소스를 사용하여 통합할 수 있습니다.

업스트림 Istio 배포에 포함된 내장 WASM 필터는 Red Hat OpenShift Service Mesh 2.0에서 사용할 수 없습니다.

2.3.4.8.2.6. 상호 TLS 변경

워크로드별 PeerAuthentication 정책과 함께 mTLS를 사용할 때 워크로드 정책이 네임스페이스/글로벌 정책과 다를 경우 트래픽을 허용하려면 상응하는 DestinationRule이 필요합니다.

자동 mTLS는 기본적으로 활성화되어 있지만 ServiceMeshControlPlane 리소스에서 spec.security.dataPlane.automtls를 false로 설정하여 비활성화할 수 있습니다. 자동 mTLS를 비활성화할 때 서비스 간 적절한 통신을 위해 DestinationRules가 필요할 수 있습니다. 예를 들어, 하나의 네임스페이스에 대해 PeerAuthentication을 STRICT으로 설정하면 DestinationRule이 네임스페이스의 서비스에 TLS 모드를 구성하지 않는 한 다른 네임스페이스의 서비스에 액세스하지 못할 수 있습니다.

mTLS에 대한 자세한 내용은 mTLS(mutual Transport Layer Security) 활성화를참조하십시오.

2.3.4.8.2.6.1. 기타 mTLS 예

mTLS 비활성화: 정보 샘플 애플리케이션의 productpage 서비스의 경우 Red Hat OpenShift Service Mesh v1.1에 대해 다음과 같은 방식으로 정책 리소스가 구성되었습니다.

정책 리소스 예

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: productpage-mTLS-disable
  namespace: <namespace>
spec:
  targets:
  - name: productpage

mTLS 비활성화: 정보 샘플 애플리케이션의 productpage 서비스의 경우 다음 예제를 사용하여 Red Hat OpenShift Service Mesh v2.0에 대해 PeerAuthentication 리소스를 구성합니다.

PeerAuthentication 리소스 예

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: productpage-mTLS-disable
  namespace: <namespace>
spec:
  mtls:
    mode: DISABLE
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage

mTLS를 활성화하려면 info 샘플 애플리케이션에서 productpage 서비스에 대한 JWT 인증으로, Red Hat OpenShift Service Mesh v1.1에 대해 다음과 같은 방식으로 정책 리소스가 구성되었습니다.

정책 리소스 예

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  targets:
  - name: productpage
    ports:
    - number: 9000
  peers:
  - mtls:
  origins:
  - jwt:
      issuer: "https://securetoken.google.com"
      audiences:
      - "productpage"
      jwksUri: "https://www.googleapis.com/oauth2/v1/certs"
      jwtHeaders:
      - "x-goog-iap-jwt-assertion"
      triggerRules:
      - excludedPaths:
        - exact: /health_check
  principalBinding: USE_ORIGIN

mTLS를 활성화하려면 info 샘플 애플리케이션에서 productpage 서비스에 대한 JWT 인증을 사용하려면 다음 예제를 사용하여 Red Hat OpenShift Service Mesh v2.0에 대해 PeerAuthentication 리소스를 구성합니다.

PeerAuthentication 리소스 예

#require mtls for productpage:9000
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage
  portLevelMtls:
    9000:
      mode: STRICT
---
#JWT authentication for productpage
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage
  jwtRules:
  - issuer: "https://securetoken.google.com"
    audiences:
    - "productpage"
    jwksUri: "https://www.googleapis.com/oauth2/v1/certs"
    fromHeaders:
    - name: "x-goog-iap-jwt-assertion"
---
#Require JWT token to access product page service from
#any client to all paths except /health_check
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  action: ALLOW
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage
  rules:
  - to: # require JWT token to access all other paths
      - operation:
          notPaths:
          - /health_check
    from:
      - source:
          # if using principalBinding: USE_PEER in the Policy,
          # then use principals, e.g.
          # principals:
          # - “*”
          requestPrincipals:
          - “*”
  - to: # no JWT token required to access health_check
      - operation:
          paths:
          - /health_check

2.3.4.8.3. 설정 레시피

이러한 구성 레시피를 사용하여 다음 항목을 구성할 수 있습니다.

2.3.4.8.3.1. 데이터 플레인의 상호 TLS

데이터 플레인 통신에 대한 상호 TLS는 ServiceMeshControlPlane 리소스의 spec.security.dataPlane.mtls를 통해 구성되며, 기본적으로 false입니다.

2.3.4.8.3.2. 사용자 정의 서명 키

Istiod는 서비스 프록시에서 사용하는 클라이언트 인증서 및 개인 키를 관리합니다. 기본적으로 Istiod는 서명에 자체 서명된 인증서를 사용하지만 사용자 정의 인증서와 개인 키를 구성할 수 있습니다. 서명 키를 구성하는 방법에 대한 자세한 내용은 외부 인증 기관 키 및 인증서 추가를 참조하십시오.

2.3.4.8.3.3. 추적

추적 기능은 spec.tracing에서 구성됩니다. 현재 지원되는 유일한 추적기 유형은 Jaeger입니다. 샘플링은 0.01% 증분을 나타내는 스케일링된 정수입니다(예: 1은 0.01%, 10000은 100%). 추적 구현 및 샘플링 비율을 지정할 수 있습니다.

spec:
  tracing:
    sampling: 100 # 1%
    type: Jaeger

Jaeger는 ServiceMeshControlPlane 리소스의 addons 섹션에서 구성됩니다.

spec:
  addons:
    jaeger:
      name: jaeger
      install:
        storage:
          type: Memory # or Elasticsearch for production mode
          memory:
            maxTraces: 100000
          elasticsearch: # the following values only apply if storage:type:=Elasticsearch
            storage: # specific storageclass configuration for the Jaeger Elasticsearch (optional)
              size: "100G"
              storageClassName: "storageclass"
            nodeCount: 3
            redundancyPolicy: SingleRedundancy
  runtime:
    components:
      tracing.jaeger: {} # general Jaeger specific runtime configuration (optional)
      tracing.jaeger.elasticsearch: #runtime configuration for Jaeger Elasticsearch deployment (optional)
        container:
          resources:
            requests:
              memory: "1Gi"
              cpu: "500m"
            limits:
              memory: "1Gi"

Jaeger 설치는 install 필드로 사용자 지정할 수 있습니다. 리소스 제한과 같은 컨테이너 구성은 spec.runtime.components.jaeger 관련 필드에 구성됩니다. spec.addons.jaeger.name 값과 일치하는 Jaeger 리소스가 있으면 기존 설치를 사용하도록 서비스 메시 컨트롤 플레인이 구성됩니다. 기존 Jaeger 리소스를 사용하여 Jaeger 설치를 완전히 사용자 지정할 수 있습니다.

2.3.4.8.3.4. 시각화

Kiali 및 Grafana는 ServiceMeshControlPlane 리소스의 addons 섹션에서 구성됩니다.

spec:
  addons:
    grafana:
      enabled: true
      install: {} # customize install
    kiali:
      enabled: true
      name: kiali
      install: {} # customize install

Grafana 및 Kiali 설치는 각각의 install 필드를 통해 사용자 지정할 수 있습니다. 리소스 제한과 같은 컨테이너 사용자 정의는 spec.runtime.components.kialispec.runtime.components.grafana에서 구성됩니다. 이름 값과 일치하는 기존 Kiali 리소스가 있는 경우 Service Mesh Control Plane은 컨트롤 플레인과 함께 사용할 Kiali 리소스를 구성합니다. Kiali 리소스의 일부 필드(예: accessible_namespaces 목록과 Grafana, Prometheus, 추적에 대한 끝점)는 재정의됩니다. 기존 리소스를 사용하여 Kiali 설치를 완전히 사용자 지정할 수 있습니다.

2.3.4.8.3.5. 리소스 사용률 및 스케줄링

리소스는 spec.runtime.<component>에서 구성됩니다. 다음과 같은 구성 요소 이름이 지원됩니다.

구성 요소설명지원되는 버전

보안

Citadel 컨테이너

v1.0/1.1

galley

Galley 컨테이너

v1.0/1.1

pilot

Pilot/Istiod 컨테이너

v1.0/1.1/2.0

mixer

Istio-telemetry 및 istio-policy 컨테이너

v1.0/1.1

mixer.policy

Istio-policy 컨테이너

v2.0

mixer.telemetry

Istio-telemetry 컨테이너

v2.0

global.oauthproxy

다양한 애드온과 함께 사용되는 oauth-proxy 컨테이너

v1.0/1.1/2.0

sidecarInjectorWebhook

사이드카 인젝터 webhook 컨테이너

v1.0/1.1

tracing.jaeger

일반 Jaeger 컨테이너 - 일부 설정은 적용할 수 없습니다. Service Mesh 컨트롤 플레인 구성에서 기존 Jaeger 리소스를 지정하면 Jaeger 설치에 대한 완전한 사용자 정의가 지원됩니다.

v1.0/1.1/2.0

tracing.jaeger.agent

Jaeger 에이전트와 관련된 설정

v1.0/1.1/2.0

tracing.jaeger.allInOne

Jaeger allInOne과 관련된 설정

v1.0/1.1/2.0

tracing.jaeger.collector

Jaeger 수집기와 관련된 설정

v1.0/1.1/2.0

tracing.jaeger.elasticsearch

Jaeger elasticsearch 배포와 관련된 설정

v1.0/1.1/2.0

tracing.jaeger.query

Jaeger 쿼리와 관련된 설정

v1.0/1.1/2.0

prometheus

prometheus 컨테이너

v1.0/1.1/2.0

kiali

Kiali 컨테이너 - Service Mesh 컨트롤 플레인 구성에서 기존 Kiali 리소스를 지정하면 Kiali 설치에 대한 완전한 사용자 정의가 지원됩니다.

v1.0/1.1/2.0

grafana

Grafana 컨테이너

v1.0/1.1/2.0

3scale

3scale 컨테이너

v1.0/1.1/2.0

wasmExtensions.cacher

WASM 확장 cacher 컨테이너

v2.0 - 기술 프리뷰

일부 구성 요소는 리소스 제한 및 스케줄링을 지원합니다. 자세한 내용은 성능 및 확장성을 참조하십시오.

2.3.4.8.4. 애플리케이션 및 워크로드를 마이그레이션하기 위한 다음 단계

애플리케이션 워크로드를 새 메시로 이동하고 이전 인스턴스를 제거하여 업그레이드를 완료합니다.

2.3.5. 데이터 플레인 업그레이드

컨트롤 플레인을 업그레이드한 후에도 데이터 플레인이 계속 작동합니다. 그러나 Envoy 프록시에 업데이트를 적용하고 프록시 구성에 대한 변경 사항을 적용하려면 애플리케이션 Pod 및 워크로드를 다시 시작해야 합니다.

2.3.5.1. 애플리케이션 및 워크로드 업데이트

마이그레이션을 완료하려면 메시의 모든 애플리케이션 pod를 다시 시작하여 Envoy 사이드카 프록시와 해당 구성을 업그레이드합니다.

배포 롤링 업데이트를 수행하려면 다음 명령을 사용합니다.

$ oc rollout restart <deployment>

메시를 구성하는 모든 애플리케이션에 대해 롤링 업데이트를 수행해야 합니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.