Partilhar via

Patch do Serviço Kubernetes do Azure e diretrizes de atualização

  • Artigo

Esta seção do guia de operações do dia 2 do Serviço Kubernetes do Azure (AKS) descreve estratégias de aplicação de patches e atualização para nós de trabalho do AKS e versões do Kubernetes. Como operador de cluster, você precisa ter um plano para manter seus clusters atualizados e monitorar as alterações e descontinuações da API do Kubernetes ao longo do tempo.

Antecedentes e tipos de atualizações

Existem três tipos de atualizações para o AKS, cada uma com base na próxima:

Tipo de atualização Frequência da atualização Manutenção planeada suportada Métodos de operação suportados Destino Link para Documentação
Patches de segurança do sistema operacional do nó Noturno Sim Automático (semanal), manual/não gerenciado (noturno) Nó Imagens de nó de atualização automática
Atualizações da versão da imagem do nó Linux: Semanal
Windows: Mensal		 Sim Automático, manual Conjunto de nós Atualização da imagem do nó AKS
Atualizações da versão (cluster) do Kubernetes Trimestral Sim Automático, manual Pool de clusters e nós Atualização do cluster AKS

Tipos de atualização

  • Patches de segurança do sistema operacional do nó (somente Linux). Para nós Linux, o Canonical Ubuntu e o Azure Linux disponibilizam patches de segurança do sistema operacional uma vez por dia. A Microsoft testa e agrupa esses patches nas atualizações semanais das imagens de nós.

  • Atualizações semanais para imagens de nós. O AKS fornece atualizações semanais para imagens de nós. Essas atualizações incluem os patches de segurança mais recentes do sistema operacional e do AKS, correções de bugs e aprimoramentos. As atualizações de nó não alteram a versão do Kubernetes. As versões são formatadas por data (por exemplo, 202311.07.0) para Linux e por compilação e data do sistema operacional Windows Server (por exemplo, 20348.2113.231115) para Windows. Para obter mais informações, consulte Status de liberação do AKS.

  • Lançamentos trimestrais do Kubernetes. O AKS fornece atualizações trimestrais para versões do Kubernetes. Essas atualizações permitem que os usuários do AKS aproveitem os recursos e aprimoramentos mais recentes do Kubernetes. Eles incluem patches de segurança e atualizações de imagem de nó. Para obter mais informações, consulte Versões suportadas do Kubernetes no AKS.

Considerações pré-atualização

Impacto geral do cluster

  • As atualizações in-loco (nó e cluster) afetam o desempenho do seu ambiente Kubernetes enquanto estão em andamento. Você pode minimizar esse efeito por meio da configuração adequada de orçamentos de interrupção de pod, configuração de aumento de nó e planejamento adequado.
  • O uso de uma estratégia de atualização azul/verde em vez da atualização no local elimina qualquer impacto no desempenho do cluster, mas aumenta o custo e a complexidade.
  • Independentemente da sua estratégia de atualização e aplicação de patches, você precisa ter um processo robusto de teste e validação para seu cluster. Corrija e atualize ambientes inferiores primeiro e execute uma validação pós-manutenção para verificar a integridade do cluster, do nó, da implantação e do aplicativo.

Práticas recomendadas de carga de trabalho do AKS

