Atualize de forma segura o Kubernetes e as imagens dos nós em vários clusters

Aplica-se a: ✔️ Fleet Manager ✔️ Fleet Manager com cluster de hubs

Os administradores de plataforma que gerem um grande número de clusters têm frequentemente dificuldades em fasear atualizações em múltiplos clusters (por exemplo, atualizar a imagem do sistema operativo dos nós ou as versões do Kubernetes) de forma segura e previsível. Para resolver este desafio, o Azure Kubernetes Fleet Manager permite-lhe orquestrar atualizações em vários clusters utilizando execuções de atualização.

As execuções de atualização consistem em etapas, grupos e estratégias. Pode aplicar atualizações manualmente para atualizações pontuais ou automaticamente para atualizações regulares contínuas usando perfis de atualização automática. Todas as atualizações, tanto manuais como automáticas, respeitam as janelas de manutenção do cluster.

Compreender as Execuções de Atualização

Uma execução de atualização representa uma atualização aplicada a uma coleção de clusters AKS. Consiste no objetivo e sequência da atualização. O objetivo da atualização descreve as atualizações desejadas. Por exemplo, atualizar para uma versão específica do Kubernetes ou utilizar uma imagem de nó uniforme em todos os clusters.

Para obter os melhores resultados ao utilizar execuções de atualização, é importante compreender os seguintes conceitos.

• Estratégia de Atualização: descreve uma sequência de atualizações reutilizável composta por estágios e grupos de clusters. Um cluster aparece num grupo numa fase com base no grupo de atualização ou nas etiquetas dos membros que lhe são atribuídas. Para mais informações, consulte Compreensão das estratégias de atualização.

  • Fase de Atualização: uma Estratégia de Atualização é dividida em Fases de Atualização, que são aplicadas sequencialmente. Por exemplo, os clusters do ambiente de teste estão na primeira Fase de Atualização, enquanto os clusters do ambiente de produção vão numa segunda Fase de Atualização. Uma Fase de Atualização contém um ou mais Grupos de Atualização. Pode usar controlos adicionais como concorrência máxima, tempos de espera e portões de aprovação para maior controlo sobre a execução da Fase de Atualização.

  • Grupo de Atualização: Cada Fase de Atualização contém um ou mais Grupos de Atualização, que selecionam clusters a atualizar. Atribua clusters de membros a Grupos de Atualização usando a propriedade de Grupo de Atualização do cluster ou a correspondência baseada em etiquetas de pré-visualização usando etiquetas de membros. Os grupos de atualização numa fase de atualização são atualizados em paralelo.

  Nota

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

  • Controlos de fluxo adicionais: estão disponíveis mais controlos para proporcionar flexibilidade quanto à rapidez com que uma frota de clusters pode ser atualizada:

    • Concorrência Máxima (versão preliminar): utilize a configuração Concorrência Máxima para alterar o número de clusters atualizados em paralelo. Pode configurar este comportamento tanto ao nível da Fase como do Grupo.

    • Falhas máximas permitidas (pré-visualização): utilize a configuração Falhas máximas permitidas para controlar quantas falhas de atualização de clusters membros são toleradas antes de a execução da atualização ser interrompida. Pode configurar este comportamento tanto ao nível da Fase como do Grupo.

    • Gates: Pausa a atualização até que a condição seja cumprida.

      • Portas de aprovação (visualização): podem ser configuradas 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 verifiquem se está tudo bem para continuar. Depois que você ou sua automação conceder aprovação, a execução da atualização continuará.

      • Portões de início programados (pré-visualização): Podem ser configurados antes de cada fase ou grupo. Os mecanismos de início programados suspendem a execução da atualização até ao dia e à hora especificados. A etapa fica concluída automaticamente quando a hora agendada é atingida, ou pode concluí-la manualmente para continuar 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 da imagem de nó são disponibilizadas pelo AKS. Para mais informações, consulte compreensão dos perfis de atualização automática.

Atualizar opções de execuçã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 controlo e os nós. Esta atualização inclui a atualização da imagem do nó.
• Atualize as versões do Kubernetes apenas para o plano de controle dos clusters.
• Atualize apenas as imagens dos nós.

