Configurar um cluster do AKS

Artigo
03/20/2024

Como parte da criação de um cluster AKS, talvez seja necessário personalizar a configuração do cluster para atender às suas necessidades. Este artigo apresenta algumas opções para personalizar seu cluster AKS.

Configuração do SO

O AKS suporta o Ubuntu 22.04 e o Azure Linux 2.0 como o sistema operacional (SO) do nó para clusters com Kubernetes 1.25 e superior. O Ubuntu 18.04 também pode ser especificado na criação do pool de nós para as versões 1.24 e inferiores do Kubernetes.

O AKS suporta o Windows Server 2022 como o sistema operacional (SO) padrão para pools de nós do Windows em clusters com Kubernetes 1.25 e superior. O Windows Server 2019 também pode ser especificado na criação do pool de nós para as versões 1.32 e inferiores do Kubernetes. O Windows Server 2019 está sendo desativado depois que o Kubernetes versão 1.32 atinge o fim da vida útil (EOL) e não é suportado em versões futuras. Para obter mais informações sobre esta aposentadoria, consulte as notas de versão do AKS.

Configuração do tempo de execução do contêiner

Um tempo de execução de contêiner é um software que executa contêineres e gerencia imagens de contêiner em um nó. O tempo de execução ajuda a abstrair as chamadas de sistema ou a funcionalidade específica do sistema operacional (SO) para executar contêineres no Linux ou no Windows. Para pools de nós Linux, containerd é usado no Kubernetes versão 1.19 e superior. Para pools de nós do Windows Server 2019 e 2022, containerd está disponível em geral e é a única opção de tempo de execução no Kubernetes versão 1.23 e superior. A partir de maio de 2023, o Docker foi desativado e não terá mais suporte. Para obter mais informações sobre esta aposentadoria, consulte as notas de versão do AKS.

Containerd é um tempo de execução de contêiner principal compatível com OCI (Open Container Initiative) que fornece o conjunto mínimo de funcionalidades necessárias para executar contêineres e gerenciar imagens em um nó. Containerd foi doado à Cloud Native Compute Foundation (CNCF) em março de 2017. O AKS usa a versão atual do Moby (upstream Docker), que é construída sobre containerdo .

Com um containerdnó baseado em nós e pools de nós, em vez de falar com o dockershim, o kubelet fala diretamente com containerd o uso do plug-in CRI (container runtime interface), removendo saltos extras no fluxo de dados quando comparado à implementação do Docker CRI. Como tal, você vê melhor latência de inicialização do pod e menos uso de recursos (CPU e memória).

Ao usar containerd para nós AKS, a latência de inicialização do pod melhora e o consumo de recursos do nó pelo tempo de execução do contêiner diminui. Estas melhorias através desta nova arquitetura permitem que o kubelet se comunique diretamente através containerd do plugin CRI. Enquanto em uma arquitetura Moby/docker, o kubelet se comunica com o mecanismo e docker dockershim antes de chegar containerd, portanto, tendo saltos extras no fluxo de dados. Para obter mais detalhes sobre a origem do e sua depreciação, consulte as Perguntas frequentes sobre remoção dockershimdo Dockershim.

Docker CRI 2

Containerd funciona em todas as versões GA do Kubernetes no AKS, e em todas as versões mais recentes do Kubernetes acima v1.19, e suporta todos os recursos do Kubernetes e AKS.

Importante

Clusters com pools de nós Linux criados no Kubernetes v1.19 ou superior padrão para containerd seu tempo de execução de contêiner. Clusters com pools de nós em versões anteriores suportadas do Kubernetes recebem o Docker para seu tempo de execução de contêiner. Os pools de nós do Linux serão atualizados assim containerd que a versão do Kubernetes do pool de nós for atualizada para uma versão que ofereça suporte containerdao .

containerd com o Windows Server 2019 e 2022, os pools de nós estão geralmente disponíveis e são a única opção de tempo de execução de contêiner no Kubernetes 1.23 e superior. Você pode continuar usando pools de nós e clusters do Docker em versões anteriores à 1.23, mas o Docker não é mais suportado a partir de maio de 2023. Para obter mais informações, consulte Adicionar um pool de nós do Windows Server com containerdo .

