Noções básicas sobre o controle de versão do componente do AKS

AKS (Serviço de Kubernetes do Azure) gerencia vários componentes que seguem diferentes estratégias de controle de versão e aplicação de patch. Entender como a versão desses componentes ajuda você a planejar atualizações, acompanhar patches de segurança e gerenciar o ciclo de vida do cluster de forma eficaz.

Este artigo explica a abordagem de controle de versão para diferentes categorias de componentes do AKS e como eles são mantidos ao longo do tempo.

Visão geral dos componentes do AKS

Diagrama de diferentes componentes do AKS – plano de controle, imagens de nós e recursos do AKS, extensões, complementos implantados como cargas de trabalho nos nós

O AKS consiste em vários componentes, cada um com padrões de controle de versão distintos:

  • Plano de controle de cluster do Kubernetes hospedado pelo AKS: servidor de API do Kubernetes gerenciado, etcd e outros componentes do plano de controle de cluster.

  • Imagens de nó: sistema operacional, runtime de contêiner e componentes principais do nó do Kubernetes. Detalhes sobre quais componentes são empacotados nas imagens do nó podem ser encontrados na pasta de anotações VHD (Disco Rígido Virtual) no repositório GitHub do AKS.

  • Cargas de trabalho: recursos/complementos/extensões gerenciados do AKS podem ter componentes em um destes dois buckets:

    • Complemento autônomo/recursos/pods de extensão: recursos/complementos/extensões do AKS que executam pods autônomos (de Implantações ou DaemonSets) em nós hospedados pelo cliente (lado esquerdo). Exemplos incluem istiod, azure-cns e coredns.
    • Componentes do AKS dentro dos pods de carga de trabalho do cliente: alguns recursos/complementos/extensões do AKS podem ter sidecars em execução dentro dos pods do usuário (lado direito). Por exemplo, Istio injeta proxies sidecar em pods de carga de trabalho do cliente.

    A tabela a seguir resume como o controle de versão e as atualizações são gerenciados para cada categoria de componente do AKS:

Painel de controle Imagens de nó Pods de complementos autônomos/recursos/extensões Componentes do AKS dentro de pods de carga de trabalho do cliente
O que é versionado? Servidor de API do Kubernetes, etcd, controladores Sistema operacional, runtime do contêiner e componentes principais do nó do Kubernetes Recursos/complementos/extensões do AKS que executam pods autônomos (por exemplo, istiod) Sidecars ou contêineres de suporte injetados por complementos/extensões
Modelo de controle de versão Segue o controle de versão semântica upstream do Kubernetes (MAJOR.MINOR.PATCH). O AKS oferece modelos de comunidade e Suporte de Longo Prazo (LTS). Mais informações podem ser encontradas na documentação da política de suporte à versão do AKS Versões de imagens de nó acompanhadas das notas de VHD publicadas nas versões do AKS. Versão secundária de complemento/recurso/extensão relacionada de forma 1-1 com a versão secundária do AKS A versão sidecar deve ser compatível com o plano de controle de complemento
Método Update O cliente tem controle sobre para qual MAJOR.MINOR.PATCH versão atualizar. Manual (az aks upgrade) ou automático usando canais de atualização automática O cliente pode realizar a atualização para a versão mais recente da imagem do nó com suporte. Manual (az aks nodepool upgrade) ou automático usando canais de atualização automática – Versão secundária atualizada quando a versão secundária do painel de controle é atualizada (exceto Istio; consulte a documentação de atualização do Istio)
– Versão do patch atualizada automaticamente pelas atualizações do AKS		 O cliente precisa realizar a atualização manualmente, reiniciando as cargas de trabalho que possuem sidecars, para as versões de sidecar compatíveis, conforme documentado pelo complemento/recurso/extensão.

Práticas recomendadas de gerenciamento de versão

