Atualize com segurança o Kubernetes e as imagens dos nós em vários clusters

Aplica-se a: ✔️ Gerenciador de frota ✔️ Gerenciador de frota com o cluster de hub

Os administradores de plataforma que gerenciam um grande número de clusters geralmente têm problemas para preparar atualizações para vários clusters (por exemplo, atualizar a imagem do sistema operacional do nó ou versões do Kubernetes) de maneira segura e previsível. Para enfrentar esse desafio, o Azure Kubernetes Fleet Manager permite orquestrar atualizações em vários clusters por meio de execuções de atualização.

As execuções de atualização consistem em estágios, grupos e estratégias. Você pode aplicar as execuções de atualização manualmente para atualizações pontuais ou automaticamente para atualizações regulares contínuas usando perfis de atualização automática. Todas as execuções de atualização, manual e automatizada, respeitam as janelas de manutenção do cluster.

Noções básicas sobre execuções 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. Ele consiste no objetivo de atualização e na sequência. A meta de atualização descreve as atualizações desejadas. Por exemplo, atualizar para uma versão específica do Kubernetes ou aplicar uma imagem de nó consistente em todos os clusters.

Para obter os melhores resultados ao usar execuções de atualização, é importante entender os conceitos a seguir.

• Estratégia de Atualização: descreve uma sequência de atualização reutilizável que consiste em estágios e grupos de clusters. Um cluster é exibido em um grupo em um estágio com base nos rótulos de grupo de atualização ou de membro que lhe foram atribuídos. Para obter mais informações, consulte noções básicas sobre estratégias de atualização.

  • Estágio de Atualização: uma Estratégia de Atualização é dividida em Estágios de Atualização, que são aplicados sequencialmente. Por exemplo, os clusters de ambiente de teste estão no primeiro Estágio de Atualização, enquanto os clusters de ambiente de produção entram em um segundo Estágio de Atualização. Um Estágio de Atualização contém um ou mais Grupos de Atualização. Você pode usar controles adicionais, como simultaneidade máxima, tempos de espera e portões de aprovação para obter mais controle sobre a execução do Estágio de Atualização.

  • Grupo de Atualizações: cada Estágio de Atualização contém um ou mais Grupos de Atualização, que selecionam clusters a serem atualizados. Atribua clusters de membro a Grupos de Atualização usando a propriedade Grupo de Atualizações do cluster ou a correspondência baseada em rótulo na versão prévia usando rótulos de membro. Os Grupos de Atualização em um Estágio de Atualização são atualizados em paralelo.

  Observação

  O número máximo de Grupos de Atualização em cada Estágio de Atualização é 50.

  • Controles de fluxo adicionais: mais controles estão disponíveis para fornecer flexibilidade sobre a rapidez com que uma frota de clusters pode ser atualizada:

    • Simultaneidade máxima (versão prévia): use a configuração máxima de simultaneidade para alterar quantos clusters são atualizados em paralelo. Você pode configurar esse comportamento no nível do Estágio e do Grupo.

    • Máximo de falhas permitidas (versão prévia): use a configuração de falhas máximas permitidas para controlar quantas falhas de atualização de cluster de membro são toleradas antes que a execução da atualização seja interrompida. Você pode configurar esse comportamento no nível do Estágio e do Grupo.

    • Portões: Interrompem a execução da atualização até que a condição seja atendida.

      • Portões de aprovação (versão prévia): pode ser configurado antes ou depois de cada estágio ou grupo. As aprovações pausam a execução da atualização, permitindo que você ou as automações que configurou confirmem se está tudo certo para prosseguir. Após você ou sua automação concederem a aprovação, a execução da atualização continuará.

      • Portões de início programados (versão prévia): podem ser configurados antes de cada etapa ou grupo. Portões de início agendado interrompem a execução da atualização até um dia e horário específicos. O portão é concluído automaticamente quando o horário agendado é atingido, ou você pode concluí-lo manualmente para prosseguir a qualquer momento.

• Perfil de atualização automática: cria e inicia automaticamente uma execução de atualização quando novas versões do Kubernetes ou de imagem de nó são disponibilizadas pelo AKS. Para obter mais informações, consulte noções básicas sobre perfis de atualização automática.

Opções para executar a atualização

As execuções de atualização podem aplicar três tipos de atualizações:

• Atualize as versões do Kubernetes para o plano de controle e os nós. Essa atualização inclui a atualização da imagem do nó.
• Atualizar versões do Kubernetes apenas para o painel de controle dos clusters.
• Faça upgrade apenas das imagens do nó.

Você pode especificar a versão do Kubernetes de destino para a qual atualizar, mas não pode selecionar as versões de imagem do nó de destino. O sistema seleciona automaticamente as versões de imagem do nó de destino com base em suas preferências:

• Mais recente: use as imagens de nó mais recentes disponíveis na região do Azure de cada cluster quando a atualização desse cluster for iniciada. Como resultado, diferentes versões de imagem podem ser usadas na frota, dependendo da região do Azure em que um cluster está e de quando sua atualização de fato começa.
• Consistente: quando a execução da atualização é iniciada, escolha versões de imagem que estão disponíveis no momento em todas as regiões Azure em que os clusters nesta execução estão localizados. Dessa forma, versões de imagem consistentes são usadas em todos os clusters.

Escolha Mais Recente para usar versões de imagem mais recentes e minimizar os riscos de segurança. Escolha Consistente para melhorar a confiabilidade usando e verificando essas imagens em clusters em estágios anteriores antes de usá-las em clusters posteriores.

Atualizar estados de execução

Para entender o ciclo de vida de uma execução de atualização, você precisa saber cada status, as ações que você pode executar e como o status é calculado.

Status pendente

• Execução de atualização: se o estágio atual estiver no estado Pending.
• Estágio de atualização: se todos os Grupos de Atualização no estágio forem Pending ou não iniciados ou se ele tiver um portão Pending.
• Grupo de atualização: se todos os clusters no grupo estiverem Pending ou não tiverem sido iniciados, ou se ele tiver um portão Pending. Quando um cluster é movido para Pending, a execução de atualização tenta atualizar o próximo cluster no grupo. Se todos os membros estiverem Pending, o grupo passará para Pending. O processo de atualização aguarda a conclusão de todos os grupos em um estágio antes de avançar para o próximo estágio.
• Cluster de membros: por qualquer um dos seguintes motivos, que você pode exibir 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 imagem do Kubernetes ou do nó de destino ainda não está disponível na região do Azure do cluster. Links de mensagem para o rastreador de versão do AKS para verificar o status da versão.

Status ignorado

• Execução de atualização: o sistema detectou que todos os estágios eram Skipped.
• Estágio de Atualização: um usuário marcou o estágio ou todos os grupos no estágio como Skipped.
• Grupo de Atualizações: um usuário marcou o grupo ou todos os clusters no grupo como Skipped.
• Cluster de membros: por qualquer um dos seguintes motivos, que você pode exibir no campo de mensagem.
  • O usuário ignorou explicitamente o cluster, o grupo ou o estágio.
  • O cluster já está na versão do Kubernetes de destino (se o modo de execução de atualização for Full ou ControlPlaneOnly) e todos os pools de nós estão na versão de imagem do nó de destino.
  • Quando a opção de imagem consistente para os nós estiver selecionada e não for possível encontrar a versão da imagem de destino para um dos pools de nós. Essa situação pode ocorrer quando um novo pool de nós com uma nova SKU de Máquina Virtual (VM) é adicionado depois que a execução de uma atualização é iniciada.

Status de falha

O status de falha se propaga em cascata a partir dos clusters, conforme mostrado. Uma mensagem de erro resumida exibe a causa da falha na atualização do cluster.

• Execução de atualização: pelo menos um cluster no grupo atual falhou.
• Fase de atualização: pelo menos um cluster em um grupo dessa fase falhou.
• Grupo de Atualizações: pelo menos um cluster no grupo falhou.
• Cluster de membros: falha na atualização e o status do cluster é definido como Failed.

Quando você configura falhas máximas permitidas, o limite de falha afeta o status do grupo de atualizações, do estágio de atualização e da execução da atualização. Ele não afeta o status de um cluster membro individual. Se uma atualização de um cluster membro falhar, seu status ainda será definido para Failed.

• Se a contagem de falhas do grupo ou estágio exceder o limite configurado maxAllowedFailures , o grupo ou estágio será marcado como Failed com uma mensagem de erro de resumo e a execução de atualização interromperá o progresso. Se não maxAllowedFailures estiver configurado (ou estiver definido como 0), uma única falha interromperá toda a execução.
• Se a contagem de falhas estiver dentro do maxAllowedFailures limite, a execução da atualização continuará atualizando os membros subsequentes. Para obter mais informações, consulte Máximo de falhas permitidas.

