Partilhar via

Atualizar o complemento de malha de serviço baseado em Istio para o Serviço 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 Serviço Kubernetes do Azure (AKS).

Os anúncios sobre os lançamentos de novas pequenas revisões 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 de malha de serviço, leia a política de suporte.

Pequena atualização de revisão

Istio add-on permite atualizar a revisão menor usando o processo de atualização canary. Quando uma atualização é iniciada, o plano de controle da nova revisão (canário) é implantado ao lado do plano de controle da revisão inicial (estável). Em seguida, você pode rolar manualmente as cargas de trabalho do plano de dados enquanto usa ferramentas de monitoramento para controlar a integridade das cargas de trabalho durante esse processo. Se você não observar nenhum problema com a integridade de suas cargas de trabalho, poderá 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 atualmente uma revisão secundária suportada do Istio, as atualizações só serão permitidas uma revisão menor de cada vez. Se o cluster estiver usando uma revisão sem suporte do Istio, você deverá atualizar para a menor revisão secundária suportada do Istio para essa versão do Kubernetes. Depois disso, as atualizações podem ser feitas novamente uma pequena revisão de cada vez.

O exemplo a seguir ilustra como atualizar da revisão asm-1-22 para com asm-1-23 todas as cargas de trabalho no default namespace. As etapas são as mesmas para todas as atualizações menores e podem ser usadas para 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 este comando, talvez seja necessário atualizar seu cluster AKS primeiro para que ele seja compatível com a revisão mais recente.

  2. Se você configurar a configuração de malha para a revisão de malha existente em seu cluster, precisará criar um ConfigMap separado correspondente à nova revisão no aks-istio-system namespace antes de iniciar a atualização canária na próxima etapa. Essa configuração é aplicável no momento em que o plano de controle da nova revisão é implantado no cluster. Estão disponíveis mais detalhes aqui.

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

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

    Uma atualização canária significa que o plano de controle 1.23 é implantado ao lado do plano de controle 1.22. Eles continuam a coexistir até que você conclua ou reverta a atualização.

  4. Opcionalmente, as tags de revisão podem ser usadas para rolar o plano de dados para a nova revisão sem a necessidade de rerotular manualmente cada namespace. Rerotular manualmente namespaces ao movê-los para uma nova revisão pode ser tedioso e propenso a erros. As tags de revisão resolvem esse problema servindo como identificadores estáveis que apontam para revisões.

    Em vez de rerotular cada namespace, um operador de cluster pode alterar a marca para apontar para uma nova revisão. Todos os namespaces rotulados com essa tag são atualizados ao mesmo tempo. No entanto, você ainda precisa reiniciar as cargas de trabalho para garantir que a versão correta dos istio-proxy sidecars seja injetada.

    Para usar tags de revisão durante uma atualização:

    1. Instalar istioctl CLI

    2. Crie uma tag de revisão para a revisão inicial. Neste exemplo, nós o prod-stablenomeamos :

      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 a atualização. Neste exemplo, nós o prod-canarynomeamos :

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

    4. Rotule namespaces de aplicativo para mapear para tags de revisão:

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

      Você também pode rotular 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 depois de ser rotulado, um sidecar será injetado correspondente à tag de revisão nesse namespace.

  5. Verifique se os pods do plano de controle correspondem a ambos asm-1-22 e asm-1-23 existem:

    1. Verificar istiod pods:

      kubectl get pods -n aks-istio-system

      Saída de exemplo:

      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 ativada, verifique os pods de entrada:

      kubectl get pods -n aks-istio-ingress

      Saída de exemplo:

      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. Rerotule o namespace para que quaisquer novos pods sejam mapeados para o sidecar Istio associado à nova revisão e seu plano de controle:

    1. Se estiver usando tags de revisão, substitua a prod-stable própria tag para alterar seu mapeamento:

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

      Verifique os mapeamentos de tag para revisão:

      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   ...

      Nesse caso, você não precisa rotular novamente cada namespace individualmente.

    2. Se não estiver usando marcas de revisão, os namespaces do plano de dados deverão ser rotulados novamente para apontar para a nova revisão:

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

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

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

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

  8. Verifique suas 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 no resultado, você tem duas opções:

    1. Conclua a atualização canária: Se você estiver satisfeito que as cargas de trabalho estão todas em execução em um estado íntegro, conforme o esperado, você pode concluir a atualização canary. A conclusão da atualização remove o plano de controle da revisão anterior e deixa para trás o plano de controle da nova revisão no cluster. Execute o seguinte comando para concluir a atualização canary:

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

    2. Reverter a atualização canária: Caso você observe algum problema com a integridade de suas cargas de trabalho, você pode reverter para a revisão anterior do Istio:

    • Rerotule o namespace para a revisão anterior: Se estiver usando tags de revisão:

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

      Ou, se 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>

    • Reverta o plano de controle para a revisão anterior:

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

    A prod-canary tag de revisão 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

Se você estiver usando gateways de entrada do Istio e estiver executando uma pequena atualização de revisão, lembre-se de que os pods/implantações do 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 em várias revisões, para que o endereço IP externo/interno dos gateways de entrada permaneça inalterado durante o curso de uma atualização.

Assim, durante a atualização canária, quando duas revisões existem simultaneamente no cluster, os pods de gateway de entrada de ambas as revisões servem o 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 de HPA (horizontal pod autoscaling) para o Istiod ou os gateways de entrada, observe o seguinte comportamento sobre como as configurações de HPA são aplicadas em ambas as revisões para manter a consistência durante uma atualização canária:

  • 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 canária quando o novo plano de controle for instalado.
  • Se você atualizar a especificação HPA enquanto uma atualização canária estiver em andamento, a especificação HPA da revisão estável terá precedência e será aplicada à HPA da revisão canária.
    • Se você atualizar o HPA da revisão estável durante uma atualização, a especificação HPA da revisão canária será atualizada para refletir as novas configurações aplicadas à revisão estável.
    • Se você atualizar o HPA da revisão canary durante uma atualização, a especificação HPA da revisão canary será revertida para a especificação HPA da revisão estável.

Atualização da versão do patch

  • As informações de disponibilidade da versão do patch complementar Istio são publicadas nas notas de versão do AKS.
  • Os patches são implementados automaticamente para istiod e pods 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. Esta versão é a mesma que a versão dos pods de ingresso istiod e Istio 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"

      Saída de exemplo:

      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 acionar 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, verifique 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

Nota

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