Migrar clusters automáticos do AKS e pools de nós de sistema geridos

Aplica-se a: ✔️ AKS Automatic ✔️ AKS Standard

Este artigo mostra-lhe como migrar clusters AKS Automatic entre configurações suportadas de pool de nós de sistema gerido e configurações do AKS Standard.

Caminhos de migração suportados

Ao usar pools de nós do sistema geridos, o AKS provisiona, escala e atualiza os pools de nós do sistema e os componentes do sistema para si, isolando-os das suas cargas de trabalho. Os clusters automáticos do AKS também são suportados por um SLA de prontidão para pods e um SLA de tempo de atividade. Para mais informações, consulte a Visão Geral dos clusters automáticos AKS com pools de nós de sistema geridos.

Migrar de um cluster AKS Automatic com conjuntos de nós de sistema geridos para um cluster AKS Standard

Como funciona a migração

Um cluster automático do AKS com conjuntos de nós de sistema geridos executa os seus componentes do sistema em conjuntos de nós de sistema que o AKS aprovisiona, dimensiona e atualiza por si.

Para migrar do AKS Automatic para o AKS Standard, complete os seguintes passos de alto nível:

1. Adicione um pool de nós do sistema autogerido ao seu cluster AKS Automatic.
2. Atualize o SKU do cluster de automatic para base.

Depois de atualizar o SKU, o cluster passa a funcionar como um cluster AKS Standard, e os componentes do sistema são executados no pool de nós de sistema que adicionou e gere.

Migrar para um cluster AKS Standard

1. Adicione um pool de nós do sistema autogerido ao seu cluster AKS Automatic existente usando o az aks nodepool add comando. Defina o modo do pool de nós para System para que possa executar componentes de sistema após a migração.

   az aks nodepool add \
       --resource-group "${RESOURCE_GROUP}" \
       --cluster-name "${RESOURCE_NAME}" \
       --name systempool \
       --mode System \
       --node-count 3
   

2. Atualize o SKU do cluster de automatic para base usando o az aks update comando.

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --sku base
   

Verificar a migração

1. Confirma que o cluster agora usa o base SKU usando o az aks show comando.

   az aks show \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --query "sku" \
       --output table
   

2. Liste os pools de nós no cluster para confirmar que o pool de nós do sistema autogerido está presente e no modo System, utilizando o comando az aks nodepool list.

   az aks nodepool list \
       --resource-group "${RESOURCE_GROUP}" \
       --cluster-name "${RESOURCE_NAME}" \
       --query "[].{Name:name, Mode:mode, Count:count}" \
       --output table
   

Migrar de um cluster AKS Automatic sem pools de nós de sistema geridos para AKS Automatic com pools de nós de sistema geridos (pré-visualização)

O AKS Automatic suporta a migração em pré-visualização de pools de nós de sistema não geridos para pools de nós de sistema geridos em regiões onde os pools de nós de sistema geridos estão disponíveis de forma geral. Esta migração mantém o cluster no automatic SKU e move os componentes do sistema AKS para um pool de nós do sistema gerido pelo AKS.

Pré-requisitos

• Um cluster AKS Automatic existente sem pools de nós de sistema geridos.
• CLI do Azure versão 2.86.0 ou posterior. Para localizar a versão, execute az --version. Se precisar de instalar ou atualizar, consulte Install CLI do Azure.
• A versão mais recente da extensão CLI do aks-preview Azure.
• A feature flag Microsoft.ContainerService/NonHoboToHoboConversionPreview está registada na sua subscrição.

Registe o sinalizador de funcionalidade NonHoboToHoboConversionPreview usando o comando az feature register:

az feature register \
    --namespace Microsoft.ContainerService \
    --name NonHoboToHoboConversionPreview

Verifique o estado do registo usando o az feature show comando:

az feature show \
    --namespace Microsoft.ContainerService \
    --name NonHoboToHoboConversionPreview \
    --query properties.state \
    --output tsv

Espera até o comando regressar Registered antes de continuares. Depois, atualize o registo do Microsoft.ContainerService fornecedor de recursos.

az provider register --namespace Microsoft.ContainerService

Instale ou atualize a aks-preview extensão:

az extension add --name aks-preview
az extension update --name aks-preview

Migrar um cluster de rede virtual gerido por AKS

Para um cluster automático do AKS que utiliza rede gerida pelo AKS, migre para conjuntos de nós de sistema geridos utilizando o comando az aks update com o parâmetro --enable-hosted-system:

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --enable-hosted-system

Migrar um cluster de rede virtual personalizado

Para um cluster AKS Automatic que utiliza uma rede virtual personalizada, forneça uma sub-rede para o pool de nós do sistema gerido usando o --system-node-subnet-id parâmetro. A sub-rede do nó do sistema deve:

• Encontrar-se na mesma rede virtual e na mesma região que o cluster.
• Sê, pelo menos, /26.
• Não ser delegado a outro serviço.
• Seja diferente da sub-rede dos nós.

O --node-subnet-id parâmetro é opcional. Se não o fornecer, o AKS usa a sub-rede existente do pool de nós do sistema.

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --enable-hosted-system \
    --system-node-subnet-id "${SYSTEM_NODE_SUBNET_ID}" \
    --node-subnet-id "${NODE_SUBNET_ID}"

Verificar a migração

Confirme que o cluster utiliza pools de nós de sistema geridas utilizando o comando az aks show:

az aks show \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --query hostedSystemProfile \
    --output json

O seguinte exemplo de saída mostra a hostedSystemProfile.enabled propriedade definida para true:

{
  "enabled": true,
  "nodeSubnetId": "<node-subnet-resource-id>",
  "systemNodeSubnetId": "<system-node-subnet-resource-id>"
}

Migrar de um cluster AKS Standard para um cluster AKS Automatic com pools de nós do sistema gerido (pré-visualização)

O AKS suporta migração de pré-visualização de clusters AKS Standard (base SKU) para clusters automáticos AKS com pools de nós do sistema gerido em regiões onde os pools de nós do sistema gerido estão geralmente disponíveis.

Para migrar, primeiro configura o seu cluster AKS Standard para corresponder à configuração automática do AKS, e depois atualiza o SKU do cluster. A maior parte do trabalho está na preparação do cluster. Complete as secções seguintes por ordem, pois várias definições dependem de outras serem configuradas primeiro.

Antes de começar

• Um cluster AKS Standard (base SKU) existente. Para requisitos e limitações gerais do AKS Automatic, veja Quickstart: Criar um cluster automático do Azure Kubernetes Service (AKS) e Visão Geral dos clusters automáticos AKS com pools de nós do sistema gerido.
• CLI do Azure versão 2.86.0 ou posterior e a versão mais recente da aks-preview extensão.
• A feature flag Microsoft.ContainerService/NonHoboToHoboConversionPreview está registada na sua subscrição. Para registar a feature flag e instalar a extensão, siga os passos em Pré-requisitos.

Defina variáveis de ambiente para o seu cluster:

export RESOURCE_GROUP="<resource-group>"
export RESOURCE_NAME="<cluster-name>"
export NODE_RESOURCE_GROUP=$(az aks show --resource-group "${RESOURCE_GROUP}" --name "${RESOURCE_NAME}" --query nodeResourceGroup --output tsv)

Requisitos de migração

Antes de poder atualizar o SKU, o seu cluster deve cumprir os seguintes requisitos. Alguns requisitos variam consoante se o seu cluster utiliza uma rede virtual gerida por AKS ou uma rede virtual personalizada. Pode configurar estas definições usando o portal Azure, CLI do Azure, um modelo ARM ou outras ferramentas. O resto deste artigo mostra os passos do CLI do Azure pela ordem em que deve aplicá-los.

Planeie a sua migração

1. Determine se o seu cluster utiliza uma rede virtual gerida por AKS ou uma rede virtual personalizada. Se o comando seguinte devolver um nome de rede virtual, o seu cluster utiliza uma rede virtual gerida por AKS. Se não devolver nada, o teu cluster usa uma rede virtual personalizada.

   az network vnet list --resource-group "${NODE_RESOURCE_GROUP}" --query "[].name" --output tsv
   

   Vários passos neste artigo variam consoante o tipo da sua rede virtual.

2. Verifique o plugin de rede atual do seu cluster, o tipo de saída, o SKU do balanceador de carga e o nível de restrição do grupo de recursos de nós:

   az aks show \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --query "{networkPlugin:networkProfile.networkPlugin, networkPluginMode:networkProfile.networkPluginMode, outboundType:networkProfile.outboundType, loadBalancerSku:networkProfile.loadBalancerSku, nrgRestrictionLevel:nodeResourceGroupProfile.restrictionLevel}" \
       --output table
   

   • Plugin de rede: Deve estar azure com o modo plugin overlay. Se o seu cluster usa kubenet ou Azure CNI sem Overlay, atualize-o para Azure CNI Overlay antes de continuar. Para mais informações, consulte Atualizar o modo IPAM para Azure CNI Overlay.
   • SKU do balanceador de carga: Deve ser standard. Se o teu cluster ainda usa basic, atualiza-o com az aks update --load-balancer-sku standard.
   • Nível de restrição do grupo de recursos de nós: Para uma rede virtual gerida por AKS, é necessário criar uma sub-rede no grupo de recursos de nós. Se o nível de restrição estiver definido para ReadOnly, defina-o para Unrestricted antes de continuar. Volta a bloqueá-lo numa etapa posterior.

