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

Ao gerenciar e manter seus clusters do AKS, certas alterações de configuração exigem que os nós sejam recriados. 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, o AKS isola o nó (impedindo o agendamento de novos pods), remove os pods existentes (descartando-os e reagendando-os em outros nós disponíveis, respeitando os Orçamentos de Interrupção de Pods) e, em seguida, recria o 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 preciso sobre quando essas operações disruptivas podem prosseguir, ajudando você a equilibrar a necessidade de atualizações com a estabilidade operacional.

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

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

• Alinhe as operações disruptivas com suas 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ó.

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. Ao tentar uma operação que exige a recriação da imagem do 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 de Nó oferece suporte a três configurações:

Considerations

Considere os seguintes pontos ao usar a Política de Interrupção de Nó:

• Escopo: A política se aplica a operações iniciadas pelo usuário que exigem a recriação da imagem do nó, não à manutenção do sistema iniciada pelo AKS. Para obter detalhes, consulte Operações de recuperação não controladas pela Política de Interrupção do Nó.
• Operações bloqueadas: quando uma operação de interrupção é bloqueada, a chamada à API falha com uma mensagem de erro. Você precisa alterar a política ou aguardar a janela de manutenção.
• Manutenção de emergência: Azure reserva o direito de executar operações de manutenção urgentes ou críticas, independentemente da configuração da política.
• Planejamento de atualização: Definir a política como Block impede determinadas atualizações do cluster. Para obter detalhes, consulte Operações cobertas pela política de interrupção de nós. Planeje de acordo para garantir que você possa aplicar as atualizações necessárias quando necessário.
• Dependência da janela de manutenção: a AllowDuringMaintenanceWindow política requer que uma aksManagedNodeOSUpgradeSchedule janela de manutenção seja configurada. Para obter detalhes, consulte Usar a manutenção planejada para agendar e controlar atualizações para o cluster Serviço de Kubernetes do Azure.

Operações cobertas pela Política de Interrupção de Nós

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 as regras de rede que protegem e gerenciam a comunicação entre pods, você precisa reinstalar 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:

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 descreve as alterações no canal de atualização do sistema operacional do nó que acionam a reinstalação da imagem:

Habilitação de pilha dupla IPv6

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

A tabela a seguir descreve as atualizações de configuração de IP e pilha de rede que acionam a reimagem:

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:

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 de Nó aciona a reimagem quando você modifica qualquer uma das seguintes propriedades de configuração de 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 Interrupção de Nó aciona a reimagem quando você adiciona, remove ou atualiza certificados de CA 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 Interrupção de Nó aciona a reimagem 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 de Nó aciona a reimagem quando você modifica a configuração de uma zona DNS privada em um cluster privado.

Habilitação da Integração de 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 reimagem quando você habilita a Integração de VNet do Servidor de API em um cluster existente que não a utilizava anteriormente. Essa alteração corresponde à alteração da apiServerAccessProfile.enableVnetIntegration propriedade (internamente o privateConnectProfile.enabled campo) de false (ou não definido) para 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:

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. Elas acionam uma reimagem gradual 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 de Nó aciona a reimagem quando você modifica uma configuração de 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:

Alterações no Streaming de Artefatos

Você precisa instalar ou remover componentes de streaming de artefatos para habilitar a extração mais rápida de imagens de contêiner, transmitindo camadas de imagem sob demanda.

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

Atualizações de perfil do GMSA do Windows (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 dos pools de nós do Windows quando uma alteração no GMSA exige a aplicação de uma nova configuração de nó:

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 no CRG, portanto, o AKS deve recriar o pool de nós para associá-los à reserva.

A Política de Interrupção de Nó aciona a recriação quando você anexa um Grupo de Reserva de Capacidade a um pool de nós existente que ainda não tem um.

Operações cobertas pela Política de Interrupção de Nó no Kubernetes 1.37 e versões posteriores

No Kubernetes 1.37 e versões posteriores, a Política de Interrupção de Nó abrange as seguintes alterações de configuração que exigem a recriação da imagem do nó. No Kubernetes 1.36 e versões anteriores, você deve executar manualmente az aks nodepool upgrade com --node-image-only após fazer essas alterações de configuração para aplicá-las aos 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 de restrição do IMDS: habilitar ou desabilitar a restrição do Serviço de Metadados da Instância (IMDS) para bloquear o acesso do pod ao ponto de extremidade 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 planejado, mantenha-as intencionalmente fora do escopo da Política de Interrupção de Nós. 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ó.

• Atualizações de versão da imagem do nó: 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). Esta operação é 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 pool de nós, que aplica novos binários do Kubernetes, configuração atualizada do kubelet e configurações de 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 do pool de nós falha devido a uma 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 reverter 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 da imagem dos nós para aplicar as novas credenciais em 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.

Práticas recomendadas

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

• Use AllowDuringMaintenanceWindow para produção: combine com janelas de manutenção planejadas para controlar quando as interrupções ocorrem 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.

Conteúdo relacionado

• Saiba como configurar a Política de Interrupção de Nós.
• Entenda a manutenção planejada no AKS.