Política de interrupção de nó no Azure Kubernetes Service (AKS) (Pré-visualização)

À medida que gere e mantém os seus clusters AKS, certas alterações de configuração exigem que os nós sejam reimaginados. Esta operação de reimagem desencadeia uma atualização contínua que recria os nós. Durante uma operação de recriação da imagem, o AKS isola o nó (impede o agendamento de novos pods), drena o nó, escoando os pods existentes (expulsando-os e reagendando-os noutros nós disponíveis, respeitando os Pod Disruption Budgets), e depois recria a imagem do nó com a configuração atualizada. Este processo é uma recriação completa do nó, não uma reinicialização — a VM subjacente é recriada com uma nova imagem do sistema operativo. Embora volumes persistentes devidamente configurados (usando Azure Disks, Ficheiros do Azure ou outro armazenamento externo) não sejam afetados, quaisquer dados armazenados no armazenamento local e efémero do nó (como volumes EmptyDir ou caminhos locais) são permanentemente perdidos. Estas operações são necessárias para aplicar atualizações importantes, mas podem perturbar cargas de trabalho em execução e afetar a disponibilidade das aplicações. A Política de Disrupção de Nós dá-lhe controlo granular sobre quando estas operações disruptivas podem prosseguir, ajudando-o 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 Disrupção de Nós é uma configuração ao nível do cluster que regula quando podem ser executadas operações que requerem a recriação da imagem e a reimplementação dos nós. Funciona como um portal de controlo, permitindo-lhe:

• Alinhe as operações disruptivas com as suas janelas de manutenção.
• Bloqueie alterações de configuração durante períodos críticos para a empresa, permitindo ainda que as atualizações da imagem dos nós e as correções de segurança prossigam.
• Manter um comportamento previsível do cluster durante eventos de grande tráfego.

A política aplica-se a alterações de configuração iniciadas pelo utilizador que exijam a recriação dos nós, como a atualização de certificados de confiança personalizados da autoridade certificadora (CA), a modificação das definições do perfil de segurança ou a alteração da configuração do sistema operativo do nó.

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

Configura a política de interrupção dos nós ao nível do cluster através da propriedade nodeDisruptionProfile. Quando tenta efetuar uma operação que exige a reimagem do nó, o AKS verifica a definição atual da política:

• 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 usar AllowDuringMaintenanceWindow, o AKS verifica se a hora atual se enquadra na janela de manutenção configurada.
• Execução da operação ou bloqueio: A operação disruptiva para os nós prossegue se tal for permitido ou é rejeitada com uma mensagem de erro caso seja bloqueada.

Opções de política

A Política de Disrupção de Nós suporta três configurações de política:

Considerations

Tenha em mente as seguintes considerações ao utilizar a Política de Interrupção de Nós:

• Âmbito: A política aplica-se a operações iniciadas pelo utilizador que exijam reimagem de nós, não à manutenção do sistema iniciada pelo AKS. Para mais detalhes, consulte Operações de recuperação não controladas pela Política de Disrupção de Nodos.
• Operações bloqueadas: Quando uma operação disruptiva é bloqueada, a chamada API falha com uma mensagem de erro. Tens de mudar a apólice ou esperar pela janela de manutenção.
• Manutenção de emergência: A Azure reserva-se o direito de realizar operações de manutenção urgentes ou críticas, independentemente da definição da política.
• Planeamento de atualizações: Definir a política como Block impede determinadas atualizações do cluster. Para obter mais detalhes, consulte Operações abrangidas pela política de interrupção de nós. Planeie em conformidade para garantir que pode 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 detalhes, consulte Utilizar manutenção planeada para agendar e controlar atualizações para o seu cluster Azure Kubernetes Service.

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

Operações ao nível do cluster

Ativaçã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 assegurem e gerem a comunicação entre pods, é necessário recriar a imagem dos nós.

A tabela seguinte descreve as atualizações das políticas de rede que desencadeiam a reimagem:

Alterações ao canal de atualização do sistema operativo do nó

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

A tabela seguinte descreve alterações nos canais de atualização do sistema operativo dos nós que desencadeiam a reimagem:

Ativação de IPv6 dual-stack

Para suportar a comunicação em dual stack, os nós precisam de configurações IP de IPv4 e de IPv6 e de atualizações na pilha de rede (como regras do nftables).

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

Alterações no plano de dados do Cilium

É necessário instalar ou remover programas eBPF que tratam do processamento de pacotes ao nível do kernel.

A tabela seguinte descreve as alterações no plano de dados Cilium que desencadeiam a reimagem:

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

Todos os componentes dos nós (containerd, kubelet, serviços do sistema) necessitam da configuração atualizada do proxy aplicada em todo o sistema. Quando atualizas a configuração do proxy HTTP, o AKS reimageia automaticamente todos os pools de nós no cluster.

