Política de interrupção de nó no AKS (Serviço de Kubernetes do Azure) (Versão Prévia)

À medida que você gerencia e mantém seus clusters do AKS, determinadas alterações de configuração exigem que os nós sejam recriados a partir da imagem. Essa operação de recriação da imagem aciona uma atualização gradual que recria os nós. Durante uma operação de recriação da imagem, o AKS marca o nó como indisponível para novo agendamento (impede o agendamento de novos pods), drena os pods existentes (desalojando-os e reagendando-os em outros nós disponíveis, respeitando os Pod Disruption Budgets) e, em seguida, recria a imagem do nó com a configuração atualizada. Esse processo é uma recriação completa do nó, não uma reinicialização - a VM subjacente é reimageada com uma nova imagem do sistema operacional. Embora volumes persistentes configurados corretamente (usando discos Azure, Arquivos do Azure ou outro armazenamento externo) não sejam afetados, todos os dados armazenados no armazenamento efêmero local do nó (como volumes EmptyDir ou caminhos locais) são permanentemente perdidos. Essas operações são necessárias para aplicar atualizações importantes, mas podem interromper a execução de cargas de trabalho e afetar a disponibilidade do aplicativo. A política de interrupção de nós oferece controle granular sobre quando essas operações de interrupção podem prosseguir, ajudando você a equilibrar a necessidade de atualizações e a estabilidade operacional.

Importante

As funcionalidades em versão preliminar do AKS estão disponíveis de forma optativa e por autoatendimento. 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. As versões prévias do AKS são parcialmente cobertas pelo suporte ao cliente em uma base de melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção. Para obter mais informações, consulte os seguintes artigos:

O que é a Política de Interrupção do Nó?

A Política de Interrupção de Nó é uma configuração em nível de cluster que define quando operações que exigem a reimagem e a reimplantação do nó podem ser executadas. Ele atua como uma porta de controle, permitindo que você:

  • Alinhe as operações que causam interrupção com as janelas de manutenção.
  • Bloqueie as alterações de configuração durante períodos críticos para os negócios, permitindo que atualizações de imagens de nós e patches de segurança continuem.
  • Mantenha o comportamento previsível do cluster durante eventos de alto tráfego.

A política se aplica a alterações de configuração iniciadas pelo usuário que exigem a recriação do nó, como atualizar certificados de confiança de autoridade certificadora (AC) personalizada, modificar as configurações do perfil de segurança ou alterar a configuração do sistema operacional do nó.

Note

É importante ressaltar que a política não bloqueia atualizações da versão da imagem do nó (incluindo os canais de upgrade SecurityPatch e NodeImage) nem upgrades de versão do Kubernetes. Essas operações continuam a continuar de acordo com seus agendamentos configurados mesmo quando a política é definida como Block. Para obter detalhes, consulte Operações de atualização não controladas pela Política de Interrupção do Nó. Além disso, determinadas operações de recuperação não são controladas por essa política para garantir a integridade e a disponibilidade do cluster. Para obter detalhes, consulte Operações de recuperação não controladas pela Política de Interrupção do Nó.

Como funciona a Política de Interrupção do Nó

Você configura a política de interrupção de nós no nível do cluster por meio da propriedade nodeDisruptionProfile. Quando você tenta uma operação que requer uma nova imagem de nó, o AKS verifica a configuração de política atual:

  • Avaliação da política: o AKS avalia se a operação é permitida com base na política atual.
  • Verificação da janela de manutenção (se aplicável): se estiver usando AllowDuringMaintenanceWindow, o AKS verificará se a hora atual está dentro da janela de manutenção configurada.
  • Execução ou bloqueio da operação: A operação disruptiva ao nó prossegue, se permitida, ou é rejeitada com uma mensagem de erro, se bloqueada.

Opções de política

A Política de Interrupção do Nó dá suporte a três configurações de política:

Policy Descrição Caso de uso
Allow Permite que operações que exigem a recriação da imagem do nó prossigam a qualquer momento. Esse é o comportamento padrão. Use quando quiser priorizar a aplicação de atualizações rapidamente e pode tolerar a interrupção da carga de trabalho.
AllowDuringMaintenanceWindow Bloqueia operações que exigem a recriação da imagem do nó, a menos que ocorram dentro da janela de manutenção aksManagedNodeOSUpgradeSchedule. Use quando quiser limitar as interrupções a janelas de manutenção específicas que se alinham ao seu agendamento operacional.
Block Bloqueia todas as operações que exigem a recriação da imagem do nó. Use-o quando precisar evitar interrupções em qualquer nó, como durante períodos críticos para os negócios ou eventos de alto tráfego.

Note

