Tutorial: Migrar nós para Azure Container Linux (ACL)

Neste tutorial, parte três de cinco, você migrará seus nós existentes para ACL. Você pode migrar seus nós existentes usando um dos seguintes métodos:

  • Remova os pools de nós existentes e adicione novos pools de nós de ACL.
  • Realize uma migração local de SKU do sistema operacional (SO).

Os comandos neste tutorial usam as variáveis de ambiente definidas no Tutorial 1: Criar um cluster com ACL para AKS.

Caso você não tenha nenhum nó existente para migrar, vá para o próximo tutorial. Em tutoriais posteriores, você aprenderá a habilitar a telemetria e o monitoramento em seus clusters e atualizar nós de ACL.

Pré-requisitos

  • Em tutoriais anteriores, você criou e implantou um cluster ACL. Se você ainda não concluiu estas etapas e deseja acompanhar, confira o Tutorial 1: Criar um cluster com ACL para AKS.
  • Azure Contêiner Linux requer CLI do Azure versão 2.86.0 ou superior. Use o az version comando para localizar a versão. Para atualizar para a versão mais recente, use o az upgrade comando.

Considerações e limitações do Azure Container Linux (ACL)

Antes de começar, examine as seguintes considerações e limitações para ACL:

Adicionar pools de nós de ACL e remover pools de nós existentes

  1. Adicione um novo pool de nós de ACL usando o az aks nodepool add comando. Use o --mode System para que o novo pool possa atuar como pool de agentes do sistema, o que permite remover o pool de nós original na próxima etapa. O exemplo a seguir cria um pool de nós chamado aclsystem que adiciona três nós ao cluster:

    az aks nodepool add \
    --resource-group $RESOURCE_GROUP \
    --cluster-name $CLUSTER_NAME \
    --name aclsystem \
    --mode System \
    --os-sku AzureContainerLinux \
    --node-count 3

    Exemplo de saída:

    {
  "id": "/subscriptions/xxxxx/resourceGroups/myACLResourceGroup/providers/Microsoft.ContainerService/managedClusters/myACLCluster/nodePools/aclsystem",
  "name": "aclsystem",
  "osSku": "AzureContainerLinux",
  "provisioningState": "Succeeded"
}

  2. Remova o pool de nós existente usando o az aks nodepool delete comando.

    az aks nodepool delete \
    --resource-group $RESOURCE_GROUP \
    --cluster-name $CLUSTER_NAME \
    --name <existing-node-pool-name>

Migração in-loco do SKU do sistema operacional

Limitações para migração no local do SKU do sistema operacional

Há várias configurações que podem bloquear a solicitação de migração de SKU do sistema operacional. Para garantir uma migração bem-sucedida, examine as seguintes diretrizes e limitações:

  • O recurso de migração de SKU do sistema operacional não está disponível por meio do PowerShell ou do portal do Azure.
  • O recurso de migração de SKU do sistema operacional não dá suporte à renomeação de pools de nós existentes.
  • Ubuntu, Azure Linux e AzureContainerLinux são os únicos destinos de migração de SKU do sistema operacional Linux com suporte.
  • A ACL requer inicialização confiável. Caso ainda não estejam habilitados no seu pool de nós, você deve incluir --enable-secure-boot e --enable-vtpm ao migrar para o SKU de SO AzureContainerLinux. O tamanho da VM do pool de nós também deve dar suporte ao Lançamento Confiável. Se o tamanho da VM atual não der suporte a ela, você precisará redimensionar ou recriar o pool de nós com um tamanho de VM com suporte antes de migrar.
  • Não há suporte para VMs de geração 1.
  • Um SKU do sistema operacional Ubuntu com UseGPUDedicatedVHD habilitado não pode executar uma migração de SKU do sistema operacional.
  • Não há suporte para CVMs (Máquinas Virtuais Confidenciais).
  • Não há suporte para o Pod Sandboxing.
  • Não há suporte para a migração do SKU do sistema operacional Windows.

