Inicio rápido: Creación de un clúster de Azure Kubernetes Service (AKS) automático privado en una red virtual personalizada

Se aplica a: ✔️ AKS Automatic

Azure Kubernetes Service (AKS) Automatic proporciona la experiencia de Kubernetes administrada más sencilla para desarrolladores, ingenieros de DevOps e ingenieros de plataforma. Ideal para aplicaciones modernas y de inteligencia artificial, AKS Automatic automatiza la configuración y las operaciones del clúster de AKS e inserta las configuraciones de procedimientos recomendados. Los usuarios de cualquier nivel de aptitud pueden beneficiarse de la seguridad, el rendimiento y la dependencia de AKS Automatic para sus aplicaciones. AKS Automatic también incluye un SLA de preparación de pods que garantiza que el 99,9% de las operaciones de preparación de pods que califican se completen en 5 minutos, garantizando una infraestructura fiable y autorreparable para tus aplicaciones. En esta guía rápida se presupone un conocimiento básico de los conceptos de Kubernetes. Para obtener más información, consulte Kubernetes conceptos básicos de Azure Kubernetes Service (AKS).

En este inicio rápido va a aprender a:

  • Cree una red virtual.
  • Cree una identidad administrada con permisos a través de la red virtual.
  • Implemente un clúster automático de AKS privado en la red virtual.
  • Conéctese al clúster privado.
  • Ejecute una aplicación de muestra de varios contenedores con un grupo de microservicios e interfaces web simulando un escenario de venta minorista.

Prerrequisitos

  • Si no tiene una cuenta de Azure, cree una cuenta free.
  • CLI de Azure versión 2.86.0 o posterior. Para buscar la versión, ejecute el az --version comando . Si necesita instalar o actualizar, consulte Install CLI de Azure.

Nota:

Este ejemplo crea el clúster AKS Automatic con el recurso azurerm_kubernetes_automatic_cluster del proveedor AzureRM, que requiere la versión v4.81 o posterior del proveedor AzureRM. Para ver un ejemplo equivalente que usa el proveedor AzAPI, consulte el ejemplo 101-aks-automatic-private-custom-network-azapi .

Importante

A partir de AKS 1.36, los nuevos clústeres automáticos de AKS habilitarán de forma predeterminada la API de puerta de enlace de Kubernetes a través del complemento de enrutamiento de aplicaciones en lugar de Entrada NGINX administrada con el complemento de enrutamiento de aplicaciones debido a la Retirada de NGINX de entrada ascendente.

Los clústeres automáticos existentes no se ven afectados, pero deben comenzar la migración a la API de puerta de enlace de Kubernetes a través del complemento de enrutamiento de aplicaciones.

Limitaciones

Las limitaciones siguientes se aplican a los clústeres automáticos de AKS:

  • AKS Automatic está disponible de forma general en las siguientes regiones: australiacentral, australiaeast, austriaeast, canadacentral, southafricanorth, canadaeast, southcentralus, centralindia, southeastasia, centralus, southindia, chilecentral, spaincentral, denmarkeast, swedencentral, eastasia, westus3, eastus2, westus2, francecentral, westus, eastus, westeurope, germanywestcentral, brazilsouth, northeurope, indonesiacentral, norwayeast, israelcentral, polandcentral, ukwest, northcentralus, westcentralus, uksouth, uaenorth, switzerlandnorth, newzealandnorth, mexicocentral, malaysiawest, koreasouth, japanwest, italynorth, koreacentral, australiasoutheast, belgiumcentral, japaneast.
  • Los nuevos clústeres automáticos de AKS habilitan de forma predeterminada grupos de nodos del sistema administrados y LocalDNS. No se pueden crear clústeres automáticos de AKS sin grupos de nodos del sistema administrados en ninguna región.
  • El clúster automático de AKS tiene node resource group lockdown preconfigurado, que no permite cambios en el grupo de recursos MC_, lo que impide vínculos de red virtual en la zona de DNS privado predeterminada. Para escenarios de redes virtuales cruzadas o DNS personalizados, utilice una red personalizada y un DNS privado siguiendo Crear un clúster automático privado de Azure Kubernetes Service (AKS) en una red virtual personalizada.
  • se requiere CLI de Azure versión 2.86.0 o posterior. Para buscar la versión, ejecute el az --version comando . Si necesita instalar o actualizar, consulte Install CLI de Azure.
  • No se admiten las siguientes extensiones:
  • No se admiten los nodos de Windows.
  • No se admite la migración de la SKU base de AKS a la SKU automática.
  • La migración desde un clúster automático de AKS existente sin grupos de nodos de sistema administrados a AKS Automatic con grupos de nodos de sistema administrados se admite en versión preliminar en las regiones en las que los grupos de nodos del sistema administrados están disponibles con carácter general. No se admite la migración desde AKS Automatic con grupos de nodos del sistema administrados a AKS Automatic sin grupos de nodos del sistema administrados.