Status concluído

Um Completed status significa que a execução da atualização atingiu um estado de ciclo de vida do terminal. Quando você usa o máximo de falhas permitidas, Completed significa que o limite de falha configurado não foi excedido quando o Fleet Manager decidiu se deseja continuar o trabalho de agendamento. Não garante uma taxa mínima de sucesso ou resultados saudáveis. Sempre inspecione FailureCount, estados-membros e mensagens de falha.

Janelas de manutenção planejada

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

Os clusters do AKS dão suporte a duas janelas de manutenção distintas: uma para atualizações do Kubernetes (plano de controle) e outra para atualizações de imagem de nó. As janelas de manutenção definem períodos em que as atualizações podem ser aplicadas a um cluster, mas não são um gatilho de atualização.

As atualizações do Fleet Manager respeitam as janelas de manutenção do AKS da seguinte forma:

A execução de atualização prioriza a atualização de clusters com base na manutenção planejada na seguinte ordem:

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

Visão geral dos perfis de atualização automática

Use os perfis de atualização automática para acionar automaticamente execuções de atualização quando novas versões do Kubernetes ou da imagem de nó estiverem disponíveis para o AKS.

Em um Perfil de Atualização Automática, você configura:

• a Channel (Rapid, Stable, TargetKubernetesVersion, NodeImage, SecurityPatch (versão prévia)) que determina o tipo de atualização aplicada aos clusters.
• um UpdateStrategy que configura a sequência na qual os clusters são atualizados. Se você não fornecer uma estratégia, os clusters atualizarão 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 Rápido

O canal Rápido é sempre a versão secundária mais recente do Kubernetes com suporte do AKS. As versões secundárias do cluster são alteradas automaticamente quando o AKS lança uma nova versão secundária do Kubernetes.

Exemplos:

• A versão secundária mais recente com suporte é 1.30. Qualquer versão de correção na faixa da versão secundária 1.30 é considerada para atualizações do canal Rapid.
• Uma nova versão secundária do Kubernetes de 1.31 foi publicada. 1.30 muda para o canal Estável. Qualquer cluster que anteriormente recebia atualizações da versão 1.30 será atualizado para a correção mais recente da versão 1.31, que agora está no canal Rapid.

Canal estável

O canal Estável é sempre a versão menor anterior ao canal Rápido. Às vezes, as pessoas se referem ao Stable como "N-1", em que "N" é a versão secundária do Kubernetes com suporte mais recente (canal Rapid). As versões secundárias do cluster são alteradas automaticamente quando o AKS lança uma nova versão secundária do Kubernetes.

Exemplos:

• A versão secundária mais recente do Kubernetes com suporte é 1.30. As 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. O canal Stable considera qualquer versão de correção na faixa secundária 1.30 para atualizações. Qualquer cluster que antes recebia atualizações da versão 1.29 é atualizado para o patch mais recente da versão 1.30.

Canal de TargetKubernetesVersion

O canal TargetKubernetesVersion fornece controle sobre quando mover seus clusters para a próxima versão secundária do Kubernetes. Você deve especificar a versão do Kubernetes de destino no formato "{major}. {minor}" (por exemplo, "1,33"). O Fleet Manager atualiza automaticamente os clusters para a versão mais recente do patch da versão do Kubernetes de destino especificada quando o patch está disponível. O Gerenciador de Frota não será atualizado para a próxima versão secundária até que a versão de destino do Kubernetes no perfil de atualização automática seja atualizada.

Exemplos:

• Crie um perfil de atualização automática usando o canal TargetKubernetesVersion e especifique uma versão do Kubernetes de destino de "1.30". Um novo patch versão 1.30.5 é publicado. Uma execução da atualização é criada automaticamente com a versão de destino 1.30.5.
• Crie um perfil de atualização automática usando o canal TargetKubernetesVersion, especifique uma versão do Kubernetes de destino de "1.29" e habilite LongTermSupport (LTS) no perfil de atualização automática. A mais recente versão menor com suporte da comunidade é "1.33". Um novo patch versão 1.29.5 é publicado. Um processo de atualização é criado automaticamente com a versão de destino 1.29.5. Se a execução de atualização gerada incluir clusters sem LTS habilitado, ela falhará.

