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

Os administradores de plataforma que gerenciam um grande número de clusters geralmente têm problemas com o preparo das atualizações de vários clusters (por exemplo, atualizando a imagem do sistema operacional do nó ou as versões do Kubernetes) de forma segura e previsível. Para enfrentar esse desafio, o Azure Kubernetes Fleet Manager (Fleet) permite orquestrar 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 contínuas usando perfis de atualização automática. Todas as atualizações são executadas (manuais ou automatizadas) pelas janelas de manutenção do cluster de membros de honra.

Noções básicas sobre 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 é 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 AKS, consistindo na meta e sequência de atualização. A meta de atualização descreve as atualizações desejadas (por exemplo, atualizar 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 de membros, expressa usando estágios e grupos. Se não for especificado, todos os clusters membros serão atualizados um a um sequencialmente. Uma execução de atualização pode ser interrompida e iniciada.
• Etapa de atualização: as execuções de atualização são divididas em etapas, que são aplicadas sequencialmente. Por exemplo, um primeiro estágio de atualização pode atualizar clusters de membros do ambiente de teste e um segundo estágio de atualização atualizaria posteriormente os clusters de membros do ambiente de produção. Um tempo de espera pode ser especificado para atrasar entre a aplicação de estágios de atualização subsequentes.
• Grupo de atualização: cada estágio de atualização contém um ou mais grupos de atualização, que são usados para selecionar os clusters de membros a serem atualizados. Os grupos de atualização também são usados para solicitar a aplicação de atualizações aos clusters membros. Dentro de um estágio de atualização, as atualizações são aplicadas a todos os diferentes grupos de atualização em paralelo; Dentro de um grupo de atualização, os clusters de membros são atualizados sequencialmente. Cada cluster membro da frota só pode fazer parte de um grupo de atualização.
• 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 reutilizar 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 Kubernetes desejados ou versões de imagem de nó.

Atualmente, as operações de atualização suportadas no cluster de membros são atualizações. Há três tipos de atualizações que você pode escolher:

• Atualize as versões do Kubernetes para o plano de controle do Kubernetes e os nós (o que inclui a atualização das imagens do nó).
• Atualize as versões do Kubernetes apenas para o plano de controle dos clusters.
• Atualize apenas as imagens do nó.

Você pode especificar a versão do Kubernetes de destino para a qual atualizar, mas não pode especificar a versão exata da imagem do nó de destino. Isso ocorre porque a versão mais recente da imagem de nó disponível 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 da 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 for iniciada. 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 é iniciada.
• Consistent: Quando a execução da atualização é iniciada, ela seleciona as versões de imagem comuns mais recentes nas regiões do Azure dos clusters membros nesta execução, de modo que as mesmas versões de imagem consistentes sejam usadas em clusters.

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

Manutenção planeada

A atualização executa as janelas de manutenção planejada definidas no nível de cluster do Serviço Kubernetes do Azure (AKS).

Dentro de uma execução de atualização (para execução de atualização do tipo Um por um ou Estágios ), a execução de atualização prioriza a atualização dos clusters na seguinte ordem:

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

Atualizar estados de execução

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

• NotStarted: A execução da atualização não foi iniciada.
• Em execução: a atualização está em andamento para pelo menos um dos clusters membros na execução da atualização.
• Pendente:
  • Cluster de membros: um cluster de membros 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 a próxima hora de abertura.
    • A versão de destino do Kubernetes ainda não está disponível na região do Azure do membro. Links de mensagem para o rastreador de liberação para que você possa verificar o status da liberação em todas as regiões.
    • A versão da imagem do nó de destino ainda não está disponível na região do Azure do membro. Links de mensagem para o rastreador de liberação para que você possa verificar o status da liberação em todas as regiões.
  • Grupo: Um grupo estará no Pending estado se todos os membros do grupo estiverem no Pending estado ou não tiverem sido iniciados. Quando um membro se move para Pendingo , a execução da atualização tentará atualizar o próximo membro do grupo. Se todos os membros forem Pending, o grupo passa para Pending o estado. Se um grupo estiver no Pending estado, a execução da atualização aguardará a conclusão do grupo antes de passar para a próxima etapa para execução.
  • Estágio: Um estágio está no Pending estado se todos os grupos sob esse estágio estiverem no Pending estado ou não forem iniciados.
  • Executar: uma execução está no Pending estado se o estágio atual que deveria estar em execução estiver no Pending estado.
• Ignorado: Todos os níveis de uma execução de atualização podem ser ignorados. Pular pode ser iniciado pelo sistema ou pelo usuário.
  • Membro:
    • Você pulou a atualização para um membro, grupo ou estágio.
    • O cluster de membros já está na versão de destino do Kubernetes (se o modo de execução da atualização for Full ou ControlPlaneOnly).
    • O cluster de membros já está na versão 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 atualização, se não for possível encontrar a versão de imagem de destino para um dos pools de nós, a atualização será ignorada para esse cluster. Por exemplo, isso pode ocorrer quando um novo pool de nós com uma nova SKU de máquina virtual (VM) é adicionado após o início de uma execução de atualização.
  • Grupo:
    • Todos os clusters membros foram detetados como Skipped pelo sistema.
    • Você iniciou um pulo no nível do grupo.
  • Estágio:
    • Todos os grupos no estágio foram detetados como Skipped pelo sistema.
    • Você iniciou um pulo no nível do estágio.
  • Executar:
    • Todas as etapas foram detetadas como Skipped pelo sistema.
• Parado: Todos os níveis de uma execução de atualização podem ser interrompidos. Há duas possibilidades para entrar em um estado parado:
  • Você interrompe a execução da atualização, momento em que a execução da atualização para de controlar todas as operações. Se uma operação já tiver sido iniciada pela execução da atualização (por exemplo, uma atualização de cluster está em andamento), essa operação não será abortada para esse cluster individual.
  • Se for encontrada uma falha durante a execução da atualização (por exemplo, as atualizações falharam em um dos clusters), toda a execução da atualização entrará em um estado interrompido. As operações não são tentadas para nenhum cluster subsequente na execução da atualização.
• Falha: uma falha ao atualizar um cluster resulta nas seguintes ações:
  • Marca como MemberUpdateStatus Failed no cluster de membros.
  • Marca todos os pais (grupo -> estágio -> execução) como Failed com uma mensagem de erro de resumo.
  • Impede que a execução da atualização progrida ainda mais.

Noções básicas sobre perfis de atualização automática (visualização)

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

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

• a Channel (Stable, Rapid, NodeImage) que determina o tipo de atualização automática que é aplicada aos clusters.
• um UpdateStrategy que configura a sequência na qual os clusters são atualizados. Se uma estratégia não for fornecida, os clusters serão atualizados um a 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 Stable é sempre o mais recente lançamento do patch Kubernetes suportado pelo AKS na versão secundária N-1, onde N é a última versão secundária suportada.

Exemplos:

• A última versão secundária do Kubernetes suportada é a 1.30. Qualquer lançamento de patch na faixa secundária 1.29 seria considerado para atualizações de canal estável.
• Uma nova versão secundária do Kubernetes da versão 1.31 é publicada. Qualquer lançamento de patch na faixa secundária 1.30 seria considerado para atualizações de canal estável. Qualquer cluster que recebesse anteriormente atualizações da versão 1.29 seria atualizado para o patch mais recente da versão 1.30.

Canal rápido

O canal Rapid é sempre a versão secundária mais recente do Kubernetes suportada pelo AKS.

Exemplos:

• A última versão secundária suportada é a 1.30. Qualquer lançamento de patch na faixa secundária 1.30 seria considerado para atualizações de canal rápido.
• Uma nova versão secundária do Kubernetes da versão 1.31 é publicada. 1,30 muda para o canal estável. Qualquer cluster que recebesse anteriormente atualizações da versão 1.30 seria atualizado para o patch mais recente da versão 1.31 , que agora é o canal Rapid.

Canal NodeImage

Os nós de cluster de membros são atualizados com um VHD recém-corrigido contendo correções de segurança e correções de bugs em uma cadência semanal. A atualização para o novo VHD é disruptiva, seguindo janelas de manutenção e configurações de surto. Nenhum custo adicional de VHD é incorrido ao escolher esta 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 de nó suportam versões de patch que foram preteridas, desde que a versão secundária do Kubernetes ainda seja suportada. As imagens de nó são testadas pelo AKS, totalmente gerenciadas 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 de imagem do nó alinhadas a esses sistemas operacionais.

Exemplo:

• Um cluster tem nós com um NodeImage do AKSWindows-2022-containerd da versão 20348.2582.240716. Uma nova versão do NodeImage 20348.2582.240916 é lançada e os nós do cluster são atualizados automaticamente para a versão 20348.2582.240916.

Comportamento de ignorar 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 a 1.30). Quando os administradores têm um conjunto diversificado de versões do Kuberenetes, recomenda-se primeiro usar uma ou mais execuções de atualização para trazer clusters de membros para um conjunto de versões com versões consistentes, de modo que as atualizações configuradas Stable ou Rapid de canal garantam que a consistência seja mantida no futuro.

Próximos passos

• Como fazer: Atualizar vários clusters usando as execuções de atualização do Kubernetes Fleet Manager do Azure.
• Como fazer: atualize automaticamente vários clusters usando o Azure Kubernetes Fleet Manager.