Definición de variables

Defina las siguientes variables que se usan en los pasos posteriores.

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)

Creación de un grupo de recursos

Un grupo de recursos Azure es un grupo lógico en el que se implementan y administran los recursos Azure.

Cree un grupo de recursos con el comando az group create.

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

La salida del siguiente ejemplo es similar a la creación correcta del grupo de recursos:

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

Creación de una red virtual

Cree una red virtual mediante el comando az network vnet create. Cree una subred del servidor de API y una subred de clúster mediante el az network vnet subnet create comando .

Al usar una red virtual personalizada con AKS Automatic, debe crear una subred del servidor de API. AKS delega la subred en Microsoft.ContainerService/managedClusters en su nombre, lo que concede al servicio AKS permisos para inyectar los pods del servidor de la API y el equilibrador de carga interno en esa subred. No puede usar la subred para ninguna otra carga de trabajo, pero puede usarla para la subred del servidor de API para varios clústeres de AKS ubicados en la misma red virtual. El tamaño mínimo admitido de subred del servidor de API para admitir un único clúster es /28.

Advertencia

Un clúster de AKS reserva al menos nueve (9) direcciones IP en el espacio de direcciones de subred. Quedarse sin direcciones IP podría impedir el escalado del servidor API y provocar una interrupción del 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

Reglas del grupo de seguridad de red

Todo el tráfico dentro de la red virtual se permite de forma predeterminada. Pero si ha agregado reglas de grupo de seguridad de red (NSG) para restringir el tráfico entre diferentes subredes, asegúrese de que las reglas de seguridad de NSG permiten los siguientes tipos de comunicación:

Destino Fuente Protocolo Puerto Uso
CIDR de subred de APIServer subred del nodo de usuario y subred del nodo del sistema TCP 443 y 4443 Necesario para habilitar la comunicación entre nodos y el servidor de API.
CIDR de subred de APIServer Azure Load Balancer TCP 9988 Necesario para habilitar la comunicación entre Azure Load Balancer y el servidor de API. También puede habilitar toda la comunicación entre el Azure Load Balancer y el CIDR de subred del servidor de API.
CIDR de nodo CIDR de nodo Todos los protocolos Todos los puertos Necesario para habilitar la comunicación entre nodos.
CIDR de nodo Pod CIDR Todos los protocolos Todos los puertos Necesario para el enrutamiento del tráfico del servicio.
Pod CIDR Pod CIDR Todos los protocolos Todos los puertos Necesario para pod a pod y pod al tráfico de servicio, incluido DNS.

Creación de una identidad administrada y concesión de permisos en la red virtual

Cree una identidad administrada mediante el comando az identity create y recupere el identificador principal. Asigne el rol Colaborador de Red en la red virtual a la identidad administrada usando el comando az role assignment create.

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

Creación de un clúster automático de AKS privado en una red virtual personalizada

Para crear un clúster automático de AKS privado, use el comando az aks create . Observe el uso de la --enable-private-cluster bandera.

Nota:

Puede consultar la documentación del clúster privado para configurar otras opciones, como deshabilitar el FQDN público del clúster y configurar la 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

Transcurridos unos minutos, el comando se completa y devuelve información en formato JSON sobre el clúster.

Conectarse al clúster

Cuando se crea un clúster automático de AKS como un clúster privado, el punto de conexión del servidor de API no tiene ninguna dirección IP pública. Para administrar el servidor de API, por ejemplo, a través de kubectl, debe conectarse a través de una máquina que tenga acceso a la red virtual Azure del clúster. Hay varias opciones para establecer la conectividad de red con el clúster privado:

La creación de una máquina virtual en la misma red virtual que el clúster de AKS es la opción más sencilla. ExpressRoute y VPN agregan costos y requieren otra complejidad de red. Para utilizar el emparejamiento de red virtual, debe planear los intervalos CIDR de la red para asegurarse de que no haya intervalos superpuestos. Para obtener más información, consulte Opciones para conectarse al clúster privado.

Para administrar un clúster de Kubernetes, use kubectl, el cliente de línea de comandos de Kubernetes. kubectl ya está instalado si usa Azure Cloud Shell. Para instalar kubectl localmente, ejecute el comando az aks install-cli. Los clústeres automáticos de AKS se configuran con Microsoft Entra ID para el control de acceso basado en rol (RBAC) de Kubernetes .

Al crear un clúster mediante el CLI de Azure, a su usuario se le asignaron roles integrados para Azure Kubernetes Service RBAC Cluster Admin.

Para configurar kubectl para conectarse a su clúster de Kubernetes, use el comando az aks get-credentials. Con este comando se descargan las credenciales y se configura la CLI de Kubernetes para usarlas.

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

Para comprobar la conexión al clúster, ejecute el comando kubectl get. Este comando devuelve una lista de los nodos del clúster.

kubectl get nodes

La siguiente salida de ejemplo muestra cómo se le solicita iniciar sesión.

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

Después de iniciar sesión, la siguiente salida de ejemplo muestra los grupos de nodos del sistema administrado. Asegúrese de que el estado del nodo es Listo.

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

Creación de una red virtual

Este archivo Bicep define una red 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 el archivo Bicep virtualNetwork.bicep al equipo local.

Importante

El archivo Bicep establece el parámetro vnetName en aksAutomaticVnet, el parámetro addressPrefix en 172.19.0.0/16apiServerSubnetPrefix param a 172.19.0.0/28 y el parámetro apiServerSubnetPrefix a 172.19.1.0/24. Si desea usar valores diferentes, asegúrese de actualizar las cadenas a sus valores preferidos.

Implemente el archivo Bicep mediante el CLI de Azure.

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

Todo el tráfico dentro de la red virtual se permite de forma predeterminada. Pero si ha agregado reglas de grupo de seguridad de red (NSG) para restringir el tráfico entre diferentes subredes, asegúrese de que las reglas de seguridad de NSG permiten los siguientes tipos de comunicación:

Destino Fuente Protocolo Puerto Uso
CIDR de subred de APIServer subred del nodo de usuario y subred del nodo del sistema TCP 443 y 4443 Necesario para habilitar la comunicación entre nodos y el servidor de API.
CIDR de subred de APIServer Azure Load Balancer TCP 9988 Necesario para habilitar la comunicación entre Azure Load Balancer y el servidor de API. También puede habilitar toda la comunicación entre el Azure Load Balancer y el CIDR de subred del servidor de API.
CIDR de nodo CIDR de nodo Todos los protocolos Todos los puertos Necesario para habilitar la comunicación entre nodos.
CIDR de nodo Pod CIDR Todos los protocolos Todos los puertos Necesario para el enrutamiento del tráfico del servicio.
Pod CIDR Pod CIDR Todos los protocolos Todos los puertos Necesario para pod a pod y pod al tráfico de servicio, incluido DNS.

Crea una identidad administrada

Este archivo Bicep define una identidad administrada asignada por el usuario.

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

Guarde el archivo Bicep uami.bicep en su equipo local.

Importante

El archivo Bicep establece el parámetro uamiName en el aksAutomaticUAMI. Si desea usar un nombre de identidad diferente, asegúrese de actualizar la cadena a su nombre preferido.

Implemente el archivo Bicep mediante el CLI de Azure.

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

Asigna el rol de Colaborador de red a la red virtual

Este archivo Bicep define asignaciones de roles a través de la red 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
  }
}

Guarda el archivo Bicep roleAssignments.bicep en tu equipo local.

Importante

El archivo Bicep establece el parámetro vnetName en aksAutomaticVnet. Si usó un nombre de red virtual diferente, asegúrese de actualizar la cadena al nombre de red virtual preferido.