Pode especificar a versão de destino do Kubernetes para a qual pretende atualizar, mas não pode selecionar as versões da imagem dos nós de destino. O sistema seleciona automaticamente as versões das imagens do nó alvo com base nas suas preferências:

• Mais recente: Utilize as imagens de nó mais recentes disponíveis na região do Azure de cada cluster quando se iniciar a atualização desse cluster. Como resultado, diferentes versões de imagem podiam ser usadas em toda a frota, dependendo da região Azure em que se encontra um cluster e de quando a sua atualização começa efetivamente.
• Consistente: Quando a execução da atualização começar, escolha versões de imagem que estejam atualmente disponíveis em todas as regiões do Azure onde os clusters desta execução estão localizados. Assim, são usadas versões de imagem consistentes em todos os clusters.

Escolha Mais recente para utilizar versões de imagem mais recentes e minimizar os riscos de segurança. Escolha Consistente para melhorar a fiabilidade, usando e verificando essas imagens em clusters em fases iniciais antes de as usar em clusters posteriores.

Atualizar estados de execução

Para compreender o ciclo de vida de uma execução de atualização, precisa de conhecer cada estado, as ações que pode tomar e como o estado é calculado.

Estado pendente

• Executar atualização: se a fase atual estiver no estado Pending.
• Fase de Atualização: se todos os Grupos de Atualização na fase já foram Pending iniciados ou não, ou se tiver um Pending portal.
• Grupo de atualização: se todos os clusters do grupo já foram Pending iniciados ou não, ou se tiver um Pending gate. Quando um cluster passa para Pending, a execução de atualização tenta atualizar o próximo cluster do grupo. Se todos os membros forem Pending, o grupo move-se para Pending. A corrida de atualização espera que todos os grupos de uma fase terminem antes de passar para a fase seguinte.
• Grupo de membros: por qualquer uma das seguintes razões, que pode consultar 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 ou da imagem do nó ainda não está disponível na região do Azure do cluster. A mensagem liga ao rastreador de lançamentos do AKS para verificar o estado do lançamento.

Estado omitido

• Execução de atualização: o sistema detetou que todas as etapas estavam Skipped.
• Atualizar etapa: um utilizador marcou a etapa, ou todos os grupos da etapa, como Skipped.
• Update Group: um utilizador marcou o grupo, ou todos os clusters do grupo, como Skipped.
• Grupo de membros: por qualquer uma das seguintes razões, que pode consultar no campo de mensagem.
  • O utilizador ignorou explicitamente o cluster, grupo ou etapa.
  • O cluster já está na versão alvo do Kubernetes (se o modo de atualização for Full ou ControlPlaneOnly) e todos os pools de nós estão na versão da imagem do nó alvo.
  • Quando a imagem de nó consistente estiver selecionada e não for possível encontrar a versão da imagem de destino para um dos conjuntos de nós. Esta situação pode ocorrer quando um novo pool de nós com um novo SKU de Máquina Virtual (VM) é adicionado após o início de uma atualização.

Estado de erro

O estado de falha propaga-se a partir dos clusters, como mostrado. Uma mensagem de erro resumida mostra a causa da falha na atualização do cluster.

• Execução da atualização: pelo menos um cluster do grupo atual falhou.
• Fase de Atualização: pelo menos um cluster de um grupo na fase falhou.
• Grupo de atualização: pelo menos um cluster do grupo falhou.
• Cluster membro: a atualização falhou e o estado do cluster está definido como Failed.

Quando configuras o Máximo de falhas permitidas, o limiar de falha afeta o estado do grupo de atualização, da fase de atualização e da execução da atualização. Não afeta o estatuto de um grupo de membros individuais. Se a atualização de um cluster membro falhar, o seu estado continua definido para Failed.

• Se a contagem de falhas para o grupo ou etapa exceder o limiar configurado maxAllowedFailures , o grupo ou etapa é marcado como Failed com uma mensagem de erro resumida, e a execução de atualização para de progredir. Se maxAllowedFailures não estiver configurado (ou se estiver definido como 0), uma única falha interrompe toda a execução.
• Se o número de falhas estiver dentro do limite de maxAllowedFailures, o processo de atualização continua com a atualização dos membros subsequentes. Para mais informações, consulte Falhas Máximas permitidas.