Comportamento de ignorar a versão secundária

O upgrade automático 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 têm um conjunto diversificado de versões do Kubernetes, primeiro use uma ou mais execuções de atualização para colocar os clusters em um conjunto de versões consistentes, de modo que as atualizações de canal configuradas Stable ou Rapid garantam a manutenção da consistência no futuro.

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. Os upgrades 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.

Nodos em diferentes sistemas operacionais são atualizados de acordo com as versões de imagem dos nodos que estão alinhadas a esses sistemas operacionais.

Exemplo:

• Um cluster tem nós com um 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.

Noções básicas sobre upgrades e instantâneos de imagem do nó

Quando um cluster tem pools de agentes que foram criados a partir de um instantâneo do pool de nós, o resultado do upgrade da imagem do nó depende da seleção de imagem do nó na Execução de Atualização do Gerenciador de Frota.

Canal SecurityPatch (versão prévia)

Atualizar nós do cluster de membros do Linux com apenas correções de segurança em uma cadência semanal. O Ubuntu canônico e Azure Linux disponibilizam patches de segurança do sistema operacional uma vez por dia. A Microsoft testa esses patches e agrupa-os nas atualizações semanais para imagens de nó.

O canal SecurityPatch de atualização automática é menos intrusivo, pois usa a aplicação de patches em tempo real no sistema operacional quando possível, minimizando interrupções nos nós enquanto mantém os nós protegidos contra vulnerabilidades conhecidas. Quando a aplicação de patch ao vivo não é possível, uma imagem de nó pré-corrigida é implantada.

Somente nós baseados em Linux são atualizados ao usar SecurityPatche nós baseados em Windows são ignorados automaticamente.

Se você precisar de correções de bugs incluídas em novas imagens de nó (VHD) ou de uma experiência consistente com nós do Windows, escolha o canal NodeImage.

Noções básicas sobre estratégias de atualização

Os administradores podem controlar a ordem na qual os clusters são atualizados criando estratégias de atualização reutilizáveis usando séries de Estágios e Grupos de Atualização. Eles podem configurar quando as aprovações e pausas devem ocorrer dentro desses estágios e grupos. Toda a configuração pode ser salva como uma Estratégia de Atualização que pode ser gerenciada independentemente de Execuções de Atualização ou Perfis de Atualização Automática, permitindo que as estratégias sejam reutilizados conforme necessário.

Agrupar clusters usando rótulos de membro (versão prévia)

Os rótulos de membro podem ser usados para agrupar clusters e configurar sua sequência de atualizações com seletores de rótulo no estilo Kubernetes. Dessa forma, você pode atribuir vários rótulos a clusters membros e usá-los para estratégias diferentes em vez de ficar restrito a um único grupo de atualizações por cluster. Você pode agrupar clusters na sua estratégia com base nos rótulos de seus membros, configurando memberSelector na sua estratégia em dois níveis:

• Nível do estágio: Seleciona clusters para todo o estágio. Quando nenhum grupo é definido, todos os clusters correspondentes formam um único grupo implícito. Quando também são definidos grupos, o seletor de nível de etapa atua como um pré-filtro antes da aplicação da correspondência de nível de grupo.
• Nível de grupo: seleciona clusters para um grupo específico em um estágio, habilitando subconjuntos paralelos com limites de simultaneidade diferentes.

memberSelector usa um seletor de rótulo baseado em cadeia de caracteres que é analisado usando a sintaxe do seletor de rótulo kubernetes padrão. Os operadores com suporte são: =, , ==, !=, in, notin, , existse !exists.

Para obter instruções sobre como atribuir rótulos de membro e usar memberSelector em uma estratégia, consulte Criar uma estratégia de atualização usando seletores de membro.

Simultaneidade máxima (versão preliminar)

Maximum concurrency é uma configuração opcional em sua estratégia de atualização que controla quantos clusters podem ser atualizados simultaneamente. Você pode definir Maximum concurrency em dois níveis:

• Nível do estágio: define o número máximo de clusters que podem ser atualizados ao mesmo tempo em todos os grupos em um estágio. Atua como um teto global para o estágio.
• Nível de grupo: define o número máximo de clusters que podem ser atualizados simultaneamente em um grupo específico.

A Concorrência Máxima aceita dois formatos de valor:

• Inteiro fixo: por exemplo, "3" limita a simultaneidade a exatamente três clusters.
• Porcentagem: por exemplo, "25%" limita a simultaneidade a um percentual de clusters. Para configurações no nível de estágio, a porcentagem é calculada a partir de todos os clusters no estágio. Para configurações de nível de grupo, o percentual é calculado a partir dos clusters nesse grupo. Os percentuais são calculados em runtime, arredondados para o menor valor inteiro e aplicados com um valor mínimo resolvido de 1.

Sugestões de controle de simultaneidade

Se você quiser atualizar com segurança (menor velocidade, mas com menor probabilidade de terminar com vários clusters quebrados): defina a simultaneidade máxima como um valor menor. Se você quiser atualizar com velocidade (mais velocidade, mas provavelmente terminará com vários clusters quebrados): defina a concorrência máxima para um valor maior.

Como os limites de estágio e grupo interagem

A concorrência máxima no nível do estágio sempre serve como o limite geral. Mesmo que grupos individuais permitam maior simultaneidade, o limite da fase terá precedência. A simultaneidade no nível de grupo pode ser menor do que a configurada devido ao limite de nível de estágio, ao tamanho do grupo ou às condições específicas do membro.

Exemplo 1: limites fixos

Resultado: até quatro clusters no total, com um máximo de dois por grupo.

Exemplo 2: o limite de etapa restringe os grupos

Resultado: apenas dois clusters são atualizados ao mesmo tempo porque o limite de estágio tem precedência.

Exemplo 3: distribuição baseada em porcentagem

Um estágio tem 20 clusters em dois grupos: Grupo A (oito clusters) e Grupo B (12 clusters).

Resultado: até cinco atualizações simultâneas no total, distribuídas entre grupos de acordo com seus limites individuais.

Máximo de falhas permitidas (versão prévia)

Maximum allowed failures é uma configuração de estratégia de atualização opcional que controla como o Fleet Manager responde a falhas durante atualizações multicluster.

Por padrão, as atualizações seguem um modelo de falha rápida — uma única falha de cluster interrompe as atualizações subsequentes. Quando você configura maximum allowed failures, a execução de atualização torna-se tolerante a falhas e as atualizações continuam entre clusters até que o limite de falha especificado seja atingido.

Essa configuração fornece um equilíbrio deliberado entre a detecção de erros precoce e a manutenção do impulso da implantação. Definir maximum allowed failures em dois níveis:

• Nível de estágio: define o número máximo de falhas de atualização de membro toleradas em todos os grupos em um estágio antes que o estágio seja marcado como com falha.
• Nível do grupo: Define o número máximo de falhas na atualização de membros toleradas dentro de um grupo específico antes que o grupo seja marcado como com falha.

Maximum allowed failures aceita dois formulários de valor:

• Número inteiro fixo: Por exemplo, "3" permite até três falhas de clusters de membros antes que o grupo ou estágio seja marcado como falho.
• Porcentagem: por exemplo, "25%" permite falhas de até 25% dos clusters membros. Para configurações no nível de estágio, a porcentagem é calculada a partir de todos os clusters no estágio. Para configurações de nível de grupo, o percentual é calculado a partir dos clusters nesse grupo. Os percentuais são calculados quando a execução de atualização é criada, usando arredondamento para cima; por exemplo, 25% de 5 clusters resulta em 2.

O Gerenciador de Frota avalia maxAllowedFailures apenas com base na contagem de atualizações dos membros com falha. Ele não avalia a taxa de êxito e não requer nenhum número mínimo de membros bem-sucedidos. Quando essa configuração está presente, Completed significa que o limite de falha configurado não foi excedido no momento em que o Fleet Manager tomou suas decisões de agendamento. Completed não significa que a implantação ocorreu bem ou foi bem-sucedida.

Exemplo: concluído com 0% êxito

Suponha que um grupo tenha quatro membros e group.maxAllowedFailures esteja definido como "4". Se as quatro atualizações dos membros falharem, o grupo ainda pode ser marcado Completed. Esse resultado é esperado e intencional, não um bug, porque quatro falhas são iguais à tolerância configurada e, portanto, não excedem o limite. Em outras palavras, um grupo pode ser Completed mesmo quando 100% de seus membros falharam.

Use esse limite apenas quando esse comportamento corresponder às suas expectativas de distribuição.