Ao usar AllowDuringMaintenanceWindow, você deve configurar uma aksManagedNodeOSUpgradeSchedule janela de manutenção. Para obter mais informações sobre como configurar janelas de manutenção, consulte Usar a manutenção planejada para agendar e controlar atualizações para o cluster Serviço de Kubernetes do Azure. Se você não configurar a janela de manutenção, as operações que causam interrupção no nó são permitidas.

Considerations

Tenha em mente as considerações a seguir ao usar a Política de Interrupção do Nó:

Operações abrangidas pela Política de Interrupção do Nó

Operações no nível do cluster

Habilitação da política de rede e atualização do Azure CNI Overlay

Para instalar os componentes de rede necessários e configurar regras de rede que protegem e gerenciam a comunicação pod a pod, você precisa refazer a imagem dos nós.

A tabela a seguir apresenta as atualizações da política de rede que acionam a recriação da imagem:

De Para
Nenhum (nenhuma política de rede) Política de Rede Azure
Nenhum (nenhuma política de rede) Calico
CNI do Azure CNI Overlay do Azure
Política de Rede Azure Nenhum (nenhuma política de rede)
Calico Nenhum (nenhuma política de rede)

Note

A alteração entre as políticas de rede Azure e Calico depois que uma já está habilitada não requer uma nova imagem.

Alterações no canal de atualização do sistema operacional do nó

Cada canal usa uma infraestrutura e uma configuração de aplicação de patches do sistema operacional diferentes que você não pode modificar nos nós em execução.

A tabela a seguir apresenta as alterações no canal de atualização do sistema operacional do nó que acionam a recriação da imagem:

De Para
Não gerenciado None
Unspecified Não gerenciado
Patch de Segurança Não gerenciado
NodeImage Não gerenciado
None Não gerenciado
Unspecified Não gerenciado
Não gerenciado Patch de Segurança
Não gerenciado NodeImage

Habilitação de pilha dupla IPv6

Para dar suporte à comunicação em pilha dupla, os nós precisam de configurações de IP para IPv4 e IPv6 e de atualizações na pilha de rede (como regras do nftables).

A tabela a seguir apresenta a configuração de IP e as atualizações da pilha de rede que acionam a recriação da imagem:

De Para
Somente IPv4 IPv4 + IPv6 (pilha dupla)

Alterações no plano de dados do Cilium

Você precisa instalar ou remover programas eBPF que lidam com o processamento de pacotes no nível do kernel.

A tabela a seguir apresenta as alterações no plano de dados do Cilium que acionam a recriação da imagem:

De Para
None Cilium
Cilium None

Atualizações na configuração de proxy HTTP

Todos os componentes do nó (containerd, kubelet, serviços do sistema) precisam que a configuração de proxy atualizada seja aplicada em todo o sistema. Quando você atualiza a configuração de proxy HTTP, o AKS recria automaticamente todos os pools de nós no cluster.

A Política de Interrupção do Nó aciona a recriação da imagem quando você modifica qualquer uma das seguintes propriedades de configuração do proxy HTTP ou executa qualquer uma das seguintes operações:

  • httpProxy: URL de proxy para conexões HTTP
  • httpsProxy: URL de proxy para conexões HTTPS
  • noProxy: lista de destinos a serem excluídos do proxy
  • trustedCa: certificado de AC alternativo codificado em Base64
  • Habilitar o proxy HTTP em um cluster (com --enable-http-proxy)
  • Desabilitar o proxy HTTP em um cluster (com --disable-http-proxy)
  • Reativar o proxy HTTP em um cluster que havia sido desativado anteriormente

Atualizações de certificados de AC personalizados

Você deve instalar novos certificados de AC no repositório de confiança do sistema operacional para afetar a validação do TLS para serviços internos e registros privados.

A Política de Disrupção de Nó aciona a recriação da imagem quando você adiciona, remove ou atualiza certificados de AC personalizados.

Alterações de identidade do Kubelet

Você deve aplicar novas credenciais de identidade à configuração do nó. Isso inclui atribuição de identidade inicial, atualizações de identidade e redefinições de perfil da entidade de serviço.

A Política de Disrupção de Nó aciona a recriação da imagem quando você atualiza uma identidade gerenciada ou uma identidade gerenciada atribuída pelo usuário para o kubelet.

alterações de zona de DNS privado

Você deve atualizar as configurações de resolvedor de DNS para resolver o ponto de extremidade do servidor de API privada usando a nova zona DNS.

A Política de Interrupção do Nó aciona o reimage quando você modifica a configuração de uma zona DNS privada em um cluster privado.

Habilitação da Integração VNet do Servidor de API

Você deve reconfigurar os nós para se comunicar com o servidor de API por meio do IP interno do balanceador de carga projetado na sub-rede delegada.

A Política de interrupção de nó aciona a recriação da imagem quando você habilita a Integração de VNet do Servidor de API em um cluster existente que anteriormente não usava esse recurso. Essa alteração corresponde à alteração da apiServerAccessProfile.enableVnetIntegration propriedade (internamente o privateConnectProfile.enabled campo) de false (ou não definido) para true:

De Para
apiServerAccessProfile.enableVnetIntegration: false ou não definido apiServerAccessProfile.enableVnetIntegration: true

Alterações no roteamento eBPF do host

Você precisa instalar ou remover programas eBPF que fornecem encaminhamento de pacotes de alto desempenho (modo de aceleração BpfVeth).

A tabela a seguir apresenta as alterações no roteamento de host do eBPF que acionam a recriação da imagem:

De Para
Roteamento padrão Roteamento de host eBPF habilitado
Roteamento do host com eBPF habilitado Roteamento padrão

Operações no nível do pool de nós

Essas operações afetam apenas os pools de nós específicos em que você faz alterações. Eles acionam um reprovisionamento gradual da imagem nesses pools de nós:

Atualizações de perfil DNS local

Você precisa aplicar alterações ao daemon de cache de DNS e às regras de encaminhamento de DNS em nível de nó.

A Política de Interrupção do Nó aciona a recriação da imagem quando você modifica a configuração de um perfil do LocalDNS.

Alterações de segurança do Trusted Launch

Não é possível alterar as configurações de firmware da VM e as configurações do processo de inicialização em VMs em execução. Essas alterações exigem que você recrie as VMs.

A tabela a seguir descreve as alterações de segurança do Trusted Launch que exigem a recriação da imagem:

Configuração De Para
vTPM (virtual Trusted Platform Module) Disabled habilitado
vTPM (virtual Trusted Platform Module) habilitado Disabled
Inicialização Segura Disabled habilitado
Inicialização Segura habilitado Disabled

Alterações no streaming de artefatos

Você precisa instalar ou remover componentes de streaming de artefatos para permitir o download mais rápido de imagens de contêiner com a transmissão sob demanda das camadas da imagem.

A tabela a seguir apresenta as alterações no streaming de artefatos que acionam a recriação da imagem:

De Para
Disabled habilitado
habilitado Disabled

Atualizações de perfil do Windows GMSA (somente para pools de nós do Windows)

Você precisa aplicar novas configurações de gMSA, configurações do servidor DNS e credenciais para ingresso no domínio para a integração com o Active Directory nos nós do Windows.

A Política de Interrupção de Nó aciona a recriação da imagem dos pools de nós do Windows quando uma alteração no GMSA exige a aplicação de uma nova configuração de nó:

De Para Aciona a recriação da imagem
GMSA desabilitado GMSA ativado Yes
GMSA ativado (servidor DNS / domínio raiz definido ou alterado) GMSA habilitado com servidor DNS atualizado ou domínio raiz Yes
GMSA habilitado (servidor DNS definido) GMSA desabilitado Yes
GMSA habilitado (nenhum servidor DNS definido) GMSA desabilitado Não (nenhuma configuração de nó a ser aplicada)

Anexo do Grupo de Reserva de Capacidade

Você precisa recriar as VMs subjacentes para que sejam alocadas a partir da capacidade reservada no Grupo de Reserva de Capacidade (CRG). Os nós existentes não foram provisionados com base no CRG; portanto o AKS deve recriar a imagem do pool de nós para associá-los à reserva.

A Política de Disrupção de Nós aciona a recriação da imagem quando você associa um Grupo de Reserva de Capacidade a um pool de nós existente que ainda não esteja associado a um.

De Para Aciona a recriação da imagem
Nenhum grupo de reserva de capacidade associado Grupo de Reserva de Capacidade anexado Yes

Operações ainda não abrangidas pela Política de Interrupção do Nó

As alterações de configuração a seguir exigem uma nova imagem de nó, mas ainda não foram cobertas pela Política de Interrupção do Nó. Uma futura atualização de uma versão menor do Kubernetes incluirá essas mudanças, pois essa alteração introduz um novo comportamento.
Depois de fazer essas alterações de configuração, você deve executar az aks nodepool upgrade--node-image-only manualmente para aplicar as alterações aos seus nós.

  • Alterações de configuração de SSH: alterando métodos de acesso SSH (SSH desabilitado, SSH baseado em Entra ID ou SSH de Usuário Local) ou atualizando chaves públicas SSH em pools de nós.
  • Alterações na restrição do IMDS: ativar ou desativar a restrição do IMDS para bloquear o acesso dos pods ao endpoint do IMDS.
  • Alterações no perfil de bootstrap: alterar o perfil de bootstrap, como alternar o artifactSource entre Direct e Cache, ou alterar o containerRegistryId (o Registro de Contêiner do Azure usado para clusters com isolamento de rede).
  • Alterações de tipo de saída: modificando o tipo de conectividade de saída do cluster (loadBalancer, userDefinedRouting, managedNATGateway ou userAssignedNATGateway).