Estado concluído

Um Completed estado significa que a execução da atualização atingiu um estado de ciclo de vida terminal. Quando usas o Máximo de falhas permitidas, Completed significa que o limiar de falha configurado não foi ultrapassado quando o Gestor de Frota decidiu continuar a agendar o trabalho. Não garante uma taxa mínima de sucesso ou resultados saudáveis. Inspecione sempre FailureCount, os estados dos membros e as mensagens de erro.

Janelas de manutenção planeada

As execuções de atualização respeitam as janelas de manutenção planeadas que definiu ao nível do cluster AKS.

Os clusters AKS suportam 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.

Da seguinte forma: a atualização do Fleet Manager respeita as janelas de manutenção do AKS.

A execução da 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 aberta em curso.
2. Agrupamento cuja janela de manutenção abre nas próximas quatro horas.
3. Cluster sem janela de manutenção.
4. Cluster com uma janela de manutenção fechada.

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

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

Num Perfil de Atualização Automática, configura-se:

• um canal (Rapid, Stable, TargetKubernetesVersion, NodeImage, SecurityPatch (pré-visualização)) que determina o tipo de atualização aplicado aos clusters.
• uma UpdateStrategy que configura a sequência em que os clusters são atualizados. Se não fornecer uma estratégia, os clusters atualizam-se um a um sequencialmente.
• o NodeImageSelectionType (Mais recente, Consistente) para especificar como a imagem do nó é selecionada durante a atualização da versão do Kubernetes.

Canal rápido

O canal Rapid é sempre a versão secundária mais recente do Kubernetes suportada pelo AKS. As versões menores do cluster mudam automaticamente quando o AKS lança uma nova versão menor do Kubernetes.

Exemplos:

• A última versão secundária suportada é 1.30. Qualquer atualização na faixa 1.30 menor é considerada para atualizações do canal Rapid.
• Uma nova versão menor do Kubernetes 1.31 é publicada. 1,30 muda para o canal estável. Qualquer cluster que recebia anteriormente atualizações a partir da versão 1.30 é atualizado para a atualização corretiva mais recente da versão 1.31, que é agora o canal Rápido.

Canal estável

O canal Stable é sempre a versão menor antes do canal Rapid . Por vezes, as pessoas referem-se ao Stable como "N-1", em que "N" é a versão secundária do Kubernetes suportada mais recente (canal Rápido). As versões menores do cluster mudam automaticamente quando o AKS lança uma nova versão menor do Kubernetes.

Exemplos:

• A última versão secundária do Kubernetes suportada é a 1.30. Qualquer lançamento de patch na gama secundária 1.29 seria considerado para atualizações do canal Estável.
• Uma nova versão menor do Kubernetes 1.31 é publicada. O canal Stable considera qualquer atualização na faixa 1.30 menor para atualizações. Qualquer cluster que tenha recebido atualizações desde a versão 1.29 é atualizado para a versão de correção mais recente da 1.30.

Canal TargetKubernetesVersion

O canal TargetKubernetesVersion dá-te controlo sobre quando mover os teus clusters para a próxima versão menor do Kubernetes. Deve especificar a versão alvo do Kubernetes no formato "{major}. {minor}" (por exemplo, "1,33"). O Fleet Manager atualiza automaticamente os clusters para a última atualização da versão alvo especificada do Kubernetes quando o patch está disponível. O Fleet Manager não atualiza para a próxima versão menor até que a versão alvo do perfil de atualização automática do Kubernetes seja atualizada.

Exemplos:

• Cria-se um perfil de atualização automática usando o canal TargetKubernetesVersion e especifica-se uma versão Kubernetes alvo da "1.30". Uma nova versão de patch 1.30.5 é publicada. É criada automaticamente uma execução de atualização com a versão de destino 1.30.5.
• Cria-se um perfil de atualização automática usando o canal TargetKubernetesVersion, especifica uma versão Kubernetes alvo da "1.29" e ativa o LongTermSupport (LTS) no perfil de atualização automática. A última versão secundária suportada pela comunidade é "1.33". Uma nova versão de patch 1.29.5 é publicada. É criada automaticamente uma execução de atualização com a versão de destino 1.29.5. Se a execução da atualização gerada incluir clusters sem LTS ativado, falha.

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 entre as versões secundárias do Kubernetes (por exemplo: 1.28 para 1.30). Quando os administradores têm um conjunto diversificado de versões do Kubernetes, primeiro utilizam uma ou mais execuções de atualização para integrar clusters num conjunto de versões consistentes, de modo a que atualizações configuradas Stable ou Rapid de canal assegurem a consistência no futuro.

Canal NodeImage

Os nós de cluster de nós membros são atualizados com um VHD recém-corrigido contendo correções de segurança e correções de bugs numa base 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. As atualizações de imagem de nó suportam versões de patch que foram descontinuadas, desde que a versão menor 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 operativos são atualizados de acordo com as versões da imagem dos nós alinhadas a esses sistemas operativos.

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.

Compreender as atualizações de imagem de nós e os snapshots

Quando um cluster tem conjuntos de agentes criados a partir de um instantâneo de conjunto de nós, o resultado da atualização da imagem do nó depende da imagem do nó selecionada na execução de atualização do Fleet Manager.

Canal SecurityPatch (pré-visualização)

Atualize os nós Linux do cluster membro com apenas correções de segurança com uma cadência semanal. O Ubuntu canónico e o Azure Linux disponibilizam patches de segurança do sistema operativo uma vez por dia. A Microsoft testa estes patches e agrupa-os em atualizações semanais das imagens dos nós.

O canal de atualização automática do SecurityPatch é menos disruptivo, pois utiliza patches ao vivo do sistema operativo sempre que possível, minimizando a perturbação dos nós enquanto os mantém protegidos contra vulnerabilidades conhecidas. Quando não é possível fazer patches em direto, é implementada uma imagem de nó pré-atualizada.

Apenas os nós baseados em Linux são atualizados ao usar SecurityPatch, e os nós baseados em Windows são automaticamente ignorados.

Se precisar de correções de erros incluídas nas novas imagens de nós (VHD), ou de uma experiência consistente com nós do Windows, opte antes pelo canal NodeImage.

Compreender as Estratégias de Atualização

Os administradores podem controlar a ordem em que os clusters são atualizados construindo Estratégias de Atualização reutilizáveis usando uma série 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 guardada como uma Estratégia de Atualização, que pode ser gerida independentemente de Execuções de Atualização ou Perfis de Atualização Automática, permitindo reutilizar estratégias conforme necessário.

Clusters de grupos usando rótulos de membros (pré-visualização)

As etiquetas dos membros podem ser usadas para agrupar clusters e configurar a sua sequência de atualização com seletores de etiquetas ao estilo Kubernetes. Desta forma, pode atribuir múltiplos rótulos a clusters membros e usá-los para diferentes estratégias, em vez de estar limitado a um único grupo de atualização por cluster. Pode agrupar clusters na sua estratégia, juntamente com os respetivos rótulos de membros, ao configurar a sua estratégia em dois níveis:

• Nível da fase: Seleciona agrupamentos para toda a fase. Quando nenhum grupo está definido, todos os clusters correspondentes formam um único grupo implícito. Quando os grupos também são definidos, o seletor ao nível de etapa atua como um pré-filtro antes de o emparelhamento ao nível de grupo ser aplicado.
• Nível de grupo: Seleciona clusters para um grupo específico dentro de uma fase, permitindo subconjuntos paralelos com diferentes limites de concorrência.

memberSelector usa um seletor de etiquetas baseado em strings, que é analisado usando a sintaxe padrão do seletor de etiquetas do Kubernetes. Os operadores suportados são: =, ==, !=, in, notin, exists, e !exists.

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

Concorrência máxima (pré-visualização)

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

• Nível de fase: Define o número máximo de clusters que podem ser atualizados simultaneamente em todos os grupos de uma fase. Funciona como um teto global para o palco.
• Nível de grupo: Define o número máximo de clusters que podem ser atualizados simultaneamente dentro de um grupo específico.

