Quickstart: Criar um cluster privado Azure Kubernetes Service (AKS) Automatic numa rede virtual personalizada

Aplica-se a: ✔️ AKS Automatic

Azure Kubernetes Service (AKS) Automatic proporciona a experiência Kubernetes gerida mais fácil para programadores, engenheiros DevOps e engenheiros de plataforma. Ideal para aplicações modernas e de IA, o AKS Automatic automatiza a configuração e as operações do cluster AKS e incorpora as configurações de melhores práticas. Usuários de qualquer nível de habilidade podem se beneficiar da segurança, desempenho e confiabilidade do AKS Automatic para suas aplicações. O AKS Automatic inclui também um SLA de prontidão de pods que garante 99,9% de operações qualificadas de prontidão de pod concluídas em 5 minutos, garantindo uma infraestrutura fiável e auto-reparadora para as suas aplicações. Este início rápido assume que possui um entendimento básico dos conceitos do Kubernetes. Para mais informações, consulte Kubernetes conceitos centrais para Azure Kubernetes Service (AKS).

Neste guia de início rápido, você aprende a:

  • Crie uma rede virtual.
  • Crie uma identidade gerenciada com permissões na rede virtual.
  • Implante um cluster privado do AKS Automatic na rede virtual.
  • Conecte-se ao cluster privado.
  • Corra uma aplicação de exemplo com vários contêineres e um conjunto de microsserviços e interfaces web simulando um cenário de retalho.

Pré-requisitos

  • Se não tiver uma conta Azure, crie uma conta gratuita.
  • CLI do Azure versão 2.86.0 ou posterior. Para encontrar a versão, execute az --version comando. Se precisares de instalar ou atualizar, vê Install CLI do Azure.
  • Identidade de cluster com uma atribuição de função incorporada na sub-rede do servidor de API.
  • Identidade de cluster com uma Network Contributor atribuição de função interna na rede virtual para dar suporte ao provisionamento automático de nós.
  • Identidade do utilizador a aceder o cluster com Azure Kubernetes Service Cluster User Role e Azure Kubernetes Service RBAC Writer.
  • Uma rede virtual com uma sub-rede dedicada para servidores API de dimensão de pelo menos */28, que é delegada a Microsoft.ContainerService/managedClusters.
    • Se existir um Grupo de Segurança de Rede (NSG) ligado às sub-redes, certifique-se de que as regras permitem o seguinte tráfego entre os nós e o servidor API, o Balanceador de Carga do Azure e o servidor API, bem como comunicação pod a pod.
    • Se existir um Azure Firewall ou outro método ou dispositivo de restrição de saída, certifique-se de que as regras de rede de saída exigidas e os FQDNs são permitidos.
  • O AKS Automatic irá ativar o Azure Policy no cluster do AKS, mas deve pré-registrar o fornecedor de recursos Microsoft.PolicyInsights na sua subscrição para uma experiência mais simples. Para obter mais informações, consulte Tipos e provedores de recursos do Azure.
  • Desinstale a extensão AKS-preview usando az extension remove -n aks-preview.

Importante

A partir da versão 1.36 do AKS, os novos clusters AKS Automatic terão por predefinição a API de Gateway do Kubernetes através do add-on de encaminhamento de aplicações ativada, em vez de ingress NGINX gerido com o add-on de encaminhamento de aplicações, devido à descontinuação a montante do Ingress NGINX.

Os clusters automáticos existentes não são afetados, mas devem iniciar a migração para a API do Kubernetes Gateway através do complemento de encaminhamento de aplicações.

Limitações