Operações de atualização não controladas pela Política de Interrupção do Nó

A política de interrupção de nós não controla as seguintes operações de atualização. Essas operações de atualização prossseguem independentemente da configuração de política. As atualizações são iniciadas pelo cliente ou iniciadas pelo AKS em janelas de manutenção planejadas. Para permitir que essas operações prossigam conforme o agendamento, mantenha-as intencionalmente fora do escopo da Política de Interrupção do Nó. Adicionalmente, se as operações cobertas pela Política de Interrupção do Nó forem incluídas nas mesmas alterações de configuração com atualizações, elas não serão controladas pela Política de Interrupção do Nó.

  • Versão da imagem do nó atualizações: Atualização para uma nova versão da imagem do sistema operacional do nó (manualmente ou por meio de canais de atualização automática). Essa é a operação de reimagem mais comum e inclui patches de segurança, atualizações do sistema operacional e lançamentos de imagens de nó do AKS.
  • Atualizações de versão do Kubernetes: Atualização da versão do Kubernetes em um conjunto de nós, que aplica novos binários do Kubernetes, uma configuração atualizada do kubelet e alterações no nível do sistema operacional.

Operações de recuperação não controladas pela política de interrupção do nó

A Política de Interrupção do Nó não controla as seguintes operações de recuperação automatizadas. Essas operações podem ocorrer independentemente da configuração de política para garantir a integridade e a recuperação do cluster.

  • Reversão da configuração do pool de nós: quando uma operação de atualização de um pool de nós falha devido a configuração inválida ou problemas de infraestrutura, o AKS reverte automaticamente para o último estado válido conhecido e recria a imagem dos nós para restaurar a configuração.
  • Operações de restauração do cluster de administração: Quando os engenheiros de suporte do Azure realizam a restauração administrativa do cluster durante a resolução de incidentes, os nós têm suas imagens recriadas para garantir a consistência entre o estado do plano de controle e a configuração dos nós.
  • Atualizações de credenciais de identidade do nó: o AKS atualiza periodicamente as credenciais de identidade do nó para segurança e conformidade. Essas atualizações iniciadas pelo sistema acionam a recriação das imagens dos nós para aplicar as novas credenciais a todos os pools de nós.

Integração com a manutenção planejada

A Política de Interrupção de Nó integra-se perfeitamente às janelas de manutenção planejada do AKS. Quando você define a política como AllowDuringMaintenanceWindow, as operações disruptivas ficam alinhadas com a janela de manutenção aksManagedNodeOSUpgradeSchedule, garantindo que:

  • As alterações ocorrem somente durante as janelas de tempo aprovadas.
  • As operações são coordenadas com outras manutenções programadas.
  • As equipes estão cientes de quando as interrupções podem ocorrer.

Essa integração fornece uma abordagem abrangente para gerenciar alterações de cluster e minimizar o impacto na execução de cargas de trabalho.

Note

Ao usar AllowDuringMaintenanceWindow, você deve configurar uma aksManagedNodeOSUpgradeSchedule janela de manutenção. Usar a default janela de manutenção ou aksManagedAutoUpgradeSchedule (atualização automática do cluster) não satisfaz esse requisito. Se você definir AllowDuringMaintenanceWindow sem ter uma janela aksManagedNodeOSUpgradeSchedule configurada, todas as operações disruptivas serão permitidas (a política não tem nenhuma janela para restringi-las). Para obter mais informações sobre como configurar janelas de manutenção, consulte Usar a manutenção planejada para agendar e controlar atualizações para o cluster Serviço de Kubernetes do Azure.

Práticas recomendadas

Considere estas recomendações ao implementar a Política de Interrupção do Nó:

  • Uso AllowDuringMaintenanceWindow para produção: combine com janelas de manutenção planejadas para controlar quando ocorrem interrupções em ambientes de produção.
  • Configurar Block durante períodos críticos: bloqueie temporariamente operações disruptivas durante eventos de alto tráfego, lançamentos de produtos ou resposta a incidentes. Não use Block indefinidamente. Embora Block seja apropriado para congelamentos de curto prazo (eventos planejados, resposta a incidentes).
  • Permitir flexibilidade na não produção: use Allow em ambientes de desenvolvimento e teste em que a iteração rápida é mais importante do que a estabilidade.
  • Comunicar alterações de política: verifique se sua equipe entende a política atual e sabe quando as operações podem ser bloqueadas.
  • Planeje as janelas de manutenção adequadamente: dimensione as janelas de manutenção para acomodar as operações que você precisa executar.
  • Comportamento da política de teste: valide as configurações de política em ambientes de não produção antes de aplicá-las a clusters de produção.
  • Monitorar operações bloqueadas: acompanhe quando as operações são bloqueadas para otimizar seu agendamento de manutenção.