A Política de Interrupção de Nós desencadeia a reimagem quando modifica qualquer uma das seguintes propriedades de configuração do proxy HTTP ou realiza qualquer uma das seguintes operações:

• httpProxy: URL de proxy para ligações HTTP
• httpsProxy: URL Proxy para ligações HTTPS
• noProxy: Lista de destinos a excluir do proxy
• trustedCa: Certificado alternativo de CA codificado em Base64
• Ativar o proxy HTTP num cluster (com --enable-http-proxy)
• Desativar o proxy HTTP num cluster (com --disable-http-proxy)
• Reativar o proxy HTTP num cluster que anteriormente o tinha desativado

Atualizações personalizadas de certificados de CA

Tem de instalar novos certificados de CA no repositório de confiança do sistema operativo para que afetem a validação TLS de serviços internos e de registos privados.

A Política de disrupção dos nós desencadeia a reinstalação da imagem quando são adicionados, removidos ou atualizados certificados de CA personalizados.

Alterações na identidade de Kubelet

Deve aplicar novas credenciais de identidade à configuração do nó. Isto inclui a atribuição inicial da identidade, as atualizações da identidade e as redefinições do perfil do principal de serviço.

A Política de Interrupção de Nó desencadeia a reimagem quando atualiza uma identidade gerida ou uma identidade gerida atribuída pelo utilizador para o kubelet.

Alterações nas zonas do DNS Privado

Deve atualizar as definições do resolvedor DNS para resolver o endpoint do servidor privado de API usando a nova zona DNS.

A Política de Interrupção de Nós desencadeia a reimagem quando se modifica a configuração de uma zona DNS privada num cluster privado.

integração de VNet do API Server ativação

Tens de reconfigurar os nós para comunicarem com o servidor API através do IP interno do balanceador de carga que é projetado na sub-rede delegada.

A Política de Interrupção de Nós desencadeia a reimagem quando se ativa a integração do VNet do API Server num cluster existente que não a utilizava anteriormente. Esta alteração corresponde a alterar a apiServerAccessProfile.enableVnetIntegration propriedade (internamente o privateConnectProfile.enabled corpo) de false (ou não definido) para true:

Alterações no encaminhamento do host eBPF

É necessário instalar ou remover programas eBPF que ofereçam encaminhamento de pacotes de alto desempenho (modo de aceleração BpfVeth).

A tabela seguinte descreve alterações no encaminhamento do host eBPF que desencadeiam a reimagem:

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

Estas operações afetam apenas os pools específicos de nós em que faz alterações. Acionam uma reimagem faseada nesses pools de nós:

Atualizações do perfil DNS local

É necessário aplicar alterações ao serviço de cache DNS e às regras de encaminhamento DNS no nível do nó.

A Política de Interrupção de Nós desencadeia a reimagem quando se modifica a configuração de um perfil LocalDNS.

Alterações de segurança no Trusted Launch

Não podes alterar a configuração do firmware da VM e as definições do processo de arranque em VMs em execução. Estas alterações exigem que recries as VMs.

A tabela seguinte descreve as alterações de segurança do Trusted Launch que desencadeiam a reimagem:

Alterações no streaming de artefactos

É necessário instalar ou remover componentes de streaming de artefactos para permitir uma extração mais rápida de imagens do contentor através de camadas de imagem de streaming on-demand.

A tabela seguinte descreve alterações no streaming de artefactos que desencadeiam a reimagem:

Atualizações do perfil Windows GMSA (apenas conjuntos de nós do Windows)

Precisas de aplicar novas definições GMSA, configuração do servidor DNS e credenciais de união de domínio para integração do Active Directory nos nós do Windows.

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

Anexo ao Grupo de Reserva de Capacidade

Precisas de 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 estavam provisionados contra o CRG, por isso o AKS tem de reimaginar o pool de nós para os associar à reserva.

A Política de Interrupção de Nós desencadeia a reimagem quando associa um Grupo de Reserva de Capacidade a um pool de nós existente que ainda não tem um.

Operações ainda não abrangidas pela Política de Disrupção de Nodes

As seguintes alterações de configuração requerem a reimagem dos nós, mas ainda não estão abrangidas pela Política de Interrupção de Nós. Uma futura atualização de versão menor do Kubernetes irá abordar estas alterações, pois introduz novos comportamentos.
Depois de fazer estas alterações de configuração, deve executar az aks nodepool upgrade manualmente com --node-image-only para aplicar as alterações aos seus nós.