As seguintes limitações aplicam-se aos clusters automáticos do AKS:

  • O AKS Automatic está geralmente disponível nas seguintes regiões: australiaeast, austriaeast, belgiumcentral, brazilsouth, canadacentral, centralindia, centralus, chilecentral, denmarkeast, eastasia, eastus, eastus2, francecentral, germanywestcentral, indonesiacentral, israelcentral, italynorth, japaneast, japanwest, koreacentral, malaysiawest, mexicocentral, newzealandnorth, northeurope, norwayeast, polandcentral, southafricanorth, southcentralus, southeastasia, spaincentral, swedencentral, switzerlandnorth, uaenorth, uksouth, westeurope, westus2, westus3.
    • Os novos clusters automáticos do AKS ativam, por predefinição, conjuntos de nós de sistema geridos e LocalDNS. Não é possível criar clusters AKS automáticos sem pools de nós do sistema geridos em nenhuma região.
  • O cluster automático do AKS tem o bloqueio do grupo de recursos do nó pré-configurado, o que não permite alterações ao grupo de recursos MC_, impedindo ligações de rede virtual na zona DNS Privado predefinida. Para cenários cross-VNet ou DNS personalizados, use rede personalizada e DNS privado seguindo Crie um cluster privado Azure Kubernetes Service (AKS) Automático numa rede virtual personalizada.
  • É necessária a versão 2.86.0 ou posterior do CLI do Azure. Para encontrar a versão, execute az --version comando. Se precisares de instalar ou atualizar, vê Install CLI do Azure.
  • As seguintes extensões não são suportadas:
  • Os nós Windows não são suportados.
  • O complemento de malha de serviço baseado em Istio para AKS não é suportado.
  • A migração entre o SKU base do AKS e o SKU Automático não é suportada.
  • Migrações entre clusters automáticos AKS sem pools de nós de sistema geridos e clusters automáticos AKS com pools de nós de sistema geridos não são suportadas.
  • A configuração da recolha personalizada de métricas do Prometheus e da recolha de logs não é suportada.
  • A ativação da observabilidade do ACNS durante a criação automática do cluster não é suportada. Pode ativar a observabilidade ACNS depois de o cluster ser criado.

Definir variáveis

Defina as seguintes variáveis que são usadas nos passos seguintes.

RG_NAME=automatic-rg
VNET_NAME=automatic-vnet
CLUSTER_NAME=automatic
IDENTITY_NAME=automatic-uami
LOCATION=eastus
SUBSCRIPTION_ID=$(az account show --query id -o tsv)

Criar um grupo de recursos

Um grupo de recursos Azure é um grupo lógico no qual Azure recursos são implementados e geridos.

Crie um grupo de recursos usando o comando az group create .

az group create -n ${RG_NAME} -l ${LOCATION}

O exemplo de saída a seguir ilustra a criação bem-sucedida do grupo de recursos:

{
  "id": "/subscriptions/<guid>/resourceGroups/automatic-rg",
  "location": "canadacentral",
  "managedBy": null,
  "name": "automatic-rg",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null
}

Criar uma rede virtual

Crie uma rede virtual usando o az network vnet create comando. Crie uma sub-rede de servidor de API e uma sub-rede de cluster usando o az network vnet subnet create comando.

Ao usar uma rede virtual personalizada com AKS Automatic, deve criar uma sub-rede de servidor API. O AKS delega a sub-rede ao Microsoft.ContainerService/managedClusters em teu nome, o que concede permissões ao serviço AKS para injetar os pods do servidor API e o balanceador de carga interno nessa subrede. Você não pode usar a sub-rede para outras cargas de trabalho, mas pode usá-la para vários clusters AKS localizados na mesma rede virtual. O tamanho mínimo suportado da sub-rede do servidor API é / 28.

Advertência

Um cluster do AKS reserva pelo menos nove (9) endereços IP no espaço de endereços da sub-rede. Ficar sem endereços IP pode impedir a escalabilidade do servidor API e causar uma falha do servidor API.

az network vnet create --name ${VNET_NAME} \
--resource-group ${RG_NAME} \
--location ${LOCATION} \
--address-prefixes 172.19.0.0/16

az network vnet subnet create --resource-group ${RG_NAME} \
--vnet-name ${VNET_NAME} \
--name apiServerSubnet \
--delegations Microsoft.ContainerService/managedClusters \
--address-prefixes 172.19.0.0/28

