Compartilhar via

Atualizar o complemento de malha de serviço baseado no Istio para o Serviço de Kubernetes do Azure

  • Artigo

Este artigo aborda as experiências de atualização para o complemento de malha de serviço baseado em Istio para o AKS (Serviço de Kubernetes do Azure).

Anúncios sobre as versões de novas revisões secundárias ou patches para o complemento de malha de serviço baseado em Istio são publicados nas notas de versão do AKS. Para saber mais sobre o cronograma de lançamento e o suporte para revisões de complementos da malha de serviço, leia a política de suporte.

Atualização de revisão secundária

O complemento do Istio permite atualizar a revisão secundária usando o processo de atualização canário. Quando uma atualização é iniciada, o painel de controle da nova revisão (canário) é implantado junto com o painel de controle da revisão inicial (estável). Em seguida, é possível distribuir manualmente cargas de trabalho do plano de dados ao usar ferramentas de monitoramento para acompanhar a integridade das cargas de trabalho durante esse processo. Se você não tiver problemas com a integridade das cargas de trabalho, será possível concluir a atualização para que apenas a nova revisão permaneça no cluster. Caso contrário, você pode reverter para a revisão anterior do Istio.

Se o cluster estiver usando uma versão secundária com suporte do Istio, as atualizações só terão permissão para uma versão secundária por vez. Se o cluster estiver usando uma versão sem suporte do Istio, será possível atualizar para a revisão secundária inferior com suporte do Istio para essa revisão do Kubernetes. Depois disso, as atualizações poderão ser feitas novamente em uma revisão secundária de cada vez.

O exemplo a seguir explica como fazer upgrade da revisão asm-1-22 para a asm-1-23 com todas as cargas de trabalho no namespace default. As etapas são iguais para todos os upgrades secundários e podem ser seguidas com qualquer número de namespaces.

  1. Use o comando az aks mesh get-upgrades para verificar quais revisões estão disponíveis para o cluster como destinos de atualização:

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

    Se você espera ver uma revisão mais recente não retornada por esse comando, é aconselhável atualizar o cluster do AKS primeiro para que ele seja compatível com a revisão mais recente.

  2. Caso tenha configurado a configuração de malha para a revisão de malha existente no seu cluster, precisará criar um ConfigMap separado correspondente à nova revisão no namespace aks-istio-system antes de iniciar a atualização do canário, na próxima etapa. Essa configuração é aplicável no momento em que o plano de controle da nova revisão é implantado no cluster. Encontre mais detalhes aqui.

  3. Inicie uma atualização canária da revisão asm-1-22 para a asm-1-23 usando az aks mesh upgrade start:

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

    Um upgrade canário significa que o plano de controle 1.23 é implantado com o plano de controle 1.22. Eles continuarão coexistindo até que você conclua ou reverta a atualização.

  4. Opcionalmente, é possível usar as tags de revisão para atualizar o plano de dados para a nova revisão sem a necessidade de rotular novamente cada namespace de maneira manual. Rotular novamente namespaces manualmente ao movê-los para uma nova revisão pode ser entediante e levar a erros. As tags de revisão resolvem esse problema porque atuam como identificadores estáveis que apontam para as revisões.

    Em vez de rotular cada namespace novamente, é possível usar um operador de cluster que altera a tag para apontar para uma nova revisão. Todos os namespaces rotulados com essa tag são atualizados ao mesmo tempo. No entanto, ainda é necessário reiniciar as cargas de trabalho para garantir que a versão correta dos sidecars istio-proxy seja injetada.

    Para usar as tags de revisão durante um upgrade:

    1. Instalar a CLI istioctl

    2. Crie uma tag de revisão para a revisão inicial. Neste exemplo, ela é chamada de prod-stable:

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

    3. Crie uma tag de revisão para a revisão instalada durante o upgrade. Neste exemplo, ela é chamada de prod-canary:

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

    4. Rotule os namespaces de aplicativo para fazer o mapeamento para as tags de revisão:

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

      Também é possível rotular os namespaces com istio.io/rev=prod-canary para a revisão mais recente. No entanto, as cargas de trabalho nesses namespaces não são atualizadas para um novo sidecar até que sejam reiniciadas.

      Se um novo aplicativo for criado em um namespace já rotulado, será injetado nesse namespace um sidecar correspondente à tag de revisão.

  5. Verifique se os pods do painel de controle correspondem aos dois e tanto asm-1-22 quanto asm-1-23 existem:

    1. Verificar pods istiod:

      kubectl get pods -n aks-istio-system

      Exemplo de saída:

      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. Se a entrada estiver habilitada, verifique os pods de entrada:

      kubectl get pods -n aks-istio-ingress

      Exemplo de saída:

      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

      Observe que os pods de gateway de entrada de ambas as revisões são implantados lado a lado. No entanto, o serviço e seu IP permanecem imutáveis.

  6. Rotule novamente o namespace para que todos os novos pods sejam mapeados para o sidecar do Istio associado à nova revisão e ao painel de controle associado:

    1. Ao usar tags de revisão, substitua a tag prod-stable em si para alterar o mapeamento dela:

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

      Verifique os mapeamentos entre tags e revisões:

      istioctl tag list

      Ambas as tags devem apontar para a revisão recém-instalada:

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

      Neste caso, não é preciso rotular novamente cada namespace de maneira individual.

    2. Se você não usar tags de revisão, será preciso rotular novamente os namespaces do plano de dados para apontar para a nova revisão:

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

    A nova rotulagem não afeta suas cargas de trabalho até que elas sejam reiniciadas.

  7. Substitua individualmente cada uma das cargas de trabalho do aplicativo reiniciando-as. Por exemplo:

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

  8. Verifique as ferramentas e painéis de monitoramento para determinar se suas cargas de trabalho estão todas em execução em um estado íntegro após a reinicialização. Com base nos resultados, você tem duas opções:

    1. Concluir a atualização canário: se você estiver satisfeito de que todas as cargas de trabalho estão em execução em um estado íntegro conforme o esperado, será possível concluir a atualização canário. A conclusão da atualização remove o painel de controle da revisão anterior e deixa o painel de controle da nova revisão no cluster para trás. Execute o seguinte comando para concluir a atualização canário:

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

    2. Reverter a atualização canário: caso você perceba problemas na integridade de suas cargas de trabalho, será possível reverter para a revisão anterior do Istio:

    • Rotule novamente o namespace para a revisão anterior: Ao usar tags de revisão:

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

      Caso contrário, se você não estiver usando tags de revisão:

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

    • Reverta as cargas de trabalho para usar o sidecar correspondente à revisão anterior do Istio reiniciando essas cargas de trabalho novamente:

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

    • Reverter o painel de controle para a revisão anterior:

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

    A tag de revisão prod-canary pode ser removida:

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

  9. Se a configuração de malha foi configurada anteriormente para as revisões, agora você pode excluir o ConfigMap para a revisão que foi removida do cluster durante a conclusão/reversão.