3. Reveja as alterações que perturbam workloads em execução ou o acesso, e planeie uma janela de manutenção:

   • Alterar o tipo de saída altera os endereços IP de saída do cluster. Atualize quaisquer regras de firewall que permitam tráfego do cluster.
   • Ativar a integração VNet do API Server altera o endereço IP do servidor API e requer um reinício do cluster. Esta mudança é permanente.
   • Alterar o dataplane de rede, o SKU do sistema operativo e as definições de acesso SSH recria a imagem dos teus nós.
   • Desabilitar contas locais remove credenciais kubeconfig estáticas. Certifique-se de que tem acesso através do Microsoft Entra ID e de uma função Azure RBAC, como o Azure Kubernetes Service RBAC Cluster Admin, antes de desativar esses controlos de acesso.
   • A migração permite as Salvaguardas de Implementação no modo Enforce com os Padrões de Segurança de Pods de linha de base. As implantações que não cumprem são rejeitadas. Podes excluir namespaces, mas não podes mudar o nível em todo o cluster para Warn. Revise as suas cargas de trabalho antes de migrar. Para mais informações, consulte Usar Salvaguardas de Implantação.

Preparar a rede do cluster

1. Tipo de saída: Para uma rede virtual gerida por AKS, o tipo de saída deve ser um gateway NAT gerido. O loadBalancer tipo de envio não é suportado. Se necessário, atualize o tipo de saída:

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --outbound-type managedNATGateway \
       --outbound-type-sku StandardV2
   

   Para uma rede virtual personalizada, qualquer tipo de saída é suportado e não é necessária qualquer alteração. Para mais informações, consulte Atualizar outboundType após a criação do cluster.

2. Identidade do cluster: Para uma rede virtual gerida por AKS, mantenha-se a identidade gerida atribuída ao sistema do cluster. Para uma rede virtual personalizada, o cluster deve usar uma identidade gerida atribuída pelo utilizador que tenha o papel de Network Contributor na rede virtual. Se necessário, atribua a identidade:

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --enable-managed-identity \
       --assign-identity "${IDENTITY_RESOURCE_ID}" \
       --yes
   

   Substitua IDENTITY_RESOURCE_ID pelo ID de recurso da sua identidade gerida atribuída pelo utilizador. Para mais informações, consulte Usar uma identidade gerida atribuída pelo utilizador.

3. Sub-rede do servidor API: Crie uma sub-rede dedicada para o servidor API na mesma rede virtual dos seus nós. A sub-rede deve ser separada da sua sub-rede de nó, ser pelo menos /28, e ser delegada a Microsoft.ContainerService/managedClusters.

   Para uma rede virtual gerida por AKS, crie-se a sub-rede na rede virtual no grupo de recursos de nós:

   export VNET_NAME=$(az network vnet list --resource-group "${NODE_RESOURCE_GROUP}" --query "[0].name" --output tsv)
   
   export APISERVER_SUBNET_ID=$(az network vnet subnet create \
       --resource-group "${NODE_RESOURCE_GROUP}" \
       --vnet-name "${VNET_NAME}" \
       --name apiserver-subnet \
       --address-prefixes "<unused-address-range>" \
       --delegations Microsoft.ContainerService/managedClusters \
       --query id --output tsv)
   

   Para uma rede virtual personalizada, crie a sub-rede na sua própria rede virtual, em vez disso, e defina APISERVER_SUBNET_ID como o ID do recurso.

4. Integração VNet do API Server: Ative a integração do VNet do API Server com a sub-rede que criou e depois reinicie o cluster:

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --enable-apiserver-vnet-integration \
       --apiserver-subnet-id "${APISERVER_SUBNET_ID}"
   
   az aks stop --resource-group "${RESOURCE_GROUP}" --name "${RESOURCE_NAME}"
   az aks start --resource-group "${RESOURCE_GROUP}" --name "${RESOURCE_NAME}"
   

   Para mais informações, consulte Converter um cluster existente do AKS Standard para API Server VNet Integration.

5. Plano de dados de rede: Atualize o plano de dados de rede para Cilium. Este comando também define a política de rede para Cilium.

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --network-dataplane cilium
   

   Para mais informações, consulte Azure CNI Powered by Cilium.

Preparar o pool de nós do sistema e o provisionamento de nós

1. Disco efémero do sistema operativo: O pool de nós do sistema deve usar um disco efémero do sistema operativo. Verifique o tipo de disco atual do sistema operativo:

   az aks nodepool list \
       --resource-group "${RESOURCE_GROUP}" \
       --cluster-name "${RESOURCE_NAME}" \
       --query "[?mode=='System'].{name:name, osDiskType:osDiskType}" \
       --output table
   

   Não podes alterar o tipo de disco do sistema operativo de um pool de nós existente. Se o teu pool de nós do sistema usar um Managed disco do sistema operativo, adiciona um novo pool de nós do sistema com --mode System --node-osdisk-type Ephemeral --os-sku AzureLinux --ssh-access disabled, move as cargas de trabalho do sistema para ele e depois elimina o pool de nós antigo. Depois, pode ignorar o passo seguinte.

