Operator를 사용하여 Istio 1.6으로 업그레이드

버전 1.6부터 Istio on Google Kubernetes Engine 부가기능은 설치 및 구성을 위해 Istio Operator를 사용합니다. Istio Operator는 Kubernetes 연산자 패턴을 따릅니다. Operator를 사용하면 Istio 설치를 위해 Kubernetes 커스텀 리소스 정의(CRD)를 정의하여 Istio를 구성할 수 있습니다. 그런 다음 Operator는 컨트롤러를 사용하여 커스텀 리소스와 일치하도록 설치를 변경합니다.

클러스터를 1.17.9-gke.6300 이상으로 업그레이드하면 기존 1.4.x Istio 제어 영역과 함께 Istio 1.6 Operator 및 제어 영역이 설치됩니다. 업그레이드를 위해서는 사용자 작업이 필요하며, 이중 제어 영역 업그레이드 프로세스를 따릅니다(Istio 문서에서 카나리아 업그레이드라고 부름). 이중 제어 영역 업그레이드의 경우, 새 제어 영역을 가리키도록 워크로드에 라벨을 설정하고 순차적 재시작을 수행하여 1.6 버전으로 마이그레이션할 수 있습니다.

1.5 버전의 Istio on GKE 부가기능은 출시하지 않습니다. 버전 1.6은 1.4.10 후에 출시하는 버전입니다.

  • 클러스터를 GKE 버전 1.17 이상으로 업그레이드하면 업그레이드 절차 중에 기본 제공 인그레스 게이트웨이를 약 5분 동안 사용할 수 없게 되며 인그레스 배포에 대한 사용자 수정 사항이 손실됩니다. 이 문제를 방지하려면 별도의 사용자 정의 게이트웨이를 설치하고 관리하는 것이 좋습니다. 자세한 내용은 게이트웨이 추가를 참조하세요.
  • GKE 1.16에서 1.17 및 R33 이전의 1.18 버전으로의 업그레이드에는 알려진 문제가 있습니다. 수정 사항은 1.17.12-gke.1501 이상 및 1.18.9-gke.1501 이상 버전에서 제공됩니다. 이 문제는 Istio 시스템 네임스페이스로 만든 커스텀 리소스가 업그레이드 중 삭제되도록 만듭니다. 이러한 리소스는 수동으로 다시 만들어야 합니다. 영향을 받는 버전으로만 업그레이드하는지 확인합니다. 이 문제는 업그레이드 중에만 발생하므로, 새로운 클러스터에는 영향을 주지 않습니다.

Istio Operator 장점

Operator는 설치 구성이 더 뛰어납니다. 1.6 이전의 부가기능 버전에서 GKE 부가기능 관리자는 Istio 매니페스트에 대한 모든 변경사항을 조정하고 대부분 유형의 구성 변경을 방지합니다. Istio Operator는 이러한 제한이 없습니다. Operator는 설치 중 제공한 IstioOperator 커스텀 리소스(CR)를 기반으로 Istio 제어 영역 설치 매니페스트를 생성합니다. 이 CR은 완전히 사용자의 제어 대상에 포함되며, 조정되지 않습니다.

Operator로 Istio 1.6으로 업그레이드한 후에는 Istio on GKE 부가기능에서 Istio 오픈소스 버전으로 마이그레이션할 수 있습니다.

Operator를 사용하여 Istio 1.6으로 업그레이드

