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 com o preparo das atualizações de vários clusters (por exemplo, atualizando versões de imagem do sistema operacional do nó, atualizando versões do Kubernetes) de forma segura e previsível. Para resolver esse problema, o Azure Kubernetes Fleet Manager (Fleet) permite orquestrar atualizações em vários clusters usando execuções de atualização, estágios, grupos e estratégias.

• 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 as atualizações 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. 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 atualizações. Há dois 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 apenas as imagens do nó.

Você pode especificar a versão de destino do Kubernetes para a qual atualizar, mas não pode especificar as versões exatas da imagem do nó de destino, pois as versões mais recentes de imagem de nó disponíveis podem variar dependendo da região do cluster (verifique o rastreador de liberação 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 de um cluster quando a atualização do cluster for iniciada. Como resultado, diferentes versões de imagem podem ser usadas dependendo da região em que um cluster está e quando sua atualização realmente começa.
• Consistent: Quando a execução da atualização é iniciada, ela seleciona as versões de imagem comuns mais recentes nas regiões dos clusters membros nesta execução, de modo que as mesmas versões de imagem consistentes sejam usadas em todos os 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: Estado da atualização executada antes de ser iniciada.

• Em execução: a atualização está em andamento para pelo menos um dos clusters 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 e são exibidos sob o campo de mensagem.
    • A janela de manutenção não está aberta. A mensagem indica a próxima hora de abertura.
    • A versão Kubernetes de destino ainda não está disponível na região 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 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 dos grupos 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 estiverem no Pending status, o grupo será movido para Pending o estado. Todos os grupos devem estar em estado terminal antes de passar para a próxima fase. Ou seja, se um grupo estiver no Pending estado, a execução da atualização aguardará a conclusão antes de passar para a próxima etapa para execução.
  • Estágio: Um estágio está em Pending se todos os grupos sob esse estágio estão no Pending estado ou não foram 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 e isso pode ser detetado pelo sistema ou iniciado pelo usuário.

  • Membro:
    • Você pulou a atualização para um membro ou um de seus pais.
    • 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 da imagem de destino para um dos pools de nós, a atualização será ignorada para esse cluster. Um exemplo de situação para isso é quando um novo pool de nós com uma nova SKU de 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 de parada e operada não será tentada para nenhum cluster subsequente na execução da atualização.

• Falha: uma falha ao atualizar um cluster resultará nas seguintes ações:

  • Marca como MemberUpdateStatusFailed 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.

Próximos passos

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