É altamente recomendável testar suas cargas de trabalho em pools de nós AKS antes containerd de usar clusters com uma versão do Kubernetes que suporte containerd seus pools de nós.

`containerd` Limitações/Diferenças

Para containerdo , recomendamos usar crictl como uma CLI de substituição em vez da CLI do Docker para solucionar problemas de pods, contêineres e imagens de contêiner em nós do Kubernetes. Para obter mais informações sobre crictlo , consulte Uso geral e Opções de configuração do cliente.
- Containerd não fornece a funcionalidade completa da CLI do docker. Está disponível apenas para resolução de problemas.
- crictl oferece uma visão mais amigável do Kubernetes dos contêineres, com conceitos como pods, etc. presentes.
Containerd Configura o registro em log usando o formato de log padronizado cri (que é diferente do que você obtém atualmente do driver JSON do Docker). Sua solução de log precisa dar suporte ao formato de log (como o cri Azure Monitor for Containers)
Você não pode mais acessar o mecanismo /var/run/docker.sockdo docker ou usar o Docker-in-Docker (DinD).
- Se você atualmente extrai logs de aplicativos ou dados de monitoramento do mecanismo do Docker, use Insights de contêiner. O AKS não suporta a execução de comandos fora de banda nos nós do agente que possam causar instabilidade.
- Criar imagens e usar diretamente o mecanismo Docker usando os métodos mencionados anteriormente não são recomendados. O Kubernetes não está totalmente ciente desses recursos consumidos, e esses métodos apresentam inúmeros problemas, conforme descrito aqui e aqui.
Criação de imagens - Você pode continuar a usar seu fluxo de trabalho de compilação atual do Docker normalmente, a menos que esteja criando imagens dentro do cluster AKS. Nesse caso, considere mudar para a abordagem recomendada para criar imagens usando tarefas ACR ou uma opção mais segura no cluster, como o Docker Buildx.

Máquinas virtuais de 2ª Geração

O Azure dá suporte a máquinas virtuais (VMs) de Geração 2 (Gen2). As VMs de 2ª geração suportam os principais recursos não suportados nas VMs de 1ª geração (Gen1). Esses recursos incluem maior memória, Intel Software Guard Extensions (Intel SGX) e memória persistente virtualizada (vPMEM).

As VMs de 2ª geração usam a nova arquitetura de inicialização baseada em UEFI em vez da arquitetura baseada em BIOS usada pelas VMs de 1ª geração. Apenas SKUs e tamanhos específicos suportam VMs Gen2. Verifique a lista de tamanhos suportados, para ver se o seu SKU suporta ou requer Gen2.

Além disso, nem todas as imagens de VM suportam VMs Gen2. No AKS, as VMs Gen2 usam a imagem do AKS Ubuntu 22.04 ou 18.04 ou a imagem do AKS Windows Server 2022. Estas imagens suportam todos os SKUs e tamanhos Gen2.

As VMs Gen2 são suportadas no Linux. As VMs Gen2 no Windows são suportadas apenas para WS2022.

Máquinas virtuais de 2ª geração no Windows

Limitações

As VMs de 2ª geração são suportadas apenas no Windows para WS2022.
As VMs de 2ª geração são padrão para clusters do Windows maiores ou iguais ao Kubernetes 1.25.
Se você selecionar um tamanho de vm que suporte Gen 1 e Gen 2, o padrão para pools de nós do Windows será Gen 1. Para especificar a Gen 2, use o cabeçalho UseWindowsGen2VM=truepersonalizado .

Adicionar um pool de nós do Windows com uma VM de 2ª geração

Adicione um pool de nós com VMs de geração 2 no Windows usando o az aks nodepool add comando.

az aks nodepool add --resource-group myResourceGroup --cluster-name myAKSCluster --name gen2np --node-vm-size Standard_D32_v4 --os-type Windows --aks-custom-headers UseWindowsGen2VM=true

O exemplo acima criará um pool de nós WS2022 com uma VM Gen 2. Se você estiver usando um tamanho de vm que suporte apenas a geração 2, não será necessário adicionar o cabeçalho personalizado. Se você estiver usando uma versão do kubernetes em que o Windows Server 2022 não seja padrão, precisará especificar --os-sku.

