Share 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 do Kubernetes do Azure (AKS) descreve estratégias de aplicação de patches e atualização para nós de trabalho 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 depreciações da API do Kubernetes ao longo do tempo.

Plano de fundo 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 de atualização Manutenção planejada com suporte Métodos operacionais com suporte Destino Link para a documentação
Patches de segurança do sistema operacional do nó De noite Yes Automático (semanal), manual/não gerenciado (noturno) Nó Imagens de nó de atualização automática
Atualizações de versão de imagem de nó Linux: Semanal
Windows: Mensal		 Sim Automático, manual Pool de nós Atualização da imagem do nó do AKS
Atualizações de versão (cluster) do Kubernetes Trimestral Yes Automático, manual Cluster e pool de nós Upgrade de cluster do AKS

Tipos de atualizações

  • Patches de segurança do sistema operacional do nó (somente Linux). Para nós do Linux, o Canonical Ubuntu e 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 para imagens de nó.

  • 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 AKS, correções de bugs e aprimoramentos. As atualizações de nós 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 Versões do AKS.

  • Versões 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, confira Versões do Kubernetes compatíveis no AKS.

Considerações sobre pré-atualização

Impacto geral do cluster

  • As atualizações in-loco (nó e cluster) afetam o desempenho do 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 surto de nó e planejamento adequado.
  • O uso de uma estratégia de atualização azul/verde em vez de atualizar 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 o cluster, o nó, a implantação e a integridade 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:

  • Definir orçamentos de interrupção do 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 o dreno necessários que ocorrem com uma atualização de imagem de nó contínua. Além disso, se muitos pods forem movidos simultaneamente, poderá ocorrer uma interrupção do aplicativo. A configuração do PDB reduz 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ós. Durante as atualizações, nós de surto extra são criados no cluster e os pods são movidos para esses nós. É importante que você monitore o espaço de endereço IP nas sub-redes dos nós para garantir que haja espaço de endereço suficiente para que essas alterações ocorram. Diferentes configurações de redes 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ós aumenta de acordo com o valor do surto. (O valor mínimo de surto é 1.)
    • Os clusters baseados no CNI do Azure atribuem endereços IP a pods individuais, portanto, é necessário que haja espaço IP suficiente para a movimentação do pod.
    • O cluster continua a operar durante as atualizações. Certifique-se de que haja espaço IP suficiente para permitir o dimensionamento de nó (se estiver habilitado).
  • 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 por 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 Opções de atualização para AKS.
  • Ajuste o tempo limite de esgotamento do nó.O tempo limite de esgotamento do nó especifica a quantidade máxima de tempo que um cluster aguardará ao tentar reagendar pods em um nó que está atualizando. O valor padrão é 30 minuto. Para cargas de trabalho que tentam reagendar pods, pode ser útil ajustar esse valor padrão.
  • Planejar e programar janelas de manutenção. Os processos de atualização podem afetar o desempenho geral do cluster do 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ê estiver usando para garantir a compatibilidade com a versão de destino.

Gerenciando atualizações semanais para imagens de nós

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 esgotamento é 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 por vez é controlado pelo valor de surto.
  • Um dos nós existentes está isolado e esgotado. O cordão garante que o nó não programe pods. O esgotamento remove seus pods e os agenda para outros nós.
  • Depois que o nó é totalmente esgotado, ele é removido do pool de nós. O nó atualizado adicionado pelo surto o substitui.
  • Esse processo é repetido para cada nó que precisa ser atualizado no pool de nós.

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

Atualizações automáticas de nós

De modo geral, a maioria dos clusters deve usar o NodeImage canal de atualização. Esse 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 Linux do Azure são aplicadas pelo sistema operacional todas as noites. As reinicializações devem ser gerenciadas separadamente. 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 bug do sistema operacional, apenas atualizações de segurança.
  • NodeImage. O AKS atualizará os nós com um VHD com patch recém aplicado contendo correções de segurança e correções de bugs semanalmente. 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 [seção Imagens de nós AKS no rastreador de versão][rastreador de liberação].

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

Se você escolher o Unmanaged canal de atualização, precisará gerenciar o processo de reinicialização usando uma ferramenta como kured. Unmanaged não vem com práticas de implantação segura fornecidas pelo AKS e não funcionará em janelas de manutenção. Se você escolher o SecurityPatch canal de atualização, as atualizações poderão ser aplicadas com a mesma frequência semanal. Esse nível de patch requer que os VHDs sejam armazenados em seu grupo de recursos, o que incorre em uma cobrança nominal. Controle quando o SecurityPatch é aplicado definindo um aksManagedNodeOSUpgradeSchedule apropriado 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 precisar de correções de bugs que vêm normalmente com novas imagens de nós (VHD), então você precisará escolher o NodeImage canal em vez de SecurityPatch.

