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 de 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 suportada Métodos operacionais com suporte Destino Link para a documentação
Patches de segurança do sistema operacional do nó De noite Sim 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 Sim Automático, manual Cluster e pool de nós Atualização do cluster AKS

Tipos de atualização

  • Patches de segurança do Node OS (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 para imagens de nó.

  • Atualizações semanais para imagens de nó. 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ó 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 da versã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 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 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:

  • Definir 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 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áquina virtual. 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 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 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 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 há 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 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á atualizando. 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.
  • 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 estiver 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 por vez é governado pelo valor de surto.
  • Um dos nós existentes está isolado e drenado. O cordão garante que o nó não programe pods. A drenagem remove suas vagens e as agenda para outros nós.
  • Depois que o nó é totalmente drenado, 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 imagem de nó

De modo geral, a maioria dos clusters deve usar o canal de NodeImage 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.
  • SecurityPatch. Os patches de segurança noturnos são implantados como uma atualização de imagem do sistema operacional.
  • NodeImage. Patches AKS semanais e patches de segurança noturnos são combinados.

Se você escolher o canal de atualização, precisará gerenciar o processo de Unmanaged reinicialização usando uma ferramenta como kured. Se você escolher o canal de atualização, as atualizações poderão ser aplicadas com a mesma frequência que todas as SecurityPatch noites. Esse nível de patch requer que os VHDs sejam armazenados em seu grupo de recursos, o que incorre em uma cobrança nominal. Além disso, você precisa combinar a SecurityPatch configuração com uma NodeImage configuração para habilitar um processo completo de aplicação de patches de nó.

Como prática recomendada, use o canal de atualização e configure uma aksManagedNodeOSUpgradeSchedule janela de manutenção para um momento em que o NodeImage 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 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 weeklyo .
  • 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 examinando 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 do 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 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 obter mais informações, 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, 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 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 preteridas.
  • 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 plutão, 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.

Aqui está 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. 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 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. Estas são as etapas detalhadas:

  1. Execute o comando az aks upgrade com o sinalizador para atualizar apenas o --control-plane-only 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 drenos pods no nó que está sendo atualizado, recria imagens do nó e, em seguida, descorda os 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 eventso . 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 canal de versão. Aqui está uma configuração recomendada de ambiente e canal de versão:

Environment 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 rapid canal. Você pode melhorar seu tempo de lançamento no mercado quando a versão em rapid é 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 Sim
Criação do cluster 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 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 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 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:

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

Outros colaboradores:

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

Próximas etapas