Verifique se você está usando a geração 1 ou a geração 2 usando o az aks nodepool show comando e verifique se o nodeImageVersion .gen2
```
az aks nodepool show
```
Verifique os tamanhos de VM de 2ª geração disponíveis usando o az vm list comando.
```
az vm list -skus -l $region
```

Para obter mais informações, consulte Suporte para VMs de 2ª geração no Azure.

Dimensionamento de disco padrão do sistema operacional

Quando você cria um novo cluster ou adiciona um novo pool de nós a um cluster existente, o número de vCPUs por padrão determina o tamanho do disco do sistema operacional. O número de vCPUs é baseado no SKU da VM e, na tabela a seguir, listamos os valores padrão:

Núcleos de SKU de VM (vCPUs)	Camada de disco padrão do sistema operacional	IOPS Aprovisionadas	Taxa de transferência provisionada (Mbps)
1 - 7	P10/128G	500	100
8 - 15	P15/256G	1100	125
16 - 63	P20/512G	2300	150
64+	P30/1024G	5000	200

Importante

O dimensionamento de disco padrão do sistema operacional só é usado em novos clusters ou pools de nós quando discos efêmeros do sistema operacional não são suportados e um tamanho de disco padrão do sistema operacional não é especificado. O tamanho padrão do disco do sistema operacional pode afetar o desempenho ou o custo do cluster, e você não pode alterar o tamanho do disco do sistema operacional após a criação do cluster ou do pool de nós. Esse dimensionamento de disco padrão afeta clusters ou pools de nós criados em julho de 2022 ou posterior.

Usar o sistema operacional efêmero em novos clusters

Configure o cluster para usar discos efêmeros do sistema operacional quando o cluster for criado. Use o --node-osdisk-type argumento para definir o sistema operacional efêmero como o tipo de disco do sistema operacional para o novo cluster.

az aks create --name myAKSCluster --resource-group myResourceGroup -s Standard_DS3_v2 --node-osdisk-type Ephemeral

Se quiser criar um cluster regular usando discos de sistema operacional conectados à rede, você pode fazer isso especificando o --node-osdisk-type=Managed argumento. Você também pode optar por adicionar outros pools de nós efêmeros do sistema operacional, que abordamos na seção a seguir.

Usar o sistema operacional efêmero em clusters existentes

Configure um novo pool de nós para usar discos do sistema operacional efêmero. Use o --node-osdisk-type argumento para definir como o tipo de disco do sistema operacional como o tipo de disco do sistema operacional para esse pool de nós.

az aks nodepool add --name ephemeral --cluster-name myAKSCluster --resource-group myResourceGroup -s Standard_DS3_v2 --node-osdisk-type Ephemeral

Importante

Com o sistema operacional efêmero, você pode implantar imagens de VM e instância até o tamanho do cache da VM. No caso do AKS, a configuração de disco do SO do nó padrão usa 128 GB, o que significa que você precisa de um tamanho de VM que tenha um cache maior que 128 GB. O Standard_DS2_v2 padrão tem um tamanho de cache de 86 GB, que não é grande o suficiente. O Standard_DS3_v2 tem um tamanho de cache de 172 GB, que é grande o suficiente. Você também pode reduzir o tamanho padrão do disco do sistema operacional usando --node-osdisk-sizeo . O tamanho mínimo para imagens AKS é de 30 GB.

Se quiser criar pools de nós com discos de sistema operacional conectados à rede, você pode fazer isso especificando --node-osdisk-type Managed.

Host de contêiner do Azure Linux para AKS

Você pode implantar o host de contêiner do Azure Linux por meio de modelos CLI ou ARM do Azure.

Pré-requisitos

Você precisa da CLI do Azure versão 2.44.1 ou posterior instalada e configurada. Execute az --version para localizar a versão atualmente instalada. Se precisar de instalar ou atualizar, veja Install Azure CLI (Instalar o Azure CLI).
Se você ainda não tiver o kubectl instalado, instale-o por meio da CLI do Azure usando az aks install-cli ou siga as instruções upstream.

Implantar um cluster do Azure Linux AKS com a CLI do Azure

Use os comandos de exemplo a seguir para criar um cluster Linux do Azure.

az group create --name AzureLinuxTest --location eastus

az aks create --name testAzureLinuxCluster --resource-group AzureLinuxTest --os-sku AzureLinux --generate-ssh-keys