Operator로 전환한 다음에만 이 단계를 수행할 필요가 있습니다. 이후 업그레이드는 이중 제어 영역 업그레이드 프로세스를 따릅니다.

  1. Istio 1.6(1.17.7-gke.8+, 1.17.8-gke.6+)을 포함하는 GKE 버전을 선택하고 클러스터를 업그레이드합니다.

    Istio 1.6의 Istio on Google Kubernetes Engine 부가기능은 두 가지 버전의 Istio를 설치합니다.

    • 하나는 부가기능 관리자(클러스터 업그레이드 후 활성화됨)로 제어되는 정적 매니페스트 버전이고,

    • 다른 하나는 Operator로 제어되는 1.6 버전입니다(사용 설정될 때까지 비활성 상태임). 비활성 1.6 버전은 프록시에 연결되지 않고, 무시 가능한 수준의 클러스터 리소스를 소비합니다.

    현재 설치된 Istio 버전이 대상 정적 매니페스트의 버전과 다른 경우, 클러스터를 업그레이드하면 Istio 인플레이스 업그레이드가 수행될 수도 있습니다. 예를 들어 클러스터가 현재 Istio 1.4.6-gke.0을 실행 중이고, GKE 클러스터 버전 1.17.7-gke.8을 선택하면 Istio 제어 영역이 업그레이드 중에 1.4.10-gke.0(또는 그 이상)으로 업그레이드됩니다.

  2. Istio의 1.6 버전이 설치되었고 실행되는지 확인합니다.

    kubectl get pods -n istio-system
    

    1.4 제어 영역 구성요소와 함께 istiod Pod가 실행 중 상태로 표시됩니다. 예를 들면 다음과 같습니다.

    NAME                                             READY   STATUS      RESTARTS   AGE
    istio-citadel-78b9b5b589-52cqg                   1/1     Running     0          4m16s
    istio-galley-79bd448645-zxfjm                    1/1     Running     0          4m16s
    istio-ingressgateway-b4f8986c4-dbr6c             1/1     Running     0          4m27s
    istio-pilot-dc558d859-cnrqt                      2/2     Running     1          4m16s
    istio-policy-8664dd6c4-m42xs                     2/2     Running     1          4m15s
    istio-security-post-install-1.4.10-gke.4-255r6   0/1     Completed   0          4m15s
    istio-sidecar-injector-7f85d7f7c4-vt2x9          1/1     Running     0          4m15s
    istio-telemetry-69b6477c5f-4pr6v                 2/2     Running     2          4m15s
    <b>istiod-istio-163-5fccfcf4dd-2p9c8                1/1     Running     0          3m31s</b>
    prometheus-7d9f49d945-4nps2                      2/2     Running     0          3m17s
    promsd-696bcc5b96-ln2s8                          2/2     Running     1          4m15s
    
  3. 지원되지 않는 v1alpha1 보안 정책 구성 객체를 마이그레이션했는지 확인하세요. 자세한 내용은 Istio 업그레이드 노트를 참조하기 바랍니다.

  4. 1.4.x 제어 영역에서 구성 검증을 사용 중지합니다.

    1. galley ClusterRole 리소스를 수정합니다.

      kubectl edit clusterrole -n istio-system istio-galley-istio-system
      
    2. 다음 목록 항목에서 '*' 값을 get으로 변경합니다.

      - apiGroups:
        - admissionregistration.k8s.io
        resources:
        - validatingwebhookconfigurations
        verbs:
        - '*' # change this to get
      

      업데이트 후에는 코드가 다음과 같이 표시됩니다.

      - apiGroups:
        - admissionregistration.k8s.io
        resources:
        - validatingwebhookconfigurations
        verbs:
        - get
      
    3. Galley ValidatingWebhookConfiguration을 삭제합니다.

      kubectl delete ValidatingWebhookConfiguration istio-galley -n istio-system
      

1.6으로 네임스페이스 마이그레이션

새 버전을 설치해도 기존 사이드카 프록시에는 영향을 미치지 않습니다. 기존 사이드카 프록시를 업그레이드하려면 새 제어 영역을 가리키도록 구성해야 합니다. 사이드카 삽입 중에는 네임 스페이스 라벨 istio.io/rev를 기반으로 제어됩니다.

  1. 정확한 Istio 1.6 버전 번호를 찾습니다.

    kubectl -n istio-system get pods -lapp=istiod --show-labels

    이 명령어 출력은 다음과 비슷합니다.

    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
    istiod-istio-163-5fccfcf4dd-2p9c8   1/1     Running   0          22h   app=istiod,istio.io/rev=istio-163,istio=istiod,pod-template-hash=5fccfcf4dd

    이 예시에서 버전은 istio-163입니다.

  2. 1.6으로 롤오버할 워크로드가 포함된 네임스페이스에 라벨을 다시 지정합니다. 버전 라벨은 제어 영역의 버전과 일치해야 합니다. 다음 명령어에서 VERSION을 이전 명령어의 버전으로 바꿉니다(예: istio-163).

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=VERSION --overwrite
  3. 선택한 워크로드의 순차적 재시작을 수행합니다.

    kubectl rollout restart deployment DEPLOYMENT -n NAMESPACE
  4. 네임스페이스의 Pod를 나열합니다.

    kubectl get pods -n NAMESPACE
  5. Pod 중 하나를 선택하여 워크로드가 사이드카 프록시의 1.6 버전으로 삽입되었는지 확인합니다.

    kubectl describe pod -n NAMESPACE YOUR_SELECTED_POD

    출력에는 1.6 버전의 프록시 컨테이너가 표시됩니다. 예를 들면 다음과 같습니다.

    ...
    istio-proxy:
      Container ID:  docker://22f62020ddcc6f8e02d800b5614e02aae2d082ce991c9e3eab9846d9f2cf90f5
      Image:         gcr.io/gke-release/istio/proxyv2:1.6.3-gke.0
    ...
    
  6. 새 Istio 버전으로 모든 네임스페이스의 마이그레이션을 완료합니다. 모든 워크로드 네임스페이스에 대해 3~5단계를 반복합니다.

