Partilhar via

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. Para saber mais sobre o cronograma de lançamento e o suporte para revisões dos complementos da malha de serviço, leia a política de suporte.

Pequena melhoria de revisão

Istio add-on permite atualizar a versão secundária usando o processo de atualização canário. 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, pode-se transferir manualmente as cargas de trabalho do plano de dados, utilizando ferramentas de monitorização para acompanhar 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.

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 com suporte (n+1) ou ignorar uma e atualizar para n+2, desde que ambas sejam suportadas e compatíveis com a versão do cluster.
  • Se a revisão atual (n) e a próxima revisão (n+1) não forem suportadas, você só poderá atualizar para a revisãon+2 suportada ( ou superior) mais próxima, 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.

Nota

Quando uma versão do AKS ou revisão de malha fica fora da janela de suporte, a atualização de qualquer versão torna-se propensa a erros. Embora essas atualizações tenham permissão para recuperar para uma versão suportada, o processo de atualização e as próprias versões fora de suporte não são suportadas pela Microsoft. É altamente recomendável manter a versão do AKS e a revisão de malha atualizadas para evitar encontrar cenários não suportados. Consulte o calendário de suporte do add-on Istio para obter as datas estimadas de lançamento e fim de vida útil, e as notas de lançamento upstream do Istio para a nova revisão com alterações notáveis.

O exemplo a seguir ilustra como atualizar da revisão asm-1-23 para asm-1-24 todas as cargas de trabalho no namespace default. 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 configurar configuração de malha para a revisão de malha existente no seu cluster, precisará criar um ConfigMap separado correspondente à nova revisão no aks-istio-system namespace antes de iniciar a canary upgrade 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-23 para 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 do tipo canário significa que o plano de controlo 1.24 é implantado em paralelo com o plano de controlo 1.23. Eles continuam a coexistir até que você conclua ou reverta a atualização.

    Enquanto uma atualização canária está em andamento, a revisão superior é considerada a revisão padrão usada para validação de recursos do Istio.

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

    Em vez de reatribuir rótulos a cada namespace, um operador de cluster pode alterar a etiqueta 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 a linha de comando istioctl

    2. Crie uma tag de revisão para a revisão inicial. Neste exemplo, atribuímos-lhe o nome 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 a atualização. Neste exemplo, atribuímos-lhe o nome prod-canary:

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

    4. Rotule os namespaces da aplicação para mapear para tags de revisão.

      # label default namespace to map to asm-1-23
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 uma nova aplicação for criada num namespace depois de este ser rotulado, um sidecar será injetado correspondente à tag de revisão nesse namespace.

  5. Verifique se existem pods do plano de controle correspondentes a asm-1-23 e asm-1-24.

    1. Verificar os istiod pods:

      kubectl get pods -n aks-istio-system

      Saída de exemplo:

      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 o ingress estiver ativado, verifique os ingress pods:

      kubectl get pods -n aks-istio-ingress

      Saída de exemplo:

      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. 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 a usar tags de revisão, substitua a tag prod-stable para alterar o seu mapeamento:

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

      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-24 --overwrite

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

  7. Reinicie individualmente cada uma das cargas de trabalho da aplicação. 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 estiver satisfeito de que as cargas de trabalho estão todas em execução num estado íntegro, conforme o esperado, pode completar a atualização canária. 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 completar a atualização do canário:

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

    2. Reverter a atualização canário: Caso o utilizador observe algum problema com a integridade das suas cargas de trabalho, 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-23 --istioNamespace aks-istio-system --overwrite

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

    • 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 gateways de entrada e saída

Se estiver a utilizar gateways de entrada ou gateways de saída do Istio e a realizar uma pequena atualização de revisão, lembre-se de que os pods/implementações de gateway de entrada e saída do Istio são implementados por revisão, mas o serviço é partilhado entre as revisões.

Fornecemos um único serviço LoadBalancer que abrange todos os pods de gateway de entrada, abrangendo várias revisões, garantindo que o endereço IP externo/interno dos gateways de entrada permaneça inalterado durante toda uma atualização. Assim, durante a atualização do tipo canário, quando duas revisões existem simultaneamente no cluster, os pods do gateway de entrada de ambas as revisões servem o tráfego que chega.

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

Pequenas atualizações de revisão com personalizações para o escalonamento horizontal automático de pods

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 defaultjanela de manutenção planejada configurada para o cluster.
  • O utilizador precisa aplicar patches ao proxy Istio nas suas cargas de trabalho, reiniciando os pods para permitir a reinjeção.

    • Verifique a versão do proxy Istio para pods novos ou reiniciados. Esta versão é a mesma que a versão dos pods de ingresso istiod e Istio após terem sido 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.23.0-distroless",
"image": "mcr.microsoft.com/oss/istio/proxyv2:1.23.0-distroless"

    • Verifique a versão da imagem do proxy Istio para todos os pods num 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.23.0, mcr.microsoft.com/oss/istio/proxyv2:1.23.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.24.0-distroless

Nota

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