az network vnet subnet create --resource-group ${RG_NAME} \
--vnet-name ${VNET_NAME} \
--name userNodeSubnet \
--address-prefixes 172.19.1.0/24

az network vnet subnet create --resource-group ${RG_NAME} \
--vnet-name ${VNET_NAME} \
--name managedSystemNodeSubnet \
--address-prefixes 172.19.0.64/26

Regras do grupo de segurança de rede

Todo o tráfego dentro da rede virtual é permitido por padrão. Mas se você adicionou regras do NSG (Grupo de Segurança de Rede) para restringir o tráfego entre sub-redes diferentes, certifique-se de que as regras de segurança do NSG permitam os seguintes tipos de comunicação:

Destino Fonte Protocolo Porto Utilização
APIServer Sub-Rede CIDR Subrede de nós de utilizador e sub-rede de nós de sistema TCP 443 e 4443 Necessário para habilitar a comunicação entre nós e o servidor de API.
APIServer Sub-Rede CIDR Balanceador de Carga do Azure TCP 9988 Necessário para permitir a comunicação entre o Balanceador de Carga do Azure e o servidor API. Também pode ativar toda a comunicação entre o Balanceador de Carga do Azure e o API Server Subnet CIDR.
Nó CIDR Nó CIDR Todos os Protocolos Todos os Portos Necessário para permitir a comunicação entre nós.
Nó CIDR Pod CIDR Todos os Protocolos Todos os Portos Necessário para roteamento de tráfego de serviço.
Pod CIDR Pod CIDR Todos os Protocolos Todos os Portos Necessário para o tráfego de Pod to Pod e Pod to Service, incluindo DNS.

Criar uma identidade gerenciada e dar-lhe permissões na rede virtual

Crie uma identidade gerenciada usando o az identity create comando e recupere o ID principal. Atribua a função de Colaborador de Rede na rede virtual à identidade gerenciada usando o az role assignment create comando.

az identity create \
--resource-group ${RG_NAME} \
 --name ${IDENTITY_NAME} \
 --location ${LOCATION}

IDENTITY_PRINCIPAL_ID=$(az identity show --resource-group ${RG_NAME} --name ${IDENTITY_NAME} --query principalId -o tsv)

az role assignment create \
--scope "/subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${RG_NAME}/providers/Microsoft.Network/virtualNetworks/${VNET_NAME}" \
--role "Network Contributor" \
--assignee-object-id "${IDENTITY_PRINCIPAL_ID}" \
--assignee-principal-type ServicePrincipal

Criar um cluster privado do AKS Automatic em uma rede virtual personalizada

Para criar um cluster privado do AKS Automatic, use o comando az aks create . Observe o uso da --enable-private-cluster bandeira.

Observação

Pode consultar a documentação do cluster privado para configurar outras opções, como desativar o FQDN público do cluster e configurar a zona DNS privada.

az aks create \
--resource-group ${RG_NAME} \
--name ${CLUSTER_NAME} \
--location ${LOCATION} \
--apiserver-subnet-id "/subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${RG_NAME}/providers/Microsoft.Network/virtualNetworks/${VNET_NAME}/subnets/apiServerSubnet" \
--node-subnet-id "/subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${RG_NAME}/providers/Microsoft.Network/virtualNetworks/${VNET_NAME}/subnets/userNodeSubnet" \
--system-node-subnet-id "/subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${RG_NAME}/providers/Microsoft.Network/virtualNetworks/${VNET_NAME}/subnets/managedSystemNodeSubnet" 
--assign-identity "/subscriptions/${SUBSCRIPTION_ID}/resourcegroups/${RG_NAME}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/${IDENTITY_NAME}" \
--sku automatic \
--enable-private-cluster \
--no-ssh-key

Após alguns minutos, o comando conclui e retorna informações formatadas em JSON sobre o cluster.