A Concorrência Máxima aceita duas formas de valor:

• Inteiro fixo: Por exemplo, "3" limita a concorrência a exatamente três clusters.
• Percentagem: Por exemplo, limita "25%" a concorrência a uma percentagem de clusters. Para configurações ao nível do estágio, a percentagem é calculada a partir de todos os clusters do estágio. Para definições ao nível do grupo, a percentagem é calculada com base nos clusters desse grupo. As percentagens são calculadas em tempo de execução, arredondadas para baixo e aplicadas com um valor mínimo resolvido de 1.

Sugestões de controlo de concorrência

Se quiser atualizar com segurança (menos velocidade, mas menos probabilidade de acabar com vários clusters partidos): defina a concorrência máxima para um valor menor. Se pretenderes atualizar com rapidez (isto significa mais velocidade, mas com o risco de terminar com múltiplos clusters corrompidos): defina a concorrência máxima para um valor maior.

Como interagem os limites de palco e grupo

A concorrência máxima a nível de etapa atua sempre como o limite geral. Mesmo que grupos individuais permitam maior concorrência, o limite de fases tem prioridade. A concorrência dentro do grupo pode ser inferior à configurada devido ao limite a nível de etapa, tamanho do grupo ou condições específicas aos membros.

Exemplo 1: Limites fixos

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

Exemplo 2: Limitação de grupos na fase

Resultado: Apenas dois clusters completam a atualização ao mesmo tempo porque o limite de estágios tem prioridade.

Exemplo 3: Implementação baseada em percentagens

Um estágio tem 20 clusters divididos 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 os seus limites individuais.

Falhas máximas permitidas (versão preliminar)

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

Por defeito, as atualizações seguem um modelo de falha rápida – uma única falha no cluster impede novas atualizações. Quando configuras maximum allowed failures, a execução da atualização torna-se tolerante a falhas, e as atualizações continuam entre clusters até que o limiar especificado seja atingido.

Esta configuração proporciona um equilíbrio deliberado entre a deteção precoce de erros e a manutenção do ímpeto de implementação. Defina maximum allowed failures em dois níveis:

• Nível de etapa: Define o número máximo de falhas de atualização de membros toleradas em todos os grupos de uma fase antes de esta ser marcada como falhada.
• Nível de grupo: Define o número máximo de falhas de atualização de membros toleradas dentro de um grupo específico antes de este ser marcado como falhado.

Maximum allowed failures aceita duas formas de valor:

• Número inteiro fixo: Por exemplo, "3" permite até três falhas de membros do cluster antes de o grupo ou a fase ser assinalado como falhado.
• Percentagem: Por exemplo, "25%" permite falhas até 25% dos clusters membros. Para configurações ao nível do estágio, a percentagem é calculada a partir de todos os clusters do estágio. Para definições ao nível do grupo, a percentagem é calculada com base nos clusters desse grupo. As percentagens são resolvidas quando a corrida de atualização é criada, usando arredondamento de teto, por exemplo, 25% de 5 clusters resolvem-se para 2.

O Fleet Manager avalia maxAllowedFailures apenas com base na contagem de atualizações falhadas dos membros. Não avalia a taxa de sucesso, nem exige um número mínimo de membros bem-sucedidos. Quando esta configuração está presente, Completed significa que o limiar de falha configurado não foi ultrapassado no momento em que o Fleet Manager tomou as decisões de agendamento. Completed Isso não significa que o lançamento tenha sido saudável ou bem-sucedido.

Exemplo: Concluído com 0% sucesso

Suponha que um grupo tem quatro membros e group.maxAllowedFailures é definido como "4". Se todas as quatro atualizações dos membros falharem, o grupo ainda pode ser marcado Completed. Este resultado é esperado e intencional, não um erro, porque quatro falhas equivalem à tolerância configurada e, portanto, não ultrapassam o limiar. Por outras palavras, um grupo pode ser Completed mesmo quando 100% dos seus membros tenham falhado.

Só use esse limiar quando esse comportamento corresponde às suas expectativas de lançamento.

Escolha cuidadosamente os valores de limiar