2. SKU do sistema operativo e acesso SSH: Atualizar o pool de nós do sistema para usar o Azure Linux e desativar o acesso SSH:

   az aks nodepool update \
       --resource-group "${RESOURCE_GROUP}" \
       --cluster-name "${RESOURCE_NAME}" \
       --name "<system-node-pool-name>" \
       --os-sku AzureLinux \
       --ssh-access disabled \
       --yes
   

   Este comando recria a imagem do pool de nós. Espera que termine antes de fazeres outras alterações ao pool de nós. Para mais informações, consulte Usar o Azure Linux Container Host e Gerir o acesso SSH em nós de cluster AKS.

3. Modo de provisão de nós: Ativar o modo de provisão automática de nós:

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --node-provisioning-mode Auto
   

   Depois de ativares o modo Auto, não podes voltar ao modo Manual sem primeiro remover todos os nós autoprovisionados. Para mais informações, consulte o auto-provisionamento de nós.

Ativar as funcionalidades e os suplementos necessários

1. Atualize o nível do cluster para Standard e ative os add-ons Azure Policy e Azure Key Vault Secrets Provider com rotação de segredos:

   az aks update --resource-group "${RESOURCE_GROUP}" --name "${RESOURCE_NAME}" --tier standard
   
   az aks enable-addons \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --addons azure-policy,azure-keyvault-secrets-provider \
       --enable-secret-rotation
   

2. Ativar as restantes funcionalidades obrigatórias:

   az aks update \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --auto-upgrade-channel stable \
       --node-os-upgrade-channel NodeImage \
       --enable-workload-identity \
       --enable-oidc-issuer \
       --enable-aad \
       --enable-azure-rbac \
       --disable-local-accounts \
       --enable-image-cleaner \
       --enable-vpa \
       --enable-keda \
       --yes
   

Bloquear o grupo de recursos do nó

Defina o nível de restrição do grupo de recursos de nós para o valor ReadOnly. Faz este passo por último, porque o lockdown bloqueia alterações nos recursos do grupo de recursos do nó, incluindo a sub-rede do servidor API que criaste anteriormente.

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --nrg-lockdown-restriction-level ReadOnly

Para mais informações, consulte bloqueio do grupo de recursos de nós.

Migrar o cluster para o AKS Automatic

Se algum requisito ainda não for cumprido, o comando de migração falha e lista os requisitos não cumpridos que detetou. Algumas verificações só são executadas depois de as anteriores passarem, por isso resolve os itens listados e executa o comando novamente até ter sucesso.

Rede virtual gerida por AKS

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --sku automatic \
    --enable-hosted-system

Rede virtual personalizada

Forneça uma sub-rede para o pool de nós do sistema gerido usando o --system-node-subnet-id parâmetro. Para requisitos de sub-rede, consulte Migrar um cluster automático AKS existente para pools de nós de sistema geridos. O --node-subnet-id parâmetro é opcional. Se não o fornecer, o AKS usa a sub-rede existente do pool de nós do sistema.

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${RESOURCE_NAME}" \
    --sku automatic \
    --enable-hosted-system \
    --system-node-subnet-id "${SYSTEM_NODE_SUBNET_ID}" \
    --node-subnet-id "${NODE_SUBNET_ID}"

Verificar a migração

1. Confirme que o cluster usa o Standard SKU e o automatic nível, e que a atualização foi concluída com sucesso:

   az aks show \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --query "{sku:sku, provisioningState:provisioningState}" \
       --output json
   

   Confirme que sku.name é Automatic, que sku.tier é Standard e que provisioningState é Succeeded.

2. Confirme que o cluster utiliza pools de nós do sistema geridos:

   az aks show \
       --resource-group "${RESOURCE_GROUP}" \
       --name "${RESOURCE_NAME}" \
       --query hostedSystemProfile \
       --output json
   

   Verifique se hostedSystemProfile.enabled é true. Para uma rede virtual personalizada, systemNodeSubnetId e nodeSubnetId mostram os IDs dos seus recursos de sub-rede. Para uma rede virtual gerida por AKS, estes valores são null.

3. Obtenha credenciais para o cluster e confirme que todos os nós estão no Ready estado:

   az aks get-credentials --resource-group "${RESOURCE_GROUP}" --name "${RESOURCE_NAME}"
   kubectl get nodes -o wide
   

Comportamento em caso de falha

Se a migração não conseguir provisionar a infraestrutura do pool de sistema gerido (por exemplo, devido a limitações de capacidade regionais), o AKS preserva os pools de nós de sistema e de utilizador existentes no seu estado pré-migração.