Conectar-se ao cluster

Quando um cluster AKS Automatic é criado como um cluster privado, o ponto de extremidade do servidor API não tem endereço IP público. Para gerir o servidor API, por exemplo via kubectl, é necessário ligar-se através de uma máquina que tenha acesso à rede virtual Azure do cluster. Existem várias opções para estabelecer conectividade de rede com o cluster privado:

  • Crie uma máquina virtual na mesma rede virtual que o cluster AKS Automatic usando o az vm create comando com o --vnet-name sinalizador.
  • Use uma máquina virtual em uma rede virtual separada e configure o emparelhamento de rede virtual.
  • Use uma Rota Expressa ou uma conexão VPN.
  • Utilize uma conexão de ponto de extremidade privado.

Criar uma máquina virtual na mesma rede virtual que o cluster AKS é a opção mais fácil. ExpressRoute e VPNs acrescentam custos e exigem outra complexidade de rede. O emparelhamento de rede virtual requer que você planeje seus intervalos CIDR de rede para garantir que não haja intervalos sobrepostos. Para mais informações, consulte Opções para ligação ao cluster privado.

Para gerenciar um cluster Kubernetes, use o cliente de linha de comando Kubernetes, kubectl. kubectl já está instalado se usares Azure Cloud Shell. Para instalar kubectl localmente, execute o comando az aks install-cli . Os clusters automáticos do AKS estão configurados com Microsoft Entra ID para controlo de acesso por funções (RBAC) do Kubernetes.

Quando crias um cluster usando o CLI do Azure, o teu utilizador é atribuído papéis incorporados para Azure Kubernetes Service RBAC Cluster Admin.

Configure kubectl para se conectar ao cluster Kubernetes usando o comando az aks get-credentials. Este comando baixa credenciais e configura a CLI do Kubernetes para usá-las.

az aks get-credentials --resource-group ${RG_NAME} --name ${CLUSTER_NAME}

Verifique a conexão com seu cluster usando o comando kubectl get . Este comando retorna uma lista dos nós do cluster.

kubectl get nodes

O resultado de exemplo seguinte mostra como lhe é pedido para iniciar sessão.

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code AAAAAAAAA to authenticate.

Após iniciar sessão, o seguinte resultado de exemplo mostra os conjuntos de nós do sistema geridos. Verifique se o status do nó é Pronto.

NAME                           STATUS   ROLES    AGE   VERSION
aks-hostedpool-16652789-vms1   Ready    <none>   19m   v1.34.7
aks-hostedpool-16652789-vms2   Ready    <none>   19m   v1.34.7
aks-hostedpool-16652789-vms3   Ready    <none>   19m   v1.34.7
aks-system-surge-zq4d2         Ready    <none>   19m   v1.34.7

Criar uma rede virtual

Este ficheiro Bicep define uma rede virtual.

@description('The location of the managed cluster resource.')
param location string = resourceGroup().location

@description('The name of the virtual network.')
param vnetName string = 'aksAutomaticVnet'

@description('The address prefix of the virtual network.')
param addressPrefix string = '172.19.0.0/16'

@description('The name of the API server subnet.')
param apiServerSubnetName string = 'apiServerSubnet'

@description('The subnet prefix of the API server subnet.')
param apiServerSubnetPrefix string = '172.19.0.0/28'

@description('The name of the user node subnet.')
param userNodeSubnetName string = 'userNodeSubnet'

@description('The subnet prefix of the user node subnet.')
param userNodeSubnetPrefix string = '172.19.1.0/24'

@description('The name of the system node subnet.')
param systemNodeSubnetName string = 'systemNodeSubnet'

@description('The subnet prefix of the system node subnet.')
param systemNodeSubnetPrefix string = '172.19.0.64/26'

