Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
À 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ó:
- Escopo: a política se aplica a operações iniciadas pelo usuário que exigem a reimagem do nó, não à manutenção do sistema iniciada pelo AKS. Para obter mais 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
Blockimpede determinadas atualizações do cluster. Para obter detalhes, consulte Operações cobertas pela política de interrupção do nó. 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
AllowDuringMaintenanceWindowpolítica requer que umaaksManagedNodeOSUpgradeSchedulejanela 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 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
artifactSourceentreDirecteCache, ou alterar ocontainerRegistryId(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
AllowDuringMaintenanceWindowpara produção: combine com janelas de manutenção planejadas para controlar quando ocorrem interrupções em ambientes de produção. -
Configurar
Blockdurante 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 useBlockindefinidamente. EmboraBlockseja apropriado para congelamentos de curto prazo (eventos planejados, resposta a incidentes). -
Permitir flexibilidade na não produção: use
Allowem 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 do Nó.
- Entenda a manutenção planejada no AKS.