Atualizar a orquestração em vários clusters de membros

Os administradores de plataforma que gerenciam um grande número de clusters geralmente têm problemas no preparo das atualizações de vários clusters (por exemplo, atualizar versões de imagem do sistema operacional do nó, atualizar versões do Kubernetes) de maneira segura e previsível. Para resolver esse problema, o Gerenciador de Frota de Kubernetes do Azure (Frota) permite orquestrar atualizações em vários clusters usando execuções, fases, grupos e estratégias de atualização.

• Execução de atualização: uma execução de atualização representa uma atualização que está sendo aplicada a uma coleção de clusters do AKS, consistindo na meta e na sequência de atualização. A meta de atualização descreve as atualizações desejadas (por exemplo, atualização para o Kubernetes versão 1.28.3). A sequência de atualização descreve a ordem exata na qual aplicar as atualizações a vários clusters membros, expressos usando estágios e grupos. Se não for especificada, todos os clusters membros serão atualizados um por um sequencialmente. Uma execução de atualização pode ser interrompida e iniciada.
• Estágio de atualização: as execuções de atualização são divididas em estágios, que são aplicados sequencialmente. Por exemplo, um primeiro estágio de atualização pode atualizar os clusters membros do ambiente de teste e um segundo estágio de atualização atualizará posteriormente os clusters membros do ambiente de produção. Um tempo de espera pode ser especificado para aguardar entre a aplicação dos estágios de atualização subsequentes.
• Grupos de atualizações: cada estágio de atualização contém um ou mais grupos de atualização, que são usados para selecionar os clusters membros a serem atualizados. Os grupos de atualização também são usados para ordenar a aplicação de atualizações para clusters membros. Em um estágio de atualização, as atualizações são aplicadas a todos os diferentes grupos de atualização em paralelo. Em um grupo de atualização, os clusters membros são atualizados sequencialmente. Cada cluster membro da frota só pode fazer parte de um grupo de atualizações.
• Estratégia de atualização: uma estratégia de atualização descreve a sequência de atualizações com estágios e grupos. Você pode reutilizar uma estratégia em suas execuções de atualização em vez de definir a sequência repetidamente em cada execução.

Atualmente, as operações de atualização com suporte no cluster são upgrades. Há dois tipos de upgrades que você pode escolher:

• Fazer upgrade das versões do Kubernetes para o painel de controle e os nós do Kubernetes (que inclui o upgrade das imagens do nó).
• Fazer upgrade apenas das imagens do nó.

Você pode especificar a versão do Kubernetes de destino para a qual fazer upgrade, mas não pode especificar as versões exatas da imagem do nó de destino, pois as versões de imagem de nó disponíveis mais recentes podem variar dependendo da região do cluster (verifique o rastreador de versão para obter mais informações). As versões de imagem do nó de destino são selecionadas automaticamente para você com base em suas preferências:

• Latest: use as imagens de nó mais recentes disponíveis na região de um cluster quando o upgrade do cluster for iniciado. Como resultado, diferentes versões de imagem podem ser usadas dependendo da região em que um cluster está e quando seu upgrade realmente é iniciado.
• Consistent: quando a execução de atualização é iniciada, ela escolhe as versões de imagem comuns mais recentes entre as regiões dos clusters membros nesta execução, de modo que as mesmas versões de imagem consistentes sejam usadas entre os clusters.

Você deve optar por Latest para usar as versões de imagem mais recentes e minimizar os riscos de segurança e optar por Consistent para melhorar a confiabilidade usando e verificando essas imagens em clusters em estágios anteriores antes de usá-las em clusters posteriores.

Manutenção planejada

As execuções da atualização respeitam as janelas de manutenção planejada que você definiu no nível de cluster do Serviço de Kubernetes do Azure (AKS).

Em uma execução de atualização (tanto para execuções de atualização do tipo Uma por uma quanto em Fases), a execução da atualização prioriza o upgrade dos clusters na seguinte ordem:

1. Membro com uma janela aberta de manutenção contínua.
2. Membro com uma janela de manutenção que será aberta nas próximas quatro horas.
3. Membro sem janela de manutenção.
4. Membro com uma janela de manutenção fechada.

Estados da execução de atualização

Uma execução de atualização pode estar em um dos seguintes estados:

• NotStarted: estado da execução da atualização antes de ser iniciada.

• Running: a atualização está em andamento para pelo menos um dos clusters na execução da atualização.

• Pendente:

  • Cluster membro: um cluster membro pode estar no estado pendente por qualquer um dos seguintes motivos a serem expostos no campo de mensagem.
    • A janela de manutenção não está aberta. A mensagem indica o horário da próxima abertura.
    • A versão do Kubernetes de destino ainda não está disponível na região do membro. A mensagem tem um link para o rastreador de versões para que você possa verificar o status da versão nas diversas regiões.
    • A versão da imagem do nó de destino ainda não está disponível na região do membro. A mensagem tem um link para o rastreador de versões para que você possa verificar o status da versão nas diversas regiões.
  • Grupo: um grupo estará no estado Pending se todos os membros dos grupos estiverem no estado Pending ou não tiverem sido iniciados. Quando um membro passar para Pending, a execução da atualização tentará fazer o upgrade do próximo membro no grupo. Se todos os membros estiverem no status Pending, o grupo passará para o estado Pending. Todos os grupos precisam estar em estado terminal antes de passarem para a próxima fase. Ou seja, se um grupo estiver no estado Pending, a execução da atualização aguardará a conclusão do processo antes de passar para a próxima fase para execução.
  • Fase: uma fase estará Pending se todos os grupos que estão nessa fase estiverem em estado Pending ou não tiverem sido iniciados.
  • Execução: uma execução estará no estado Pending se a fase atual que deveria estar em execução estiver no estado Pending.

• Ignorada: todos os níveis de uma execução de atualização podem ser ignorados e isso pode ser detectado pelo sistema ou iniciado pelo usuário.

  • Membro:
    • Você ignorou o upgrade para um membro ou um de seus pais.
    • O cluster membro já está na versão do Kubernetes de destino (se o modo de execução de atualização for Full ou ControlPlaneOnly).
    • O cluster membro já está na versão do Kubernetes de destino e todos os pools de nós estão na versão de imagem do nó de destino.
    • Quando a imagem de nó consistente é escolhida para uma execução de upgrade, se não for possível localizar a versão da imagem de destino para um dos pools de nós o upgrade será ignorado para esse cluster. Um exemplo dessa situação ocorre quando um novo pool de nós com um novo SKU de VM é adicionado após uma execução de atualização ter sido iniciada.
  • Grupo:
    • Todos os clusters membros foram detectados como Skipped pelo sistema.
    • Você iniciou uma ação de ignorar no nível do grupo.
  • Fase:
    • Todos os grupos na fase foram detectados como Skipped pelo sistema.
    • Você iniciou uma ação de ignorar no nível da fase.
  • Execução:
    • Todas as fases foram detectadas como Skipped pelo sistema.

• Interrompida: todos os níveis de uma execução de atualização podem ser interrompidos. Existem duas possibilidades para entrar em um estado interrompido:

  • Você interrompe a execução da atualização, momento em que a execução da atualização para de acompanhar todas as operações. Se uma operação já tiver sido iniciada pela execução de atualização (por exemplo, um upgrade de cluster está em andamento), essa operação não será anulada para esse cluster individual.
  • Se uma falha for encontrada durante a execução da atualização (por exemplo, os upgrades falharam em um dos clusters), toda a execução de atualização entra em um estado interrompido e não haverá tentativas de operação para nenhum cluster subsequente na execução da atualização.

• Falha: uma falha ao fazer o upgrade de um cluster resultará nas seguintes ações:

  • Marca o MemberUpdateStatus como Failed no cluster membro.
  • Marca todos os pais (grupo — > fase — > execução) como Failed com uma mensagem de erro resumida.
  • Impede que a execução da atualização prossiga.

Próximas etapas

• Orquestrar atualizações em vários clusters membros.