Configurar um cluster do AKS
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 containerd
o .
Com um containerd
nó 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 dockershim
do Dockershim.
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 containerd
ao .
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 containerd
o .
É 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
containerd
o , recomendamos usarcrictl
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 sobrecrictl
o , 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 padronizadocri
(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 ocri
Azure Monitor for Containers)Você não pode mais acessar o mecanismo
/var/run/docker.sock
do 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=true
personalizado .
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 onodeImageVersion
.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-size
o . 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.json
ARM.
{
"$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_location
de 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
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 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-level
Somente 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.