Pré-requisitos para a migração de SKU do sistema operacional no local

  • Um cluster AKS existente com pelo menos um pool de nós de Linux.
  • Recomendamos que você verifique se suas cargas de trabalho são executadas com êxito na ACL implantando um cluster ACL em um ambiente de desenvolvimento ou preparo antes de migrar clusters de produção.
  • Verifique se o recurso de migração está funcionando para você no teste/desenvolvimento antes de usar o processo em um cluster de produção.
  • Garanta que seus pods tenham Pod Disruption Budget (PDB) suficiente para permitir que o AKS mova pods entre VMs durante a atualização.
  • Você precisa da versão 2.61.0 ou posterior da CLI do Azure. Use o az version comando para localizar a versão. Para atualizar para a versão mais recente, use o az upgrade comando.

Migrar para ACL usando a migração local da SKU do sistema operacional

Você pode migrar seus pools de nós existentes do Ubuntu ou do Azure Linux para ACL alterando a SKU do sistema operacional do pool de nós, o que faz com que o cluster passe pelo processo padrão de atualização da imagem dos nós. Esse método não exige criar novos pools de nós; em vez disso, os pools de nós existentes são automaticamente recriados a partir da imagem.

Importante

A ACL requer inicialização confiável. Você deve incluir --enable-secure-boot e --enable-vtpm ao migrar para o SKU do sistema operacional AzureContainerLinux. O tamanho da VM do seu pool de nós também deve ser compatível com o Lançamento Confiável.

Migre o SKU do sistema operacional do pool de nós para ACL usando o az aks nodepool update comando. Esse comando dispara uma nova imagem do pool de nós. A alteração do SKU do sistema operacional dispara uma operação de atualização imediata, que leva vários minutos para ser concluída.

az aks nodepool update \
    --resource-group $RESOURCE_GROUP \
    --cluster-name $CLUSTER_NAME \
    --name <existing-node-pool-name> \
    --os-sku AzureContainerLinux \
    --enable-secure-boot \
    --enable-vtpm

Exemplo de saída:

{
  "id": "/subscriptions/xxxxx/resourceGroups/myACLResourceGroup/providers/Microsoft.ContainerService/managedClusters/myACLCluster/nodePools/nodepool1",
  "name": "nodepool1",
  "osSku": "AzureContainerLinux",
  "provisioningState": "Succeeded"
}

Note

Se você tiver problemas durante a migração do SKU do sistema operacional, poderá reverter para o SKU do sistema operacional anterior.

Verificar a migração de SKU do sistema operacional

Depois que a migração for concluída em seus clusters de teste, verifique o seguinte para garantir uma migração bem-sucedida:

  1. Confirme se os novos nós estão executando ACL usando o seguinte comando:

    kubectl get nodes -o wide

  2. Verifique se todos os pods e daemonsets estão em execução no novo pool de nós usando o seguinte comando:

    kubectl get pods -o wide -A

  3. Verifique se todos os rótulos dos nós do pool de nós atualizado correspondem ao esperado com o seguinte comando:

    kubectl get nodes --show-labels

  4. Verifique a versão da imagem do nó usando o az aks nodepool list comando.

    az aks nodepool list \
    --resource-group $RESOURCE_GROUP \
    --cluster-name $CLUSTER_NAME \
    --query '[].{name: name, osSku: osSku, nodeImageVersion: nodeImageVersion}'

    Exemplo de saída:

    [
  {
    "name": "nodepool1",
    "nodeImageVersion": "AKSAzureContainerLinux-202606.01.0",
    "osSku": "AzureContainerLinux"
  }
]

Dica

Recomendamos monitorar a integridade do serviço por algumas semanas antes de migrar seus clusters de produção.

Reverter para o SKU do sistema operacional anterior

Se você tiver problemas durante a migração do SKU do sistema operacional, poderá reverter para o SKU do sistema operacional anterior. Para fazer isso, altere o campo SKU do sistema operacional de volta para seu valor anterior e reenvie a implantação, que dispara outra operação de atualização e reimageia o pool de nós para sua SKU anterior do sistema operacional.

Reverta para o SKU do sistema operacional anterior usando o comando az aks nodepool update. Este exemplo reverte da ACL para Azure Linux:

az aks nodepool update \
    --resource-group $RESOURCE_GROUP \
    --cluster-name $CLUSTER_NAME \
    --name <existing-node-pool-name> \
    --os-sku AzureLinux

Próxima etapa

Neste tutorial, você migrou os nodos existentes para a ACL. No próximo tutorial, você aprenderá a habilitar a telemetria e o monitoramento para seu cluster de ACL.

Habilitar a telemetria e o monitoramento

  • Last updated on