Compartilhar via

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

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.

As atualizações disponíveis dependem se a revisão atual do Istio e a versão do cluster AKS são suportadas:

  • Você pode atualizar para a próxima revisão suportada (n+1) ou pular uma e atualizar para n+2, desde que ambas sejam suportadas e compatíveis com a versão do cluster.
  • Se tanto a sua revisão atual (n) quanto a próxima revisão (n+1) não forem suportadas, você só poderá atualizar para a revisão suportada mais próxima (n+2 ou superior), mas não além dela.
  • Se a versão do cluster e a revisão do Istio não forem suportadas, a versão do cluster deverá ser atualizada antes que uma atualização do Istio possa ser iniciada.

Observação

Depois que uma versão do AKS ou uma revisão de malha ficar fora da janela de suporte, a atualização de qualquer versão se tornará propensa a erros. Embora essas atualizações possam ser recuperadas em uma versão com suporte, o processo de atualização e as próprias versões sem suporte não são compatíveis com a Microsoft. Recomendamos enfaticamente manter a versão do AKS e a revisão da malha atualizadas para evitar cenários não suportados. Consulte o calendário de suporte do complemento Istio para datas estimadas de lançamento e fim de vida útil e as notas de versão do Istio upstream para a nova revisão para alterações notáveis.

O exemplo a seguir explica como fazer upgrade da revisão asm-1-23 para a asm-1-24 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-systemantes 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-23 para a asm-1-24 usando az aks mesh upgrade start:

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

    Uma atualização canária significa que o painel de controle 1.24 está implantado junto ao painel de controle 1.23. Eles continuarão coexistindo até que você conclua ou reverta a atualização.

    Enquanto uma atualização canary estiver em andamento, a revisão mais recente será considerada a revisão padrão usada para validação dos recursos do Istio.

  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. Instale 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-23 --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-24 --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-23
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 uma nova aplicação for criada em um namespace após ter sido rotulada, um sidecar correspondente à tag de revisão desse namespace será injetado.

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

    1. Verificar pods istiod:

      kubectl get pods -n aks-istio-system

      Exemplo de saída:

      NAME                                        READY   STATUS    RESTARTS   AGE
istiod-asm-1-23-55fccf84c8-dbzlt            1/1     Running   0          58m
istiod-asm-1-23-55fccf84c8-fg8zh            1/1     Running   0          58m
istiod-asm-1-24-f85f46bf5-7rwg4             1/1     Running   0          51m
istiod-asm-1-24-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-23-58f889f99d-qkvq2   1/1     Running   0          59m
aks-istio-ingressgateway-external-asm-1-23-58f889f99d-vhtd5   1/1     Running   0          58m
aks-istio-ingressgateway-external-asm-1-24-7466f77bb9-ft9c8   1/1     Running   0          51m
aks-istio-ingressgateway-external-asm-1-24-7466f77bb9-wcb6s   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-23-579c5d8d4b-4cc2l   1/1     Running   0          58m
aks-istio-ingressgateway-internal-asm-1-23-579c5d8d4b-jjc7m   1/1     Running   0          59m
aks-istio-ingressgateway-internal-asm-1-24-757d9b5545-g89s4   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-24-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-24 --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-24   default
prod-stable   asm-1-24   ...

      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-24 --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. Conclua a atualização do canário: Se você estiver satisfeito com o funcionamento de todas as cargas de trabalho, conforme o esperado, poderá concluir a atualização canary. 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 atualização canário: Caso observe algum problema com a integridade de suas cargas de trabalho, você pode reverter para a versão anterior do Istio:

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

      istioctl tag set prod-stable --revision asm-1-23 --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-23 --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.

Atualizações de revisão menores com gateways de entrada e saída

Se você estiver usando gateways de entrada ou gateways de saída do Istio e estiver realizando uma atualização de revisão menor, lembrem-se de que os pods/implantações do gateways de entrada e saída do Istio são implantados por revisão, mas o serviço é compartilhado entre as duas revisões.

Oferecemos um serviço LoadBalancer único para todos os pods do gateway de entrada em várias revisões, de modo que o endereço IP externo/interno dos gateways de entrada permaneça inalterado durante todo o processo de atualização. Assim, durante a atualização canary, quando duas revisões existem simultaneamente no cluster, os pods do gateway de entrada de ambas as revisões atendem o tráfego de entrada.

Da mesma forma, durante uma atualização do canary, todos os pods de um gateway de saída em ambas as revisões serão atendidos por um serviço ClusterIP único.

Pequenas atualizações de revisão com personalizações de dimensionamento automático de pods horizontais

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

  • Se você atualizar a especificação HPA antes de iniciar uma atualização, as configurações da revisão existente (estável) serão aplicadas aos HPAs da revisão canary quando o novo plano de controle for instalado.
  • Se você atualizar a especificação HPA enquanto uma atualização canary estiver em andamento, a especificação HPA da revisão estável terá precedência e será aplicada à HPA da revisão canary.
    • Se você atualizar o HPA da revisão estável durante uma atualização, a especificação do HPA da revisão canary 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 defaultjanela 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"

      Exemplo de saída:

      "image": "mcr.microsoft.com/oss/istio/proxyv2:1.23.0-distroless",
"image": "mcr.microsoft.com/oss/istio/proxyv2:1.23.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.23.0, mcr.microsoft.com/oss/istio/proxyv2:1.23.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"

      Exemplo de saída:

      productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.2.0, mcr.microsoft.com/oss/istio/proxyv2:1.24.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

  • Last updated on