Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
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.
- En este artículo se requiere la versión 2.77.0 o posterior del Azure CLI. Si usa Azure Cloud Shell, la versión más reciente ya está instalada allí. Si necesita instalar o actualizar, consulte Install Azure CLI.
- Identidad de clúster con una
Network Contributorasignación de roles integrada en la subred del servidor de API. - Identidad de clúster con una
Network Contributorasignación de roles integrada en la red virtual para admitir el aprovisionamiento automático de nodos. - Identidad de usuario que accede al clúster con
Azure Kubernetes Service Cluster User RoleyAzure Kubernetes Service RBAC Writer. - Una red virtual con una subred de servidor de API dedicada de al menos
*/28tamaño al que se delegaMicrosoft.ContainerService/managedClusters.- Si hay un grupo de seguridad de red (NSG) asociado a subredes, asegúrese de que las reglas permiten el siguiente tráfico entre los nodos y el servidor de API, entre el Azure Load Balancer y el servidor de API, y para la comunicación de pod a pod.
- Si hay un Azure Firewall u otro método o dispositivo de restricción de salida, asegúrese de que se permiten las reglas de red de salida y los FQDN requeridos.
- AKS Automatic habilitará Azure Policy en tu clúster de AKS, pero debes registrar previamente el proveedor de recursos
Microsoft.PolicyInsightsen tu suscripción para garantizar una experiencia más fluida. Consulte proveedores de recursos de Azure y tipos para obtener más información.
Limitaciones
- El grupo de nodos del sistema de clústeres automáticos de AKS requiere la implementación en regiones de Azure que admiten al menos tres zonas de disponibilidad, Disco OS efímero y Azure Linux OS.
- AKS Automatic está disponible en las siguientes regiones:
australiaeast,austriaeast,belgiumcentral,brazilsouth,canadacentral,centralindia,centralus,chilecentral,denmarkeast,eastasia,eastus,eastus2,francecentral,germanywestcentral,indonesiacentral,israelcentral,italynorth,japaneast,japanwest,koreacentral,malaysiawest,mexicocentral,newzealandnorth,northcentralus,northeurope,norwayeast,polandcentral,southafricanorth,southcentralus,southeastasia,spaincentral,swedencentral,switzerlandnorth,uaenorth,uksouth,westeurope,westus,westus2,westus3. - 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 Private DNS 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.
Importante
AKS Automatic intenta seleccionar dinámicamente un tamaño de máquina virtual para el system grupo de nodos en función de la capacidad disponible en la suscripción. Asegúrese de que la suscripción tiene cuota de 16 vCPUs de cualquiera de las siguientes tamaños de la región en la que va a implementar el clúster: Standard_D4lds_v5, Standard_D4ads_v5, Standard_D4ds_v5, Standard_D4d_v5, Standard_D4d_v4, Standard_DS3_v2, Standard_DS12_v2, Standard_D4alds_v6, Standard_D4lds_v6, o Standard_D4alds_v5. Puede ver las cuotas para familias de VM específicas y enviar solicitudes de aumento de cuota a través del portal de Azure.
Si tiene preguntas adicionales, obtenga más información a través de los documentos de solución de problemas.
Definición de variables
Defina las siguientes variables que se usarán 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": "eastus",
"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 y delegar una subred del servidor de API para Microsoft.ContainerService/managedClusters, lo que concede los permisos del servicio AKS para insertar los pods del servidor de 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 varios clústeres de AKS ubicados en la misma red virtual. El tamaño mínimo admitido de subred del servidor de API es /28.
Advertencia
Un clúster de AKS reserva al menos 9 direcciones IP en el espacio de direcciones de la subred. El agotamiento de direcciones IP puede 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 clusterSubnet \
--address-prefixes 172.19.1.0/24
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 de clúster | 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 ${IDENTITY_PRINCIPAL_ID}
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 opciones adicionales, 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" \
--vnet-subnet-id "/subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${RG_NAME}/providers/Microsoft.Network/virtualNetworks/${VNET_NAME}/subnets/clusterSubnet" \
--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:
- Cree una máquina virtual en la misma red virtual que el clúster automático de AKS usando el comando
az vm createcon la opción--vnet-name. - Use una máquina virtual en una red virtual independiente y configure el emparejamiento de redes virtuales.
- Use una conexión de ExpressRoute o VPN.
- Use una conexión de punto de conexión 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 complejidad adicional 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. Consulte Opciones para conectarse al clúster privado para obtener más información.
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 Azure CLI, 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
El siguiente resultado 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-nodepool1-13213685-vmss000000 Ready agent 2m26s v1.28.5
aks-nodepool1-13213685-vmss000001 Ready agent 2m26s v1.28.5
aks-nodepool1-13213685-vmss000002 Ready agent 2m26s v1.28.5
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 cluster subnet.')
param clusterSubnetName string = 'clusterSubnet'
@description('The subnet prefix of the cluster subnet.')
param clusterSubnetPrefix string = '172.19.1.0/24'
// Virtual network with an API server subnet and a cluster subnet
resource virtualNetwork 'Microsoft.Network/virtualNetworks@2023-09-01' = {
name: vnetName
location: location
properties: {
addressSpace: {
addressPrefixes: [ addressPrefix ]
}
subnets: [
{
name: apiServerSubnetName
properties: {
addressPrefix: apiServerSubnetPrefix
}
}
{
name: clusterSubnetName
properties: {
addressPrefix: clusterSubnetPrefix
}
}
]
}
}
output apiServerSubnetId string = resourceId('Microsoft.Network/virtualNetworks/subnets', vnetName, apiServerSubnetName)
output clusterSubnetId string = resourceId('Microsoft.Network/virtualNetworks/subnets', vnetName, clusterSubnetName)
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 Azure CLI.
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 de clúster | 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. |
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 Azure CLI.
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 Azure CLI. 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 opciones adicionales, 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 = 'aksAutomaticCluster'
@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 cluster subnet.')
param clusterSubnetId 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: {
agentPoolProfiles: [
{
name: 'systempool'
mode: 'System'
count: 3
vnetSubnetID: clusterSubnetId
}
]
apiServerAccessProfile: {
subnetId: apiServerSubnetId
enablePrivateCluster: true
}
networkProfile: {
outboundType: 'loadBalancer'
}
}
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 aksAutomaticCluster. 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 Azure CLI. Debe proporcionar el Id. de recurso de subred del servidor de API, el Id. de recurso de subred del clúster y el Id. de entidad de seguridad de identidad asignado por el usuario.
az deployment group create --resource-group <resource-group> --template-file aks.bicep \
--parameters apiServerSubnetId=<API server subnet resource id> \
--parameters clusterSubnetId=<cluster 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:
- Cree una máquina virtual en la misma red virtual que el clúster automático de AKS usando el comando
az vm createcon la opción--vnet-name. - Use una máquina virtual en una red virtual independiente y configure el emparejamiento de redes virtuales.
- Use una conexión de ExpressRoute o VPN.
- Use una conexión de punto de conexión 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 las VPN incrementan los costos y requieren redes más complejas. Para utilizar el emparejamiento de red virtual, debe planear los intervalos CIDR de la red para asegurarse de que no haya intervalos superpuestos. Consulte Opciones para conectarse al clúster privado para obtener más información.
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
El siguiente resultado 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-nodepool1-13213685-vmss000000 Ready agent 2m26s v1.28.5
aks-nodepool1-13213685-vmss000001 Ready agent 2m26s v1.28.5
aks-nodepool1-13213685-vmss000002 Ready agent 2m26s v1.28.5
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:
- 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.
Cree un espacio de nombres
aks-store-demopara implementar los recursos de Kubernetes.kubectl create ns aks-store-demoImplemente 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.yamlLa 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.
Compruebe el estado de los pods implementados con el comando kubectl get pods. Asegúrate de que todos los pods tengan el estado
Runningantes de continuar. Si se trata de la primera carga de trabajo que implementa, puede tardar unos minutos para que el aprovisionamiento automático de nodos cree un grupo de nodos para ejecutar los pods.kubectl get pods -n aks-store-demoComprueba 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 --watchLa salida de ADDRESS del servicio
store-frontaparece inicialmente vacía:NAME CLASS HOSTS ADDRESS PORTS AGE store-front webapprouting.kubernetes.azure.com * 80 12mUna vez que ADDRESS cambia de estar en blanco a una dirección IP pública real, use
CTRL-Cpara detener el proceso de monitoreo dekubectl.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 12mAbra un explorador web en la dirección IP externa de su punto de entrada para ver la aplicación Azure Store en acción.
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.
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.
Para obtener más información sobre AKS Automatic, continúe con la introducción.