다음을 통해 공유

Azure Kubernetes Service용 Istio 기반 서비스 메시 추가 기능 업그레이드

  • 아티클

이 문서에서는 Azure Kubernetes Service(AKS)용 Istio 기반 서비스 메시 추가 기능의 업그레이드 환경을 다룹니다.

Istio 기반 서비스 메시 추가 기능에 대한 새로운 부 수정 버전 또는 패치 릴리스에 대한 공지 사항은 AKS 릴리스 정보에 게시됩니다. 서비스 메시 추가 기능 수정 버전에 대한 릴리스 일정 및 지원에 대해 자세히 알아보려면 지원 정책을 읽어보세요.

부 수정 버전 업그레이드

Istio 추가 기능을 사용하면 카나리아 업그레이드 프로세스를 사용하여 부 수정 버전을 업그레이드할 수 있습니다. 업그레이드가 시작되면 새(카나리아) 수정 버전의 컨트롤 플레인은 초기(안정적인) 수정 버전의 컨트롤 플레인과 함께 배포됩니다. 그런 다음 모니터링 도구를 사용하여 이 프로세스 중에 워크로드의 상태를 추적하면서 데이터 평면 워크로드를 수동으로 롤오버할 수 있습니다. 워크로드의 상태에 문제가 없는 경우 새 수정 버전만 클러스터에 유지되도록 업그레이드를 완료할 수 있습니다. 그렇지 않으면 Istio의 이전 수정 버전으로 롤백할 수 있습니다.

클러스터가 현재 지원되는 Istio의 부 수정 버전을 사용하고 있는 경우 업그레이드는 한 번에 하나의 부 수정 버전만 허용됩니다. 클러스터가 지원되지 않는 수정 버전의 Istio를 사용하는 경우 해당 Kubernetes 버전에 대해 지원되는 가장 낮은 Istio 부 수정 버전으로 업그레이드해야 합니다. 그 후에는 한 번에 하나의 부 수정 버전으로 업그레이드를 다시 수행할 수 있습니다.

다음 예제에서는 네임스페이스의 모든 워크로드를 사용하여 수정 버전 asm-1-22 에서 업그레이드하는 방법을 보여 줍니다default.asm-1-23 단계는 모든 사소한 업그레이드에 대해 동일하며 임의의 수의 네임스페이스에 사용할 수 있습니다.

  1. az aks mesh get-upgrades 명령을 사용하여 업그레이드 대상으로 클러스터에 사용할 수 있는 수정 버전을 확인합니다.

    az aks mesh get-upgrades --resource-group $RESOURCE_GROUP --name $CLUSTER

    이 명령에서 반환되지 않는 최신 수정 버전이 표시되어야 하는 경우 최신 수정 버전과 호환되도록 AKS 클러스터를 먼저 업그레이드해야 할 수 있습니다.

  2. 클러스터에서 기존 메시 수정 버전에 대한 메시 구성을 설정하는 경우 다음 단계에서 카나리아 업그레이드를 시작하기 전에 네임스페이스의 새 수정 버전에 aks-istio-system 해당하는 별도의 ConfigMap을 만들어야 합니다. 이 구성은 새 수정 버전의 컨트롤 플레인이 클러스터에 배포되는 순간 적용 가능합니다. 자세한 내용은 여기에서 찾을 수 있습니다.

  3. az aks mesh upgrade start를 사용하여 수정 버전 asm-1-22에서 asm-1-23로 카나리아 업그레이드를 시작합니다.

    az aks mesh upgrade start --resource-group $RESOURCE_GROUP --name $CLUSTER --revision asm-1-23

    카나리아 업그레이드는 1.23 제어 평면이 1.22 컨트롤 플레인과 함께 배포됨을 의미합니다. 두 컨트롤 플레인은 업그레이드를 완료하거나 롤백할 때까지 계속 공존합니다.

  4. 필요에 따라 수정 태그를 사용하여 각 네임스페이스의 레이블을 수동으로 다시 지정하지 않고도 데이터 평면을 새 수정 버전으로 롤오버할 수 있습니다. 네임스페이스를 새 수정 버전으로 이동할 때 수동으로 레이블을 다시 지정하는 것은 지루하고 오류가 발생하기 쉽습니다. 수정 태그는 수정 버전을 가리키는 안정적인 식별자 역할을 하여 이 문제를 해결합니다.

    클러스터 연산자는 각 네임스페이스의 레이블을 다시 지정하는 대신 새 수정 버전을 가리키도록 태그를 변경할 수 있습니다. 해당 태그로 레이블이 지정된 모든 네임스페이스는 동시에 업데이트됩니다. 그러나 올바른 버전의 istio-proxy 사이드카가 주입되도록 워크로드를 다시 시작해야 합니다.

    업그레이드 중에 수정 태그를 사용하려면 다음을 수행합니다.

    1. istioctl CLI 설치

    2. 초기 수정 버전에 대한 수정 태그를 만듭니다. 이 예제에서는 이름을 다음과 같이 지정합니다 prod-stable.

      istioctl tag set prod-stable --revision asm-1-22 --istioNamespace aks-istio-system

    3. 업그레이드 중에 설치된 수정 버전에 대한 수정 태그를 만듭니다. 이 예제에서는 이름을 다음과 같이 지정합니다 prod-canary.

      istioctl tag set prod-canary --revision asm-1-23 --istioNamespace aks-istio-system

    4. 수정 태그에 매핑할 애플리케이션 네임스페이스에 레이블을 지정합니다.

      # label default namespace to map to asm-1-22
kubectl label ns default istio.io/rev=prod-stable --overwrite

      또한 최신 수정 버전에 대한 네임스페이스에 istio.io/rev=prod-canary 레이블을 지정할 수도 있습니다. 그러나 해당 네임스페이스의 워크로드는 다시 시작될 때까지 새 사이드카로 업데이트되지 않습니다.

      레이블이 지정된 후 새 애플리케이션이 네임스페이스에 만들어지면 해당 네임스페이스의 수정 태그에 해당하는 사이드카가 삽입됩니다.

  5. asm-1-22과 asm-1-23 모두에 해당하는 컨트롤 플레인 Pod가 있는지 확인합니다.

    1. istiod Pod를 확인합니다.

      kubectl get pods -n aks-istio-system

      예제 출력:

      NAME                                        READY   STATUS    RESTARTS   AGE
istiod-asm-1-22-55fccf84c8-dbzlt            1/1     Running   0          58m
istiod-asm-1-22-55fccf84c8-fg8zh            1/1     Running   0          58m
istiod-asm-1-23-f85f46bf5-7rwg4             1/1     Running   0          51m
istiod-asm-1-23-f85f46bf5-8p9qx             1/1     Running   0          51m

    2. 수신을 사용하는 경우 수신 Pod를 확인합니다.

      kubectl get pods -n aks-istio-ingress

      예제 출력:

      NAME                                                          READY   STATUS    RESTARTS   AGE
aks-istio-ingressgateway-external-asm-1-22-58f889f99d-qkvq2   1/1     Running   0          59m
aks-istio-ingressgateway-external-asm-1-22-58f889f99d-vhtd5   1/1     Running   0          58m
aks-istio-ingressgateway-external-asm-1-23-7466f77bb9-ft9c8   1/1     Running   0          51m
aks-istio-ingressgateway-external-asm-1-23-7466f77bb9-wcb6s   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-22-579c5d8d4b-4cc2l   1/1     Running   0          58m
aks-istio-ingressgateway-internal-asm-1-22-579c5d8d4b-jjc7m   1/1     Running   0          59m
aks-istio-ingressgateway-internal-asm-1-23-757d9b5545-g89s4   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-23-757d9b5545-krq9w   1/1     Running   0          51m

      두 수정 버전의 수신 게이트웨이 Pod가 나란히 배포되는지 확인합니다. 그러나 서비스와 해당 IP는 변경할 수 없는 상태로 유지됩니다.

  6. 새 Pod가 새 수정 버전 및 해당 컨트롤 플레인과 연결된 Istio 사이드카에 매핑되도록 네임스페이스의 레이블을 다시 지정합니다.

    1. 수정 태그를 사용하는 경우 태그 자체를 덮어써 prod-stable 매핑을 변경합니다.

      istioctl tag set prod-stable --revision asm-1-23 --istioNamespace aks-istio-system --overwrite

      태그-수정 버전 매핑을 확인합니다.

      istioctl tag list

      두 태그 모두 새로 설치된 수정 버전을 가리킵니다.

      TAG           REVISION   NAMESPACES
prod-canary   asm-1-23   default
prod-stable   asm-1-23   ...

      이 경우 각 네임스페이스의 레이블을 개별적으로 다시 지정할 필요가 없습니다.

    2. 수정 태그를 사용하지 않는 경우 새 수정 버전을 가리키도록 데이터 평면 네임스페이스의 레이블을 다시 지정해야 합니다.

      kubectl label namespace default istio.io/rev=asm-1-23 --overwrite

    레이블 다시 지정은 워크로드가 다시 시작될 때까지 워크로드에 영향을 주지 않습니다.

  7. 각 애플리케이션 워크로드를 다시 시작하여 개별적으로 롤오버하세요. 예시:

    kubectl rollout restart deployment <deployment name> -n <deployment namespace>

  8. 다시 시작한 후 모니터링 도구와 대시보드를 확인하여 워크로드가 모두 정상 상태로 실행되고 있는지 확인합니다. 결과에 따라 다음 두 가지 옵션이 있습니다.

    1. 카나리아 업그레이드 완료: 워크로드가 모두 예상대로 정상 상태로 실행되고 있는 경우 카나리아 업그레이드를 완료할 수 있습니다. 업그레이드가 완료되면 이전 수정 버전의 컨트롤 플레인이 제거되고 클러스터에 새 수정 버전의 컨트롤 플레인이 남습니다. 다음 명령을 실행하여 카나리아 업그레이드를 완료합니다.

      az aks mesh upgrade complete --resource-group $RESOURCE_GROUP --name $CLUSTER

    2. 카나리아 업그레이드 롤백: 워크로드의 상태에 문제가 있는 경우 Istio의 이전 수정 버전으로 롤백할 수 있습니다.

    • 이전 수정 버전으로 네임스페이스 레이블 다시 지정: 수정 태그를 사용하는 경우:

      istioctl tag set prod-stable --revision asm-1-22 --istioNamespace aks-istio-system --overwrite

      또는 수정 태그를 사용하지 않는 경우:

      kubectl label namespace default istio.io/rev=asm-1-22 --overwrite

    • 이러한 워크로드를 다시 시작하여 이전 Istio 수정 버전에 해당하는 사이드카를 사용하도록 워크로드를 롤백합니다.

      kubectl rollout restart deployment <deployment name> -n <deployment namespace>

    • 컨트롤 플레인을 이전 수정 버전으로 롤백합니다.

      az aks mesh upgrade rollback --resource-group $RESOURCE_GROUP --name $CLUSTER

    수정 태그를 prod-canary 제거할 수 있습니다.

    istioctl tag remove prod-canary --istioNamespace aks-istio-system

  9. 이전에 수정 버전에 대해 메시 구성을 설정한 경우 이제 완료/롤백 중에 클러스터에서 제거된 수정 버전에 대한 ConfigMap을 삭제할 수 있습니다.

수신 게이트웨이를 통한 부 수정 버전 업그레이드

현재 Istio 수신 게이트웨이를 사용 중이고 부 수정 버전 업그레이드를 수행 중인 경우 Istio 수신 게이트웨이 Pod/배포는 수정 버전별로 배포된다는 점에 유의해야 합니다. 그러나 여러 수정 버전을 통해 모든 수신 게이트웨이 Pod에서 단일 LoadBalancer 서비스를 제공하므로 업그레이드 과정에서 수신 게이트웨이의 외부/내부 IP 주소는 변경되지 않습니다.

따라서 카나리아 업그레이드 중에 클러스터에 두 개의 수정 버전이 동시에 있는 경우 두 수정 버전의 수신 게이트웨이 Pod는 들어오는 트래픽을 제공합니다.

가로 Pod 자동 크기 조정 사용자 지정을 사용하는 보조 수정 버전 업그레이드

Istiod 또는 수신 게이트웨이에 대한 HPA(가로 Pod 자동 크기 조정) 설정을 사용자 지정한 경우 카나리아 업그레이드 중에 일관성을 유지하기 위해 두 수정 버전에서 HPA 설정을 적용하는 방법에 대해 다음 동작을 확인합니다.

  • 업그레이드를 시작하기 전에 HPA 사양을 업데이트하면 새 컨트롤 플레인을 설치할 때 기존(안정적인) 수정 버전의 설정이 카나리아 수정 버전의 HPA에 적용됩니다.
  • 카나리아 업그레이드가 진행 중인 동안 HPA 사양을 업데이트하면 안정적인 수정 버전의 HPA 사양이 우선 적용되고 카나리아 수정 버전의 HPA에 적용됩니다.
    • 업그레이드 중에 안정적인 수정 버전의 HPA를 업데이트하면 카나리아 수정 버전의 HPA 사양이 안정적인 수정 버전에 적용된 새 설정을 반영하도록 업데이트됩니다.
    • 업그레이드 중에 카나리아 수정 버전의 HPA를 업데이트하면 카나리아 수정 버전의 HPA 사양이 안정적인 수정 버전의 HPA 사양으로 되돌아갑니다.

패치 버전 업그레이드

  • Istio 추가 기능 패치 버전 가용성 정보는 AKS 릴리스 정보에 게시되어 있습니다.
  • 이러한 AKS 릴리스의 일부로 istiod 및 수신 Pod의 패치가 자동으로 롤아웃됩니다. 이러한 패치는 클러스터에 대해 설정된 default 계획된 유지 관리 기간을 적용합니다.
  • 사용자는 재주입을 위해 Pod를 다시 시작하여 워크로드에서 Istio 프록시에 대한 패치를 시작해야 합니다.

    • 새 Pod 또는 다시 시작한 Pod의 Istio 프록시 버전을 확인합니다. 이 버전은 패치된 후 istiod 및 Istio 수신 Pod의 버전과 동일합니다.

      kubectl get cm -n aks-istio-system -o yaml | grep "mcr.microsoft.com\/oss\/istio\/proxyv2"

      예제 출력:

      "image": "mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless",
"image": "mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless"

    • 네임스페이스에 있는 모든 Pod의 Istio 프록시 이미지 버전을 확인합니다.

      kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
sort |\
grep "mcr.microsoft.com\/oss\/istio\/proxyv2"

      예제 출력:

      productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.22.0, mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless

    • 재주입을 트리거하려면 워크로드를 다시 시작합니다. 예시:

      kubectl rollout restart deployments/productpage-v1 -n default

    • 이제 최신 버전인지 확인하려면 네임스페이스의 모든 Pod에 대해 Istio 프록시 이미지 버전을 다시 검사합니다.

      kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
sort |\
grep "mcr.microsoft.com\/oss\/istio\/proxyv2"

      예제 출력:

      productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.2.0, mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless

참고 항목

업그레이드 중에 문제가 발생하는 경우 메시 수정 버전 업그레이드 문제 해결에 대한 문서를 참조하세요.