Como prática recomendada, use o NodeImage canal de atualização e configure uma janela de manutenção aksManagedNodeOSUpgradeSchedule 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ê possa usar para configurar a janela de manutenção do cluster. Os principais atributos são:

  • name. Use aksManagedNodeOSUpgradeSchedule para atualizações do sistema operacional do nó.
  • utcOffset. Configurar 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 weekly.
  • durationHours. Defina esse atributo como pelo menos quatro horas.

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

az aks maintenanceconfiguration add -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule --utcOffset -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.

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

Você pode Assinar eventos do Serviço de 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 controlar 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 de atualização manual 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

Exemplo de saída:

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 disponível da imagem do nó para um pool de nós específico:

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

Exemplo de saída:

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

Atualizações do cluster

A comunidade Kubernetes libera 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 versão 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 saber mais, consulte 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 testar novas versões em ambientes inferiores e planejar a 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 as interrupções nos aplicativos. Para obter mais informações, confira Atualizar um cluster do AKS.

Se o cluster exigir um ciclo de atualização mais longo, use versões do AKS que oferecem suporte à opção LTS (Suporte de Longo Prazo). 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, confira Versões do Kubernetes compatíveis 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 inferiores 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 preteridas. 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 preteriçõ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 versão do AKS. Esta página fornece informações abrangentes sobre novas versões e lançamentos do AKS. Revise estas notas para se manter informado sobre as atualizações e alterações mais recentes.
  • Página de notas de versão do Kubernetes. Esta página fornece informações detalhadas sobre as versões mais recentes do Kubernetes. Preste atenção especial à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 Fairwinds pluto, 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

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

Veja um exemplo:

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

Exemplo de saída:

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

Verifique as versões 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

Exemplo de saída:

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

Atualizando manualmente

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

  1. Atualizar o plano de controle do AKS. Comece atualizando o plano de controle do AKS. Esta etapa envolve a atualização dos componentes do plano de controle responsáveis por gerenciar e orquestrar o cluster. Atualizar o plano de controle primeiro ajuda a garantir a compatibilidade e a 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 oferece suporte aos seus aplicativos.
  3. Atualizar pools de nós de usuário. Depois de atualizar o pool de nós do sistema, atualize todos os pools de nós do usuário no cluster AKS.

Seguindo essa abordagem, você pode minimizar as interrupções durante o processo de atualização e manter a disponibilidade de seus aplicativos. Aqui estão as etapas detalhadas:

  1. Execute o comando az aks upgrade com o sinalizador --control-plane-only 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 surto, cordões e pods de drenos no nó que está sendo atualizado, recria imagens do nó e, em seguida, cancela os drenos dos pods. 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.

Registrar 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ê registra um cluster em um canal de versão, a Microsoft gerencia automaticamente a cadência de versão e atualização para o cluster e seus pools de nós.

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

Ambiente Canal de atualização Descrição
Produção stable Para estabilidade e maturidade de versão, use o canal estável ou regular para cargas de trabalho de produção.
Preparação, teste, desenvolvimento O mesmo que produção Para garantir que os testes sejam indicativos da versão para a qual você atualizará seu ambiente de produção, use o mesmo canal de lançamento que a produção.
Canário rapid Para testar as versões mais recentes do Kubernetes e os novos recursos ou APIs do AKS, use o canal rapid. Você poderá melhorar seu tempo de lançamento no mercado quando a versão em rapid for promovida para o canal que 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 Usuário iniciado Atualização do Kubernetes Atualização do kernel do sistema operacional Atualização da imagem do nó
Aplicação de patch de segurança Não Não Sim, após a reinicialização Yes
Criação do cluster Yes 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 Não Não
Atualização do Kubernetes do pool de nós Sim Yes Sim, se uma imagem de nó atualizada usar um kernel atualizado Sim, se uma nova versão estiver disponível
Expansão do pool de nós Sim Não No Não
Atualização da imagem do nó Sim Não Sim, se uma imagem de nó atualizada usar um kernel atualizado Yes
Atualização automática do 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 dimensionamento da máquina virtual. Os kernels do sistema operacional são atualizados quando os patches de segurança são aplicados e os nós são reinicializados.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

Outros colaboradores:

Para ver perfis não públicos no LinkedIn, entre no LinkedIn.

Próximas etapas