Para garantir o bom funcionamento do cluster AKS durante a manutenção, siga estas práticas recomendadas:

  • Defina orçamentos de interrupção de pod (PDBs). Configurar orçamentos de interrupção de pod para suas implantações é essencial. Os PDBs impõem um número mínimo de réplicas de aplicativos disponíveis para garantir a funcionalidade contínua durante eventos de interrupção. Os PDBs ajudam a manter a estabilidade do cluster durante falhas de manutenção ou de nó.

    Aviso

    PDBs mal configurados podem bloquear o processo de atualização porque a API do Kubernetes impede o cordão e a drenagem necessários que ocorrem com uma atualização de imagem de nó contínua. Além disso, se muitos pods forem movidos simultaneamente, pode ocorrer uma interrupção do aplicativo. A configuração do PDB atenua esse risco.

  • Verifique os limites de computação e rede disponíveis. Verifique os limites de computação e rede disponíveis em sua assinatura do Azure por meio da página de cota no portal do Azure ou usando o comando az quota. Verifique os recursos de computação e rede, especialmente vCPUs de VM para seus nós, e o número de máquinas virtuais e conjuntos de dimensionamento de máquinas virtuais. Se você estiver perto de um limite, solicite um aumento de cota antes de atualizar.
  • Verifique o espaço IP disponível nas sub-redes do nó. Durante as atualizações, nós de surto extra são criados em seu cluster e pods são movidos para esses nós. É importante que você monitore o espaço de endereço IP nas sub-redes do nó para garantir que haja espaço de endereço suficiente para que essas alterações ocorram. Diferentes configurações de rede do Kubernetes têm requisitos de IP diferentes. Como ponto de partida, analise estas considerações:
    • Durante uma atualização, o número de IPs de nó aumenta de acordo com o seu valor de surto. (O valor mínimo de aumento é 1.)
    • Os clusters baseados no Azure CNI atribuem endereços IP a pods individuais, portanto, precisa haver espaço IP suficiente para a movimentação de pods.
    • O cluster continua a operar durante as atualizações. Certifique-se de que há espaço IP suficiente para permitir o dimensionamento do nó (se estiver ativado).
  • Configure vários ambientes. Recomendamos que você configure ambientes separados, como desenvolvimento, preparação e produção, para permitir que você teste e valide as alterações antes de implementá-las na produção.
  • Ajuste os valores de atualização de surto. Por padrão, o AKS tem um valor de aumento de 1, o que significa que um nó extra é criado de cada vez como parte do processo de atualização. Você pode aumentar a velocidade de uma atualização do AKS aumentando esse valor. 33% de aumento é o valor máximo recomendado para cargas de trabalho sensíveis a interrupções. Para obter mais informações, consulte Personalizar atualização de aumento de aumento de nó.
  • Ajuste o tempo limite de drenagem do nó. O tempo limite de drenagem do nó especifica a quantidade máxima de tempo que um cluster aguardará ao tentar reagendar pods em um nó que está sendo atualizado. O valor padrão para isso é 30 minutos. Para cargas de trabalho que lutam para reagendar pods, pode ser útil ajustar esse valor padrão.
  • Planeje e agende janelas de manutenção. Os processos de atualização podem afetar o desempenho geral do cluster Kubernetes. Agende processos de atualização in-loco fora das janelas de pico de uso e monitore o desempenho do cluster para garantir o dimensionamento adequado, especialmente durante os processos de atualização.
  • Verifique outras dependências no cluster. Os operadores do Kubernetes geralmente implantam outras ferramentas no cluster do Kubernetes como parte das operações, como escaladores KEDA, Dapr e malhas de serviço. Ao planejar seus processos de atualização, verifique as notas de versão de todos os componentes que você está usando para garantir a compatibilidade com a versão de destino.

Gerenciando atualizações semanais para imagens de nó

A Microsoft cria uma nova imagem de nó para nós AKS aproximadamente uma vez por semana. Uma imagem de nó contém patches de segurança atualizados do sistema operacional, atualizações do kernel do sistema operacional, atualizações de segurança do Kubernetes, versões atualizadas de binários como kubelet e atualizações de versão de componentes listadas nas notas de versão.

Quando uma imagem de nó é atualizada, uma ação de cordão e drenagem é acionada nos nós do pool de nós de destino:

  • Um nó com a imagem atualizada é adicionado ao pool de nós. O número de nós adicionados ao mesmo tempo é governado pelo valor de aumento.
  • Dependendo do valor do surto, um lote de nós existentes é isolado e drenado. O cordão garante que o nó não programe pods. A drenagem remove seus pods e os agenda para outros nós.
  • Depois que esses nós são totalmente drenados, eles são removidos do pool de nós. Os nós atualizados adicionados pelo surto os substituem.
  • Esse processo é repetido para cada lote restante de nós que precisa ser atualizado no pool de nós.

Um processo semelhante ocorre durante uma atualização de cluster.

Atualizações automáticas de imagem de nó