Implemente el archivo Bicep mediante el CLI de Azure. Debe proporcionar el Id. de entidad de seguridad de identidad asignado por el usuario.

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

Creación de un clúster automático de AKS privado en una red virtual personalizada

Este archivo Bicep define el clúster AKS Automatic.

Nota:

Puede consultar la documentación del clúster privado para configurar otras opciones, como deshabilitar el FQDN público de clústeres y configurar la 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}': {}
    }
  }
}

Guarda el archivo Bicep aks.bicep en tu equipo local.

Importante

El archivo Bicep establece el parámetro clusterName en aksPrivateAutomaticCluster. Si desea un nombre de clúster diferente, asegúrese de actualizar la cadena al nombre de clúster preferido.

Implemente el archivo Bicep mediante el CLI de Azure. Debe proporcionar el identificador de recurso de subred del servidor de API, el identificador de recurso de subred del nodo de usuario, el identificador de recurso de subred del nodo del sistema y el identificador de recurso de identidad administrada asignada por el usuario.

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>

Conectarse al clúster

Cuando se crea un clúster automático de AKS como un clúster privado, el punto de conexión del servidor de API no tiene ninguna dirección IP pública. Para administrar el servidor de API, por ejemplo, a través de kubectl, debe conectarse a través de una máquina que tenga acceso a la red virtual Azure del clúster. Hay varias opciones para establecer la conectividad de red con el clúster privado:

La creación de una máquina virtual en la misma red virtual que el clúster de AKS es la opción más sencilla. ExpressRoute y VPN agregan costos y requieren más complejidad de red. Para utilizar el emparejamiento de red virtual, debe planear los intervalos CIDR de la red para asegurarse de que no haya intervalos superpuestos. Para obtener más información, consulte Opciones para conectarse al clúster privado.

Para administrar un clúster de Kubernetes, use kubectl, el cliente de línea de comandos de Kubernetes. kubectl ya está instalado si usa Azure Cloud Shell. Para instalar kubectl localmente, ejecute el comando az aks install-cli. Los clústeres automáticos de AKS se configuran con Microsoft Entra ID para el control de acceso basado en rol (RBAC) de Kubernetes .

Importante

Al crear un clúster mediante Bicep, debe assignar uno de los roles integrados como Azure Kubernetes Service RBAC Reader, Azure Kubernetes Service RBAC Writer, Azure Kubernetes Service RBAC Admin o Azure Kubernetes Service RBAC Cluster Admin a los usuarios, en el ámbito del clúster o en un espacio de nombres específico, por ejemplo, mediante az role assignment create --role "Azure Kubernetes Service RBAC Cluster Admin" --scope <AKS cluster resource id> --assignee user@contoso.com. Asegúrese también de que los usuarios tengan el rol integrado Azure Kubernetes Service Cluster User para poder ejecutar az aks get-credentials y, a continuación, obtenga el kubeconfig del clúster de AKS mediante el comando az aks get-credentials.

Para configurar kubectl para conectarse a su clúster de Kubernetes, use el comando az aks get-credentials. Con este comando se descargan las credenciales y se configura la CLI de Kubernetes para usarlas.

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

Para comprobar la conexión al clúster, ejecute el comando kubectl get. Este comando devuelve una lista de los nodos del clúster.

kubectl get nodes

La siguiente salida de ejemplo muestra cómo se le solicita iniciar sesión.

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

Después de iniciar sesión, la siguiente salida de ejemplo muestra los grupos de nodos del sistema administrado. Asegúrese de que el estado del nodo es Listo.

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

Revisión del código de Terraform

Nota:

El código de ejemplo de este artículo se encuentra en el repositorio Azure Terraform GitHub. Puedes ver el archivo de registro que contiene los resultados de las pruebas de las versiones actuales y anteriores de Terraform.

Consulte más artículos y código de ejemplo en el que se muestra cómo usar Terraform para administrar recursos de Azure.

  1. Cree un directorio para probar el código de Terraform de ejemplo y establézcalo como directorio actual.

  2. Cree un archivo denominado providers.tf e inserte el siguiente código:

    terraform {
  required_version = ">= 1.0"
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~>5.0"
    }
    random = {
      source  = "hashicorp/random"
      version = "~>3.0"
    }
  }
}