Consideração de segurança: habilite as atualizações automáticas de patch para garantir que as correções de segurança sejam aplicadas assim que possível. Escolha o canal de autoupgrade que melhor atenda aos requisitos do cluster e à tolerância a riscos. Manual ou automático: escolha a estratégia de atualização que melhor atenda aos seus requisitos operacionais. As atualizações automáticas fornecem patches de segurança oportunos e reduzem a sobrecarga operacional, enquanto as atualizações manuais oferecem controle preciso sobre o tempo e o gerenciamento de alterações. Use janelas de manutenção planejada para controlar quando as atualizações automáticas são aplicadas, garantindo que as atualizações ocorram durante os períodos de tempo aprovados para o cluster. Monitorar e preparar as alterações: mantenha-se informado sobre as próximas atualizações e a disponibilidade de novas versões usando notas de versão do AKS e o rastreador de versão do AKS. Valide atualizações em ambientes de não produção antes de atualizar ambientes de produção.

  • Para clusters de produção:
    • Considere as atualizações automáticas de patch para correções de segurança em tempo hábil
    • Escolha entre atualizações automáticas ou manuais de versão secundária com base em suas necessidades operacionais
    • Teste todas as alterações em ambientes de teste primeiro
  • Para clusters de desenvolvimento:
    • Habilitar atualizações automáticas para que o plano de controle e os pools de nós permaneçam atualizados com os recursos mais recentes.
    • Escolha canais apropriados com base em suas necessidades de desenvolvimento e teste (consulte atualizações automáticas de cluster e atualização automática de imagem de nó para opções de canal)
    • Usar como um campo de teste para estratégias de atualização de produção
  • Alterações interruptivas: monitore o rastreador de versão do AKS e examine as políticas de substituição do Kubernetes para se manter informado sobre as substituições de API e alterações interruptivas no AKS e no Kubernetes upstream.
  • Validação de pré-atualização: antes de atualizar seus clusters de produção, teste seus aplicativos, recursos personalizados e integrações de terceiros em clusters de pré-produção para garantir a compatibilidade com a nova versão do Kubernetes e os componentes atualizados do AKS.

Exibir versões de componente do AKS usando o AKS Component Insights (versão prévia)

AKS Component Insights (Preview) fornece visibilidade detalhada das versões exatas de todos os componentes em execução no cluster Serviço de Kubernetes do Azure. Esse recurso ajuda você a entender o estado atual do cluster, planejar atualizações e identificar possíveis problemas de compatibilidade.

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:

Pré-requisitos

  • Uma conta Azure com uma assinatura ativa. Se você não tiver uma, crie uma conta gratuita.
  • Um cluster AKS configurado em seu ambiente de Azure
Pré-requisito Anotações
CLI do Azure 2.74.0 ou posterior instalado. Para saber qual é a versão, execute az --version. Se precisar instalar ou atualizar, consulte Instalar CLI do Azure.
Extensão CLI do Azureaks-preview 18.0.0b19 ou posterior. Para saber qual é a versão, execute az --version. Se você precisar instalar ou atualizar, consulte Manage CLI do Azure extensões.

Você pode instalar ou atualizar para a extensão aks-preview CLI do Azure mais recente usando os seguintes comandos:

# Install the aks-preview extension
az extension add --name aks-preview

# Update to the latest version if already installed
az extension update --name aks-preview

Exibir versões de componente usando CLI do Azure

Use o az aks get-upgrades comando para exibir versões de componente:

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster

As informações do componente são retornadas na componentsByReleases seção. A saída esperada seria semelhante à seguinte (apenas uma parte de componentByReleases é mostrada aqui para fins de brevidade):

{
  "componentsByReleases": [
      {
        "components": [
          {
            "hasBreakingChanges": false,
            "name": "cloud-provider-node-manager-linux",
            "version": "v1.32.5"
          },
          {
            "hasBreakingChanges": false,
            "name": "cloud-provider-node-manager-windows",
            "version": "v1.32.5"
          },
          {
            "hasBreakingChanges": false,
            "name": "health-probe-proxy",
            "version": "v1.29.1"
          },
          {
            "hasBreakingChanges": false,
            "name": "kubelet-serving-csr-approver",
            "version": "v0.0.7"
          },
          {
            "hasBreakingChanges": false,
            "name": "coredns",
            "version": "v1.11.3-8"
          },
          {
            "hasBreakingChanges": false,
            "name": "metrics-server",
            "version": "v0.7.2-7"
          }
        ],
        "kubernetesVersion": "1.32"
      }
  ]
}

Os componentes reais mostrados podem variar com base na configuração do cluster, nos complementos habilitados e na versão do Kubernetes. Use o az aks get-upgrades comando para ver a lista completa de componentes do cluster específico.

Cada entrada de componente inclui:

  • nome: o identificador do componente
  • versão: a versão exata do componente instalado no cluster
  • hasBreakingChanges: se essa versão do componente apresenta alterações interruptivas

Dica

Além de usar o CLI do Azure para consultar informações de versão do componente, você também pode usar o GET upgradeProfiles API com APIs do AKS de visualização (2025-05-04-preview ou posterior) para recuperar dados detalhados da versão do componente programaticamente.

Próximas etapas

  • Última atualização em