• Os valores absolutos são fáceis de entender, mas podem produzir resultados contraintuitivos em pequenos grupos. Por exemplo, permitir "2" falhas num grupo de dois membros significa que o grupo pode terminar Completed mesmo que nenhum dos membros tenha tido sucesso.
• Os valores percentuais escalam melhor em diferentes tamanhos de grupo, por isso são recomendados para a maioria dos utilizadores.
• Evite definir maxAllowedFailures como igual ao número total de membros, a menos que pretenda intencionalmente um comportamento que, na prática, corresponda a "nunca falhar devido a falhas dos membros". Se esse comportamento for intencional, 100% normalmente escala de forma mais clara do que um número fixo.
• Tenha ainda mais cuidado com grupos pequenos, onde uma única falha pode representar uma grande percentagem do lançamento.
• Reavalie o limiar à medida que a sua frota cresce. Um valor que pareça seguro para cinco clusters pode ser demasiado rigoroso ou permissivo para 500 clusters.

Compreender a contagem de falhas

Os FailureCount campos são métricas de reporte. Contam as atualizações falhadas dos membros. Não são rácios ou percentagens, e não são o mesmo que o limiar de fiscalização configurado.

• UpdateRun.FailureCount: Total de atualizações de membros com falha em todas as fases e em todos os grupos da execução.
• Stage.FailureCount: Total de atualizações de membros que falharam em todos os grupos nessa etapa.
• Group.FailureCount: Total de atualizações de membros sem êxito nesse grupo.

Revise sempre estas contagens juntamente com os estados, condições e mensagens de falha ao nível dos membros antes de decidir se o resultado da implementação é aceitável.

Porque é que o FailureCount pode exceder o maxAllowedFailures

maxAllowedFailures controla a decisão do Gestor de Frota sobre continuar ou não a agendar novos trabalhos. Não é um limite superior rígido para o número final reportado de falhas.

Se permitir atualizações paralelas de membros usando maxConcurrency, vários membros podem falhar quase ao mesmo tempo antes de o Gestor de Frota observar que o limiar foi ultrapassado e parar de agendar mais trabalho. Como resultado, é possível e esperado que seja FailureCount maior do que o valor configurado maxAllowedFailures .

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

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

• Cada grupo monitoriza a sua própria contagem de falhas em relação ao seu próprio limiar.
• Essas mesmas falhas de grupo também se acumulam nas fases FailureCount.
• Se algum dos limites for ultrapassado, o Gestor de Frota deixa de agendar novos trabalhos nesse segmento.
• As atualizações de membros já iniciadas podem ainda ser concluídas, o que pode aumentar o valor final comunicado FailureCount depois de ser tomada a decisão de parar.

O nível maxAllowedFailures de estágio funciona como o teto geral para a tolerância a falhas numa fase. Mesmo que grupos individuais permitam números de falhas mais elevados, o limite da fase prevalece. Se o número de falhas de um grupo exceder o seu próprio maxAllowedFailures, esse grupo é marcado como falhado, independentemente da definição ao nível da fase.

Exemplo 1: Limites de falha fixos

Resultado: O Grupo A tolera até duas falhas e o Grupo B tolera até três. Se o total de falhas no estágio ultrapassar cinco, o estágio falha.

Exemplo 2: Tolerância baseada em percentagens

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

Usos recomendados e não recomendados

Utilize limiares mais elevados ou baseados em percentagens quando estiver a atualizar grandes frotas, quando for de esperar algumas falhas transitórias, ou quando o progresso da implementação for mais importante do que um comportamento estrito de falha rápida.

Use 0 ou valores muito pequenos para implementações críticas para a segurança, fases de produção rigorosamente controladas ou qualquer situação em que tenha de parar e verificar após a primeira falha.

Próximos passos

• Guia: Atualizar vários clusters usando as execuções de atualização do Fleet Manager do Azure Kubernetes.
• Como fazer: Atualizar automaticamente múltiplos clusters usando Azure Kubernetes Fleet Manager.
• Como fazer: Monitorizar execuções de atualização para Azure Kubernetes Fleet Manager.
• Perguntas frequentes sobre atualizações de vários clusters.