De um modo geral, a maioria dos clusters deve usar o canal de NodeImage atualização. Este canal fornece um VHD de imagem de nó atualizado semanalmente e é atualizado de acordo com a janela de manutenção do cluster.

Os canais disponíveis incluem o seguinte:

  • None. Nenhuma atualização é aplicada automaticamente.
  • Unmanaged. As atualizações do Ubuntu e do Azure Linux são aplicadas pelo sistema operacional todas as noites. As reinicializações devem ser gerenciadas separadamente. A AKS não é capaz de testar isso nem controlar a cadência disso.
  • SecurityPatch. Patches de segurança do sistema operacional que são testados pelo AKS, totalmente gerenciados e aplicados com práticas de implantação seguras. Ele não contém nenhuma correção de bugs do sistema operacional, apenas atualizações de segurança.
  • NodeImage. O AKS atualiza os nós com um VHD recém-corrigido contendo correções de segurança e correções de bugs em uma cadência semanal. Isso é totalmente testado e implantado com práticas de implantação seguras. Para obter informações em tempo real sobre imagens de nó atualmente implantadas, consulte Atualizações de imagens de nó AKS.

Para entender as cadências padrão sem uma janela de manutenção estabelecida, consulte Atualizar propriedade e cadência.

Se você escolher o canal de Unmanaged atualização, você precisa gerenciar o processo de reinicialização usando uma ferramenta como kured. Unmanaged não vem com práticas de implantação seguras fornecidas pelo AKS e não funcionará em janelas de manutenção. Se você escolher o canal de atualização, as SecurityPatch atualizações poderão ser aplicadas semanalmente. Esse nível de patch requer que os VHDs sejam armazenados em seu grupo de recursos, o que incorre em uma carga nominal. Controle quando o SecurityPatch é aplicado definindo um apropriado aksManagedNodeOSUpgradeSchedule que se alinha a uma cadência que funcione melhor para sua carga de trabalho. Para obter mais informações, consulte Criando uma janela de manutenção. Se você também precisa de correções de bugs que normalmente vêm com novas imagens de nó (VHD), então você precisa escolher o NodeImage canal em vez de SecurityPatch.

Como prática recomendada, use o NodeImage canal de atualização e configure uma aksManagedNodeOSUpgradeSchedule janela de manutenção para um momento em que o cluster esteja fora das janelas de pico de uso. Consulte Criando uma janela de manutenção para atributos que você pode usar para configurar a janela de manutenção de cluster. Os principais atributos são:

  • name. Use aksManagedNodeOSUpgradeSchedule para atualizações do sistema operacional do nó.
  • utcOffset. Configure o fuso horário.
  • startTime. Defina a hora de início da janela de manutenção.
  • dayofWeek. Defina os dias da semana para a janela. Por exemplo, Saturday.
  • schedule. Defina a frequência da janela. Para NodeImage atualizações, recomendamos weeklyo .
  • durationHours. Defina esse atributo para pelo menos quatro horas.

Este exemplo define uma janela de manutenção semanal para 20h00, horário do leste, aos sábados:

az aks maintenanceconfiguration add -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule --utc-offset=-05:00 --start-time 20:00 --day-of-week Saturday --schedule-type weekly --duration 4

Para obter mais exemplos, consulte Adicionar uma configuração de janela de manutenção com a CLI do Azure.

Idealmente, essa configuração seria implantada como parte da implantação de infraestrutura como código do cluster.

Você pode verificar se há janelas de manutenção configuradas usando a CLI do Azure:

az aks maintenanceconfiguration list -g <ResourceGroupName> --cluster-name <AKSClusterName>

Você também pode verificar os detalhes de uma janela de manutenção específica usando a CLI:

az aks maintenanceconfiguration show -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule

Se uma janela de manutenção de cluster não estiver configurada, as atualizações de imagem do nó ocorrerão quinzenalmente. Tanto quanto possível, a manutenção do AKS ocorre dentro da janela configurada, mas o tempo de manutenção não é garantido.

Importante