// Virtual network with an API server subnet, a user node subnet, and a system node subnet
resource virtualNetwork 'Microsoft.Network/virtualNetworks@2023-09-01' = {
    name: vnetName
    location: location
    properties: {
        addressSpace: {
            addressPrefixes: [ addressPrefix ]
        }
        subnets: [
            {
                name: apiServerSubnetName
                properties: {
                    addressPrefix: apiServerSubnetPrefix
                }
            }
            {
                name: userNodeSubnetName
                properties: {
                    addressPrefix: userNodeSubnetPrefix
                }
            }
            {
                name: systemNodeSubnetName
                properties: {
                    addressPrefix: systemNodeSubnetPrefix
                }
            }
        ]
    }
}

output apiServerSubnetId string = resourceId('Microsoft.Network/virtualNetworks/subnets', vnetName, apiServerSubnetName)
output userNodeSubnetId string = resourceId('Microsoft.Network/virtualNetworks/subnets', vnetName, userNodeSubnetName)
output systemNodeSubnetId string = resourceId('Microsoft.Network/virtualNetworks/subnets', vnetName, systemNodeSubnetName)

Guarde o ficheiro Bicep virtualNetwork.bicep para o seu computador local.

Importante

O ficheiro Bicep define o parâmetro vnetName para aksAutomaticVnet, o parâmetro addressPrefix para 172.19.0.0/16, o parâmetro apiServerSubnetPrefix para 172.19.0.0/28, e o parâmetro apiServerSubnetPrefix para 172.19.1.0/24. Se você quiser usar valores diferentes, certifique-se de atualizar as cadeias de caracteres para seus valores preferidos.

Implemente o ficheiro Bicep usando a CLI do Azure.

az deployment group create --resource-group <resource-group> --template-file virtualNetwork.bicep

Todo o tráfego dentro da rede virtual é permitido por padrão. Mas se você adicionou regras do NSG (Grupo de Segurança de Rede) para restringir o tráfego entre sub-redes diferentes, certifique-se de que as regras de segurança do NSG permitam os seguintes tipos de comunicação:

Destino Fonte Protocolo Porto Utilização
APIServer Sub-Rede CIDR Subrede de nós de utilizador e sub-rede de nós de sistema TCP 443 e 4443 Necessário para habilitar a comunicação entre nós e o servidor de API.
APIServer Sub-Rede CIDR Balanceador de Carga do Azure TCP 9988 Necessário para permitir a comunicação entre o Balanceador de Carga do Azure e o servidor API. Também pode ativar toda a comunicação entre o Balanceador de Carga do Azure e o API Server Subnet CIDR.
Nó CIDR Nó CIDR Todos os Protocolos Todos os Portos Necessário para permitir a comunicação entre nós.
Nó CIDR Pod CIDR Todos os Protocolos Todos os Portos Necessário para roteamento de tráfego de serviço.
Pod CIDR Pod CIDR Todos os Protocolos Todos os Portos Necessário para o tráfego de Pod to Pod e Pod to Service, incluindo DNS.

Criar uma identidade gerenciada

Este ficheiro Bicep define uma identidade gerida atribuída pelo próprio utilizador.

param location string = resourceGroup().location
param uamiName string = 'aksAutomaticUAMI'

resource userAssignedManagedIdentity 'Microsoft.ManagedIdentity/userAssignedIdentities@2023-01-31' = {
  name: uamiName
  location: location
}

output uamiId string = userAssignedManagedIdentity.id
output uamiPrincipalId string = userAssignedManagedIdentity.properties.principalId
output uamiClientId string = userAssignedManagedIdentity.properties.clientId

Guardar o ficheiro Bicep uami.bicep para o seu computador local.

Importante

O ficheiro Bicep define o param uamiName para aksAutomaticUAMI. Se você quiser usar um nome de identidade diferente, atualize a cadeia de caracteres para seu nome preferido.

Implemente o ficheiro Bicep usando a CLI do Azure.

az deployment group create --resource-group <resource-group> --template-file uami.bicep

Atribuir a função de Colaborador de Rede sobre a rede virtual