az aks get-credentials --resource-group AzureLinuxTest --name testAzureLinuxCluster

kubectl get pods --all-namespaces

Implantar um cluster do Azure Linux AKS com um modelo ARM

Para adicionar o Azure Linux a um modelo ARM existente, você precisa fazer as seguintes alterações:

Adicione "osSKU": "AzureLinux" e "mode": "System" à propriedade agentPoolProfiles.
Defina o apiVersion como 2021-03-01 ou mais recente: "apiVersion": "2021-03-01"

A implantação a seguir usa o modelo azurelinuxaksarm.jsonARM.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.1",
  "parameters": {
    "clusterName": {
      "type": "string",
      "defaultValue": "azurelinuxakscluster",
      "metadata": {
        "description": "The name of the Managed Cluster resource."
      }
    },
    "location": {
      "type": "string",
      "defaultValue": "[resourceGroup().location]",
      "metadata": {
        "description": "The location of the Managed Cluster resource."
      }
    },
    "dnsPrefix": {
      "type": "string",
      "defaultValue": "azurelinux",
      "metadata": {
        "description": "Optional DNS prefix to use with hosted Kubernetes API server FQDN."
      }
    },
    "osDiskSizeGB": {
      "type": "int",
      "defaultValue": 0,
      "minValue": 0,
      "maxValue": 1023,
      "metadata": {
        "description": "Disk size (in GB) to provision for each of the agent pool nodes. This value ranges from 0 to 1023. Specifying 0 will apply the default disk size for that agentVMSize."
      }
    },
    "agentCount": {
      "type": "int",
      "defaultValue": 3,
      "minValue": 1,
      "maxValue": 50,
      "metadata": {
        "description": "The number of nodes for the cluster."
      }
    },
    "agentVMSize": {
      "type": "string",
      "defaultValue": "Standard_DS2_v2",
      "metadata": {
        "description": "The size of the Virtual Machine."
      }
    },
    "linuxAdminUsername": {
      "type": "string",
      "metadata": {
        "description": "User name for the Linux Virtual Machines."
      }
    },
    "sshRSAPublicKey": {
      "type": "string",
      "metadata": {
        "description": "Configure all linux machines with the SSH RSA public key string. Your key should include three parts, for example 'ssh-rsa AAAAB...snip...UcyupgH azureuser@linuxvm'"
      }
    },
    "osType": {
      "type": "string",
      "defaultValue": "Linux",
      "allowedValues": [
        "Linux"
      ],
      "metadata": {
        "description": "The type of operating system."
      }
    },
    "osSKU": {
      "type": "string",
      "defaultValue": "azurelinux",
      "allowedValues": [
        "AzureLinux",
        "Ubuntu",
      ],
      "metadata": {
        "description": "The Linux SKU to use."
      }
    }
  },
  "resources": [
    {
      "type": "Microsoft.ContainerService/managedClusters",
      "apiVersion": "2021-03-01",
      "name": "[parameters('clusterName')]",
      "location": "[parameters('location')]",
      "properties": {
        "dnsPrefix": "[parameters('dnsPrefix')]",
        "agentPoolProfiles": [
          {
            "name": "agentpool",
            "mode": "System",
            "osDiskSizeGB": "[parameters('osDiskSizeGB')]",
            "count": "[parameters('agentCount')]",
            "vmSize": "[parameters('agentVMSize')]",
            "osType": "[parameters('osType')]",
            "osSKU": "[parameters('osSKU')]"
          }
        ],
        "linuxProfile": {
          "adminUsername": "[parameters('linuxAdminUsername')]",
          "ssh": {
            "publicKeys": [
              {
                "keyData": "[parameters('sshRSAPublicKey')]"
              }
            ]
          }
        }
      },
      "identity": {
          "type": "SystemAssigned"
      }
    }
  ],
  "outputs": {
    "controlPlaneFQDN": {
      "type": "string",
      "value": "[reference(parameters('clusterName')).fqdn]"
    }
  }
}

Crie este ficheiro no seu sistema e inclua as definições definidas no azurelinuxaksarm.json ficheiro.

az group create --name AzureLinuxTest --location eastus

az deployment group create --resource-group AzureLinuxTest --template-file azurelinuxaksarm.json --parameters linuxAdminUsername=azureuser sshRSAPublicKey=`<contents of your id_rsa.pub>`