Se você tiver um pool de nós com um grande número de nós, mas ele não estiver configurado com aumento de nó, o evento de atualização automática pode não ser acionado. As imagens de nó em um pool de nós só serão atualizadas enquanto o tempo total estimado de atualização estiver dentro de 24 horas.

Nessa situação, você pode considerar um dos seguintes:

  • dividir nós em pools de nós diferentes se sua cota de vCPU estiver quase cheia e você não puder aumentar a cota de vCPU
  • configurando o aumento do nó para diminuir o tempo de atualização estimado se sua cota de vCPU for suficiente

Você pode verificar o status dos eventos de atualização por meio de seus logs de atividade do Azure ou revisando os logs de recursos em seu cluster.

Você pode Assinar eventos do Serviço Kubernetes do Azure (AKS) com a Grade de Eventos do Azure, que inclui eventos de atualização do AKS. Esses eventos podem alertá-lo quando uma nova versão do Kubernetes estiver disponível e ajudar a rastrear as alterações de status do nó durante os processos de atualização.

Você também pode gerenciar o processo de atualização semanal usando as Ações do GitHub. Esse método fornece um controle mais granular do processo de atualização.

Processo manual de atualização do nó

Você pode usar o comando kubectl describe nodes para determinar a versão do kernel do sistema operacional e a versão da imagem do sistema operacional dos nós em seu cluster:

kubectl describe nodes <NodeName>

Exemplo de saída (truncado):

System Info:
  Machine ID:                 bb2e85e682ae475289f2e2ca4ed6c579
  System UUID:                6f80de9d-91ba-490c-8e14-9e68b7b82a76
  Boot ID:                    3aed0fd5-5d1d-4e43-b7d6-4e840c8ee3cf
  Kernel Version:             5.15.0-1041-azure
  OS Image:                   Ubuntu 22.04.2 LTS
  Operating System:           linux
  Architecture:               arm64
  Container Runtime Version:  containerd://1.7.1+azure-1
  Kubelet Version:            v1.26.6
  Kube-Proxy Version:         v1.26.6

Use o comando Azure CLI az aks nodepool list para determinar as versões de imagem de nó dos nós em um cluster:

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,NodeImageVersion:nodeImageVersion}" --output table

Saída de exemplo:

Name       NodeImageVersion
---------  ---------------------------------------------
systempool  AKSUbuntu-2204gen2containerd-202307.12.0
usernodepool  AKSUbuntu-2204gen2arm64containerd-202307.12.0

Use az aks nodepool get-upgrades para determinar a versão mais recente da imagem de nó disponível para um pool de nós específico:

az aks nodepool get-upgrades \
   --resource-group <ResourceGroupName> \
   --cluster-name <AKSClusterName> \
   --nodepool-name <NodePoolName> --output table

Saída de exemplo:

KubernetesVersion    LatestNodeImageVersion                         Name     OsType
-------------------  ---------------------------------------------  -------  --------
1.26.6               AKSUbuntu-2204gen2arm64containerd-202308.10.0  default  Linux

Atualizações de cluster

A comunidade Kubernetes lança versões secundárias do Kubernetes aproximadamente a cada três meses. Para mantê-lo informado sobre novas versões e lançamentos do AKS, a página de notas de lançamento do AKS é atualizada regularmente. Você também pode assinar o feed RSS do GitHub AKS, que fornece atualizações em tempo real sobre alterações e aprimoramentos.

O AKS segue uma política de suporte N - 2 , o que significa que o suporte total é fornecido para a versão mais recente (N) e duas versões secundárias anteriores. O suporte limitado à plataforma é oferecido para a terceira versão secundária anterior. Para obter mais informações, consulte a política de suporte do AKS.

Para garantir que seus clusters AKS permaneçam suportados, você precisa estabelecer um processo contínuo de atualização de cluster. Esse processo envolve o teste de novas versões em ambientes inferiores e o planejamento da atualização para produção antes que a nova versão se torne o padrão. Essa abordagem pode manter a previsibilidade em seu processo de atualização e minimizar interrupções nos aplicativos. Para obter mais informações, veja Atualizar um cluster do AKS.