Anthos Service Mesh로 마이그레이션하려면 이전 제어 영역을 사용 중지합니다.

Istio 부가기능에 계속 머물려면 다음 단계를 따라 인그레스 게이트웨이를 새 Istio 버전으로 마이그레이션합니다.

  1. IstioOperator CR을 수정하여 인그레스 게이트웨이를 1.6 버전으로 바꿉니다.

    kubectl edit istiooperators -n istio-system istio-1-6-3-gke-0
    
  2. 게이트웨이의 enabled 설정을 true로 변경합니다.

    ...
    spec:
      components:
        ingressGateways:
        - enabled: false # change this to true
          name: istio-ingressgateway
    
  3. 게이트웨이 Pod가 새 1.6 버전으로 다시 생성되었는지 확인합니다.

    kubectl get pods -n istio-system -l app=istio-ingressgateway -o yaml | grep image
    

이전 제어 영역 해제

모든 워크로드 프록시에 1.6 제어 영역이 사용된 후에는 이전의 각 구성요소 복제본을 0으로 축소하여 이전 제어 영역을 해제할 수 있습니다.

복제본의 규모를 축소하려면 다음 안내를 따르세요.

kubectl scale deploy -n istio-system --replicas=0 \
  istio-citadel istio-galley istio-pilot istio-policy istio-sidecar-injector istio-telemetry prometheus promsd

남은 Istio 리소스가 클러스터에 있어도 문제가 발생하지 않습니다.

이제 Istio에 남아있는 경우 이제 IstioOperator CR을 수정하고 자신의 일정에 따라 Operator를 업그레이드할 수 있습니다. 자세한 내용은 Operator 문서를 참조하세요.

Anthos Service Mesh로 마이그레이션

Anthos Service Mesh로 마이그레이션하기 전에 아래 설명에 따라 Operator를 사용 중지해야 합니다. 마이그레이션 후에도 Operator와 동일한 IstioOperator CR 형식을 사용하여 서비스 메시를 구성하지만, 설치된 상태를 변경하고자 할 때는 Operator 컨트롤러가 IstioOperator CR을 지속적으로 감시하는 것이 아니라 istioctl install 명령어를 사용하여 구성합니다.

Anthos Service Mesh로 마이그레이션하려면 Cloud 프로젝트와 클러스터 준비에 대한 모든 세부정보를 처리하는 Google 제공 스크립트를 사용한 후 istioctl install의 Anthos Service Mesh 버전을 사용하여 Anthos Service Mesh를 설치합니다. Anthos Service Mesh 1.7로 마이그레이션하는 것이 좋지만, 스크립트의 1.6 버전을 사용하여 Anthos Service Mesh 1.6으로 마이그레이션할 수 있습니다.

요구사항

클러스터가 다음 요구사항을 충족하는지 확인합니다.

  • vCPU가 4개 이상 있는 머신 유형(예: e2-standard-4). 클러스터의 머신 유형에 4개 미만의 vCPU가 있으면 여러 머신 유형에 워크로드 마이그레이션에 설명된 대로 머신 유형을 변경합니다.

  • 최소 노드 수는 머신 유형에 따라 다릅니다. Anthos Service Mesh에는 최소 8개의 vCPU가 필요합니다. 머신 유형에 vCPU가 4개 있는 경우 클러스터에는 노드가 2개 이상 있어야 합니다. 머신 유형에 vCPU가 8개 있는 경우 클러스터에는 노드가 1개만 필요합니다. 노드를 추가해야 하는 경우 클러스터 크기 조절을 참조하세요.

  • 이 스크립트는 클러스터에서 워크로드 아이덴티티를 사용 설정합니다. 워크로드 아이덴티티는 Google API 호출에 권장되는 방법입니다. 워크로드 아이덴티티를 사용 설정하면 워크로드 아이덴티티 제한사항의 설명대로 워크로드에서 Google API로 호출이 보호되는 방식이 변경됩니다.

  • 서비스 메시에 포함하려면 서비스 포트의 이름이 지정되어야 하며 이름은 name: protocol[-suffix] 구문에서 포트 프로토콜을 포함해야 합니다. 여기서 대괄호는 대시로 시작해야 하는 선택적 서픽스를 나타냅니다. 자세한 내용은 서비스 포트 이름 지정을 참조하세요.

  • 비공개 클러스터에 Anthos Service Mesh를 설치하는 경우 자동 사이드카 삽입과 함께 사용되는 웹훅을 가져오려면 방화벽에서 포트 15017을 열어야 제대로 작동합니다. 자세한 내용은 비공개 클러스터에서 포트 열기를 참조하세요.

  • 조직에서 서비스 경계를 만든 경우 경계에 Mesh CA 서비스를 추가해야 할 수도 있습니다. 자세한 내용은 서비스 경계에 Mesh CA 추가를 참조하세요.

마이그레이션 계획

마이그레이션을 계획하려면 Istio에서 마이그레이션 준비를 참조하세요.

Operator 사용 중지

운영자가 Anthos Service Mesh가 설치한 istio-ingressgateway를 다시 조정하지 못하게 하려면 Operator를 사용 중지해야 합니다.

Operator를 사용 중지하려면 다음 단계를 따르세요.

  1. Operator 버전을 가져옵니다.

    kubectl get istiooperators -n istio-system
    

    출력은 다음과 비슷합니다.

    NAME                        REVISION     STATUS    AGE
    istio-1-6-11-gke-0          istio-1611   HEALTHY   12h

    샘플 출력에서 Operator 버전은 istio-1-6-11-gke-0입니다.

  2. Operator를 사용 중지합니다. 다음 명령어에서 VERSION을 이전 단계의 Operator 버전으로 바꿉니다.

    kubectl patch -n istio-system istiooperator VERSION -p '{"spec":{"profile":"disabled"}}' --type=merge
    

    이 명령어는 연산자가 클러스터를 변경하지 못하도록 차단합니다.

Anthos Service Mesh로 마이그레이션

이 섹션에서는 install_asm 스크립트를 사용하여 Anthos Service Mesh로 마이그레이션하는 방법을 설명합니다. Anthos Service Mesh 1.7로 마이그레이션하는 것이 좋지만 Anthos Service Mesh 1.6으로의 마이그레이션도 지원됩니다.

1.7로 마이그레이션

  1. 필수 도구 설치.

  2. install_asm 스크립트 다운로드.

  3. 스크립트의 옵션 및 플래그를 검토합니다.

    Istio 설치를 맞춤설정하지 않은 경우 Citadel을 인증 기관(CA)으로 계속 사용하려면 스크립트에 대한 다음 인수를 사용하여 Anthos Service Mesh로 마이그레이션할 수 있습니다.

    ./install_asm \
      --project_id PROJECT_ID \
      --cluster_name CLUSTER_NAME\
      --cluster_location CLUSTER_LOCATION \
      --mode migrate \
      --ca citadel \
      --enable_apis
    

    Anthos Service Mesh 1.7은 또한 GitHub에서 이그레스 게이트웨이 사용 설정과 같이 흔히 사용되는 기능에 사용할 수 있는 오버레이 파일을 제공합니다. 자세한 내용은 선택적 기능 사용 설정을 참조하세요.

  4. Anthos Service Mesh 설정을 완료하려면 자동 사이드카 주입을 사용 설정하고 워크로드를 배포 또는 재배포해야 합니다.

1.6으로 마이그레이션

  1. 필수 도구 설치.

  2. install_asm 스크립트 다운로드.

  3. 스크립트의 옵션 및 플래그를 검토합니다.

    Istio 설치를 맞춤설정하지 않은 경우 Citadel을 인증 기관(CA)으로 계속 사용하려면 스크립트에 대한 다음 인수를 사용하여 Anthos Service Mesh로 마이그레이션할 수 있습니다.

    ./install_asm \
      --project_id PROJECT_ID \
      --cluster_name CLUSTER_NAME\
      --cluster_location CLUSTER_LOCATION \
      --mode migrate \
      --ca citadel \
      --enable_apis
    
  4. Anthos Service Mesh 설정을 완료하려면 자동 사이드카 주입을 사용 설정하고 워크로드를 배포 또는 재배포해야 합니다.

마이그레이션 후

다음 명령어를 실행하고 VERSION을 이전에 Operator를 사용 중지하는 데 사용한 연산자 버전으로 바꿉니다.

kubectl patch -n istio-system istiooperator VERSION -p '{"spec":{"profile":"empty"}}'

이 명령어는 empty 프로필을 통해 Operator를 다시 사용 설정함으로써 이전에 클러스터에서 설치된 리소스를 삭제합니다. install_asm 스크립트에 의해 설치된 게이트웨이 또는 제어 영역 요소는 포함되지 않습니다.