Atualizar o complemento de malha de serviço baseado em Istio para o Serviço 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 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.

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 antiga (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 de revisão asm-1-18 para asm-1-19. As etapas são as mesmas para todas as pequenas atualizações.

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ê configurou 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-18 para o uso do az aks mesh upgrade startasm-1-19:

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

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

4. Verifique se os pods do plano de controle correspondem a ambos asm-1-18 e asm-1-19 existem:

   • Verificar istiod pods:

     kubectl get pods -n aks-istio-system
     

     Saída de exemplo:

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

   • 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-18-58f889f99d-qkvq2   1/1     Running   0          59m
     aks-istio-ingressgateway-external-asm-1-18-58f889f99d-vhtd5   1/1     Running   0          58m
     aks-istio-ingressgateway-external-asm-1-19-7466f77bb9-ft9c8   1/1     Running   0          51m
     aks-istio-ingressgateway-external-asm-1-19-7466f77bb9-wcb6s   1/1     Running   0          51m
     aks-istio-ingressgateway-internal-asm-1-18-579c5d8d4b-4cc2l   1/1     Running   0          58m
     aks-istio-ingressgateway-internal-asm-1-18-579c5d8d4b-jjc7m   1/1     Running   0          59m
     aks-istio-ingressgateway-internal-asm-1-19-757d9b5545-g89s4   1/1     Running   0          51m
     aks-istio-ingressgateway-internal-asm-1-19-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.

5. Rerotule o namespace para que quaisquer novos pods tenham o sidecar Istio associado à nova revisão e seu plano de controle:

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

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

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

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

   • 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
     

   • 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:

       kubectl label namespace default istio.io/rev=asm-1-18 --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
       

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

Nota

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. As tags de revisão são identificadores estáveis que apontam para revisões e podem ser usadas para evitar a remarcação de namespaces. Em vez de rotular novamente o namespace, um operador de malha pode simplesmente alterar a tag para apontar para uma nova revisão. Todos os namespaces rotulados com essa tag serão atualizados ao mesmo tempo. No entanto, observe que você ainda precisa reiniciar as cargas de trabalho para garantir que a versão correta dos istio-proxy sidecars seja injetada.

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 não seja alterado ao longo de uma atualização.

Assim, durante a atualização canária, quando duas revisões existirem simultaneamente no cluster, o tráfego de entrada será servido pelos pods de gateway de entrada de ambas as revisões.

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 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. 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.18.2-distroless",
    "image": "mcr.microsoft.com/oss/istio/proxyv2:1.18.2-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.18.0, mcr.microsoft.com/oss/istio/proxyv2:1.18.1-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.18.0, mcr.microsoft.com/oss/istio/proxyv2:1.18.2-distroless