provider "azurerm" {
  features {}
}

  3. Crea un archivo con nombre main.tf y añade el siguiente código:

    # Create a random name for the resource group using random_pet
resource "random_pet" "rg_name" {
  prefix = var.resource_group_name_prefix
}

# Create a resource group using the generated random name
resource "azurerm_resource_group" "rg" {
  location = var.resource_group_location
  name     = random_pet.rg_name.id
}

# Create the custom virtual network that hosts the cluster
resource "azurerm_virtual_network" "vnet" {
  name                = var.virtual_network_name
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  address_space       = var.virtual_network_address_space
}

# Create the subnet delegated to AKS for API Server VNet Integration
resource "azurerm_subnet" "api_server" {
  name                 = "apiServerSubnet"
  resource_group_name  = azurerm_resource_group.rg.name
  virtual_network_name = azurerm_virtual_network.vnet.name
  address_prefixes     = var.api_server_subnet_address_prefixes

  delegation {
    name = "aks-delegation"

    service_delegation {
      name    = "Microsoft.ContainerService/managedClusters"
      actions = ["Microsoft.Network/virtualNetworks/subnets/join/action"]
    }
  }
}

# Create the subnet that hosts the user node pools
resource "azurerm_subnet" "user_nodes" {
  name                 = "userNodeSubnet"
  resource_group_name  = azurerm_resource_group.rg.name
  virtual_network_name = azurerm_virtual_network.vnet.name
  address_prefixes     = var.user_node_subnet_address_prefixes
}

# Create the subnet that hosts the managed system node pool
resource "azurerm_subnet" "system_nodes" {
  name                 = "managedSystemNodeSubnet"
  resource_group_name  = azurerm_resource_group.rg.name
  virtual_network_name = azurerm_virtual_network.vnet.name
  address_prefixes     = var.system_node_subnet_address_prefixes

  lifecycle {
    # AKS adds its own managed cluster delegation to this subnet after the
    # cluster is created.
    ignore_changes = [delegation]
  }
}

# Create the user-assigned managed identity used by the cluster
resource "azurerm_user_assigned_identity" "aks" {
  name                = var.identity_name
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
}

# Grant the cluster identity Network Contributor on the virtual network
resource "azurerm_role_assignment" "network_contributor" {
  scope                = azurerm_virtual_network.vnet.id
  role_definition_name = "Network Contributor"
  principal_id         = azurerm_user_assigned_identity.aks.principal_id
  principal_type       = "ServicePrincipal"
}

# Create a random name for the AKS Automatic cluster
resource "random_pet" "cluster_name" {
  prefix = var.cluster_name_prefix
}

# Create the private AKS Automatic cluster in the custom virtual network
resource "azurerm_kubernetes_automatic_cluster" "aks_automatic" {
  name                = random_pet.cluster_name.id
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name

  identity {
    type         = "UserAssigned"
    identity_ids = [azurerm_user_assigned_identity.aks.id]
  }

  api_server_access {
    subnet_id = azurerm_subnet.api_server.id
  }

  hosted_system {
    node_subnet_id        = azurerm_subnet.user_nodes.id
    system_node_subnet_id = azurerm_subnet.system_nodes.id
  }

  # The private_cluster block gives the API server a private IP address in the
  # virtual network. Reaching it requires private connectivity and DNS
  # resolution of the private FQDN, which peering, a VPN, or ExpressRoute can
  # provide from outside this virtual network.
  private_cluster {
    public_fully_qualified_domain_name_enabled = var.public_fully_qualified_domain_name_enabled
  }

  depends_on = [azurerm_role_assignment.network_contributor]
}

  4. Crea un archivo con nombre variables.tf y añade el siguiente código:

    variable "resource_group_location" {
  type        = string
  default     = "westus2"
  description = "Location of the resource group."
}

variable "resource_group_name_prefix" {
  type        = string
  default     = "rg"
  description = "Prefix of the resource group name that's combined with a random ID so name is unique in your Azure subscription."
}

variable "cluster_name_prefix" {
  type        = string
  default     = "aks-automatic"
  description = "Prefix of the AKS Automatic cluster name that's combined with a random ID so the name is unique in your Azure subscription."
}