Se o cluster exigir um ciclo de atualização mais longo, use as versões do AKS que suportam a opção Long Term Support (LTS). Se você habilitar a opção LTS, a Microsoft fornecerá suporte estendido para versões do Kubernetes por dois anos, o que permitirá um ciclo de atualização mais prolongado e controlado. Para obter mais informações, consulte Versões suportadas do Kubernetes no AKS.

Uma atualização de cluster inclui uma atualização de nó e usa um processo de cordão e drenagem semelhante.

Antes de atualizar

Como prática recomendada, você deve sempre atualizar e testar em ambientes mais baixos para minimizar o risco de interrupção na produção. As atualizações de cluster exigem testes extras porque envolvem alterações de API, o que pode afetar as implantações do Kubernetes. Os seguintes recursos podem ajudá-lo no processo de atualização:

  • Pasta de trabalho AKS para APIs obsoletas. Na página de visão geral do cluster no portal do Azure, você pode selecionar Diagnosticar e resolver problemas, ir para a categoria Criar, Atualizar, Excluir e Dimensionar e selecionar Descontinuações da API do Kubernetes. Isso executa uma pasta de trabalho que verifica se há versões de API preteridas que estão sendo usadas no cluster. Para obter mais informações, consulte Remover o uso de APIs obsoletas.
  • Página de notas de lançamento do AKS. Esta página fornece informações abrangentes sobre novas versões e lançamentos do AKS. Reveja estas notas para se manter informado sobre as últimas atualizações e alterações.
  • Página de notas de lançamento do Kubernetes. Esta página fornece informações detalhadas sobre as versões mais recentes do Kubernetes. Preste especial atenção às notas de atualização urgentes, que destacam informações críticas que podem afetar seu cluster AKS.
  • Componentes AKS quebrando alterações por versão. Esta tabela fornece uma visão geral abrangente das alterações de quebra nos componentes do AKS, por versão. Ao consultar este guia, você pode resolver proativamente quaisquer possíveis problemas de compatibilidade antes do processo de atualização.

Além desses recursos da Microsoft, considere o uso de ferramentas de código aberto para otimizar o processo de atualização do cluster. Uma dessas ferramentas é o plutão Fairwinds, que pode verificar suas implantações e gráficos Helm em busca de APIs do Kubernetes obsoletas. Essas ferramentas podem ajudá-lo a garantir que seus aplicativos permaneçam compatíveis com as versões mais recentes do Kubernetes.

Processo de atualização de versão

Para verificar quando seu cluster requer uma atualização, use az aks get-upgrades para obter uma lista de versões de atualização disponíveis para seu cluster AKS. Determine a versão de destino do cluster a partir dos resultados.

Eis um exemplo:

az aks get-upgrades \
   --resource-group <ResourceGroupName> --name <AKSClusterName> --output table

Saída de exemplo:

MasterVersion  Upgrades
-------------  ---------------------------------
1.26.6         1.27.1, 1.27.3

Verifique as versões do Kubernetes dos nós em seus pools de nós para determinar os pools que precisam ser atualizados:

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,k8version:orchestratorVersion}" --output table

Saída de exemplo:

Name          K8version
------------  ------------
systempool    1.26.6
usernodepool  1.26.6

Atualização manual

Para minimizar interrupções e ajudar a garantir uma atualização suave para seu cluster AKS, siga esta abordagem de atualização:

  1. Atualize o plano de controle AKS. Comece atualizando o plano de controle AKS. Esta etapa envolve a atualização dos componentes do plano de controle responsáveis pelo gerenciamento e orquestração do cluster. Atualizar o plano de controle primeiro ajuda a garantir compatibilidade e estabilidade antes de atualizar os pools de nós individuais.
  2. Atualize o pool de nós do sistema. Depois de atualizar o plano de controle, atualize o pool de nós do sistema no cluster AKS. Os pools de nós consistem nas instâncias de máquina virtual que executam as cargas de trabalho do aplicativo. A atualização dos pools de nós separadamente permite uma atualização controlada e sistemática da infraestrutura subjacente que suporta seus aplicativos.
  3. Atualize os pools de nós do usuário. Depois de atualizar o pool de nós do sistema, atualize todos os pools de nós de usuário no cluster AKS.