Este ficheiro Bicep define atribuições de funções na rede virtual.

@description('The name of the virtual network.')
param vnetName string = 'aksAutomaticVnet'

@description('The principal ID of the user assigned managed identity.')
param uamiPrincipalId string

// Get a reference to the virtual network
resource virtualNetwork 'Microsoft.Network/virtualNetworks@2023-09-01' existing ={
  name: vnetName
}

// Assign the Network Contributor role to the user assigned managed identity on the virtual network
// '4d97b98b-1d4f-4787-a291-c67834d212e7' is the built-in Network Contributor role definition
// See: https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/networking#network-contributor
resource networkContributorRoleAssignmentToVirtualNetwork 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(uamiPrincipalId, '4d97b98b-1d4f-4787-a291-c67834d212e7', resourceGroup().id, virtualNetwork.name)
  scope: virtualNetwork
  properties: {
      roleDefinitionId: resourceId('Microsoft.Authorization/roleDefinitions', '4d97b98b-1d4f-4787-a291-c67834d212e7')
      principalId: uamiPrincipalId
  }
}

Guardar o ficheiro Bicep roleAssignments.bicep para o seu computador local.

Importante

O ficheiro Bicep define o param vnetName para aksAutomaticVnet. Se você usou um nome de rede virtual diferente, certifique-se de atualizar a cadeia de caracteres para seu nome de rede virtual preferido.

Implemente o ficheiro Bicep usando a CLI do Azure. Você precisa fornecer o ID principal de identidade atribuído ao usuário.

az deployment group create --resource-group <resource-group> --template-file roleAssignments.bicep \
--parameters uamiPrincipalId=<user assigned identity prinicipal id>

Criar um cluster privado do AKS Automatic em uma rede virtual personalizada

Este ficheiro Bicep define o cluster automático do AKS.

Observação

Podes consultar a documentação do cluster privado para configurar outras opções, como desativar o FQDN público do cluster e configurar a zona DNS privada.

@description('The name of the managed cluster resource.')
param clusterName string = 'aksPrivateAutomaticCluster'

@description('The location of the managed cluster resource.')
param location string = resourceGroup().location

@description('The resource ID of the API server subnet.')
param apiServerSubnetId string

@description('The resource ID of the user node subnet.')
param userNodeSubnetId string

@description('The resource ID of the system node subnet.')
param systemNodeSubnetId string

@description('The resource ID of the user assigned managed identity.')
param uamiId string

/// Create the private AKS Automatic cluster using the custom virtual network and user assigned managed identity
resource aks 'Microsoft.ContainerService/managedClusters@2024-03-02-preview' = {
  name: clusterName
  location: location  
  sku: {
    name: 'Automatic'
  }
  properties: {
    apiServerAccessProfile: {
        subnetId: apiServerSubnetId
        enablePrivateCluster: true
    }
    networkProfile: {
      outboundType: 'loadBalancer'
    }
    hostedSystemProfile: {
      systemNodeSubnetID: systemNodeSubnetId
      nodeSubnetID: userNodeSubnetId
    }
  }
  identity: {
    type: 'UserAssigned'
    userAssignedIdentities: {
      '${uamiId}': {}
    }
  }
}

Guardar o ficheiro Bicep aks.bicep para o seu computador local.

Importante

O ficheiro Bicep define o param clusterName para aksPrivateAutomaticCluster. Se você quiser um nome de cluster diferente, atualize a cadeia de caracteres para o nome do cluster de sua preferência.

Implemente o ficheiro Bicep usando a CLI do Azure. É necessário fornecer o ID de recurso de sub-rede do servidor API, o ID de recurso de sub-rede do nó do utilizador, o ID de recurso de sub-rede do nó do sistema e o ID de recurso de identidade gerida atribuído pelo utilizador.