variable "public_fully_qualified_domain_name_enabled" {
  type        = bool
  default     = false
  description = "Whether to provision a public FQDN for the private cluster."
}

variable "virtual_network_name" {
  type        = string
  default     = "aks-automatic-vnet"
  description = "Name of the custom virtual network that hosts the cluster."
}

variable "identity_name" {
  type        = string
  default     = "aks-automatic-identity"
  description = "Name of the user-assigned managed identity that the cluster uses."
}

variable "virtual_network_address_space" {
  type        = list(string)
  default     = ["172.19.0.0/16"]
  description = "Address space of the custom virtual network."
}

variable "api_server_subnet_address_prefixes" {
  type        = list(string)
  default     = ["172.19.0.0/28"]
  description = "Address prefixes of the subnet delegated to the cluster API server."
}

variable "user_node_subnet_address_prefixes" {
  type        = list(string)
  default     = ["172.19.1.0/24"]
  description = "Address prefixes of the subnet that hosts the user node pools."
}

variable "system_node_subnet_address_prefixes" {
  type        = list(string)
  default     = ["172.19.0.64/26"]
  description = "Address prefixes of the subnet that hosts the managed system node pool."
}

  5. Cree un archivo denominado outputs.tf e inserte el siguiente código:

    output "resource_group_name" {
  value = azurerm_resource_group.rg.name
}

output "cluster_name" {
  value = azurerm_kubernetes_automatic_cluster.aks_automatic.name
}

output "cluster_id" {
  value = azurerm_kubernetes_automatic_cluster.aks_automatic.id
}

output "node_resource_group_id" {
  value = azurerm_kubernetes_automatic_cluster.aks_automatic.node_resource_group_id
}

output "virtual_network_name" {
  value = azurerm_virtual_network.vnet.name
}

output "private_fully_qualified_domain_name" {
  value = azurerm_kubernetes_automatic_cluster.aks_automatic.private_fully_qualified_domain_name
}

Inicializar Terraform

Ejecute terraform init para inicializar la implementación de Terraform. Este comando descarga los proveedores de Azure necesarios para administrar los recursos de Azure.

terraform init -upgrade

Creación de un plan de ejecución de Terraform

Ejecute terraform plan para crear un plan de ejecución.

terraform plan -out main.tfplan

Aplicación de un plan de ejecución de Terraform

Ejecute terraform apply para aplicar el plan de ejecución a su infraestructura en la nube.

terraform apply main.tfplan

La creación de un clúster automático de AKS tarda varios minutos en completarse.

Comprobación del clúster

  1. Obtenga el nombre del grupo de recursos de Azure y el nombre del clúster.

    resource_group_name=$(terraform output -raw resource_group_name)
cluster_name=$(terraform output -raw cluster_name)

  2. Ejecute az aks show para mostrar el clúster y confirme que es privado y usa la Automatic SKU.

    az aks show --resource-group $resource_group_name --name $cluster_name --query "{name:name, sku:sku, provisioningState:provisioningState, privateCluster:apiServerAccessProfile.enablePrivateCluster}"

Conectarse al clúster

El servidor de API de clúster privado no tiene ninguna dirección IP pública, por lo que la administra desde una máquina que tiene acceso de red a la red virtual del clúster. Tiene varias opciones para establecer esa conectividad:

Para obtener más información, consulte Opciones para conectarse al clúster privado.

Desde una máquina con conectividad a la red virtual, configure kubectl para conectarse al clúster de Kubernetes mediante el comando az aks get-credentials . Los clústeres automáticos de AKS se configuran con Microsoft Entra ID para el control de acceso basado en rol (RBAC) de Kubernetes .

az aks get-credentials --resource-group $resource_group_name --name $cluster_name

Compruebe la conexión al clúster mediante el comando kubectl get .

kubectl get nodes

Implementación de la aplicación

Para implementar la aplicación, use un archivo de manifiesto para crear todos los objetos necesarios para ejecutar la aplicación AKS Store. Un archivo de manifiesto de Kubernetes define el estado deseado del clúster, por ejemplo, qué imágenes de contenedor se van a ejecutar. El manifiesto incluye las siguientes implementaciones y servicios de Kubernetes:

Captura de pantalla de la arquitectura de ejemplo de Azure Store.

  • Tienda en línea: aplicación web para que los clientes vean productos y realicen pedidos.
  • Servicio de producto: muestra información del producto.
  • Servicio de pedidos: realiza pedidos.
  • Rabbit MQ: cola de mensajes para una cola de pedidos.

Nota:

No se recomienda ejecutar contenedores con estado, como Rabbit MQ, sin almacenamiento persistente para producción. Estos contenedores se usan aquí para simplificar, pero se recomienda usar servicios administrados, como Azure Cosmos DB o Azure Service Bus.

  1. Cree un espacio de nombres aks-store-demo para implementar los recursos de Kubernetes.

    kubectl create ns aks-store-demo

  2. Implemente la aplicación mediante el comando kubectl apply en el espacio de nombres aks-store-demo. El archivo YAML que define la implementación está en GitHub.

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

    La salida del siguiente ejemplo muestra las implementaciones y los servicios:

    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

Prueba de la aplicación

Cuando se ejecuta la aplicación, un servicio de Kubernetes expone el front-end de la aplicación a Internet. Este proceso puede tardar unos minutos en completarse.

  1. Compruebe el estado de los pods implementados con el comando kubectl get pods. Asegúrate de que todos los pods tengan el estado Running antes de continuar. Si se trata de la primera carga de trabajo que implementa, el aprovisionamiento automático de nodos puede tardar unos minutos en crear un grupo de nodos para ejecutar los pods.

    kubectl get pods -n aks-store-demo

  2. Comprueba si la aplicación de tienda tiene una dirección IP pública. Para supervisar el progreso, utilice el comando kubectl get service con el argumento --watch.

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

    La salida de ADDRESS del servicio store-front aparece inicialmente vacía:

    NAME          CLASS                                HOSTS   ADDRESS        PORTS   AGE
store-front   webapprouting.kubernetes.azure.com   *                      80      12m

  3. Una vez que ADDRESS cambia de estar en blanco a una dirección IP pública real, use CTRL-C para detener el proceso de monitoreo de kubectl.

    En la salida del ejemplo siguiente se muestra una dirección IP pública válida asignada al servicio:

    NAME          CLASS                                HOSTS   ADDRESS        PORTS   AGE
store-front   webapprouting.kubernetes.azure.com   *       4.255.22.196   80      12m

  4. Abra un explorador web en la dirección IP externa de su punto de entrada para ver la aplicación Azure Store en acción.

    Captura de pantalla de la aplicación de ejemplo de la Tienda AKS.

Eliminación del clúster

Si no planea pasar por el tutorial AKS, elimine los recursos innecesarios para evitar cargos de Azure. Ejecute el comando az group delete para quitar el grupo de recursos, el servicio de contenedor y todos los recursos relacionados.

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

Nota:

El clúster de AKS se creó con una identidad administrada asignada por el usuario. Si ya no necesita esa identidad, puede quitarla manualmente.

Cuando ya no necesite los recursos creados con Terraform, ejecute terraform plan y especifique el indicador destroy.

terraform plan -destroy -out main.destroy.tfplan

Ejecute terraform apply para aplicar el plan de ejecución.

terraform apply main.destroy.tfplan

Pasos siguientes

En este inicio rápido, ha implementado un clúster privado de Kubernetes mediante AKS Automatic dentro de una red virtual personalizada y, a continuación, ha implementado una sencilla aplicación de varios contenedores en él. Esta aplicación de ejemplo es solo para fines de demostración y no representa todos los procedimientos recomendados para las aplicaciones de Kubernetes. Para instrucciones sobre cómo crear soluciones completas con AKS para producción, consulte Guía de soluciones de AKS.

Dado que este clúster es privado, su servidor de API no tiene ninguna dirección IP pública. Para conectarse y administrar el clúster, consulte Opciones para conectarse al clúster privado. Para ver otras opciones de configuración de clúster privado, consulte la documentación del clúster privado .

Para obtener más información sobre AKS Automatic, continúe con la introducción.

Introducción a Azure Kubernetes Service (AKS) Automatic

  • Last updated on