• Alterações na configuração do SSH: Alteração dos métodos de acesso ao SSH (SSH desativado, SSH baseado no Entra ID, ou SSH do Utilizador Local) ou atualização das chaves públicas do SSH em pools de nós.
• Alterações à restrição do IMDS: Ativação ou desativação da restrição do Instance Metadata Service (IMDS) para bloquear o acesso do pod ao endpoint IMDS.
• Alterações no perfil de bootstrap: Alterar o perfil de bootstrap, como alternar entre artifactSourceDirect e Cache, ou alterar o containerRegistryId (o Azure Container Registry usado para clusters isolados de rede).
• Alterações no tipo de saída: Modificação do tipo de conectividade de saída do cluster (loadBalancer, userDefinedRouting, managedNATGateway ou userAssignedNATGateway).

Operações de atualização não controladas pela Node Disruption Policy

A Política de Interrupção de Nós não controla as seguintes operações de atualização. Estas operações de atualização decorrem independentemente da sua definição de apólice. As atualizações são iniciadas pelo cliente ou iniciadas pelo AKS dentro das janelas de manutenção planeadas. Para permitir que estas operações prossigam conforme planeado, mantém-nas intencionalmente fora do âmbito da Política de Interrupção de Node. Além disso, se as operações abrangidas pela Política de Interrupção de Nó estiverem incluídas nas mesmas alterações de configuração que as atualizações, não serão regidas pela Política de Interrupção de Nó.

• Atualização da versão da imagem do nó: Atualização para uma nova versão da imagem do sistema operativo do nó (manualmente ou através de canais automáticos de atualização). Esta operação é a mais comum de reimagem e inclui patches de segurança, atualizações do sistema operativo e lançamentos de imagens de nós AKS.
• Atualizações da versão Kubernetes: Atualização da versão Kubernetes num pool de nós, que aplica novos binários Kubernetes, configuração atualizada do kubelet e alterações ao nível do sistema operativo.

Operações de recuperação não controladas pela Política de Disrupção dos Nós

A Política de Interrupção de Nós não controla as seguintes operações automatizadas de recuperação. Estas operações podem ocorrer independentemente da definição da sua política, para garantir a saúde e recuperação do cluster.

• Reversão da configuração do conjunto de nós: Quando uma operação de atualização de um conjunto de nós falha devido a uma configuração inválida ou a problemas de infraestrutura, o AKS reverte automaticamente para o último estado válido conhecido e recria a imagem dos nós para repor a configuração.
• Operações de restauro do cluster administrativo: Quando os engenheiros de suporte do Azure efetuam o restauro administrativo do cluster durante a resolução de incidentes, são recriadas as imagens dos nós para garantir a consistência entre o estado do plano de controlo e a configuração dos nós.
• Atualizações das credenciais de identidade de nós: O AKS atualiza periodicamente as credenciais de identidade dos nós para segurança e conformidade. Estas atualizações iniciadas pelo sistema desencadeiam a reimagem dos nós para aplicar as novas credenciais em todos os pools de nós.

Integração com manutenção planeada

A Política de interrupção de nós integra-se perfeitamente com as janelas de manutenção planeada do AKS. Quando definir a política para AllowDuringMaintenanceWindow, as operações disruptivas ficam alinhadas com a sua janela de manutenção aksManagedNodeOSUpgradeSchedule, garantindo que:

• As alterações ocorrem apenas durante as janelas de tempo aprovadas.
• As operações coordenam-se com outras manutenções programadas.
• As equipas estão cientes de quando podem ocorrer perturbações.

Esta integração proporciona uma abordagem abrangente para gerir alterações de cluster e minimizar o impacto nas cargas de trabalho em curso.

Melhores práticas

Ao implementar a Política de Interrupção dos Nós, considere estas recomendações:

• Utilize AllowDuringMaintenanceWindow para produção: Combine-o com janelas de manutenção planeadas para controlar quando ocorrem interrupções em ambientes de produção.
• Defina Block durante períodos críticos: Bloqueie temporariamente operações disruptivas durante eventos de tráfego intenso, lançamentos de produtos ou resposta a incidentes. Não uses Block indefinidamente. Embora Block seja apropriado para congelamentos de curto prazo (eventos planeados, resposta a incidentes).
• Permitir flexibilidade em não-produção: Utilização Allow em ambientes de desenvolvimento e testes onde a iteração rápida é mais importante do que a estabilidade.
• Comunique alterações às políticas: Certifique-se de que a sua equipa compreende a política atual e sabe quando as operações podem ser bloqueadas.
• Planeie as janelas de manutenção adequadamente: Dimensione as janelas de manutenção para acomodar as operações que precisa de realizar.
• Teste o comportamento das políticas: Valide as definições de políticas em ambientes não de produção antes de as aplicar a clusters de produção.
• Monitorize operações bloqueadas: Acompanhe quando as operações estão bloqueadas para otimizar o seu calendário de manutenção.

Conteúdo relacionado

• Aprenda a configurar a Política de Interrupção de Nodos.
• Compreenda a manutenção planeada no AKS.