az aks get-credentials --resource-group AzureLinuxTest --name testAzureLinuxCluster

kubectl get pods --all-namespaces

Implantar um cluster do Azure Linux AKS com o Terraform

Para implantar um cluster Linux do Azure com o Terraform, primeiro você precisa definir seu provedor para a azurerm versão 2.76 ou superior.

required_providers {
  azurerm = {
    source = "hashicorp/azurerm"
    version = "~> 2.76"
  }
}

Depois de atualizar seu azurerm provedor, você pode especificar o AzureLinux os_sku em default_node_pool.

default_node_pool {
  name = "default"
  node_count = 2
  vm_size = "Standard_D2_v2"
  os_sku = "AzureLinux"
}

Da mesma forma, você pode especificar o AzureLinux os_sku em azurerm_kubernetes_cluster_node_pool.

Nome do grupo de recursos personalizado

Quando você implanta um cluster do Serviço Kubernetes do Azure no Azure, ele também cria um segundo grupo de recursos para os nós de trabalho. Por padrão, o AKS nomeia o grupo MC_resourcegroupname_clustername_locationde recursos do nó, mas você pode especificar um nome personalizado.

Para especificar um nome de grupo de recursos personalizado, instale a extensão da CLI do aks-preview Azure versão 0.3.2 ou posterior. Ao usar a CLI do Azure, inclua o --node-resource-group parâmetro com o az aks create comando para especificar um nome personalizado para o grupo de recursos. Para implantar um cluster AKS com um modelo do Azure Resource Manager, você pode definir o nome do grupo de recursos usando a nodeResourceGroup propriedade.

az aks create --name myAKSCluster --resource-group myResourceGroup --node-resource-group myNodeResourceGroup

O provedor de recursos do Azure em sua assinatura cria automaticamente o grupo de recursos secundário. Você só pode especificar o nome do grupo de recursos personalizado durante a criação do cluster.

Ao trabalhar com o grupo de recursos do nó, lembre-se de que não é possível:

Especifique um grupo de recursos existente para o grupo de recursos do nó.
Especifique uma assinatura diferente para o grupo de recursos do nó.
Altere o nome do grupo de recursos do nó depois de criar o cluster.
Especifique nomes para os recursos gerenciados dentro do grupo de recursos do nó.
Modifique ou exclua marcas criadas pelo Azure de recursos gerenciados dentro do grupo de recursos do nó.

Restrição de nó (visualização)

O controlador de admissão de restrição de nó limita os objetos Node e Pod que um kubelet pode modificar. A Restrição de Nó está ativada por padrão nos clusters AKS 1.24+. Se você estiver usando uma versão mais antiga, use os comandos a seguir para criar um cluster com Restrição de Nó ou atualize um cluster existente para adicionar Restrição de Nó.

Importante

Os recursos de visualização do AKS estão disponíveis em uma base de autosserviço e opt-in. 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 visualizações do AKS são parcialmente cobertas pelo suporte ao cliente com base no melhor esforço. Como tal, estas funcionalidades não se destinam a utilização em produção. Para obter mais informações, consulte os seguintes artigos de suporte:

Antes de começar

Você deve ter o seguinte recurso instalado:

A CLI do Azure
A aks-preview versão de extensão 0.5.95 ou posterior

Instalar a extensão da CLI aks-preview

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

# Update the extension to make sure you have the latest version installed
az extension update --name aks-preview

Criar um cluster AKS com restrição de nó

Para criar um cluster usando a Restrição de Nó.

az aks create -n aks -g myResourceGroup --enable-node-restriction

Atualizar um cluster AKS com restrição de nó

Para atualizar um cluster para usar a Restrição de Nó.

az aks update -n aks -g myResourceGroup --enable-node-restriction

Remover restrição de nó de um cluster AKS

Para remover a Restrição de Nó de um cluster.

az aks update -n aks -g myResourceGroup --disable-node-restriction

Grupo de recursos totalmente gerenciado (Visualização)

O AKS implanta infraestrutura em sua assinatura para se conectar e executar seus aplicativos. As alterações feitas diretamente nos recursos no grupo de recursos do nó podem afetar as operações de cluster ou causar problemas posteriormente. Por exemplo, o dimensionamento, o armazenamento ou a configuração de rede devem ser feitos por meio da API do Kubernetes e não diretamente nesses recursos.