Escolha valores de limite com cuidado

• Valores absolutos são fáceis de entender, mas podem produzir resultados contraintuitivos em grupos pequenos. Por exemplo, permitir "2" falhas em um grupo com dois membros significa que o grupo pode concluir como Completed mesmo que nenhum dos membros tenha êxito.
• Os valores percentuais são dimensionados melhor em diferentes tamanhos de grupo, portanto, são recomendados para a maioria dos usuários.
• Evite definir maxAllowedFailures como o número total de membros, a menos que você queira, na prática, o comportamento de “nunca falhar por causa de falhas dos membros”. Se esse comportamento for intencional, 100% geralmente será dimensionado mais claramente do que um número fixo.
• Tenha cuidado extra com grupos pequenos, em que uma única falha pode representar uma grande porcentagem da distribuição.
• Reavalie o limite à medida que sua frota cresce. Um valor que parece seguro para cinco clusters pode ser muito estrito ou permissivo demais para 500 clusters.

Noções básicas sobre FailureCount

Os FailureCount campos estão relatando métricas. Eles contam atualizações de membros que falharam. Elas não são proporções ou porcentagens e não são iguais ao limite de imposição configurado.

• UpdateRun.FailureCount: total de atualizações de membros com falha em todos os estágios e em todos os grupos durante a execução.
• Stage.FailureCount: total de atualizações de membros com falha em todos os grupos nesse estágio.
• Group.FailureCount: total de falhas nas atualizações de membros nesse grupo.

Sempre revise essas contagens juntamente com os status, as condições e as mensagens de falha no nível do membro antes de decidir se o resultado da implantação é aceitável.

Por que FailureCount pode exceder maxAllowedFailures

maxAllowedFailures controla a tomada de decisões do Fleet Manager sobre a possibilidade de continuar agendando novos trabalhos. Não é um limite superior rígido para o número final de falhas relatado.

Se você permitir atualizações de membros paralelos usando maxConcurrency, vários membros poderão falhar quase ao mesmo tempo antes que o Fleet Manager observe que o limite é excedido e interrompe o agendamento de mais trabalho. Como resultado, é possível e esperado FailureCount que seja maior que o valor configurado maxAllowedFailures .

Como os limites de falha de estágio e grupo interagem

O nível de grupo e o nível maxAllowedFailures do estágio são avaliados de forma independente:

• Cada grupo acompanha sua própria contagem de falhas em relação ao seu próprio limite.
• Essas mesmas falhas de grupo também se acumulam no FailureCount do estágio.
• Se um dos limites for excedido, o Fleet Manager interromperá o agendamento de novos trabalhos para esse segmento.
• As atualizações de membros já iniciadas ainda podem ser finalizadas, o que pode aumentar o FailureCount final informado depois que a decisão de parada for tomada.

No nível do estágio, maxAllowedFailures funciona como o limite máximo geral da tolerância a falhas. Mesmo que grupos individuais permitam contagens de falhas mais altas, o limite de estágio terá precedência. Se a contagem de falhas de um grupo exceder seu próprio maxAllowedFailures, esse grupo será marcado como falho, independentemente da configuração no nível do estágio.

Exemplo 1: limites fixos de falha

Resultado: o Grupo A tolera até duas falhas e o Grupo B tolera até três. Se o total de falhas em todo o estágio exceder cinco, o estágio falhará.

Exemplo 2: tolerância baseada em porcentagem

Um estágio tem 19 clusters em dois grupos: Grupo A com 7 clusters e Grupo B com 12 clusters.

Usos recomendados e não recomendados

Use limites mais altos ou baseados em porcentagem ao atualizar grandes frotas, quando você espera algumas falhas transitórias ou quando o progresso da distribuição é mais importante do que um comportamento estrito de fail-fast.

Use 0 ou valores muito pequenos para implantações essenciais para a segurança, etapas de produção rigidamente controladas ou qualquer situação em que você precisar parar e inspecionar após a primeira falha.

Próximas etapas

• Guia para: atualizar vários clusters usando execuções de atualização do Azure Kubernetes Fleet Manager.
• Como fazer: atualize automaticamente vários clusters usando Azure Kubernetes Fleet Manager.
• Guia Prático: Monitorar ciclos de atualização para o Azure Kubernetes Fleet Manager.
• Perguntas frequentes sobre atualizações de vários clusters.