Istio on GKE 업그레이드

이 가이드에는 특정 업그레이드 지침이 포함된 모든 출시 버전에 대한 업그레이드 노트가 포함되어 있습니다. 이 가이드에 설명되지 않은 업그레이드의 경우 특별한 작업을 수행할 필요가 없습니다.

연산자 기반 1.6 Istio를 최신 패치 출시 버전으로 업그레이드

다음을 실행하는 GKE 클러스터를 사용해야 합니다.

  • 1.17.17-gke.3100 이상
  • 1.18.16-gke.1600 이상
  • 1.19.8-gke.1600 이상

그렇지 않으면 업그레이드 안내에 따라 클러스터를 업그레이드합니다.

istio-operator 1.6 배포 이미지를 패치하려면 Istio on GKE 클러스터에 연결하도록 구성된 워크스테이션에서 다음 명령어를 실행합니다.

  1. 현재 연산자 이미지 버전을 백업합니다.

    kubectl -n istio-operator get deployment/istio-operator -o \
    jsonpath={.spec.template.spec.containers..image} > operator-image-backup
    
    more operator-image-backup
    
  2. 업데이트할 버전을 식별합니다. 예를 들어 Istio on GKE를 1.6.14-gke.5로 업그레이드하려면 다음 명령어를 실행합니다.

    kubectl -n istio-operator set image deployment/istio-operator \
    istio-operator=gcr.io/gke-release/istio/operator:1.6.14-gke.5
    

    제어 영역과 istio-ingressgateway는 자동으로 업그레이드됩니다.

  3. 워크로드를 다시 시작하여 새 Envoy 프록시를 다시 삽입합니다.

문제가 발생하여 롤백하려면 다음 명령어를 실행합니다.

kubectl -n istio-operator set image deployment/istio-operator \
istio-operator=$(cat operator-image-backup)

1.4 Istio를 최신 패치 출시 버전으로 업그레이드

Istio 1.4를 업그레이드하려면 Istio on GKE 클러스터에 연결하도록 구성된 워크스테이션에서 다음 명령어를 실행합니다.

  1. 현재 배포 이미지를 백업합니다.

    export ORIGINAL_ISTIO_VERSION=$(kubectl -n  istio-system get deployment/istio-pilot -o \
    jsonpath={.spec.template.spec.containers[0].image} | sed 's/.*://')
    
    echo $ORIGINAL_ISTIO_VERSION
    
  2. 환경 변수를 업그레이드할 Istio 버전으로 설정합니다. 예를 들어 다음 명령어를 실행하여 1.4.10-gke.17로 설정합니다.

    export ISTIO_VERSION=1.4.10-gke.17
    
  3. Istio 부가기능 배포 이미지 버전을 업데이트합니다.

    kubectl set image -n istio-system deployment/istio-ingressgateway istio-proxy=gke.gcr.io/istio/proxyv2:${ISTIO_VERSION}
    
    kubectl set image -n istio-system deployment/istio-citadel citadel=gke.gcr.io/istio/citadel:${ISTIO_VERSION}
    
    kubectl set image -n istio-system deployment/istio-galley galley=gke.gcr.io/istio/galley:${ISTIO_VERSION}
    
    kubectl set image -n istio-system deployment/istio-sidecar-injector sidecar-injector-webhook=gke.gcr.io/istio/sidecar_injector:${ISTIO_VERSION}
    
    kubectl set image -n istio-system deployment/istio-pilot discovery=gke.gcr.io/istio/pilot:${ISTIO_VERSION} istio-proxy=gke.gcr.io/istio/proxyv2:${ISTIO_VERSION}
    
    kubectl set image -n istio-system deployment/istio-policy mixer=gke.gcr.io/istio/mixer:${ISTIO_VERSION} istio-proxy=gke.gcr.io/istio/proxyv2:${ISTIO_VERSION}
    
    kubectl set image -n istio-system deployment/istio-telemetry mixer=gke.gcr.io/istio/mixer:${ISTIO_VERSION} istio-proxy=gke.gcr.io/istio/proxyv2:${ISTIO_VERSION}
    
  4. 사이드카 인젝터 구성 맵을 가져옵니다.

    kubectl get configmap -n istio-system istio-sidecar-injector -oyaml > sidecar-injector.yaml
    
  5. 모든 원본 이미지 버전은 대상 istio 버전으로 바꿉니다.

    sed -i -- "s/${ORIGINAL_ISTIO_VERSION}/${ISTIO_VERSION}/g" sidecar-injector.yaml
    
  6. 업데이트된 configmap을 적용합니다.

    kubectl apply -f sidecar-injector.yaml
    
  7. 워크로드를 다시 시작하여 새 Envoy 프록시를 다시 삽입합니다.

문제가 발생하여 롤백하려면 ISTIO_VERSION을 이전 버전으로 설정하여 동일한 단계를 실행하면 됩니다.

Istio 1.1.3에서 업그레이드

Istio on GKE 부가기능 버전 1.1.3-gke.0에는 PodDisruptionBudget(PDB) 정의가 있습니다. 이 정의에서는 사용 가능한 복제본 수가 최소 1 이상이어야 합니다. 버전 1.1.7-gke.0부터는 부가기능에 이 요구사항이 더 이상 없습니다. 하지만 이 PDB가 설치된 후에는 PDB를 위반할 경우 다른 버전으로의 업그레이드가 방지됩니다. 즉, 1.1.3-gke.0에서 더 높은 버전 1.1.x(예: 1.1.7-gke.0)로 업그레이드하려면 먼저 모든 Istio HorizontalPodAutoscaler 리소스에 대해 minReplicas 값을 2 이상으로 늘려야 합니다. 그렇지 않으면 PodDisruptionBudget 위반으로 인해 업그레이드가 실패합니다.

Istio 1.1로 업그레이드

1.0.x에서 1.1.x로 GKE 클러스터를 업그레이드하려면 먼저 해당 구성이 1.1과 호환되는지 확인해야 합니다. Istio 1.1의 다음 변경사항은 잠재적으로 하위 호환성을 가지며, 중단 또는 예상치 않은 동작을 방지하기 위해 구성을 업데이트해야 할 수 있습니다. 구성 확인을 위해 업그레이드 스크립트를 실행하는 것이 좋습니다.

주석을 통한 TLS 동작 재정의

1.0에서는 주석을 통해 TLS 정책을 수정합니다. 1.1에서는 이러한 주석이 작동하지 않으며, 대신 Policy 및 DestinationRule을 구성해야 합니다. 자세한 내용은 Istio 문서를 참조하세요.

업그레이드 프로세스

Istio 문서에 따라 주석을 Policy 및 DestinationRule로 바꿉니다. 이 변경은 1.0 구성을 중단시키지 않습니다. 1.1로 업그레이드한 후에는 이전 주석이 효과가 없으며, 따라서 이전 주석을 삭제하거나 그대로 둘 수도 있습니다.

RbacConfig에서 ClusterRbacConfigㄹ로 이름 변경

RbacConfig CRD 이름이 ClusterRbacConfig로 변경되었습니다. 스키마는 변경되지 않았습니다.

업그레이드 프로세스

모든 RbacConfig CR에 대해 동일한 ClusterRbacConfig CR을 만듭니다.

대상 규칙 우선 적용

서비스로 사이드카 라우팅하는 중에는 사이드카와 동일한 네임스페이스에 있는 대상 서비스에 대한 대상 규칙이 우선 적용되고, 이후 서비스 네임스페이스에 있는 대상 규칙이 적용되고, 마지막으로 다른 네임스페이스에 있는 대상 규칙이 적용됩니다(있는 경우).

업그레이드 프로세스

DestinationRules에서 동일한 대상 서비스에 대해 여러 네임스페이스의 규칙이 포함되어 있는지 확인합니다. 그렇다면 규칙을 자세히 조사하여 얼마나 겹치는지 확인하고, 원하는 동작을 위해 올바른 우선 순위로 적용되는지 확인합니다.