Para evitar que sejam feitas alterações no Grupo de Recursos de Nó, você pode aplicar uma atribuição de negação e impedir que os usuários modifiquem os recursos criados como parte do cluster AKS.

Importante

Antes de começar

Você deve ter os seguintes recursos instalados:

A CLI do Azure versão 2.44.0 ou posterior. Execute az --version para localizar a versão atual e, se precisar instalar ou atualizar, consulte Instalar a CLI do Azure.
A aks-preview versão de extensão 0.5.126 ou posterior

Instalar a extensão da CLI aks-preview

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

# Update the extension to make sure you have the latest version installed
az extension update --name aks-preview

Registre o sinalizador de recurso 'NRGLockdownPreview'

Registre o NRGLockdownPreview sinalizador de recurso usando o comando az feature register , conforme mostrado no exemplo a seguir:

az feature register --namespace "Microsoft.ContainerService" --name "NRGLockdownPreview"

Leva alguns minutos para que o status mostre Registrado. Verifique o status do registro usando o comando az feature show :

az feature show --namespace "Microsoft.ContainerService" --name "NRGLockdownPreview"

Quando o status refletir Registrado, atualize o registro do provedor de recursos Microsoft.ContainerService usando o comando az provider register :

az provider register --namespace Microsoft.ContainerService

Criar um cluster AKS com bloqueio de grupo de recursos de nó

Para criar um cluster usando o bloqueio do grupo de recursos do nó, defina como --nrg-lockdown-restriction-levelSomente leitura. Essa configuração permite visualizar os recursos, mas não modificá-los.

az aks create -n aksTest -g aksTest --nrg-lockdown-restriction-level ReadOnly

Atualizar um cluster existente com bloqueio de grupo de recursos de nó

az aks update -n aksTest -g aksTest --nrg-lockdown-restriction-level ReadOnly

Remover bloqueio de grupo de recursos de nó de um cluster

az aks update -n aksTest -g aksTest --nrg-lockdown-restriction-level Unrestricted

Próximos passos

Saiba como atualizar as imagens do nó no cluster.
Analise a arquitetura de linha de base para um cluster do Serviço Kubernetes do Azure (AKS) para saber mais sobre nossa arquitetura de infraestrutura de linha de base recomendada.
Consulte Atualizar um cluster do Serviço Kubernetes do Azure (AKS) para saber como atualizar seu cluster para a versão mais recente do Kubernetes.
Leia mais sobre containerd e Kubernetes
Consulte a lista de Perguntas frequentes sobre o AKS para encontrar respostas para algumas perguntas comuns do AKS.
Leia mais sobre discos Ephemeral OS.

Configurar um cluster do AKS

Configuração do SO

Configuração do tempo de execução do contêiner

containerd Limitações/Diferenças

Máquinas virtuais de 2ª Geração

Máquinas virtuais de 2ª geração no Windows

Limitações

Adicionar um pool de nós do Windows com uma VM de 2ª geração

Dimensionamento de disco padrão do sistema operacional

Usar o sistema operacional efêmero em novos clusters

Usar o sistema operacional efêmero em clusters existentes

Host de contêiner do Azure Linux para AKS

Pré-requisitos

Implantar um cluster do Azure Linux AKS com a CLI do Azure

Implantar um cluster do Azure Linux AKS com um modelo ARM

Implantar um cluster do Azure Linux AKS com o Terraform

Nome do grupo de recursos personalizado

Restrição de nó (visualização)

Antes de começar

Instalar a extensão da CLI aks-preview

Criar um cluster AKS com restrição de nó

Atualizar um cluster AKS com restrição de nó

Remover restrição de nó de um cluster AKS

Grupo de recursos totalmente gerenciado (Visualização)

Antes de começar

Instalar a extensão da CLI aks-preview

Registre o sinalizador de recurso 'NRGLockdownPreview'

Criar um cluster AKS com bloqueio de grupo de recursos de nó

Atualizar um cluster existente com bloqueio de grupo de recursos de nó

Remover bloqueio de grupo de recursos de nó de um cluster

Próximos passos

Recursos adicionais

`containerd` Limitações/Diferenças