az deployment group create --resource-group <resource-group> --template-file aks.bicep \
--parameters apiServerSubnetId=<API server subnet resource id> \
--parameters nodeSubnetId=<user node subnet resource id> \
--parameters systemNodeSubnetId=<system node subnet resource id> \
--parameters uamiPrincipalId=<user assigned identity prinicipal id>

Conectar-se ao cluster

Quando um cluster AKS Automatic é criado como um cluster privado, o ponto de extremidade do servidor API não tem endereço IP público. Para gerir o servidor API, por exemplo via kubectl, é necessário ligar-se através de uma máquina que tenha acesso à rede virtual Azure do cluster. Existem várias opções para estabelecer conectividade de rede com o cluster privado:

  • Crie uma máquina virtual na mesma rede virtual que o cluster AKS Automatic usando o az vm create comando com o --vnet-name sinalizador.
  • Use uma máquina virtual em uma rede virtual separada e configure o emparelhamento de rede virtual.
  • Use uma Rota Expressa ou uma conexão VPN.
  • Utilize uma conexão de ponto de extremidade privado.

Criar uma máquina virtual na mesma rede virtual que o cluster AKS é a opção mais fácil. Express Route e VPNs acrescentam custos e exigem maior complexidade de rede. O emparelhamento de rede virtual requer que você planeje seus intervalos CIDR de rede para garantir que não haja intervalos sobrepostos. Para mais informações, consulte Opções para ligação ao cluster privado.

Para gerenciar um cluster Kubernetes, use o cliente de linha de comando Kubernetes, kubectl. kubectl já está instalado se usares Azure Cloud Shell. Para instalar kubectl localmente, execute o comando az aks install-cli . Os clusters automáticos do AKS estão configurados com Microsoft Entra ID para controlo de acesso por funções (RBAC) do Kubernetes.

Importante

Quando crias um cluster usando Bicep, precisas de atribuir um dos papéis incorporados como Azure Kubernetes Service RBAC Reader, Azure Kubernetes Service RBAC Writer, Azure Kubernetes Service RBAC Admin ou Azure Kubernetes Service RBAC Cluster Admin aos teus utilizadores, com o âmbito do cluster ou de um namespace específico, por exemplo usando az role assignment create --role "Azure Kubernetes Service RBAC Cluster Admin" --scope <AKS cluster resource id> --assignee user@contoso.com. Também certifica-te de que os teus utilizadores têm o papel incorporado Azure Kubernetes Service Cluster User para poderem executar az aks get-credentials, e depois obter o kubeconfig do teu cluster AKS usando o comando az aks get-credentials.

Configure kubectl para se conectar ao cluster Kubernetes usando o comando az aks get-credentials. Este comando baixa credenciais e configura a CLI do Kubernetes para usá-las.

az aks get-credentials --resource-group <resource-group> --name <cluster-name>

Verifique a conexão com seu cluster usando o comando kubectl get . Este comando retorna uma lista dos nós do cluster.

kubectl get nodes

O resultado de exemplo seguinte mostra como lhe é pedido para iniciar sessão.

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code AAAAAAAAA to authenticate.

Após iniciar sessão, o seguinte resultado de exemplo mostra os conjuntos de nós do sistema geridos. Verifique se o status do nó é Pronto.

NAME                           STATUS   ROLES    AGE   VERSION
aks-hostedpool-16652789-vms1   Ready    <none>   19m   v1.34.7
aks-hostedpool-16652789-vms2   Ready    <none>   19m   v1.34.7
aks-hostedpool-16652789-vms3   Ready    <none>   19m   v1.34.7
aks-system-surge-zq4d2         Ready    <none>   19m   v1.34.7

Implantar o aplicativo

Para implementar a aplicação, utiliza-se um ficheiro manifesto para criar todos os objetos necessários para executar a aplicação AKS Store. Um arquivo de manifesto do Kubernetes define o estado desejado de um cluster, como quais imagens de contêiner devem ser executadas. O manifesto inclui as seguintes implantações e serviços do Kubernetes:

Captura de ecrã da arquitetura de exemplos Azure Store.

  • Vitrine: aplicativo Web para que os clientes visualizem produtos e façam pedidos.
  • Serviço do produto: Mostra as informações do produto.
  • Serviço de pedidos: Faz pedidos.
  • Rabbit MQ: Fila de mensagens para processamento de pedidos.

Observação

Não recomendamos a execução de contentores com estado, como Rabbit MQ, sem armazenamento persistente para produção. Estes contentores são usados aqui para simplificar, mas recomendamos o uso de serviços geridos, como o Azure Cosmos DB ou o Azure Service Bus.

  1. Crie um namespace aks-store-demo para implantar os recursos do Kubernetes.

    kubectl create ns aks-store-demo
    
  2. Implante o aplicativo usando o comando kubectl apply no aks-store-demo namespace. O ficheiro YAML que define a implementação está em GitHub.

    kubectl apply -n aks-store-demo -f https://raw.githubusercontent.com/Azure-Samples/aks-store-demo/main/aks-store-ingress-quickstart.yaml
    

    O exemplo seguinte mostra as implementações e os serviços:

    statefulset.apps/rabbitmq created
    configmap/rabbitmq-enabled-plugins created
    service/rabbitmq created
    deployment.apps/order-service created
    service/order-service created
    deployment.apps/product-service created
    service/product-service created
    deployment.apps/store-front created
    service/store-front created
    ingress/store-front created
    

Testar a aplicação

Quando o aplicativo é executado, um serviço Kubernetes expõe o front-end do aplicativo à Internet. Este processo pode demorar alguns minutos a concluir.

  1. Verifique o status dos pods implantados usando o comando kubectl get pods . Certifique-se de que todos os pods estejam Running antes de prosseguir. Se esta for a primeira carga de trabalho que implementa, poderá demorar alguns minutos até que o aprovisionamento automático de nós crie um conjunto de nós para executar os pods.

    kubectl get pods -n aks-store-demo
    
  2. Verifique se há um endereço IP público para a aplicação de loja. Monitore o progresso utilizando o comando kubectl get service com o argumento --watch.

    kubectl get ingress store-front -n aks-store-demo --watch
    

    A saída ADDRESS para o store-front serviço inicialmente mostra vazio:

    NAME          CLASS                                HOSTS   ADDRESS        PORTS   AGE
    store-front   webapprouting.kubernetes.azure.com   *                      80      12m
    
  3. Quando o ENDEREÇO mudar de um estado em branco para um endereço IP público real, use CTRL-C para parar o processo de kubectl monitorização.

    A saída de exemplo a seguir mostra um endereço IP público válido atribuído ao serviço:

    NAME          CLASS                                HOSTS   ADDRESS        PORTS   AGE
    store-front   webapprouting.kubernetes.azure.com   *       4.255.22.196   80      12m
    
  4. Abra um navegador web no endereço IP externo do seu acesso para ver a aplicação Azure Store em ação.

    Captura de ecrã da aplicação de exemplo AKS Store.

Eliminar o cluster

Se não planeias seguir o tutorial AKS, elimina recursos desnecessários para evitar encargos do Azure. Execute o comando az group delete para remover o grupo de recursos, o serviço de contêiner e todos os recursos relacionados.

az group delete --name <resource-group> --yes --no-wait

Observação

O cluster AKS foi criado com uma identidade gerenciada atribuída pelo usuário. Se já não precisar dessa identidade, pode removê-la manualmente.

Próximos passos

Neste início rápido, você implantou um cluster Kubernetes privado usando o AKS Automatic dentro de uma rede virtual personalizada e, em seguida, implantou um aplicativo simples de vários contêineres nele. Este aplicativo de exemplo é apenas para fins de demonstração e não representa todas as práticas recomendadas para aplicativos Kubernetes. Para obter orientação sobre como criar soluções completas com o AKS para produção, consulte Orientação de solução AKS.

Para saber mais sobre o AKS Automatic, continue para a introdução.