Seguindo essa abordagem, você pode minimizar interrupções durante o processo de atualização e manter a disponibilidade de seus aplicativos. Estes são os passos detalhados:

  1. Execute o comando az aks upgrade com o --control-plane-only sinalizador para atualizar apenas o plano de controle do cluster e não os pools de nós do cluster:

    az aks upgrade \
   --resource-group <ResourceGroupName> --name <AKSClusterName> \
   --control-plane-only \
   --kubernetes-version <KubernetesVersion>

  2. Execute az aks nodepool upgrade para atualizar pools de nós para a versão de destino:

    az aks nodepool upgrade \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> --name <NodePoolName> \
   --no-wait --kubernetes-version <KubernetesVersion>

    Durante a atualização do pool de nós, o AKS cria um nó de sobretensão, corda e drena pods no nó que está sendo atualizado, cria uma nova imagem do nó e, em seguida, descorda os pods. Em seguida, esse processo se repete para quaisquer outros nós no pool de nós.

Você pode verificar o status do processo de atualização executando kubectl get events. Para obter informações sobre como solucionar problemas de atualização de cluster, consulte a documentação de solução de problemas do AKS.

Inscrever clusters em canais de versão de atualização automática

O AKS também oferece uma solução de atualização automática de cluster para manter seu cluster atualizado. Se você usar essa solução, deverá emparelhá-la com uma janela de manutenção para controlar o tempo das atualizações. A janela de atualização deve ser de quatro horas ou mais. Quando você inscreve um cluster em um canal de versão, a Microsoft gerencia automaticamente a versão e a cadência de atualização para o cluster e seus pools de nós.

A atualização automática do cluster oferece diferentes opções de canal de versão. Aqui está uma configuração recomendada de ambiente e canal de versão:

Environment Canal de atualização Description
Produção stable Para estabilidade e maturidade da versão, use o canal estável ou regular para cargas de trabalho de produção.
Preparação, testes, desenvolvimento O mesmo que a produção Para garantir que seus testes sejam indicativos da versão para a qual você atualizará seu ambiente de produção, use o mesmo canal de lançamento da produção.
Versão canary rapid Para testar as versões mais recentes do Kubernetes e os novos recursos ou APIs do AKS, use o rapid canal. Você pode melhorar seu tempo de comercialização quando a versão em é promovida para o canal que rapid você está usando para produção.

Considerações

A tabela a seguir descreve as características de vários cenários de atualização e aplicação de patches do AKS:

Cenário Iniciado pelo utilizador Atualização do Kubernetes Atualização do kernel do SO Atualização da imagem do nó
Correção de segurança No Não Sim, após a reinicialização Sim
Criação de clusters Sim Talvez Sim, se uma imagem de nó atualizada usar um kernel atualizado Sim, em relação a um cluster existente se uma nova versão estiver disponível
Atualização do Kubernetes do plano de controle Sim Sim No Não
Atualização do Kubernetes do pool de nós Sim Sim Sim, se uma imagem de nó atualizada usar um kernel atualizado Sim, se uma nova versão estiver disponível
Escalonamento do pool de nós Sim No No Não
Atualização da imagem do nó Sim No Sim, se uma imagem de nó atualizada usar um kernel atualizado Sim
Atualização automática de cluster Não Sim Sim, se uma imagem de nó atualizada usar um kernel atualizado Sim, se uma nova versão estiver disponível
  • Um patch de segurança do sistema operacional aplicado como parte de uma atualização de imagem de nó pode instalar uma versão posterior do kernel do que a criação de um novo cluster instalaria.
  • A expansão do pool de nós usa o modelo atualmente associado ao conjunto de escala da máquina virtual. Os kernels do sistema operacional são atualizados quando patches de segurança são aplicados e os nós são reinicializados.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

  • Anthony Nevico - Brasil | Arquiteto Principal de Soluções na Nuvem

Outros contribuidores:

  • Rishabh Saha - Brasil | Arquiteto de Soluções Principal
  • Paolo Salvatori - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
  • Ali Yousefi - Brasil | Arquiteto de Soluções Cloud

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos