Atualizar imagens do Kubernetes e do nó em vários clusters membros

Artigo
10/20/2024

Os administradores da plataforma que gerenciam um grande número de clusters frequentemente têm problemas com o preparo das atualizações de vários clusters (por exemplo, atualizar a imagem do SO do nó ou as versões do Kubernetes) de forma segura e previsível. Para resolver esse desafio, o Gerenciador de Frota de Kubernetes do Azure (Frota) permite que você orquestre atualizações em vários clusters usando execuções de atualização.

As execuções de atualização consistem em estágios, grupos e estratégias e podem ser aplicadas manualmente, para atualizações únicas, ou automaticamente, para atualizações regulares em andamento usando perfis de atualização automática. Todas as execuções de atualização (manuais ou automatizadas) respeitam as janelas de manutenção do cluster membro.

Entendendo as execuções de atualização

A imagem a seguir visualiza uma execução de atualização contendo dois estágios de atualização, cada um contendo dois grupos de atualização com dois clusters membros. Um período de espera está configurado entre o primeiro e o segundo estágios.

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 para aplicar a atualização 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ção com estágios e grupos e permite que você reutilize uma configuração de execução de atualização em vez de definir a sequência repetidamente em cada execução. Uma estratégia de atualização não inclui as versões desejadas da imagem do Kubernetes ou do nó.

Atualmente, as operações de atualização com suporte no cluster membro são atualizações. Há três 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ó).
Atualizar versões do Kubernetes apenas para o painel de controle dos clusters.
Fazer upgrade apenas das imagens do nó.

Você pode especificar a versão de destino do Kubernetes para atualizar, mas não pode especificar a versão exata da imagem do nó alvo. Isso ocorre porque a versão mais recente disponível da imagem do nó pode variar dependendo da região do Azure do cluster (verifique o rastreador de versão do AKS 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 do Azure de um cluster quando a atualização do cluster começar. Como resultado, diferentes versões de imagem podem ser usadas dependendo de qual região do Azure um cluster está e quando sua atualização realmente começa.
Consistent: Quando a execução da atualização começa, ela escolhe as versões de imagem mais recentes comuns nas regiões do Azure dos clusters membros nessa execução, de modo que as mesmas versões de imagem consistentes sejam usadas em todos 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:

Membro com uma janela aberta de manutenção contínua.
Membro com uma janela de manutenção que será aberta nas próximas quatro horas.
Membro sem janela de manutenção.
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: A execução de atualização ainda não foi iniciada.
Running: A atualização está em andamento para pelo menos um dos clusters membros na execução de atualização.
Pendente:
- Cluster membro: Um cluster membro pode estar no estado pendente por qualquer um dos seguintes motivos, que podem ser visualizados 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 de destino do Kubernetes ainda não está disponível na região do Azure 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 de destino da imagem do nó ainda não está disponível na região do Azure 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 do grupo estiverem no estado Pending ou não forem 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 forem Pending, o grupo passará para o estado Pending. Se um grupo estiver no estado Pending, a execução de atualização aguardará a conclusão do grupo antes de passar para o próximo estágio para execução.
- Estágio: Um estágio estará no estado Pending se todos os grupos sob esse estágio estiverem no estado Pending ou não forem iniciados.
- Execução: uma execução estará no estado Pending se a fase atual que deveria estar em execução estiver no estado Pending.
Skipped: Todos os níveis de uma execução de atualização podem ser ignorados. Ignorar pode ser iniciado pelo sistema ou pelo usuário.
- Membro:
  - Você ignorou a atualização para um membro, grupo ou estágio.
  - 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 do nó consistente é escolhida para uma execução de atualização, se não for possível encontrar a versão de destino da imagem para um dos pools de nós, a atualização será ignorada para esse cluster. Como exemplo, isso pode ocorrer quando um novo pool de nós com um novo SKU de Máquina Virtual (VM) é adicionado após uma execução de atualização ter começado.
- 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á foi iniciada pela execução de atualização (por exemplo, uma atualização de cluster está em andamento), essa operação não será abortada para esse cluster individual.
- Se uma falha for encontrada durante a execução de atualização (por exemplo, as atualizações falharam em um dos clusters), toda a execução de atualização entrará em um estado parado. As operações não são tentadas para nenhum cluster subsequente na execução de atualização.
Falhou: Uma falha ao atualizar um cluster resulta 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.

Observação

Você pode reexecutar uma execução de atualização a qualquer momento para reaplicar atualizações que podem ter sido ignoradas ou falharam.

Entendendo os perfis de atualização automática (versão prévia)

Os perfis de atualização automática são usados para acionar automaticamente execuções de atualização quando novas versões do Kubernetes ou da imagem do nó são disponibilizadas para o AKS.

Importante

A versão prévia do recurso Gerenciador de Frota de Kubernetes do Azure está disponível com base em autoatendimento e aceitação. As versões prévias são fornecidas “no estado em que se encontram” e “conforme disponíveis” e são excluídas dos contratos de nível de serviço e da garantia limitada. A versão prévia do Gerenciador de Frota de Kubernetes do Azure é parcialmente coberta pelo suporte ao cliente com base no melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção.

Em um perfil de atualização automática, você pode configurar:

um Channel (Estável, Rápido, NodeImage) que determina o tipo de atualização automática que é aplicado aos clusters.
um UpdateStrategy que configura a sequência em que os clusters são atualizados. Se uma estratégia não for fornecida, os clusters serão atualizados um por um, sequencialmente.
o NodeImageSelectionType (Mais Recente, Consistente) para especificar como a imagem do nó é selecionada ao atualizar a versão do Kubernetes.

Canal estável

O canal Estável é sempre a versão de patch do Kubernetes mais recente com suporte pelo AKS na versão secundária N-1, em que N é a versão secundária mais recente com suporte.

Exemplos:

A versão secundária mais recente do Kubernetes com suporte é 1.30. Quaisquer versões de patch no intervalo secundário 1.29 seriam consideradas para atualizações do canal Estável.
Uma nova versão secundária do Kubernetes de 1.31 foi publicada. Qualquer versão do patch intervalo secundário 1.30seria considerado para atualizações do canal Estável. Qualquer cluster anteriormente recebendo atualizações de 1.29 seria atualizado para o patch mais recente para 1.30.

Canal Rápido

O canal Rápido é sempre a versão secundária mais recente do Kubernetes com suporte do AKS.

Exemplos:

A versão secundária mais recente com suporte é 1.30. Qualquer versão de patch do intervalo secundário 1.30 seria considerado para atualizações do canal Rápido.
Uma nova versão secundária do Kubernetes de 1.31 foi publicada. 1.30 muda para o canal Estável. Qualquer cluster anteriormente recebendo atualizações de 1.30 seria atualizado para o patch mais recente para 1.31 que agora é o canal Rápido.

Canal NodeImage

Os nós do cluster membro são atualizados com um VHD recém corrigido contendo correções de segurança e correções de bug em uma cadência semanal. A atualização para o novo VHD é disruptiva, seguindo as janelas de manutenção e as configurações de aumento. Nenhum custo extra de VHD é incorrido ao escolher essa opção.

Se você usar esse canal, as atualizações autônomas do Linux serão desabilitadas por padrão. As atualizações de imagem do nó são compatíveis com as versões de patch que foram preteridas, contanto que ainda haja suporte para a versão secundária do Kubernetes. As imagens de nó são testadas pelo AKS, totalmente gerenciado e aplicadas com práticas de implantação seguras.

Os nós em diferentes sistemas operacionais serão atualizados de acordo com as versões da imagem do nó alinhadas a esses sistemas operacionais.

Exemplo:

Um cluster tem nós com uma NodeImage de AKSWindows-2022-containerd da versão 20348.2582.240716. Uma nova versão da NodeImage 20348.2582.240916 foi liberada e os nós do cluster serão automaticamente atualizados para a versão 20348.2582.240916.

Comportamento de ignorar a versão secundária

A atualização automática não move clusters entre versões secundárias do Kubernetes quando há mais de uma diferença de versão secundária do Kubernetes (por exemplo: 1.28 para 1.30). Quando os administradores tiverem um conjunto diversificado de versões do Kubernetes é recomendado primeiro usar uma ou mais execução de atualização para trazer os clusters membros para um conjunto de versões com versões consistentes para que Stable ou Rapid atualizações do canal configuradas garantam que a consistência seja mantida no futuro.