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

O Azure Kubernetes Service (AKS) gere múltiplos componentes que seguem diferentes estratégias de versionamento e correção. Compreender como esses componentes são versionados ajuda você a planejar atualizações, rastrear 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 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 controlo, imagens de nós de computação e funcionalidades do AKS, extensões e complementos implantados como cargas de trabalho em nós

O AKS consiste em vários componentes, cada um com padrões de versionamento distintos:

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

  • Imagens de nó: sistema operativo, tempo de execução do contêiner e componentes principais do nó Kubernetes. Detalhes sobre os componentes que estão empacotados nas imagens dos nós podem ser encontrados na pasta de notas Virtual Hard Disk (VHD) no repositório AKS GitHub.

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

    • Pods autónomos de complementos/recursos/extensões: complementos/recursos/extensões do AKS que executam pods autónomos (de Implementações ou DaemonSets) em nós hospedados pelo cliente (no lado esquerdo). Exemplos incluem istiod, azure-cnse coredns.
    • Componentes do AKS dentro dos pods de carga de trabalho do cliente: Alguns recursos/complementos/extensões do AKS podem incluir módulos auxiliares rodando dentro dos pods do usuário (no lado direito). Por exemplo, o Istio injeta proxies de sidecar nos 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:

Plano de controlo Imagens de nó Complementos, recursos ou pods de extensão independentes Componentes AKS dentro de pods de carga de trabalho do cliente
O que é versionado? Kubernetes API server, etcd, controladores Sistema operativo, tempo de execução do contentor e componentes principais dos nós Kubernetes Recurso/complementos/extensões do AKS que executam pods autônomos (por exemplo - istiod) Sidecars ou contentores de suporte incorporados por complementos/extensões
Modelo de controle de versão Segue o versionamento semântico upstream do Kubernetes (MAJOR.MINOR.PATCH). A 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 da versão do AKS As versões das imagens de nó juntamente com as notas VHD são publicadas com as lançamentos do AKS. Add-on/feature/extension versão secundária vinculada 1-1 à versão secundária AKS A versão sidecar deve ser compatível com o plano de controle adicional
Método de atualização 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 atualizar para a versão mais recente da imagem do nó suportada. 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 plano de controle é atualizada (exceto Istio; consulte a documentação de atualização do Istio)
- Versão do patch atualizada pelo AKS libera automaticamente		 O cliente precisa atualizar manualmente (reiniciar cargas de trabalho com sidecars) para versões de sidecar compatíveis, conforme documentado pelo complemento/recurso/extensão.

Práticas recomendadas de gerenciamento de versões

Consideração de segurança: habilite as atualizações automáticas de patches para garantir que as correções de segurança sejam aplicadas o mais rápido possível. Escolha o canal de atualização automática que melhor se adapta aos requisitos e à tolerância ao risco do cluster. Manual ou automática: escolha a estratégia de atualização que melhor se adapta 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 aprovados para seu cluster. Monitore e prepare-se para mudanças: Mantenha-se informado sobre as próximas atualizações e disponibilidade de novas versões usando as notas de versão do AKS e o rastreador de versões do AKS. Valide upgrades em ambientes que não sejam de produção antes de atualizar ambientes de produção.

  • Para os clusters de produção:
    • Considere atualizações automáticas de patches para correções de segurança oportunas
    • Escolha entre atualizações automáticas ou manuais de versões secundárias com base nas suas necessidades operacionais
    • Teste primeiro todas as alterações em ambientes de preparo
  • Para clusters de desenvolvimento:
    • Habilite as atualizações automáticas para o control plane e os node pools para permanecer atualizado com os recursos mais recentes
    • Escolha os canais apropriados com base nas suas necessidades de desenvolvimento e teste (consulte atualizações automáticas de cluster e atualização automática da imagem do nó para obter opções de canais)
    • Uso como campo de testes para estratégias de atualização de produção
  • Alterações críticas: Monitore o rastreador de lançamento do AKS e reveja as políticas de descontinuação do Kubernetes para se manter informado sobre as descontinuações da API e as alterações críticas no AKS e no Kubernetes de origem.
  • 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 AKS atualizados.

Visualizar versões dos componentes AKS usando o AKS Component Insights (Pré-visualização)

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

Importante

Os recursos de pré-visualização do AKS estão disponíveis numa base de autosserviço e adesão voluntária. As visualizações prévias são fornecidas "como estão" e "conforme disponíveis" e são excluídas dos contratos de nível de serviço e da garantia limitada. As versões de teste do AKS são parcialmente cobertas pelo suporte ao cliente numa base de melhor esforço. Assim sendo, estas funcionalidades não se destinam ao uso em produção. Para obter mais informações, consulte os seguintes artigos de suporte:

Pré-requisitos

Pré-requisito Observações
CLI do Azure 2.74.0 ou instalado posteriormente. Para localizar a versão, execute az --version. Se precisares de instalar ou atualizar, vê Install CLI do Azure.
CLI do Azure aks-preview extensão 18.0.0b19 ou mais tarde. Para localizar a versão, execute az --version. Se precisares de instalar ou atualizar, vê Gerir CLI do Azure extensões.

Pode instalar ou atualizar para a mais recente extensão aks-preview CLI do Azure disponível 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

Ver versões dos componentes usando CLI do Azure

Use o comando para visualizar as versões dos az aks get-upgrades componentes:

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

As informações do componente são retornadas na seção componentsByReleases. A saída esperada seria semelhante à seguinte (apenas parte do componentByReleases é mostrada aqui para 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 de acordo com a configuração do cluster, complementos habilitados e versão do Kubernetes. Use o az aks get-upgrades comando para ver a lista completa de componentes para seu cluster específico.

Cada entrada de componente inclui:

  • nome: O identificador do componente
  • version: A versão exata do componente instalado no cluster
  • hasBreakingChanges: Se esta versão do componente introduz alterações significativas

Sugestão

Para além de usar o CLI do Azure para consultar informação de versão dos componentes, também pode usar o GET upgradeProfiles API com APIs AKS de pré-visualização (2025-05-04-preview ou posteriores) para obter dados detalhados das versões dos componentes de forma programática.

Próximos passos

  • Última atualização a