Pequenas atualizações de revisão com o gateway de entrada

Caso esteja usando o gateways de entrada do Istio e estiver executando uma pequena atualização de revisão, tenha em mente que os pods/implantações de gateway de entrada do Istio são implantados por revisão. No entanto, fornecemos um único serviço LoadBalancer em todos os pods de gateway de entrada por meio de várias revisões. Devido a isso, o endereço IP externo/interno dos gateways de entrada não é alterado ao longo de um upgrade.

Assim, durante a atualização do canário, quando duas revisões existirem simultaneamente no cluster, os pods de gateway de entrada de ambas as revisões atenderão ao tráfego de entrada.

Pequenas atualizações de revisão com personalizações de dimensionamento automático de pod horizontal

Se você tiver personalizado as configurações do HPA (dimensionamento automático de pod horizontal) para o Istiod ou os gateways de entrada, observe o seguinte comportamento sobre como as configurações do HPA são aplicadas em ambas as revisões para manter a consistência durante uma atualização do canário:

  • Se você atualizar a especificação do HPA antes de iniciar uma atualização, as configurações da revisão existente (estável) serão aplicadas aos HPAs da revisão do canário quando o novo painel de controle for instalado.
  • Se você atualizar a especificação do HPA enquanto uma atualização do canário estiver em andamento, a especificação do HPA da revisão estável terá precedência e será aplicada ao HPA da revisão do canário.
    • Se você atualizar o HPA da revisão estável durante uma atualização, a especificação do HPA da revisão do canário será atualizada para refletir as novas configurações aplicadas à revisão estável.
    • Se você atualizar o HPA da revisão do canário durante uma atualização, a especificação do HPA da revisão do canário será revertida para a especificação do HPA da revisão estável.

Atualização de versão do patch

  • As informações de disponibilidade da versão do patch de complemento Istio são publicadas nas notas de versão do AKS.
  • Os patches são distribuídos automaticamente para pods istiod e de entrada como parte dessas versões do AKS, que respeitam a default janela de manutenção planejada configurada para o cluster.
  • O usuário precisa iniciar patches para o proxy Istio em suas cargas de trabalho reiniciando os pods para reinjeção:

    • Verifique a versão do proxy Istio destinada a pods novos ou reiniciados. Essa versão é a mesma que a versão dos pods de entrada istiod e Istio ingress depois que eles foram corrigidos:

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

      Saída de exemplo:

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

    • Verifique a versão da imagem de proxy do Istio para todos os pods em um namespace:

      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"

      Exemplo de saída:

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

    • Para disparar a reinjeção, reinicie as cargas de trabalho. Por exemplo:

      kubectl rollout restart deployments/productpage-v1 -n default

    • Para verificar se eles estão agora nas versões mais recentes, marque a versão da imagem de proxy do Istio novamente para todos os pods no namespace:

      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"

      Saída de exemplo:

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

Observação

Em caso de problemas encontrados durante as atualizações, consulte o artigo sobre solução de problemas de atualizações de revisão de malha