Azure Kubernetes Service (AKS)

Contents
Azure Kubernetes Service (AKS)

Información general
Acerca de AKS
Arquitecturas de las soluciones
Guías de inicio rápido
Implementación de un clúster de AKS
Uso de la CLI de Azure
Uso de Azure PowerShell
Uso de Azure Portal
Uso de una plantilla de Resource Manager
Desarrollo de aplicaciones
Desarrollo con Helm
Tutoriales
Paso 1: Preparación de la aplicación para AKS
2 - Creación de un registro de contenedor
3 - Creación de un clúster de Kubernetes
4 - Ejecución de una aplicación
5 - Escalado de una aplicación
6 - Actualización de una aplicación
7 - Actualización de un clúster
Conceptos
Clústeres y cargas de trabajo
Acceso e identidad
Seguridad
Línea de base de seguridad
Seguridad para aplicaciones y clústeres
Controles de seguridad de Azure Policy
Redes
Storage
Escala
Reparación automática de nodo
Procedimientos recomendados
Arquitectura de línea de base para un clúster de AKS
Para los operadores del clúster
Aislamiento multiempresa y de clúster
Características básicas del programador
Características avanzadas del programador
Autenticación y autorización
Seguridad de clúster
Administración de imágenes de contenedor
Redes
Storage
Continuidad empresarial (BC) y recuperación ante desastres (DR)
Para desarrolladores de aplicaciones
Administración de recursos
Seguridad de pod
Cuotas y límites regionales
Migración a AKS
Planeamiento y ejecución de una migración
Spring Boot
Tomcat
Wildfly
WebLogic
WebSphere
JBoss EAP
Versión compatible de Kubernetes
Protección de la seguridad en el sistema operativo del host
Introducción a los diagnósticos de Azure Kubernetes Service
Ingeniería de software sostenible
Guías paso a paso
Operaciones del clúster
Operaciones del clúster
Escalado de un clúster de AKS
Detención de un clúster de AKS
Uso del mantenimiento planeado (versión preliminar)
Actualización de un clúster de AKS
Uso del Acuerdo de Nivel de Servicio de tiempo de actividad
Uso de grupos de selección de ubicación de proximidad
Actualización de la imagen de nodo
Actualización automática de la imagen de nodo con Acciones de GitHub
Procesamiento de actualizaciones de sistema operativo del nodo
Configuración de un clúster de AKS
Personalización de configuración de nodo (versión preliminar)
Integración de ACR con un clúster de AKS
Creación de nodos virtuales
Uso de nodos virtuales
Uso de la CLI de Azure
Uso de Azure Portal
Uso de escalador automático de clúster
Uso de zonas de disponibilidad
Uso de grupos de nodos
Uso de grupos de varios nodos
Uso del grupo de nodos de acceso puntual
Uso de grupos de nodos del sistema
Implementación de AKS con Terraform
Vista de recursos de Kubernetes de Azure Portal
Uso del panel de Kubernetes
Configuración de volúmenes de datos
Azure Disk: Dinámico
Azure Disk: Estático
Azure Files: Dinámico
Azure Files: Estático
Servidor NFS: estático
Azure NetApp Files
Uso de Ultra Disks de Azure (versión preliminar)
Controladores de almacenamiento CSI
Habilitación de controladores de almacenamiento CSI (versión preliminar)
Controladores CSI de Azure Data Box Disk (versión preliminar)
Controladores CSI de Azure Files (versión preliminar)
Configuración de las redes
Creación o uso de una red virtual existente
Uso de kubenet
Uso de Azure-CNI
Creación de un conjunto de equilibrador de carga interno
Uso de una instancia de Standard Load Balancer
Uso de una dirección IP estática
Entrada
Creación de un controlador básico
Uso del enrutamiento de aplicación HTTP
Uso de la red interna
Habilitación del complemento AGIC para un clúster de AKS existente
Uso de TLS con sus propios certificados
Uso de TLS con Let's Encrypt
Uso de una dirección IP pública dinámica
Uso de una dirección IP pública estática
Salida
Restricción y control del tráfico de salida del clúster
Uso de una ruta definida por el usuario para la salida
Uso de un equilibrador de carga básico y una dirección IP estática
Personalización de CoreDNS
Seguridad y autenticación
Creación de una entidad de servicio
Uso de identidades administradas
Uso de la identidad de pod de AAD (versión preliminar)
Limitación del acceso al archivo de configuración de clúster
Protección del tráfico de pod con directivas de red
Uso de Azure Policy
Uso de directivas de seguridad de pod (versión preliminar)
Definición de intervalos IP de servidor de API autorizado
Control de implementaciones con Azure Policy
Actualización de credenciales del clúster
Habilitar la integración de Azure Active Directory
Azure AD administrado por AKS
Integración de Azure AD (heredado)
Uso de la autorización de Azure RBAC para Kubernetes
Uso del acceso basado en rol de Kubernetes con integración de Azure AD
Rotación de certificados
Creación de un clúster privado
BYOK para discos
Habilitación del cifrado basado en host
Controlador del almacén de secretos de CSI (versión preliminar)
Supervisión y registro
Visualización de métricas de clúster
Azure Monitor para contenedores
Visualización de los registros de componentes del plano de control
Visualización de los registros de kubelet
Visualización de datos de contenedor en tiempo real
Uso de contenedores de Windows Server
Creación de un clúster de AKS
Creación de un clúster de AKS con PowerShell
Conexión remota
Preguntas más frecuentes sobre los contenedores de Windows Server
Creación de archivos Dockerfile para contenedores de Windows Server
Optimización de archivos Dockerfile para contenedores de Windows Server
Desarrollo y ejecución de aplicaciones
Uso de Bridge to Kubernetes con Visual Studio Code
Uso de Bridge to Kubernetes con Visual Studio
Instalación de aplicaciones existentes con Helm
Uso de OpenFaaS
Ejecución de trabajos de Spark
Uso de GPU
Compilación de una aplicación con PostgreSQL
Compilación de una aplicación con MySQL
Compilación de una aplicación con Open Liberty o WebSphere Liberty
Uso de Azure API Management
Selección e implementación de una malla de servicio
Acerca de las mallas de servicio
Complemento Open Service Mesh (versión preliminar) de AKS
Uso de Istio
Acerca de Istio
Instalar y configurar
Escenario: enrutamiento inteligente y versiones controladas
Uso de Linkerd
Acerca de Linkerd
Uso de Consul
Acerca de Consul
DevOps
Uso de Ansible para crear clústeres de AKS
Implementación continua de Jenkins
Azure DevOps Project
Iniciador del centro de implementación
Acciones de GitHub para Kubernetes
Solución de problemas
Problemas comunes
Comprobación de los procedimientos recomendados
Acceso al nodo SSH
Herramientas de rendimiento de Linux
Compruebe los eventos de Resource Health (versión preliminar)
Referencia
Azure CLI
REST
PowerShell
.NET
Python
Java
Node.js
Plantilla de Resource Manager
Elementos integrados de Azure Policy
Recursos
Creación de aptitudes con Microsoft Learn
Disponibilidad en regiones
Precios
Directivas de soporte técnico
Azure Roadmap
Hoja de ruta de AKS
Stack Overflow
Vídeos
Preguntas más frecuentes
Azure Kubernetes Service
19/05/2021 • 7 minutes to read • Edit Online
Azure Kubernetes Service (AKS) simplifica la implementación de un clúster de Kubernetes administrado en

Azure, ya que descarga la sobrecarga operativa en Azure. Al ser un servicio de Kubernetes hospedado, Azure
controla tareas críticas como la supervisión del estado y el mantenimiento. Como Azure administra los maestros
de Kubernetes, el usuario solo administra y mantiene los nodos de agente. Por consiguiente, AKS es gratuito;
solo se paga por los nodos de agente en los clústeres, no por los maestros.
Puede crear un clúster de AKS mediante:
La CLI de Azure
Portal de Azure
Azure PowerShell
El uso de opciones de implementación controladas por plantillas, como las plantillas de Azure Resource
Manager y Terraform
Al implementar un clúster de AKS, el maestro y todos los nodos de Kubernetes se implementan y configuran
automáticamente. Las redes avanzadas, la integración de Azure Active Directory (Azure AD), la supervisión y
otras características se pueden configurar durante el proceso de implementación.
Para más información sobre los conceptos básicos de Kubernetes, consulte Conceptos básicos de Kubernetes
para AKS.
NOTE
Este servicio admite Azure Lighthouse, que permite a los proveedores de servicios iniciar sesión en su propio inquilino
para administrar las suscripciones y los grupos de recursos que los clientes hayan delegado.
AKS también admite contenedores de Windows Server.
Acceso, seguridad y supervisión

Para mejorar la seguridad y administración, AKS permite realizar la integración con Azure AD para:
Utilizar el control de acceso basado en roles de Kubernetes (RBAC de Kubernetes).
Supervisar el mantenimiento del clúster y los recursos.
Administración de identidades y seguridad
RBAC de Kubernetes
Para limitar el acceso a los recursos de clúster, AKS admite RBAC de Kubernetes. RBAC de Kubernetes controla el
acceso a los recursos y espacios de nombres de Kubernetes, y los permisos de los mismos.
Azure AD
Puede configurar un clúster de AKS para que se integre con Azure AD. Con la integración con Azure AD, puede
configurar el acceso a Kubernetes en función de la identidad y la pertenencia a grupos existentes. Puede
proporcionar una experiencia de inicio de sesión integrada a sus usuarios y grupos de Azure AD existentes, así
como acceso a recursos de AKS.
Para más información sobre la identidad, consulte Opciones de acceso e identidad para AKS.
Para proteger sus clústeres de AKS, consulte Integrate Azure Active Directory with AKS (Integración de Azure
Active Directory con AKS).
Supervisión y registro integrados
Azure Monitor para el estado de los contenedores recopila métricas de procesador y memoria de contenedores,
nodos y controladores dentro del clúster de AKS y las aplicaciones implementadas. Puede revisar tanto los
registros de contenedores como los registros maestros de Kubernetes, que:
Se almacenan en un área de trabajo de Azure Log Analytics.
Están disponible mediante Azure Portal, la CLI de Azure o un punto de conexión de REST.
Para más información, consulte Supervisión del mantenimiento de contenedores de Azure Kubernetes Service.
Clústeres y nodos
Los nodos de AKS se ejecutan en máquinas virtuales de Azure (VM). Con los nodos de AKS, puede conectar el
almacenamiento a nodos y pods, actualizar los componentes de clúster y usar GPU. AKS admite clústeres de
Kubernetes que ejecutan varios grupos de nodos, con el fin de que se puedan usar sistemas operativos mixtos y
contenedores de Windows Server.
Para más información sobre las funcionalidades de los clústeres, nodos y grupos de nodos de Kubernetes,
consulte Conceptos básicos de Kubernetes de Azure Kubernetes Service (AKS).
Escalado de pods y nodos de clúster
A medida que cambia la demanda de recursos, el número de pods o nodos de clúster que ejecutan sus servicios
se escala vertical u horizontalmente. Puede ajustar el escalador automático del pod horizontal o el escalador
automático del clúster en función de las demandas u y ejecutar solo los recursos necesarios.
Para más información, consulte Escalado de un clúster de Azure Kubernetes Service (AKS).
Actualizaciones de nodos de clúster
AKS ofrece varias versiones de Kubernetes. A medida que hay nuevas versiones disponibles en AKS, puede
actualizar el clúster mediante Azure Portal o la CLI de Azure. Durante el proceso de actualización, los nodos se
acordonan y vacían minuciosamente para minimizar las interrupciones en las aplicaciones en ejecución.
Para obtener más información sobre las versiones del ciclo de vida, vea Versiones de Kubernetes compatibles en
Azure Kubernetes Service (AKS). Para obtener información sobre los pasos de actualización, vea Actualización de
un clúster de Azure Kubernetes Service (AKS).
Nodos habilitados para GPU
AKS admite la creación de grupos de nodos habilitados para GPU. Azure proporciona actualmente máquinas
virtuales habilitadas para una o varias GPU. Las máquinas virtuales habilitadas para GPU están diseñadas para
cargas de trabajo de proceso intensivo, uso intensivo de gráficos y visualización.
Para más información, consulte Uso de GPU en AKS.
Nodos de computación confidencial (versión preliminar pública)
AKS admite la creación de grupos de nodos de computación confidencial basados en Intel SGX (máquinas
virtuales DCSv2). Los nodos de computación confidencial permiten que los contenedores se ejecuten en un
entorno de ejecución de confianza basado en hardware (enclaves). El aislamiento entre contenedores en
combinación con la integridad del código mediante la atestación puede contribuir a la estrategia de seguridad
de contenedores de defensa en profundidad. Los nodos de computación confidencial admiten tanto
contenedores confidenciales (aplicaciones de Docker existentes) como contenedores compatibles con enclave.
Para más información, consulte Nodos de computación confidencial en Azure Kubernetes Service.
Compatibilidad con volúmenes de almacenamiento
Para admitir las cargas de trabajo de la aplicación, puede montar volúmenes de almacenamiento estáticos o
dinámicos para los datos persistentes. En función del número de pods conectados que se espere que vayan a
compartir los volúmenes de almacenamiento, se puede usar un almacenamiento respaldado por:
Azure Disks para el acceso de un solo pod, o bien
Azure Files para el acceso de varios pod al mismo tiempo.
Para más información, consulte Opciones de almacenamiento para aplicaciones en AKS.
Empiece con volúmenes persistentes dinámicos mediante Azure Disks o Azure Files.
Redes virtuales y entrada

Un clúster de AKS se puede implementar en una red virtual existente. En esta configuración, cada pod del clúster
tiene asignada una dirección IP en la red virtual y puede comunicarse directamente con:
Otros pods del clúster.
Otros nodos de la red virtual.
Un pod se puede conectar también con otros servicios de una red virtual emparejada y con redes locales
mediante ExpressRoute o conexiones VPN de sitio a sitio (S2S).
Para más información, consulte Conceptos de red para aplicaciones en AKS.
Entrada con el enrutamiento de aplicación HTTP
El complemento de enrutamiento de aplicaciones de HTTP le ayuda a acceder fácilmente a las aplicaciones
implementadas en el clúster de AKS. Cuando está habilitada, la solución de enrutamiento de aplicaciones HTTP
configura un controlador de entrada en el clúster de AKS.
A medida que se implementan las aplicaciones, los nombres DNS con acceso público se configuran
automáticamente. El enrutamiento de aplicación HTTP configura una zona DNS y la integra con el clúster de
AKS. A continuación, puede implementar recursos de entrada de Kubernetes de la forma habitual.
Para empezar con el tráfico de entrada, consulte Enrutamiento de aplicación HTTP.
Integración de herramientas de desarrollo

Kubernetes tiene un ecosistema completo de herramientas de desarrollo y administración que funcionan sin
problemas con AKS. Estas herramientas incluyen Helm y la extensión Kubernetes para Visual Studio Code.
Azure proporciona varias herramientas que ayudan a simplificar Kubernetes, como Azure Dev Spaces y DevOps
Starter.
Azure Dev Spaces
Azure Dev Spaces proporciona a los equipos una experiencia de desarrollo en Kubernetes iterativa y rápida. Con
una configuración mínima, puede ejecutar y depurar contenedores directamente en AKS. Para empezar, consulte
Azure Dev Spaces.
DevOps Starter
DevOps Starter ofrece una solución sencilla para llevar a Azure el código y los repositorios de Git existentes.
DevOps Starter hace lo siguiente de forma automática:
Crea recursos de Azure (como AKS),
Configura una canalización de versión en Azure DevOps Services que incluye una canalización de
compilación para integración continua,
Configura una canalización de versión para implementación continua y
Genera un recurso de Azure Application Insights para la supervisión.
Para más información, consulte DevOps Starter.
Compatibilidad con imágenes de Docker y registro de contenedor

privado
AKS admite el formato de imagen de Docker. Para el almacenamiento privado de las imágenes de Docker, puede
realizar la integración de AKS con Azure Container Registry (ACR).
Para crear un almacén de imágenes privado, consulte Azure Container Registry.
Certificación de Kubernetes
AKS cuenta con el certificado CNCF de cumplimiento con Kubernetes.
Cumplimiento de normativas
AKS cumple con SOC, ISO, PCI DSS e HIPAA. Para más información, consulte Introducción al cumplimiento de
Microsoft Azure.
Pasos siguientes
Más información sobre la implementación y administración de AKS con el inicio rápido de la CLI de Azure.
Implementación de un clúster de AKS Cluster mediante la CLI de Azure
Inicio rápido: Implementación de un clúster de
Azure Kubernetes Service mediante la CLI de Azure
Azure Kubernetes Service (AKS) es un servicio de Kubernetes administrado que le permite implementar y
administrar clústeres rápidamente. En este inicio rápido realizará lo siguiente:
Implementación de un clúster de AKS con la CLI de Azure.
Ejecución de una aplicación de varios contenedores con un servidor front-end web y una instancia de
Redis en el clúster.
Supervisión del estado del clúster y de los pods que ejecutan la aplicación.
En esta guía rápida se presupone un conocimiento básico de los conceptos de Kubernetes. Para más
información, consulte Conceptos básicos de Kubernetes de Azure Kubernetes Service (AKS).
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.
Para más información sobre cómo crear un grupo de nodos de Windows Server, consulte Creación de un clúster
de AKS que admita contenedores de Windows Server.
Requisitos previos
Use el entorno de Bash en Azure Cloud Shell.
Si lo prefiere, instale la CLI de Azure para ejecutar sus comandos de referencia.

Si usa una instalación local, inicie sesión en la CLI de Azure mediante el comando az login. Siga los
pasos que se muestran en el terminal para completar el proceso de autenticación. Para ver otras
opciones de inicio de sesión, consulte Inicio de sesión con la CLI de Azure.
Cuando se le solicite, instale las extensiones de la CLI de Azure la primera vez que la use. Para más
información sobre las extensiones, consulte Uso de extensiones con la CLI de Azure.
Ejecute az version para buscar cuál es la versión y las bibliotecas dependientes que están
instaladas. Para realizar la actualización a la versión más reciente, ejecute az upgrade.
En este artículo se necesita la versión 2.0.64, o versiones posteriores, de la CLI de Azure. Si usa Azure Cloud
Shell, ya está instalada la versión más reciente.
NOTE
Si planea ejecutar los comandos de este inicio rápido localmente en lugar de en Azure Cloud Shell, hágalo como
administrador.
Crear un grupo de recursos

Un grupo de recursos de Azure es un grupo lógico en el que se implementan y administran recursos de Azure.
Cuando crea un grupo de recursos, se le pide que especifique una ubicación. Esta ubicación es:
La ubicación de almacenamiento de los metadatos del grupo de recursos.
El lugar en el que se ejecutan los recursos en Azure si no se especifica otra región al crearlos.
En el ejemplo siguiente, se crea un grupo de recursos denominado myResourceGroup en la ubicación eastus.
Cree un grupo de recursos con el comando az group create.
az group create --name myResourceGroup --location eastus
Salida del grupo de recursos que se creó correctamente:
{
"id": "/subscriptions/<guid>/resourceGroups/myResourceGroup",
"location": "eastus",
"managedBy": null,
"name": "myResourceGroup",
"properties": {
"provisioningState": "Succeeded"
},
"tags": null
}
Habilitación de la supervisión de clústeres

1. Compruebe que Microsoft.OperationsManagement y Microsoft.OperationalInsights están registrados en
la suscripción. Para comprobar el estado del registro, siga estos pasos:
az provider show -n Microsoft.OperationsManagement -o table

az provider show -n Microsoft.OperationalInsights -o table
Si no están registrados, use el siguiente comando para registrar Microsoft.OperationsManagement y

Microsoft.OperationalInsights:
az provider register --namespace Microsoft.OperationsManagement

az provider register --namespace Microsoft.OperationalInsights
2. Habilite Azure Monitor para contenedores mediante el parámetro --enable-addons monitoring.

Cree un clúster de AKS con el comando az aks create. En el siguiente ejemplo se crea un clúster denominado
myAKSCluster con un nodo:
az aks create --resource-group myResourceGroup --name myAKSCluster --node-count 1 --enable-addons monitoring

--generate-ssh-keys
Transcurridos unos minutos, el comando se completa y devuelve información en formato JSON sobre el clúster.
NOTE
Al crear un clúster de AKS, se crea automáticamente un segundo grupo de recursos para almacenar los recursos de dicho
clúster. Para más información, consulte ¿Por qué se crean dos grupos de recursos con AKS?
Conectarse al clúster
Para administrar un clúster de Kubernetes, use kubectl, el cliente de línea de comandos de Kubernetes. Si usa
Azure Cloud Shell, kubectl ya está instalado.
1. Instale kubectl localmente mediante el comando az aks install-cli:
az aks install-cli
2. Para configurar kubectl para conectarse a su clúster de Kubernetes, use el comando az aks get-
credentials. El siguiente comando:
Descarga las credenciales y configura la CLI de Kubernetes para usarlas.
Usa ~/.kube/config , la ubicación predeterminada del archivo de configuración de Kubernetes. Puede
especificar otra ubicación para el archivo de configuración de Kubernetes con la opción --file.
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
3. Compruebe la conexión al clúster con el comando kubectl get. Este comando devuelve una lista de los
nodos del clúster.
kubectl get nodes
La salida muestra el nodo único creado en los pasos anteriores. Asegúrese de que el estado del nodo es
Listo:
NAME STATUS ROLES AGE VERSION

aks-nodepool1-31718369-0 Ready agent 6m44s v1.12.8
Ejecución de la aplicación
Un archivo de manifiesto de Kubernetes define el estado deseado del clúster, por ejemplo, qué imágenes de
contenedor se van a ejecutar.
En este inicio rápido se usa un manifiesto para crear todos los objetos necesarios para ejecutar la aplicación
Azure Vote. Este manifiesto incluye dos implementaciones de Kubernetes:
Las aplicaciones de Python de ejemplo de Azure Vote.
Una instancia de Redis.
También se crean dos servicios de Kubernetes:
Un servicio interno para la instancia de Redis.
Un servicio externo para acceder a la aplicación Azure Vote desde Internet.
1. Cree un archivo llamado azure-vote.yaml .
Si usa Azure Cloud Shell, este archivo se puede crear mediante code , vi o nano como si trabajara
en un sistema físico o virtual:
2. Copie la siguiente definición de código YAML:
apiVersion: apps/v1
kind: Deployment
metadata:
name: azure-vote-back
spec:
replicas: 1
selector:
matchLabels:
app: azure-vote-back
template:
metadata:
labels:
spec:
nodeSelector:
"beta.kubernetes.io/os": linux
containers:
- name: azure-vote-back
image: mcr.microsoft.com/oss/bitnami/redis:6.0.8
env:
- name: ALLOW_EMPTY_PASSWORD
value: "yes"
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
ports:
- containerPort: 6379
name: redis
---
apiVersion: v1
kind: Service
metadata:
spec:
ports:
- port: 6379
selector:
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: azure-vote-front
spec:
replicas: 1
selector:
matchLabels:
app: azure-vote-front
template:
metadata:
labels:
spec:
nodeSelector:
containers:
- name: azure-vote-front
image: mcr.microsoft.com/azuredocs/azure-vote-front:v1
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
ports:
- containerPort: 80
env:
- name: REDIS
value: "azure-vote-back"
---
apiVersion: v1
kind: Service
metadata:
spec:
type: LoadBalancer
ports:
- port: 80
selector:
3. Implemente la aplicación mediante el comando kubectl apply y especifique el nombre del manifiesto de
YAML:
kubectl apply -f azure-vote.yaml
La salida muestra los servicios y las implementaciones que se crearon correctamente:
deployment "azure-vote-back" created

service "azure-vote-back" created
deployment "azure-vote-front" created
service "azure-vote-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.
Para supervisar el progreso, utilice el comando kubectl get service con el argumento --watch .
kubectl get service azure-vote-front --watch
La salida de EXTERNAL-IP del servicio azure-vote-front aparecerá inicialmente como pendiente.

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
azure-vote-front LoadBalancer 10.0.37.27 <pending> 80:30572/TCP 6s
Una vez que la dirección EXTERNAL-IP cambia de pendiente a una dirección IP pública real, use CTRL-C para
detener el kubectl proceso de inspección. En la salida del ejemplo siguiente se muestra una dirección IP pública
válida asignada al servicio:
azure-vote-front LoadBalancer 10.0.37.27 52.179.23.131 80:30572/TCP 2m
Para ver la aplicación Azure Vote en acción, abra un explorador web en la dirección IP externa del servicio.
Vea las métricas de mantenimiento de los nodos del clúster y los pods capturadas por Azure Monitor para
contenedores en Azure Portal.
Eliminación del clúster

Para evitar cargos de Azure, se recomienda limpiar los recursos que no sean necesarios. Use el comando az
group delete para quitar el grupo de recursos, el servicio de contenedor y todos los recursos relacionados.
az group delete --name myResourceGroup --yes --no-wait
NOTE
Cuando elimina el clúster, la entidad de servicio Azure Active Directory que utiliza el clúster de AKS no se quita. Para
conocer los pasos que hay que realizar para quitar la entidad de servicio, consulte Consideraciones principales y
eliminación de AKS.
Si usó una identidad administrada, esta está administrada por la plataforma y no requiere que la quite.
Obtención del código

En este inicio rápido, se han usado imágenes de un contenedor creado previamente para crear una
implementación de Kubernetes. El código de la aplicación relacionada, Dockerfile, y el archivo de manifiesto de
Kubernetes están disponibles en GitHub.
Pasos siguientes
En este inicio rápido, ha implementado un clúster de Kubernetes y luego ha implementado en él una aplicación
de varios contenedores. Acceda al panel web de Kubernetes del clúster de AKS.
Para obtener más información sobre AKS y un ejemplo completo desde el código hasta la implementación,
continúe con el tutorial del clúster de Kubernetes.
Tutorial de AKS
Azure Kubernetes Service mediante PowerShell
Implementar un clúster de AKS mediante PowerShell.
Ejecutar en el clúster una aplicación de varios contenedores con un front-end web y una instancia de Redis.
Supervisar el mantenimiento del clúster y los pods que ejecutan la aplicación.
Para más información sobre cómo crear un grupo de nodos de Windows Server, consulte Creación de un clúster
de AKS que admita contenedores de Windows Server.
Prerrequisitos
Si va a ejecutar PowerShell de forma local, instale el módulo Az PowerShell y conéctese a su cuenta de Azure
con el cmdlet Connect-AzAccount. Para más información sobre cómo instalar el módulo Az PowerShell, consulte
Instalación de Azure PowerShell.
Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el
explorador. Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar
los comandos preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada
en su entorno local.
Para iniciar Azure Cloud Shell:
O P C IÓ N E JEM P LO O VÍN C ULO
Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se
copia automáticamente el código en Cloud Shell.
Vaya a https://shell.azure.com o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.
Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.
Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si tiene varias suscripciones a Azure, seleccione el identificador de la suscripción adecuada en la que se deben
facturar los recursos con el cmdlet Set-AzContext.
Set-AzContext -SubscriptionId 00000000-0000-0000-0000-000000000000

Cuando crea un grupo de recursos, se le pide que especifique una ubicación. Esta ubicación es:
La ubicación de almacenamiento de los metadatos del grupo de recursos.
El lugar en el que se ejecutan los recursos en Azure si no se especifica otra región al crear los recursos.
En el ejemplo siguiente, se crea un grupo de recursos denominado myResourceGroup en la región eastus .
Cree un grupo de recursos con el cmdlet New-AzResourceGroup.
New-AzResourceGroup -Name myResourceGroup -Location eastus
Salida del grupo de recursos que se creó correctamente:
ResourceGroupName : myResourceGroup
Location : eastus
ProvisioningState : Succeeded
Tags :
ResourceId : /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup

1. Use la utilidad de línea de comandos ssh-keygen para generar un par de claves SSH.
Para más información, consulte Pasos rápidos: Creación y uso de un par de claves pública-privada SSH
para máquinas virtuales Linux en Azure.
2. Use el cmdlet New-AzAks para crear un clúster de AKS. Azure Monitor para contenedores está habilitado
de forma predeterminada.
En el siguiente ejemplo se crea un clúster denominado myAKSCluster con un nodo.
New-AzAksCluster -ResourceGroupName myResourceGroup -Name myAKSCluster -NodeCount 1
NOTE
Al crear un clúster de AKS, se crea automáticamente un segundo grupo de recursos para almacenar los recursos de AKS.
Para más información, consulte ¿Por qué se crean dos grupos de recursos con AKS?
1. Para instalar kubectl localmente, use el cmdlet Install-AzAksKubectl :
Install-AzAksKubectl
2. Para configurar kubectl para conectarse al clúster de Kubernetes, use el cmdlet Import-AzAksCredential.
El siguiente cmdlet permite descargar las credenciales y configurar la CLI de Kubernetes para usarlas.
Import-AzAksCredential -ResourceGroupName myResourceGroup -Name myAKSCluster
3. 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
Listo:

Si usa Azure Cloud Shell, este archivo se puede crear mediante vi o nano como si trabajara en un
sistema físico o virtual.
apiVersion: apps/v1
kind: Deployment
metadata:
spec:
replicas: 1
selector:
matchLabels:
template:
metadata:
labels:
spec:
nodeSelector:
containers:
env:
value: "yes"
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
ports:
name: redis
---
apiVersion: v1
kind: Service
metadata:
spec:
ports:
- port: 6379
selector:
---
apiVersion: apps/v1
kind: Deployment
metadata:
spec:
replicas: 1
selector:
matchLabels:
template:
metadata:
labels:
spec:
nodeSelector:
containers:
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
ports:
- containerPort: 80
env:
- name: REDIS
---
apiVersion: v1
kind: Service
metadata:
spec:
type: LoadBalancer
ports:
- port: 80
selector:
YAML:
.\kubectl apply -f azure-vote.yaml
deployment.apps/azure-vote-back created
service/azure-vote-back created
deployment.apps/azure-vote-front created
service/azure-vote-front created
.\kubectl get service azure-vote-front --watch

Vea las métricas de mantenimiento de los nodos del clúster y los pods capturadas por Azure Monitor para los
contenedores de Azure Portal.

Para evitar cargos de Azure, se recomienda limpiar los recursos que no sean necesarios. Use el cmdlet Remove-
AzResourceGroup para eliminar el grupo de recursos, el servicio de contenedor y todos los recursos
relacionados.
Remove-AzResourceGroup -Name myResourceGroup
NOTE

Pasos siguientes
Tutorial de AKS
Azure Kubernetes Service (AKS) mediante Azure
Portal
Implementación de un clúster de AKS en Azure Portal.
Ejecución de una aplicación de varios contenedores con un servidor front-end web y una instancia de Redis
en el clúster.
Supervisión del estado del clúster y de los pods que ejecutan la aplicación.
Requisitos previos
Inicie sesión en Azure Portal en https://portal.azure.com.

1. En el menú de Azure Portal o en la página principal , seleccione Crear un recurso .
2. Seleccione Containers > Kubernetes Ser vice .
3. En la página Datos básicos , configure las siguientes opciones:
Detalles del proyecto :
Seleccione una suscripción de Azure.
Seleccione o cree un grupo de recursos de Azure, como myResourceGroup.
Detalles del clúster :
Escriba un Nombre del clúster de Kubernetes , como myAKSCluster.
En Región y Versión de Kubernetes , seleccionelos valores adecuados para el clúster de AKS.
Grupo de nodos principal :
Seleccione un tamaño de nodo de máquina virtual para los nodos de AKS. El tamaño de VM
no puede cambiarse una vez que se ha implementado un clúster de AKS.
Seleccione el número de nodos que se van a implementar en el clúster. En esta guía de inicio
rápido, establezca Número de nodos en 1. El número de nodos puede ajustarse después de
implementar el clúster.
4. Seleccione Siguiente: Grupos de nodos cuando haya terminado.

5. Mantenga las opciones predeterminadas de los grupos de nodos . En la parte inferior de la pantalla,
haga clic en Siguiente: Autenticación .
Cau t i on
Las entidades de servicio de Azure AD recién creadas pueden tardar varios minutos en propagarse y
estar disponibles, lo que provoca errores de "entidad de servicio no encontrada" y de validación en Azure
Portal. Si se tropieza con esta situación, visite nuestro artículo de solución de problemas para resolverla.
6. En la página Autenticación , configure las siguientes opciones:
Cree una identidad de clúster; para ello puede:
Dejar el campo Autenticación con System-assinged managed identity (Identidad
administrada por el sistema) o
Elegir Entidad de ser vicio para usar una entidad de servicio.
Seleccione Entidad de servicio predeterminada (nueva) para crear una entidad de
servicio predeterminada.
También puede elegir Configurar la entidad de servicio para usar una existente. Deberá
proporcionar el identificador y el secreto de cliente del SPN de la entidad de servicio
existente.
Habilite la opción de control de acceso basado en rol de Kubernetes (Kubernetes RBAC) para
proporcionar un control más preciso sobre el acceso a los recursos de Kubernetes implementados en
el clúster de AKS.
De forma predeterminada, se usa la red Básica y está habilitado Azure Monitor para contenedores.
7. Haga clic en Revisar y crear y, luego, en Crear cuando finalice la validación.
8. El clúster de AKS tarda unos minutos en crearse. Una vez finalizada la implementación, vaya al recurso;
puede hacerlo de dos maneras:
Haga clic en Ir al recurso .
Vaya al grupo de recursos del clúster de AKS y seleccione el recurso de AKS.
Por ejemplo, en el panel de clúster siguiente, busque myResourceGroup y seleccionar el recurso
myAKSCluster.
1. Abra Cloud Shell mediante el botón >_ de la parte superior de Azure Portal.
NOTE
Para realizar estas operaciones en una instalación de shell local:
1. Compruebe que la CLI de Azure está instalada.
2. Conéctese a Azure a través del comando az login .
credentials. El siguiente comando descarga las credenciales y configura la CLI de Kubernetes para usarlas.
3. Para comprobar la conexión al clúster, use el comando kubectl get para devolver una lista de los nodos
del clúster.
kubectl get nodes

Listo:

aks-agentpool-14693408-0 Ready agent 15m v1.11.5
Un archivo de manifiesto de Kubernetes define el estado deseado de un clúster, por ejemplo, qué imágenes de
1. En Cloud Shell, use un editor para crear un archivo llamado azure-vote.yaml , por ejemplo:
code azure-vote.yaml
nano azure-vote.yaml o
vi azure-vote.yaml .
apiVersion: apps/v1
kind: Deployment
metadata:
spec:
replicas: 1
selector:
matchLabels:
template:
metadata:
labels:
spec:
nodeSelector:
containers:
env:
value: "yes"
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
ports:
name: redis
name: redis
---
apiVersion: v1
kind: Service
metadata:
spec:
ports:
- port: 6379
selector:
---
apiVersion: apps/v1
kind: Deployment
metadata:
spec:
replicas: 1
selector:
matchLabels:
template:
metadata:
labels:
spec:
nodeSelector:
containers:
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
ports:
- containerPort: 80
env:
- name: REDIS
---
apiVersion: v1
kind: Service
metadata:
spec:
type: LoadBalancer
ports:
- port: 80
selector:
YAML:


Supervisión de estado y registros

Cuando se creó el clúster, se habilitó Azure Monitor para contenedores. Azure Monitor para contenedores
proporciona métricas de estado para el clúster de AKS y los pods que se ejecutan en él.
Los datos de métricas tardan unos minutos en rellenarse en Azure Portal. Para ver el estado de mantenimiento,
el tiempo de actividad y el uso de recursos actuales de los pods de Azure Vote, haga lo siguiente:
1. Vuelva al recurso de AKS en Azure Portal.
2. En Super visión en el lado izquierdo, elija Detalles .
3. En la parte superior, elija + Agregar filtro .
4. Seleccione Espacio de nombres como propiedad y, después, elija <All but kube-system> .
5. Seleccione Contenedores para verlos.
Se muestran los contenedores azure-vote-back y azure-vote-front , como se ilustra en el ejemplo siguiente:
Para ver los registros del pod azure-vote-front , seleccione el vínculo Ver registros del contenedor en el
menú desplegable de la lista de contenedores. Estos registros incluyen los flujos stdout y stderr del contenedor.
Eliminación de clúster
Para evitar cargos de Azure, se recomienda limpiar los recursos que no sean necesarios. Seleccione el botón
Eliminar en el panel del clúster de AKS. También puede usar el comando az aks delete en Cloud Shell:
az aks delete --resource-group myResourceGroup --name myAKSCluster --no-wait
NOTE

Pasos siguientes
Para más información sobre AKS con un recorrido por un ejemplo completo, con la creación de una aplicación,
la implementación desde Azure Container Registry, la actualización de una aplicación en ejecución y el escalado
y la actualización del clúster, continúe con el tutorial de clústeres de Kubernetes.
Tutorial de AKS
Azure Kubernetes Service (AKS) mediante una
plantilla de ARM
Implementación de un clúster de AKS mediante una plantilla de Azure Resource Manager.
Ejecución de una aplicación de varios contenedores con un servidor front-end web y una instancia de Redis
en el clúster.
Una plantilla de Resource Manager es un archivo de notación de objetos JavaScript (JSON) que define la
infraestructura y la configuración del proyecto. La plantilla usa sintaxis declarativa. En la sintaxis declarativa, se
describe la implementación deseada sin escribir la secuencia de comandos de programación para crearla.
Si su entorno cumple los requisitos previos y está familiarizado con el uso de plantillas de Resource Manager,
seleccione el botón Implementar en Azure . La plantilla se abrirá en Azure Portal.
Requisitos previos
En este artículo se necesita la versión 2.0.61 de la CLI de Azure, o cualquier versión posterior. Si usa Azure
Cloud Shell, ya está instalada la versión más reciente.
Para crear un clúster de AKS con una plantilla de Resource Manager, proporcione una clave pública SSH.
Si necesita este recurso, consulte la sección siguiente; en caso contrario, vaya a la sección Revisión de la
plantilla.
Creación de un par de claves SSH
Para acceder a los nodos de AKS, se conectará mediante un par de claves SSH (pública y privada), que se genera
mediante el comando ssh-keygen . De forma predeterminada, estos archivos se crean en el directorio ~/.ssh. La
ejecución del comando ssh-keygen sobrescribirá cualquier par de claves SSH con el mismo nombre que ya
exista en la ubicación especificada.
1. Vaya a https://shell.azure.com para abrir Cloud Shell en el explorador.
2. Ejecute el comando ssh-keygen . El siguiente comando crea un par de claves SSH con ayuda del cifrado
RSA y una longitud en bits de 2048:
ssh-keygen -t rsa -b 2048
Para más información sobre cómo crear claves SSH, consulte el artículo sobre Creación y administración de
claves SSH para la autenticación en Azure.
Revisión de la plantilla
La plantilla usada en este inicio rápido forma parte de las plantillas de inicio rápido de Azure.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.1",
"parameters": {
"clusterName": {
"type": "string",
"defaultValue": "aks101cluster",
"metadata": {
"description": "The name of the Managed Cluster resource."
}
},
"location": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"metadata": {
"description": "The location of the Managed Cluster resource."
}
},
"dnsPrefix": {
"type": "string",
"metadata": {
"metadata": {
"description": "Optional DNS prefix to use with hosted Kubernetes API server FQDN."
}
},
"osDiskSizeGB": {
"type": "int",
"defaultValue": 0,
"minValue": 0,
"maxValue": 1023,
"metadata": {
"description": "Disk size (in GB) to provision for each of the agent pool nodes. This value ranges
from 0 to 1023. Specifying 0 will apply the default disk size for that agentVMSize."
}
},
"agentCount": {
"type": "int",
"defaultValue": 3,
"minValue": 1,
"maxValue": 50,
"metadata": {
"description": "The number of nodes for the cluster."
}
},
"agentVMSize": {
"type": "string",
"defaultValue": "Standard_DS2_v2",
"metadata": {
"description": "The size of the Virtual Machine."
}
},
"linuxAdminUsername": {
"type": "string",
"metadata": {
"description": "User name for the Linux Virtual Machines."
}
},
"sshRSAPublicKey": {
"type": "string",
"metadata": {
"description": "Configure all linux machines with the SSH RSA public key string. Your key should
include three parts, for example 'ssh-rsa AAAAB...snip...UcyupgH azureuser@linuxvm'"
}
},
"osType": {
"type": "string",
"defaultValue": "Linux",
"allowedValues": [
"Linux"
],
"metadata": {
"description": "The type of operating system."
}
}
},
"resources": [
{
"type": "Microsoft.ContainerService/managedClusters",
"apiVersion": "2020-03-01",
"name": "[parameters('clusterName')]",
"location": "[parameters('location')]",
"properties": {
"dnsPrefix": "[parameters('dnsPrefix')]",
"agentPoolProfiles": [
{
"name": "agentpool",
"osDiskSizeGB": "[parameters('osDiskSizeGB')]",
"count": "[parameters('agentCount')]",
"vmSize": "[parameters('agentVMSize')]",
"osType": "[parameters('osType')]",
"storageProfile": "ManagedDisks"
"storageProfile": "ManagedDisks"
}
],
"linuxProfile": {
"adminUsername": "[parameters('linuxAdminUsername')]",
"ssh": {
"publicKeys": [
{
"keyData": "[parameters('sshRSAPublicKey')]"
}
]
}
}
},
"identity": {
"type": "SystemAssigned"
}
}
],
"outputs": {
"controlPlaneFQDN": {
"type": "string",
"value": "[reference(parameters('clusterName')).fqdn]"
}
}
}
Para más ejemplos de AKS, consulte el sitio de plantillas de inicio rápido de AKS.
Implementación de la plantilla
1. Seleccione el botón siguiente para iniciar sesión en Azure y abrir una plantilla.
2. Seleccione o escriba los siguientes valores.

Para este inicio rápido, deje los valores predeterminados de Tamaño del disco del SO GB, Número de
agentes, Tamaño de VM del agente, Tipo de SO y Versión de Kubernetes. Proporcione sus propios valores
para los siguientes parámetros de plantilla:
Suscripción : Seleccione una suscripción de Azure.
Grupo de recursos : Seleccione Crear nuevo . Escriba un nombre único para el grupo de recursos,
como myResourceGroup, y elija Aceptar .
Ubicación : seleccione una ubicación, como Este de EE. UU .
Nombre del clúster : escriba un nombre único para el clúster de AKS, como myAKSCluster.
Prefijo de DNS : escriba un prefijo DNS único para el clúster, como myakscluster.
Linux Admin Username (Nombre de usuario administrador de Linux): escriba un nombre de
usuario para conectarse mediante SSH, como azureuser.
SSH RSA Public Key (Clave pública SSH RSA): copie y pegue la parte pública del par de claves SSH
(de forma predeterminada, el contenido de ~/.ssh/id_rsa.pub).
3. Seleccione Revisar + crear .
El clúster de AKS tarda unos minutos en crearse. Espere a que el clúster se implemente correctamente para
pasar al siguiente paso.
Validación de la implementación
1. Instale kubectl localmente mediante el comando az aks install-cli:
az aks install-cli
credentials. Con este comando se descargan las credenciales y se configura la CLI de Kubernetes para
usarlas.
3. Compruebe la conexión al clúster con el comando kubectl get. Este comando devuelve una lista de los
nodos del clúster.
kubectl get nodes
La salida muestra los nodos creados en los pasos anteriores. Asegúrese de que el estado de los nodos sea
Listo:

aks-agentpool-41324942-0 Ready agent 6m44s v1.12.6
Si usa Azure Cloud Shell, este archivo se puede crear mediante vi o nano como si trabajara en un
sistema físico o virtual.
apiVersion: apps/v1
kind: Deployment
metadata:
spec:
replicas: 1
selector:
matchLabels:
template:
metadata:
labels:
spec:
nodeSelector:
containers:
env:
value: "yes"
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
ports:
name: redis
---
apiVersion: v1
kind: Service
metadata:
spec:
ports:
- port: 6379
selector:
---
apiVersion: apps/v1
kind: Deployment
metadata:
spec:
replicas: 1
selector:
matchLabels:
template:
metadata:
labels:
spec:
nodeSelector:
containers:
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
ports:
- containerPort: 80
env:
- name: REDIS
---
apiVersion: v1
kind: Service
metadata:
spec:
type: LoadBalancer
ports:
- port: 80
selector:
YAML:


Limpieza de recursos
Para evitar cargos de Azure, se recomienda limpiar los recursos que no sean necesarios. Use el comando az
group delete para quitar el grupo de recursos, el servicio de contenedor y todos los recursos relacionados.
NOTE

Pasos siguientes
Tutorial de AKS
Inicio rápido: Desarrollo en Azure Kubernetes
Service (AKS) con Helm
Helm es una herramienta de empaquetado de código abierto que ayuda a instalar y administrar el ciclo de vida
de las aplicaciones de Kubernetes. Al igual que los administradores de paquetes de Linux, como APT y Yum,
Helm administra los gráficos de Kubernetes, que son paquetes de recursos de Kubernetes preconfigurados.
En esta guía de inicio rápido, usará Helm para empaquetar y ejecutar una aplicación en AKS. Para más
información sobre cómo instalar una aplicación existente con Helm, consulte la guía paso a paso Instalación de
aplicaciones existentes con Helm en AKS.
Requisitos previos
Suscripción a Azure. Si no tiene una suscripción a Azure, puede crear una cuenta gratuita.
La CLI de Azure instalada.
Helm v3 instalado.
Creación de una instancia de Azure Container Registry

Tendrá que almacenar las imágenes de contenedor en una instancia de Azure Container Registry (ACR) para
ejecutar la aplicación en el clúster de AKS mediante Helm. Proporcione su propio nombre de registro único en
Azure que contenga entre 5 y 50 caracteres alfanuméricos. La SKU básica es un punto de entrada optimizado
para costo con fines de desarrollo que proporciona un equilibrio entre almacenamiento y rendimiento.
En el ejemplo siguiente se usa az acr create para crear una instancia de ACR llamada MyHelmACR en
MyResourceGroup con la SKU Básica.
az group create --name MyResourceGroup --location eastus

az acr create --resource-group MyResourceGroup --name MyHelmACR --sku Basic
El resultado será similar al ejemplo siguiente. Tome nota del valor de loginServer para la instancia de ACR,
puesto que lo usará en un paso posterior. En el ejemplo siguiente, myhelmacr.azurecr.io es el valor de
loginServer para MyHelmACR.
{
"adminUserEnabled": false,
"creationDate": "2019-06-11T13:35:17.998425+00:00",
"id":
"/subscriptions/<ID>/resourceGroups/MyResourceGroup/providers/Microsoft.ContainerRegistry/registries/MyHelmA
CR",
"loginServer": "myhelmacr.azurecr.io",
"name": "MyHelmACR",
"networkRuleSet": null,
"provisioningState": "Succeeded",
"resourceGroup": "MyResourceGroup",
"sku": {
"name": "Basic",
"tier": "Basic"
},
"status": null,
"storageAccount": null,
"tags": {},
"type": "Microsoft.ContainerRegistry/registries"
}

El nuevo clúster de AKS necesita acceder a la instancia de ACR para extraer las imágenes de contenedor y
ejecutarlas. Use el comando siguiente para:
Cree un clúster de AKS denominado MyAKS y asocie MyHelmACR .
Conceda al clúster MyAKS acceso a la instancia de ACR MyHelmACR .
az aks create -g MyResourceGroup -n MyAKS --location eastus --attach-acr MyHelmACR --generate-ssh-keys
Conectarse al clúster AKS

Para conectar un clúster de Kubernetes de manera local, use kubectl, el cliente de línea de comandos de
Kubernetes. Si usa Azure Cloud Shell, kubectl ya está instalado.
1. Instale kubectl localmente mediante el comando az aks install-cli :
az aks install-cli
2. Para configurar para conectarse a su clúster de Kubernetes, use el comando

kubectl
. En el comando de ejemplo siguiente se obtienen las credenciales del clúster de
az aks get-credentials
AKS llamado MyAKS en MyResourceGroup:
az aks get-credentials --resource-group MyResourceGroup --name MyAKS
Descarga de la aplicación de ejemplo

En esta guía de inicio rápido se usa una aplicación de Node.js de ejemplo del repositorio de ejemplo de Azure
Dev Spaces. Clone la aplicación desde GitHub y vaya al directorio
dev-spaces/samples/nodejs/getting-started/webfrontend .
git clone https://github.com/Azure/dev-spaces
cd dev-spaces/samples/nodejs/getting-started/webfrontend
Creación de un archivo Dockerfile

Cree un nuevo archivo Dockerfile mediante los siguientes comandos:
FROM node:latest
WORKDIR /webfrontend
COPY package.json ./
RUN npm install
COPY . .
EXPOSE 80
CMD ["node","server.js"]
Compilación e inserción de la aplicación de ejemplo en la instancia de

ACR
Con el archivo Dockerfile anterior, ejecute el comando az acr build para compilar e insertar una imagen en el
registro. El signo . al final del comando establece la ubicación del archivo Dockerfile (en este caso, el directorio
actual).
az acr build --image webfrontend:v1 \

--registry MyHelmACR \
--file Dockerfile .
Creación del gráfico de Helm

Genere el gráfico de Helm con el comando helm create .
helm create webfrontend
Actualice webfrontend/values.yaml:
Reemplace el valor loginServer del registro que anotó en un paso anterior, como myhelmacr.azurecr.io.
Cambie image.repository a <loginServer>/webfrontend .
Cambie service.type a LoadBalancer .
Por ejemplo:
# Default values for webfrontend.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
replicaCount: 1
image:
repository: myhelmacr.azurecr.io/webfrontend
pullPolicy: IfNotPresent
...
service:
type: LoadBalancer
port: 80
...
Actualice appVersion a v1 en webfrontend/Chart.yaml. Por ejemplo
apiVersion: v2
name: webfrontend
...
# This is the version number of the application being deployed. This version number should be
# incremented each time you make changes to the application.
appVersion: v1
Ejecución del gráfico de Helm

Instale la aplicación con el gráfico de Helm mediante el comando helm install .
helm install webfrontend webfrontend/
El servicio puede tardar unos minutos en devolver una dirección IP pública. Para supervisar el progreso, utilice
el comando kubectl get service con el argumento --watch .
$ kubectl get service --watch

webfrontend LoadBalancer 10.0.141.72 <pending> 80:32150/TCP 2m
...
webfrontend LoadBalancer 10.0.141.72 <EXTERNAL-IP> 80:32150/TCP 7m
Vaya al equilibrador de carga de la aplicación en un explorador mediante la <EXTERNAL-IP> para ver la aplicación
de ejemplo.

Use el comando az group delete para quitar el grupo de recursos, el clúster de AKS, el registro de contenedores,
las imágenes de contenedor almacenadas en la instancia de ACR y todos los recursos relacionados.
az group delete --name MyResourceGroup --yes --no-wait

NOTE
Pasos siguientes
Para más información sobre el uso de Helm, consulte la documentación de Helm.
Documentación de Helm
Tutorial: Preparación de una aplicación para Azure
Kubernetes Service (AKS)
En este tutorial, la primera parte de siete, se prepara una aplicación con varios contenedores para usarla en
Kubernetes. Las herramientas de desarrollo existentes como Docker Compose se usan para compilar y probar
una aplicación localmente. Aprenderá a:
Clonar el origen de una aplicación de ejemplo desde GitHub
Crear una imagen de contenedor a partir del origen de la aplicación de ejemplo
Probar la aplicación con varios contenedores en un entorno local de Docker
Tras finalizar, la siguiente aplicación se ejecuta en su entorno de desarrollo local:
En tutoriales posteriores, la imagen de contenedor se carga en una instancia de Azure Container Registry y
después se implementa en un clúster de AKS.
Antes de empezar
En este tutorial se asume que el usuario tiene un conocimiento básico de los principales conceptos de Docker,
como los contenedores, las imágenes de contenedor y los comandos de docker . Si es necesario, consulte la
introducción a Docker, donde encontrará datos básicos acerca de los contenedores.
Para completar este tutorial, se necesita un entorno de desarrollo de Docker local en el que se ejecuten
contenedores Linux. Docker proporciona paquetes que lo configuran en cualquier sistema Mac, Windows o
Linux.
NOTE
Azure Cloud Shell no incluye los componentes de Docker necesarios para completar todos los pasos de este tutorial. Por
lo tanto, se recomienda usar un entorno completo de desarrollo de Docker.
Obtención del código de la aplicación

La aplicación de ejemplo que se usa en este tutorial es una aplicación de votación básica, con un componente
web front-end y una instancia back-end de Redis. El componente web se empaqueta en una imagen de
contenedor personalizada. La instancia de Redis usa una imagen sin modificar de Docker Hub.
Use git para clonar la aplicación en su entorno de desarrollo:
git clone https://github.com/Azure-Samples/azure-voting-app-redis.git
Cambie al directorio clonado.
cd azure-voting-app-redis
En el directorio se encuentra el código fuente de la aplicación, un archivo de Docker Compose creado

previamente y un archivo de manifiesto de Kubernetes. Estos archivos se usan en todo el conjunto del tutorial. El
contenido y la estructura del directorio son los siguientes:
azure-voting-app-redis
│ azure-vote-all-in-one-redis.yaml
│ docker-compose.yaml
│ LICENSE
│ README.md
│
├───azure-vote
│ │ app_init.supervisord.conf
│ │ Dockerfile
│ │ Dockerfile-for-app-service
│ │ sshd_config
│ │
│ └───azure-vote
│ │ config_file.cfg
│ │ main.py
│ │
│ ├───static
│ │ default.css
│ │
│ └───templates
│ index.html
│
└───jenkins-tutorial
config-jenkins.sh
deploy-jenkins-vm.sh
Creación de imágenes de contenedor

Docker Compose se puede utilizar para automatizar la creación de imágenes de contenedor y la
implementación de aplicaciones con varios contenedores.
Use el archivo docker-compose.yaml de ejemplo para crear la imagen de contenedor, descargar la imagen de
Redis e iniciar la aplicación:
docker-compose up -d
Cuando haya finalizado, use el comando docker images para ver las imágenes creadas. Se han descargado o
creado tres imágenes. La imagen azure-vote-front contiene la aplicación de front-end y usa la imagen nginx-
flask como base. La imagen redis se usa para iniciar una instancia de Redis.
$ docker images
REPOSITORY TAG IMAGE ID CREATED

SIZE
mcr.microsoft.com/azuredocs/azure-vote-front v1 84b41c268ad9 9 seconds ago
944MB
mcr.microsoft.com/oss/bitnami/redis 6.0.8 3a54a920bb6c 2 days ago
103MB
tiangolo/uwsgi-nginx-flask python3.6 a16ce562e863 6 weeks ago
944MB
Ejecute el comando docker ps para ver los contenedores en ejecución:
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED

STATUS PORTS NAMES
d10e5244f237 mcr.microsoft.com/azuredocs/azure-vote-front:v1 "/entrypoint.sh /sta…" 3 minutes ago
Up 3 minutes 443/tcp, 0.0.0.0:8080->80/tcp azure-vote-front
21574cb38c1f mcr.microsoft.com/oss/bitnami/redis:6.0.8 "/opt/bitnami/script…" 3 minutes ago
Up 3 minutes 0.0.0.0:6379->6379/tcp azure-vote-back
Prueba local de la aplicación

Para ver la aplicación en ejecución, escriba http://localhost:8080 en un explorador web local. Se carga la
aplicación de ejemplo, como se muestra en el ejemplo siguiente:
Ahora que la funcionalidad de la aplicación se ha validado, los contenedores en ejecución se pueden detener y
eliminar. No elimine las imágenes de contenedor : en el siguiente tutorial, la imagen _azure-vote-front se
carga en una instancia de Azure Container Registry.
Detenga y quite las instancias de contenedor y los recursos con el comando docker-compose down:
docker-compose down
Cuando se haya quitado la aplicación local, tendrá una imagen de Docker con la aplicación Azure Vote, azure-
vote-front, que podrá usar en el siguiente tutorial.
Pasos siguientes
En este tutorial, se ha probado una aplicación y se han creado imágenes del contenedor para la aplicación. Ha
aprendido a:
Clonar el origen de una aplicación de ejemplo desde GitHub
Crear una imagen de contenedor a partir del origen de la aplicación de ejemplo
Probar la aplicación con varios contenedores en un entorno local de Docker
Pase al siguiente tutorial para aprender a almacenar imágenes de contenedor en Azure Container Registry.
Insertar imágenes en Azure Container Registry
Tutorial: Implementación y uso de Azure Container
Registry
Azure Container Registry (ACR) es un registro privado para imágenes de contenedor. Un registro de contenedor
privado permite compilar e implementar aplicaciones y código personalizado de forma segura. En este tutorial,
que es la segunda de las siete partes, se implementa una instancia de ACR y se insertar una imagen de
contenedor en ella. Aprenderá a:
Crear una instancia de Azure Container Registry (ACR)
Etiquetar una imagen de contenedor para ACR
Cargar la imagen a ACR
Ver las imágenes del registro
En tutoriales posteriores, esta instancia de ACR se integra con un clúster de Kubernetes en AKS y se implementa
una aplicación a partir de la imagen.
Antes de empezar
En el tutorial anterior, se creó una imagen de contenedor para una aplicación sencilla de Azure Voting. Si no ha
creado la imagen de la aplicación de Azure Voting, vuelva al Tutorial 1: creación de imágenes de contenedor.
Para realizar este tutorial es necesario ejecutar la versión 2.0.53, o superior, de la CLI de Azure. Ejecute
az --version para encontrar la versión. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure.
Creación de una instancia de Azure Container Registry

Para crear una instancia de Azure Container Registry, es preciso tener antes un grupo de recursos. Un grupo de
recursos de Azure es un contenedor lógico en el que se implementan y se administran los recursos de Azure.
Para crear un grupo de recursos, use el comando az group create. En el siguiente ejemplo, se crea un grupo de
recursos denominado myResourceGroup en la región eastus:
Cree una instancia de Azure Container Registry con el comando crear az acr y especifique su propio nombre de
registro. El nombre del registro debe ser único dentro de Azure y contener entre 5 y 50 caracteres
alfanuméricos. En el resto del tutorial, se usa <acrName> como marcador de posición del nombre del registro de
contenedor. Proporcione su propio nombre único de registro. La SKU básica es un punto de entrada optimizado
para costo con fines de desarrollo que proporciona un equilibrio entre almacenamiento y rendimiento.
az acr create --resource-group myResourceGroup --name <acrName> --sku Basic
Inicio de sesión en el registro de contenedor

Para usar la instancia de ACR, primero debe iniciar sesión. Use el comando az acr login y especifique el nombre
único que dio al registro de contenedor en el paso anterior.
az acr login --name <acrName>
Al finalizar, el comando devuelve un mensaje que indica que el inicio de sesión se ha realizado correctamente.
Etiquetado de una imagen de contenedor

Para ver una lista de las imágenes locales actuales, use el comando docker images:
docker images
La salida del comando anterior muestra una lista de las imágenes locales actuales:

SIZE
mcr.microsoft.com/azuredocs/azure-vote-front v1 84b41c268ad9 7 minutes ago
944MB
103MB
944MB
Para usar la imagen de contenedor azure-vote-front con ACR, se debe etiquetar con la dirección del servidor de
inicio de sesión del registro de imagen. Esta etiqueta se usa para el enrutamiento al insertar imágenes de
contenedor en un registro de imágenes.
Para obtener la dirección del servidor de inicio de sesión, use el comando az acr list y consulte loginServer como
se indica a continuación:
az acr list --resource-group myResourceGroup --query "[].{acrLoginServer:loginServer}" --output table
Ahora, etiquete la imagen azure-vote-front local con la dirección acrLoginServer del registro de contenedor. Para
indicar la versión de la imagen, agregue :v1 al final de su nombre:
docker tag mcr.microsoft.com/azuredocs/azure-vote-front:v1 <acrLoginServer>/azure-vote-front:v1
Para comprobar que se aplican las etiquetas, vuelva a ejecutar docker images.
docker images
Una imagen se etiqueta con la dirección de la instancia de ACR y un número de versión.

SIZE
mcr.microsoft.com/azuredocs/azure-vote-front v1 84b41c268ad9 16 minutes ago
944MB
mycontainerregistry.azurecr.io/azure-vote-front v1 84b41c268ad9 16 minutes ago
944MB
103MB
944MB
Inserción de imágenes en el registro
Con la imagen generada y etiquetada, inserte la imagen azure-vote-front en la instancia de ACR. Use docker
push y especifique su propia dirección acrLoginServer para el nombre de la imagen, tal como se muestra a
continuación:
docker push <acrLoginServer>/azure-vote-front:v1
La inserción de la imagen en ACR puede tardar varios minutos en completarse.
Lista de imágenes en el registro

Para que se devuelva una lista de las imágenes que se han insertado en la instancia de ACR, el usuario debe
utilizar el comando az acr repository list. Escriba su propio <acrName> como se indica a continuación:
az acr repository list --name <acrName> --output table
En la siguiente salida de ejemplo se muestra la imagen azure-vote-front como disponible en el registro:
Result
----------------
azure-vote-front
Para ver las etiquetas de una imagen concreta, use el comando az acr repository show-tags como se indica a
continuación:
az acr repository show-tags --name <acrName> --repository azure-vote-front --output table
La salida de ejemplo siguiente muestra la imagen de v1 etiquetada en un paso anterior:
Result
--------
v1
Ya hay una imagen de contenedor almacenada en una instancia de Azure Container Registry privada. En el
siguiente tutorial, dicha imagen se implementa desde ACR en un clúster de Kubernetes.
Pasos siguientes
En este tutorial, ha creado una instancia de Azure Container Registry y ha insertado una imagen para su uso en
un clúster de AKS. Ha aprendido a:
Crear una instancia de Azure Container Registry (ACR)
Etiquetar una imagen de contenedor para ACR
Cargar la imagen a ACR
Ver las imágenes del registro
Vaya al siguiente tutorial para aprender a implementar un clúster de Kubernetes en Azure.
Implementación de un clúster de Kubernetes
Tutorial: Implementación de un clúster de Azure
Kubernetes proporciona una plataforma distribuida para aplicaciones en contenedores. Con AKS, puede crear
rápidamente un clúster de Kubernetes listo para producción. En este tutorial, la tercera parte de siete, se
implementa un clúster de Kubernetes en AKS. Aprenderá a:
Implementación de un clúster de Kubernetes AKS que puede autenticarse en un registro de contenedor de
Azure
Instalar la CLI de Kubernetes (kubectl)
Configurar kubectl para conectarse a un clúster de AKS
En tutoriales posteriores, la aplicación Azure Vote se implementa en el clúster, se escala y se actualiza.
Antes de empezar
En los tutoriales anteriores, se creó una imagen de contenedor y se actualizó en una instancia de Azure
Container Registry. Si no ha realizado estos pasos, y desea continuar, inicie el Tutorial 1: Creación de imágenes
de contenedor.
Creación de un clúster de Kubernetes

Los clústeres de AKS pueden usar los controles de acceso basado en rol de Kubernetes (RBAC de Kubernetes).
Dichos controles permiten definir el acceso a los recursos en función de los roles asignados a los usuarios. Los
permisos se combinan si a un usuario se le asignan varios roles y los permisos se pueden limitar a un espacio
de nombres único o a todo el clúster. De forma predeterminada, la CLI de Azure habilita automáticamente RBAC
de Kubernetes al crear un clúster de AKS.
Cree un clúster de AKS mediante az aks create. En el ejemplo siguiente se crea un clúster denominado
myAKSCluster en el grupo de recursos denominado myResourceGroup. Este grupo de recursos se creó en el
tutorial anterior en la región eastus. En el ejemplo siguiente no se especifica una región, por lo que el clúster de
AKS también se crea en la región eastus. Para más información sobre los límites de recursos y la disponibilidad
de regiones para AKS, consulte Cuotas, restricciones de tamaño de máquina virtual y disponibilidad de regiones
en Azure Kubernetes Service (AKS).
Para permitir que un clúster de AKS interactúe con otros recursos de Azure, se crea automáticamente una
identidad de clúster, ya que no se especificó ninguna. Aquí, a esta identidad de clúster se le concede el derecho a
extraer imágenes de la instancia de Azure Container Registry (ACR) que creó en el tutorial anterior. Para ejecutar
el comando correctamente, es necesario tener un rol Propietario o Administrador de cuenta de Azure en
la suscripción de Azure.
az aks create \
--resource-group myResourceGroup \
--name myAKSCluster \
--node-count 2 \
--generate-ssh-keys \
--attach-acr <acrName>
Para evitar la necesidad de un rol Propietario o Administrador de cuenta de Azure , también puede
configurar una entidad de servicio manualmente para extraer imágenes de ACR. Para más información, consulte
Autenticación de ACR con entidades de servicio o Autenticación desde Kubernetes con un secreto de extracción.
También puede usar una identidad administrada en lugar de una entidad de servicio para facilitar la
administración.
Al cabo de varios minutos, la implementación se completa y devuelve información en formato JSON sobre la
implementación de AKS.
NOTE
Para asegurarse de que el clúster funciona de forma confiable, debe ejecutar al menos 2 (dos) nodos.
Instalación de la CLI de Kubernetes

Para conectarse al clúster de Kubernetes desde su equipo local, use kubectl, el cliente de la línea de comandos de
Kubernetes.
Si usa Azure Cloud Shell, kubectl ya está instalado. También lo puede instalar localmente. Para ello debe usar el
comando az aks install-cli:
az aks install-cli
Conexión a un clúster mediante kubectl

Para configurar kubectl para conectarse a su clúster de Kubernetes, use el comando az aks get-credentials. En
el ejemplo siguiente se obtienen las credenciales del clúster de AKS llamado myAKSCluster en el grupo de
recursos myResourceGroup:
Para comprobar la conexión al clúster, use ejecute el comando kubectl get nodes para devolver una lista de los
nodos del clúster:
$ kubectl get nodes

aks-nodepool1-37463671-vmss000000 Ready agent 2m37s v1.18.10
Pasos siguientes
En este tutorial, se ha implementado un clúster de Kubernetes en AKS y se ha configurado kubectl para
conectarse a él. Ha aprendido a:
Implementación de un clúster de Kubernetes AKS que puede autenticarse en un registro de contenedor de
Azure
Instalar la CLI de Kubernetes (kubectl)
Configurar kubectl para conectarse a un clúster de AKS
Vaya al siguiente tutorial para aprender a implementar una aplicación en el clúster.
Implementación de una aplicación en Kubernetes
Tutorial: Ejecución de aplicaciones en Azure
Kubernetes proporciona una plataforma distribuida para aplicaciones en contenedores. Compile e implemente
sus propios servicios y aplicaciones en un clúster de Kubernetes, y deje que el clúster administre la
disponibilidad y conectividad. En este tutorial, la cuarta parte de siete, se implementa una aplicación de ejemplo
en un clúster de Kubernetes. Aprenderá a:
Actualizar los archivos de manifiesto de Kubernetes
Ejecutar una aplicación en Kubernetes
En tutoriales posteriores, esta aplicación se escala horizontalmente y se actualiza.
Antes de empezar
En tutoriales anteriores se empaquetó una aplicación en una imagen de contenedor, se cargó esta imagen en
Azure Container Registry y se creó un clúster de Kubernetes.
Para completar este tutorial, necesita el archivo de manifiesto de Kubernetes azure-vote-all-in-one-redis.yaml
creado previamente. Este archivo se descargó con el código fuente de la aplicación en un tutorial anterior.
Confirme que ha clonado el repositorio y que ha cambiado los directorios en el repositorio clonado. Si no ha
realizado estos pasos, pero quiere continuar, comience con el Tutorial 1: Creación de imágenes de contenedor.
Actualización del archivo de manifiesto

En estos tutoriales, una instancia de Azure Container Registry (ACR) almacena la imagen del contenedor de la
aplicación de ejemplo. Para implementar la aplicación, debe actualizar el nombre de la imagen en el archivo de
manifiesto de Kubernetes para incluir el nombre del servidor de inicio de sesión de ACR.
Para obtener el nombre del servidor de inicio de sesión de ACR se usa el comando az acr list, como se muestra a
continuación:
El archivo de manifiesto de ejemplo del repositorio git clonado en el primer tutorial usa el nombre de servidor
de inicio de sesión microsoft. Asegúrese de que está en el directorio clonaod azure-voting-app-redis y abra el
archivo de manifiesto con un editor de texto, como vi :
vi azure-vote-all-in-one-redis.yaml
Reemplace microsoft por el nombre del servidor de inicio de sesión de ACR. El nombre de la imagen aparece en
la línea 60 del archivo de manifiesto. En el ejemplo siguiente se muestra el nombre de imagen predeterminado:
containers:
Especifique su propio nombre del servidor de inicio de sesión de ACR para que el archivo de manifiesto sea
parecido al del ejemplo siguiente:
containers:
image: <acrName>.azurecr.io/azure-vote-front:v1
Guarde y cierre el archivo. En vi , use :wq .
Implementación de la aplicación
Para implementar la aplicación, use el comando kubectl apply. Este comando analiza el archivo de manifiesto y
crea los objetos de Kubernetes definidos. Especifique el archivo de manifiesto de ejemplo, como se muestra en
el ejemplo siguiente:
kubectl apply -f azure-vote-all-in-one-redis.yaml
La salida de ejemplo siguiente muestra los recursos que se crearon correctamente en el clúster de AKS:
$ kubectl apply -f azure-vote-all-in-one-redis.yaml

En un primer momento, el parámetro EXTERNAL-IP del servicio azure-vote-front se muestra como pendiente:
Cuando la dirección EXTERNAL-IP cambie de pendiente a una dirección IP pública real, use CTRL-C para detener
el proceso de inspección de kubectl . En la salida del ejemplo siguiente se muestra una dirección IP pública
azure-vote-front LoadBalancer 10.0.34.242 52.179.23.131 80:30676/TCP 67s
Para ver la aplicación en acción, abra un explorador web en la dirección IP externa del servicio:
Si no se cargó la aplicación, esto se puede deber a un problema de autorización con el registro de la imagen.
Para ver el estado de los contenedores, use el comando kubectl get pods . Si las imágenes del contenedor no se
pueden extraer, consulte Autenticación con Azure Container Registry desde Azure Kubernetes Service.
Pasos siguientes
En este tutorial, una instancia de la aplicación Azure Vote de ejemplo se implementó en un clúster de Kubernetes
en AKS. Ha aprendido a:
Actualizar los archivos de manifiesto de Kubernetes
Ejecutar una aplicación en Kubernetes
Pase al siguiente tutorial para aprender a escalar una aplicación Kubernetes y la infraestructura de Kubernetes
subyacente.
Escalar infraestructura y aplicación de Kubernetes
Tutorial: Escalado de aplicaciones en Azure
Si ha seguido los tutoriales, tiene un clúster de Kubernetes en funcionamiento en AKS y ha implementado la

aplicación Azure Voting de ejemplo. En este tutorial, la parte cinco de siete, se escalan horizontalmente los pods
en la aplicación y se prueba el escalado automático de pods. También se aprende a escalar el número de nodos
de VM de Azure para cambiar la capacidad del clúster de hospedar cargas de trabajo. Aprenderá a:
Escalar los nodos de Kubernetes
Escalar de forma manual pods de Kubernetes que ejecutan la aplicación
Configurar el escalado automático de pods que ejecutan el front-end de la aplicación
En tutoriales posteriores, la aplicación Azure Vote se actualiza a una nueva versión.
Antes de empezar
En los tutoriales anteriores se empaquetó una aplicación en una imagen de contenedor. Esta imagen se cargó en
Azure Container Registry y el usuario creó un clúster de AKS. Luego la aplicación se implementó en el clúster de
AKS. Si no ha realizado estos pasos, pero quiere continuar, comience con el Tutorial 1: Creación de imágenes de
contenedor.
Escalado manual de pods

Cuando el front-end de Azure Vote y la instancia de Redis se implementaron en los tutoriales anteriores, se creó
una única réplica. Para ver el número y el estado de los pods del clúster, use el comando kubectl get como se
indica a continuación:
kubectl get pods
La salida del ejemplo siguiente muestra un pod de front-end y un pod de back-end:
NAME READY STATUS RESTARTS AGE

azure-vote-back-2549686872-4d2r5 1/1 Running 0 31m
azure-vote-front-848767080-tf34m 1/1 Running 0 31m
Para cambiar manualmente el número de pods en la implementación azure-vote-front, use el comando kubectl
scale. El ejemplo siguiente aumenta el número de pods de front-end a 5:
kubectl scale --replicas=5 deployment/azure-vote-front
Ejecute de nuevo el comando kubectl get pods para comprobar que AKS crea los pods adicionales. Tras un
minuto aproximadamente, los pods adicionales estarán disponibles en el clúster:
kubectl get pods
READY STATUS RESTARTS AGE

azure-vote-back-2606967446-nmpcf 1/1 Running 0 15m
azure-vote-front-3309479140-2hfh0 1/1 Running 0 3m
azure-vote-front-3309479140-bzt05 1/1 Running 0 3m
azure-vote-front-3309479140-fvcvm 1/1 Running 0 3m
azure-vote-front-3309479140-hrbf2 1/1 Running 0 15m
azure-vote-front-3309479140-qphz8 1/1 Running 0 3m
Escalado automático de pods

Kubernetes admite el escalado horizontal automático de pods para ajustar el número de pods en una
implementación en función del uso de la CPU o de otras métricas de selección. El servidor de medición se usa
para proporcionar utilización de recursos a Kubernetes y se implementa automáticamente en clústeres de Azure
Kubernetes Service de la versión 1.10 o posteriores. Para ver la versión del clúster de Azure Kubernetes Service,
use el comando az aks show, tal y como se muestra en el ejemplo siguiente:
az aks show --resource-group myResourceGroup --name myAKSCluster --query kubernetesVersion --output table
NOTE
Si la versión del clúster de Azure Kubernetes Service es anterior a 1.10, el servidor de métricas no se instala
automáticamente. Los manifiestos de instalación del servidor de medición están disponibles como un recurso
components.yaml en las versiones del servidor de medición, lo que significa que puede instalarlos a través de una
dirección URL. Para más información sobre estas definiciones de YAML, consulte la sección de implementación del archivo
Léame.
Instalación de ejemplo:
kubectl apply -f https://github.com/kubernetes-sigs/metrics-

server/releases/download/v0.3.6/components.yaml
Para usar la autoescala, todos los contenedores de los pod y los pods deben tener definidos solicitudes y límites
de CPU. En la implementación de azure-vote-front , el contenedor del front-end ya solicita 0,25 CPU, con un
límite de 0,5 CPU. Estas solicitudes de recursos y los límites se definen tal y como se muestra en el siguiente
fragmento de código de ejemplo:
resources:
requests:
cpu: 250m
limits:
cpu: 500m
En el ejemplo siguiente se usa el comando kubectl autoscale para escalar automáticamente el número de pods
en la implementación azure-vote-front. Si el uso medio de la CPU en todos los pods supera el 50 % del uso
solicitado, la escalabilidad automática aumenta el valor de los pods hasta un máximo de 10 instancias. Luego se
define un mínimo de 3 instancias para la implementación:
kubectl autoscale deployment azure-vote-front --cpu-percent=50 --min=3 --max=10
También puede crear un archivo de manifiesto para definir el comportamiento de escalabilidad automática y
límites de recursos. A continuación se muestra un ejemplo de un archivo de manifiesto llamado
azure-vote-hpa.yaml .
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: azure-vote-back-hpa
spec:
maxReplicas: 10 # define max replica count
minReplicas: 3 # define min replica count
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
targetCPUUtilizationPercentage: 50 # target CPU utilization
---
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: azure-vote-front-hpa
spec:
maxReplicas: 10 # define max replica count
minReplicas: 3 # define min replica count
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
targetCPUUtilizationPercentage: 50 # target CPU utilization
Use kubectl applypara aplicar la escalabilidad automática definida en el archivo de manifiesto

azure-vote-hpa.yaml .
kubectl apply -f azure-vote-hpa.yaml
Para ver el estado del escalador automático, use el comando kubectl get hpa como se indica a continuación:
kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE

azure-vote-front Deployment/azure-vote-front 0% / 50% 3 10 3 2m
Después de unos minutos con carga mínima en la aplicación Azure Vote, el número de réplicas del pod se
reduce automáticamente a tres. Puede usar nuevamente kubectl get pods para ver los pods innecesarios que
se han eliminado.
Escalado manual de nodos de AKS

Si creó el clúster de Kubernetes mediante los comandos en el tutorial anterior, este tiene dos nodos. Puede
ajustar el número de nodos manualmente si tiene previsto usar más o menos cargas de trabajo de contenedor
en el clúster.
En el ejemplo siguiente, el número de nodos aumenta a tres en el clúster de Kubernetes denominado
myAKSCluster. El comando tarda unos minutos en completarse.
az aks scale --resource-group myResourceGroup --name myAKSCluster --node-count 3

Cuando el clúster se escaló correctamente, el resultado es similar al ejemplo siguiente:
{
"count": 3,
"dnsPrefix": null,
"fqdn": null,
"name": "myAKSCluster",
"osDiskSizeGb": null,
"osType": "Linux",
"ports": null,
"storageProfile": "ManagedDisks",
"vmSize": "Standard_D2_v2",
"vnetSubnetId": null
}
Pasos siguientes
En este tutorial, se han usado distintas características de escalado en el clúster de Kubernetes. Ha aprendido a:
Escalar de forma manual pods de Kubernetes que ejecutan la aplicación
Configurar el escalado automático de pods que ejecutan el front-end de la aplicación
Escalado manual de los nodos de Kubernetes
Vaya al siguiente tutorial para aprender a actualizar la aplicación en Kubernetes.
Actualización de una aplicación en Kubernetes
Tutorial: Actualización de una aplicación en Azure
Después de implementar una aplicación en Kubernetes, se puede actualizar especificando una nueva imagen de
contenedor o la versión de la imagen. Una actualización se preconfigura para que solo una parte de la
implementación se actualice al mismo tiempo. Esta actualización preconfigurada permite que la aplicación siga
ejecutándose durante la actualización. También proporciona un mecanismo de reversión si se produce un error
de implementación.
En este tutorial, la sección seis de siete, se actualiza la aplicación de ejemplo de Azure Vote. Aprenderá a:
Actualizar el código de la aplicación de front-end
Crear una imagen de contenedor actualizada
Insertar una imagen de contenedor en Azure Container Registry
Implementar la imagen de contenedor actualizada
Antes de empezar
AKS.
También se clonó un repositorio de aplicaciones que incluye el código fuente de la aplicación y un archivo de
Docker Compose creado previamente que se usa en este tutorial. Confirme que ha creado un clon del
repositorio y que ha cambiado los directorios en el repositorio clonado. Si no ha finalizado estos pasos y desea
continuar, comience con el Tutorial 1: Creación de imágenes de contenedor.
Actualización de una aplicación

Vamos a realizar un cambio en la aplicación de ejemplo y, después, a actualizar la versión ya implementada en el
clúster de AKS. Asegúrese de que está en el directorio clonado azure-voting-app-redis. El código fuente de la
aplicación de ejemplo se puede encontrar en el directorio azure-vote. Abra el archivo config_file.cfg con un
editor, como vi :
vi azure-vote/azure-vote/config_file.cfg
Cambie los valores de VOTE1VALUE y VOTE2VALUE por otros diferentes, como colores. En el ejemplo siguiente
se muestran los valores actualizados:
# UI Configurations
TITLE = 'Azure Voting App'
VOTE1VALUE = 'Blue'
VOTE2VALUE = 'Purple'
SHOWHOST = 'false'
Guarde y cierre el archivo. En vi , use :wq .
Actualización de la imagen del contenedor

Para volver a crear la imagen del front-end y probar la aplicación actualizada, use docker-compose. El
argumento --build se emplea para indicar a Docker Compose que vuelva a crear la imagen de la aplicación.
docker-compose up --build -d
Prueba de la aplicación de forma local

Para comprobar que la imagen de contenedor actualizada muestra los cambios, abra un explorador web local en
http://localhost:8080 .
Los valores actualizados que se proporcionan en el archivo config_file.cfg se muestran en la aplicación en

ejecución.
Etiquetado e inserción de la imagen

Para usar correctamente la imagen actualizada, etiquete la imagen azure-vote-front con el nombre del servidor
de inicio de sesión de seguridad del registro de ACR. Para obtener el nombre del servidor de inicio de sesión,
use el comando az acr list:
Use la docker tag para etiquetar la imagen. Reemplace <acrLoginServer> por el nombre del servidor de inicio de
sesión de ACR o el nombre de host del registro público y actualice la versión de la imagen a : v2 como se
muestra a continuación:
docker tag mcr.microsoft.com/azuredocs/azure-vote-front:v1 <acrLoginServer>/azure-vote-front:v2
Ahora use docker push para cargar la imagen en el registro. Reemplace <acrLoginServer> por el nombre del
servidor de inicio de sesión de ACR.
NOTE
Si surgen problemas al realizar inserciones en el registro de ACR, asegúrese de que no se ha cerrado la sesión. Ejecute el
comando az acr login y use el nombre de la instancia de Azure Container Registry que creó en el paso Creación de una
instancia de Azure Container Registry. Por ejemplo, az acr login --name <azure container registry name> .
docker push <acrLoginServer>/azure-vote-front:v2
Implementación de la aplicación actualizada

Para proporcionar el tiempo máximo de actividad, se deben ejecutar varias instancias del pod de aplicación.
Compruebe el número de instancias de front-end en ejecución con el comando kubectl get pods:
$ kubectl get pods

azure-vote-back-217588096-5w632 1/1 Running 0 10m
azure-vote-front-233282510-b5pkz 1/1 Running 0 10m
azure-vote-front-233282510-dhrtr 1/1 Running 0 10m
azure-vote-front-233282510-pqbfk 1/1 Running 0 10m
Si no tiene varios pods de front-end, escale la implementación de azure-vote-front de la manera siguiente:
kubectl scale --replicas=3 deployment/azure-vote-front
Use el comando kubectl set para actualizar la aplicación. Actualice <acrLoginServer> con el nombre de host o de
servidor de inicio de sesión del registro del contenedor y especifique la versión de la aplicación v2:
kubectl set image deployment azure-vote-front azure-vote-front=<acrLoginServer>/azure-vote-front:v2
Para supervisar la implementación, use el comando kubectl get pod. A medida que se implementa la aplicación
actualizada, sus pods se terminan y se vuelven a crear con la nueva imagen de contenedor.
kubectl get pods
La salida del ejemplo siguiente muestra los pods que terminan y las nuevas instancias que se ejecutan a medida
que progresa la implementación:
$ kubectl get pods

azure-vote-back-2978095810-gq9g0 1/1 Running 0 5m
azure-vote-front-1297194256-tpjlg 1/1 Running 0 1m
azure-vote-front-1297194256-tptnx 1/1 Running 0 5m
azure-vote-front-1297194256-zktw9 1/1 Terminating 0 1m
Prueba de la aplicación actualizada

Para ver la aplicación actualizada, obtenga primero la dirección IP externa del servicio azure-vote-front :
kubectl get service azure-vote-front
Ahora, abra un explorador web a la dirección IP del servicio:
Pasos siguientes
En este tutorial, ha actualizado una aplicación y ha implementado esta actualización en el clúster de AKS. Ha
aprendido a:
Actualizar el código de la aplicación de front-end
Crear una imagen de contenedor actualizada
Insertar una imagen de contenedor en Azure Container Registry
Implementar la imagen de contenedor actualizada
Pase al siguiente tutorial para aprender a actualizar un clúster de AKS a una nueva versión de Kubernetes.
Actualización de Kubernetes
Tutorial: Actualización de Kubernetes en Azure
Como parte del ciclo de vida de la aplicación y del clúster, es posible que desee actualizar su versión de
Kubernetes a la más reciente y usar las nuevas características. Un clúster de Azure Kubernetes Service (AKS) se
puede actualizar mediante la CLI de Azure.
En este tutorial, la séptima parte de siete, se actualiza un clúster de Kubernetes. Aprenderá a:
Identificación de las versiones de Kubernetes actuales y disponibles
Actualización de los nodos de Kubernetes
Validación de una actualización correcta
Antes de empezar
AKS. Si no ha realizado estos pasos, pero desea continuar, comience con el Tutorial 1: Creación de imágenes de
contenedor.
Para realizar este tutorial es necesario disponer de la versión 2.0.53, o superior, de la CLI de Azure. Ejecute
Obtención de las versiones disponibles del clúster

Antes de actualizar un clúster, use el comando az aks get-upgrades para comprobar qué versiones de
Kubernetes están disponibles para la actualización:
az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster
En el siguiente ejemplo, la versión actual es la 1.18.10 y las versiones disponibles se muestran bajo upgrades
(actualizaciones).
{
"agentPoolProfiles": null,
"controlPlaneProfile": {
"kubernetesVersion": "1.18.10",
...
"upgrades": [
{
"isPreview": null,
"kubernetesVersion": "1.19.1"
},
{
"isPreview": null,
"kubernetesVersion": "1.19.3"
}
]
},
...
}
Actualizar un clúster
Para minimizar las interrupciones en las aplicaciones en ejecución, los nodos de AKS se acordonan y purgan
minuciosamente. En este proceso, se realizan los pasos siguientes:
1. El programador de Kubernetes impide que se programen pods adicionales en un nodo que se va a actualizar.
2. Los pods en ejecución en el nodo se programan en otros nodos del clúster.
3. Se crea un nodo que ejecuta los componentes más recientes de Kubernetes.
4. Cuando el nuevo nodo está listo y se ha unido al clúster, el programador de Kubernetes comienza a ejecutar
pods en él.
5. El nodo antiguo se elimina y el siguiente nodo del clúster comienza el proceso de acordonamiento y purga.
Use el comando az aks upgrade para actualizar el clúster de AKS.
az aks upgrade \
--kubernetes-version KUBERNETES_VERSION
NOTE
No se pueden actualizar varias versiones secundarias al mismo tiempo. Por ejemplo, puede realizar la actualización de la
versión 1.14.x a la 1.15.x, pero no de la 1.14.x a la 1.16.x directamente. Para actualizar de la versión 1.14.x a la 1.16.x,
primero actualice de la 1.14.x a la 1.15.x y, después, realice otra actualización de la versión 1.15.x a la 1.16.x.
La siguiente salida de ejemplo condensada muestra el resultado de la actualización a la versión 1.19.1. Observe
que ahora en kubernetesVersion se puede ver 1.19.1:
{
{
"count": 3,
"maxPods": 110,
"name": "nodepool1",
"osType": "Linux",
"vmSize": "Standard_DS1_v2",
}
],
"dnsPrefix": "myAKSClust-myResourceGroup-19da35",
"enableRbac": false,
"fqdn": "myaksclust-myresourcegroup-19da35-bd54a4be.hcp.eastus.azmk8s.io",
"id": "/subscriptions/<Subscription
ID>/resourcegroups/myResourceGroup/providers/Microsoft.ContainerService/managedClusters/myAKSCluster",
"name": "myAKSCluster",
"type": "Microsoft.ContainerService/ManagedClusters"
}
Validación de una actualización

Confirme que la actualización se realizó correctamente con el comando az aks show, tal como se muestra a
continuación:
az aks show --resource-group myResourceGroup --name myAKSCluster --output table
La salida del ejemplo siguiente muestra que el clúster de AKS ejecuta KubernetesVersion 1.19.1:
Name Location ResourceGroup KubernetesVersion ProvisioningState Fqdn

------------ ---------- --------------- ------------------- ------------------- -----------------------
-----------------------------------------
myAKSCluster eastus myResourceGroup 1.19.1 Succeeded myaksclust-
myresourcegroup-19da35-bd54a4be.hcp.eastus.azmk8s.io

Como este tutorial es la última parte de la serie, puede que quiera eliminar el clúster de AKS. Mientras los nodos
de Kubernetes se ejecutan en Azure Virtual Machines (VM), seguirán acumulando cargos, aunque no se use el
clúster. Use el comando az group delete para quitar el grupo de recursos, el servicio de contenedor y todos los
recursos relacionados.
NOTE
eliminación de AKS. Si usó una identidad administrada, esta está administrada por la plataforma y no requiere que
aprovisione o rote los secretos.
Pasos siguientes
En este tutorial, actualizó Kubernetes en un clúster de AKS. Ha aprendido a:
Identificación de las versiones de Kubernetes actuales y disponibles
Actualización de los nodos de Kubernetes
Validación de una actualización correcta
Para más información sobre AKS, consulte Introducción a AKS. Para instrucciones sobre cómo crear soluciones
completas con AKS, consulte Guía de soluciones de AKS.
Conceptos básicos de Kubernetes de Azure
El desarrollo de aplicaciones continúa avanzando hacia un enfoque basado en contenedores, lo que aumenta
nuestra necesidad de orquestar y administrar recursos. Como plataforma líder, Kubernetes proporciona una
programación de confianza de cargas de trabajo de aplicaciones tolerantes a errores. Azure Kubernetes Service
(AKS) es una oferta administrada de Kubernetes que simplifica aún más la implementación y administración de
aplicaciones basadas en contenedores.
En este artículo se presentan:
Componentes básicos de la infraestructura de Kubernetes:
Plano de control
Nodos
Grupos de nodos
Recursos de carga de trabajo:
Pods
deployments
Conjuntos
Cómo agrupar recursos en espacios de nombres.
¿Qué es Kubernetes?
Kubernetes es una plataforma de rápida evolución que administra aplicaciones basadas en contenedores y sus
componentes de red y almacenamiento asociados. Se centra en las cargas de trabajo de la aplicación, no en los
componentes subyacentes de la infraestructura. Kubernetes proporciona un enfoque declarativo en las
implementaciones, respaldado por un sólido conjunto de API para las operaciones de administración.
Usted puede compilar y ejecutar aplicaciones modernas, portátiles y basadas en microservicios, usando
Kubernetes para orquestar y administrar la disponibilidad de sus componentes. Kubernetes admite tanto
aplicaciones con estado como sin estado, a medida que los equipos progresan a través de la adopción de
aplicaciones basadas en microservicios.
Como plataforma abierta, Kubernetes le permite compilar aplicaciones con el lenguaje de programación, el
sistema operativo, las bibliotecas o el bus de mensajería que prefiera. La integración continua y las herramientas
de entrega continua (CI/CD) existentes pueden integrarse con Kubernetes para programar e implementar
versiones.
AKS proporciona un servicio administrado de Kubernetes que reduce la complejidad de la implementación y de
tareas básicas de administración, como la coordinación de actualizaciones. La plataforma Azure administra el
plano de control de AKS, y usted solo paga los nodos de AKS que ejecutan sus aplicaciones. AKS se ha diseñado
sobre el motor de código abierto de Azure Kubernetes Service (aks-engine).
Arquitectura del clúster de Kubernetes

Un clúster de Kubernetes se divide en dos componentes:
Plano de control: proporciona los servicios básicos de Kubernetes y la orquestación de las cargas de trabajo
de las aplicaciones.
Nodos: ejecutan las cargas de trabajo de las aplicaciones.
Plano de control
Cuando crea un clúster AKS, se crea y configura automáticamente un plano de control. Este plano de control se
proporciona sin coste alguno como recurso administrado de Azure que se extrae del usuario. Usted solo paga
los nodos asociados al clúster de AKS. El plano de control y sus recursos solo residen en la región en la que creó
el clúster.
El plano de control incluye los siguientes componentes principales de Kubernetes:
C O M P O N EN T E DESC RIP C IÓ N
kube-apiserver El servidor de API es el modo en el que se exponen las API

de Kubernetes subyacentes. Este componente proporciona la
interacción de las herramientas de administración, como
kubectl o el panel de Kubernetes.
etcd Para mantener el estado del clúster de Kubernetes y la

configuración, el componente etcd de alta disponibilidad es
un almacén de pares clave-valor en Kubernetes.
kube-scheduler Al crear o escalar aplicaciones, Scheduler determina qué

nodos pueden ejecutar la carga de trabajo y los inicia.
kube-controller-manager El administrador de controladores supervisa un número de

controladores más pequeños que realizan acciones, como
replicar pods y controlar operaciones de nodos.
AKS proporciona un plano de control de inquilino único con un servidor de API dedicado, Scheduler, etc. Usted
define el número de nodos y su tamaño, mientras que la plataforma Azure configura la comunicación segura
entre el plano de control y los nodos. La interacción con el plano de control se produce a través de las API de
Kubernetes, como kubectl o el panel de Kubernetes.
Aunque no es necesario configurar componentes (como el almacén etcd de alta disponibilidad) con este plano
de control administrado, usted no puede obtener acceso al plano de control directamente. Las actualizaciones
del plano de control y de los nodos de Kubernetes se orquestan a través de CLI de Azure o de Azure Portal. Para
solucionar los posibles problemas, puede revisar los registros del plano de control mediante registros de Azure
Monitor.
Para configurar un plano de control o acceder a este directamente, implemente su propio clúster de Kubernetes
mediante aks-engine.
Para los procedimientos recomendados asociados, consulte Procedimientos recomendados para administrar la
seguridad y las actualizaciones de los clústeres en Azure Kubernetes Service (AKS).
Nodos y grupos de nodos
Para ejecutar las aplicaciones y los servicios de soporte técnico, necesitará un nodo de Kubernetes. Un clúster de
AKS tiene al menos un nodo, una máquina virtual de Azure que ejecuta los componentes de nodo de
Kubernetes y el entorno de ejecución del contenedor.
C O M P O N EN T E DESC RIP C IÓ N
kubelet Agente de Kubernetes que procesa las solicitudes de

orquestación desde el plano de control y la programación de
la ejecución de los contenedores solicitados.
kube-proxy Controla las redes virtuales en cada nodo. El proxy enruta el

tráfico de red y administra las direcciones IP para los
servicios y los pods.
entorno de ejecución de contenedor Permite que las aplicaciones contenedorizadas ejecuten

recursos adicionales, como la red virtual y el
almacenamiento, e interactúen con estos. Los clústeres de
AKS que usan grupos de nodos con la versión 1.19 de
Kubernetes u otras posteriores usan containerd como
entorno de ejecución del contenedor. Los clústeres de AKS
que usan grupos de nodos con versiones de Kubernetes
anteriores a la 1.19 utilizan Moby (docker ascendente) como
entorno de ejecución de contenedor.
El tamaño de la máquina virtual de Azure para los nodos define las CPU, la memoria, el tamaño y el tipo del
almacenamiento disponible (por ejemplo, SSD de alto rendimiento o HDD normal). Planee el tamaño de los
nodos en función de si las aplicaciones pueden requerir grandes cantidades de CPU y memoria o
almacenamiento de alto rendimiento. Escale horizontalmente el número de nodos del clúster de AKS para
satisfacer la demanda.
En AKS, la imagen de máquina virtual para los nodos del clúster se basa en Ubuntu Linux o Windows Server
2019. Al crear un clúster de AKS o escalar horizontalmente el número de nodos, la plataforma Azure crea y
configura automáticamente el número solicitado de máquinas virtuales. Los nodos de agente se facturan como
máquinas virtuales estándar, por lo que cualquier descuento en el tamaño de la máquina virtual (incluidas
reservas de Azure) se aplica automáticamente.
Implemente su propio clúster de Kubernetes con aks-engine si usa un sistema operativo host diferente o un
entorno de ejecución de contenedor, o bien si incluye distintos paquetes personalizados. El componente
aks-engine ascendente incluye y ofrece opciones de configuración antes de que se admitan en los clústeres de
AKS. Por lo tanto, si quiere usar un entorno de ejecución de contenedor que no sea containerd ni Moby, puede
ejecutar aks-engine para configurar e implementar un clúster de Kubernetes que satisfaga sus necesidades
actuales.
Reservas de recursos
AKS usa recursos de nodo para ayudar al nodo a funcionar como parte del clúster. Este uso puede crear
discrepancias entre los recursos totales del nodo y los recursos que se pueden asignar en AKS. Tenga esto
presente al establecer solicitudes y límites para los pods implementados por el usuario.
Para buscar la ejecución de los recursos de un nodo que se pueden asignar:
kubectl describe node [NODE_NAME]
Para mantener la funcionalidad y el rendimiento de los nodos, AKS reserva recursos en cada nodo. A medida
que aumentan los recursos de un nodo, la reserva de recursos también crece debido a la mayor necesidad de
administrar pods implementados por el usuario.
NOTE
El uso de complementos AKS como Container Insights (OMS) consumirá recursos de nodo adicionales.
Hay reservados dos tipos de recursos:

CPU
La CPU reservada depende del tipo de nodo y de la configuración del clúster, lo que puede provocar que
haya menos CPU para asignar, debido a la ejecución de otras características.
N ÚC L EO S
DE C P U
EN EL
H O ST 1 2 4 8 16 32 64
Reservado 60 100 140 180 260 420 740

para Kube
(milinúcleo
s)
Memoria
La memoria que utiliza AKS incluye la suma de dos valores.
1. Demonio kubelet
El demonio kubelet se instala en todos los nodos de agente de Kubernetes para administrar la
creación y terminación de contenedores.
De forma predeterminada en AKS, el demonio kubelet tiene la regla de expulsión
memory.available<750Mi, que garantiza que un nodo siempre tenga al menos 750 Mi asignables
en todo momento. Cuando un host esté por debajo de ese umbral de memoria disponible, se
activará kubelet para finalizar uno de los pods en ejecución y liberar memoria en el equipo host.
2. Tasa regresiva de reser vas de memoria para que el demonio “kubelet” funcione
correctamente (kube-reserved).
25 % de los primeros 4 GB de memoria
20 % de los siguientes 4 GB de memoria (hasta 8 GB)
2 % de cualquier memoria que esté por encima de 128 GB
Las reglas de asignación de memoria y CPU:
mantienen los nodos de agente en buen estado, incluidos algunos pods del sistema host críticos para el
mantenimiento del clúster y
hacen que el nodo notifique un volumen menor de memoria y CPU asignables que el que notificaría si no
formase parte de un clúster de Kubernetes.
Las reservas de recursos anteriores no se pueden cambiar.
Por ejemplo, si un nodo ofrece 7 GB, informará del 34 % de la memoria no asignable, incluido el umbral de
expulsión estricto de 750 Mi.
0.75 + (0.25*4) + (0.20*3) = 0.75GB + 1GB + 0.6GB = 2.35GB / 7GB = 33.57% reserved
Además de las reservas para Kubernetes mismo, el sistema operativo del nodo subyacente también reserva una
cantidad de recursos de CPU y memoria para mantener las funciones del sistema operativo.
Para consultar los procedimientos recomendados asociados, consulteProcedimientos recomendados para
características básicas del programador en Azure Kubernetes Service (AKS).
Grupos de nodos
Los nodos de la misma configuración se agrupan en grupos de nodos. Un clúster de Kubernetes contiene al
menos un grupo de nodos. El número de nodos y el tamaño iniciales se definen al crear un clúster de AKS, que
crea un grupo de nodos predeterminado. Este grupo de nodos predeterminado de AKS contiene las máquinas
virtuales subyacentes que ejecutan los nodos del agente.
NOTE
Para asegurarse de que el clúster funcione de forma fiable, debe ejecutar al menos dos (2) nodos del grupo
predeterminado.
Los clústeres de AKS se escalan o actualizan con relación al grupo de nodos predeterminado. También se puede
optar por escalar o actualizar un grupo de nodos específico. Para las operaciones de actualización, los
contenedores en ejecución se programan en otros nodos del grupo de nodos hasta que todos los nodos se
actualizan correctamente.
Para obtener más información sobre cómo usar varios grupos de nodos en AKS, consulte Creación y
administración de varios grupos de nodos para un clúster en AKS.
Selectores de nodos
En un clúster de AKS con varios grupos de nodos, es posible que tenga que indicar a Scheduler de Kubernetes
qué grupo de nodos se debe utilizar para un recurso determinado. Por ejemplo, los controladores de entrada no
deben ejecutarse en los nodos de Windows Server.
Los selectores de nodo le permiten definir varios parámetros, por ejemplo, el sistema operativo del nodo, para
controlar dónde se debe programar un pod.
El siguiente ejemplo básico programa una instancia de NGINX en un nodo Linux mediante el selector de nodos
"beta.kubernetes.io/os": linux:
kind: Pod
apiVersion: v1
metadata:
name: nginx
spec:
containers:
- name: myfrontend
image: mcr.microsoft.com/oss/nginx/nginx:1.15.12-alpine
nodeSelector:
Para más información sobre cómo controlar pods en grupos de nodos, consulte Procedimientos recomendados
para las características avanzadas del programador en AKS.
Pods
Kubernetes utiliza pods para ejecutar una instancia de la aplicación. Un pod representa una instancia individual
de la aplicación.
Los pods suelen tener una asignación de uno a uno con un contenedor. En escenarios avanzados, un pod puede
contener varios contenedores. Los pods de varios contenedores se programan conjuntamente en el mismo
nodo y permiten que los contenedores compartan recursos relacionados.
Al crear un pod, puede definir solicitudes de recursos para solicitar una determinada cantidad de recursos de
memoria o CPU. Scheduler de Kubernetes intenta satisfacer la solicitud programando los pods para que se
ejecuten en un nodo con recursos disponibles. También puede especificar límites de recursos máximos, con el
fin de impedir que un pod consuma demasiados recursos de proceso del nodo subyacente. El procedimiento
recomendado consiste en incluir límites de recursos para todos los pods, con el fin de ayudar a Scheduler de
Kubernetes a identificar qué recursos son necesarios y cuáles se permiten.
Para obtener más información, consulte Pods de Kubernetes y Ciclo de vida de pods de Kubernetes.
Un pod es un recurso lógico, pero las cargas de trabajo de aplicaciones se ejecutan en los contenedores. Los
pods suelen ser recursos efímeros y descartables. Los pods programados por separado carecen de algunas de
las características de alta disponibilidad y redundancia de Kubernetes. En su lugar, los pods se implementan y
administran mediante controladores de Kubernetes, como el controlador de implementación.
Implementaciones y manifiestos YAML

Una implementación representa pods idénticos administrados por el controlador de implementación de
Kubernetes. Una implementación define el número de réplicas de pod que deben crearse. Scheduler de
Kubernetes garantiza que se programen pods adicionales en nodos correctos si los pods o los nodos tienen
problemas.
Puede actualizar implementaciones para cambiar la configuración de los pods, la imagen del contenedor que se
ha utilizado o el almacenamiento conectado. El controlador de implementación:
purga y finaliza un número determinado de réplicas;
crea réplicas a partir de la nueva definición de implementación;
continúa el proceso hasta que se actualizan todas las réplicas de la implementación.
La mayoría de las aplicaciones sin estado de AKS debe usar el modelo de implementación en lugar de
programar pods individuales. Kubernetes puede supervisar el mantenimiento de las implementaciones para
garantizar que se ejecute el número de réplicas necesario dentro del clúster. Cuando se programan por
separado, los pods no se reinician en caso de producirse un problema, ni tampoco se vuelven a programar en
nodos correctos si el que sufre un problema es su nodo actual.
No es aconsejable trastocar decisiones de administración con un proceso de actualización si la aplicación
requiere un número mínimo de instancias disponibles. Los presupuestos de interrupción de pods definen el
número de réplicas de una implementación que se pueden quitar durante una actualización o la actualización de
un nodo. Por ejemplo, si tiene cinco (5) réplicas en la implementación, puede definir una interrupción del pod
de 4 (cuatro) para permitir que solo se elimine o se vuelva a programar una réplica a la vez. Como en el caso de
los límites de recursos de pods, el procedimiento recomendado consiste en definir presupuestos de interrupción
de pods en aplicaciones que requieran que siempre esté presente un número mínimo de réplicas.
Normalmente, las implementaciones se crean o administran con kubectl create o kubectl apply . Cree una
implementación definiendo un archivo de manifiesto en formato YAML.
En el ejemplo siguiente, se crea una implementación básica del servidor web NGINX. La implementación
especifica que se crearán tres (3) réplicas y requiere que el puerto 80 esté abierto en el contenedor. También se
definen las solicitudes de recursos y los límites de CPU y memoria.
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
ports:
- containerPort: 80
resources:
requests:
cpu: 250m
memory: 64Mi
limits:
cpu: 500m
memory: 256Mi
Es posible crear aplicaciones más complejas incluyendo servicios (como equilibradores de carga) en el
manifiesto YAML.
Para más información, consulte el artículo sobre las implementaciones de Kubernetes.
Administración de paquetes con Helm
Helm se usa normalmente para administrar aplicaciones en Kubernetes. Puede implementar recursos
compilando y usando gráficos públicos de Helm ya existentes que contengan una versión empaquetada de
código de aplicación y manifiestos YAML de Kubernetes. Estos gráficos de Helm pueden almacenarse localmente
o en un repositorio remoto, como un repositorio de gráficos de Helm de Azure Container Registry.
Para usar Helm, instale el cliente de Helm en el equipo o use el cliente de Helm en Azure Cloud Shell. Busque o
cree gráficos de Helm y, después, instálelos en el clúster de Kubernetes. Para más información, consulte
Instalación de aplicaciones existentes con Helm en AKS.
StatefulSets y DaemonSets
El controlador de implementación usa Scheduler de Kubernetes para ejecutar réplicas en cualquier nodo
disponible que cuente con recursos. Aunque este enfoque puede bastar en el caso de aplicaciones sin estado, el
controlador de implementación no es la opción ideal en el caso de aplicaciones que requieran lo siguiente:
Una convención de nomenclatura o un almacenamiento persistentes
Una réplica en cada nodo seleccionado dentro de un clúster
Pero hay dos recursos de Kubernetes con los que puede administrar estos tipos de aplicaciones:
StatefulSets: mantienen el estado de las aplicaciones más allá del ciclo de vida de un determinado pod, como
el almacenamiento.
DaemonSets: garantizan la ejecución de una instancia en cada nodo en un fase inicial del proceso de
arranque de Kubernetes.
StatefulSets
El desarrollo de aplicaciones modernas suele tener como objetivo aplicaciones sin estado. En el caso de las
aplicaciones con estado, como las que incluyen componentes de base de datos, puede usar StatefulSets. Al igual
que las implementaciones, un StatefulSet crea y administra al menos un pod idéntico. Las réplicas de un
StatefulSet siguen un enfoque estable y secuencial de implementación, escalado, actualización y finalización.
Con un StatefulSet, la convención de nomenclatura, los nombres de red y el almacenamiento persisten como
réplicas que se vuelven a programar.
Defina la aplicación en formato YAML usando kind: StatefulSet . Después, el controlador del StatefulSet
controla la implementación y administración de las réplicas necesarias. Los datos se escriben en el
almacenamiento persistente, proporcionado por Azure Managed Disks o Azure Files. Con un StatefulSet, el
almacenamiento persistente subyacente permanece aunque se elimine el StatefulSet.
Para más información, consulte el objeto StatefulSets de Kubernetes.
Las réplicas de StatefulSet se programan y se ejecutan en cualquier nodo disponible en un clúster de AKS. Para
asegurarse de que al menos un pod del conjunto se ejecute en un nodo, use un DaemonSet en su lugar.
DaemonSets
Para recopilar o supervisar registros específicos, es posible que tenga que ejecutar un pod en todos los nodos o
en una selección de estos. Aunque un DaemonSet puede usarse para implementar uno o más pods idénticos, su
controlador garantiza que cada nodo especificado ejecute una instancia del pod.
El controlador de DaemonSet puede programar los pods en los nodos al principio del proceso de arranque del
clúster, antes de que se haya iniciado el programador de Kubernetes predeterminado. Esta capacidad garantiza
que los pods de DaemonSet se inicien antes de que se programen los pods tradicionales en una
implementación o StatefulSet.
Como StatefulSets, DaemonSet se define como parte de una definición de YAML mediante kind: DaemonSet .
Para más información, consulte el objeto DaemonSets de Kubernetes.
NOTE
Si usa el complemento de nodos virtuales, DaemonSets no creará los pods en el nodo virtual.
Espacios de nombres
Los recursos de Kubernetes, como pods e implementaciones, se agrupan de forma lógica en un espacio de
nombres, con el fin de dividir un clúster de AKS y restringir el acceso para crear, visualizar o administrar
recursos. Por ejemplo, puede crear espacios de nombres para separar grupos de negocios. Los usuarios solo
pueden interactuar con los recursos dentro de sus espacios de nombres asignados.
Cuando se crea un clúster de AKS, están disponibles los siguientes espacios de nombres:
ESPA C IO DE N O M B RES DESC RIP C IÓ N
default Espacio donde se crean los pods y las implementaciones de

forma predeterminada si no se proporciona ninguno. En
entornos más pequeños, puede implementar aplicaciones
directamente en el espacio de nombres predeterminado sin
crear separaciones lógicas adicionales. Al interactuar con la
API de Kubernetes, como con kubectl get pods , el
espacio de nombres predeterminado se utiliza cuando no se
especifica ninguno.
kube-system Espacio donde existen los recursos básicos, por ejemplo,

características de red como el DNS y el proxy, o bien el panel
de Kubernetes. Normalmente, el usuario no implementa sus
propias aplicaciones en este espacio de nombres.
kube-public Aunque no suele utilizarse, este espacio puede usarse para

que los recursos sean visibles en todo el clúster y para que
puedan verlos todos los usuarios.
Para más información, consulte los espacios de nombres de Kubernetes.
Pasos siguientes
En este artículo se tratan algunos de los componentes básicos de Kubernetes y cómo se aplican a los clústeres
de AKS. Para obtener más información sobre los conceptos básicos de Kubernetes y AKS, consulte los artículos
siguientes:
Acceso a Kubernetes/AKS e identidad
Seguridad de Kubernetes/AKS
Redes virtuales de Kubernetes/AKS
Almacenamiento de Kubernetes/AKS
Escala de Kubernetes/AKS
Opciones de acceso e identidad en Azure
Puede autenticar, autorizar, proteger y controlar el acceso a los clústeres de Kubernetes de varias maneras.
Mediante el control de acceso basado en rol de Kubernetes (RBAC de Kubernetes), puede conceder acceso a
usuarios, grupos y cuentas de servicio únicamente a los recursos que necesitan.
Con Azure Kubernetes Service (AKS), puede mejorar aún más la seguridad y la estructura de permisos
mediante el uso de Azure Active Directory y Azure RBAC.
AKS y RBAC de Kubernetes le ayudan a proteger el acceso al clúster y a proporcionar solo los permisos mínimos
necesarios a los desarrolladores y operadores.
En este artículo se presentan los conceptos básicos para ayudarle a autenticarse y a asignar permisos en AKS.
Permisos del servicio AKS

Al crear un clúster, AKS genera o modifica los recursos necesarios (por ejemplo, máquinas virtuales y NIC) para
crear y ejecutar el clúster en nombre del usuario. Esta identidad es distinta del permiso de identidad del clúster,
que se crea durante la construcción del clúster.
Identidad para crear y administrar los permisos de clúster
Los siguientes permisos son necesarios para la identidad que crea y administra el clúster.
P ERM ISO M OT IVO
Microsoft.Compute/diskEncryptionSets/read Se requiere para leer el identificador de conjunto de cifrado

de disco.
Microsoft.Compute/proximityPlacementGroups/write Necesario para actualizar los grupos con ubicación por

proximidad.
Microsoft.Network/applicationGateways/read Se requiere para configurar las puertas de enlace de

Microsoft.Network/applicationGateways/write aplicaciones y unirse a la subred.
Microsoft.Network/virtualNetworks/subnets/join/action
Microsoft.Network/virtualNetworks/subnets/join/action Se requiere para configurar el grupo de seguridad de red

para la subred cuando se usa una red virtual personalizada.
Microsoft.Network/publicIPAddresses/join/action Se requiere para configurar las direcciones IP públicas

Microsoft.Network/publicIPPrefixes/join/action salientes en el servicio Standard Load Balancer.
Microsoft.OperationalInsights/workspaces/sharedkeys/read Se requiere para crear y actualizar las áreas de trabajo de

Microsoft.OperationalInsights/workspaces/read Log Analytics y la supervisión de Azure para contenedores.
Microsoft.OperationsManagement/solutions/write
Microsoft.OperationsManagement/solutions/read
Microsoft.ManagedIdentity/userAssignedIdentities/assign/action
Permisos de identidad de clúster de AKS

Los siguientes permisos se usan en la identidad de clúster de AKS, que se crea y se asocia al clúster de AKS.
Cada permiso se usa por los motivos que se indican a continuación:
P ERM ISO M OT IVO
Microsoft.ContainerService/managedClusters/* Necesario para la creación de usuarios y el funcionamiento

del clúster
Microsoft.Network/loadBalancers/delete Se requiere para configurar el equilibrador de carga para un

Microsoft.Network/loadBalancers/read servicio LoadBalancer.
Microsoft.Network/loadBalancers/write
Microsoft.Network/publicIPAddresses/delete Se requiere para buscar y configurar direcciones IP públicas

Microsoft.Network/publicIPAddresses/read para un servicio LoadBalancer.
Microsoft.Network/publicIPAddresses/write
Microsoft.Network/publicIPAddresses/join/action Se requiere para configurar direcciones IP públicas para un

servicio LoadBalancer.
Microsoft.Network/networkSecurityGroups/read Se requiere para crear o eliminar reglas de seguridad para un

Microsoft.Network/networkSecurityGroups/write servicio LoadBalancer.
Microsoft.Compute/disks/delete Se requiere para configurar AzureDisks.

Microsoft.Compute/disks/read
Microsoft.Compute/disks/write
Microsoft.Compute/locations/DiskOperations/read
Microsoft.Storage/storageAccounts/delete Se requiere para configurar las cuentas de almacenamiento

Microsoft.Storage/storageAccounts/listKeys/action de AzureFile o AzureDisk.
Microsoft.Storage/storageAccounts/read
Microsoft.Storage/storageAccounts/write
Microsoft.Storage/operations/read
Microsoft.Network/routeTables/read Se requiere para configurar las tablas de ruta y las rutas para
Microsoft.Network/routeTables/routes/delete nodos.
Microsoft.Network/routeTables/routes/read
Microsoft.Network/routeTables/routes/write
Microsoft.Network/routeTables/write
Microsoft.Compute/virtualMachines/read Se requiere para encontrar información de las máquinas

virtuales en un clúster VMAS (por ejemplo, zonas, dominio
de error, tamaño y discos de datos).
Microsoft.Compute/virtualMachines/write Se requiere para asociar AzureDisks a una máquina virtual

en un clúster VMAS.
Microsoft.Compute/virtualMachineScaleSets/read Se requiere para encontrar información de máquinas

virtuales en un conjunto de escalado de máquinas virtuales
Microsoft.Compute/virtualMachineScaleSets/virtualMachines/read
(por ejemplo, zonas, dominio de error, tamaño y discos de
Microsoft.Compute/virtualMachineScaleSets/virtualmachines/instanceView/read
datos).
Microsoft.Network/networkInterfaces/write Se requiere para agregar una máquina virtual de un clúster

VMAS a un grupo de direcciones de back-end del
equilibrador de carga.
P ERM ISO M OT IVO
Microsoft.Compute/virtualMachineScaleSets/write Se requiere para agregar un conjunto de escalado de

máquinas virtuales a grupos de direcciones de back-end del
equilibrador de carga y a nodos de escalabilidad horizontal
en un conjunto de escalado de máquinas virtuales.
Se requiere para asociar AzureDisks y agregar una máquina

Microsoft.Compute/virtualMachineScaleSets/virtualmachines/write
virtual de un conjunto de escalado de máquinas virtuales al
Microsoft.Network/networkInterfaces/read Se requiere para buscar grupos de direcciones IP internas y

de direcciones de back-end del equilibrador de carga para las
máquinas virtuales de un clúster VMAS.
Se requiere para buscar grupos de direcciones IP internas y

Microsoft.Compute/virtualMachineScaleSets/virtualMachines/networkInterfaces/read
de back-end del equilibrador de carga para una máquina
virtual de un conjunto de escalado de máquinas virtuales.
Se requiere para buscar direcciones IP públicas para una

Microsoft.Compute/virtualMachineScaleSets/virtualMachines/networkInterfaces/ipconfigurations/publicipaddresses/read
máquina virtual de un conjunto de escalado de máquinas
virtuales.
Microsoft.Network/virtualNetworks/read Se requiere para comprobar si existe una subred para el

Microsoft.Network/virtualNetworks/subnets/read equilibrador de carga interno en otro grupo de recursos.
Microsoft.Compute/snapshots/delete Se requiere para configurar instantáneas de AzureDisk.

Microsoft.Compute/snapshots/read
Microsoft.Compute/snapshots/write
Microsoft.Compute/locations/vmSizes/read Se requiere para buscar tamaños de máquina virtual y

Microsoft.Compute/locations/operations/read encontrar límites de volumen de AzureDisk.
Permisos adicionales de identidad de clúster

Al crear un clúster con atributos específicos, necesitará los siguientes permisos adicionales para la identidad del
clúster. Dado que estos permisos no se asignan automáticamente, debe agregarlos a la identidad del clúster
después de su creación.
P ERM ISO M OT IVO
Microsoft.Network/networkSecurityGroups/write Se requiere cuando se usa un grupo de seguridad de red en

Microsoft.Network/networkSecurityGroups/read otro grupo de recursos. Se requiere para configurar reglas de
seguridad para un servicio LoadBalancer.
Microsoft.Network/virtualNetworks/subnets/read Se requiere cando se usa una subred en otro grupo de

Microsoft.Network/virtualNetworks/subnets/join/action recursos (por ejemplo, una red virtual personalizada).
Microsoft.Network/routeTables/routes/read Se requiere cuando se usa una subred asociada a una tabla

Microsoft.Network/routeTables/routes/write de rutas en otro grupo de recursos (por ejemplo, una red
virtual personalizada con una tabla de rutas personalizada).
Se requiere para comprobar si ya existe una subred para la
subred en el otro grupo de recursos.
P ERM ISO M OT IVO
Microsoft.Network/virtualNetworks/subnets/read Se requiere cuando se usa un equilibrador de carga interno

en otro grupo de recursos. Se requiere para comprobar si ya
existe una subred para el equilibrador de carga interno en el
grupo de recursos.
Microsoft.Network/privatednszones/* Se requiere cuando se usa una subred en otro grupo de

recursos (por ejemplo, una red privateDNSZone
personalizada).
RBAC de Kubernetes
RBAC de Kubernetes proporciona un filtrado detallado de las acciones del usuario. Con este mecanismo de
control:
Asigna a usuarios o grupos de usuarios permiso para crear o modificar recursos, o ver registros de cargas de
trabajo de aplicaciones en ejecución.
Puede limitar los permisos a un único espacio de nombres o a todo el clúster de AKS.
Crea roles para definir permisos y, después, asigna esos roles a usuarios mediante enlaces de rol.
Para obtener más información, consulte Uso de la autorización de RBAC de Kubernetes.
Roles y ClusterRoles
Roles
Antes de asignar permisos a los usuarios con RBAC de Kubernetes, definirá los permisos de usuario como un
rol. Conceda permisos dentro de un espacio de nombres mediante roles.
NOTE
Los roles de Kubernetes conceden permisos; no los deniegan.
Para conceder permisos en todo el clúster o a recursos de clúster fuera de un espacio de nombres determinado,
puede usar en su lugar ClusterRoles.
ClusterRoles
Un objeto ClusterRole concede y aplica permisos a los recursos de todo el clúster, no a un espacio de nombres
específico.
RoleBindings y ClusterRoleBindings
Tras definir los roles para conceder permisos a los recursos, asigne esos permisos de RBAC de Kubernetes con
un RoleBinding. Si el clúster de AKS se integra con Azure Active Directory (Azure AD), los RoleBindings conceden
permisos a los usuarios de Azure AD para que realicen acciones en el clúster. Consulte cómo se hace en
Administración del acceso a recursos de clúster mediante el control de acceso basado en roles de Kubernetes y
las identidades de Azure Active Directory.
RoleBindings
Asigne roles a los usuarios de un espacio de nombres determinado mediante RoleBindings. Con RoleBindings,
puede separar lógicamente un único clúster de AKS, de modo que solo se permita a los usuarios acceder a los
recursos de la aplicación en su espacio de nombres asignado.
Para enlazar roles en todo el clúster o para recursos de clúster fuera de un espacio de nombres determinado,
use en su lugar ClusterRoleBindings.
ClusterRoleBinding
Con un objeto ClusterRoleBinding, enlaza roles a usuarios y los aplica a los recursos de todo el clúster, no a un
espacio de nombres determinado. Este enfoque le permite conceder acceso para los administradores o
ingenieros de soporte técnico a todos los recursos del clúster de AKS.
NOTE
Microsoft/AKS realiza todas las acciones de clúster con el consentimiento del usuario en el rol de Kubernetes integrado
aks-service y el enlace de roles integrado aks-service-rolebinding .
Este rol permite a AKS solucionar problemas de clústeres, pero no puede modificar permisos ni crear roles, enlaces de
roles ni otras acciones de privilegios elevados. El acceso a roles solo se habilita en incidencias de soporte técnico activos
con acceso Just-in-Time (JIT). Obtenga más información sobre Directivas de soporte técnico de AKS.
Cuentas de servicio de Kubernetes

Las cuentas de servicio son uno de los tipos de usuario principales en Kubernetes. La API de Kubernetes
contiene y administra cuentas de servicio. Las credenciales de las cuentas de servicio se almacenan como
secretos de Kubernetes que pueden usar los pods autorizados para comunicarse con el servidor de API. La
mayoría de las solicitudes de API proporcionan un token de autenticación para una cuenta de servicio o una
cuenta de usuario normal.
Las cuentas de usuario normales permiten un acceso más tradicional para administradores o desarrolladores
humanos, no solo a servicios y procesos. Aunque Kubernetes no proporciona una solución de administración de
identidades para almacenar contraseñas y cuentas de usuario normales, puede integrar soluciones de
identidades externas en Kubernetes. Para los clústeres de AKS, esta solución de identidades integrada es
Azure AD.
Para más información sobre las opciones de identidad en Kubernetes, consulte la autenticación Kubernetes.
Integración de Azure AD
Mejore la seguridad del clúster de AKS con la integración de Azure AD. Con la experiencia de varias décadas de
administración de identidades empresariales, Azure AD es un servicio multiinquilino de administración de
identidades y de directorios basado en la nube que combina los servicios de directorio principales, la
administración del acceso de las aplicaciones y la protección de identidades. Con Azure AD, puede integrar
identidades locales en clústeres de AKS para proporcionar un único origen para la seguridad y administración
de cuentas.
Con los clústeres de AKS integrados en Azure AD, puede conceder a los usuarios o grupos acceso a los recursos
de Kubernetes de un espacio de nombres o del clúster.
1. Para obtener un contexto de configuración de kubectl , el usuario ejecuta el comando az aks get-credentials.
2. Cuando un usuario interactúa con el clúster de AKS con kubectl , se le pide que inicie sesión con sus
credenciales de Azure AD.
Este enfoque proporciona un único origen para la administración de cuentas de usuario y de las credenciales de
contraseña. El usuario solo puede acceder a los recursos como defina el administrador de clústeres.
La autenticación de Azure AD se proporciona a los clústeres de AKS con OpenID Connect. OpenID Connect es
una capa de identidad creada basándose en el protocolo OAuth 2.0. Puede encontrar más información sobre
OpenID Connect en la documentación de OpenID Connect. Dentro del clúster de Kubernetes, se usa la
autenticación de token de webhook para verificar los tokens de autenticación. La autenticación de token de
webhook se configura y administra como parte del clúster de AKS.
Webhook y servidor de API
Como se muestra en el gráfico anterior, el servidor de API llama al servidor de webhook de AKS y realiza los
pasos siguientes:
1. kubectl usa la aplicación cliente de Azure AD para el inicio de sesión de los usuarios con el flujo de
concesión de autorización de dispositivos OAuth 2.0.
2. Azure AD proporciona un access_token, id_token y un refresh_token.
3. El usuario realiza una solicitud a kubectl con un access_token de kubeconfig .
4. kubectl envía access_token al servidor de API.
5. El servidor de API se configura con el servidor de autenticación de Webhook para realizar la validación.
6. El servidor de autenticación de webhook confirma que la firma JSON Web Token es válida mediante la
comprobación de la clave de firma pública de Azure AD.
7. La aplicación del servidor usa credenciales proporcionadas por el usuario para consultar la pertenencia a
grupos del usuario que ha iniciado sesión desde la MS Graph API.
8. Se envía una respuesta al servidor de API con información del usuario, como la notificación del nombre
principal de usuario (UPN) del token de acceso y la pertenencia al grupo del usuario en función del
identificador de objeto.
9. La API realiza una decisión de autorización basada en el rol Kubernetes/RoleBinding.
10. Una vez autorizado, el servidor de API devuelve una respuesta a kubectl .
11. kubectl envía comentarios al usuario.
Obtenga información sobre cómo integrar AKS con Azure AD con nuestra guía paso a paso de integración de
Azure AD administrada por AKS.
Control de acceso basado en roles de Azure
El control de acceso basado en rol (RBAC) de Azure es un sistema de autorización basado en Azure Resource
Manager que proporciona administración de acceso específico a los recursos de Azure.
SIST EM A RB A C DESC RIP C IÓ N
RBAC de Kubernetes Diseñado para funcionar en recursos de Kubernetes dentro

del clúster de AKS.
Azure RBAC Diseñado para funcionar en recursos dentro de la suscripción

de Azure.
Con el control de acceso basado en rol de Azure, puede crear una definición de rol que describe los permisos
que se aplicarán. A continuación, asigne esta definición de rol a un usuario o grupo mediante una asignación de
roles para un ámbito determinado. El ámbito puede ser un recurso individual, un grupo de recursos o toda la
suscripción.
Para obtener más información, consulte ¿Qué es el control de acceso basado en roles (RBAC) de Azure?
Hay dos niveles de acceso necesarios para operar completamente un clúster de AKS:
Acceso al recurso de AKS en la suscripción de Azure
Controle el escalado o la actualización del clúster mediante las API de AKS.
Extraiga kubeconfig .
Acceso al API de Kubernetes. Este acceso se controla mediante:
RBAC de Kubernetes (tradicionalmente).
Integración de RBAC de Azure con AKS para la autorización de Kubernetes.
Azure RBAC para autorizar el acceso al recurso de AKS
Con Azure RBAC, puede proporcionar a los usuarios (o identidades) acceso granular a los recursos de AKS en
una o varias suscripciones. Por ejemplo, puede usar el rol de colaborador de Azure Kubernetes Service para
escalar y actualizar el clúster. Mientras, otro usuario con el rol de administrador de clúster de Azure Kubernetes
Service solo tiene permiso para extraer el kubeconfig de administración.
Como alternativa, puede dar a su usuario el rol de colaborador general. Con el rol de colaborador general, los
usuarios tienen los permisos anteriores y pueden realizar todas las acciones posibles en el recurso de AKS,
excepto la administración de permisos.
Use Azure RBAC para definir el acceso al archivo de configuración de Kubernetes en AKS.
Azure RBAC para la autorización de Kubernetes (versión preliminar)
Con la integración de Azure RBAC, AKS utilizará un servidor de webhooks de autorización de Kubernetes, lo que
le permitirá administrar los permisos y asignaciones de los recursos del clúster de Kubernetes integrados en
Azure AD utilizando la definición y la asignación de roles de Azure.
Como se muestra en el diagrama anterior, al usar la integración de Azure RBAC, todas las solicitudes a la API de
Kubernetes seguirán el mismo flujo de autenticación que se explica en la sección de integración de Azure Active
Directory.
Si la identidad que realiza la solicitud existe en Azure AD, Azure colaborará con RBAC de Kubernetes para
autorizar la solicitud. Si la identidad existe fuera de Azure AD (es decir, una cuenta de servicio de Kubernetes), la
autorización usará al RBAC de Kubernetes normal.
En este escenario, usará mecanismos y API de RBAC de Azure para asignar roles integrados a los usuarios o
crear roles personalizados, tal como lo haría con los roles de Kubernetes.
Con esta característica, no solo concede permisos a los usuarios para el recurso de AKS entre suscripciones, sino
que también configura el rol y los permisos dentro de cada uno de esos clústeres que controlan el acceso a la
API de Kubernetes. Por ejemplo, puede conceder el rol Azure Kubernetes Service RBAC Viewer en el ámbito de la
suscripción. El destinatario del rol podrá enumerar y obtener todos los objetos de Kubernetes de todos los
clústeres sin modificarlos.
IMPORTANT
Debe habilitar Azure RBAC para la autorización de Kubernetes antes de usar esta característica. Para obtener información
detallada e instrucciones paso a paso, siga nuestra guía paso a paso Uso de Azure RBAC para la autorización de
Kubernetes.
Roles integrados
AKS proporciona los siguientes cuatro roles integrados. Son similares a los roles integrados de Kubernetes con
algunas diferencias, como la compatibilidad con CRDs. Consulte la lista completa de acciones permitidas por
cada rol integrado de Azure.
RO L E DESC RIP C IÓ N
Visor de Azure Kubernetes Service RBAC Permite el acceso de solo lectura para ver la mayoría de los
objetos en un espacio de nombres.
No permite la visualización de roles o enlaces de roles.
No permite la visualización de Secrets . Leer el contenido
de Secrets permite el acceso a las credenciales de
ServiceAccount en el espacio de nombres, lo que
permitiría el acceso a la API como cualquier
ServiceAccount en el espacio de nombres (una forma de
elevación de privilegios).
Escritor de Azure Kubernetes Service RBAC Permite el acceso de lectura y escritura para ver la mayoría
de los objetos en un espacio de nombres.
No permite la visualización o modificación de roles o enlaces
de roles.
Permite acceder a Secrets y ejecutar pods como cualquier
ServiceAccount en el espacio de nombres, por lo que se
puede usar para obtener los niveles de acceso de la API de
cualquier ServiceAccount en el espacio de nombres.
Administrador de Azure Kubernetes Service RBAC Permite el acceso de administrador, diseñado para su
concesión dentro de un espacio de nombres.
Permite el acceso de lectura y escritura a la mayoría de los
recursos de un espacio de nombres (o ámbito de clúster),
incluida la capacidad de crear roles y enlaces de roles dentro
del espacio de nombres.
No permite el acceso de escritura a la cuota de recursos o al
espacio de nombres en sí.
Administrador de clúster de Azure Kubernetes Service RBAC Permite el acceso de superusuario para realizar cualquier
acción en cualquier recurso.
Proporciona control total sobre todos los recursos del clúster
y en todos los espacios de nombres.
Resumen
Vea en la tabla un resumen rápido de cómo los usuarios pueden autenticarse en Kubernetes cuando la
integración de Azure AD está habilitada. En todos los casos, la secuencia de comandos del usuario es:
1. Ejecute az login para autenticarse en Azure.
2. Ejecute az aks get-credentials para descargar las credenciales del clúster en .kube/config .
3. Ejecute comandos kubectl .
El primer comando puede desencadenar la autenticación basada en explorador para autenticarse en el
clúster, tal y como se describe en la tabla siguiente.
En Azure Portal, puede encontrar lo siguiente:
La concesión de roles (concesión de roles de Azure RBAC) a la que se hace referencia en la segunda columna
se muestra en la pestaña Control de acceso .
El grupo de Azure AD de administración del clúster se muestra en la pestaña Configuración .
También se encuentra con el nombre de parámetro --aad-admin-group-object-ids en la CLI de Azure.
GRUP O S DE
C O N C ESIÓ N DE RO L A DM IN IST RA C IÓ N DE
DESC RIP C IÓ N REQ UERIDA C L ÚST ERES DE A Z URE A D C UÁ N DO SE USA
GRUP O S DE
Inicio de sesión de Rol de administrador de N/D Si está bloqueado de forma

administrador heredado Azure Kubernetes . Este permanente porque no
con certificado de cliente rol permite usar tiene acceso a un grupo
az aks get-credentials válido de Azure AD con
con la marca --admin , que acceso al clúster.
descarga un certificado de
administrador de clústeres
heredado (no de Azure AD)
en .kube/config del
usuario. Este es el único
propósito del "rol de
administrador de Azure
Kubernetes".
Azure AD con Rol de usuario de Azure El usuario no se encuentra Si desea tener un control de
(Cluster)RoleBindings Kubernetes . El rol en ninguno de estos acceso específico y no usa
manual "Usuario" permite usar grupos. Dado que el RBAC de Azure para la
az aks get-credentials usuario no está en ningún autorización de Kubernetes.
sin la marca --admin . grupo de administración de Tenga en cuenta que el
(Este es el único propósito clústeres, cualquier usuario que configura los
del "rol de usuario de Azure RoleBindings o enlaces debe iniciar sesión
Kubernetes"). El resultado, ClusterRoleBindings con uno de los otros
en un clúster habilitado configurado por los métodos enumerados en
para Azure AD, es la administradores de esta tabla.
descarga de una entrada clústeres controlarán por
vacía en .kube/config , completo sus derechos.
que desencadena la (Cluster)RoleBindings
autenticación basada en designa los usuarios de
explorador cuando se usa Azure AD o los grupos de
por primera vez en Azure AD como sus
kubectl . subjects . Si no se ha
configurado ningún enlace
de este tipo, el usuario no
podrá ejecutar ningún
comando kubectl .
Azure AD por miembro de Lo mismo que antes. El usuario es miembro de Si desea conceder de forma
grupo de administración uno de los grupos que se práctica a los usuarios
indican aquí. AKS genera derechos de administrador
automáticamente un completos y no usan RBAC
elemento de Azure para la
ClusterRoleBinding que autorización de Kubernetes.
enlaza todos los grupos
indicados al rol
cluster-admin de
Kubernetes. De este modo,
los usuarios de estos
grupos pueden ejecutar
todos los comandos
kubectl como
cluster-admin .
GRUP O S DE
Azure AD con RBAC de Dos roles: El campo de roles de Usa RBAC de Azure para la
Azure para la autorización En primer lugar, el rol de administrador de la pestaña autorización de Kubernetes.
de Kubernetes usuario de Azure Configuración es irrelevante Este enfoque proporciona
Kubernetes . cuando está habilitada la un control específico, sin
En segundo lugar, uno de autorización de RBAC de necesidad de configurar
los roles RBAC de "Azure Azure para Kubernetes. RoleBindings o
Kubernetes Service" ClusterRoleBindings.
indicados anteriormente, o
su propia alternativa
personalizada.
Pasos siguientes
Para empezar a trabajar con Azure AD y el RBAC de Kubernetes, consulte Integración de Azure Active
Directory con AKS.
Para conocer los procedimientos recomendados asociados, consulte Procedimientos recomendados para la
autenticación y la autorización en AKS.
Para empezar a trabajar con Azure RBAC para la autorización de Kubernetes, consulte usar Azure RBAC para
autorizar el acceso en el clúster de Azure Kubernetes Service (AKS).
Para empezar a proteger el archivo kubeconfig , consulte Limitación del acceso al archivo de configuración
de clúster.
Para obtener más información sobre los conceptos básicos de Kubernetes y AKS, consulte los artículos
siguientes:
Clústeres y cargas de trabajo de Kubernetes/AKS
Conceptos de seguridad de las aplicaciones y los
clústeres en Azure Kubernetes Service (AKS)
La seguridad del clúster protege los datos de los clientes a medida que ejecuta cargas de trabajo de aplicaciones
Kubernetes incluye componentes de seguridad, tales como directivas de red y secretos. Mientras tanto, Azure
incluye componentes como grupos de seguridad de red y actualizaciones de clústeres orquestadas. AKS
combina estos componentes de seguridad para:
Hacer que el clúster de AKS ejecute las últimas actualizaciones de seguridad del sistema operativo y
versiones de Kubernetes.
Proporcionar tráfico de pod seguro y acceso a credenciales confidenciales.
En este artículo se presentan los conceptos básicos para proteger sus aplicaciones en AKS:
Conceptos de seguridad de las aplicaciones y los clústeres en Azure Kubernetes Service (AKS)
Seguridad de componentes maestros
Seguridad de nodos
Aislamiento de proceso
Actualización de un clúster de Service Fabric
Acordonamiento y purga
Seguridad de las redes
Grupos de seguridad de red de Azure
Secretos de Kubernetes
Pasos siguientes
Seguridad de componentes maestros

En AKS, los componentes maestros de Kubernetes forman parte del servicio administrado, proporcionado y
mantenido por Microsoft. Cada clúster de AKS tiene su propio maestro de Kubernetes dedicado con un solo
inquilino para proporcionar el servidor de API, Scheduler, etc.
De forma predeterminada, el servidor de API de Kubernetes utiliza una dirección IP pública y un nombre de
dominio completo (FQDN). Puede limitar el acceso al punto de conexión del servidor de API mediante los
intervalos IP autorizados. También puede crear un clúster privado por completo para limitar el acceso del
servidor de la API a la red virtual.
Puede regular el acceso al servidor de API mediante control de acceso basado en rol de Kubernetes (RBAC de
Kubernetes) y RBAC de Azure. Para más información, consulte el artículo de integración de Azure AD con AKS.
Seguridad de nodos
Los nodos de AKS son máquinas virtuales (VM) de Azure que el usuario administra y mantiene.
Los nodos de Linux ejecutan una distribución Ubuntu optimizada con containerd o el entorno de ejecución
del contenedor de Moby.
Los nodos de Windows Server ejecutan una versión de Windows Server 2019 optimizada con containerd o
el entorno de ejecución del contenedor de Moby.
Cuando se crea o se escala verticalmente un clúster de AKS, los nodos se implementan automáticamente con las
actualizaciones de seguridad del sistema operativo y las configuraciones más recientes.
NOTE
Clústeres de AKS que usan:
Grupos de nodos con la versión 1.19 de Kubernetes y posterior usan containerd como entorno de ejecución del
contenedor.
Grupos de nodos con versiones anteriores a la 1.19 de Kubernetes usan Moby (Docker ascendente) como entorno de
ejecución del contenedor.
Parches de seguridad de nodo

Nodos de Linux
La plataforma Azure aplica automáticamente las revisiones de seguridad del sistema operativo a los nodos de
Linux del clúster durante la noche. Si una actualización de seguridad del sistema operativo de Linux requiere un
reinicio del host, no se realizará automáticamente. Puede:
Reiniciar manualmente los nodos de Linux.
Usar Kured, un demonio de reinicio de código abierto para Kubernetes. Kured se ejecuta como un elemento
DaemonSet y supervisa en todos los nodos un archivo que indique que hace falta un reinicio.
Los reinicios se administran en el clúster con el mismo proceso de acordonar y purgar que una actualización de
clúster.
Nodos de Windows Server
Para los nodos de Windows Server, Windows Update no ejecuta ni aplica las actualizaciones más recientes de
manera automática. Programe las actualizaciones del grupo de nodos de Windows Server en el clúster de AKS
según el ciclo de Windows Update normal y su propio proceso de validación. Este proceso de actualización crea
nodos que ejecutan la imagen y las revisiones más recientes de Windows Server y elimina los nodos anteriores.
Para obtener más información sobre este proceso, consulte Actualización de un grupo de nodos en AKS.
Implementación de nodo
Los nodos se implementan en una subred de una red privada virtual, sin ninguna dirección IP pública asignada.
Con fines de solución de problemas y administración, SSH está habilitado de manera predeterminada y solo es
accesible mediante la dirección IP interna.
Almacenamiento del nodo
Para proporcionar almacenamiento, los nodos usan Azure Managed Disks. Para la mayoría de los tamaños de
nodo de máquina virtual, las instancias de Azure Managed Disks son discos Premium respaldados por SSD de
alto rendimiento. Los datos almacenados en discos administrados se cifran automáticamente en reposo dentro
de la plataforma Azure. Para mejorar la redundancia, las instancias de Azure Managed Disks se replican de
forma segura en el centro de datos de Azure.
Cargas de trabajo multiinquilino hostiles
Actualmente, los entornos de Kubernetes no están completamente seguros ante el uso de varios inquilinos
hostiles. Las características de seguridad adicionales, como las directivas de seguridad de pods o Kubernetes
RBAC para nodos, bloquean eficazmente las vulnerabilidades de seguridad. Para una verdadera seguridad al
ejecutar cargas de trabajo multiinquilino hostiles, solo debe confiar en un hipervisor. El dominio de seguridad de
Kubernetes se convierte en todo el clúster, no en un nodo específico.
En el caso de estos tipos de cargas de trabajo multiinquilino hostiles, debe usar clústeres que estén físicamente
aislados. Para obtener más información sobre las formas de aislar las cargas de trabajo, consulte
Procedimientos recomendados para el aislamiento de clústeres en AKS.
Aislamiento de proceso
Debido a los requisitos normativos o de cumplimiento, ciertas cargas de trabajo pueden requerir un alto grado
de aislamiento de otras cargas de trabajo del cliente. Para estas cargas de trabajo, Azure proporciona VM
aisladas para usarse como nodos de agente en un clúster de AKS. Estas VM están aisladas en un tipo de
hardware específico y están dedicadas a un solo cliente.
Seleccione uno de los tamaños de VM aisladas como tamaño de nodo al crear un clúster de AKS o agregar un
grupo de nodos.
Actualizaciones de clústeres
Azure proporciona herramientas de orquestación de actualizaciones para actualizar un clúster de AKS y sus
componentes, mantener la seguridad y el cumplimiento y acceder a las características más recientes. La
orquestación de esta actualización incluye los componentes tanto de maestro como de agente de Kubernetes.
Para iniciar el proceso de actualización, especifique una de las versiones de Kubernetes disponibles de la lista. A
continuación, Azure acordona y purga de manera segura cada uno de los nodos de AKS y los actualiza.
Acordonar y purgar
Durante el proceso de actualización, los nodos de AKS se acordonan de manera individual desde el clúster para
evitar que se programen nuevos pods en ellos. A continuación, los nodos se purgan y actualizan de la siguiente
manera:
1. Se implementa un nuevo nodo en el grupo de nodos.
Este nodo ejecuta la imagen de sistema operativo y las revisiones más recientes.
2. Se identifica uno de los nodos existentes para la actualización.
3. Los pods del nodo identificado finalizan correctamente y se programan en los otros nodos del grupo.
4. El nodo vacío se elimina del clúster de AKS.
5. Los pasos del 1 al 4 se repiten hasta que todos los nodos se reemplazan correctamente como parte del
proceso de actualización.
Para más información, consulte Actualización de un clúster de Azure Kubernetes Service (AKS).
Seguridad de las redes

Por motivos de conectividad y seguridad con las redes locales, puede implementar el clúster de AKS en subredes
de red virtual de Azure existentes. Estas redes virtuales se conectan de vuelta a su red local con una VPN de sitio
a sitio o ExpressRoute de Azure. Defina controladores de entrada de Kubernetes con direcciones IP privadas
internas para limitar el acceso de los servicios a la conexión de red interna.
Grupos de seguridad de red de Azure
Para filtrar el flujo del tráfico de red virtual, Azure usa reglas de grupo de seguridad de red. Estas reglas definen
los intervalos, los puertos y los protocolos de IP de origen y destino que tienen permitido o denegado el acceso
a los recursos. Se crean reglas predeterminadas para permitir el tráfico TLS al servidor de API de Kubernetes.
Los servicios se crean con equilibradores de carga, asignaciones de puertos o rutas de entrada. AKS modifica
automáticamente el grupo de seguridad de red para el flujo de tráfico.
Si proporciona su propia subred para el clúster de AKS, no modifique el grupo de seguridad de red del nivel de
subred que administra AKS. En su lugar, cree más grupos de seguridad de red de nivel de subred para modificar
el flujo de tráfico. Asegúrese de que no interfieran con el tráfico necesario para administrar el clúster, como el
acceso al equilibrador de carga, la comunicación con el plano de control y la salida.
Directiva de red de Kubernetes
Para limitar el tráfico de red entre los pods del clúster, AKS ofrece compatibilidad con las directivas de red de
Kubernetes. Con las directivas de red, puede permitir o denegar las rutas de acceso de red específicas en el
clúster en función de los espacios de nombres y los selectores de etiquetas.
Secretos de Kubernetes
Con un secreto de Kubernetes, puede insertar datos confidenciales en pods, como credenciales de acceso o
claves.
1. Cree un secreto mediante la API de Kubernetes.
2. Defina el pod o la implementación y solicite un secreto específico.
Los secretos solo se proporcionan a los nodos que tienen un pod programado que los requiere.
El secreto se almacena en tmpfs, no se escribe en el disco.
3. Cuando se elimina el último pod de un nodo que requiere un secreto, dicho secreto se elimina del tmpfs del
nodo.
Los secretos se almacenan en un espacio de nombres determinado y solo son accesibles para los pods
del mismo espacio de nombres.
El uso de secretos reduce la información confidencial definida en el pod o el manifiesto YAML del servicio. En su
lugar, solicite el secreto almacenado en el servidor de API de Kubernetes como parte de su manifiesto YAML.
Este enfoque proporciona acceso al secreto solo al pod específico.
NOTE
Los archivos de manifiesto de secreto sin formato contienen los datos secretos en formato base64 (consulte la
documentación oficial para más detalles). Trate estos archivos como información confidencial y no los confirme nunca en el
control de código fuente.
Los secretos de Kubernetes se almacenan en etcd, un almacén distribuido de pares clave-valor. El almacén etcd
está totalmente administrado por AKS y los datos se cifran en reposo dentro de la plataforma de Azure.
Pasos siguientes
Para empezar a proteger los clústeres de AKS, consulte Actualización de un clúster de Azure Kubernetes Service
(AKS).
Para los procedimientos recomendados asociados, consulte Procedimientos recomendados para la seguridad de
clústeres y las actualizaciones en AKS y Procedimientos recomendados para la seguridad de pod en AKS.
Para obtener más información sobre los conceptos básicos de Kubernetes y AKS, consulte:
Identidad de Kubernetes/AKS
Controles de cumplimiento normativo de Azure
Policy para Azure Kubernetes Service (AKS)
El cumplimiento normativo de Azure Policy proporciona definiciones de iniciativas (integradas) creadas y

administradas por Microsoft para los dominios de cumplimiento y los controles de seguridad relacionados con
diferentes estándares de cumplimiento. En esta página se enumeran los dominios de cumplimiento y los
controles de seguridad de Azure Kubernetes Service (AKS).
Para que los recursos de Azure sean compatibles con el estándar específico, puede asignar las integraciones a
un control de seguridad de manera individual.
El título de cada definición de directiva integrada se vincula a la definición de directiva en Azure Portal. Use el
vínculo de la columna Versión de directiva para ver el origen en el repositorio de GitHub de Azure Policy.
IMPORTANT
Cada control que se muestra a continuación está asociado a una o varias definiciones de Azure Policy. Estas directivas
pueden ayudarle a evaluar el cumplimiento mediante el control. Sin embargo, con frecuencia no hay una correspondencia
completa o exacta entre un control y una o varias directivas. Como tal, el cumplimiento con Azure Policy solo se refiere a
las propias directivas; esto no garantiza que sea totalmente compatible con todos los requisitos de un control. Además, el
estándar de cumplimiento incluye controles que no se abordan con las definiciones de Azure Policy en este momento. Por
lo tanto, el cumplimiento en Azure Policy es solo una vista parcial del estado general de cumplimiento. Las asociaciones
entre los controles y las definiciones de cumplimiento normativo de Azure Policy para estos estándares de cumplimiento
pueden cambiar con el tiempo.
Prueba comparativa de la seguridad de Azure

Azure Security Benchmark proporciona recomendaciones sobre cómo puede proteger sus soluciones de nube
en Azure. Para ver cómo este servicio se asigna por completo a Azure Security Benchmark, consulte los archivos
de asignación de Az Security Benchmark.
Para revisar el modo en que las integraciones de Azure Policy disponibles para todos los servicios de Azure se
asignan a este estándar de cumplimiento, consulte Cumplimiento normativo de Azure Policy: Azure Security
Benchmark.
VERSIÓ N DE L A
DIREC T IVA DIREC T IVA
DO M A IN ID. DE C O N T RO L T ÍT ULO DE C O N T RO L ( A ZURE PO RTA L) ( GIT HUB)
Seguridad de redes NS-1 implementación de la Los intervalos IP 2.0.1

seguridad para el autorizados deben
tráfico interno definirse en los
servicios de
Kubernetes
Seguridad de redes NS-4 protección de las Los intervalos IP 2.0.1

aplicaciones y autorizados deben
servicios de ataques definirse en los
de redes externas servicios de
Kubernetes
VERSIÓ N DE L A
DO M A IN ID. DE C O N T RO L T ÍT ULO DE C O N T RO L
Acceso con PA-7 Seguimiento de solo Se debe usar el 1.0.2

privilegios una administración control de acceso
suficiente (principio basado en rol (RBAC)
de privilegios en los servicios de
mínimos) Kubernetes
Protección de datos DP-4 Cifrado de la Los clústeres de 6.0.0

información Kubernetes solo
confidencial en deben ser accesibles
tránsito mediante HTTPS
administración de PV-2 sostenimiento de El complemento 1.0.2

posturas y configuraciones Azure Policy para
vulnerabilidades seguras para Kubernetes Service
servicios de Azure (AKS) debería estar
instalado y habilitado
en sus clústeres
administración de PV-2 sostenimiento de Asegurarse de que 6.0.0

posturas y configuraciones los límites de los
vulnerabilidades seguras para recursos de memoria
servicios de Azure y CPU del
contenedor no
superan los límites
especificados en el
clúster de Kubernetes
administración de PV-2 sostenimiento de Los contenedores del 3.0.0

posturas y configuraciones clúster de Kubernetes
vulnerabilidades seguras para no deben compartir
servicios de Azure el identificador de
proceso del host ni el
espacio de nombres
IPC del host

posturas y configuraciones los contenedores
vulnerabilidades seguras para solo escuchan en los
servicios de Azure puertos permitidos
en el clúster de
Kubernetes
administración de PV-2 sostenimiento de Los contenedores de 3.0.0

vulnerabilidades seguras para solo deben usar
servicios de Azure perfiles de AppArmor
permitidos
administración de PV-2 sostenimiento de Los contenedores de 3.0.0

vulnerabilidades seguras para solo deben usar
servicios de Azure funcionalidades
permitidas
VERSIÓ N DE L A

posturas y configuraciones solo se admiten las
vulnerabilidades seguras para imágenes de
servicios de Azure contenedor
permitidas en el
administración de PV-2 sostenimiento de Los contenedores del 3.0.0

vulnerabilidades seguras para deben ejecutarse con
servicios de Azure un sistema de
archivos raíz de solo
lectura
administración de PV-2 sostenimiento de Los volúmenes 3.0.0

posturas y configuraciones hostPath del pod del
vulnerabilidades seguras para clúster de Kubernetes
servicios de Azure solo deben usar rutas
de host permitidas
administración de PV-2 sostenimiento de Los contenedores y 3.0.0

posturas y configuraciones pods de clúster de
vulnerabilidades seguras para Kubernetes solo
servicios de Azure deben ejecutarse con
identificadores de
usuario y grupo
aprobados
administración de PV-2 sostenimiento de Los pods del clúster 3.0.0

posturas y configuraciones de Kubernetes solo
vulnerabilidades seguras para pueden usar redes de
servicios de Azure host e intervalos de
puerto permitidos

posturas y configuraciones los servicios solo
vulnerabilidades seguras para escuchan en los
servicios de Azure puertos permitidos
en el clúster de
Kubernetes
administración de PV-2 sostenimiento de No permitir 6.0.0

posturas y configuraciones contenedores con
vulnerabilidades seguras para privilegios en el
servicios de Azure clúster de Kubernetes
administración de PV-2 sostenimiento de Los clústeres de 3.0.0

posturas y configuraciones Kubernetes no deben
vulnerabilidades seguras para permitir la elevación
servicios de Azure de privilegios del
contenedor
Azure Security Benchmark v1

Azure Security Benchmark proporciona recomendaciones sobre cómo puede proteger sus soluciones de nube
en Azure. Para ver cómo este servicio se asigna por completo a Azure Security Benchmark, consulte los archivos
de asignación de Az Security Benchmark.
asignan a este estándar de cumplimiento, consulte Cumplimiento normativo de Azure Policy: Azure Security
Benchmark.
VERSIÓ N DE L A
Seguridad de redes 1.1 Proteja los recursos Los intervalos IP 2.0.1

mediante grupos de autorizados deben
seguridad de red o definirse en los
Azure Firewall en su servicios de
red virtual Kubernetes
Protección de datos 4.6 Uso de RBAC de Se debe usar el 1.0.2

Azure para controlar control de acceso
el acceso a los basado en rol (RBAC)
recursos en los servicios de
Kubernetes
Administración de 5.3 Implemente una Kubernetes Services 1.0.2

vulnerabilidades solución se debe actualizar a
automatizada de una versión de
administración de Kubernetes no
revisiones de vulnerable
software de terceros
CIS Microsoft Azure Foundations Benchmark 1.1.0

corresponden a este estándar de cumplimiento, consulte Cumplimiento normativo de Azure Policy: CIS
Microsoft Azure Foundations Benchmark 1.1.0. Para más información sobre este estándar de cumplimiento,
consulte CIS Microsoft Azure Foundations Benchmark.
VERSIÓ N DE L A
Otras 8.5 Habilite el control de Se debe usar el 1.0.2

consideraciones de acceso basado en rol control de acceso
seguridad (RBAC) en Azure basado en rol (RBAC)
Kubernetes Services. en los servicios de
Kubernetes
CIS Microsoft Azure Foundations Benchmark 1.3.0

Para consultar la correspondencia que existe entre las integraciones de Azure Policy disponibles para todos los
servicios de Azure y este estándar de cumplimiento, consulte este artículo sobre el cumplimiento normativo de
Azure Policy: CIS Microsoft Azure Foundations Benchmark 1.3.0. Para más información sobre este estándar de
cumplimiento, consulte CIS Microsoft Azure Foundations Benchmark.
VERSIÓ N DE L A
Otras 8.5 Habilite el control de Se debe usar el 1.0.2

consideraciones de acceso basado en rol control de acceso
seguridad (RBAC) en Azure basado en rol (RBAC)
Kubernetes Services. en los servicios de
Kubernetes
CMMC nivel 3
Para ver cómo se corresponden las integraciones de Azure Policy disponibles para todos los mapas de servicio
de Azure con este estándar de cumplimiento, consulte Detalles de la iniciativa integrada de cumplimiento
normativo CMMC nivel 3. Para más información sobre este estándar de cumplimiento, consulte Certificación del
modelo de madurez de ciberseguridad (CMMC).
VERSIÓ N DE L A
Control de acceso AC.1.001 Limita el acceso del Los pods del clúster 3.0.0
sistema de de Kubernetes solo
información a los pueden usar redes de
usuarios autorizados, host e intervalos de
a los procesos que puerto permitidos
actúan en nombre de
los usuarios
autorizados y a los
dispositivos (incluidos
otros sistemas de
información).
Control de acceso AC.1.001 Limita el acceso del Se debe usar el 1.0.2

sistema de control de acceso
información a los basado en rol (RBAC)
usuarios autorizados, en los servicios de
a los procesos que Kubernetes
actúan en nombre de
los usuarios
autorizados y a los
dispositivos (incluidos
otros sistemas de
información).
Control de acceso AC.1.002 Limita el acceso del Los pods del clúster 3.0.0
sistema de de Kubernetes solo
información a los pueden usar redes de
tipos de host e intervalos de
transacciones y puerto permitidos
funciones que los
usuarios autorizados
pueden ejecutar.
VERSIÓ N DE L A
Control de acceso AC.1.002 Limita el acceso del Se debe usar el 1.0.2

sistema de control de acceso
información a los basado en rol (RBAC)
tipos de en los servicios de
transacciones y Kubernetes
funciones que los
usuarios autorizados
pueden ejecutar.
Control de acceso AC.2.007 Utiliza el principio de Se debe usar el 1.0.2

privilegios mínimos, control de acceso
incluidas las cuentas basado en rol (RBAC)
con privilegios y en los servicios de
funciones de Kubernetes
seguridad específicas.
Control de acceso AC.2.016 Controla el flujo de Se debe usar el 1.0.2

CUI de acuerdo con control de acceso
las autorizaciones basado en rol (RBAC)
aprobadas. en los servicios de
Kubernetes
Administración de la CM.2.062 Utiliza el principio de Se debe usar el 1.0.2

configuración funcionalidad mínima control de acceso
y configura los basado en rol (RBAC)
sistemas de la en los servicios de
organización para Kubernetes
proporcionar
únicamente las
funcionalidades
esenciales.
Administración de la CM.3.068 Restringe, deshabilita Los pods del clúster 3.0.0

configuración o impide el uso de de Kubernetes solo
programas, pueden usar redes de
funciones, puertos, host e intervalos de
protocolos y servicios puerto permitidos
no esenciales.
Evaluación de riesgos RM.2.143 Corrige las Kubernetes Services 1.0.2

vulnerabilidades con se debe actualizar a
arreglo a las una versión de
evaluaciones de Kubernetes no
riesgos. vulnerable
Protección del SC.1.175 Supervisa, controla y Los pods del clúster 3.0.0
sistema y de las protege las de Kubernetes solo
comunicaciones comunicaciones (es pueden usar redes de
decir, la información host e intervalos de
transmitida o recibida puerto permitidos
por los sistemas de la
organización) en los
límites externos y los
límites internos clave
de los sistemas de la
organización.
VERSIÓ N DE L A
Protección del SC.3.177 Emplea criptografía Los sistemas 1.0.0

sistema y de las validada mediante operativos y los
comunicaciones FIPS cuando se usa discos de datos de
para proteger la los clústeres de Azure
confidencialidad de Kubernetes Service
CUI. deben cifrarse
mediante claves
administradas por el
cliente
Protección del SC.3.183 Deniega el tráfico de Los pods del clúster 3.0.0
sistema y de las las comunicaciones de Kubernetes solo
comunicaciones de red de forma pueden usar redes de
predeterminada y host e intervalos de
solo permite el tráfico puerto permitidos
de las
comunicaciones de
red de forma
excepcional (es decir,
deniega todo el
tráfico y permite las
excepciones).
Integridad del SI.1.210 Identifica, notifica y Kubernetes Services 1.0.2

sistema y de la corrige la información se debe actualizar a
información y los errores del una versión de
sistema de Kubernetes no
información en el vulnerable
momento oportuno.
HIPAA/HITRUST 9.2
Con el fin de revisar el modo en que las integraciones de Azure Policy disponibles para los servicios de Azure
siguen este estándar de cumplimiento, consulte Cumplimiento normativo de Azure Policy: HIPAA/HITRUST 9.2.
Para más información acerca de este estándar de cumplimiento, consulte HIPAA/HITRUST 9.2.
VERSIÓ N DE L A
VERSIÓ N DE L A
Administración de 1149.01c2System.9 - Con el fin de facilitar Se debe usar el 1.0.2

privilegios 01.c el uso compartido de control de acceso
la información, la basado en rol (RBAC)
organización permite en los servicios de
que los usuarios Kubernetes
autorizados
determinen el acceso
de un asociado
comercial según unos
criterios definidos y el
empleo de procesos
manuales o
mecanismos
automatizados para
ayudar a los usuarios
a tomar decisiones
de colaboración y
uso compartido de la
información.
Administración de 1153.01c3System.35 Todo acceso al Se debe usar el 1.0.2

privilegios - 01.c sistema de archivos control de acceso
que no sea basado en rol (RBAC)
claramente necesario en los servicios de
se deshabilita, y tan Kubernetes
solo los usuarios
autorizados podrán
acceder a los
recursos
específicamente
necesarios para el
desempeño de sus
obligaciones.
Separación de 1229.09c1Organizati La separación de Se debe usar el 1.0.2

obligaciones onal.1 - 09.c obligaciones se utiliza control de acceso
para limitar el riesgo basado en rol (RBAC)
de modificaciones no en los servicios de
autorizada o Kubernetes
accidentales de la
información y los
sistemas.
NIST SP 800-171 R2
corresponden a este estándar de cumplimiento, consulte Cumplimiento normativo de Azure Policy: NIST SP
800-171 R2. Para más información acerca de este estándar normativo, consulte NIST SP 800-171 R2.
VERSIÓ N DE L A
VERSIÓ N DE L A
Integridad del 3.14.1 Identifica, informa y Kubernetes Services 1.0.2

sistema y de la corrige los errores del se debe actualizar a
información sistema de manera una versión de
puntual. Kubernetes no
vulnerable
Pasos siguientes
Obtenga más información sobre el cumplimiento normativo de Azure Policy.
Los elementos integrados se pueden encontrar en el repositorio de GitHub de Azure Policy.
Conceptos de redes de aplicaciones en Azure
En un enfoque de microservicios basado en contenedores para desarrollar aplicaciones, los componentes de la

aplicación funcionan juntos para procesar sus tareas. Kubernetes proporciona varios recursos que permiten esta
cooperación:
Puede conectarse a aplicaciones y exponer estas de forma interna o externa.
Puede equilibrar la carga de sus aplicaciones para compilar aplicaciones de alta disponibilidad.
En el caso de las aplicaciones más complejas, puede configurar el tráfico de entrada para la terminación
SSL/TLS o el enrutamiento de varios componentes.
Por motivos de seguridad, puede restringir el flujo de tráfico de red entre pods y nodos.
En este artículo se presentan los conceptos básicos que proporcionan redes para sus aplicaciones en AKS:
Servicios
Redes virtuales de Azure
Controladores de entrada
Directivas de red
Aspectos básicos de Kubernetes

Para permitir el acceso a las aplicaciones o entre los componentes de las aplicaciones, Kubernetes proporciona
una capa de abstracción para la red virtual. Los nodos de Kubernetes se conectan a una red virtual para
proporcionar conectividad de entrada y salida para los pods. El componente kube-proxy se ejecuta en cada nodo
para proporcionar estas características de red.
En Kubernetes:
los servicios agrupan lógicamente los pods para permitir el acceso directo a un puerto específico mediante
una dirección IP o nombre DNS.
Puede distribuir el tráfico mediante un equilibrador de carga.
También se puede lograr un enrutamiento del tráfico de la aplicación más complejo mediante los
controladores de entradas.
La seguridad y el filtrado del tráfico de red de los pods es posible con las directivas de red de Kubernetes.
La plataforma Azure también simplifica las redes virtuales de los clústeres de AKS. Cuando se crea un
equilibrador de carga de Kubernetes, también se crea y configura el recurso de equilibrador de carga de Azure
subyacente. Cuando abre los puertos de red a los pods, se configuran las reglas de los grupos de seguridad de
red de Azure correspondientes. Para el enrutamiento de aplicaciones HTTP, Azure también puede configurar un
DNS externo a medida que se configuran nuevas rutas de entrada.
Servicios
Para simplificar la configuración de red de las cargas de trabajo de la aplicación, Kubernetes usa servicios para
agrupar lógicamente un conjunto de pods y proporcionar conectividad de red. Están disponibles los siguientes
tipos de servicio:
IP del clúster
Crea una dirección IP interna para usarse dentro del clúster de AKS. Es útil solo para aplicaciones internas
que admiten otras cargas de trabajo dentro del clúster.
NodePor t
Una asignación de puerto en el nodo subyacente que permite que se pueda acceder a la aplicación
directamente con la dirección IP del nodo y el puerto.
LoadBalancer
Crea un recurso de equilibrador de carga de Azure, configura una dirección IP externa y conecta los pods
solicitados al grupo de back-end del equilibrador de carga. Para permitir que el tráfico de los clientes
llegue a la aplicación, se crean reglas de equilibrio de carga en los puertos deseados.
Para un control y enrutamiento adicionales del tráfico entrante, puede usar en su lugar un controlador de
entrada.
ExternalName
Crea una entrada DNS específica para facilitar el acceso a la aplicación.
La dirección IP tanto de los equilibradores de carga como de los servicios se puede asignar dinámicamente, o
puede especificar una dirección IP estática existente. Puede asignar direcciones IP estáticas internas y externas. A
menudo, las direcciones IP estáticas existentes están asociadas a una entrada DNS.
Puede crear equilibradores de carga internos y externos. Solo se asigna una dirección IP privada a los
equilibradores de carga internos, por lo que no se puede acceder a ellos desde Internet.
Redes virtuales de Azure

En AKS, puede implementar un clúster que use uno de los dos siguientes modelos de red:
Redes de Kubenet
Los recursos de red normalmente se crean y configuran cuando se implementa el clúster de AKS.
Redes de Azure Container Networking Interface (CNI)
el clúster de AKS está conectado a configuraciones y recursos de red virtual existentes.
Red (básica) de kubenet
La opción de red de kubenet es la configuración predeterminada para la creación del clúster de AKS. Con
kubenet:
1. los nodos obtienen una dirección IP de una subred de la red virtual de Azure.
2. Los pods reciben una dirección IP de un espacio de direcciones lógicamente distinto a la subred de red
virtual de Azure de los nodos.
3. A continuación, se configura la traducción de direcciones de red (NAT) para que los pods puedan acceder a
los recursos en la red virtual de Azure.
4. La dirección IP de origen del tráfico se traduce a la dirección IP principal del nodo.
Los nodos usan el complemento kubenet de Kubernetes. Puede:
Deje que la plataforma Azure cree y configure las redes virtuales automáticamente, o bien
Opte por implementar el clúster de AKS en una subred de red virtual existente.
Recuerde que solo los nodos reciben una dirección IP enrutable. Los pods usan NAT para comunicarse con otros
recursos fuera del clúster de AKS. Este enfoque reduce el número de direcciones IP que se deben reservar en el
espacio de red para su uso por parte de los pods.
Para más información, consulte el artículo de Configuración de la red de kubenet para un clúster de AKS.
Redes (avanzadas) de Azure CNI
Con Azure CNI, cada pod obtiene una dirección IP de la subred y se puede acceder a ella directamente. Estas
direcciones IP deben planearse de antemano y deben ser únicas en el espacio de red. Cada nodo tiene un
parámetro de configuración para el número máximo de pods que admite. Luego, el número equivalente de
direcciones IP por nodo se reserva por adelantado. Sin una planeación, este enfoque puede llevar al
agotamiento de las direcciones IP o a la necesidad de volver a generar los clústeres en una subred de mayor
tamaño, a medida que crecen las exigencias de la aplicación.
A diferencia de kubenet, el tráfico hacia los puntos de conexión de la misma red virtual no traduce las
direcciones de red a la dirección IP principal del nodo. La dirección de origen para el tráfico dentro de la red
virtual es la dirección IP del pod. El tráfico externo a la red virtual sigue traduciendo las direcciones de red a la
dirección IP principal del nodo.
Los nodos usan el complemento Azure CNI de Kubernetes.
Para más información, consulte el artículo de Configuración de Azure CNI para un clúster de AKS.
Comparación de modelos de red
Kubenet y Azure CNI proporcionan conectividad de red para los clústeres de AKS. Sin embargo, cada uno tiene
sus ventajas y sus desventajas. En general, se aplican las siguientes consideraciones:
kubenet
Conserva el espacio de direcciones IP.
Usa el equilibrador de carga interno o externo de Kubernetes para llegar a los pods desde fuera del
clúster.
Administre y mantenga las rutas definidas por el usuario (UDR) de manera manual.
400 nodos por clúster como máximo.
Azure CNI
Los pods obtienen conectividad de red virtual completa y se pueden alcanzar directamente a través de
su dirección IP privada desde redes conectadas.
Requiere más espacio de direcciones IP.
Existen las siguientes diferencias de comportamiento entre kubenet y Azure CNI:
C A PA C IDA D K UB EN ET C N I DE A Z URE
Implementación del clúster en la red Se admite, las UDR se aplican Compatible

virtual existente o en una nueva manualmente
Conectividad entre pods Compatible Compatible
Conectividad entre la máquina virtual Funciona cuando lo inicia el pod Funciona en ambas direcciones
y el pod; con la máquina virtual en la
misma red virtual
Conectividad entre la máquina virtual Funciona cuando lo inicia el pod Funciona en ambas direcciones
y el pod; con la máquina virtual en una
red virtual del mismo nivel
Acceso local mediante VPN o Funciona cuando lo inicia el pod Funciona en ambas direcciones
ExpressRoute
Acceso a los recursos protegidos por Compatible Compatible

puntos de conexión de servicio
Expone los servicios de Kubernetes Compatible Compatible

mediante un servicio de equilibrador
de carga, App Gateway o un
controlador de entrada
Azure DNS y zonas privadas Compatible Compatible

predeterminadas
Con respecto a DNS, con los complementos kubenet y Azure CNI, DNS se ofrece mediante CoreDNS, una
implementación que se ejecuta en AKS con su propio escalador automático. Para más información sobre
CoreDNS en Kubernetes, consulte Personalización del servicio DNS. De manera predeterminada, CoreDNS está
configurado para reenviar dominios desconocidos a la funcionalidad DNS de la red virtual de Azure en la que se
ha implementado el clúster de AKS. Por lo tanto, las zonas privadas y Azure DNS funcionarán para los pods que
se ejecutan en AKS.
Ámbito de compatibilidad entre los modelos de red
Sin importar qué modelo de red use, kubenet y Azure CNI pueden implementarse de una de las siguientes
maneras:
La plataforma Azure puede crear y configurar automáticamente los recursos de red virtual al crear un clúster
de AKS.
Puede crear y configurar los recursos de red virtual manualmente y conectarse a ellos al crear el clúster de
AKS.
Aunque se admiten funcionalidades como puntos de conexión de servicio o UDR tanto con kubenet como con
Azure CNI, las directivas de compatibilidad para AKS definen los cambios que se pueden realizar. Por ejemplo:
Si crea manualmente los recursos de red virtual para un clúster de AKS, tendrá soporte técnico para
configurar sus propios puntos de conexión de servicio o UDR.
Si la plataforma de Azure crea automáticamente los recursos de red virtual para el clúster de AKS, no puede
cambiar manualmente esos recursos administrados de AKS para configurar sus propios UDR o puntos de
conexión de servicio.
Controladores de entrada
Cuando se crea un servicio del tipo LoadBalancer, también se crea un recurso subyacente de equilibrador de
carga de Azure. El equilibrador de carga está configurado para distribuir el tráfico a los pods en su servicio en
un puerto determinado.
LoadBalancer solo funciona en la capa 4. En la capa 4, el servicio no conoce las aplicaciones reales y no puede
realizar ninguna otra consideración de enrutamiento.
Los controladores de entrada funcionan en la capa 7 y puede usar reglas más inteligentes para distribuir el
tráfico de la aplicación. Normalmente un controlador de entrada enruta el tráfico HTTP a diferentes aplicaciones
según la URL de entrada.
Creación de un recurso de entrada

En AKS, puede crear un recurso de entrada con NGINX, una herramienta similar o la característica de
enrutamiento de la aplicación HTTP de AKS. Cuando se habilita el enrutamiento de aplicación HTTP para un
clúster de AKS, la plataforma Azure crea el controlador de entrada y un controlador de DNS externo. Cuando se
crean nuevos recursos de entrada en Kubernetes, se crean los registros DNS A necesarios en una zona DNS
específica del clúster.
Para más información, consulte Implementación del enrutamiento de aplicaciones HTTP.
Controlador de entrada de Application Gateway (AGIC )
Con el complemento del controlador de entrada de Application Gateway (AGIC) los clientes de AKS aprovechan
la tecnología nativa del equilibrador de carga de nivel 7 de Application Gateway para exponer el software en la
nube a Internet. AGIC supervisa el clúster de Kubernetes de host y actualiza continuamente una instancia de
Application Gateway, de modo que los servicios seleccionados se exponen a Internet.
Para más información acerca del complemento de AGIC para AKS, consulte ¿Qué es controlador de entrada de
Application Gateway?
Terminación SSL/TLS
La terminación SSL/TLS es otra característica común de la entrada. En aplicaciones web de gran tamaño a las
que se accede a través de HTTPS, el recurso de entrada administra la terminación TLS, en lugar de en la propia
aplicación. Para proporcionar una configuración y generación automática de certificados TLS, puede configurar
el recurso de entrada para que use proveedores como "Let's Encrypt".
Para más información sobre cómo configurar un controlador de entrada de NGINX con Let's Encrypt, consulte el
artículo de Entrada y TLS.
Conservación de la dirección IP de origen de cliente
Configure el controlador de entrada para conservar la dirección IP de origen de cliente en las solicitudes a los
contenedores en el clúster de AKS. Cuando el controlador de entrada enruta la solicitud de un cliente a un
contenedor del clúster de AKS, la dirección IP de origen de la solicitud no está disponible para el contenedor de
destino. Al habilitar la conservación de la dirección IP de origen de cliente, la dirección IP de origen para el
cliente está disponible en el encabezado de solicitud en X-Forwarded-For.
Si usa la conservación de la dirección IP de origen de cliente en el controlador de entrada, no puede usar TLS de
paso a través. La conservación de la dirección IP de origen de cliente y TLS de paso a través pueden usarse con
otros servicios, como de tipo LoadBalancer.
Grupos de seguridad de red

Un grupo de seguridad de red filtra el tráfico de las máquinas virtuales, como los nodos de AKS. Al crear los
servicios, como LoadBalancer, la plataforma Azure configura automáticamente las reglas de grupo de seguridad
de red necesarias.
No necesita configurar manualmente las reglas del grupo de seguridad de red para filtrar el tráfico de los pods
en un clúster de AKS. Simplemente defina los puertos necesarios y el reenvío como parte de los manifiestos de
Kubernetes Service. Permita que la plataforma Azure cree o actualice las reglas correspondientes.
También puede usar directivas de red para aplicar automáticamente las reglas de filtro de tráfico a los pods.
Directivas de red
De forma predeterminada, todos los pods de un clúster de AKS pueden enviar y recibir tráfico sin limitaciones.
Para mejorar la seguridad, defina reglas que controlen el flujo de tráfico, como:
Las aplicaciones back-end solo se exponen a los servicios de front-end necesarios.
Los componentes de base de datos solo son accesibles para las capas de aplicación que se conectan a ellos.
La directiva de red es una característica de Kubernetes disponible en AKS que permite controlar el flujo de
tráfico entre pods. Según la configuración se permite o deniega el tráfico al pod, como, por ejemplo, etiquetas
asignadas, espacio de nombres o puerto de tráfico. Aunque los grupos de seguridad de red son mejores para
los nodos de AKS, las directivas de red son una manera más adecuada y nativa de la nube para controlar el flujo
de tráfico de los pods. Como los pods se crean dinámicamente en un clúster de AKS, se pueden aplicar
automáticamente las directivas de red necesarias.
Para más información, consulte Protección del tráfico entre pods mediante directivas de red en Azure
Kubernetes Service (AKS).
Pasos siguientes
Para empezar a trabajar con las redes de AKS, cree y configure un clúster de AKS con sus propios intervalos de
direcciones IP mediante kubenet o CNI de Azure.
Para los procedimientos recomendados asociados, consulte Procedimientos recomendados con la conectividad
de red y la seguridad en Azure Kubernetes Service (AKS).
siguientes:
Opciones de almacenamiento de aplicaciones en
Las aplicaciones que se ejecutan en Azure Kubernetes Service (AKS) pueden necesitar almacenar y recuperar
datos. Aunque algunas cargas de trabajo de aplicación pueden usar almacenamiento local y rápido en nodos
vacíos innecesarios, otras requieren almacenamiento que se conserva en volúmenes de datos más normales
dentro de la plataforma Azure.
Es posible que varios pods necesiten:
compartir los mismos volúmenes de datos o
volver a adjuntar volúmenes de datos si el pod se programa de nuevo en otro nodo.
Por último, es posible que deba insertar datos confidenciales o información de configuración de la aplicación en
los pods.
En este artículo se presentan los conceptos básicos que proporcionan almacenamiento para sus aplicaciones en
AKS:
Volúmenes
Volúmenes persistentes
Clases de almacenamiento
Notificaciones de volúmenes persistentes
Volúmenes
Kubernetes suele tratar los pods individuales como recursos efímeros y descartables. Las aplicaciones disponen
de diferentes enfoques para usar y conservar datos. Un volumen representa una manera de almacenar,
recuperar y conservar datos entre pods y durante el ciclo de vida de la aplicación.
Los volúmenes tradicionales se crean como recursos de Kubernetes respaldados por Azure Storage. Puede crear
manualmente volúmenes de datos para que se asignen directamente a los pods, o bien hacer que Kubernetes
los cree automáticamente. Los volúmenes de datos pueden utilizar Azure Disks o Azure Files.
Azure Disks
Use Azure Disks para crear un recurso DataDisk de Kubernetes. Los discos pueden usar:
Azure Premium Storage, respaldado por SSD de alto rendimiento o
Azure Standard Storage, respaldado por HDD normales.
TIP
Para la mayoría de las cargas de trabajo de producción y desarrollo, utilice el almacenamiento Premium.
Los discos de Azure Disks se montan como ReadWriteOnce, por lo que solo están disponibles para un único
pod. Para los volúmenes de almacenamiento a los que pueden acceder varios pods simultáneamente, use Azure
Files.
Azure Files
Use Azure Files para montar un recurso compartido de SMB 3.0 respaldado por una cuenta de Azure Storage en
los pods. Con Azure Files, puede compartir datos entre varios nodos y pods, además de utilizar:
Azure Premium Storage, respaldado por SSD de alto rendimiento o
Azure Standard Storage, respaldado por HDD normales.
Tipos de volúmenes
Los volúmenes de Kubernetes representan algo más que un disco tradicional para almacenar y recuperar
información. Los volúmenes de Kubernetes pueden utilizarse también como una forma de insertar datos en un
pod para su uso en contenedores.
Algunos tipos de volumen comunes de Kubernetes son, entre otros:
emptyDir
Se suele utilizar como espacio temporal para un pod. Todos los contenedores dentro de un pod pueden acceder
a los datos del volumen. Los datos escritos en este tipo de volumen solo se conservan durante la vida útil del
pod. Una vez eliminado el pod, también se elimina el volumen. Este volumen suele usar el almacenamiento en
disco del nodo local subyacente, aunque también puede existir solo en la memoria del nodo.
secret
Los volúmenes secret se usan para insertar en pods datos confidenciales, como contraseñas.
1. Cree un secreto mediante la API de Kubernetes.
2. Defina el pod o la implementación y solicite un secreto específico.
Los secretos solo se proporcionan a nodos con un pod programado que los requiera.
El secreto se almacena en tmpfs, no se escribe en el disco.
3. Cuando se elimina el último pod de un nodo que requiere un secreto, dicho secreto se elimina del tmpfs del
nodo.
Los secretos se almacenan en un espacio de nombres determinado y solo son accesibles para los pods
del mismo espacio de nombres.
configMap
Los volúmenes configMap pueden usarse para insertar en pods propiedades de pares clave-valor, como la
información de configuración de la aplicación. Defina esta información como un recurso de Kubernetes que se
actualice fácilmente y se aplique a nuevas instancias de pods a medida que se implementen.
Al igual que al usar un secreto, debe:
1. crear un volumen ConfigMap mediante la API de Kubernetes y
2. solicitar el volumen ConfigMap al definir un pod o una implementación.
Los volúmenes ConfigMap se almacenan en un espacio de nombres determinado y solo son
accesibles para los pods del mismo espacio de nombres.
Volúmenes persistentes
Los volúmenes definidos y creados como parte del ciclo de vida del pod solo existen hasta que se elimina este.
Los pods suelen esperar que su almacenamiento se conserve si un pod se vuelve a programar en un host
diferente durante un evento de mantenimiento, especialmente en StatefulSets. Un volumen persistente es un
recurso de almacenamiento creado y administrado por la API de Kubernetes, que puede existir más allá de la
duración de un pod individual.
Puede usar Azure Disks o Azure Files para proporcionar el volumen PersistentVolume. Como se ha indicado en
la sección Volúmenes, la elección de Azure Disks o Azure Files suele venir determinada por la necesidad de
acceso simultáneo a los datos o al nivel de rendimiento.
Un volumen PersistentVolume puede crearlo de forma estática un administrador de clústeres o de forma

dinámica el servidor de API de Kubernetes. Si un pod está programado y solicita almacenamiento que no está
disponible actualmente, Kubernetes puede crear el almacenamiento subyacente de Azure Disks o Azure Files y
conectarlo al pod. El aprovisionamiento dinámico usa StorageClass para identificar el tipo de almacenamiento
que Azure Storage debe crear.
Clases de almacenamiento
Para definir niveles de almacenamiento diferentes, como Premium y Estándar, puede crear una clase
StorageClass.
La clase StorageClass también define la directiva reclaimPolicy. Si se elimina el pod y el volumen persistente
deja de ser necesario, la directiva reclaimPolicy controla el comportamiento del recurso de almacenamiento
subyacente de Azure. Este recurso puede eliminarse o conservarse para usarse con un pod futuro.
En AKS, se crean cuatro StorageClasses iniciales para el clúster mediante los complementos de almacenamiento
en árbol:
P ERM ISO M OT IVO
default Usa almacenamiento de SSD estándar de Azure para crear

un disco administrado. La directiva de reclamación garantiza
que el almacenamiento de Azure Disks subyacente se elimina
cuando se elimina el volumen persistente que lo utiliza.
managed-premium Usa Azure Premium Storage para crear un disco

administrado. De nuevo, la directiva de reclamación
garantiza que el almacenamiento de Azure Disks subyacente
se elimina cuando se elimina el volumen persistente que lo
utiliza.
azurefile Usa Azure Standard Storage para crear un recurso

compartido de archivos de Azure. La directiva de
reclamación garantiza que el recurso compartido de archivos
de Azure subyacente se elimina cuando se elimina el
volumen persistente que lo usa.
P ERM ISO M OT IVO
azurefile-premium Usa Azure Premium Storage para crear un recurso

En el caso de los clústeres que usan los nuevos complementos externos de Container Storage Interface (CSI,
versión preliminar), se crean las siguientes clases StorageClasses extras:
P ERM ISO M OT IVO
managed-csi Usa almacenamiento con redundancia local de SSD Estándar

de Azure para crear un disco administrado. La directiva de
reclamación garantiza que el almacenamiento de Azure Disks
subyacente se elimina cuando se elimina el volumen
persistente que lo utiliza. La clase de almacenamiento
también configura los volúmenes persistentes para que se
puedan expandir, solo es necesario editar la notificación de
volumen persistente con el nuevo tamaño.
managed-csi-premium Usa almacenamiento con redundancia local Premium de

Azure para crear un disco administrado. De nuevo, la
directiva de reclamación garantiza que el almacenamiento de
Azure Disks subyacente se elimina cuando se elimina el
volumen persistente que lo utiliza. De forma similar, esta
clase de almacenamiento permite expandir los volúmenes
persistentes.
azurefile-csi Usa Azure Standard Storage para crear un recurso

azurefile-csi-premium Usa Azure Premium Storage para crear un recurso

A menos que especifique una clase StorageClass para un volumen persistente, se usará la clase StorageClass
predeterminada. Cuando solicite volúmenes persistentes, asegúrese de que usen el almacenamiento adecuado
que necesita.
Puede crear una clase StorageClass para satisfacer necesidades adicionales mediante kubectl . En el siguiente
ejemplo se utilizan discos administrados Premium y se especifica que el disco subyacente de Azure Disks debe
conservarse cuando se elimine el pod:
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: managed-premium-retain
provisioner: kubernetes.io/azure-disk
reclaimPolicy: Retain
parameters:
storageaccounttype: Premium_LRS
kind: Managed
NOTE
AKS concilia las clases de almacenamiento predeterminadas y sobrescribirá los cambios que realice en ellas.
Notificaciones de volúmenes persistentes

Una notificación PersistentVolumeClaim solicita almacenamiento en disco o archivo de una clase StorageClass,
un modo de acceso y un tamaño determinados. El servidor de API de Kubernetes puede aprovisionar
dinámicamente el recurso de almacenamiento subyacente de Azure si no existe ningún recurso para satisfacer la
notificación de acuerdo con la clase StorageClass definida.
La definición del pod incluye el montaje del volumen una vez que se este se ha conectado al pod.
Una vez que se ha asignado un recurso de almacenamiento disponible al pod que lo solicita, se enlaza un
volumen PersistentVolume a una notificación PersistentVolumeClaim. Los volúmenes persistentes se asignan a
las notificaciones de uno a uno.
El manifiesto YAML de ejemplo siguiente muestra una notificación de volumen persistente que usa la clase
StorageClass managed-premium y solicita un disco de 5 Gi de tamaño:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: azure-managed-disk
spec:
accessModes:
- ReadWriteOnce
storageClassName: managed-premium
resources:
requests:
storage: 5Gi
Al crear una definición de pod, también se especifica lo siguiente:

La notificación de volumen persistente para solicitar el almacenamiento deseado
El objeto volumeMount para que sus aplicaciones lean y escriban datos
El siguiente manifiesto YAML de ejemplo muestra cómo se puede usar la notificación de volumen persistente
anterior para montar un volumen en /mnt/azure:
kind: Pod
apiVersion: v1
metadata:
name: nginx
spec:
containers:
- name: myfrontend
volumeMounts:
- mountPath: "/mnt/azure"
name: volume
volumes:
- name: volume
persistentVolumeClaim:
claimName: azure-managed-disk
Para montar un volumen en un contenedor de Windows, especifique la letra de unidad y la ruta de acceso. Por
ejemplo:
...
volumeMounts:
- mountPath: "d:"
name: volume
- mountPath: "c:\k"
name: k-dir
...
Pasos siguientes
Para consultar los procedimientos recomendados asociados, consulte Procedimientos recomendados para el
almacenamiento y las copias de seguridad en Azure Kubernetes Service (AKS).
Para ver cómo crear volúmenes dinámicos y estáticos que usen Azure Disks o Azure Files, consulte los artículos
de procedimientos siguientes:
Creación de un volumen estático con Azure Disks
Creación de un volumen estático con Azure Files
Creación de un volumen dinámico con Azure Disks
Creación de un volumen dinámico con Azure Files
siguientes:
Identidad de Kubernetes/AKS
Opciones de escalado de aplicaciones en Azure
A medida que ejecuta aplicaciones en Azure Kubernetes Service (AKS), es posible que deba aumentar o
disminuir la cantidad de recursos de proceso. Del mismo modo que debe cambiar el número de instancias de la
aplicación, es posible que deba cambiar también el número de nodos de Kubernetes subyacentes. Es posible que
también deba aprovisionar rápidamente un gran número de instancias de aplicación adicionales.
En este artículo se presentan los conceptos básicos para ayudarle a escalar aplicaciones en AKS:
Escalado manual
Horizontal Pod Autoscaler (HPA)
Cluster Autoscaler
Integración de Azure Container Instances (ACI) con AKS
Escalado manual de pods o nodos

Puede escalar manualmente las réplicas (pods) y nodos para probar cómo responde la aplicación a un cambio
en los recursos disponibles y el estado. El escalado manual de recursos también le permite definir una cantidad
establecida de recursos que se usarán para mantener un costo fijo como el número de nodos. Para realizar un
escalado manual, defina el número de réplicas o de nodos. Luego, Kubernetes API programará la creación de
pods adicionales o el drenaje de nodos en función del número de réplicas o de nodos.
Al reducir verticalmente los nodos, la API de Kubernetes llama a la API de proceso de Azure correspondiente
asociada al tipo de proceso que usa el clúster. Por ejemplo, para los clústeres basados en VM Scale Sets, la lógica
para seleccionar los nodos que se van a quitar vienen determinada por la API de VM Scale Sets. Para obtener
más información sobre cómo se seleccionan los nodos para su eliminación al reducir verticalmente, vea las
preguntas más frecuentes sobre VMSS.
Para empezar con el escalado manual de pods y nodos, consulte Escalado de aplicaciones en AKS.
Horizontal Pod Autoscaler

Kubernetes utiliza Horizontal Pod Autoscaler (HPA) para supervisar la demanda de recursos y escalar
automáticamente el número de réplicas. De forma predeterminada, Horizontal Pod Autoscaler comprueba la API
de métricas cada 30 segundos para ver si se requieren cambios en el número de réplicas. Cuando se necesitan
cambios, el número de réplicas aumenta o disminuye en consecuencia. Horizontal Pod Autoscaler funciona con
los clústeres de AKS que han implementado el servidor de métricas para Kubernetes 1.8 y versiones posteriores.
Si configura Horizontal Pod Autoscaler para una implementación determinada, defina el número mínimo y
máximo de réplicas que se pueden ejecutar. Defina también la métrica que se supervisará y en la que se basarán
todas las decisiones de escalado, como el uso de la CPU.
Para empezar a usar Horizontal Pod Autoscaler en AKS, consulte Escalado automático de pods en AKS.
Recuperación de eventos de escalado
Dado que Horizontal Pod Autoscaler comprueba cada 30 segundos la API de métricas, es posible que los
eventos de escalado anteriores no se hayan completado correctamente antes de realizar otra comprobación.
Este comportamiento puede provocar que Horizontal Pod Autoscaler cambie el número de réplicas antes de que
el evento de escalado anterior pueda recibir la carga de trabajo de la aplicación y las demandas de recursos para
ajustarlas en consecuencia.
Para minimizar los eventos de carrera, se establece un valor de retraso. Este valor define cuánto tiempo debe
esperar Horizontal Pod Autoscaler después de un evento de escalado antes de que se pueda desencadenar otro
evento de escalado. Este comportamiento permite que el nuevo recuento de réplicas surta efecto y que Metrics
API refleje la carga de trabajo distribuida. No hay retraso para los eventos de escalado vertical a partir de
Kubernetes 1.12, pero el retraso en los eventos de reducción vertical está establecido de manera
predeterminada en 5 minutos.
Actualmente, estos valores de recuperación no se pueden ajustar a partir del valor predeterminado.
Cluster Autoscaler
Para responder a las distintas exigencias de pods, Kubernetes tiene un componente Cluster Autoscaler que
ajusta el número de nodos según los recursos de proceso solicitados en el grupo de nodos. De manera
predeterminada, Cluster Autoscaler comprueba en el servidor de la API de métricas cada 10 segundos los
cambios necesarios en el recuento de nodos. Si Cluster Autoscaler determina que es necesario un cambio, el
número de nodos del clúster de AKS aumenta o disminuye en consecuencia. El escalador automático de
clústeres funciona con clústeres de AKS habilitados para RBAC de Kubernetes que ejecutan Kubernetes 1.10.x o
una versión superior.
Cluster Autoscaler se usa normalmente junto con Horizontal Pod Autoscaler. Cuando se combinan, Horizontal
Pod Autoscaler aumenta o disminuye el número de pods según la demanda de la aplicación, mientras que
Cluster Autoscaler ajusta el número de nodos según sea necesario para ejecutar los pods adicionales en
consecuencia.
Para empezar a usar Cluster Autoscaler en AKS, consulte Cluster Autoscaler en AKS.
Eventos de escalado horizontal
Si un nodo no tiene suficientes recursos de proceso para ejecutar un pod solicitado, el pod no avanza por el
progreso de la programación. El pod no se puede iniciar, salvo que haya recursos de proceso adicionales
disponibles en el grupo de nodos.
Si Cluster Autoscaler detecta pods que no se pueden programar debido a restricciones de recursos del grupo de
nodos, el número de nodos del grupo de nodos aumenta para proporcionar los recursos de proceso adicionales.
Cuando esos nodos adicionales están correctamente implementados y disponibles para su uso en el grupo de
nodos, los pods se programan para ejecutarse en estos.
Si su aplicación necesita escalar rápidamente, algunos de los pods pueden permanecer en un estado de espera
de programación hasta que los nodos adicionales implementados por Cluster Autoscaler puedan aceptar los
pods programados. Para las aplicaciones que tienen una alta demanda de ráfaga, puede realizar el escalado con
nodos virtuales y Azure Container Instances.
Eventos de reducción horizontal
Cluster Autoscaler también supervisa el estado de programación de los pods en los nodos que no han recibido
recientemente nuevas solicitudes de programación. Este escenario indica que el grupo de nodos tiene más
recursos de proceso de los necesarios y que se puede reducir el número de nodos.
Un nodo que supera un umbral que indica que ya no es necesario durante 10 minutos, está programado de
forma predeterminada para su eliminación. Cuando se produce esta situación, los pods se programan para
ejecutarse en otros nodos del grupo de nodos y Cluster Autoscaler reduce el número de nodos.
Las aplicaciones pueden experimentar interrupciones, ya que los pods se programan en distintos nodos cuando
Cluster Autoscaler reduce el número de nodos. Para minimizar las interrupciones, evite las aplicaciones que
usan una instancia de un solo pod.
Ráfaga en Azure Container Instances

Para escalar rápidamente el clúster de AKS, puedes realizar la integración con Azure Container Instances (ACI).
Kubernetes tiene componentes integrados para escalar el recuento de réplicas y nodos. Sin embargo, si la
aplicación se debe escalar rápidamente, Horizontal Pod Autoscaler puede programar más pods que los recursos
de proceso existentes puedan proporcionar en el grupo de nodos. Si está configurado, este escenario
desencadenará Cluster Autoscaler para la implementación de nodos adicionales en el grupo de nodos, pero es
posible que se necesiten unos minutos para aprovisionar correctamente esos nodos y permitir que el
programador de Kubernetes ejecute pods en estos.
ACI le permite implementar rápidamente instancias de contenedor sin sobrecarga de infraestructura adicional.
Cuando se conecta con AKS, ACI se convierte en una extensión lógica y segura de su clúster de AKS. El
componente de nodos virtuales, que se basa en Virtual Kubelet, se instala en el clúster de AKS que presenta ACI
como un nodo de Kubernetes virtual. Kubernetes puede programar pods que se ejecuten como instancias de
ACI a través de los nodos virtuales, no como pods en nodos de máquina virtual directamente en el clúster de
AKS.
La aplicación no requiere ninguna modificación para usar los nodos virtuales. Puede escalar las
implementaciones en AKS y ACI sin ningún retraso, ya que Cluster Autoscaler implementa los nodos nuevos en
el clúster de AKS.
Los nodos virtuales se implementan en una subred adicional en la misma red virtual que el clúster de AKS. Esta
configuración de red virtual permite proteger el tráfico entre ACI y AKS. Al igual que un clúster de AKS, una
instancia de ACI es un recurso de proceso lógico y seguro que se aísla de otros usuarios.
Pasos siguientes
Para empezar con el escalado de aplicaciones, siga el inicio rápido para crear un clúster de AKS con la CLI de
Azure. A continuación, puede empezar a escalar aplicaciones de manera manual o automática en el clúster de
AKS:
Escalado manual de pods o nodos
Uso de Horizontal Pod Autoscaler
Uso de Cluster Autoscaler
siguientes:
Reparación automática de nodos de Azure
AKS supervisa de manera continua el estado de mantenimiento de los nodos de trabajo y realiza reparaciones
automáticas si son incorrectos. La plataforma de máquina virtual (VM) de Azure realiza el mantenimiento de las
VM que experimentan problemas.
AKS y las VM de Azure trabajan de forma conjunta para minimizar las interrupciones del servicio de los
clústeres.
Este documento, obtendrá información acerca de cómo se comporta la funcionalidad de reparación automática
del nodo para nodos Windows y Linux.
Comprobaciones de nodos en mal estado en AKS

AKS usa las siguientes reglas para determinar si un nodo es incorrecto y necesita reparación:
El nodo notifica un estado NotReady en comprobaciones consecutivas durante un período de 10 minutos.
El nodo no notifica ningún estado en un plazo de 10 minutos.
Puede comprobar manualmente el estado de mantenimiento de los nodos con kubectl.
kubectl get nodes
Funcionamiento de la reparación automática

NOTE
AKS inicia las operaciones de reparación con la cuenta de usuario aks-remediator .
Si AKS identifica un nodo incorrecto que permanece de este modo durante 10 minutos, AKS realiza las
siguientes acciones:
1. Reinicie el nodo.
2. Si el reinicio no se realiza correctamente, restablece la imagen inicial del nodo.
3. Si la nueva imagen no se restablece correctamente, crea y restablece la imagen inicial de un nuevo nodo.
Los ingenieros de AKS están investigando correcciones alternativas si la reparación automática no se realiza
correctamente.
Si AKS encuentra varios nodos incorrectos durante una comprobación de estado, cada nodo se repara
individualmente antes de que comience otra reparación.
Pasos siguientes
Use Availability Zones para aumentar la alta disponibilidad con las cargas de trabajo del clúster de AKS.
Procedimientos recomendados de operadores de
clúster y desarrolladores para crear y administrar
aplicaciones en Azure Kubernetes Service (AKS)
La creación y ejecución correctas de aplicaciones en Azure Kubernetes Service (AKS) requieren la comprensión y
la implementación de algunas consideraciones clave, entre las que se incluyen:
Características multiinquilino y programador
Seguridad de clúster y pod
Continuidad empresarial y recuperación ante desastres
El grupo de productos de AKS, los equipos de ingeniería y los equipos de campo (incluidos cinturones negros
globales [GBB]) han escrito y agrupado los procedimientos recomendados siguientes y los artículos
conceptuales, así como han contribuido a ellos. Su propósito es ayudar a los operadores y desarrolladores de
clústeres a comprender las consideraciones anteriores e implementar las características adecuadas.
Procedimientos recomendados para operadores de clúster

Como operador de clúster, trabaje en conjunto con los propietarios y desarrolladores de aplicaciones para
conocer sus necesidades. A continuación, puede usar los siguientes procedimientos recomendados para
configurar los clústeres de AKS según sea necesario.
Ser vicios multiinquilino
Procedimientos recomendados para el aislamiento de clústeres
Incluye los componentes principales de los servicios multiinquilino y el aislamiento lógico con
espacios de nombres.
Procedimientos recomendados para las características básicas del programador
Incluye el uso de las cuotas de recursos y los presupuestos de interrupciones de pod.
Procedimientos recomendados para las características avanzadas del programador
Incluye el uso de defectos y tolerancias, los selectores de nodo y afinidad, y la afinidad y falta de
afinidad entre pods.
Procedimientos recomendados para autenticación y autorización
Incluye la integración en Azure Active Directory, el uso del control de acceso basado en rol de
Kubernetes (RBAC de Kubernetes), el uso de Azure RBAC y el uso de identidades de pod.
Seguridad
Procedimientos recomendados para actualizaciones y seguridad de clústeres
Incluye la protección del acceso al servidor de API, limitar el acceso a los contenedores y la
administración de las actualizaciones y los reinicios de nodos.
Procedimientos recomendados para la administración y la protección de las imágenes de contenedor
Incluye la protección de la imagen y los runtime y compilaciones automatizadas en actualizaciones de
la imagen base.
Procedimientos recomendados para la seguridad de pods
Incluye la protección del acceso a los recursos, la limitación de la exposición de las credenciales y el
uso de identidades de pods y almacenes de claves digitales.
Red y almacenamiento
Procedimientos recomendados para la conectividad de red
Incluye distintos modelos de red, el uso de firewalls de aplicaciones web (WAF) y de entrada, y la
protección del acceso SSH a los nodos.
Procedimientos recomendados para almacenamiento y copias de seguridad
Incluye la elección del tipo de almacenamiento y el tamaño de nodo apropiados, el aprovisionamiento
dinámico de volúmenes, y copias de seguridad de datos.
Ejecución de cargas de trabajo preparadas para la empresa
Procedimientos recomendados para continuidad empresarial y recuperación ante desastres
Incluye el uso de pares de regiones, varios clústeres con Azure Traffic Manager y la replicación
geográfica de las imágenes de contenedor.
Procedimientos recomendados para desarrolladores

Como desarrollador o propietario de una aplicación, puede simplificar su experiencia de desarrollo y definir las
necesidades de rendimiento de la aplicación.
Procedimientos recomendados para desarrolladores de aplicaciones para administrar recursos
Incluye la definición de las solicitudes y los límites de recursos de pod, la configuración de las
herramientas de desarrollo y la comprobación de problemas de la aplicación.
Procedimientos recomendados para la seguridad de pods
Incluye la protección del acceso a los recursos, la limitación de la exposición de las credenciales y el
uso de identidades de pods y almacenes de claves digitales.
Conceptos de Kubernetes/AKS
Para ayudar a comprender algunas de las características y componentes de estos procedimientos
recomendados, también puede consultar los siguientes artículos conceptuales para clústeres en Azure
Kubernetes Service (AKS):
Conceptos básicos de Kubernetes
Acceso e identidad
Conceptos de seguridad
Conceptos de red
Opciones de almacenamiento
Opciones de escalado
Pasos siguientes
Si necesita empezar a trabajar con AKS, siga uno de los tutoriales de inicio rápido para implementar un clúster
de Azure Kubernetes Service (AKS) con la CLI de Azure o Azure Portal.
Procedimientos recomendados para el aislamiento
de clústeres en Azure Kubernetes Service (AKS)
A medida que administra los clústeres en Azure Kubernetes Service (AKS), a menudo necesita aislar los equipos
y las cargas de trabajo. AKS proporciona flexibilidad acerca de cómo puede ejecutar clústeres multiempresa y
aislar recursos. Para maximizar la inversión en Kubernetes, primero debe comprender e implementar las
funciones multiempresa y de aislamiento de AKS.
Este artículo de procedimientos recomendados se centra en el aislamiento de los operadores de clústeres. En
este artículo aprenderá a:
Planificar clústeres multiempresa y separación de recursos.
Usar el aislamiento lógico o físico de los clústeres de AKS.
Diseño de clústeres para la configuración multiempresa

Kubernetes permite aislar lógicamente equipos y cargas de trabajo en el mismo clúster. El objetivo es
proporcionar el número mínimo de privilegios en el ámbito de los recursos que necesita cada equipo. Un
espacio de nombres de Kubernetes crea un límite de aislamiento lógico. A continuación, se incluyen otras
características y consideraciones de Kubernetes sobre el aislamiento y la arquitectura multiinquilino:
Scheduling
La programación usa características básicas, como las cuotas de recursos y los presupuestos de interrupciones
del pod. Para más información acerca de estas características, consulte Procedimientos recomendados para
características básicas del programador en Azure Kubernetes Service (AKS).
Las siguientes son algunas de las características más avanzadas del programador:
Intolerancias y tolerancias
Selectores de nodos
Afinidad o antiafinidad de nodos y pods.
Para más información acerca de estas características, consulte Procedimientos recomendados para
características avanzadas del programador en Azure Kubernetes Service (AKS).
Redes
Las redes usan directivas de red para controlar el flujo de tráfico de entrada y salida de pods.
Usos de la autenticación y autorización:
Control de acceso basado en roles (RBAC)
Integración de Azure Active Directory (AD)
Identidades de pod
Secretos en Azure Key Vault
Para más información sobre estas características, consulte Procedimientos recomendados para la autenticación
y autorización en Azure Kubernetes Service (AKS).
Contenedores
Los contenedores incluyen:
El complemento de Azure Policy para AKS con el fin de aplicar la seguridad del pod.
El uso de contextos de seguridad de pod.
Examen de las imágenes y el entorno de ejecución en busca de vulnerabilidades.
El uso de AppArmor o Seccomp (informática segura) para restringir el acceso del contenedor al nodo
subyacente.
Aislamiento de clústeres de forma lógica

Guía de procedimientos recomendados
Separe los equipos y proyectos mediante el aislamiento lógico. Minimice el número de clústeres físicos de
AKS que implementa para aislar los equipos o las aplicaciones.
Con el aislamiento lógico, un único clúster de AKS puede utilizarse para varios entornos, equipos o cargas de
trabajo. Los espacios de nombres de Kubernetes forman el límite de aislamiento lógico para las cargas de
trabajo y los recursos.
La separación lógica de clústeres normalmente proporciona una mayor densidad de pods que los clústeres
aislados físicamente, con una menor capacidad de proceso inactiva en el clúster. Cuando se combina con el
escalador automático de clúster de Kubernetes, puede escalar vertical u horizontalmente el número de nodos
para satisfacer las necesidades. Esta estrategia de procedimiento recomendado para el escalado automático
minimiza los costos al ejecutar solo el número de nodos necesario.
Actualmente, los entornos de Kubernetes no están completamente seguros ante el uso de varios inquilinos
hostiles. En un entorno multiinquilino, varios inquilinos trabajan en una infraestructura compartida común. Si
no se puede confiar en todos los inquilinos, necesitará de planeamiento adicional para evitar que dichos
inquilinos afecten a la seguridad y el servicio de otros.
Las características de seguridad adicionales, como las directivas de seguridad de pods o Kubernetes RBAC para
nodos, bloquean eficazmente las vulnerabilidades de seguridad. Para una verdadera seguridad al ejecutar cargas
de trabajo multiinquilino hostiles, debe confiar solo en un hipervisor. El dominio de seguridad de Kubernetes se
convierte en todo el clúster, no en un nodo específico.
En el caso de estos tipos de cargas de trabajo multiinquilino hostiles, debe usar clústeres que estén físicamente
aislados.
Aislamiento de clústeres de forma física
Minimice el uso del aislamiento físico para cada implementación de la aplicación o equipo independientes.
En su lugar, use el aislamiento lógico, como se describe en la sección anterior.
Separar físicamente los clústeres de AKS es un enfoque común para el aislamiento de clústeres. En este modelo
de aislamiento, los equipos o las cargas de trabajo se asignan a su propio clúster de AKS. Aunque el aislamiento
físico podría parecer la manera más fácil de aislar cargas de trabajo o equipos, agrega una sobrecarga financiera
y administrativa. Ahora, debe mantener estos clústeres, así como proporcionar acceso y asignar permisos de
manera individual. También se le facturará por cada nodo individual.
Los clústeres físicamente independientes suelen tener una densidad de pods baja. Ya que cada equipo o carga
de trabajo tiene su propio clúster de AKS, el clúster a menudo se aprovisiona en exceso con recursos de proceso.
Con frecuencia, se programa un pequeño número de pods en esos nodos. La capacidad de los nodos no
utilizada no se puede usar para aplicaciones o servicios que están desarrollando otros equipos. Estos recursos
en exceso contribuyen a los costos adicionales en los clústeres físicamente independientes.
Pasos siguientes
Este artículo se centra en el aislamiento de clústeres. Para obtener más información acerca de las operaciones de
clúster en AKS, consulte los siguientes procedimientos recomendados:
Características básicas del programador de Kubernetes
Características avanzadas del programador de Kubernetes
Procedimientos recomendados para características
básicas del programador en Azure Kubernetes
Service (AKS)
y las cargas de trabajo. El programador de Kubernetes le permite controlar la distribución de los recursos de
proceso o limitar el impacto de los eventos de mantenimiento.
Este artículo de procedimientos recomendados se centra en las características básicas de Kubernetes para
operadores de clúster. En este artículo aprenderá a:
Utilizar las cuotas de recursos para proporcionar una cantidad fija de recursos para cargas de trabajo o
equipos
Limitar el impacto del mantenimiento programado utilizando presupuestos de interrupciones de pods
Comprobar si faltan solicitudes y límites de recursos de pods con la herramienta kube-advisor
Aplicación de cuotas de recursos

Planee y aplique cuotas de recursos en el nivel del espacio de nombres. Si los pods no definen solicitudes y
límites de recursos, rechace la implementación. Supervise el uso de recursos y ajuste las cuotas según sea
necesario.
Las solicitudes y límites de recursos se colocan en la especificación de pod. El programador de Kubernetes usa
los límites en el momento de la implementación para buscar un nodo disponible en el clúster. Los límites y las
solicitudes funcionan en el nivel de pod individual. Para obtener más información sobre cómo definir estos
valores, vea Definición de los límites y solicitudes de recursos del pod.
Para proporcionar una manera de reservar y limitar los recursos a través de un proyecto o equipo de desarrollo,
debe usar las cuotas de recursos. Estas cuotas se definen en un espacio de nombres y se pueden usar para
establecer cuotas de la siguiente manera:
Recursos de proceso , como CPU y memoria, o GPU.
Recursos de almacenamiento , que incluyen el número total de volúmenes o la cantidad de espacio en
disco para una clase de almacenamiento determinada.
Recuento de objetos , como el número máximo de secretos, servicios o trabajos que se pueden crear.
Kubernetes no sobrecarga los recursos. Una vez que el total de solicitudes de recursos acumuladas supera la
cuota asignada, todas las demás implementaciones no se realizarán correctamente.
Al definir las cuotas de recursos, todos los pods creados en el espacio de nombres deben proporcionar límites o
recursos en sus especificaciones de pods. Si no proporcionan estos valores, puede rechazar la implementación.
En su lugar, puede configurar solicitudes y límites predeterminados para un espacio de nombres.
El siguiente manifiesto YAML de ejemplo llamado dev-app-team-quotas.yaml establece un límite rígido de un
total de 10 CPU, 20Gi de memoria y 10 pods:
apiVersion: v1
kind: ResourceQuota
metadata:
name: dev-app-team
spec:
hard:
cpu: "10"
memory: 20Gi
pods: "10"
Esta cuota de recursos se puede aplicar mediante la especificación del espacio de nombres, como dev-apps:
kubectl apply -f dev-app-team-quotas.yaml --namespace dev-apps
Trabaje con los desarrolladores y propietarios de su aplicación para conocer sus necesidades y aplicar las cuotas
de recursos adecuadas.
Para obtener más información sobre los objetos de recursos, los ámbitos y las prioridades disponibles, consulte
Resource quotas (Cuotas de recursos) en Kubernetes.
Planeación de disponibilidad mediante presupuestos de

interrupciones de pods
Para mantener la disponibilidad de las aplicaciones, defina presupuestos de interrupciones de pods para
asegurarse de que haya un número mínimo de pods disponible en el clúster.
Hay dos eventos de interrupción que provocan que se quiten los pods:
Interrupciones involuntarias
Las interrupciones involuntarias son eventos más allá del control típico del operador del clúster o el propietario
de la aplicación. Inclusión:
Error de hardware en la máquina física
Pánico de kernel
Eliminación de una máquina virtual de nodo
Las interrupciones involuntarias se pueden mitigar mediante:
El uso de varias réplicas de los pods en una implementación.
La ejecución de varios nodos en el clúster de AKS.
Interrupciones voluntarias
Las interrupciones voluntarias son eventos solicitados por el operador del clúster o el propietario de la
aplicación. Inclusión:
Actualizaciones de clústeres
Plantilla de implementación actualizada
Eliminación accidental de un pod
Kubernetes proporciona presupuestos de interrupciones de pods para interrupciones voluntarias, lo que le
permite planear cómo responden las implementaciones o los conjuntos de réplicas cuando se produce un
evento de interrupción voluntaria. Mediante los presupuestos de interrupciones de pods, los operadores del
clúster pueden definir un número máximo de recursos no disponibles o un número mínimo de recursos
disponibles.
Si actualiza un clúster o una plantilla de implementación, el programador de Kubernetes programará pods
adicionales en otros nodos antes de permitir que continúen los eventos de interrupción voluntaria. El
programador espera a que se reinicie un nodo hasta que la cantidad definida de pods se programe
correctamente en otros nodos del clúster.
Veamos un ejemplo de un conjunto de réplicas con cinco pods que ejecutan NGINX. Se ha asignado la etiqueta
app: nginx-frontend a los pods del conjunto de réplicas. Durante un evento de interrupción voluntaria, como
una actualización de clúster, desea asegurarse de que al menos tres pods continúen ejecutándose. El siguiente
manifiesto YAML para un objeto PodDisruptionBudget define estos requisitos:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: nginx-pdb
spec:
minAvailable: 3
selector:
matchLabels:
app: nginx-frontend
También puede definir un porcentaje, como 60 % , que permite compensar automáticamente el conjunto de
réplicas escalando verticalmente el número de pods.
Puede definir un número máximo de instancias no disponibles en un conjunto de réplicas. De nuevo, también se
puede definir un porcentaje máximo de pods no disponibles. El siguiente manifiesto YAML de presupuesto de
interrupciones de pods define que no estarán no disponibles más de dos pods en el conjunto de réplicas:
kind: PodDisruptionBudget
metadata:
name: nginx-pdb
spec:
maxUnavailable: 2
selector:
matchLabels:
app: nginx-frontend
Una vez que se ha definido su presupuesto de interrupciones de pods, créelo en el clúster de AKS al igual que
cualquier otro objeto de Kubernetes:
kubectl apply -f nginx-pdb.yaml
Trabaje con los desarrolladores y propietarios de su aplicación para conocer sus necesidades y aplicar los
presupuestos de interrupciones de pods adecuados.
Para obtener más información sobre el uso de los presupuestos de interrupciones de pods, vea Especificando un
presupuesto de disrupción para tu aplicación.
Comprobación de forma periódica de problemas de clúster con kube-

advisor
Ejecute periódicamente la versión más reciente de la herramienta de código abierto kube-advisor para
detectar problemas en el clúster. Si aplica cuotas de recursos en un clúster de AKS existente, en primer lugar,
ejecute kube-advisor para buscar los pods que no tienen definidos los límites y las solicitudes de recursos.
La herramienta kube-advisor es un proyecto de código abierto de AKS asociado que examina un clúster de
Kubernetes e informa sobre los problemas identificados. kube-advisor resulta útil para identificar pods sin
solicitudes de recursos ni límites.
Aunque la herramienta kube-advisor puede informar sobre la solicitud de recursos y la falta de límites en
PodSpecs para las aplicaciones Windows y Linux, la propia herramienta debe programarse en un pod de Linux.
Programe un pod para que se ejecute en un grupo de nodos con un sistema operativo específico mediante un
selector de nodo en la configuración del pod.
El seguimiento de pods sin límites y solicitudes de recursos establecidos en un clúster de AKS que hospeda
varios equipos y aplicaciones de desarrollo puede ser difícil. Como práctica recomendada, ejecute regularmente
kube-advisor en los clústeres de AKS, especialmente si no asigna cuotas de recursos a los espacios de nombres.
Pasos siguientes
Este artículo se ha centrado en características básicas del programador de Kubernetes. Para obtener más
información acerca de las operaciones de clúster en AKS, consulte los siguientes procedimientos recomendados:
Aislamiento de clúster y de multiinquilinato
Procedimientos recomendados para características
avanzadas del programador en Azure Kubernetes
Service (AKS)
y las cargas de trabajo. Las características avanzadas proporcionadas por el programador de Kubernetes le
permiten controlar:
Qué pods se pueden programar en determinados nodos.
Cómo se pueden distribuir correctamente las aplicaciones de varios pods en el clúster.
Este artículo de procedimientos recomendados se centra en las características avanzadas de Kubernetes para
operadores de clúster. En este artículo aprenderá a:
Usar valores taint y toleration para limitar los pods que pueden programarse en nodos.
Dar prioridad a los pods para ejecutarse en determinados nodos con los selectores de nodo o la afinidad de
nodo.
Dividir o agrupar pods con afinidad o falta de afinidad entre pods.
Proporcionar nodos dedicados con taints y tolerations

Guía de procedimientos recomendados:
Limite el acceso a aplicaciones que consumen muchos recursos, como los controladores de entrada, a nodos
específicos. Mantenga recursos de nodo disponibles para las cargas de trabajo que los necesite y no permita
la programación de otras cargas de trabajo en los nodos.
Al crear el clúster de AKS, puede implementar los nodos con compatibilidad con GPU o un gran número de CPU
eficaces. Puede usar estos nodos para cargas de trabajo de procesamiento de datos grandes, como el
aprendizaje automático o la inteligencia artificial.
Como este hardware de recurso de nodo suele ser costoso para implementar, limite las cargas de trabajo que se
pueden programar en esos nodos. En su lugar, puede dedicar algunos nodos del clúster a ejecutar servicios de
entrada y evitar otras cargas de trabajo.
Esta compatibilidad para distintos nodos se proporciona mediante el uso de varios grupos de nodos. Un clúster
de AKS proporciona uno o varios grupos de nodos.
El programador de Kubernetes utiliza valores taint y toleration para limitar las cargas de trabajo que se pueden
ejecutar en los nodos.
Aplique un valor taint a un nodo para indicar que solo se pueden programar determinados pods en él.
A continuación, aplique un valor toleration a un pod, lo que le permite tolerar el taint de un nodo.
Al implementar un pod en un clúster de AKS, Kubernetes programa solo pods en nodos donde un valor taint se
alinea con un valor toleration. Por ejemplo, suponga que agregó un grupo de nodos en el clúster de AKS para
nodos con compatibilidad con GPU. Define el nombre (por ejemplo, gpu) y, a continuación, un valor para la
programación. Al establecer este valor en NoSchedule, se impide que el programador de Kubernetes programe
pods con el valor toleration indefinido en el nodo.
az aks nodepool add \
--cluster-name myAKSCluster \
--name taintnp \
--node-taints sku=gpu:NoSchedule \
--no-wait
Una vez aplicado un valor taint a los nodos del grupo de nodos, puede definir un valor toleration en la
especificación del pod que permite la programación en los nodos. En el ejemplo siguiente se define sku: gpu y
effect: NoSchedule para tolerar el valor taint aplicado al grupo de nodos en el paso anterior:
kind: Pod
apiVersion: v1
metadata:
name: tf-mnist
spec:
containers:
- name: tf-mnist
image: mcr.microsoft.com/azuredocs/samples-tf-mnist-demo:gpu
resources:
requests:
cpu: 0.5
memory: 2Gi
limits:
cpu: 4.0
memory: 16Gi
tolerations:
- key: "sku"
operator: "Equal"
value: "gpu"
effect: "NoSchedule"
Cuando se implemente este pod mediante kubectl apply -f gpu-toleration.yaml , Kubernetes puede programar
correctamente el pod en los nodos donde se ha aplicado el valor taint. Este aislamiento lógico le permite
controlar el acceso a los recursos dentro de un clúster.
Al aplicar valores taint, el trabajo con los desarrolladores y propietarios de su aplicación les permite definir las
tolerancias necesarias en sus implementaciones.
Para obtener más información sobre cómo usar varios grupos de nodos en AKS, consulte Creación y
administración de varios grupos de nodos para un clúster en AKS.
Comportamiento de taints y tolerations en AKS
Al actualizar un grupo de nodos en AKS, taints y tolerations siguen un patrón de conjunto a medida que se
aplican a los nuevos nodos:
Clústeres predeterminados que utilizan conjuntos de escalado de máquinas virtuales
Puede agregar un valor taint a un grupo de nodos desde la API de AKS para que los nuevos nodos que se
escalen horizontalmente reciban los valores taint de nodo especificados por la API.
Supongamos que:
1. Comienza con un clúster de dos nodos: node1 y node2.
2. Actualice el grupo de nodos.
3. Se crean dos nodos adicionales, node3 y node4.
4. Se pasan los valores taint respectivamente.
5. Las versiones originales de node1 y node2 se eliminan.
Clústeres sin compatibilidad con conjuntos de escalado de máquinas virtuales
Una vez más, supongamos que:
1. Tiene un clúster de dos nodos: node1 y node2.
2. Actualiza el grupo de nodos.
3. Se crea un nodo adicional: node3.
4. Los valores taint de node1 se aplican a node3.
5. node1 se elimina.
6. Se crea un nuevo node1 para reemplazar al nodo original node1.
7. Los valores taint de node2 se aplican al nuevo node1.
8. node2 se elimina.
Básicamente, node1 se convierte en node3 y node2 se convierte en el nuevo node1.
Al escalar un grupo de nodos en AKS, los valores taints y tolerations no se transfieren mediante el diseño.
Control de la programación del pod mediante selectores de nodo y

afinidad
Controle la programación de pods en nodos mediante selectores de nodo, la afinidad de nodo y la afinidad
entre nodos. Esta configuración permite que el programador de Kubernetes aísle lógicamente las cargas de
trabajo, como el hardware en el nodo.
Los valores taint y toleration aíslan lógicamente los recursos con un límite máximo. Si el pod no tolera el valor
taint de un nodo, no se programa en el nodo.
Como alternativa, puede usar selectores de nodo. Por ejemplo, etiqueta los nodos para indicar el
almacenamiento SSD adjunto localmente o una gran cantidad de memoria y, luego, define en la especificación
del pod un selector de nodo. Kubernetes programa los pods en un nodo coincidente.
A diferencia de las tolerancias, los pods sin un selector de nodo coincidente aún pueden programarse en nodos
etiquetados. Este comportamiento permite que los recursos no utilizados en los nodos se consuman, pero da
prioridad a los pods que definen el selector de nodo correspondiente.
Veamos un ejemplo de nodos con una gran cantidad de memoria. Estos nodos pueden dar preferencia a los
pods que solicitan una gran cantidad de memoria. Para asegurarse de que los recursos no estén inactivos,
también permiten que se ejecuten otros pods. El siguiente comando de ejemplo agrega un grupo de nodos con
la etiqueta hardware=highmem a myAKSCluster en myResourceGroup. Todos los nodos de ese grupo de nodos
tendrán esta etiqueta.

--name labelnp \
--node-count 1 \
--labels hardware=highmem \
--no-wait
Una especificación de pod, a continuación, agrega la propiedad nodeSelector para definir un selector de nodo
que coincide con la etiqueta configurada en un nodo:
kind: Pod
apiVersion: v1
metadata:
name: tf-mnist
spec:
containers:
- name: tf-mnist
resources:
requests:
cpu: 0.5
memory: 2Gi
limits:
cpu: 4.0
memory: 16Gi
nodeSelector:
hardware: highmem
Cuando utilice estas opciones del programador, trabaje con los desarrolladores y propietarios de las
aplicaciones para permitirles definir correctamente sus especificaciones de pods.
Para obtener más información sobre el uso de selectores de nodo, vea Assigning Pods to Nodes (Asignación de
pods a nodos).
Afinidad de nodos
Un selector de nodos es una solución básica para asignar pods a un nodo determinado. La afinidad de nodo
proporciona más flexibilidad, lo que le permite definir lo que sucede si el pod no puede coincidir con un nodo.
Puede:
Exigir que el programador de Kubernetes coincida con un pod con un host etiquetado. O bien,
Preferir una coincidencia, pero permitir que el pod se programe en un host diferente si no hay coincidencias
disponibles.
En el ejemplo siguiente se establece la afinidad de nodo en requiredDuringSchedulingIgnoredDuringExecution.
Esta afinidad requiere que la programación de Kubernetes utilice un nodo con una etiqueta coincidente. Si
ningún nodo está disponible, el pod tiene que esperar una programación para continuar. Para permitir que el
pod se programe en un nodo diferente, puede establecer el valor en preferred
DuringSchedulingIgnoreDuringExecution:
kind: Pod
apiVersion: v1
metadata:
name: tf-mnist
spec:
containers:
- name: tf-mnist
resources:
requests:
cpu: 0.5
memory: 2Gi
limits:
cpu: 4.0
memory: 16Gi
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: hardware
operator: In
values: highmem
La parte IgnoredDuringExecution de la configuración indica que, si cambian las etiquetas del nodo, el pod no
debe expulsarse del nodo. El programador de Kubernetes usa solo las etiquetas de nodo actualizadas para los
nuevos pods que se programan, no para los pods que ya están programados en los nodos.
Para obtener más información, consulte Affinity and anti-affinity (Afinidad y falta de afinidad).
Afinidad y falta de afinidad entre pods
Un último enfoque para que el programador de Kubernetes aísle lógicamente las cargas de trabajo es usar la
afinidad o la falta de afinidad entre pods. Esta configuración define si los pods deben o no deben estar
programados en un nodo que tenga un pod coincidente existente. De forma predeterminada, el programador de
Kubernetes intenta programar varios pods en un conjunto de réplica entre nodos. Puede definir reglas más
específicas sobre este comportamiento.
Por ejemplo, tiene una aplicación web que también usa una instancia de Azure Cache for Redis.
1. Usa reglas de falta de afinidad de pods para solicitar que el programador de Kubernetes distribuya réplicas
entre nodos.
2. Usa las reglas de afinidad para asegurarse de que cada componente de aplicación web se programe en el
mismo host como una caché correspondiente.
La distribución de pods en todos los nodos es similar al ejemplo siguiente:
N O DO 1 N O DO 2 N O DO 3
aplicación web-1 aplicación web-2 aplicación web-3
caché-1 caché-2 caché-3
La afinidad entre pods y la antiafinidad proporcionan una implementación más compleja que los selectores de
nodo o la afinidad de nodo. Con la implementación, aislará lógicamente los recursos y controlará cómo
Kubernetes programa pods en los nodos.
Para obtener un ejemplo completo de esta aplicación web con el ejemplo de la instancia de Azure Redis Cache,
consulte Colocación de pods en el mismo nodo.
Pasos siguientes
Este artículo se ha centrado en las características avanzadas del programador de Kubernetes. Para obtener más
información acerca de las operaciones de clúster en AKS, consulte los siguientes procedimientos recomendados:
Procedimientos recomendados para la
autenticación y autorización en Azure Kubernetes
Service (AKS)
A medida que implementa y mantiene clústeres en Azure Kubernetes Service (AKS), deberá implementar
maneras de administrar el acceso a los recursos y servicios. Sin estos controles:
Las cuentas podrían tener acceso a recursos y servicios innecesarios.
Se dificulta el seguimiento del conjunto de credenciales que se usaron para los cambios.
Este artículo de procedimientos recomendados se centra en cómo un operador de clústeres puede administrar
el acceso y la identidad de los clústeres de AKS. En este artículo aprenderá a:
Autenticar a los usuarios de clústeres de AKS con Azure Active Directory.
Controlar el acceso a los recursos con el control de acceso basado en roles de Kubernetes (RBAC de
Kubernetes).
Usar RBAC de Azure para controlar en detalle el acceso al recurso de AKS, a Kubernetes API a escala y a
kubeconfig .
Usar una identidad administrada para autenticar los pods con otros servicios.
Uso de Azure Active Directory (Azure AD)

Implementación de clústeres de AKS con integración de Azure AD. Mediante Azure AD se centraliza el
componente de administración de identidades. Cualquier cambio en el estado del grupo o cuenta del
usuario se actualiza automáticamente al acceder al clúster de AKS. Establezca el ámbito de los usuarios o
grupos en la cantidad mínima de permisos mediante roles, ClusterRoles o enlaces.
Los desarrolladores del clúster de Kubernetes y propietarios de aplicaciones necesitan acceder a diferentes
recursos. Kubernetes carece de una solución de administración de identidades para controlar los recursos con
los que los usuarios pueden interactuar. En su lugar, el usuario suele integrar el clúster con una solución de
identidades existente. Introduzca Azure AD: una solución de administración de identidades para el ámbito
empresarial que se integra con los clústeres de AKS.
Con los clústeres integrados con Azure AD en AKS, podrá crear roles o ClusterRoles que definan los permisos de
acceso a los recursos. A continuación, enlaza los roles a usuarios o grupos de Azure AD. Más información sobre
estos RBAC de Kubernetes en la sección siguiente. En el diagrama siguiente se muestran la integración de
Azure AD y la forma de controlar el acceso a los recursos:
1. El desarrollador se autentica con Azure AD.
2. El punto de conexión de emisión de tokens de Azure AD emite el token de acceso.
3. El desarrollador realiza una acción con el token de Azure AD, como kubectl create pod .
4. Kubernetes valida el token con Azure AD y recupera las pertenencias a grupos del desarrollador.
5. Se aplican las directivas del clúster y de RBAC de Kubernetes.
6. La solicitud del desarrollador es correcta en función de la validación anterior de pertenencia a grupos de
Azure AD, y las directivas y RBAC de Kubernetes.
Para crear un clúster de AKS que use Azure AD, consulte Integración de Azure Active Directory con AKS.
Uso del control de acceso basado en roles de Kubernetes (RBAC de

Kubernetes)
Defina permisos de usuario o grupo para agrupar recursos con RBAC de Kubernetes. Cree roles y enlaces
que asignen la mínima cantidad de permisos necesarios. Use la integración de Azure AD para actualizar
automáticamente cualquier cambio de estado de usuario o pertenencia a grupos y mantener el acceso a los
recursos del clúster actual.
En Kubernetes se proporciona control de acceso pormenorizado a los recursos del clúster. Los permisos se
definen en el nivel de clúster, así como en espacios de nombres específicos. Determine qué recursos se pueden
administrar y con qué permisos. A continuación, aplique estos roles a los usuarios o grupos con un enlace. Para
obtener más información sobre los roles, ClusterRoles y enlaces, consulte Opciones de acceso e identidad en
Azure Kubernetes Service (AKS).
Por ejemplo, puede crear un rol con acceso total a los recursos del espacio de nombres denominado finance-
app, tal y como se muestra en el siguiente ejemplo de manifiesto de YAML:
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: finance-app-full-access-role
namespace: finance-app
rules:
- apiGroups: [""]
resources: ["*"]
verbs: ["*"]
A continuación, cree un elemento RoleBinding y enlace el usuario de Azure AD developer1@contoso.com con

RoleBinding, como se muestra en el siguiente manifiesto de YAML:
kind: RoleBinding
metadata:
name: finance-app-full-access-role-binding
namespace: finance-app
subjects:
- kind: User
name: developer1@contoso.com
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: finance-app-full-access-role
Cuando developer1@contoso.com se autentica en el clúster de AKS, se tienen los permisos completos sobre los
recursos en el espacio de nombres finance-app. De esta forma, separa y controla el acceso a los recursos de
forma lógica. Use RBAC de Kubernetes junto con la integración de Azure AD.
Para ver cómo usar los grupos de Azure AD para controlar el acceso a los recursos de Kubernetes mediante
RBAC de Kubernetes, consulte Administración del acceso a recursos de clúster mediante el control de acceso
basado en roles y las identidades de Azure Active Directory en Azure Kubernetes Service.
Uso de Azure RBAC

Use RBAC de Azure para definir los permisos mínimos de los usuarios o grupos de los recursos de AKS en
una o más suscripciones.
Hay dos niveles de acceso necesarios para operar completamente un clúster de AKS:
1. Acceda al recurso de AKS en la suscripción de Azure.
Este nivel de acceso permite:
Controlar el escalado o la actualización del clúster mediante las API de AKS.
Extraer kubeconfig .
Para ver cómo controlar el acceso al recurso de AKS y a kubeconfig , consulte Limitación del acceso al
archivo de configuración del clúster.
2. Acceso al API de Kubernetes.
Este nivel de acceso se controla mediante:
RBAC de Kubernetes (tradicionalmente), o bien,
mediante la integración de RBAC de Azure con AKS para la autorización de Kubernetes.
Para ver cómo conceder permisos pormenorizados a Kubernetes API con RBAC de Azure, consulte Uso de
RBAC de Azure para la autorización de Kubernetes.
Uso de identidades administradas de pod

No use credenciales fijas dentro de pods o imágenes de contenedor, ya que corren riesgo de exposición o
abuso. En su lugar, use identidades de pod para solicitar acceso automáticamente mediante una solución
central de identidades de Azure AD.
NOTE
Las identidades de pod están pensadas para su uso únicamente con pods de Linux y las imágenes de contenedor. La
compatibilidad de las identidades administradas de pod con los contenedores de Windows va a estar disponible
próximamente.
Para acceder a otros servicios de Azure, como Cosmos DB, Key Vault o Blob Storage, el pod necesita credenciales
de acceso. Puede definir las credenciales de acceso con la imagen de contenedor o insertarlas como secreto de
Kubernetes. En cualquier caso, tendría que crearlas y asignarlas manualmente. A menudo, las credenciales se
reutilizan en los pods y no se rotan de forma periódica.
Con las identidades administradas de pod para los recursos de Azure, podrá solicitar acceso automáticamente a
los servicios por medio de Azure AD. Las identidades administradas de pod están actualmente en versión
preliminar para AKS. Consulte la documentación de [Uso de identidades administradas del pod de Azure Active
Directory en Azure Kubernetes Service (versión preliminar)] (https://docs.microsoft.com/azure/aks/use-azure-
ad-pod-identity) ) para comenzar.
En lugar de definir manualmente las credenciales de los pods, las identidades administradas por pods solicitan
un token de acceso en tiempo real y lo usan para acceder solo a sus servicios asignados. En AKS hay dos
componentes que controlan las operaciones para permitir que los pods usen identidades administradas:
El ser vidor de identidad de administración de nodos (NMI) es un pod que se ejecuta como
DaemonSet en cada nodo del clúster de AKS. El servidor de NMI escucha las solicitudes de pods para
servicios de Azure.
El proveedor de recursos de Azure consulta al servidor de API de Kubernetes y busca una asignación de
identidad de Azure que corresponda a un pod.
Cuando los pods solicitan acceso a un servicio de Azure, las reglas de red redirigen el tráfico al servidor NMI.
1. El servidor NMI:
Identifica los pods que solicitan acceso a los servicios de Azure en función de su dirección remota.
Consulta al proveedor de recursos de Azure.
2. El proveedor de recursos de Azure las asignaciones de identidad de Azure en el clúster de AKS.
3. El servidor NMI solicita un token de acceso de Azure AD en función de la asignación de identidad del pod.
4. Azure AD proporciona acceso al servidor de NMI, que se devuelve al pod.
El pod puede usar este token de acceso para, después, solicitar acceso a los servicios de Azure.
En el ejemplo siguiente, un desarrollador crea un pod que usa una identidad administrada para solicitar acceso a
Azure SQL Database:
1. El operador de los clústeres crea una cuenta de servicio para asignar identidades cuando los pods solicitan
acceso a los servicios.
2. El servidor de NMI se implementa para retransmitir las solicitudes de los pods, y del proveedor de recursos
de Azure, de tokens de acceso a Azure AD.
3. Un desarrollador implementa un pod con una identidad administrada que solicita un token de acceso a
través del servidor de NMI.
4. El token se devuelve al pod y se utiliza para obtener acceso a Azure SQL Database.
NOTE
Las identidades administradas de pod están actualmente en estado de versión preliminar.
Para usar identidades administradas de pod, vea Uso de identidades administradas del pod de Azure Active
Directory en Azure Kubernetes Service (versión preliminar).
Pasos siguientes
Este artículo de procedimientos recomendados se centra en la autenticación y autorización para el clúster y los
recursos. Para implementar algunos de estos procedimientos recomendados, consulte los artículos siguientes:
Integración de Azure Active Directory con AKS
Uso de identidades administradas del pod de Azure Active Directory en Azure Kubernetes Service (versión
preliminar)
Para obtener más información acerca de las operaciones de clúster en AKS, consulte los siguientes
procedimientos recomendados:
Procedimientos recomendados para administrar la
seguridad y las actualizaciones de los clústeres en
A medida que administra los clústeres en Azure Kubernetes Service (AKS), es clave considerar la seguridad de
los datos y de las cargas de trabajo. Cuando ejecuta clústeres multiinquilino con aislamiento lógico, debe
proteger especialmente el acceso a los recursos y a las cargas de trabajo. Minimice el riesgo de ataque mediante
la aplicación de las actualizaciones de seguridad más recientes de Kubernetes y del sistema operativo del nodo.
En este artículo se indica cómo proteger el clúster de AKS. Aprenderá a:
Usar Azure Active Directory y el control de acceso basado en rol de Kubernetes (RBAC de Kubernetes) para
proteger el acceso al servidor de API.
Proteger el acceso del contenedor a los recursos del nodo.
Actualizar un clúster de AKS a la última versión de Kubernetes.
Mantener actualizados los nodos y aplicar automáticamente los parches de seguridad.
También puede leer las prácticas recomendadas para la administración de imágenes de contenedor y para
seguridad de pod.
También puede usar la integración de Azure Kubernetes Services con Security Center para ayudar a detectar
amenazas y ver recomendaciones para proteger los clústeres de AKS.
Proteger el acceso a los nodos del clúster y al servidor de API

Una de las formas más importantes de proteger el clúster es proteger el acceso al servidor de API de
Kubernetes. Integre el control de acceso basado en rol de Kubernetes con Azure Active Directory para
controlar el acceso al servidor de API. Con estos controles puede proteger AKS del mismo modo que
protege el acceso a las suscripciones a Azure.
El servidor de API de Kubernetes proporciona un punto de conexión único para las solicitudes para realizar
acciones dentro de un clúster. Para proteger y auditar el acceso al servidor de API, limite el acceso y proporcione
los niveles de permiso más bajos posibles. Aunque este enfoque no es exclusivo de Kubernetes, es
especialmente importante cuando ha aislado lógicamente el clúster de AKS para el uso multiinquilino.
Azure AD proporciona una solución de administración de identidades para el ámbito empresarial que se puede
integrar con los clústeres de AKS. Dado que Kubernetes no proporciona una solución de administración de
identidades, es posible que se sienta obligado a restringir de forma individual el acceso al servidor de API. Con
los clústeres integrados con Azure AD en AKS, usted utiliza sus cuentas de usuario y de grupo existentes para
autenticar a los usuarios en el servidor de API.
Mediante la integración del control de acceso basado en rol de Kubernetes y Azure AD, puede proteger el
servidor de API y proporcionar los permisos mínimos necesarios para un conjunto de recursos con ámbito
como, por ejemplo, un espacio de nombres único. Puede conceder a diferentes usuarios o grupos de Azure AD
diferentes roles de Kubernetes. Con permisos específicos puede restringir el acceso al servidor de API y
proporcionar una pista de auditoría clara de las acciones realizadas.
El procedimiento recomendado consiste en utilizar grupos para proporcionar acceso a archivos y carpetas en
lugar de identidades individuales. Por ejemplo, utilizar una pertenencia a un grupo de Azure AD para enlazar
usuarios a roles de Kubernetes en lugar de usuarios individuales. A medida que cambie la pertenencia al grupo
de un usuario, también lo harán sus permisos de acceso en el clúster de AKS.
Mientras tanto, supongamos que enlaza al usuario individual directamente a un rol y su función de trabajo
cambia. Aunque las pertenencias al grupo de Azure AD se actualizarán, sus permisos en el clúster de AKS no lo
harán. En este escenario, el usuario al final cuenta con más permisos de los que necesita.
Para más información sobre la integración de Azure AD, RBAC de Kubernetes y Azure RBAC, consulte los
procedimientos recomendados para la autenticación y autorización en AKS.
Proteger el acceso del contenedor a los recursos

Limite el acceso a las acciones que los contenedores pueden realizar. Proporcione el menor número de
permisos y evite el uso del acceso a raíz y la elevación de privilegios.
Por el mismo motivo que debería conceder a los usuarios o a los grupos el menor número de privilegios
necesarios, también debería limitar los contenedores a solo las acciones y procesos necesarios. Para minimizar
el riesgo de ataques, evite configurar las aplicaciones y los contenedores que requieren elevación de privilegios
o acceso a raíz.
Por ejemplo, establezca allowPrivilegeEscalation: false en el manifiesto de pod. Estos contextos de seguridad
de pod integrados en Kubernetes le permiten definir permisos adicionales, como el usuario o grupo como el
que se ejecutará, o qué funcionalidades de Linux se expondrán. Para más recomendaciones, consulte Protección
del acceso del pod a los recursos.
Para un control aún más detallado de las acciones de los contenedores, también puede usar las características
de seguridad incorporadas de Linux como AppArmor y seccomp.
1. Defina las características de seguridad de Linux en el nivel de nodo.
2. Implemente las características mediante un manifiesto de pod.
Las características de seguridad integradas de Linux solo están disponibles en los pods y los nodos de Linux.
NOTE
Actualmente, los entornos de Kubernetes no están completamente seguros ante el uso de varios inquilinos hostiles. Las
características de seguridad adicionales, como AppArmor, seccomp, las directivas de seguridad de pods o el control de
acceso basado en rol de Kubernetes para los nodos, bloquean eficazmente las vulnerabilidades de seguridad.
Para una verdadera seguridad al ejecutar cargas de trabajo multiinquilino hostiles, solo debe confiar en un hipervisor. El
dominio de seguridad de Kubernetes se convierte en todo el clúster, no en un nodo específico.
En el caso de estos tipos de cargas de trabajo multiinquilino hostiles, debe usar clústeres que estén físicamente aislados.
AppArmor
Para limitar las acciones de los contenedores, puede usar el módulo de seguridad del kernel de Linux
denominado AppArmor. AppArmor está disponible como parte del SO del nodo de AKS subyacente del sistema
operativo y está habilitado de forma predeterminada. Puede crear perfiles de AppArmor para restringir acciones
como leer, escribir o ejecutar, o funciones del sistema como montar sistemas de archivos. Los perfiles de
AppArmor predeterminados restringen el acceso a diferentes ubicaciones de /proc y /sys , y proporcionan un
medio para aislar lógicamente los contenedores desde el nodo subyacente. AppArmor funciona para cualquier
aplicación que se ejecuta en Linux, no solo para los pods de Kubernetes.
Para ver AppArmor en acción, en el ejemplo siguiente se crea un perfil que impide la escritura en archivos.
1. Acceda mediante SSH a un nodo de AKS.
2. Cree un archivo denominado deny-write.profile.
3. Pegue el siguiente contenido:
#include <tunables/global>
profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
#include <abstractions/base>
file,
# Deny all file writes.
deny /** w,
}
Los perfiles de AppArmor se agregan con el comando apparmor_parser .

1. Agregue el perfil a AppArmor.
2. Especifique el nombre del perfil creado en el paso anterior:
sudo apparmor_parser deny-write.profile

Si el perfil se analiza y se aplica correctamente a AppArmor, no verá ninguna salida y se le devolverá al
símbolo del sistema.
3. Desde la máquina local, cree un manifiesto de pod denominado aks-apparmor.yaml. Este manifiesto:
Define una anotación para container.apparmor.security.beta.kubernetes .
Hace referencia al perfil deny-write creado en los pasos anteriores.
apiVersion: v1
kind: Pod
metadata:
name: hello-apparmor
annotations:
container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write
spec:
containers:
- name: hello
image: mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
4. Con el pod implementado, compruebe que el pod hello-apparmor aparece bloqueado:
$ kubectl get pods

aks-ssh 1/1 Running 0 4m2s
hello-apparmor 0/1 Blocked 0 50s
Para más información sobre AppArmor, consulte los perfiles de AppArmor en Kubernetes.
Informática segura
Si bien AppArmor funciona con cualquier aplicación de Linux, seccomp (sec ure comp uting) funciona en el nivel
de proceso. Seccomp también es un módulo de seguridad del kernel de Linux, y es compatible de forma nativa
con el tiempo de ejecución de Docker que utilizan los nodos de AKS. Con seccomp, puede limitar las llamadas de
proceso de contenedor. Adopte el procedimiento recomendado de conceder al contenedor el permiso mínimo
solo para ejecutarlo mediante:
La definición que filtra qué acciones se permiten o deniegan.
La anotación dentro de un manifiesto YAML de pod para asociarlo al filtro de seccomp.
Para ver seccomp en acción, cree un filtro que evite el cambio de permisos en un archivo.
1. Acceda mediante SSH a un nodo de AKS.
2. Cree un filtro de seccomp denominado /var/lib/kubelet/seccomp/prevent-chmod.
3. Pegue el siguiente contenido:
{
"defaultAction": "SCMP_ACT_ALLOW",
"syscalls": [
{
"name": "chmod",
"action": "SCMP_ACT_ERRNO"
},
{
"name": "fchmodat",
},
{
"name": "chmodat",
}
]
}
En la versión 1.19 y versiones posteriores, debe configurar lo siguiente:
{
"defaultAction": "SCMP_ACT_ALLOW",
"syscalls": [
{
"names": ["chmod","fchmodat","chmodat"],
}
]
}
4. En la máquina local, cree un manifiesto de pod denominado aks-seccomp.yaml y pegue el contenido

siguiente. Este manifiesto:
Define una anotación para seccomp.security.alpha.kubernetes.io .
Hace referencia al filtro prevent-chmod que se creó en el paso anterior.
apiVersion: v1
kind: Pod
metadata:
name: chmod-prevented
annotations:
seccomp.security.alpha.kubernetes.io/pod: localhost/prevent-chmod
spec:
containers:
- name: chmod
command:
- "chmod"
args:
- "777"
- /etc/hostname
restartPolicy: Never
En la versión 1.19 y versiones posteriores, debe configurar lo siguiente:

apiVersion: v1
kind: Pod
metadata:
name: chmod-prevented
spec:
securityContext:
seccompProfile:
type: Localhost
localhostProfile: prevent-chmod
containers:
- name: chmod
command:
- "chmod"
args:
- "777"
- /etc/hostname
restartPolicy: Never
5. Implemente el pod de ejemplo con el comando kubectl apply:
kubectl apply -f ./aks-seccomp.yaml
6. Consulte el estado de los pod mediante el comando kubectl get pods.

El pod indica un error.
El filtro seccomp impide que se ejecute el comando chmod , tal como se muestra en la salida del
ejemplo siguiente:
$ kubectl get pods

chmod-prevented 0/1 Error 0 7s
Para más información sobre los filtros disponibles, consulte Perfiles de seguridad de Seccomp para Docker.
Actualización regular a la versión más reciente de Kubernetes

Para mantenerse al día con las nuevas características y correcciones de errores, actualice regularmente la
versión de Kubernetes en el clúster de AKS.
Kubernetes presenta nuevas características a un ritmo más rápido que otras plataformas de infraestructura más
tradicionales. Las actualizaciones de Kubernetes incluyen:
Nuevas características
Correcciones de errores o de seguridad
Las nuevas características normalmente pasan al estado alfa y beta antes de convertirse en estables. Una vez
que son estables, están disponibles con carácter general y se recomiendan para su uso en producción. Este
nuevo ciclo de versión de actualización de características debería permitirle actualizar Kubernetes sin encontrar
normalmente cambios importantes ni tener que ajustar las implementaciones ni las plantillas.
AKS es compatible con tres versiones secundarias de Kubernetes. Cuando se introduce una nueva versión
secundaria de revisión, se retiran la versión secundaria y la versión de revisión compatibles más antiguas. Las
actualizaciones secundarias de Kubernetes se realizan periódicamente. Para poder disponer de soporte técnico,
asegúrese de que tiene un proceso de gobernanza para comprobar si hay actualizaciones necesarias. Para más
información, consulte Versiones de Kubernetes compatibles en Azure Kubernetes Service (AKS).
Para comprobar las versiones que están disponibles para el clúster, use el comando az aks get-upgrades tal
como se muestra en el ejemplo siguiente:
A continuación, puede actualizar el clúster de AKS con el comando az aks upgrade. De forma segura, el proceso
de actualización:
Acordona y purga un nodo cada vez.
Programa pods en los nodos restantes.
Implementa un nuevo nodo que ejecuta las versiones más recientes del sistema operativo y Kubernetes.
IMPORTANT
Pruebe las nuevas versiones secundarias en un entorno de desarrollo y pruebas, y compruebe que la carga de trabajo
funciona correctamente con la nueva versión de Kubernetes.
Kubernetes puede poner en desuso las API (como en la versión 1.16) en las que se basan las cargas de trabajo. Al
incorporar nuevas versiones en producción, considere la posibilidad de usar varios grupos de nodos en versiones
independientes y actualizar grupos individuales de uno en uno para implementar progresivamente la actualización en un
clúster. Si se ejecutan varios clústeres, actualice un clúster cada vez para supervisar progresivamente el impacto o los
cambios.
az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version

KUBERNETES_VERSION
Para obtener más información sobre las actualizaciones de AKS, consulte Versiones de Kubernetes compatibles
en Azure Kubernetes Service (AKS) y Actualización de un clúster de AKS.
Proceso de las actualizaciones y reinicios de nodos Linux con kured

Aunque AKS descarga e instala automáticamente correcciones de seguridad en cada uno de los nodos Linux,
no se reinicia automáticamente.
1. Use kured para ver si hay reinicios pendientes.
2. Acordone y purgue el nodo de forma segura para permitir que el nodo se reinicie.
3. Aplique las actualizaciones.
4. Mantenga la mayor seguridad posible con respecto al sistema operativo.
Para los nodos de Windows Server, realice periódicamente una operación de actualización de AKS para
acordonar y drenar los pods de forma segura, e implemente los nodos actualizados.
Cada noche, los nodos Linux de AKS obtienen las actualizaciones de seguridad a través de su canal de
actualización de distribuciones. Este comportamiento se configura automáticamente cuando se implementan los
nodos en un clúster de AKS. Para minimizar las interrupciones y el posible impacto sobre las cargas de trabajo
en ejecución, los nodos no se reinician automáticamente si lo requiere una revisión de seguridad o una
actualización de kernel.
El proyecto kured (KUbernetes REboot Daemon) de código abierto de Weaveworks vigila los reinicios
pendientes del nodo. Cuando un nodo Linux aplica actualizaciones que requieren un reinicio, el nodo se
acordona y se drena de forma segura para mover y programar los pods en otros nodos del clúster. Una vez que
se reinicia el nodo, se vuelve a agregar al clúster y Kubernetes vuelve a reanudar la programación de pods. Para
minimizar las interrupciones, solo se permite que kured reinicie un único nodo a la vez.
Si desea un control aún más estrecho sobre los reinicios, kured puede integrarse con Prometheus para evitar
reinicios si hay otros eventos de mantenimiento o problemas de clúster en curso. Esta integración reduce las
complicaciones al reiniciar los nodos mientras está solucionando activamente otros problemas.
Para más información sobre cómo controlar los inicios del nodo, consulte Aplicación de actualizaciones de
kernel y de seguridad en los nodos en AKS.
Pasos siguientes
En este artículo se indica cómo proteger el clúster de AKS. Para implementar algunas de estas áreas, consulte los
artículos siguientes:
Integración de Azure Active Directory con AKS
Actualización de un clúster AKS a la última versión de Kubernetes
Procesamiento de actualizaciones de seguridad y reinicios del nodo con kured
Procedimientos recomendados para la
administración y la protección de las imágenes de
contenedor en Azure Kubernetes Service (AKS)
La seguridad de los contenedores y de las imágenes de contenedor es una prioridad importante a la hora de
desarrollar y ejecutar aplicaciones en Azure Kubernetes Service (AKS). Los contenedores que incluyen imágenes
base obsoletas o entornos de ejecución de aplicaciones sin revisar suponen un riesgo para la seguridad y un
posible vector de ataque.
Minimice los riesgos mediante la integración y ejecución de herramientas de análisis y corrección en los
contenedores en tiempo de compilación y ejecución. Cuanto antes se detecte la vulnerabilidad o la imagen base
obsoleta, más seguro será el clúster.
En este artículo, "contenedores" significa lo siguiente:
Las imágenes de contenedor almacenadas en un registro de contenedor.
Los contenedores en ejecución.
En este artículo se indica cómo proteger los contenedores de AKS. Aprenderá a:
Buscar y corregir vulnerabilidades de la imagen.
Desencadenar automáticamente y volver a implementar imágenes de contenedor cuando se actualiza una
imagen base.
También puede leer los procedimientos recomendados para la seguridad del clúster y la seguridad de pod.
También puede usar la seguridad de contenedor de Security Center para facilitar el análisis de los contenedores
en busca de vulnerabilidades. La integración de Azure Container Registry con Security Center ayuda a proteger
las imágenes y el Registro de vulnerabilidades.
Proteger las imágenes y el tiempo de ejecución

Examine las imágenes de contenedor para detectar vulnerabilidades. Implemente solo imágenes validadas.
Actualice periódicamente las imágenes base y el entorno de ejecución de la aplicación. Vuelva a
implementar las cargas de trabajo en el clúster de AKS.
Al adoptar cargas de trabajo basadas en contenedores, querrá comprobar la seguridad de las imágenes y el
entorno de ejecución usados para compilar sus propias aplicaciones. ¿Cómo evitar introducir vulnerabilidades
de seguridad en las implementaciones?
Incluya un proceso para examinar imágenes de contenedor mediante herramientas como Twistlock o Aqua
en su flujo de trabajo de implementación.
Permitir solo la implementación de imágenes comprobadas.
Por ejemplo, puede usar una integración continua y una canalización de implementación continua (CI/CD) para
automatizar el análisis, la comprobación y la implementación de imágenes. Azure Container Registry incluye
estas funcionalidades de análisis de vulnerabilidades.
Compilar automáticamente nuevas imágenes en la actualización de

imagen base
Si usa imágenes base para las imágenes de la aplicación, use la automatización para crear nuevas imágenes
cuando actualice la imagen base. Puesto que las imágenes base actualizadas suelen incluir correcciones de
seguridad, actualice todas las imágenes de contenedor de aplicación de nivel inferior.
Cada vez que se actualice una imagen base, también se deben actualizar las imágenes de contenedor de nivel
inferior. Integre este proceso de compilación en las canalizaciones de validación e implementación, como Azure
Pipelines o Jenkins. Estas canalizaciones aseguran que sus aplicaciones siguen ejecutándose en las imágenes
base actualizadas. Una vez que se validan las imágenes de contenedor de aplicación, se pueden actualizar las
implementaciones de AKS para ejecutar las imágenes más recientes y seguras.
Azure Container Registry Tasks también puede actualizar automáticamente las imágenes de contenedor cuando
se actualiza la imagen base. Gracias a esta característica, puede crear unas cuantas imágenes base y mantenerlas
actualizadas con correcciones de errores y seguridad.
Para más información sobre las actualizaciones de imagen base, consulte el artículo de Automatización de
compilaciones de imágenes al actualizarse una imagen base con Azure Container Registry Tasks.
Pasos siguientes
En este artículo se indica cómo proteger los contenedores. Para implementar algunas de estas áreas, consulte
los artículos siguientes:
Automatización de compilaciones de imágenes al actualizarse una imagen base con Azure Container Registry
Tasks
Procedimientos recomendados con la conectividad
de red y la seguridad en Azure Kubernetes Service
(AKS)
Al crear y administrar clústeres en Azure Kubernetes Service (AKS), se proporciona conectividad de red para los
nodos y las aplicaciones. Estos recursos de red incluyen los intervalos de direcciones IP, los equilibradores de
carga y los controladores de entrada. Para mantener un servicio de alta calidad para las aplicaciones, debe
elaborar estrategias y configurar estos recursos.
Este artículo de procedimientos recomendados se centra en la conectividad de red y la seguridad para los
operadores del clúster. En este artículo aprenderá a:
Comparar los modos de red kubenet y Azure Container Networking Interface (CNI) en AKS.
Planear la conectividad y el direccionamiento IP necesarios.
Distribuir el tráfico mediante equilibradores de carga, controladores de entrada o un firewall de aplicaciones
web (WAF).
Conectarse de forma segura a los nodos del clúster.
Elección del modelo de red adecuado

Use las redes de Azure CNI en AKS para la integración con redes virtuales existentes o redes locales. Este
modelo de red permite mayor separación de los recursos y los controles en un entorno empresarial.
Las redes virtuales proporcionan conectividad básica para que los nodos de AKS y los clientes accedan a las
aplicaciones. Hay dos maneras diferentes de implementar los clústeres de AKS en redes virtuales:
Redes de CNI de Azure
Se implementan en una red virtual y usan el complemento Azure CNI de Kubernetes. Los pods reciben
direcciones IP individuales que se pueden enrutar a otros servicios de red o recursos locales.
Redes de Kubenet
Azure administra los recursos de red virtual cuando el clúster se implementa y utiliza el complemento
kubenet de Kubernetes.
En las implementaciones de producción, tanto kubenet como Azure CNI son opciones válidas.
Redes de CNI
Azure CNI es un protocolo independiente del proveedor que permite que el entorno de ejecución del
contenedor realice solicitudes a un proveedor de red. Asigna direcciones IP a los nodos y los pods, y
proporciona características de administración de direcciones IP (IPAM) cuando se conecta a redes virtuales de
Azure existentes. Cada recurso de nodo y pod recibe una dirección IP en la red virtual de Azure y no se necesita
más enrutamiento para la comunicación con otros servicios o recursos.
En particular, las redes de Azure CNI para producción permiten separar el control y la administración de los
recursos. Desde una perspectiva de seguridad, se suele preferir que distintos equipos administren y protejan los
recursos. Con las redes de Azure CNI, puede conectarse a recursos de Azure existentes, recursos locales u otros
servicios mediante direcciones IP asignadas a cada pod.
Al usar redes de Azure CNI, el recurso de red virtual se encuentra en un grupo de recursos independiente del
clúster de AKS. Delegue permisos en la identidad de clúster de AKS para acceder y administrar estos recursos. La
identidad de clúster que usa el clúster de AKS debe tener como mínimo permisos de Colaborador de la red en la
subred de la red virtual.
Si quiere definir un rol personalizado en lugar de usar el rol integrado de colaborador de red, se requieren los
permisos siguientes:
Microsoft.Network/virtualNetworks/subnets/read
De manera predeterminada, AKS utiliza una identidad administrada para su identidad de clúster. Sin embargo,
puede usar una entidad de servicio en su lugar. Para más información acerca de:
la delegación en entidad de servicio de AKS, consulte Delegación del acceso a otros recursos de Azure.
las identidades administradas, consulte Uso de identidades administradas.
Como cada pod y cada nodo recibe su propia dirección IP, planee los intervalos de direcciones para las subredes
de AKS. Tenga en cuenta lo siguiente:
La subred debe ser lo suficientemente grande como para proporcionar direcciones IP para cada nodo, pod y
recurso de red que implemente.
Con las redes de kubenet y de Azure CNI, cada nodo que se ejecuta tiene límites predeterminados del
número de pods.
Cada clúster de AKS se debe colocar en su propia subred.
Evite el uso de intervalos de direcciones IP que se superponen con los recursos de red existentes.
Es necesario para permitir la conectividad a redes locales o emparejadas en Azure.
Para controlar los eventos de escalado horizontal o las actualizaciones de clúster, es necesario que haya otras
direcciones IP disponibles en la subred asignada.
Este espacio de direcciones adicional es especialmente importante si usa contenedores de
Windows Server, como aquellos grupos de nodos que requieren una actualización para aplicar las
revisiones de seguridad más recientes. Para obtener más información sobre los nodos de Windows
Server, consulte Actualización de un grupo de nodos en AKS.
Para calcular la dirección IP necesaria, consulte Configuración de redes de Azure CNI en AKS.
Cuando se crea un clúster con redes de Azure CNI, se especifican otros intervalos de direcciones para el clúster,
como la dirección del puente de Docker, la IP del servicio DNS y el intervalo de direcciones de servicio. En
general, asegúrese de que estos intervalos de direcciones:
No se superponen entre sí.
No se superponen con las redes asociadas al clúster, incluidas las redes virtuales, las subredes, las redes
locales y las redes emparejadas.
Para obtener detalles específicos sobre los límites y el tamaño de estos intervalos de direcciones, consulte
Configuración de redes de Azure CNI en AKS.
Redes de kubenet
Aunque las redes de kubenet no requieren configuración de las redes virtuales antes de la implementación del
clúster, existen algunos inconvenientes por la espera:
Puesto que los nodos y pods se colocan en subredes IP diferentes, el enrutamiento definido por el usuario
(UDR) y el reenvío IP enruta el tráfico entre pods y nodos. Este enrutamiento adicional puede reducir el
rendimiento de las redes.
Las conexiones a redes locales existentes o el emparejamiento con otras redes virtuales de Azure pueden ser
complejos.
Dado que no crea la red virtual y las subredes por separado del clúster de AKS, Kubenet es ideal para:
Cargas de trabajo pequeñas de desarrollo o pruebas.
Sitios web sencillos con poco tráfico.
Elevación y desplazamiento de cargas de trabajo a contenedores.
Para la mayoría de las implementaciones de producción, debe planificar y usar redes de Azure CNI.
También puede configurar sus propios intervalos de direcciones IP y redes virtuales con kubenet. De forma
similar a las redes de Azure CNI, estos intervalos de direcciones no deben superponerse entre sí y no deben
superponerse con las redes asociadas al clúster (las redes virtuales, las subredes, las redes locales y las redes
emparejadas).
Para obtener detalles específicos sobre los límites y el tamaño de estos intervalos de direcciones, consulte Uso
de redes kubenet con sus propios intervalos de direcciones IP en AKS.
Distribución del tráfico de entrada

Para distribuir el tráfico HTTP o HTTPS a las aplicaciones, use los recursos y los controladores de entrada. En
comparación con el equilibrador de carga de Azure, los controladores de entrada proporcionan
características adicionales y se pueden administrar como recursos nativos de Kubernetes.
Aunque un equilibrador de carga de Azure puede distribuir el tráfico de cliente a las aplicaciones en el clúster de
AKS, su conocimiento sobre ese tráfico es limitado. Un recurso de equilibrador de carga funciona en la capa 4 y
distribuye el tráfico en función de protocolos o puertos.
La mayoría de las aplicaciones web que usan HTTP o HTTPS deben usar recursos y controladores de entrada de
Kubernetes, que funcionan en la capa 7. En la entrada se puede distribuir el tráfico en función de la dirección
URL de la aplicación y administrar la terminación TLS/SSL. La entrada también reduce el número de direcciones
IP que se exponen y se asignan.
Con un equilibrador de carga, cada aplicación normalmente necesita una dirección IP pública asignada y a ella y
al servicio del clúster de AKS. Con un recurso de entrada, una única dirección IP puede distribuir tráfico a varias
aplicaciones.
En la entrada existen dos componentes:
un recurso de entrada
un controlador de entrada
Recurso de entrada
El recurso de entrada es un manifiesto YAML de kind: Ingress . Define el host, los certificados y las reglas para
enrutar el tráfico a los servicios que se ejecutan en el clúster de AKS.
El siguiente ejemplo de manifiesto de YAML distribuye el tráfico de myapp.com a uno de los dos servicios,
blogservice o storeservice. El cliente se dirige a un servicio o al otro en función de la dirección URL a la que
acceden.
kind: Ingress
metadata:
name: myapp-ingress
annotations: kubernetes.io/ingress.class: "PublicIngress"
spec:
tls:
- hosts:
- myapp.com
secretName: myapp-secret
rules:
- host: myapp.com
http:
paths:
- path: /blog
backend:
serviceName: blogservice
servicePort: 80
- path: /store
backend:
serviceName: storeservice
servicePort: 80
Controlador de entrada
Un controlador de entrada es un demonio que se ejecuta en un nodo de AKS y supervisa las solicitudes
entrantes. A continuación, el tráfico se distribuye según las reglas definidas en el recurso de entrada. Aunque el
controlador de entrada más común se basa en NGINX, AKS no le restringe a un controlador específico. Puede
usar Contour, HAProxy, Traefik, etc.
El controlador de entrada también debe programarse en un nodo de Linux. Indique que el recurso debe
ejecutarse en un nodo basado en Linux mediante un selector de nodo en el manifiesto YAML o una
implementación de gráfico de Helm. Para obtener más información, consulte Uso de selectores de nodo para
controlar dónde se programan los pods en AKS.
NOTE
Los nodos de Windows Server no deben ejecutar el controlador de entrada.
Hay muchos escenarios de entrada, incluidas las siguientes guías paso a paso:
Creación de un controlador de entrada básico con conectividad de red externa
Creación de un controlador de entrada que use una red privada interna y una dirección IP
Crear un controlador de entrada que usa sus propios certificados TLS
Creación de un controlador de entrada que use Let's Encrypt para generar certificados TLS de forma
automática con una dirección IP pública dinámica o con una dirección IP pública estática
Protección del tráfico con un firewall de aplicaciones web (WAF)

Para analizar el tráfico entrante en busca de posibles ataques, use un firewall de aplicaciones web (WAF)
como Barracuda WAF para Azure o Azure Application Gateway. Estos recursos de red más avanzados
también pueden enrutar el tráfico más allá de las conexiones HTTP y HTTPS sencillas o la terminación TLS
básica.
Normalmente, un controlador de entrada es un recurso de Kubernetes en el clúster de AKS que distribuye el

tráfico a servicios y aplicaciones. El controlador se ejecuta como demonio en un nodo de AKS y consume
algunos de los recursos del nodo, como la CPU, la memoria y el ancho de banda de red. En entornos mayores,
se prefiere:
Descargar algo de tráfico mediante el enrutamiento o la terminación TLS a un recurso de red externo al
clúster de AKS.
Analizar el tráfico entrante en busca de posibles ataques.
Para esa capa adicional de seguridad, un firewall de aplicaciones web (WAF) filtra el tráfico entrante. Con un
conjunto de reglas, Open Web Application Security Project (OWASP) detecta ataques, como el scripting entre
sitios o el envenenamiento de cookies. Azure Application Gateway (actualmente en versión preliminar en AKS)
es una solución WAF que se integra con los clústeres de AKS, lo que bloquea estas características de seguridad
antes de que el tráfico llegue al clúster y a las aplicaciones de AKS.
Dado que otras soluciones de terceros también realizan estas funciones, puede seguir usando las inversiones
existentes o la experiencia en su producto preferido.
Los recursos de entrada o el equilibrador de carga continúan ejecutándose en el clúster de AKS y mejoran la
distribución del tráfico. Application Gateway se puede administrar de manera centralizada como controlador de
entrada con definición de recurso. Para empezar, cree un controlador de entrada de Application Gateway.
Control del flujo de tráfico con directivas de red

Use directivas de red para permitir o denegar el tráfico a los pods. De forma predeterminada, se permite
todo el tráfico entre los pods dentro de un clúster. Para mejorar la seguridad, defina reglas que limiten la
comunicación del pod.
La directiva de red es una característica de Kubernetes disponible en AKS que permite controlar el flujo de
tráfico entre pods. Según la configuración se permite o deniega el tráfico al pod, como, por ejemplo, etiquetas
asignadas, espacio de nombres o puerto de tráfico. Las directivas de red son una manera nativa de nube para
controlar el flujo de tráfico de los pods. Como los pods se crean dinámicamente en un clúster de AKS, se pueden
aplicar automáticamente las directivas de red necesarias.
Para usar la directiva de red, habilite la característica al crear un clúster de AKS. No se puede habilitar la directiva
de red en un clúster de AKS existente. Planee con antelación la habilitación de la directiva de red en los clústeres
necesarios.
NOTE
La directiva de red solo se debe usar para los pods y los nodos basados en Linux de AKS.
Se crea una directiva de red como un recurso de Kubernetes mediante un manifiesto YAML. Las directivas se
aplican a pods definidos, con reglas de entrada o salida que definen el flujo de tráfico.
El ejemplo siguiente aplica una directiva de red a los pods que tienen la etiqueta app: backend. La regla de
entrada solo permite el tráfico desde los pods con la etiqueta app: frontend:
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: backend-policy
spec:
podSelector:
matchLabels:
app: backend
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
Para empezar a usar directivas, consulte Protección del tráfico entre pods mediante directivas de red en Azure
Conexión segura a los nodos mediante una pasarela de aplicaciones

No exponga la conectividad remota a los nodos de AKS. Cree una pasarela de aplicaciones, o host jump, en
una red virtual de administración. Utilice la pasarela de aplicaciones para enrutar el tráfico de forma segura
en el clúster de AKS para las tareas de administración remota.
La mayoría de las operaciones en AKS puede realizarse con las herramientas de administración de Azure o
mediante el servidor de API de Kubernetes. Los nodos de AKS solo están disponibles en una red privada y no
están conectados a la red pública de Internet. Para conectarse a los nodos y proporcionar mantenimiento y
soporte técnico, enrute las conexiones a través de un host bastión o jumpbox. Compruebe que este host se
encuentre en una red virtual de administración independiente emparejada de forma segura a la red virtual del
clúster de AKS.
La red de administración para la pasarela de aplicaciones también debe protegerse. Use Azure ExpressRoute o
VPN Gateway para conectarse a una red local y controlar el acceso con grupos de seguridad de red.
Pasos siguientes
Este artículo se centra en la conectividad de red y la seguridad. Para obtener más información sobre los
conceptos básicos de red en Kubernetes, consulte Conceptos de redes de aplicaciones en Azure Kubernetes
Service (AKS).
Procedimientos recomendados para el
almacenamiento y las copias de seguridad en Azure
A medida que se crean y gestionan clústeres en Azure Kubernetes Service (AKS), las aplicaciones a menudo
necesitan almacenamiento. Asegúrese de que comprende las necesidades de rendimiento de los pods y los
métodos de acceso para poder seleccionar el mejor almacenamiento para la aplicación. El tamaño del nodo de
AKS puede afectar a las opciones de almacenamiento. Debe planear la manera de realizar copias de seguridad y
de probar el proceso de restauración del almacenamiento conectado.
Este artículo de procedimientos recomendados se centra en las consideraciones de almacenamiento de los
operadores de clústeres. En este artículo, aprenderá lo siguiente:
Los tipos de almacenamiento disponibles.
El dimensionamiento correcto del tamaño de los nodos de AKS para el rendimiento del almacenamiento.
Las diferencias entre el aprovisionamiento de volúmenes dinámico y estático.
Las formas de realizar copias de seguridad y proteger los volúmenes de datos.
Elección del tipo de almacenamiento adecuado

Conozca las necesidades de la aplicación para seleccionar el almacenamiento correcto. Utilice
almacenamiento de alto rendimiento respaldado por SSD para cargas de trabajo de producción. Planee el
almacenamiento basado en red cuando se necesiten varias conexiones simultáneas.
Las aplicaciones a menudo requieren diferentes tipos y velocidades de almacenamiento. Determine el tipo de
almacenamiento más adecuado mediante las siguientes preguntas.
¿Necesitan las aplicaciones almacenamiento que se conecte a pods individuales?
¿Necesitan las aplicaciones almacenamiento compartido entre varios pods?
El almacenamiento, ¿es para el acceso de solo lectura a los datos?
¿Se usará el almacenamiento para escribir grandes cantidades de datos estructurados?
En la tabla siguiente se describen los tipos de almacenamiento disponibles y sus capacidades:
C O M PAT IB IL IDA
D C ON
L EC T URA / ESC RIT C O N T EN EDO RES
C O M P L EM EN TO L EC T URA / ESC RI SO LO L EC T URA URA VA RIA S DE W IN DO W S
C A SO DE USO DE VO L UM EN T URA UN A VEZ VA RIA S VEC ES VEC ES SERVER
Configuración Azure Files Sí Sí Sí Sí

compartida
Datos de la Azure Disks Sí No No Sí

aplicación
estructurados
C O M PAT IB IL IDA
D C ON
L EC T URA / ESC RIT C O N T EN EDO RES
C O M P L EM EN TO L EC T URA / ESC RI SO LO L EC T URA URA VA RIA S DE W IN DO W S
C A SO DE USO DE VO L UM EN T URA UN A VEZ VA RIA S VEC ES VEC ES SERVER
Datos no BlobFuse Sí Sí Sí No
estructurados,
operaciones del
sistema de
archivos
AKS proporciona dos tipos principales de almacenamiento seguro para los volúmenes respaldados por Azure
Disks o Azure Files. Ambos usan el cifrado Storage Service Encryption (SSE) predeterminado de Azure que cifra
los datos en reposo. No se pueden cifrar los discos con Azure Disk Encryption en el nivel de nodo de AKS.
Tanto Azure Files como Azure Disks están disponibles en los niveles de rendimiento Estándar y Premium:
Discos prémium
Respaldados por discos de estado sólido (SSD) de alto rendimiento.
Se recomiendan para las cargas de trabajo de producción.
Discos estándar
Respaldados por discos de rotación normales (HDD).
Buenos para datos de archivo o a los que se accede con poca frecuencia.
Comprender las necesidades de rendimiento de la aplicación y los patrones de acceso para elegir el nivel de
almacenamiento adecuado. Para más información sobre los tamaños y niveles de rendimiento de Managed
Disks, consulte Introducción a los discos administrados de Azure
Crear y utilizar clases de almacenamiento para definir las necesidades de la aplicación
Defina el tipo de almacenamiento que desea mediante las clases de almacenamiento de Kubernetes. A
continuación, se hacer referencia a la clase de almacenamiento en la especificación de almacenamiento o en el
pod. Estas definiciones de clase de almacenamiento funcionan conjuntamente para crear el almacenamiento
adecuado y conectarlo a los pods.
Para más información, consulte Clases de almacenamiento en AKS.
Cambiar el tamaño de los nodos según las necesidades de

almacenamiento
Cada tamaño de nodo tiene un límite máximo de discos. Los diferentes tamaños de nodos también
proporcionan distintas cantidades de almacenamiento local y de ancho de banda de red. Realice el
planeamiento adecuado a la demanda de la aplicación para implementar el tamaño correcto de nodo.
Los nodos de AKS se ejecutan tipos y tamaños de máquina virtual de Azure distintos. Cada tamaño de máquina
virtual proporciona:
Una cantidad diferente de recursos principales, como CPU y memoria.
Un número máximo de discos que se pueden conectar.
El rendimiento del almacenamiento también varía en función de los tamaños de VM para el IOPS (operaciones
de entrada/salida por segundo) máximo de discos conectados y locales.
Si las aplicaciones requieren Azure Disks como solución de almacenamiento, planee y elija un tamaño de
máquina virtual para el nodo adecuado. Las funcionalidades de almacenamiento y las cantidades de CPU y
memoria desempeñan un papel principal a la hora de decidir el tamaño de máquina virtual.
Por ejemplo, aunque Standard_B2ms y Standard_DS2_v2 incluyen una cantidad similar de recursos de CPU y
memoria, su rendimiento de almacenamiento difiere:
REN DIM IEN TO

IO P S DE DISC O M Á XIM O SIN
M Á XIM O SIN A L M A C EN A M IEN
TA M A Ñ O Y T IP O DISC O S DE A L M A C EN A M IEN TO EN C A C H É
DE N O DO VC P U M EM O RIA ( GIB ) DATO S M Á X. TO EN C A C H É ( M B P S)
Standard_B2ms 2 8 4 1.920 22.5
Standard_DS2_v 2 7 8 6.400 96
2
En este ejemplo, Standard_DS2_v2 ofrece el doble de discos conectados y de tres a cuatro veces la cantidad de
IOPS y rendimiento del disco. Si solo comparó los recursos de proceso principales y los costos, quizá haya
elegido Standard_B2ms como tamaño de máquina virtual, que presenta limitaciones y menor rendimiento del
almacenamiento.
Trabaje con su equipo de desarrollo de aplicaciones para comprender sus necesidades de rendimiento y de
capacidad de almacenamiento. Elija el tamaño de VM adecuado para los nodos de AKS para cumplir o superar
las necesidades de rendimiento. Establezca regularmente las aplicaciones para ajustar el tamaño de VM según
sea necesario.
Para más información sobre los tamaños de máquina virtual disponibles, consulte Tamaños de las máquinas
virtuales Linux en Azure.
Aprovisionar volúmenes dinámicamente

Para reducir la sobrecarga de administración y habilitar el escalado, evite crear y asignar volúmenes
persistentes estáticamente. Use el aprovisionamiento dinámico. En las clases de almacenamiento, defina la
directiva de reclamación adecuada para reducir los costos de almacenamiento innecesarios una vez que se
eliminan los pods.
Para conectar el almacenamiento a los pods, use volúmenes persistentes. Los volúmenes persistentes se pueden
crear manual o dinámicamente. La creación manual de volúmenes persistentes agrega sobrecarga de
administración y limita su capacidad de escalado. En su lugar, aprovisione el volumen persistente de manera
dinámica para simplificar la administración del almacenamiento y permitir que las aplicaciones crezcan y se
escalen según sea necesario.
Una notificación de volumen persistente (PVC) le permite crear almacenamiento dinámicamente según sea
necesario. Los discos subyacentes de Azure se crean a medida que los solicitan los pods. En la definición del pod
se solicita la creación de un volumen y su conexión a una ruta de acceso de montaje designada.
Para los conceptos sobre cómo crear y usar volúmenes dinámicamente, consulte Notificaciones de volúmenes
persistentes.
Para ver los volúmenes en acción, consulte cómo crear y usar dinámicamente un volumen persistente con Azure
Disks o Azure Files.
Como parte de las definiciones de clase de almacenamiento, configure la directiva reclaimPolicy apropiada. Esta
directiva reclaimPolicy controla el comportamiento del recurso de almacenamiento subyacente de Azure cuando
se elimina el pod. El recurso de almacenamiento subyacente se puede eliminar o conservar para su uso con un
pod en el futuro. Establezca la directiva reclaimPolicy en Retener o Eliminar.
Conozca las necesidades de su aplicación e implemente comprobaciones periódicas del almacenamiento que se
conserva para minimizar la cantidad de espacio de almacenamiento que no se usa y se factura.
Para más información sobre las opciones de clase de almacenamiento, consulte las directivas de reclamación de
almacenamiento.
Proteja y realice una copia de seguridad de los datos

Realice una copia de seguridad de los datos con una herramienta apropiada para su tipo de
almacenamiento, como Velero o Azure Backup. Compruebe la integridad y seguridad de las copias de
seguridad.
Cuando las aplicaciones almacenan y consumen datos que persisten en los discos o en los archivos, es necesario
realizar copias de seguridad o instantáneas periódicamente de esos datos. La tecnología Azure Disks puede usar
la tecnología integrada de instantánea. Las aplicaciones pueden necesitar vaciar las escrituras en el disco para la
operación de instantánea. Velero puede realizar copias de seguridad de volúmenes persistentes junto con
recursos y configuraciones de clústeres adicionales. Si no puede eliminar el estado de sus aplicaciones, realice
una copia de seguridad de los datos de los volúmenes persistentes y pruebe regularmente las operaciones de
restauración para verificar la integridad de los datos y los procesos necesarios.
Comprenda las limitaciones de los diferentes enfoques de las copias de seguridad de datos y si necesita dejar
sus datos en reposo antes de la instantánea. Las copias de seguridad de datos no necesariamente le permiten
restaurar el entorno de la aplicación de la implementación del clúster. Para más información acerca de estos
escenarios, consulte Procedimientos recomendados para continuidad empresarial y recuperación ante desastres
en AKS.
Pasos siguientes
Este artículo se centra en el procedimiento recomendado de almacenamiento en AKS. Para más información
sobre los conceptos básicos de almacenamiento en Kubernetes, consulte Opciones de almacenamiento de
aplicaciones en Azure Kubernetes Service (AKS).
Procedimientos recomendados para continuidad
empresarial y recuperación ante desastres en Azure
A medida que administra los clústeres en Azure Kubernetes Service (AKS), el tiempo de actividad de la
aplicación pasa a ser importante. De forma predeterminada, AKS proporciona alta disponibilidad mediante el
uso de varios nodos en un conjunto de escalado de máquinas virtuales (VMSS). Pero estos múltiples nodos no
protegen al sistema frente a un error de la región. Para maximizar el tiempo de actividad, planee con antelación
para mantener la continuidad empresarial y preparar la recuperación ante desastres.
Este artículo se centra en cómo planear la continuidad empresarial y la recuperación ante desastres en AKS.
Aprenderá a:
Planear los clústeres de AKS en varias regiones.
Enrutar el tráfico entre varios clústeres con Azure Traffic Manager.
Usar la replicación geográfica para los registros de imágenes de contenedor.
Planear el estado de la aplicación entre varios clústeres.
Replicar el almacenamiento entre varias regiones.
Planeamiento de la implementación en varias regiones

Procedimiento recomendado
Al implementar varios clústeres de AKS, elija las regiones en las que AKS está disponible. Use regiones
emparejadas.
Un clúster de AKS se implementa en una sola región. Para proteger el sistema frente al error en una región,
implemente la aplicación en varios clústeres de AKS en diferentes regiones. Cuando planee dónde implementar
el clúster de AKS, tenga en cuenta:
Disponibilidad por región de AKS
Elija regiones cerca de los usuarios.
AKS se expande continuamente en nuevas regiones.
Regiones emparejadas de Azure
Para su área geográfica, elija dos regiones emparejadas entre sí.
Las regiones emparejadas coordinan las actualizaciones de la plataforma y dan prioridad a los
esfuerzos de recuperación cuando resulta necesario.
Disponibilidad del ser vicio
Decida si las regiones emparejadas deben ser las del nivel de acceso frecuente/frecuente,
frecuente/normal o frecuente/poco frecuente.
¿Desea ejecutar ambas regiones al mismo tiempo, con una región preparada para empezar a atender
el tráfico? O bien,
¿Desea dar a una región tiempo para prepararse para atender el tráfico?
La disponibilidad por región de AKS y las regiones emparejadas son una consideración conjunta. Implemente
los clústeres de AKS en regiones emparejadas diseñadas para administrar la recuperación ante desastres de las
regiones de forma conjunta. Por ejemplo, AKS está disponible en el Este de EE. UU. y en el Oeste de EE. UU. Estas
regiones están emparejadas. Elija estas dos regiones al crear una estrategia de continuidad empresarial y
recuperación ante desastres en AKS.
Al implementar la aplicación, agregue otro paso a la canalización de CI/CD para implementar en estos varios
clústeres de AKS. La actualización de las canalizaciones de implementación impide que las aplicaciones se
implementen solo en una de las regiones y clústeres de AKS. En ese escenario, el tráfico de cliente que se dirige
a una región secundaria no recibirá las actualizaciones más recientes de código.
Uso de Azure Traffic Manager para enrutar el tráfico

Azure Traffic Manager puede dirigirlo a la instancia de la aplicación y los clústeres de AKS más cercanos.
Para conseguir los máximos niveles de rendimiento y redundancia, dirija todo el tráfico de la aplicación con
Traffic Manager antes de que pase al clúster de AKS.
Si tiene varios clústeres de AKS en distintas regiones, use Traffic Manager para controlar el flujo de tráfico a las
aplicaciones que se ejecutan en cada clúster. Azure Traffic Manager es un equilibrador de carga de tráfico basado
en DNS que puede distribuir el tráfico de red entre regiones. Use Traffic Manager para enrutar a los usuarios en
función del tiempo de respuesta del clúster o de la ubicación geográfica.
Si tiene un único clúster de AKS, normalmente lo conecta a la dirección IP de servicio o al nombre DNS de una
aplicación determinada. En una implementación de varios clústeres, debe conectarse a un nombre DNS de
Traffic Manager que apunte a los servicios en cada clúster de AKS. Para definir estos servicios, use los puntos de
conexión de Traffic Manager. Cada punto de conexión es la dirección IP del equilibrador de carga del servicio.
Use esta configuración para dirigir el tráfico de red desde el punto de conexión de Traffic Manager de una región
al punto de conexión de otra.
Traffic Manager realiza las búsquedas de DNS y devuelve el punto de conexión más adecuado. Los perfiles
anidados pueden dar prioridad a una ubicación principal. Por ejemplo, debería conectarse a su región geográfica
más cercana. Si esa región tiene un problema, Traffic Manager lo dirige a una región secundaria. Este enfoque
garantiza que pueda conectarse a una instancia de una aplicación, incluso aunque su región geográfica más
próxima no esté disponible.
Para información sobre cómo configurar estos puntos de conexión y el enrutamiento, consulte Configuración
del método de enrutamiento de tráfico geográfico con Traffic Manager.
Enrutamiento de aplicaciones con Azure Front Door Service
Mediante el protocolo de difusión por proximidad basado en división TCP, Azure Front Door Service conecta
inmediatamente a los usuarios finales con el punto de presencia (POP) de Front Door más cercano. Más
características de Azure Front Door Azure:
Finalización de TLS
Dominio personalizado
Firewall de aplicaciones web
Reescritura de direcciones URL
Afinidad de sesión
Revise los requisitos del tráfico de su aplicación para saber qué solución es la más conveniente.
Interconexión de regiones con el emparejamiento de redes virtuales globales
Conecte ambas redes virtuales entre sí a través del emparejamiento de redes virtuales para habilitar la
comunicación entre clústeres. El emparejamiento de red virtual interconecta las redes virtuales, lo que ofrece un
alto ancho de banda en toda la red troncal de Microsoft, incluso en distintas regiones geográficas.
Antes de emparejar redes virtuales con clústeres de AKS en ejecución, use la instancia de Load Balancer
estándar en el clúster de AKS. Este requisito previo permite comunicarse con los servicios de Kubernetes a
través del emparejamiento de red virtual.
Habilitar la replicación geográfica para las imágenes de contenedor

almacene las imágenes de contenedor en Azure Container Registry y replique geográficamente el registro
en cada región de AKS.
Para implementar y ejecutar sus aplicaciones en AKS, necesita una manera de almacenar y extraer las imágenes
de contenedor. Container Registry se integra con AKS de modo que puede almacenar de forma segura sus
imágenes de contenedor o los gráficos de Helm. Container Registry admite la replicación geográfica de
arquitectura multimaestro para replicar automáticamente las imágenes en las regiones de Azure de todo el
mundo.
Para mejorar el rendimiento y la disponibilidad:
1. Use la replicación geográfica de Container Registry para crear un registro en cada región donde haya un
clúster de AKS.
2. Cada clúster de AKS, a continuación, extrae las imágenes del registro de contenedor local en la misma región:
Cuando se usa la replicación geográfica de Container Registry para extraer imágenes de la misma región, los
resultados son:
Más rápidos : puede extraer imágenes de conexiones de red de alta velocidad y baja latencia dentro de la
misma región de Azure.
Más confiables : si una región no está disponible, el clúster de AKS extrae las imágenes desde un registro de
contenedor disponible.
Más baratos : no se genera ningún cargo por salida de red entre los centros de datos.
La replicación geográfica es una característica de los registros de contenedor de SKU Prémium. Para
información sobre cómo configurar la replicación geográfica, consulte Replicación geográfica en
Azure Container Registry.
Quitar el estado de servicio de dentro de los contenedores

Evite almacenar el estado del servicio dentro del contenedor. En su lugar, use una plataforma como servicio
(PaaS) de Azure que admita la replicación en varias regiones.
Estado de servicio hace referencia a los datos en memoria o en disco necesarios para que el servicio funcione. El
estado incluye las variables de miembro y las estructuras de datos que el servicio lee y escribe. Según el diseño
del servicio, el estado también puede incluir archivos u otros recursos almacenados en el disco. Por ejemplo, el
estado podría incluir los archivos que una base de datos usa para almacenar los registros de transacciones y de
datos.
El estado se puede externalizar o colocar con el código que lo está manipulando. Generalmente, la
externalización del estado se realiza con una base de datos u otro almacén de datos que se ejecuta en distintas
máquinas de la red o fuera del proceso en la misma máquina.
Los contenedores y los microservicios son más resistentes si los procesos que se ejecutan dentro de ellos no
conservan el estado. Ya que las aplicaciones casi siempre contienen algún estado, use una solución PaaS, como:
Azure Cosmos DB
Azure Database for PostgreSQL
Azure Database for MySQL
Azure SQL Database
Para crear aplicaciones portátiles, consulte las siguientes directrices:
La metodología de las aplicaciones con doce factores
Ejecución de una aplicación web en varias regiones de Azure
Crear un plan de migración de almacenamiento

si usa Azure Storage, prepárelo y pruebe cómo migrar el almacenamiento desde la región principal a la
región de copia de seguridad.
Las aplicaciones pueden utilizar Azure Storage para sus datos. En caso afirmativo, las aplicaciones se extienden
entre varios clústeres de AKS en distintas regiones. Debe mantener sincronizado el almacenamiento. Existen dos
formas habituales de replicar el almacenamiento:
Replicación asincrónica basada en la infraestructura
Replicación asincrónica basada en la aplicación
Replicación asincrónica basada en la infraestructura
Las aplicaciones pueden requerir almacenamiento persistente, incluso después de eliminar un pod. En
Kubernetes, puede usar los volúmenes persistentes para conservar el almacenamiento de datos. Los volúmenes
persistentes se montan en la máquina virtual de un nodo y, a continuación, se exponen a los pods. Los
volúmenes persistentes realizan el seguimiento de los pods, aunque estos se muevan a un nodo diferente
dentro del mismo clúster.
La estrategia de replicación que use dependerá de la solución de almacenamiento. Las siguientes soluciones de
almacenamiento comunes proporcionan sus propias instrucciones sobre la recuperación ante desastres y la
replicación:
Gluster
Ceph
Rook
Portworx
Normalmente, se proporciona un punto de almacenamiento común en el que las aplicaciones escriben sus
datos. A continuación, estos datos se replican entre regiones y se accede a ellos de manera local.
Si usa Azure Managed Disks, puede emplear Velero en Azure y Kasten para controlar la replicación y la
recuperación ante desastres. Estas opciones son soluciones de copia de seguridad nativas de Kubernetes, pero
no reciben soporte de dicha plataforma.
Replicación asincrónica basada en la aplicación
Actualmente, Kubernetes no proporciona ninguna implementación para la replicación asincrónica basada en la
aplicación. Ya que los contenedores y Kubernetes apenas tienen conexión, cualquier enfoque de lenguaje o
aplicación tradicional debe funcionar. Generalmente, las propias aplicaciones replican las solicitudes de
almacenamiento, que posteriormente se escriben en el almacenamiento de datos subyacente de cada clúster.
Pasos siguientes
Este artículo se centra en las consideraciones sobre continuidad empresarial y recuperación ante desastres en
los clústeres de AKS. Para más información acerca de las operaciones de clúster en AKS, consulte en los
siguientes artículos los procedimientos recomendados:
Aislamiento multiempresa y de clúster
Procedimientos recomendados para desarrolladores
de aplicaciones para administrar recursos en Azure
Kubernetes Services (AKS)
A medida que desarrolla y ejecuta aplicaciones en Azure Kubernetes Service (AKS), hay algunas áreas clave a
tener en cuenta. El modo de administrar las implementaciones de aplicaciones puede repercutir negativamente
en la experiencia del usuario final de los servicios que proporciona. Para que el proceso sea correcto, tenga en
cuenta algunos procedimientos recomendados que puede seguir a medida que desarrolla y ejecuta aplicaciones
en AKS.
Este artículo se centra en la ejecución del clúster y las cargas de trabajo desde la perspectiva de un desarrollador
de aplicaciones. Para obtener información acerca de los procedimientos recomendados, consulte
Procedimientos recomendados para el aislamiento y la administración de recursos en Azure Kubernetes Service
(AKS). En este artículo, aprenderá lo siguiente:
Solicitudes y límites de recursos de pod
Formas de desarrollar e implementar aplicaciones con Bridge to Kubernetes y Visual Studio Code.
Cómo usar la herramienta kube-advisor para comprobar si existen problemas con las implementaciones.
Definición de los límites y solicitudes de recursos del pod

Configure las solicitudes y los límites de pod en todos los pods de los manifiestos de YAML. Si el clúster de
AKS usa cuotas de recursos y no define estos valores, es posible que la implementación se rechace.
Use las solicitudes y los límites de pod para administrar los recursos de proceso dentro de un clúster de AKS.
Las solicitudes y los límites de pod informan al programador de Kubernetes sobre los recursos de proceso que
se asignarán a un pod.
Solicitudes de CPU/memoria de pod
Las solicitudes de pod definen una cierta cantidad de CPU y memoria que necesita el pod periódicamente.
En las especificaciones de su pod, es un procedimiento recomendado y muy impor tante definir estas
solicitudes y límites en función de la información anterior. Si no incluye estos valores, el scheduler de
Kubernetes no puede tener en cuenta los recursos que requieren sus aplicaciones para ayudarlo a tomar
decisiones de programación.
Supervise el rendimiento de la aplicación para ajustar las solicitudes de pod.
Si subestima las solicitudes de pod, su aplicación puede recibir un rendimiento degradado debido a la
programación excesiva de un nodo.
Si se sobrestiman las solicitudes, su aplicación puede tener mayores dificultades para ser programada.
Límites de CPU/memoria de pod**
Los límites de pods establecen la cantidad máxima de CPU y memoria que puede usar un pod.
Los límites de memoria definen qué pods se deben terminar cuando los nodos son inestables por haber
recursos insuficientes. Sin los límites adecuados, los pods establecidos se terminarán hasta que se levante la
presión de los recursos.
Aunque un pod puede exceder el límite de CPU periódicamente, el pod no se terminará por exceder el límite
de CPU.
Los límites de pod definen cuándo ha perdido un pod el control del consumo de recursos. Cuando supera el
límite, el pod se marca para su terminación. Este comportamiento mantiene el estado del nodo y minimiza el
impacto en los pods que comparten el nodo. Al no establecer un límite de pod, el valor predeterminado es el
valor más alto disponible en un nodo determinado.
Evite establecer un límite de pod superior al que pueden admitir los nodos. Cada nodo de AKS reserva una
cierta cantidad de CPU y memoria para los componentes básicos de Kubernetes. La aplicación puede intentar
consumir demasiados recursos en el nodo para que otros pods se ejecuten correctamente.
Supervise el rendimiento de la aplicación en distintos momentos del día o de la semana. Determine cuándo se
produce la máxima demanda y ajuste en consonancia los límites del pod para que haya recursos necesarios
para las necesidades máximas.
IMPORTANT
En las especificaciones de su pod, defina estas solicitudes y límites en función de la información anterior. Si no se incluyen
estos valores, el programador de Kubernetes no tiene en cuenta los recursos que las aplicaciones necesitan para ayudar
en la programación de decisiones.
Si el Scheduler coloca un Pod en un nodo con recursos insuficientes, el rendimiento de la aplicación se

degradará. El administrador de clústeres debe definir cuotas de recursos en un espacio de nombres que
requiere el establecimiento de límites y solicitudes de recursos. Para obtener más información, consulte cuotas
de recursos en clústeres de AKS.
Al definir un límite o solicitud de CPU, el valor se mide en unidades de CPU.
CPU 1.0 equivale a un núcleo de CPU virtual subyacente en el nodo.
Se usa la misma unidad de medida para las GPU.
Puede definir fracciones medidas en milinúcleos. Por ejemplo, 100 m es 0,1 de un núcleo de vCPU
subyacente.
En el siguiente ejemplo básico para un solo pod de NGINX, el pod solicita 100 m de tiempo de CPU y 128 Mi de
memoria. Los límites de recursos para el pod se definen en 250 m de CPU y 256 Mi de memoria:
kind: Pod
apiVersion: v1
metadata:
name: mypod
spec:
containers:
- name: mypod
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
Para obtener más información acerca de las asignaciones y medidas de recursos, consulte Administración de
recursos de proceso para contenedores.
Desarrollo y depuración de aplicaciones en un clúster de AKS
Los equipos de desarrollo deben realizar la implementación y depuración en un clúster de AKS mediante
Bridge to Kubernetes.
Con Bridge to Kubernetes, desarrolle, depure y pruebe aplicaciones directamente en un clúster de AKS. Los
desarrolladores de un equipo colaboran para realizar compilaciones y pruebas a lo largo del ciclo de vida de la
aplicación. Puede seguir usando herramientas existentes, como Visual Studio o Visual Studio Code, con la
extensión Bridge to Kubernetes.
El uso de este proceso de desarrollo y pruebas integrado con Bridge to Kubernetes reduce la necesidad de
entornos de prueba locales, como minikube. En su lugar, desarrolle y pruebe con un clúster de AKS, incluso con
clústeres protegidos y aislados.
NOTE
Bridge to Kubernetes está pensado para su uso con aplicaciones que se ejecutan en nodos y pods de Linux.
Uso de Visual Studio Code (VS Code) para Kubernetes

Instale y use la extensión de VS Code para Kubernetes al escribir manifiestos de YAML. También puede usar
la extensión para la solución de implementación integrada, lo que puede ayudar a los propietarios de
aplicaciones que interactúan con poca frecuencia con el clúster de AKS.
La extensión de Visual Studio Code para Kubernetes le ayuda a desarrollar e implementar aplicaciones en AKS.
Esta extensión proporciona:
Recursos de IntelliSense para Kubernetes, gráficos de Helm y plantillas.
Funcionalidades de examen, implementación y edición para recursos de Kubernetes desde VS Code.
Una comprobación de IntelliSense para los límites o solicitudes de recursos que se van a establecer en las
especificaciones del pod:
Comprobación de forma periódica de problemas de aplicaciones con

kube-advisor
Ejecute periódicamente la versión más reciente de la herramienta de código abierto kube-advisor para
detectar problemas en el clúster. Ejecute kube-advisor antes de aplicar cuotas de recursos en un clúster de
AKS existente para buscar pods que no tengan definidas solicitudes y límites de recursos.
La herramienta kube-advisor es un proyecto de código abierto de AKS asociado que examina un clúster de
Kubernetes e informa sobre los problemas identificados. Una comprobación útil consiste en identificar los pods
sin límites y solicitudes de recursos vigentes.
Aunque la herramienta kube-advisor puede informar sobre la falta de límites y solicitudes de recursos en
PodSpecs para las aplicaciones Windows y Linux, la propia kube-advisor debe programarse en un pod de Linux.
Use un selector de nodos en la configuración del pod para programar la ejecución de un pod en un grupo de
nodos con un sistema operativo específico.
En un clúster de AKS que hospeda muchos equipos y aplicaciones de desarrollo, le resultará fácil realizar un
seguimiento de los pods con los límites y solicitudes de recursos. Como procedimiento recomendado, ejecute
kube-advisor de forma periódica en los clústeres de AKS.
Pasos siguientes
Este artículo se centra en cómo ejecutar el clúster y las cargas de trabajo desde la perspectiva de un operador de
clústeres. Para obtener información acerca de los procedimientos recomendados, consulte Procedimientos
recomendados para el aislamiento y la administración de recursos en Azure Kubernetes Service (AKS).
Para implementar algunos de estos procedimientos recomendados, consulte los artículos siguientes:
Desarrollo con Bridge to Kubernetes
Comprobación de problemas con kube-advisor
Procedimientos recomendados para la seguridad de
pods en Azure Kubernetes Service (AKS)
A la hora de desarrollar y ejecutar aplicaciones en Azure Kubernetes Service (AKS), es importante tener en
cuenta la seguridad de los pods. Las aplicaciones se deben diseñar con el principio del número mínimo de
privilegios necesarios. Mantener seguros los datos privados es prioritario para los clientes. No deseará que
credenciales como las cadenas de conexión de base de datos, las claves o los secretos y los certificados se vean
expuestas al mundo exterior, donde un atacante podría aprovechar esos secretos con propósitos
malintencionados. No debe incorporarlas al código ni insertarlas en las imágenes de contenedor. Este enfoque
crearía un riesgo de exposición y limitaría la posibilidad de rotar esas credenciales, ya que las imágenes de
contenedor se deberían volver a generar.
Este artículo de procedimientos recomendados se centra en cómo proteger los pods en AKS. Aprenderá a:
Usar el contexto de seguridad del pod para limitar el acceso a los procesos y los servicios o una elevación de
privilegios
Autenticarse con otros recursos de Azure mediante identidades administradas del pod
Solicitar y recuperar credenciales de un almacén digital, como Azure Key Vault
También puede consultar los procedimientos recomendados sobre la seguridad del clúster y la administración
de imágenes de contenedor.
Protección del acceso del pod a los recursos

Guía de procedimiento recomendado : para la ejecución como un usuario o grupo diferentes y limitar el
acceso a los procesos y servicios del nodo subyacente, defina la configuración del contexto de seguridad del
pod. Asigne el menor número de privilegios necesarios.
Para que las aplicaciones se ejecuten correctamente, los pods se deben ejecutar como un usuario o grupo
definidos y no como root. El elemento securityContext de un pod o un contenedor permite definir valores de
configuración como runAsUser o fsGroup para asumir los permisos adecuados. Asigne solo los permisos de
usuario o grupo necesarios y no utilice el contexto de seguridad como un medio para asumir permisos
adicionales. El runAsUser, elevación de privilegios y otros valores de configuración de las capacidades de Linux
solo están disponibles en los pods y los nodos de Linux.
Cuando se ejecuta como un usuario que no es root, los contenedores no se pueden enlazar a los puertos con
privilegios inferiores al 1024. En este escenario, los servicios de Kubernetes se pueden utilizar para ocultar el
hecho de que una aplicación se ejecuta en un puerto determinado.
Un contexto de seguridad del pod también puede definir funcionalidades o permisos adicionales para el acceso
a los procesos y servicios. Se pueden establecer las siguientes definiciones de contexto de seguridad comunes:
allowPrivilegeEscalation define si el pod puede asumir privilegios de usuario root. Diseñe las aplicaciones
de modo que este valor siempre esté establecido en false.
Funcionalidades de Linux : permite el acceso del pod a los procesos de nodo subyacente. Tenga cuidado
con la asignación de estas funcionalidades. Asigne el menor número de privilegios necesarios. Para más
información, consulte las funcionalidades de Linux.
Etiquetas SELinux es un módulo de seguridad del kernel de Linux que le permite definir directivas para el
acceso a los servicios, los procesos y el sistema de archivos. De nuevo, asigne el menor número de
privilegios necesarios. Para más información, consulte las opciones de SELinux disponibles en Kubernetes.
El siguiente ejemplo de manifiesto YAML de pod establece la configuración del contexto de seguridad para
definir:
El pod se ejecuta con el identificador de usuario 1000 y es parte del grupo con el identificador 2000
No se pueden elevar los privilegios para usar root
Permite a las funcionalidades de Linux acceder a las interfaces de red y al reloj en tiempo real del host
(hardware)
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
fsGroup: 2000
containers:
- name: security-context-demo
securityContext:
runAsUser: 1000
allowPrivilegeEscalation: false
capabilities:
add: ["NET_ADMIN", "SYS_TIME"]
Colabore con el operador del clúster para determinar la configuración de contexto de seguridad que necesita.
Intente diseñar las aplicaciones para minimizar los permisos adicionales y el acceso que requiere el pod. Hay
características de seguridad adicionales para limitar el acceso mediante AppArmor y seccomp (informática
segura) que los operadores del clúster pueden implementar. Para más información, consulte Protección del
acceso del contenedor a los recursos.
Limitación de la exposición de credenciales

Guía de procedimiento recomendado : no defina las credenciales en el código de aplicación. Use identidades
administradas para los recursos de Azure para permitir que el pod solicite acceso a otros recursos. Se debería
usar también un almacén digital, como Azure Key Vault, para almacenar y recuperar las credenciales y claves
digitales. Las identidades administradas de pod está pensadas para usar únicamente con pods de Linux y las
imágenes de contenedor.
Para limitar el riesgo de exposición de las credenciales en el código de la aplicación, evite el uso de credenciales
compartidas o fijas. Las credenciales y las claves no se deberían incluir directamente en el código. Si se exponen
estas credenciales, la aplicación se debe actualizar y volver a implementar. Un enfoque mejor es dar a los pods
sus propias identidades y formas para autenticarse a sí mismos o recuperar automáticamente las credenciales
de un almacén digital.
Uso de proyectos ascendentes de proceso de contenedor de Azure
IMPORTANT
El soporte técnico de Azure no admite los proyectos de código abierto de AKS asociados. Se proporcionan para que los
usuarios se ocupen por sí mismos de su instalación en los clústeres y recopilen comentarios de nuestra comunidad.
Los siguientes proyectos de código abierto de AKS asociados le permiten autenticar automáticamente los pods
o las credenciales de la solicitud y las claves desde un almacén digital. Estos proyectos los mantiene el equipo de
flujo ascendente de proceso de contenedor de Azure y forman parte de una lista más amplia de proyectos
disponibles para su uso.
Azure Active Directory Pod Identity
Proveedor de Azure Key Vault para el controlador de CSI del almacén de secretos
Uso de identidades administradas del pod
Las identidades administradas de los recursos de Azure permiten a un pod autenticarse a sí mismo en cualquier
servicio de Azure que lo permita, como Storage o SQL. Se asigna al pod una identidad de Azure que le permite
autenticarse en Azure Active Directory y recibir un token digital. Este token digital se puede presentar a otros
servicios de Azure que comprueban si el pod está autorizado para acceder al servicio y realizar las acciones
necesarias. Este enfoque significa que no es necesario ningún secreto para las cadenas de conexión de base de
datos, por ejemplo. El flujo de trabajo simplificado de la identidad administrada del pod se muestra en el
diagrama siguiente:
Con una identidad administrada, el código de la aplicación no necesita incluir credenciales para acceder a un
servicio como Azure Storage. Como cada pod se autentica con su propia identidad, puede auditar y revisar el
acceso. Si la aplicación se conecta con otros servicios de Azure, utilice identidades administradas para limitar la
reutilización de credenciales y el riesgo de exposición.
Para más información acerca de las identidades de los pods, consulte Configuración de un clúster de AKS para
usar identidades administradas de pods con las aplicaciones.
Uso de Azure Key Vault con el controlador de CSI del almacén de secretos
El uso del proyecto de identidades de pods permite la autenticación en los servicios compatibles de Azure. Para
sus propios servicios o aplicaciones sin identidades administradas para recursos de Azure, puede seguir
autenticándose mediante credenciales o claves. Se puede utilizar un almacén digital para almacenar el contenido
de estos secretos.
Cuando las aplicaciones necesitan una credencial, se comunican con el almacén digital, recuperan el contenido
de los secretos más reciente y luego se conectan al servicio solicitado. Azure Key Vault puede ser este almacén
digital. El flujo de trabajo simplificado para recuperar una credencial de Azure Key Vault mediante identidades
administradas de pods se muestra en el diagrama siguiente:
Con Key Vault, puede almacenar y rotar periódicamente secretos como credenciales, claves de cuenta de
almacenamiento o certificados. Puede integrar Azure Key Vault con un clúster de AKS mediante el proveedor de
Azure Key Vault para el controlador de CSI del almacén de secretos. El controlador de CSI del almacén de
secretos permite que el clúster de AKS pueda recuperar de forma nativa el contenido de los secretos de Key
Vault y proporcionárselo de forma segura solo al pod solicitante. Trabaje con el operador de clúster para
implementar el controlador de CSI del almacén de secretos en los nodos de trabajo de AKS. Puede usar una
identidad administrada de pods para solicitar acceso a Key Vault y recuperar el contenido de los secretos que
necesita mediante el controlador de CSI del almacén de secretos.
Azure Key Vault con el controlador de CSI del almacén de secretos se puede usar para pods y nodos de Linux
que requieren una versión la versión 1.16, o superior, de Kubernetes. Para pods y nodos de Windows, se
requiere la versión 1.18, o superior, de Kubernetes 1.18.
Pasos siguientes
Este artículo se centra en cómo proteger los pods. Para implementar algunas de estas áreas, consulte los
artículos siguientes:
Uso de identidades administradas para recursos de Azure con AKS
Integración de Azure Key Vault con AKS
Cuotas, restricciones de tamaño de máquinas
virtuales y disponibilidad de regiones en Azure
Todos los servicios de Azure establecen límites y cuotas predeterminados para recursos y características,
incluidas restricciones de uso para determinadas SKU de máquina virtual (VM).
En este artículo se detallan los límites de recursos predeterminados para los recursos de Azure Kubernetes
Service (AKS) y la disponibilidad de AKS en las regiones de Azure.
Límites y cuotas del servicio

RESO URC E L ÍM IT E
Número máximo de clústeres por suscripción 5000
Número máximo de nodos por clúster con los conjuntos de 100

disponibilidad de máquina virtual y el SKU básico de Load
Balancer
Número máximo de nodos por clúster con Virtual Machine 1000 (entre todos los grupos de nodos)
Scale Sets y el SKU estándar de Load Balancer
Número máximo de grupos de nodos por clúster 100
Número máximo de pods por nodo: redes básicas con Máximo: 250
Kubenet Valor predeterminado de la CLI de Azure: 110
Valor predeterminado de la plantilla de Azure Resource
Manager: 110
Valor predeterminado de la implementación de Azure Portal:
30
Número máximo de pods por nodo: redes avanzadas con Máximo: 250
Azure Container Networking Interface Valor predeterminado: 30
Versión preliminar del complemento Open Service Mesh Versión del clúster de Kubernetes: 1.19+1
(OSM) AKS Controladores OSM por clúster: 11
Pods por controlador OSM: 5001
Cuentas de servicio de Kubernetes administradas por OSM:
501
1 El complemento OSM para AKS se encuentra en versión preliminar y se someterá a mejoras adicionales antes
de su disponibilidad con carácter general. Durante la fase de versión preliminar, se recomienda no superar los
límites indicados.
Infraestructura aprovisionada
A la infraestructura aprovisionada se le aplican las demás limitaciones de red, proceso y almacenamiento.
Consulte límites de suscripción y servicios de Azure para conocer los límites pertinentes.
IMPORTANT
Al actualizar un clúster de AKS, se consumen recursos adicionales temporalmente. Estos recursos incluyen las direcciones
IP disponibles en una subred de red virtual o una cuota de vCPU de máquina virtual.
En el caso de los contenedores de Windows Server, puede realizar una operación de actualización para aplicar las
actualizaciones de nodo más recientes. Si no tiene el espacio de direcciones IP disponible o la cuota de vCPU necesaria
para administrar estos recursos temporales, se producirá un error en el proceso de actualización del clúster. Para obtener
más información sobre el proceso de actualización del nodo de Windows Server, consulte Actualización de un grupo de
nodos en AKS.
Tamaños de VM restringidos
Cada nodo en un clúster de AKS contiene una cantidad fija de recursos de proceso, como la vCPU y la memoria.
Si un nodo de AKS no tiene suficientes recursos de proceso, es posible que los pods no se ejecuten
correctamente. Para asegurarse de que los pods de kube-system necesarios y las aplicaciones puedan
programarse de manera confiable, no use las siguientes SKU de máquina vir tual en AKS :
Standard_A0
Standard_A1
Standard_A1_v2
Standard_B1s
Standard_B1ms
Standard_F1
Standard_F1s
Para obtener más información sobre los tipos de VM y sus recursos de proceso, consulte Tamaños de las
máquinas virtuales en Azure.
Para obtener la lista más reciente con los lugares donde puede implementar y ejecutar clústeres, consulte
Disponibilidad de regiones de AKS.
Pasos siguientes
Puede aumentar ciertas cuotas y límites predeterminados. Si su recurso admite un aumento, solicítelo mediante
una solicitud de soporte técnico de Azure (en Tipo de problema , seleccione Cuota ).
Migrar a Azure Kubernetes Service (AKS)
Para ayudarle a planear y ejecutar una migración correcta a Azure Kubernetes Service (AKS), en esta guía se
proporcionan detalles para la configuración de AKS que se recomienda actualmente. Aunque en este artículo no
se tratan todos los escenarios, se incluyen vínculos a información más detallada para planear una migración
correcta.
Este documento ayuda con los siguientes escenarios:
Incluir en contenedores ciertas aplicaciones y migrarlas a AKS con Azure Migrate.
Migrar un clúster de AKS respaldado por Conjuntos de disponibilidad a Virtual Machine Scale Sets.
Migrar un clúster de AKS para usar un equilibrador de carga de SKU estándar.
Migrar desde Azure Container Service (ACS), que se retirará el 31 de enero de 2020, a AKS.
Migrar desde el motor de AKS a AKS.
Migrar desde clústeres de Kubernetes no basados en Azure a AKS.
Trasladar recursos existentes a otra región.
Al realizar la migración, asegúrese de que la versión de Kubernetes de destino se encuentre en la ventana
admitida para AKS. Es posible que las versiones anteriores no se encuentren dentro del intervalo admitido y que
AKS requiera una actualización de versión. Para más información, consulte Versiones de Kubernetes compatibles
Si va a migrar a una versión más reciente de Kubernetes, consulte Versión de Kubernetes y directiva de soporte
de asimetría de versiones.
Varias herramientas de código abierto pueden ayudarle con la migración, en función de su escenario:
Velero (requiere Kubernetes 1.7+)
Extensión de la CLI de Azure Kube
ReShifter
En este artículo se resumen los detalles de la migración para lo siguiente:
Incluir aplicaciones en contenedores a través de Azure Migrate
AKS con Standard Load Balancer y Virtual Machine Scale Sets
Servicios de Azure asociados existentes
Garantizar cuotas válidas
Alta disponibilidad y continuidad empresarial
Consideraciones sobre las aplicaciones sin estado
Consideraciones sobre las aplicaciones con estado
Implementación de la configuración del clúster
Use Azure Migrate para migrar sus aplicaciones a AKS

Azure Migrate ofrece una plataforma unificada para evaluar y migrar a servidores, infraestructura, aplicaciones
y datos locales de Azure. En el caso de AKS, puede usar Azure Migrate para las tareas siguientes:
Inclusión de aplicaciones ASP.NET en contenedores y migración a AKS
Inclusión de aplicaciones web de Java en contenedores y migración a AKS
AKS es un servicio administrado que ofrece funcionalidades únicas con una sobrecarga de administración
menor. Como AKS es un servicio administrado, debe seleccionar un conjunto de regiones que AKS admita. Quizá
deba modificar las aplicaciones existentes para mantenerlas en buen estado en el plano de control administrado
por AKS durante la transición del clúster existente a AKS.
Se recomienda el uso de clústeres de AKS respaldados por Virtual Machine Scale Sets y Azure Standard Load
Balancer para garantizar características como las siguientes:
Varios grupos de nodos
Zonas de disponibilidad
Intervalos IP autorizados
Escalador automático de clústeres
Azure Policy para AKS
Otras características nuevas que vayan saliendo.
Los clústeres de AKS respaldados por Virtual Machine Availability Sets no tienen compatibilidad con muchas de
estas características.
En el ejemplo siguiente se crea un clúster de AKS con un único grupo de nodos respaldado por un conjunto de
escalado de máquinas virtuales. El clúster:
Usa una instancia de Standard Load Balancer.
Habilita el escalador automático de clústeres en el grupo de nodos del clúster.
Establece un mínimo de 1 y un máximo de 3 nodos.
# First create a resource group

# Now create the AKS cluster and enable the cluster autoscaler
az aks create \
--node-count 1 \
--vm-set-type VirtualMachineScaleSets \
--load-balancer-sku standard \
--enable-cluster-autoscaler \
--min-count 1 \
--max-count 3

Al migrar clústeres quizá haya asociado servicios externos de Azure. Aunque los siguientes servicios no
requieren la recreación de los recursos, requerirán la actualización de las conexiones de los clústeres anteriores
a los nuevos para mantener la funcionalidad.
Azure Container Registry
Log Analytics
Application Insights
Traffic Manager
Cuenta de almacenamiento
Bases de datos externas

Dado que otras máquinas virtuales se implementarán en su suscripción durante la migración, debe comprobar
que los límites y las cuotas sean suficientes para estos recursos. Si es necesario, solicite un aumento de la cuota
de CPU virtual.
Es posible que tenga que solicitar un aumento de las cuotas de red para asegurarse de no agotar las direcciones
IP. Para más información, consulte Redes e intervalos IP para AKS.
Para más información, consulte Azure subscription and service limits (Límites de suscripción y servicio de
Azure). Para comprobar las cuotas actuales, en Azure Portal, vaya a la hoja de suscripciones, seleccione la
suscripción y seleccione Uso y cuotas .

Si la aplicación no puede controlar el tiempo de inactividad, debe seguir los procedimientos recomendados para
los escenarios de migración de alta disponibilidad. Más información sobre los Procedimientos recomendados
para la planeación de la continuidad empresarial compleja, la recuperación ante desastres y la maximización del
tiempo de actividad en Azure Kubernetes Service (AKS).
Normalmente, las aplicaciones complejas se migran en varias veces en lugar de en una sola vez,por lo que los
entornos antiguos y los nuevos quizá deban comunicarse a través de la red. Es posible que aplicaciones que
anteriormente usaban servicios ClusterIP para comunicarse deban exponerse como tipo LoadBalancer y estar
protegidas adecuadamente.
Para completar la migración, querrá dirigir los clientes a los nuevos servicios que se ejecutan en AKS. Se
recomienda redirigir el tráfico mediante la actualización de DNS para que apunte a la instancia de Load Balancer
que se encuentra frente al clúster de AKS.
Azure Traffic Manager puede dirigir a los clientes a la instancia de la aplicación y los clústeres de Kubernetes
deseados. Azure Traffic Manager es un equilibrador de carga de tráfico basado en DNS que puede distribuir el
tráfico de red entre regiones. Para conseguir los máximos niveles de rendimiento y redundancia, dirija todo el
tráfico de la aplicación con Traffic Manager antes de que pase al clúster de AKS.
En una implementación de varios clústeres, los clientes deben conectarse a un nombre DNS de Traffic Manager
que apunte a los servicios en cada clúster de AKS. Para definir estos servicios, use los puntos de conexión de
Traffic Manager. Cada punto de conexión es la dirección IP del equilibrador de carga del servicio. Use esta
configuración para dirigir el tráfico de red desde el punto de conexión de Traffic Manager de una región al punto
de conexión de otra.
Azure Front Door Service es otra opción para enrutar el tráfico de los clústeres de AKS. Con Azure Front Door
Service podrá definir, administrar y supervisar el enrutamiento global para el tráfico web mediante la
optimización para obtener mejor rendimiento y conmutación por error global instantánea para la alta
disponibilidad.
La migración de aplicaciones sin estado es el caso más sencillo:
1. Aplique las definiciones de recurso (YAML o Helm) al nuevo clúster.
2. Asegúrese de que todo funciona según lo previsto.
3. Redirija el tráfico para activar el nuevo clúster.
Planee meticulosamente la migración de aplicaciones con estado para evitar la pérdida de datos o tiempos de
inactividad inesperados.
Si usa Azure Files, puede montar el recurso compartido de archivos como un volumen en el nuevo clúster.
Consulte Montaje de instancias estáticas de Azure Files como volumen.
Si usa Azure Managed Disks, solo podrá montar el disco si no está conectado a ninguna máquina virtual.
Consulte Montaje de disco estático de Azure como volumen.
Si ninguno de estos métodos funciona, puede usar las opciones de copia de seguridad y restauración.
Consulte Velero en Azure.
Archivos de Azure
A diferencia de los discos, Azure Files puede montarse simultáneamente en varios hosts. En el clúster de AKS,
Azure y Kubernetes no impiden crear un pod que el clúster de AKS siga usando. Para evitar la pérdida de datos y
un comportamiento inesperado, asegúrese de que los clústeres no escriben en los mismos archivos
simultáneamente.
Si la aplicación puede hospedar varias réplicas que apunten al mismo recurso compartido de archivos, siga los
pasos de la migración sin estado e implemente las definiciones de YAML en el nuevo clúster.
Si no es así, un posible enfoque de migración implica los pasos siguientes:
1. Compruebe que la aplicación funciona correctamente.
2. Apunte el tráfico en directo al nuevo clúster de AKS.
3. Desconecte el clúster anterior.
Si quiere comenzar con un recurso compartido vacío y luego realizar una copia de los datos de origen, puede
usar los comandos az storage file copy para migrar los datos.
Migración de volúmenes persistentes
Si migra volúmenes persistentes existentes a AKS, generalmente seguirá estos pasos:
1. Desactivar las escrituras en la aplicación.
Este paso es opcional y requiere tiempo de inactividad.
2. Tomar instantáneas de los discos.
3. Crear discos administrados nuevos a partir de las instantáneas.
4. Crear volúmenes persistentes en AKS.
5. Actualizar las especificaciones de pod para usar volúmenes existentes en lugar de PersistentVolumeClaims
(aprovisionamiento estático).
6. Implemente la aplicación en AKS.
7. Compruebe que la aplicación funciona correctamente.
8. Apunte el tráfico en directo al nuevo clúster de AKS.
IMPORTANT
Si decide no desactivar las escrituras, deberá replicar los datos en la nueva implementación. En caso contrario, perderá los
datos que se escriban después de tomar las instantáneas de disco.
Algunas herramientas de código abierto pueden ayudarle a crear discos administrados y a migrar volúmenes
entre clústeres de Kubernetes:
La extensión de copia de disco de la CLI de Azure copia y convierte los discos entre grupos de recursos y
regiones de Azure.
La extensión de la CLI de Azure Kube enumera los volúmenes de ACS Kubernetes y los migra a un clúster de
AKS.
Se recomienda usar la canalización existente de integración continua (CI) y entrega continua (CD) para
implementar una configuración válida conocida en AKS. Puede usar Azure Pipelines para compilar e
implementar las aplicaciones en AKS. Clone las tareas de implementación existentes y asegúrese de que
kubeconfig apunta al nuevo clúster de AKS.
Si no es posible, exporte las definiciones de recursos desde el clúster de Kubernetes existente y luego aplíquelas
a AKS. Puede usar kubectl para exportar objetos.
kubectl get deployment -o=yaml --export > deployments.yaml
Movimiento de recursos existentes a otra región

Puede que quiera trasladar el clúster de AKS a otra región compatible con AKS. Se recomienda crear un nuevo
clúster en la otra región e implementar los recursos y las aplicaciones en el nuevo clúster.
Además, si tiene servicios como Azure Dev Spaces en ejecución en el clúster de AKS, deberá instalar y configurar
esos servicios en el clúster en la nueva región.
En este artículo se proporciona un resumen de los detalles de la migración para:
Versiones de Kubernetes compatibles en Azure
La Comunidad de Kubernetes libera versiones secundarias aproximadamente cada tres meses. Recientemente, la
comunidad de Kubernetes ha aumentado el período de soporte técnico de todas las versiones de 9 a 12 meses,
a partir de la versión 1.19.
Las versiones secundarias incluyen nuevas características y mejoras. Las versiones de revisión son más
frecuentes (a veces semanales) y están previstas para correcciones de errores críticos en una versión secundaria.
Las versiones de revisión incluyen correcciones para vulnerabilidades de seguridad o errores importantes.
Versiones de Kubernetes
Kubernetes usa el esquema de versiones estándar de SemVer en todas las versiones:
[major].[minor].[patch]
Example:
1.17.7
1.17.8
Cada número en la versión indica compatibilidad general con la versión anterior:

Las versiones principales cambian cuando las actualizaciones de la API no son compatibles o la
compatibilidad con versiones anteriores deja de funcionar.
Las versiones secundarias cambian cuando se realizan actualizaciones de la funcionalidad que son
compatibles las versiones anteriores de las restantes versiones secundarias.
Las versiones de revisión cambian cuando se hacen correcciones de errores compatibles con versiones
anteriores.
El objetivo es ejecutar la versión de revisión más reciente de la versión secundaria que se ejecuta. Por ejemplo, el
clúster de producción está en 1.17.7 . 1.17.8 es la versión de revisión más reciente disponible para la
serie 1.17. Debe realizar la actualización a 1.17.8 lo antes posible para asegurarse de que el clúster tiene todas
las revisiones y es compatible.
Directiva de soporte técnico de versión de Kubernetes

AKS define una versión disponible con carácter general como una versión habilitada en todas las medidas del
SLO o SLA y disponible en todas las regiones. AKS es compatible con tres versiones secundarias en
disponibilidad general de Kubernetes:
La versión secundaria más reciente en disponibilidad general publicada en AKS (a la que nos referiremos
como N).
Dos versiones secundarias anteriores.
Cada versión secundaria compatible también admite un máximo de dos (2) revisiones estables.
AKS también puede admitir versiones preliminares que se etiquetan explícitamente y están sujetas a los
términos y condiciones de la versión preliminar.
NOTE
AKS usa prácticas de implementación segura que implican la implementación gradual de regiones. Esto significa que
pueden pasar hasta 10 días hábiles hasta que haya una nueva versión disponible en todas las regiones.
La ventana admitida de las versiones de Kubernetes en AKS se conoce como "N-2": (N [versión más reciente] - 2
[versiones secundarias]).
Por ejemplo, si AKS presenta 1.17.a hoy, también se proporciona compatibilidad para las versiones siguientes:
N UEVA VERSIÓ N SEC UN DA RIA L ISTA DE VERSIO N ES A DM IT IDA S
1.17.a 1.17.a, 1.17.b, 1.16.c, 1.16.d, 1.15.e, 1.15.f
Donde ".letter" es representativo de las versiones de revisión.

Cuando se introduce una nueva versión secundaria, la versión secundaria y la versión de revisión compatibles
más antiguas quedan obsoletas y se retiran. Por ejemplo, la lista de versiones que se admiten actualmente es:
1.17.a
1.17.b
1.16.c
1.16.d
1.15.e
1.15.f
Versiones 1.18.* de AKS, se eliminan todas las versiones 1.15.* que queden fuera del soporte técnico en 30 días.
NOTE
Si los clientes ejecutan una versión incompatible de Kubernetes, se les pedirá que la actualicen al solicitar soporte técnico
para el clúster. Los clústeres que ejecutan versiones de Kubernetes no admitidas no están cubiertos por el las directivas de
soporte técnico de AKS.
Además de lo anterior, AKS admite un máximo de dos versiones de revisión de una versión secundaria
determinada. Así pues, dadas las siguientes versiones admitidas:
Current Supported Version List

------------------------------
1.17.8, 1.17.7, 1.16.10, 1.16.9
Si AKS publica 1.17.9 y 1.16.11 , las versiones de revisión más antiguas quedan en desuso y se eliminan, y la
lista de versiones admitidas pasa a ser:
New Supported Version List

----------------------
1.17.*9*, 1.17.*8*, 1.16.*11*, 1.16.*10*
Versiones de kubectl admitidas

Puede usar una versión secundaria de kubectl que sea inmediatamente anterior o posterior a la versión de
kube-apiserver y que sea coherente con la directiva de compatibilidad de Kubernetes para kubectl.
Por ejemplo, si la versión de kube-apiserver es 1.17, puede usar las versiones de kubectl comprendidas entre
1.16 y 1.18 con esa versión de kube-apiserver.
Para instalar o actualizar la versión de kubectl , ejecute az aks install-cli .
Proceso de publicación y desuso

Puede consultar las próximas publicaciones de versiones y las que se quedarán obsoletas en el Calendario
publicación de AKS Kubernetes.
En el caso de las nuevas versiones secundarias de Kubernetes:
AKS publica un anuncio previo con la fecha planificada de la nueva publicación de una versión y el
respectivo desuso de una versión antigua en las notas de la versión de AKS al menos 30 días antes de la
eliminación.
AKS usa Azure Advisor alertar a los usuarios si una nueva versión causará problemas en su clúster
debido a las API en desuso. Azure Advisor también se usa para alertar al usuario si actualmente no tiene
soporte técnico.
AKS publica una notificación de estado del servicio disponible para todos los usuarios con acceso al
portal y AKS, y envía un correo electrónico a los administradores de suscripciones con las fechas de
eliminación de versión planeadas.
NOTE
Para averiguar quién es el administrador de la suscripción o cambiarlo, consulte Administración de suscripciones
de Azure.
Los usuarios tienen 30 días a partir de la eliminación de una versión para actualizar a una versión
secundaria compatible para seguir recibiendo soporte técnico.
En el caso de las nuevas versiones de revisión de Kubernetes:
Dada la naturaleza urgente de las versiones de revisión, se pueden introducir en el servicio en cuanto estén
disponibles.
En general, AKS no difunde profusamente el lanzamiento de las versiones de revisión. Sin embargo, AKS
supervisa y valida constantemente las revisiones de CVE disponibles para admitirlas en AKS de manera
puntual. Si se encuentra una revisión crítica o se requiere una acción del usuario, AKS enviará una
notificación a los usuarios para que actualicen a la revisión recién disponible.
Desde que se quita de AKS una versión de revisión los usuarios tienen 30 días para actualizarla a una
revisión compatible sin perder el soporte técnico.
Excepciones de directiva de versiones admitidas
AKS se reserva el derecho de agregar o eliminar las versiones nuevas o existentes con uno o varios problemas
de seguridad o errores críticos que afecten a la producción sin previo aviso.
Se pueden omitir versiones de revisión concretas o se puede acelerar su lanzamiento en función de la gravedad
del error o del problema de seguridad.
Versiones de Azure Portal y CLI

Cuando se implementa un clúster de AKS en Azure Portal o con la CLI de Azure, los valores predeterminados del
clúster son la versión secundaria n-1 y la revisión más reciente. Por ejemplo, si AKS admite 1.17.a, 1.17.b, 1.16.c,
1.16.d, 1.15.e y 1.15.f, la versión predeterminada seleccionada es la 1.16.c.
Para averiguar qué versiones están disponibles actualmente para su suscripción y región, utilice el comando az
aks get-versions. En el ejemplo siguiente se enumeran las versiones de Kubernetes disponibles para la región
EastUS :
az aks get-versions --location eastus --output table
Calendario de publicación de AKS Kubernetes

Para ver el historial de versiones anteriores, vea Kubernetes.
VERSIÓ N DISP O N IB IL IDA D F IN A L DE L A VIDA

VERSIÓ N DE K 8S VERSIÓ N A N T ERIO R P REL IM IN A R DE A K S GEN ERA L DE A K S ÚT IL
1.18 23 de marzo de 2020 Mayo de 2020 Agosto de 2020 1.21 disponibilidad

general
1.19 4 de agosto de 2020 Septiembre de 2020 Noviembre de 2020 1.22 disponibilidad

general
1.20 8 de diciembre de Enero de 2021 Marzo de 2021 1.23 Disponibilidad

2020 general
1.21 8 de abril de 2021 Mayo de 2021 Junio de 2021 1.24 disponibilidad

general

¿Cómo me notifica Microsoft las nuevas versiones de Kubernetes?
El equipo de AKS publica anuncios previos con las fechas planeadas de las nuevas versiones de Kubernetes en
nuestra documentación, en GitHub, así como en los correos electrónicos a los administradores de suscripciones
que poseen clústeres que van a dejar de recibir soporte técnico. Además de los anuncios, AKS también usa
Azure Advisor para notificar al cliente de Azure Portal que alerte a los usuarios si no tienen soporte técnico, así
como alertarlos de las API en desuso que afectarán a su aplicación o proceso de desarrollo.
¿Con qué frecuencia debo planear actualizar las versiones de Kubernetes para mantenerme con
sopor te técnico?
A partir de Kubernetes 1.19, la comunidad de código abierto ha ampliado el soporte técnico a 1 año. AKS se
compromete a habilitar unas revisiones y un soporte técnico que cumplan los compromisos ascendentes. En el
caso de los clústeres de AKS de la versión 1.19, y las versiones superiores, podrá actualizar al menos una vez al
año para permanecer en una versión con soporte técnico.
En el caso de las versiones 1.18, o anteriores, el período de soporte técnico permanece en 9 meses y será
preciso realizar una actualización cada 9 meses para permanecer en una versión con soporte técnico. Pruebe
con regularidad las nuevas versiones y esté preparado para actualizarse a versiones más recientes para
aprovechar las mejoras estables más recientes dentro de Kubernetes.
¿Qué ocurre cuando un cliente actualiza un clúster de Kubernetes con una versión secundaria que
no es compatible?
Si está en el versión n-3 o anterior, está fuera del soporte técnico y se le pedirá que la actualice. Si la
actualización de la versión n-3 a n-2 se completa correctamente, estará dentro de nuestras directivas de soporte
técnico. Por ejemplo:
Si la versión de AKS admitida más antigua es la 1.15.a y la suya es la 1.14.b o anterior, no es compatible.
Si la actualización de la versión 1.14.b a la 1.15.a, o a cualquier otra versión superior, se realiza
correctamente, estará de nuevo dentro de nuestras directivas de soporte técnico.
No se admite el cambio a una versión anterior.
¿Qué significa "fuera de sopor te técnico"?
"Fuera del soporte técnico" significa lo siguiente:
La versión que utiliza está fuera de la lista de versiones admitidas.
Se le pedirá que actualice el clúster a una versión compatible cuando solicite soporte técnico, a menos que
estén en el período de gracia de 30 días después de que la versión haya quedado en desuso.
Además, AKS no ofrece ningún entorno de ejecución ni otras garantías para los clústeres que estén fuera de la
lista de versiones admitidas.
¿Qué ocurre cuando un cliente escala un clúster de Kubernetes con una versión secundaria que no
es compatible?
Tanto la reducción como el escalado horizontales deberían seguir funcionando en las versiones secundarias que
no son compatibles con AKS. Dado que no hay garantías de Calidad de servicio, se recomienda realizar la
actualización para que el clúster vuelva tener soporte técnico.
¿Puede un cliente permanecer en una versión de Kubernetes para siempre?
Si un clúster ha estado sin soporte técnico durante más de tres (3) versiones secundarias y se ha descubierto
que presenta riesgos para la seguridad, Azure se pondrá en contacto con usted de forma proactiva para que lo
actualice con antelación. Si no hace nada, Azure se reserva el derecho de actualizar automáticamente el clúster
en su nombre.
¿Qué versión admite el plano de control si el grupo de nodos no está en una de las versiones de
AKS compatibles?
El plano de control debe estar dentro de una ventana de versiones de todos los grupos de nodos. Para obtener
más información sobre la actualización del plano de control o de los grupos de nodos, visite la documentación
sobre cómo actualizar grupos de nodos.
¿Puedo saltarme varias versiones de AKS durante la actualización del clúster?
Cuando se actualiza un clúster de AKS compatible, no pueden omitirse las versiones secundarias de Kubernetes.
Por ejemplo, las actualizaciones entre las siguientes versiones:
1.12.x -> 1.13.x: permitida.
1.13.x -> 1.14.x: permitida.
1.12.x -> 1.14.x: no permitida.
Para actualizar de 1.12.x -> 1.14.x:
1. Actualización de 1.12.x -> 1.14.x.
2. Actualización de 1.12.x -> 1.14.x.
Solo se pueden omitir varias versiones cuando se actualiza de una versión que no es compatible a otra que sí lo
es. Por ejemplo, puede realizar la actualización de la versión 1.10.x, que no es compatible, a la versión 1.15.x, que
lo es.
¿Puedo crear un nuevo clúster 1.xx.x durante su período de sopor te técnico de 30 días?
No. Una vez que una versión está en desuso o se ha quitado, no se puede crear un clúster con esa versión. A
medida que el cambio se implementa, comenzará a ver que la versión anterior se quita de la lista de versiones.
Este proceso puede tardar hasta dos semanas desde el anuncio, y será progresivo por región.
Utilizo una versión que acaba de entrar en desuso, ¿puedo seguir agregando nuevos grupos de
nodos o tendré que actualizar?
No. No se le permitirá agregar grupos de nodos de la versión en desuso al clúster. Puede agregar grupos de
nodos de una nueva versión. Sin embargo, puede requerir que primero actualice el plano de control.
Pasos siguientes
Para obtener información sobre cómo actualizar el clúster, vea Actualización de un clúster de Azure Kubernetes
Service (AKS).
Protección de seguridad para el sistema operativo
host del nodo del agente de AKS
Como servicio seguro, Azure Kubernetes Service (AKS) es compatible con los estándares SOC, ISO, PCI DSS e
HIPAA. En este artículo se explica la protección de la seguridad que se aplica a los hosts de máquina virtual de
AKS. Para más información acerca de la seguridad de AKS, consulte Conceptos de seguridad de las aplicaciones
y los clústeres en Azure Kubernetes Service (AKS).
NOTE
Este documento se limita a los agentes de Linux en AKS.
Los clústeres de AKS se implementan en máquinas virtuales de host, que ejecutan un sistema operativo
optimizado para la seguridad que se utiliza para los contenedores que se ejecutan en AKS. El sistema operativo
de este host se basa en una imagen de Ubuntu 16.04.LTS a la que se aplican optimizaciones y protecciones de
seguridad adicionales.
El objetivo del sistema operativo del host con protección de la seguridad es reducir el área expuesta de ataque y
optimizar la implementación de contenedores de forma segura.
IMPORTANT
El sistema operativo con protección de la seguridad no ha pasado el punto de referencia de CIS. Aunque hay
superposiciones con los puntos de referencia de CIS, el objetivo no es ser compatible con CIS. El objetivo de la protección
del sistema operativo del host es converger en un nivel de seguridad coherente con los estándares de seguridad del host
interno de Microsoft.
Características de la protección de la seguridad

AKS proporciona un sistema operativo de host optimizado para seguridad de manera predeterminada,
pero ninguna opción para seleccionar un sistema operativo alternativo.
Azure aplica revisiones diarias (lo que incluye revisiones de seguridad) a los hosts de máquina virtual de
AKS.
Algunas de estas revisiones requieren que se reinicie el equipo, pero otras no.
Usted es el responsable de programar los reinicios del host de máquina virtual de AKS cuando sea
necesario.
Para obtener instrucciones sobre cómo automatizar la aplicación de parches de AKS, consulte el
artículo acerca de la aplicación de parches a los nodos de AKS.
¿Qué se configura?
C IS DESC RIP C IÓ N DE L A A UDITO RÍA
1.1.1.1 Asegurarse de que el montaje de sistemas de archivos

cramfs está deshabilitado
1.1.1.2 Asegurarse de que el montaje de sistemas de archivos

freevxfs está deshabilitado
1.1.1.3 Asegurarse de que el montaje de sistemas de archivos jffs2

está deshabilitado
1.1.1.4 Asegurarse de que el montaje de sistemas de archivos HFS

está deshabilitado
1.1.1.5 Asegurarse de que el montaje de sistemas de archivos HFS

Plus está deshabilitado
1.4.3 Asegurarse de la autenticación que se requiere para el modo

de usuario único
1.7.1.2 Asegurarse de que el banner de advertencia de inicio de

sesión local está configurado correctamente
1.7.1.3 Asegurarse de que el banner de advertencia de inicio de

sesión remoto está configurado correctamente
1.7.1.5 Asegurarse de que están configurados los permisos

en/etc/issue
1.7.1.6 Asegurarse de que están configurados los permisos

en/etc/issue.net
2.1.5 Asegurarse de que el valor de --streaming-connection-idle-

timeout no es 0
3.1.2 Asegurarse de que el envío de redireccionamiento de

paquetes está deshabilitado
3.2.1 Asegurarse de que no se aceptan los paquetes enrutados de

origen
3.2.2 Asegurarse de que no se aceptan los redireccionamientos de

ICMP
3.2.3 Asegurarse de que no se aceptan los redireccionamientos de

ICMP seguros
3.2.4 Asegurarse de que se registran los paquetes sospechosos
3.3.1 Asegurarse de que no se aceptan anuncios de enrutadores

IPv6
3.5.1 Asegurarse de que DCCP está deshabilitado
3.5.2 Asegurarse de que SCTP está deshabilitado
3.5.3 Asegurarse de que RDS está deshabilitado

3.5.4 Asegurarse de que TIPC está deshabilitado
4.2.1.2 Asegurarse de que el registro está configurado
5.1.2 Asegurarse de que están configurados los permisos

en/etc/crontab
5.2.4 Asegurarse de que el reenvío de SSH X11 está deshabilitado
5.2.5 Asegúrese de que el valor de SSH MaxAuthTries es 4, o

menos
5.2.8 Asegurarse de que el inicio de sesión de la raíz de SSH está

deshabilitado
5.2.10 Asegúrese de que SSH PermitUserEnvironment está

deshabilitado
5.2.11 Asegurarse de que solo se usan algoritmos MAX aprobados
5.2.12 Asegúrese de que está configurado el intervalo de tiempo de

espera de inactividad de SSH
5.2.13 Asegúrese de que el valor de LoginGraceTime de SSH es un

minuto, o menos
5.2.15 Asegurarse de que está configurado el banner de

advertencia de SSH
5.3.1 Asegurarse de que están configurados los requisitos para la

creación de contraseñas
5.4.1.1 Asegurarse de que la contraseña expira en un plazo máximo

de 90 días
5.4.1.4 Asegurarse de que el plazo máximo del bloqueo de

contraseñas inactivas es 30 días
5.4.4 Asegurarse de que el umask de usuario predeterminado es

027, o incluso más restrictivo
5.6 Asegurarse de que está restringido el acceso al comando su
Notas adicionales
Para reducir aún más el área expuesta a ataques, se han deshabilitado en el sistema operativo algunos
controladores de módulos de kernel que no eran necesarios.
El sistema operativo con protección de seguridad se crea y se mantiene específicamente para AKS y no se
admite fuera de la plataforma AKS.
Pasos siguientes
Para más información acerca de la seguridad de AKS, consulte los siguientes artículos:
Consideraciones sobre la seguridad de AKS
Procedimientos recomendados para AKS
Introducción a los diagnósticos de Azure
Kubernetes Service (versión preliminar)
La solución de problemas de clústeres de Azure Kubernetes Service (AKS) desempeña un papel importante en el
mantenimiento de su clúster, especialmente si este ejecuta cargas de trabajo críticas. AKS Diagnostics es una
experiencia de autodiagnóstico inteligente que:
Le ayuda a identificar y resolver problemas en el clúster.
Es nativa de la nube.
No requiere configuración adicional ni acarrea costos de facturación.
Esta característica ahora está en versión preliminar pública.
Abrir AKS Diagnostics

Para acceder a AKS Diagnostics:
1. Vaya a su clúster de Kubernetes en Azure Portal.
2. En el panel izquierdo, haga clic en Diagnosticar y solucionar problemas , lo que abrirá AKS Diagnostics.
3. Elija la categoría que describa mejor el problema del clúster, como Problemas del nodo de clúster, de estas
formas:
Use las palabras clave del icono de la página principal.
Escriba una palabra clave que describa mejor el problema en la barra de búsqueda.
Visualización de un informe de diagnóstico

Después de hacer clic en una categoría, podrá ver un informe de diagnóstico específico del clúster. Los informes
de diagnóstico señalan de forma inteligente los problemas del clúster con iconos de estado. Puede hacer clic en
Más información para explorar en profundidad cada tema para ver una descripción detallada de lo siguiente:
Issues
Acciones recomendadas
Vínculos a documentos útiles
Métricas relacionadas
Registrar datos
Los informes de diagnóstico se generan en función del estado actual del clúster después de ejecutar diversas
comprobaciones. Pueden ser útiles para identificar el problema del clúster y entender los pasos siguientes para
resolver el problema.
Información de clúster
Las siguientes comprobaciones de diagnóstico están disponibles en Información de clúster .
Problemas del nodo de clúster
Problemas del nodo de clúster comprueba la existencia de problemas relacionados con el nodo que hacen que
el clúster se comporte de forma inesperada.
Problemas de preparación del nodo
Errores del nodo
No hay suficientes recursos
El nodo no cuenta con una dirección IP configurada
Errores de CNI del nodo
Nodo no encontrado
Nodo apagado
Error de autenticación del nodo
Proxy de kube del nodo obsoleto
Operaciones de creación, lectura, actualización y eliminación (CRUD)
Las operaciones de CRUD comprueban si alguna de estas operaciones causa problemas en su clúster.
Error de operación de eliminación de subred en uso
Estado de operación de eliminación del grupo de seguridad de red
Error de operación de eliminación de la tabla de rutas en uso
Error de aprovisionamiento de recursos a los que se hace referencia
Error de operación de eliminación de dirección IP pública
Error de implementación debido a la cuota de implementación
Error de operación debido a la directiva de la organización
Falta de registro de suscripción
Error de aprovisionamiento de la extensión de máquina virtual
Capacidad de subred
Cuota de errores superada
Administración de identidades y seguridad
La administración de identidades y seguridad detecta errores de autenticación y autorización que impiden la
comunicación con el clúster.
Errores de autorización de nodo
401 errores
403 errores
Pasos siguientes
Recopile registros para ayudarle a solucionar los problemas de los clústeres mediante el uso de AKS
Periscope.
Lea la sección Prácticas de evaluación de prioridades de la guía de operaciones del día 2 de AKS.
Publique sus preguntas o comentarios en UserVoice agregando "[Diag]" en el título.
Principios de ingeniería de software sostenible en
Azure Kubernetes Services (AKS)
Los principios de ingeniería de software sostenible son un conjunto de competencias que le ayudarán a definir,
crear y ejecutar aplicaciones sostenibles. El objetivo general es reducir la huella de carbono de cada aspecto de
la aplicación. Los principios de ingeniería de software sostenible incluyen una visión general de estos principios.
La ingeniería de software sostenible supone un cambio de prioridades y de enfoque. En muchos casos, la forma
en que se diseña y ejecuta la mayoría del software prioriza un rendimiento rápido y una latencia baja. Por su
parte, la ingeniería de software sostenible se centra en reducir las emisiones de carbono tanto como sea posible.
Considere:
La aplicación de principios de ingeniería de software sostenible puede proporcionar un rendimiento más
rápido o una menor latencia, por ejemplo, reduciendo el recorrido total de la red.
Reducir las emisiones de carbono puede ralentizar el rendimiento o aumentar la latencia, como el retraso de
las cargas de trabajo de prioridad baja.
Antes de aplicar principios de ingeniería de software sostenible a una aplicación, revise las prioridades, las
necesidades y las ventajas e inconvenientes de su aplicación.
Medición y optimización
Para reducir la huella de carbono de los clústeres de AKS, necesita comprender cómo se usan los recursos del
clúster. Azure Monitor proporciona detalles sobre el uso de recursos del clúster, como pueden ser el uso de
memoria y la CPU. Estos datos fundamentan su decisión de reducir la huella de carbono del clúster y reflejan el
efecto de los cambios.
También puede instalar Microsoft Sustainability Calculator para ver la huella de carbono de todos los recursos
de Azure.
Aumento de la utilización de recursos

Un enfoque para reducir la huella de carbono es reducir el tiempo de inactividad. Reducir el tiempo de
inactividad implica aumentar el uso de los recursos de proceso. Por ejemplo:
1. Suponga que tenía cuatro nodos en el clúster, todos funcionando al 50 % de su capacidad. Por tanto, los
cuatro nodos tenían un 50 % de capacidad sin usar inactiva.
2. Decide reducir el clúster a tres nodos, cada uno funcionando al 67 % de capacidad con la misma carga de
trabajo. Así lograría reducir la capacidad sin usar en un 33 % en cada nodo e incrementaría su uso.
IMPORTANT
Al considerar la posibilidad de cambiar los recursos del clúster, compruebe que los grupos del sistema tengan suficientes
recursos para mantener la estabilidad de los componentes principales del sistema del clúster. No reduzca nunca los
recursos del clúster hasta el punto en el que el clúster pueda volverse inestable.
Después de revisar el uso del clúster, considere la posibilidad de usar las características que varios grupos de
nodos ofrecen:
Ajuste de tamaño del nodo
Use el ajuste de tamaño de nodo para definir grupos de nodos con perfiles de CPU y de memoria
específicos, lo que le permite adaptar los nodos a sus necesidades de carga de trabajo. Al ajustar el
tamaño de los nodos a sus necesidades de carga de trabajo, puede ejecutar unos cuantos nodos con un
uso mayor.
Escalado de clústeres
Configure el modo en que el clúster se escala. Use el escalador automático de pod horizontal y el
escalador automático de clúster para escalar el clúster automáticamente en función de la configuración.
Controle el modo en que el clúster se escala para mantener todos los nodos en ejecución con un uso
elevado y, al mismo tiempo, mantener sincronizados los cambios en la carga de trabajo del clúster.
Grupos de acceso puntual
En los casos en los que una carga de trabajo es tolerante a interrupciones o finalizaciones repentinas,
puede usar grupos de acceso puntual. Estos grupos aprovechan la capacidad inactiva en Azure. Por
ejemplo, los grupos de acceso puntual pueden funcionar bien para los trabajos por lotes o los entornos
de desarrollo.
NOTE
Aumentar la utilización también puede reducir el exceso de nodos, lo que disminuye la energía consumida por las reservas
de recursos en cada nodo.
Por último, revise las solicitudes y los límites de la CPU y la memoria en los manifiestos de Kubernetes de las
aplicaciones.
A medida que reduce los valores para la memoria y la CPU, hay más memoria y CPU disponibles para el
clúster para ejecutar otras cargas de trabajo.
A medida que ejecuta más cargas de trabajo con menor CPU y memoria, su clúster se asigna más
densamente, lo que aumenta su utilización.
Al reducir la CPU y la memoria para las aplicaciones, el comportamiento de estas se puede degradar o pasar a
ser inestable si establece unos valores para la memoria y la CPU demasiado bajos. Antes de cambiar las
solicitudes y los límites de la CPU y la memoria, ejecute algunas pruebas comparativas para comprobar si los
valores están establecidos correctamente. No reduzca nunca estos valores hasta un punto en que la aplicación
se vuelva inestable.
Reducción del viaje de red

Al reducir la distancia que recorren las solicitudes y respuestas hacia y desde el clúster, puede reducir las
emisiones de carbono y el consumo de electricidad de los dispositivos de red. Después de revisar el tráfico de
red, considere la posibilidad de crear clústeres en regiones más cerca del origen del tráfico de red. Puede usar
Azure Traffic Manager para enrutar el tráfico al clúster más cercano y los grupos con ubicación por proximidad
para reducir la distancia entre los recursos de Azure.
IMPORTANT
Al considerar la posibilidad de realizar cambios en las redes del clúster, no reduzca nunca el viaje de red a costa de cumplir
los requisitos de la carga de trabajo. Por ejemplo, el uso de zonas de disponibilidad provoca más viaje de red en el clúster,
pero es posible que sean necesarias para controlar los requisitos de la carga de trabajo.
Modelado de la demanda
Siempre que sea posible, considere la posibilidad de cambiar la demanda de los recursos del clúster a las horas
o regiones en las que puede usar exceso de capacidad. Por ejemplo, considere lo siguiente:
Cambiar la hora o la región de ejecución de un trabajo por lotes.
Usar grupos de acceso puntual.
Refactorizar la aplicación para usar una cola para diferir las cargas de trabajo en ejecución que no necesitan
un procesamiento inmediato.
Pasos siguientes
Más información acerca de las siguientes características de AKS mencionadas en este artículo:
Varios grupos de nodos
Ajuste de tamaño del nodo
Escala de un clúster
Escalador automático horizontal de pod
Cluster Autoscaler
Grupos de acceso puntual
Grupos del sistema
Reservas de recursos
Grupos con ubicación por proximidad
Zonas de disponibilidad
Escalación del número de nodos en un clúster de
Si las necesidades del recurso de las aplicaciones cambian, puede escalar manualmente un clúster de AKS para
ejecutar un número diferente de nodos. Durante la reducción vertical, los nodos se acordonarán y vaciarán
minuciosamente para minimizar las interrupciones en las aplicaciones en ejecución. Durante el escalado vertical,
AKS espera hasta que el clúster de Kubernetes marca los nodos como Ready antes de que se programen pods
en ellos.
Escalado de los nodos de clúster

En primer lugar, obtenga el nombre del grupo de nodos con el comando az aks show. En el ejemplo siguiente se
obtiene el nombre del grupo de nodos del clúster denominado myAKSCluster en el grupo de recursos
myResourceGroup:
az aks show --resource-group myResourceGroup --name myAKSCluster --query agentPoolProfiles
La salida de ejemplo siguiente muestra que el nombre es nodepool1:
[
{
"count": 1,
"maxPods": 110,
"osDiskSizeGb": 30,
"osType": "Linux",
"vmSize": "Standard_DS2_v2"
}
]
Use el comandoaz aks scale para escalar los nodos de clúster. En el siguiente ejemplo, se escala un clúster
denominado myAKSCluster en un único nodo. Proporcione su propio valor para --nodepool-name del comando
anterior, como nodepool1:
az aks scale --resource-group myResourceGroup --name myAKSCluster --node-count 1 --nodepool-name <your node
pool name>
La siguiente salida de ejemplo muestra que el clúster ha escalado correctamente a un nodo, como se muestra en
la sección agentPoolProfiles:
{
"aadProfile": null,
"addonProfiles": null,
{
"count": 1,
"maxPods": 110,
"osDiskSizeGb": 30,
"osType": "Linux",
}
],
[...]
}
Escalado de grupos de nodos de User a0

A diferencia de los grupos de nodos de System que siempre requieren nodos en ejecución, los grupos de nodos
de User permiten escalar a 0. Para obtener más información sobre las diferencias entre los grupos de nodos de
sistema y de usuario, consulte Grupos de nodos del sistema y del usuario.
Para escalar un grupo de usuarios a 0, puede usar az aks nodepool scale como alternativa al comando anterior
az aks scale y establecer 0 como recuento de nodos.
az aks nodepool scale --name <your node pool name> --cluster-name myAKSCluster --resource-group
myResourceGroup --node-count 0
También puede escalar automáticamente grupos de nodos de User a 0 nodos; para ello, establezca el
parámetro --min-count del escalador automático del clúster en 0.
Pasos siguientes
En este artículo, escaló manualmente un clúster de AKS para aumentar o disminuir el número de nodos.
También puede usar el escalador automático del clúster para escalar automáticamente el clúster.
Inicio y detención de un clúster de
Es posible que las cargas de trabajo de AKS no tengan que ejecutarse continuamente, por ejemplo, en el caso de
un clúster de desarrollo que se use solo durante el horario comercial. Esto se traduce en momentos en que el
clúster de Azure Kubernetes Service (AKS) podría estar inactivo, sin ejecutar más que los componentes del
sistema. Para reducir la superficie del clúster, escale todos los grupos de nodos User a 0, aunque sigue siendo
necesario que el grupo System ejecute los componentes del sistema mientras el clúster está en ejecución. Para
optimizar aún más los costos durante estos períodos, puede desactivar por completo (detener) el clúster. Esta
acción detiene el plano de control y los nodos del agente, lo que permite ahorrar en todos los costos de proceso,
a la vez que se mantienen todos los objetos y el estado del clúster almacenados para cuando se inicie de nuevo.
Puede continuar justo donde se ha dejado después de un fin de semana o hacer que el clúster se ejecute solo
mientras se ejecutan los trabajos por lotes.
Antes de empezar
En este artículo se supone que ya tiene un clúster de AKS. Si necesita un clúster de AKS, consulte el inicio rápido
de AKS mediante la CLI de Azure o mediante Azure Portal.
Limitaciones
Cuando se usa la característica de inicio o detención del clúster, se aplican las restricciones siguientes:
Esta característica solo se admite para clústeres respaldados por Virtual Machine Scale Sets.
El estado de clúster de un clúster de AKS detenido se conserva durante un máximo de 12 meses. Si el clúster
se detiene durante más de 12 meses, no se puede recuperar su estado. Para obtener más información, vea
Directivas de soporte técnico para AKS.
Solo puede iniciar o eliminar un clúster de AKS detenido. Para realizar cualquier operación, como escalado o
actualización, primero inicie el clúster.
Detención de un clúster de AKS

Puede usar el comando az aks stop para detener los nodos y el plano de control de un clúster de AKS en
ejecución. En el siguiente ejemplo se detiene un clúster denominado myAKSCluster:
az aks stop --name myAKSCluster --resource-group myResourceGroup
Para comprobar que el clúster se ha detenido, use el comando az aks show y confirme que powerState aparece
como Stopped en la siguiente salida:
{
[...]
"nodeResourceGroup": "MC_myResourceGroup_myAKSCluster_westus2",
"powerState":{
"code":"Stopped"
},
"privateFqdn": null,
"resourceGroup": "myResourceGroup",
[...]
}
Si provisioningState muestra Stopping , significa que el clúster aún no se ha detenido por completo.
IMPORTANT
Si usa presupuestos de interrupciones de pods, la operación de detención puede tardar más tiempo, ya que el proceso de
purga tarda más en finalizar.
Inicio de un clúster de AKS

Puede usar el comando az aks start para iniciar los nodos y el plano de control de un clúster de AKS detenido.
El clúster se reinicia con el estado del plano de control y el número de nodos de agente anteriores.
En el siguiente ejemplo se inicia un clúster denominado myAKSCluster:
az aks start --name myAKSCluster --resource-group myResourceGroup
Para comprobar que el clúster se ha iniciado, use el comando az aks show y confirme que powerState aparece
como Running en la siguiente salida:
{
[...]
"nodeResourceGroup": "MC_myResourceGroup_myAKSCluster_westus2",
"powerState":{
"code":"Running"
},
[...]
}
Si provisioningState muestra Starting , significa que el clúster aún no se ha iniciado por completo.
Pasos siguientes
Para obtener información sobre cómo escalar grupos User a 0, vea Escalado de grupos User a 0.
Para obtener información sobre cómo ahorrar costos mediante instancias de acceso puntual, vea
Incorporación de un grupo de nodos de acceso puntual a AKS.
Para obtener más información sobre las directivas de soporte técnico de AKS, vea Directivas de soporte
técnico de AKS.
Uso del mantenimiento planeado a fin de
programar ventanas de mantenimiento para el
clúster de Azure Kubernetes Service (AKS) (versión
preliminar)
El clúster de AKS tiene un mantenimiento periódico que se realiza automáticamente. De manera

predeterminada, este trabajo puede producirse en cualquier momento. El mantenimiento planeado le permite
programar ventanas de mantenimiento semanales que actualizarán el plano de control, así como los pods del
sistema Kube en una instancia de VMSS y minimizar el impacto en la carga de trabajo. Una vez programado,
todo el mantenimiento se realizará durante la ventana seleccionada. Puede programar una o varias ventanas
semanales en el clúster especificando un día o un intervalo de tiempo en un día concreto. Las ventanas de
mantenimiento se configuran mediante la CLI de Azure.
Antes de empezar
IMPORTANT
Las características en versión preliminar de AKS están disponibles como opción de participación y autoservicio. Las
versiones preliminares se proporcionan "tal cual" y "como están disponibles", y están excluidas de los Acuerdos de nivel de
servicio y la garantía limitada. Las versiones preliminares de AKS reciben cobertura parcial del soporte al cliente en la
medida de lo posible. Por lo tanto, estas características no están diseñadas para su uso en producción. Las características
en versión preliminar de AKS no están disponibles en nubes de Azure Government ni Azure China 21Vianet. Para más
información, consulte los siguientes artículos de soporte:
Directivas de soporte técnico para AKS
Preguntas más frecuentes de Soporte técnico de Azure
Limitaciones
Al utilizar el mantenimiento planeado, se aplican las restricciones siguientes:
AKS se reserva el derecho de interrumpir estas ventanas para las operaciones de mantenimiento no
planeadas y reactivas que sean urgentes o críticas.
Actualmente, la realización de operaciones de mantenimiento se considera solo el mejor esfuerzo y no se
garantiza que se produzcan en una ventana especificada.
Las actualizaciones no se pueden bloquear durante más de siete días.
Instalación de la extensión aks-preview de la CLI
También se necesita la versión 0.5.4 o posterior de la extensión de la CLI de Azure aks-preview . Instale la
extensión de la CLI de Azure aks-preview mediante el comando az extension add. También puede instalar las
actualizaciones disponibles mediante el comando az extension update.
# Install the aks-preview extension
az extension add --name aks-preview
# Update the extension to make sure you have the latest version installed
az extension update --name aks-preview
Permitir mantenimiento cada lunes de 1:00 a. m. a 2:00 a. m.

Para agregar una ventana de mantenimiento, puede usar el comando az aks maintenanceconfiguration add .
IMPORTANT
Las ventanas de mantenimiento planeado se especifican en hora universal coordinada (UTC).
az aks maintenanceconfiguration add -g MyResourceGroup --cluster-name myAKSCluster --name default --weekday

Monday --start-hour 1
En la salida de ejemplo siguiente se muestra la ventana de mantenimiento de 1:00 a. m. a 2:00 a. m. todos los
lunes.
{- Finished ..
"id":
"/subscriptions/<subscriptionID>/resourcegroups/MyResourceGroup/providers/Microsoft.ContainerService/managed
Clusters/myAKSCluster/maintenanceConfigurations/default",
"name": "default",
"notAllowedTime": null,
"systemData": null,
"timeInWeek": [
{
"day": "Monday",
"hourSlots": [
1
]
}
],
"type": null
}
Para permitir el mantenimiento a cualquier hora del día, omita el parámetro start-hour. Por ejemplo, el comando
siguiente establece la ventana de mantenimiento del día completo todos los lunes:
az aks maintenanceconfiguration add -g MyResourceGroup --cluster-name myAKSCluster --name default --weekday

Monday
Incorporación de una configuración de mantenimiento con un archivo

JSON
También puede usar un archivo JSON para crear una ventana de mantenimiento en lugar de usar parámetros.
Cree un archivo test.json con el siguiente contenido:
{
"timeInWeek": [
{
"day": "Tuesday",
"hour_slots": [
1,
2
]
},
{
"day": "Wednesday",
"hour_slots": [
1,
6
]
}
],
"notAllowedTime": [
{
"start": "2021-05-26T03:00:00Z",
"end": "2021-05-30T12:00:00Z"
}
]
}
El archivo JSON anterior especifica las ventanas de mantenimiento cada martes de 1:00 a. m. a 3:00 a. m. y
todos los miércoles de 1:00 a. m. a 2:00 a. m. y de 6:00 a. m. a 7:00 a. m. También hay una excepción de 2021-
05-26T03:00:00Z a 2021-05-30T12:00:00Z, donde no se permite el mantenimiento, incluso si se superpone a
una ventana de mantenimiento. El comando siguiente agrega las ventanas de mantenimiento de test.json .
az aks maintenanceconfiguration add -g MyResourceGroup --cluster-name myAKSCluster --name default --config-

file ./test.json
Actualización de una ventana de mantenimiento existente

Para actualizar una configuración de mantenimiento existente, use el comando
az aks maintenanceconfiguration update .
az aks maintenanceconfiguration update -g MyResourceGroup --cluster-name myAKSCluster --name default --

weekday Monday --start-hour 1
Enumeración de todas las ventanas de mantenimiento en un clúster

existente
Para ver todas las ventanas de configuración de mantenimiento actuales en el clúster de AKS, use el comando
az aks maintenanceconfiguration list .
az aks maintenanceconfiguration list -g MyResourceGroup --cluster-name myAKSCluster
En la salida siguiente, puede ver que hay dos ventanas de mantenimiento configuradas para myAKSCluster. Una
ventana está para el lunes a la 1:00 a. m. y la otra para el viernes a las 4:00 a. m.
[
{
"id":
"name": "default",
"systemData": null,
"timeInWeek": [
{
"day": "Monday",
"hourSlots": [
1
]
}
],
"type": null
},
{
"id":
Clusters/myAKSCluster/maintenanceConfigurations/testConfiguration",
"name": "testConfiguration",
"systemData": null,
"timeInWeek": [
{
"day": "Friday",
"hourSlots": [
4
]
}
],
"type": null
}
]
Muestra de una ventana de configuración de mantenimiento

específica en un clúster de AKS
Para ver una ventana de configuración de mantenimiento específica en el clúster de AKS, use el comando
az aks maintenanceconfiguration show .
az aks maintenanceconfiguration show -g MyResourceGroup --cluster-name myAKSCluster --name default
En la salida de ejemplo siguiente se muestra la ventana de mantenimiento para default:

{
"id":
"name": "default",
"systemData": null,
"timeInWeek": [
{
"day": "Monday",
"hourSlots": [
1
]
}
],
"type": null
}
Eliminación de una determinada ventana de configuración de

mantenimiento en un clúster de AKS existente
Para eliminar una ventana de configuración de mantenimiento determinada en el clúster de AKS, use el
comando az aks maintenanceconfiguration delete .
az aks maintenanceconfiguration delete -g MyResourceGroup --cluster-name myAKSCluster --name default
Pasos siguientes
Para empezar a actualizar el clúster de AKS, vea Actualización de un clúster de Azure Kubernetes Service
(AKS).
Actualización de un clúster de Azure Kubernetes
Service (AKS)
Parte del ciclo de vida del clúster de AKS implica efectuar actualizaciones periódicas a la versión más reciente de
Kubernetes. Es importante que aplique las versiones de seguridad más recientes o que actualice el software para
obtener las últimas características. En este artículo se muestra cómo actualizar los componentes principales o un
único grupo de nodos predeterminado en un clúster de AKS.
Para los clústeres de AKS que usan varios grupos de nodos o nodos de Windows Server, consulte Actualización
de un grupo de nodos en AKS.
Antes de empezar
Para este artículo es preciso usar la versión 2.0.65 de la CLI de Azure, o cualquier versión posterior. Ejecute
WARNING
Una actualización del clúster de AKS desencadena un acordonamiento y purga de los nodos. Si tiene una cuota de
proceso baja disponible, se puede producir un error en la actualización. Para más información, consulte Solicitudes de
aumento de cuota.
Compruebe las actualizaciones disponibles del clúster de AKS

Para comprobar qué versiones de Kubernetes están disponibles para su clúster, use el comando az aks get-
upgrades. En el siguiente ejemplo se comprueban las actualizaciones disponibles para myAKSCluster en
myResourceGroup:
az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table
NOTE
Cuando se actualiza un clúster de AKS compatible, no pueden omitirse las versiones secundarias de Kubernetes. Todas las
actualizaciones deben realizarse secuencialmente con arreglo al número de versión principal. Por ejemplo, las
actualizaciones comprendidas entre 1.14.x -> 1.15.x o 1.15.x -> 1.16.x están permitidas, pero las comprendidas entre
1.14.x -> 1.16.x no lo están.
Solo se pueden omitir varias versiones al actualizar de una versión que no es compatible a una versión compatible.
Por ejemplo, se puede efectuar una actualización de una versión 1.10.x no compatible a una versión 1.15.x compatible.
La siguiente salida de ejemplo muestra que el clúster se puede actualizar a las versiones 1.19.1 y 1.19.3:
Name ResourceGroup MasterVersion Upgrades

------- --------------- --------------- --------------
default myResourceGroup 1.18.10 1.19.1, 1.19.3
Si no hay ninguna actualización disponible, verá el mensaje:
ERROR: Table output unavailable. Use the --query option to specify an appropriate query. Use --debug for
more info.
Personalización de la actualización de sobrecargas de nodo

IMPORTANT
Los sobrecargas de nodo requieren la cuota de suscripción para el recuento máximo de sobrecargas solicitado para cada
operación de actualización. Por ejemplo, un clúster con 5 grupos de nodos, cada uno con un recuento de 4 nodos, tiene
un total de 20 nodos. Si cada grupo de nodos tiene un valor de sobrecarga máxima del 50 %, se requiere un proceso
adicional y una cuota de IP de 10 nodos (2 nodos x 5 grupos) para completar la actualización.
Si usa Azure CNI, compruebe que haya direcciones IP disponibles en la subred, además de cumplir los requisitos de
direcciones IP de Azure CNI.
De forma predeterminada, AKS configura las actualizaciones para la sobrecarga con un nodo adicional. Un valor
predeterminado de uno para la configuración de sobrecarga máxima permitirá a AKS minimizar la interrupción
de la carga de trabajo mediante la creación de un nodo adicional antes de acordonar o purgar las aplicaciones
existentes para reemplazar un nodo de una versión anterior. El valor de sobrecarga máxima se puede
personalizar por grupo de nodos para permitir un equilibrio entre la velocidad de actualización y la interrupción
de la actualización. Al aumentar el valor de sobrecarga máxima, el proceso de actualización se completa más
rápido, pero si se establece un valor alto para la sobrecarga máxima, pueden producirse interrupciones durante
el proceso de actualización.
Por ejemplo, un valor de sobrecarga máxima del 100 % proporciona el proceso de actualización más rápido
posible (se duplica el número de nodos), pero también hace que todos los nodos del grupo de nodos se
purguen simultáneamente. Es posible que desee usar un valor más alto, como este, para los entornos de prueba.
En el caso de los grupos de nodos de producción, se recomienda un valor de sobrecarga máxima del 33 %.
AKS acepta valores enteros y un valor de porcentaje para la sobrecarga máxima. Un entero como "5" indica
cinco nodos adicionales para la sobrecarga. Un valor de "50 %" indica un valor de sobrecarga de la mitad del
número de nodos actual del grupo. Los valores de porcentaje de sobrecarga máxima pueden ser de 1 % como
mínimo y 100 % como máximo. Un valor de porcentaje se redondea al número de nodos más próximo. Si el
valor de sobrecarga máxima es inferior al número de nodos actual en el momento de la actualización, el número
de nodos actual se usa para el valor de sobrecarga máxima.
Durante una actualización, el valor de sobrecarga máxima puede ser 1 como mínimo y un valor igual al número
de nodos del grupo de nodos como máximo. Puede establecer valores mayores, pero el número máximo de
nodos que se usan para la sobrecarga máxima no será mayor que el número de nodos del grupo en el
momento de la actualización.
IMPORTANT
La configuración de sobrecarga máxima en un grupo de nodos es permanente. Las actualizaciones posteriores de
Kubernetes o las actualizaciones de la versión de nodo usarán esta configuración. Puede cambiar el valor de sobrecarga
máxima para los grupos de nodos en cualquier momento. En el caso de los grupos de nodos de producción, se
recomienda un valor de sobrecarga máxima del 33 %.
Use los siguientes comandos para establecer los valores de sobrecarga máxima para los grupos de nodos
nuevos o existentes.
# Set max surge for a new node pool
az aks nodepool add -n mynodepool -g MyResourceGroup --cluster-name MyManagedCluster --max-surge 33%
# Update max surge for an existing node pool

az aks nodepool update -n mynodepool -g MyResourceGroup --cluster-name MyManagedCluster --max-surge 5
Actualización de un clúster de AKS

Con una lista de las versiones disponibles para el clúster de AKS, use el comando az aks upgrade para realizar la
actualización. Durante el proceso de actualización, AKS se ocupará de lo siguiente:
Agregar un nuevo nodo de búfer (o tantos nodos como se hayan configurado en sobrecarga máxima) al
clúster que ejecuta la versión especificada de Kubernetes.
Acordonar y purgar uno de los nodos antiguos para minimizar la interrupción de las aplicaciones en
ejecución. Si se usa la sobrecarga máxima, acordonará y purgará tantos nodos al mismo tiempo como el
número de nodos de búfer que se haya especificado.
Cuando el nodo anterior se ha purgado por completo, se restablecerá la imagen inicial para recibir la nueva
versión y se convertirá en el nodo de búfer para el siguiente nodo que se va a actualizar.
Este proceso se repite hasta que se hayan actualizado todos los nodos del clúster.
Al final del proceso, se eliminará el último nodo del búfer, manteniendo el número de nodos de agente
existentes, así como el equilibrio de zona.
az aks upgrade \
--kubernetes-version KUBERNETES_VERSION
Dicha actualización tarda varios minutos. El tiempo exacto dependerá del número de nodos que tenga.
IMPORTANT
Asegúrese de que cualquier PodDisruptionBudgets (PDB) permita que se mueva al menos una réplica de pod a la vez;
en caso contrario, se producirá un error en la operación de purga o expulsión. Si se produce un error en la operación de
purga, se producirá un error por diseño en la operación de actualización para garantizar que no se interrumpan las
aplicaciones. Corrija lo que hizo que se detuviese la operación (PDB incorrectos, falta de cuota, etc.) y vuelva a intentar la
operación.
Para confirmar que la actualización se ha realizado correctamente, use el comando az aks show:
az aks show --resource-group myResourceGroup --name myAKSCluster --output table
En la salida de ejemplo siguiente se muestra que el clúster ahora ejecuta la versión 1.18.10:
Name Location ResourceGroup KubernetesVersion ProvisioningState Fqdn

------------ ---------- --------------- ------------------- ------------------- -----------------------
-----------------------
myAKSCluster eastus myResourceGroup 1.18.10 Succeeded myakscluster-dns-
379cbbb9.hcp.eastus.azmk8s.io
Establecimiento de un canal de actualización automática

Además de actualizar manualmente un clúster, puede establecer un canal de actualización automática en el
clúster. Están disponibles los siguientes canales de actualización:
CANAL A C C IÓ N E JEM P LO
none Deshabilita las actualizaciones Si no se hacen cambios, se usa la

automáticas y mantiene la versión configuración predeterminada.
actual del clúster de Kubernetes.
patch Actualiza automáticamente el clúster a Por ejemplo, si un clúster ejecuta la

la última versión de revisión versión 1.17.7 y las versiones 1.17.9,
compatible cuando esté disponible, 1.18.4, 1.17.9 y 1.19.1 están
mientras se mantiene la misma versión disponibles, se actualizará a la 1.18.6.
secundaria.
stable Actualiza automáticamente el clúster a Por ejemplo, si un clúster ejecuta la

la última versión de revisión versión 1.17.7 y las versiones 1.17.9,
compatible en la versión secundaria N- 1.18.4, 1.18.6 y 1.19.1 están
1, donde N es la última versión disponibles, el clúster se actualiza a
secundaria compatible. 1.18.6.
rapid Actualiza automáticamente el clúster a En los casos en los que el clúster está
la última versión de revisión en una versión de Kubernetes que se
compatible en la última versión encuentra en una versión secundaria
secundaria compatible. N-2 donde N es la última versión
secundaria, el clúster se actualiza
primero a la última versión de revisión
compatible en la versión secundaria N-
1. Por ejemplo, si un clúster ejecuta la
versión 1.17.7 y las versiones 1.17.9,
1.18.4, 1.18.6 y 1.19.1 están
disponibles, el clúster se actualiza
primero a 1.18.6 y, a continuación, se
actualiza a 1.19.1.
node-image Actualiza automáticamente la imagen Microsoft proporciona revisiones e

de nodo a la última versión disponible. imágenes nuevas para los nodos de
imagen con frecuencia (normalmente,
semanalmente), pero los nodos en
ejecución no obtienen las nuevas
imágenes, a menos que realice una
actualización de la imagen de nodo. Al
activar el canal node-image, se
actualizarán automáticamente las
imágenes de nodo cada vez que haya
disponible una nueva versión.
NOTE
La actualización automática del clúster solo se actualiza a las versiones de disponibilidad general de Kubernetes y no se
actualizará a las versiones preliminares.
La actualización automática de un clúster sigue el mismo proceso que la manual. Para obtener más detalles,
consulte Actualización de un clúster de AKS.
La actualización automática del clúster para los clústeres de AKS es una característica en vista previa (GB).
IMPORTANT
Registre la marca de la característica AutoUpgradePreview con el comando az feature register, como se muestra
en el siguiente ejemplo:
az feature register --namespace Microsoft.ContainerService -n AutoUpgradePreview
Tarda unos minutos en que el estado muestre Registrado. Puede comprobar el estado de registro con el
comando az feature list:
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/AutoUpgradePreview')].

{Name:name,State:properties.state}"
Cuando haya terminado, actualice el registro del proveedor de recursos Microsoft.ContainerService con el
comando az provider register:
az provider register --namespace Microsoft.ContainerService
Para establecer el canal de actualización automática al crear un clúster, use el parámetro auto-upgrade-channel,
similar al ejemplo siguiente.
az aks create --resource-group myResourceGroup --name myAKSCluster --auto-upgrade-channel stable --generate-

ssh-keys
Para establecer el canal de actualización automática en el clúster existente, actualice el parámetro auto-upgrade-
channel, similar al ejemplo siguiente.
az aks update --resource-group myResourceGroup --name myAKSCluster --auto-upgrade-channel stable
Pasos siguientes
En este artículo se ha mostrado cómo actualizar un clúster de AKS existente. Para más información acerca de la
implementación y administración de clústeres de AKS, consulte el conjunto de tutoriales.
Tutoriales de AKS
Acuerdo de nivel de servicio de tiempo de actividad
de Azure Kubernetes Service (AKS)
El acuerdo de nivel de servicio (SLA) de tiempo de actividad es una característica opcional para habilitar un
mejor acuerdo de nivel de servicio con respaldo financiero para un clúster. El acuerdo de nivel de servicio de
tiempo de actividad garantiza una disponibilidad del 99,95 % del punto de conexión del servidor de API de
Kubernetes para los clústeres que usan zonas de disponibilidad, y una disponibilidad del 99,9 % de los clústeres
que no utilizan zonas de disponibilidad. AKS usa réplicas de nodo maestro en los dominios de actualización y de
error para garantizar que se cumplan los requisitos del acuerdo de nivel de servicio.
Los clientes que necesiten un acuerdo de nivel de servicio para alcanzar los requisitos de cumplimiento o que
requieren extender un acuerdo de nivel de servicio a sus usuarios finales deben habilitar esta característica. Los
clientes con cargas de trabajo críticas que se beneficien de un mayor acuerdo de nivel de servicio de tiempo de
actividad también pueden beneficiarse. El uso de la característica de acuerdo de nivel de servicio de tiempo de
actividad con zonas de disponibilidad permite una mayor disponibilidad para el tiempo de actividad del servidor
de API de Kubernetes.
Los clientes todavía pueden crear un número ilimitado de clústeres gratuitos con un objetivo de nivel de
servicio (SLO) del 99,5 %, y optar por el tiempo de actividad preferido del SLO o SLA según sea necesario.
IMPORTANT
En el caso de los clústeres con bloqueo de salida, consulte la limitación del tráfico de salida para abrir los puertos
adecuados.
El Acuerdo de Nivel de Servicio de tiempo de actividad está disponible en las regiones públicas y de Azure
Government en las que se admite AKS.
El Acuerdo de Nivel de Servicio de tiempo de actividad está disponible para clústeres AKS privados en todas
las regiones públicas en las que se admite AKS.
Términos y condiciones del acuerdo de nivel de servicio

El acuerdo de nivel de servicio de tiempo de actividad es una característica de pago y se habilita para cada
clúster. El precio del acuerdo de nivel de servicio de tiempo de actividad viene determinado por el número de
clústeres discretos, no por el tamaño de los clústeres individuales. Puede ver los Detalles de precios de los
acuerdos de nivel de servicio de tiempo de actividad para obtener más información.
Antes de empezar
Instale la versión 2.8.0 de la CLI de Azure, o cualquier versión posterior.
Creación de un clúster con un Acuerdo de Nivel de Servicio de

tiempo de actividad
Para crear un nuevo clúster con el acuerdo de nivel de servicio de tiempo de actividad, use la CLI de Azure.
En el ejemplo siguiente, se crea un grupo de recursos denominado myResourceGroup en la ubicación eastus:
# Create a resource group

Use el comando az aks create para crear un clúster de AKS. En el siguiente ejemplo se crea un clúster
denominado myAKSCluster con un nodo. La operación tarda varios minutos en completarse:
# Create an AKS cluster with uptime SLA

az aks create --resource-group myResourceGroup --name myAKSCluster --uptime-sla --node-count 1
El siguiente fragmento JSON muestra el nivel de pago de la SKU, que indica que el clúster tiene habilitado el
Acuerdo de Nivel de Servicio de tiempo de actividad.
},
"sku": {
"name": "Basic",
"tier": "Paid"
},
Modificación de un clúster existente para usar un Acuerdo de Nivel

de Servicio de tiempo de actividad
Opcionalmente, puede actualizar los clústeres existentes para usar el Acuerdo de Nivel de Servicio de tiempo de
actividad.
Si creó un clúster de AKS con los pasos anteriores, elimine el grupo de recursos:
# Delete the existing cluster by deleting the resource group

Cree un nuevo grupo de recursos:

Cree un nuevo clúster y no use el Acuerdo de Nivel de Servicio de tiempo de actividad:
# Create a new cluster without uptime SLA

az aks create --resource-group myResourceGroup --name myAKSCluster--node-count 1
Use el comando az aks update para actualizar el clúster existente:
# Update an existing cluster to use Uptime SLA

az aks update --resource-group myResourceGroup --name myAKSCluster --uptime-sla
El siguiente fragmento JSON muestra el nivel de pago de la SKU, que indica que el clúster tiene habilitado el
Acuerdo de Nivel de Servicio de tiempo de actividad.
},
"sku": {
"name": "Basic",
"tier": "Paid"
},
Exclusión del Acuerdo de Nivel de Servicio de tiempo de actividad

Puede actualizar el clúster para cambiar al nivel gratis y excluirse del Acuerdo de Nivel de Servicio de tiempo de
actividad.
# Update an existing cluster to opt out of Uptime SLA

az aks update --resource-group myResourceGroup --name myAKSCluster --no-uptime-sla
Limpieza
Para evitar cargos, limpie los recursos que haya creado. Para eliminar el clúster, use el comando
az group delete para eliminar el grupo de recursos de AKS:
Pasos siguientes
Use Availability Zones para aumentar la alta disponibilidad con las cargas de trabajo del clúster de AKS.
Configure el clúster para limitar el tráfico de salida.
Reducción de la latencia con grupos con ubicación
por proximidad
NOTE
Cuando se usan los grupos con ubicación por proximidad en AKS, la coubicación solo se aplica a los nodos agente. Se
mejora la latencia nodo a nodo y la latencia pod a pod hospedado correspondiente. La coubicación no afecta la selección
de ubicación del plano de control de un clúster.
Al implementar la aplicación en Azure, la propagación de instancias de máquina virtual (VM) entre regiones o
zonas de disponibilidad crea una latencia de red, lo que puede afectar al rendimiento general de la aplicación.
Un grupo con ubicación por proximidad es una agrupación lógica que se usa para asegurarse de que los
recursos de proceso de Azure se encuentran físicamente cercanos entre sí. Algunas aplicaciones como juegos,
simulaciones de ingeniería y operaciones bursátiles de alta frecuencia (HFT) requieren una latencia baja y tareas
que se completen rápidamente. En escenarios de informática de alto rendimiento (HPC), como estos, considere
la posibilidad de usar grupos con ubicación por proximidad (PPG) en los grupos de nodos del clúster.
Antes de comenzar
Para este artículo es preciso usar la versión 2.14 o posterior de la CLI de Azure. Ejecute az --version para
encontrar la versión. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure.
Limitaciones
Un grupo con ubicación por proximidad se puede asignar a una zona de disponibilidad como máximo.
Un grupo de nodos debe usar Virtual Machine Scale Sets para asociar un grupo con ubicación por
proximidad.
Un grupo de nodos puede asociar un grupo con ubicación por proximidad solo en el momento de la creación
del grupo de nodos.
Grupos de nodos y grupos con ubicación por proximidad

El primer recurso que se implementa con un grupo con ubicación por proximidad se adjunta a un centro de
datos específico. Los recursos adicionales implementados con el mismo grupo con ubicación por proximidad se
colocan en el mismo centro de datos. Una vez que todos los recursos que usan el grupo con ubicación por
proximidad se han detenido (desasignado) o eliminado, ya no se adjuntan.
Muchos grupos de nodos pueden asociarse a un solo grupo con ubicación por proximidad.
Un grupo de nodos solo se puede asociar a un solo grupo con ubicación por proximidad.
Configuración de grupos con ubicación por proximidad con zonas de disponibilidad
NOTE
Aunque los grupos con ubicación por proximidad necesitan un grupo de nodos para poder usar como máximo una zona
de disponibilidad, el Acuerdo de Nivel de Servicio de máquina virtual de Azure de línea de base del 99,9 % sigue vigente
para las máquinas virtuales de una sola zona.
Los grupos de ubicación por proximidad son un concepto de grupo de nodos y están asociados a cada grupo de
nodos individual. El uso de un recurso PPG no afecta a la disponibilidad del plano de control de AKS. Sí puede
afectar al modo en que un clúster debe diseñarse con zonas. Para que un clúster se distribuya entre varias zonas,
se recomienda el diseño siguiente.
Aprovisione un clúster con el primer grupo del sistema usando tres zonas y sin grupo de ubicación por
proximidad asociado. De esta forma, se garantiza que los pods del sistema aterrizan en un grupo de nodos
dedicado que se distribuirá entre varias zonas.
Agregue grupos de nodos de usuario adicionales con una única zona y un grupo de ubicación por
proximidad asociado a cada grupo. Por ejemplo, nodepool1 en la zona 1 y PPG1, nodepool2 en la zona 2 y
PPG2 o nodepool3 en la zona 3 con PPG3. Así, se tiene la seguridad de que, en el nivel de clúster, los nodos
se reparten entre varias zonas y cada grupo de nodos individual se ubica en la zona designada con un
recurso de PPG dedicado.
Creación de un clúster de AKS con un grupo con ubicación por

proximidad
El ejemplo siguiente usa el comando az group create para crear un grupo de recursos denominado
myResourceGroup en la región centralus. Se crea un clúster de AKS denominado myAKSCluster mediante el
comando az aks create.
Las redes aceleradas mejoran en gran medida el rendimiento de red de las máquinas virtuales. Idealmente, use
grupos con ubicación por proximidad junto con redes aceleradas. De forma predeterminada, AKS usa redes
aceleradas en las instancias de máquinas virtuales admitidas, que incluyen la mayoría de las máquinas virtuales
de Azure con dos o más CPU virtuales.
Cree un clúster de AKS con un grupo de ubicación por proximidad asociado al primer grupo de nodos del
sistema:
# Create an Azure resource group

az group create --name myResourceGroup --location centralus
Ejecute el comando siguiente y almacene el id. que se devuelve:
# Create proximity placement group

az ppg create -n myPPG -g myResourceGroup -l centralus -t standard
El comando genera una salida, que incluye el valor id que necesita para los comandos siguientes de la CLI:
{
"availabilitySets": null,
"colocationStatus": null,
"id":
"/subscriptions/yourSubscriptionID/resourceGroups/myResourceGroup/providers/Microsoft.Compute/proximityPlace
mentGroups/myPPG",
"location": "centralus",
"name": "myPPG",
"proximityPlacementGroupType": "Standard",
"tags": {},
"type": "Microsoft.Compute/proximityPlacementGroups",
"virtualMachineScaleSets": null,
"virtualMachines": null
}
Use el id. de recurso del grupo con ubicación por proximidad para el valor myPPGResourceID en el comando
siguiente:
# Create an AKS cluster that uses a proximity placement group for the initial system node pool only. The PPG
has no effect on the cluster control plane.
az aks create \
--ppg myPPGResourceID
Incorporación de un grupo con ubicación por proximidad a un clúster

existente
Puede agregar un grupo con ubicación por proximidad a un clúster existente mediante la creación de un grupo
de nodos nuevo. Si lo desea, puede migrar las cargas de trabajo existentes al grupo de nodos nuevo y, a
continuación, eliminar el grupo de nodos original.
Use el mismo grupo con ubicación por proximidad que creó anteriormente y esto garantizará que los nodos de
agente de ambos grupos de nodos del clúster de AKS estén físicamente ubicados en el mismo centro de datos.
Use el id. de recurso del grupo con ubicación por proximidad que creó anteriormente y agregue un grupo de
nodos nuevo con el comando az aks nodepool add :
# Add a new node pool that uses a proximity placement group, use a --node-count = 1 for testing
--name mynodepool \
--node-count 1 \
--ppg myPPGResourceID
Limpieza
Para eliminar el clúster, use el comando az group delete para eliminar el grupo de recursos de AKS:
Pasos siguientes
Más información sobre los grupos con ubicación por proximidad.
Actualización de la imagen de nodos de Azure
AKS admite la actualización de las imágenes de un nodo para que esté actualizado con las actualizaciones más
recientes del sistema operativo y en tiempo de ejecución. AKS proporciona una nueva imagen por semana con
las actualizaciones más recientes, por lo que es beneficioso actualizar las imágenes del nodo con regularidad
por las características más recientes, incluidas las revisiones de Linux o Windows. En este artículo se muestra
cómo actualizar las imágenes de nodo de un clúster de AKS y cómo actualizar las imágenes de grupo de nodos
sin actualizar la versión de Kubernetes.
Para más información sobre las imágenes más recientes proporcionadas por AKS, consulte las notas de la
versión de AKS.
Para obtener información sobre la actualización de la versión del clúster de Kubernetes, vea Actualización de un
clúster de AKS.
NOTE
El clúster de AKS debe usar conjuntos de escalado de máquinas virtuales para los nodos.
Comprobación de si el grupo de nodos está en la imagen de nodo

más reciente
Puede ver cuál es la versión más reciente de la imagen de nodo disponible para el grupo de nodos con el
siguiente comando:
az aks nodepool get-upgrades \

--nodepool-name mynodepool \
--resource-group myResourceGroup
En la salida puede ver latestNodeImageVersion como en el ejemplo siguiente:
{
"id": "/subscriptions/XXXX-XXX-XXX-XXX-
XXXXX/resourcegroups/myResourceGroup/providers/Microsoft.ContainerService/managedClusters/myAKSCluster/agent
Pools/nodepool1/upgradeProfiles/default",
"latestNodeImageVersion": "AKSUbuntu-1604-2020.10.28",
"name": "default",
"osType": "Linux",
"type": "Microsoft.ContainerService/managedClusters/agentPools/upgradeProfiles",
"upgrades": null
}
Por lo tanto, para nodepool1 la imagen de nodo más reciente disponible es AKSUbuntu-1604-2020.10.28 . Ahora
puede compararla con la versión de la imagen de nodo actual que usa el grupo de nodos mediante la ejecución
de:
az aks nodepool show \
--name mynodepool \
--query nodeImageVersion
La siguiente sería una salida de ejemplo:
"AKSUbuntu-1604-2020.10.08"
Por lo tanto, en este ejemplo puede actualizar desde la versión de la imagen actual AKSUbuntu-1604-2020.10.08 a
la versión más reciente AKSUbuntu-1604-2020.10.28 .
Actualización de todos los nodos de todos los grupos de nodos

La actualización de imágenes de nodo se realiza con az aks upgrade . Para actualizar la imagen de nodo, utilice
el siguiente comando:
az aks upgrade \
--node-image-only
Durante la actualización, compruebe el estado de las imágenes de nodo con el siguiente comando kubectl ,
para obtener las etiquetas y filtrar la información de la imagen de nodo actual:
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}

{.metadata.labels.kubernetes\.azure\.com\/node-image-version}{"\n"}{end}'
Una vez completada la actualización, use az aks show para obtener los detalles actualizados del grupo de
nodos. La imagen del nodo actual se muestra en la propiedad nodeImageVersion .
az aks show \
--name myAKSCluster
Actualización de un grupo de nodos específico

La actualización de la imagen en un grupo de nodos es similar a la actualización de la imagen en un clúster.
Para actualizar la imagen del sistema operativo del grupo de nodos sin realizar una actualización del clúster de
Kubernetes, utilice la opción --node-image-only en el ejemplo siguiente:
az aks nodepool upgrade \

--name mynodepool \
--node-image-only
Una vez completada la actualización, use az aks nodepool show para obtener los detalles actualizados del grupo
de nodos. La imagen del nodo actual se muestra en la propiedad nodeImageVersion .

--name mynodepool
Actualización de imágenes de nodo con sobrecarga de nodos

Para acelerar el proceso de actualización de la imagen de nodo, puede actualizar las imágenes de nodo
mediante un valor de sobrecarga de nodo personalizable. De forma predeterminada, AKS usa un nodo adicional
para configurar las actualizaciones.
Si desea aumentar la velocidad de las actualizaciones, use el valor --max-surge para configurar el número de
nodos que se usarán para las actualizaciones, de forma que se completen más rápido. Para obtener más
información sobre las ventajas e inconvenientes de varias configuraciones de --max-surge , consulte
Personalización de la actualización de sobrecargas de nodo.
El siguiente comando establece el valor máximo de sobrecarga para realizar una actualización de imagen de
nodo:

--name mynodepool \
--max-surge 33% \
--node-image-only \
--no-wait

Use az aks nodepool show para obtener los detalles actualizados del grupo de nodos. La imagen del nodo actual
se muestra en la propiedad nodeImageVersion .

--name mynodepool
Pasos siguientes
Consulte las notas de la versión de AKS para más información sobre las imágenes de nodo más recientes.
Obtenga información sobre cómo actualizar la versión de Kubernetes con Actualización de un clúster de AKS.
Aplicación de actualizaciones de grupos de nodos y clústeres automáticamente con Acciones de GitHub
Obtenga más información sobre varios grupos de nodos y cómo actualizar los grupos de nodos con
Creación y administración de varios grupos de nodos.
Aplicación de actualizaciones de seguridad a los
nodos de Azure Kubernetes Service (AKS)
automáticamente mediante Acciones de GitHub
Las actualizaciones de seguridad son una parte fundamental del mantenimiento de la seguridad y el
cumplimiento del clúster de AKS con las últimas correcciones para el sistema operativo subyacente. Estas
actualizaciones incluyen las revisiones de seguridad del sistema operativo o las actualizaciones del kernel.
Algunas de las actualizaciones requieren un reinicio del nodo para completar el proceso.
La ejecución de az aks upgrade proporciona una manera de aplicar actualizaciones sin tiempo de inactividad. El
comando administra la aplicación de las actualizaciones más recientes a todos los nodos del clúster, el
acordonamiento y el drenaje del tráfico a los nodos, el reinicio de los nodos y la habilitación del tráfico a los
nodos actualizados. Si actualiza los nodos con un método diferente, AKS no los reiniciará automáticamente.
NOTE
La principal diferencia entre az aks upgrade cuando se usa con la marca de --node-image-only es que, cuando se
utiliza, solo se actualizarán las imágenes de nodo. Si se omite, se actualizarán las imágenes de nodo y la versión del plano
de control de Kubernetes. Puede comprobar los documentos para las actualizaciones administradas en los nodos y los
documentos para las actualizaciones de clúster para ver información más detallada.
Todos los nodos de Kubernetes se ejecutan en una máquina virtual (VM) de Azure estándar. Estas máquinas
virtuales pueden estar basadas en Windows o Linux. Las máquinas virtuales basadas en Linux utilizan una
imagen de Ubuntu, con el sistema operativo configurado para buscar actualizaciones automáticamente cada
noche.
Cuando se utiliza el comando az aks upgrade , la CLI de Azure crea un aumento de los nuevos nodos con las
actualizaciones de kernel y de seguridad más recientes, estos nodos se acordonan inicialmente para evitar que
las aplicaciones estén programadas en función de ellos hasta que se complete la actualización. Una vez
finalizada, Azure acordona (hace que el nodo no esté disponible para la programación de nuevas cargas de
trabajo), drena (mueve las cargas de trabajo existentes a otro nodo) los nodos más antiguos y desacordona los
nuevos, con lo que se transfieren de forma efectiva todas las aplicaciones programadas a los nuevos nodos.
Este proceso es mejor que la actualización manual de kernels basados en Linux, ya que Linux requiere un
reinicio cuando se instala una nueva actualización del kernel. Si actualiza el sistema operativo manualmente,
también debe reiniciar la máquina virtual, acordonando y drenando manualmente todas las aplicaciones.
En este artículo se muestra cómo automatizar el proceso de actualización de los nodos de AKS. Utilizará
Acciones de GitHub y la CLI de Azure para crear una tarea de actualización basada en cron que se ejecuta
automáticamente.
Antes de empezar
También es preciso que esté instalada y configurada la versión 2.0.59 de la CLI de Azure u otra versión posterior.
Ejecute az --version para encontrar la versión. Si necesita instalarla o actualizarla, vea Instalación de la CLI de
Azure.
En este artículo también se da por hecho que tiene una cuenta de GitHub en la que crear acciones.
Creación de una acción de GitHub con hora

cron es una utilidad que permite ejecutar un conjunto de comandos, o trabajo, en una programación
automatizada. Para crear un trabajo, y que actualice los nodos de AKS en una programación automatizada,
necesitará un repositorio para hospedar las acciones. Normalmente, las acciones de GitHub se configuran en el
mismo repositorio que la aplicación, pero puede utilizar cualquier repositorio. En este artículo, vamos a utilizar
el repositorio de su perfil. Si no tiene ninguno, cree un repositorio con el mismo nombre que el nombre de
usuario de GitHub.
1. Vaya al repositorio en GitHub.
2. Haga clic en la pestaña Actions (Acciones) de la parte superior de la página.
3. Si ya ha configurado un flujo de trabajo en este repositorio, se le redirigirá a la lista de ejecuciones
completadas, en este caso, haga clic en el botón New Workflow (Nuevo flujo de trabajo). Si este es su
primer flujo de trabajo en el repositorio, GitHub le presentará algunas plantillas de proyecto, haga clic en
el vínculo Set up a workflow yourself (Configurar un flujo de trabajo personalmente) debajo del texto
de la descripción.
4. Cambie el flujo de trabajo name y las etiquetas on de forma similar a lo siguiente. Las Acciones de
GitHub utilizan la misma sintaxis cron de POSIX que cualquier sistema basado en Linux. En esta
programación, estamos indicando al flujo de trabajo que se ejecute cada 15 días a las 3 de la mañana.
name: Upgrade cluster node images

on:
schedule:
- cron: '0 3 */15 * *'
5. Cree un nuevo trabajo con lo siguiente. Este trabajo se denomina upgrade-node , se ejecuta en un agente
de Ubuntu y se conectará a su cuenta de la CLI de Azure a fin de ejecutar los pasos necesarios para
actualizar los nodos.
on:
schedule:
- cron: '0 3 */15 * *'
jobs:
upgrade-node:
runs-on: ubuntu-latest
Configuración de la CLI de Azure en el flujo de trabajo

En la clave steps , definirá todo el trabajo que ejecutará el flujo de trabajo para actualizar los nodos.
Descarga e inicio de sesión en la CLI de Azure
1. En el lado derecho de la pantalla Acciones de GitHub, busque la barra de búsqueda de marketplace y
escriba "Azure Login" (Inicio de sesión de Azure).
2. Obtendrá como resultado una acción llamada Azure Login (Inicio de sesión de Azure) publicada por
Azure :
3. Haga clic en Azure Login (Inicio de sesión de Azure). En la siguiente pantalla, haga clic en el icono de
copiar en la parte superior derecha del ejemplo de código.
4. Pegue lo siguiente bajo la clave steps :
on:
schedule:
- cron: '0 3 */15 * *'
jobs:
upgrade-node:
steps:
- name: Azure Login
uses: Azure/login@v1.1
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}
5. En la CLI de Azure, ejecute el siguiente comando para generar un nuevo nombre de usuario y contraseña.
az ad sp create-for-rbac -o json
La salida debe ser similar al siguiente json:
{
"appId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"displayName": "azure-cli-xxxx-xx-xx-xx-xx-xx",
"name": "http://azure-cli-xxxx-xx-xx-xx-xx-xx",
"password": "xXxXxXxXx",
"tenant": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}
6. En una nueva ventana del explorador vaya al repositorio de GitHub y abra la pestaña Settings
(Configuración) del repositorio. Haga clic en Secrets (Secretos) y, a continuación, en New Repositor y
Secret (Nuevo secreto del repositorio).
7. En Nombre, use AZURE_CREDENTIALS .
8. En Value (Valor), agregue todo el contenido de la salida del paso anterior en el que ha creado un nuevo
nombre de usuario y contraseña.
9. Haga clic en Add Secret (Agregar secreto).

La CLI utilizada por la acción se registrará en su cuenta de Azure y estará preparada para ejecutar comandos.
Para crear los pasos a fin de ejecutar los comandos de la CLI de Azure:
1. Vaya a la página de búsqueda en el marketplace de GitHub en el lado derecho de la pantalla y busque
Azure CLI Action (Acción de la CLI de Azure). Elija Azure CLI Action by Azure (Acción de la CLI de Azure
por Azure).
2. Haga clic en el botón de copiar en el resultado de marketplace de GitHub y pegue el contenido de la
acción en el editor principal, debajo del paso Azure Login (Inicio de sesión de Azure), de forma similar a lo
siguiente:
on:
schedule:
- cron: '0 3 */15 * *'
jobs:
upgrade-node:
steps:
- name: Azure Login
with:
- name: Upgrade node images
uses: Azure/cli@v1.0.0
with:
inlineScript: az aks upgrade -g {resourceGroupName} -n {aksClusterName} --node-image-only -
-yes
TIP
Puede desacoplar los parámetros -g y -n del comando agregándolos a secretos similares a los pasos
anteriores. Reemplace los marcadores de posición {resourceGroupName} y {aksClusterName} por sus
homólogos secretos, por ejemplo, ${{secrets.RESOURCE_GROUP_NAME}} y ${{secrets.AKS_CLUSTER_NAME}}
3. Cambie el nombre del archivo upgrade-node-images .

4. Haga clic en Star t Commit (Iniciar confirmación), agregue un título de mensaje y guarde el flujo de
trabajo.
Una vez creada la confirmación, el flujo de trabajo se guardará y estará preparado para su ejecución.
NOTE
Para actualizar un solo grupo de nodos en lugar de todos los grupos de nodos del clúster, agregue el parámetro --name
al comando az aks nodepool upgrade para especificar el nombre del grupo de nodos. Por ejemplo:
az aks nodepool upgrade -g {resourceGroupName} --cluster-name {aksClusterName} --name {{nodePoolName}} -

-node-image-only
Ejecución manual de la acción de GitHub

Puede ejecutar el flujo de trabajo manualmente, además de la ejecución programada, agregando un nuevo
desencadenador de on denominado workflow_dispatch . El archivo terminado debería tener un aspecto similar
al YAML siguiente:
on:
schedule:
- cron: '0 3 */15 * *'
workflow_dispatch:
jobs:
upgrade-node:
steps:
- name: Azure Login
with:
# Code for upgrading one or more node pools
Pasos siguientes
Consulte las notas de la versión de AKS para más información sobre las imágenes de nodo más recientes.
Obtenga información sobre cómo actualizar la versión de Kubernetes con Actualización de un clúster de AKS.
Obtenga más información sobre varios grupos de nodos y cómo actualizar los grupos de nodos con
Creación y administración de varios grupos de nodos.
Más información sobre los grupos de nodos del sistema.
Para más información sobre cómo ahorrar costos mediante instancias de acceso puntual, consulte el artículo
sobre la incorporación de un grupo de nodos de acceso puntual a AKS.
Aplicación de actualizaciones de kernel y seguridad
a los nodos de Linux en Azure Kubernetes Service
(AKS)
Para proteger los clústeres, las actualizaciones de seguridad se aplican automáticamente a los nodos de Linux en
AKS. Estas actualizaciones incluyen las revisiones de seguridad del sistema operativo o las actualizaciones del
kernel. Algunas de estas actualizaciones requieren un reinicio del nodo para completar el proceso. AKS no
reinicia automáticamente estos nodos de Linux para completar el proceso de actualización.
El proceso para mantener actualizados los nodos de Windows Server difiere ligeramente. Los nodos de
Windows Server no reciben actualizaciones diarias. En su lugar, debe actualizar AKS para implementar nuevos
nodos con la imagen base de Windows Server más reciente y las revisiones. Para los clústeres de AKS que usan
los nodos de Windows Server, consulte Actualización de un grupo de nodos de AKS.
En este artículo se muestra cómo usar el código abierto de Kured (demonio de reinicio de Kubernetes) para
buscar nodos de Linux que requieran un reinicio y, a continuación, administrar automáticamente la
reprogramación de pods en ejecución y el proceso de reinicio de los nodos.
NOTE
Kured es un proyecto de código abierto de Weaveworks. La asistencia para este proyecto en AKS se proporciona dentro
de lo posible. Se puede encontrar soporte técnico adicional en el canal de Slack #weave-community.
Antes de empezar
Azure.
Información sobre la experiencia de actualización del nodo AKS

En un clúster de AKS, los nodos de Kubernetes se ejecutan como máquinas virtuales de Azure. Estas máquinas
virtuales basadas en Linux, usan una imagen de Ubuntu, con el sistema operativo configurado para buscar
automáticamente actualizaciones cada noche. Si hay disponibles actualizaciones de kernel o de seguridad, estas
se descargan e instalan automáticamente.
Algunas actualizaciones de seguridad, como las actualizaciones del kernel, requieren un reinicio del nodo para
finalizar el proceso. Un nodo de Linux que requiere reinicio crea un archivo denominado /var/run/reboot-
required. Este proceso de reinicio no se realiza automáticamente.
Puede usar sus propios flujos de trabajo y procesos para controlar los reinicios de nodo, o usar kured para
coordinar el proceso. Con kured , se implementa un valor de DaemonSet que ejecuta un pod en cada nodo de
Linux del clúster. Estos pods en DaemonSet comprueban si existe el archivo /var/run/reboot-required y, a
continuación, inician un proceso para reiniciar los nodos.
Actualizaciones de nodo
Hay un proceso adicional en AKS que le permite actualizar un clúster. Una actualización consiste generalmente
en el cambio a una versión más reciente de Kubernetes, no solo en aplicar las actualizaciones de seguridad de
nodo. Una actualización de AKS realiza las acciones siguientes:
Se implementa un nuevo nodo con las últimas actualizaciones de seguridad y se aplica la versión de
Kubernetes.
Se acordona y vacía un nodo anterior.
Los pods se programan en el nuevo nodo.
El nodo anterior se elimina.
No puede permanecer en la misma versión de Kubernetes durante un evento de actualización. Tiene que
especificar una versión más reciente de Kubernetes. Para actualizar a la versión más reciente de Kubernetes,
puede actualizar el clúster de AKS.
Implementación de Kured en un clúster de AKS

Para implementar el valor kured de DaemonSet, instale el siguiente gráfico oficial de Kured Helm. Esta acción
crea un rol y un rol de clúster, enlaces y una cuenta de servicio y, luego, implementa DaemonSet con kured .
# Add the Kured Helm repository

helm repo add kured https://weaveworks.github.io/kured
# Update your local Helm chart repository cache

helm repo update
# Create a dedicated namespace where you would like to deploy kured into
kubectl create namespace kured
# Install kured in that namespace with Helm 3 (only on Linux nodes, kured is not working on Windows nodes)
helm install kured kured/kured --namespace kured --set nodeSelector."beta\.kubernetes\.io/os"=linux
También puede configurar parámetros adicionales para kured , como la integración con Prometheus o Slack.
Para más información sobre los parámetros de configuración adicionales, consulte el gráfico de Kured Helm.
Actualización de nodos de clúster

De forma predeterminada, los nodos de Linux en AKS buscan actualizaciones por la noche. Si no desea esperar,
puede realizar manualmente una actualización para comprobar que kured se ejecuta correctamente. En primer
lugar, siga los pasos para establecer conexión mediante SSH con uno de los nodos de AKS. Una vez que tenga
una conexión SSH al nodo de Linux, compruebe si hay actualizaciones y aplíquelas como sigue:
sudo apt-get update && sudo apt-get upgrade -y
Si se aplicaron actualizaciones que requieren un reinicio del nodo, se escribe un archivo en /var/run/reboot-
required. Kured comprueba si hay nodos que requieran un reinicio cada 60 minutos de forma predeterminada.
Supervisión y revisión del proceso de reinicio

Cuando una de las réplicas en el DaemonSet ha detectado que se requiere el reinicio de un nodo, se coloca un
bloqueo en el nodo mediante la API de Kubernetes. Este bloqueo impide que se programen pods adicionales en
el nodo. El bloqueo también indica que solo un nodo debe reiniciarse cada vez. Con el nodo acordonado, los
pods en ejecución se purgan desde el nodo y este se reinicia.
Puede supervisar el estado de los nodos mediante el comando kubectl get nodes. La salida del ejemplo
siguiente muestra un nodo con el estado SchedulingDisabled mientras el nodo se prepara para el proceso de
reinicio:

aks-nodepool1-28993262-0 Ready,SchedulingDisabled agent 1h v1.11.7
Una vez completado el proceso de actualización, puede ver el estado de los nodos mediante el comando kubectl
get nodes con el parámetro --output wide . Esta salida adicional le permite ver la diferencia en KERNEL-
VERSION de los nodos subyacentes, como se muestra en la siguiente salida de ejemplo. El nodo aks-nodepool1-
28993262-0 se actualizó en un paso anterior y muestra la versión de kernel 4.15.0-1039-azure. El nodo aks-
nodepool1-28993262-1 que no ha sido actualizado muestra la versión de kernel 4.15.0-1037-azure.
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE

KERNEL-VERSION CONTAINER-RUNTIME
aks-nodepool1-28993262-0 Ready agent 1h v1.11.7 10.240.0.4 <none> Ubuntu
16.04.6 LTS 4.15.0-1039-azure docker://3.0.4
aks-nodepool1-28993262-1 Ready agent 1h v1.11.7 10.240.0.5 <none> Ubuntu
16.04.6 LTS 4.15.0-1037-azure docker://3.0.4
Pasos siguientes
En este artículo se ha detallado cómo utilizar kured para reiniciar nodos de Linux automáticamente como parte
del proceso de actualización de seguridad. Para actualizar a la versión más reciente de Kubernetes, puede
actualizar el clúster de AKS.
Para los clústeres de AKS que usan los nodos de Windows Server, consulte Actualización de un grupo de nodos
de AKS.
Configuración de un clúster de AKS
Como parte de la creación de un clúster de AKS, puede que tenga que personalizar la configuración del clúster
para que se adapte a sus necesidades. En este artículo se presentan algunas opciones para personalizar el
clúster de AKS.
Configuración del sistema operativo

AKS ahora es compatible con Ubuntu 18.04 como sistema operativo de nodo predeterminado (SO) en
disponibilidad general (GA) para clústeres de versiones de Kubernetes superiores a 1.18. Para versiones
inferiores a esa, AKS Ubuntu 16.04 sigue siendo la imagen base predeterminada. A partir de Kubernetes v1.18 y
posteriores, la base predeterminada es AKS Ubuntu 18.04.
IMPORTANT
Los grupos de nodos creados en Kubernetes v1.18 o versiones posteriores tienen una imagen de nodo
AKS Ubuntu 18.04 de forma predeterminada. Los grupos de nodos de una versión de Kubernetes compatible inferior a
la versión 1.18 reciben AKS Ubuntu 16.04 como la imagen de nodo, pero se actualizarán a AKS Ubuntu 18.04 una vez
que la versión Kubernetes del grupo de nodos se actualice a la versión 1.18 o posteriores.
Es muy recomendable que pruebe sus cargas de trabajo en los grupos de nodos de AKS Ubuntu 18.04 antes de usar los
clústeres en la versión 1.18 o posteriores.
Uso de AKS Ubuntu 18.04 (GA ) en clústeres nuevos

Los clústeres creados en Kubernetes v1.18 o versiones posteriores tienen una imagen de nodo
AKS Ubuntu 18.04 de forma predeterminada. Los grupos de nodos en versiones de Kubernetes compatibles
anteriores a la versión 1.18 seguirán recibiendo AKS Ubuntu 16.04 como imagen de nodo, pero se actualizarán a
AKS Ubuntu 18.04 una vez que la versión de Kubernetes del clúster o del grupo de nodos se actualice a la
versión 1.18 o posteriores.
Es muy recomendable que pruebe sus cargas de trabajo en los grupos de nodos de AKS Ubuntu 18.04 antes de
usar los clústeres en la versión 1.18 o posteriores.
Para crear un clúster con la imagen de nodo AKS Ubuntu 18.04 , solo tiene que crear un clúster que ejecute
kubernetes v1.18 o una versión posterior, tal como se muestra a continuación:
az aks create --name myAKSCluster --resource-group myResourceGroup --kubernetes-version 1.18.14
Uso de AKS Ubuntu 18.04 (GA ) en clústeres existentes

Los clústeres creados en Kubernetes v1.18 o versiones posteriores tienen una imagen de nodo
AKS Ubuntu 18.04 una vez que la versión de Kubernetes del clúster o del grupo de nodos se actualice a la
versión 1.18 o posteriores.
Es muy recomendable que pruebe sus cargas de trabajo en los grupos de nodos de AKS Ubuntu 18.04 antes de
usar los clústeres en la versión 1.18 o posteriores.
Si los clústeres o grupos de nodos están listos para la imagen de nodo AKS Ubuntu 18.04 , simplemente puede
actualizarlos a una versión 1.18 o posterior, tal como se muestra a continuación.
az aks upgrade --name myAKSCluster --resource-group myResourceGroup --kubernetes-version 1.18.14
Si solo quiere actualizar un grupo de nodos:
az aks nodepool upgrade -name ubuntu1804 --cluster-name myAKSCluster --resource-group myResourceGroup --

kubernetes-version 1.18.14
Prueba de AKS Ubuntu 18.04 (GA ) en clústeres existentes

Los grupos de nodos creados en Kubernetes v1.18 o versiones posteriores tienen una imagen de nodo
AKS Ubuntu 18.04 una vez que la versión de Kubernetes del grupo de nodos se actualice a la versión 1.18 o
posteriores.
Es muy recomendable probar las cargas de trabajo en los grupos de nodos de AKS Ubuntu 18.04 antes de
actualizar los grupos de nodos de producción.
Para crear un grupo de nodos con la imagen de nodo AKS Ubuntu 18.04 , solo tiene que crear un grupo de nodos
que ejecute kubernetes v1.18 o una versión posterior. El plano de control del clúster tiene que estar como
mínimo en la versión 1.18 o una versión posterior, pero los demás grupos de nodos pueden permanecer en una
versión anterior de Kubernetes. En el ejemplo siguiente, primero se actualiza el plano de control y luego se crea
un nuevo grupo de nodos con la versión 1.18 que recibirá la versión del sistema operativo de la nueva imagen
de nodo.
az aks upgrade --name myAKSCluster --resource-group myResourceGroup --kubernetes-version 1.18.14 --control-

plane-only
az aks nodepool add --name ubuntu1804 --cluster-name myAKSCluster --resource-group myResourceGroup --

kubernetes-version 1.18.14
Configuración del entorno de ejecución de contenedor

Un entorno de ejecución de contenedor es un software que ejecuta contenedores y administra imágenes de
contenedor en un nodo. El entorno de ejecución ayuda a abstraer la funcionalidad específica del sistema
operativo o de sys-call para ejecutar contenedores en Linux o Windows. Los clústeres de AKS que usan grupos
de nodos con la versión 1.19 de Kubernetes y posterior usan containerd como entorno de ejecución del
contenedor. Los clústeres de AKS que usan grupos de nodos con versiones anteriores a la 1.19 de Kubernetes
usan Moby (Docker ascendente) como entorno de ejecución del contenedor.
Containerd es un entorno de ejecución de contenedor básico compatible con OCI (Open Container Initiative)
que proporciona el conjunto mínimo de funciones necesarias para ejecutar contenedores y administrar
imágenes en un nodo. Fue donado a la Cloud Native Compute Foundation (CNCF) en marzo de 2017. La versión
actual de Moby que AKS usa se basa en containerd y ya aprovecha sus ventajas, como se mostró
anteriormente.
Con los grupos de nodos y los nodos basados en containerd , en lugar de comunicarse con dockershim , el
kubelet se comunicará directamente con containerd mediante el complemento CRI (interfaz del entorno de
ejecución de contenedor) y eliminará los saltos adicionales del flujo, en comparación con la implementación de
CRI de Docker. Como tal, verá una mejor latencia de inicio del pod y menor uso de recursos (CPU y memoria).
Usar containerd para los nodos AKS mejora la latencia de inicio del pod y reduce el consumo de recursos de
nodo del entorno de ejecución de contenedor. Estas mejoras son posibles gracias a la nueva arquitectura, en la
que el kubelet se comunica directamente con containerd mediante el complemento CRI; sin embargo, en la
arquitectura de Moby o Docker, el kubelet se comunica con dockershim y con el motor de Docker antes de llegar
a containerd y, por lo tanto, tiene saltos adicionales en el flujo.
Containerd funciona en todas las versiones de disponibilidad general de Kubernetes en AKS y en todas las
versiones de Kubernetes anteriores a la versión 1.19, y admite todas las características de Kubernetes y AKS.
IMPORTANT
Los clústeres con grupos de nodos creados en Kubernetes versión 1.19 o versiones posteriores tienen como entorno de
ejecución del contenedor a containerd de manera predeterminada. Los clústeres con grupos de nodos de una versión
de Kubernetes compatible inferior a la versión 1.19 reciben Moby como entorno de ejecución del contenedor, pero se
actualizarán a ContainerD una vez que la versión de Kubernetes del grupo de nodos se actualice a la versión 1.19 o
posteriores. Puede seguir usando los clústeres y grupos de nodos de Moby en las versiones anteriores compatibles hasta
que se retire el soporte técnico.
Es muy recomendable que pruebe sus cargas de trabajo en los grupos de nodos de AKS con containerD antes de usar
los clústeres en la versión 1.19 o posteriores.
Limitaciones y diferencias de Containerd
Para usar containerd como entorno de ejecución de contenedor, debe usar AKS Ubuntu 18.04 como imagen
base del sistema operativo.
Aunque el conjunto de herramientas de Docker todavía está presente en los nodos, Kubernetes usa
containerd como entorno de ejecución de contenedor. Por lo tanto, dado que Moby y Docker no administran
los contenedores creados por Kubernetes en los nodos, no puede ver los contenedores ni interactuar con
ellos mediante los comandos de Docker (como docker ps ) o la API de Docker.
Para containerd , se recomienda usar crictl como CLI en lugar de la CLI de Docker para solucionar
problemas de pods, contenedores e imágenes de contenedor en nodos Kubernetes (por ejemplo,
crictl ps ).
No proporciona la funcionalidad completa de la CLI de Docker. Está pensado solo para solucionar
problemas.
crictl ofrece una vista de los contenedores más compatible con Kubernetes, con conceptos como
pods, etc.
Containerd configura el registro con el formato de registro cri normalizado (que es diferente de lo que se
obtiene actualmente del controlador JSON de Docker). La solución de registro debe admitir el formato de
registro cri (como Azure Monitor para contenedores)
Ya no puede tener acceso al motor de Docker, /var/run/docker.sock , ni usar Docker en Docker (DinD).
Si actualmente extrae los registros de aplicación o los datos de supervisión del motor de Docker,
utilice en su lugar Azure Monitor para contenedores, por ejemplo. Además, AKS no admite la
ejecución de comandos fuera de banda en los nodos del agente que podrían provocar inestabilidad.
Incluso cuando se use Moby o Docker, es muy desaconsejable crear imágenes y aprovechar
directamente el motor de Docker con los métodos anteriores. Kubernetes no es totalmente consciente
de esos recursos consumidos y esos enfoques presentan numerosos problemas, que se detallan aquí
y aquí, por ejemplo.
Compilación de imágenes: puede seguir usando su flujo de trabajo de compilación de Docker como de
costumbre, a menos que vaya a compilar imágenes dentro del clúster de AKS. En este caso, considere la
posibilidad de utilizar el enfoque recomendado para compilar imágenes con ACR Tasks. O bien, una
alternativa más segura dentro del clúster, como docker buildx.
Máquinas virtuales de generación 2

Azure admite máquinas virtuales de generación 2 (Gen2). Las máquinas virtuales de generación 2 admiten
características clave que no se admiten en las máquinas virtuales de generación 1 (Gen1). Estas características
incluyen una memoria mayor, Intel Software Guard Extensions (SGX Intel) y memoria persistente virtualizada
(vPMEM).
Las VM de generación 2 usan la nueva arquitectura de arranque basado en UEFI en lugar de la arquitectura
basada en BIOS que utilizan las VM de generación 1. Solo determinadas SKU y tamaños admiten máquinas
virtuales de generación 2. Consulte la lista de tamaños admitidos para ver si la SKU admite o requiere Gen2.
Además, no todas las imágenes de máquina virtual admiten Gen2; en ASK, las máquinas virtuales Gen2 usaran
la nueva imagen de Ubuntu 18.04 para AKS. Esta imagen admite todas las SKU y tamaños de Gen2.
SO efímero
De manera predeterminada, Azure replica automáticamente el disco del sistema operativo de una máquina
virtual en Azure Storage para evitar la pérdida de datos cuando hay que reubicar la máquina virtual en otro
host. Sin embargo, como los contenedores no están diseñados para preservar el estado local, este
comportamiento ofrece un valor limitado y, además, presenta algunos inconvenientes, como un
aprovisionamiento más lento de los nodos y una mayor latencia de lectura y escritura.
En cambio, los discos de sistema operativo efímero solo se almacenan en el equipo host, al igual que los discos
temporales. Esto proporciona una latencia de lectura y escritura menor, junto con escalabilidad de nodos y
actualizaciones de clúster más rápidas.
Al igual que sucede con un disco temporal, el disco de sistema operativo efímero está incluido en el precio de la
máquina virtual, por lo que no lleva asociado ningún costo adicional de almacenamiento.
IMPORTANT
Cuando un usuario no solicita explícitamente los discos administrados para el sistema operativo, AKS tomará como valor
predeterminado el sistema operativo efímero si es posible para una configuración de grupo de nodos determinada.
Cuando se usa un sistema operativo efímero, el disco del sistema operativo debe caber en la memoria caché de
la máquina virtual. Los tamaños de la memoria caché de la máquina virtual están disponibles en la
documentación de Azure entre paréntesis junto a rendimiento de E/S ("tamaño de caché en GiB").
Con el tamaño de máquina virtual predeterminado de AKS Standard_DS2_v2 con el tamaño de disco de sistema
operativo predeterminado de 100 GB como ejemplo, este tamaño de máquina virtual es compatible con el
sistema operativo efímero pero solo tiene 86 GB de tamaño de caché. El valor predeterminado de esta
configuración serán discos administrados si el usuario no lo especifica explícitamente. Si un usuario solicita
explícitamente el sistema operativo efímero, recibirá un error de validación.
Si un usuario solicita el mismo tamaño Standard_DS2_v2 con un disco del sistema operativo de 60 GB, esta
configuración sería el sistema operativo efímero de manera predeterminada: el tamaño solicitado de 60 GB es
menor que el tamaño máximo de la caché de 86 GB.
Al usar el tamaño Standard_D8s_v3 con un disco de sistema operativo de 100 GB, este tamaño de máquina
virtual es compatible con el sistema operativo efímero y tiene 200 GB de espacio en caché. Si un usuario no
especifica el tipo de disco del sistema operativo, el grupo de nodos recibiría un sistema operativo efímero de
manera predeterminada.
El sistema operativo efímero requiere la versión 2.15.0 de la CLI de Azure.
Uso del sistema operativo efímero en clústeres nuevos
Configure el clúster para que utilice discos de sistema operativo efímero al crearlo. Use la marca
--node-osdisk-type para establecer el sistema operativo efímero como el tipo de disco de sistema operativo
para el nuevo clúster.
az aks create --name myAKSCluster --resource-group myResourceGroup -s Standard_DS3_v2 --node-osdisk-type

Ephemeral
Si quiere crear un clúster normal con discos de sistema operativo conectados a la red, especifique la etiqueta
--node-osdisk-type=Managed . También puede optar por añadir más grupos de nodos de sistema operativo
efímero, tal y como se indica a continuación.
Uso del sistema operativo efímero en clústeres existentes
Configure un nuevo grupo de nodos para usar discos de sistema operativo efímero. Utilice la marca
--node-osdisk-type para establecerla como el tipo de disco de para ese grupo de nodos.
az aks nodepool add --name ephemeral --cluster-name myAKSCluster --resource-group myResourceGroup -s

Standard_DS3_v2 --node-osdisk-type Ephemeral
IMPORTANT
El sistema operativo efímero permite implementar imágenes de instancias y de máquinas virtuales cuyo tamaño máximo
sea equivalente al de la memoria caché de máquina virtual. En el caso de AKS, la configuración predeterminada del disco
de sistema operativo del nodo usa 128 GB, lo cual significa que necesitará una máquina virtual con una memoria caché
cuyo tamaño sea superior a 128 GB. El tamaño de VM predeterminado Standard_DS2_v2 tiene un tamaño de caché de
86 GB, que no es lo suficientemente grande. Las máquinas virtuales Standard_DS3_v2 tienen un tamaño de caché de
172 GB, que es lo suficientemente grande. También puede reducir el tamaño predeterminado del disco de sistema
operativo mediante --node-osdisk-size . El tamaño mínimo de las imágenes de AKS es 30 GB.
Si quiere crear grupos de nodos con discos de sistema operativo conectados a red, puede especificar
--node-osdisk-type Managed para hacerlo.
Nombre del grupo de recursos personalizado

Al implementar un clúster de Azure Kubernetes Service en Azure, se crea un segundo grupo de recursos para
los nodos de trabajo. De forma predeterminada, AKS asignará un nombre al grupo de recursos del nodo
MC_resourcegroupname_clustername_location , pero también puede proporcionar su propio nombre.
Para especificar su propio nombre de grupo de recursos, instale la versión de la extensión de la CLI de Azure
aks-preview 0.3.2 o una posterior. Con la CLI de Azure, use el parámetro --node-resource-group del comando
az aks create para especificar un nombre personalizado para el grupo de recursos. Si usa una plantilla de
Azure Resource Manager para implementar un clúster de AKS, puede definir el nombre del grupo de recursos
mediante la propiedad nodeResourceGroup .
az aks create --name myAKSCluster --resource-group myResourceGroup --node-resource-group myNodeResourceGroup
El proveedor de recursos de Azure crea automáticamente el grupo de recursos secundario en su propia

suscripción. Solo puede especificar el nombre del grupo de recursos personalizado al crear el clúster.
Cuando trabaje con el grupo de recursos del nodo, tenga en cuenta que no puede:
Especificar un grupo de recursos existente para el grupo de recursos del nodo.
Especificar otra suscripción para el grupo de recursos del nodo.
Cambiar el nombre del grupo de recursos del nodo una vez se haya creado el clúster.
Especificar los nombres de los recursos administrados del grupo de recursos del nodo.
Modificar o eliminar las etiquetas creadas en Azure de los recursos administrados del grupo de recursos del
nodo.
Pasos siguientes
Aprenda a actualizar las imágenes del nodo del clúster.
Consulte Actualización de un clúster de Azure Kubernetes Service (AKS) para más información sobre cómo
actualizar el clúster a la versión más reciente de Kubernetes.
Más información sobre containerd y Kubernetes
Consulte la lista de Preguntas más frecuentes sobre AKS para encontrar respuestas a algunas preguntas
comunes sobre AKS.
Obtenga más información sobre los discos de sistema operativo efímero.
Personalización de la configuración de nodos en los
grupos de nodos de Azure Kubernetes Service
(AKS) (versión preliminar)
La personalización de la configuración de los nodos permite configurar o ajustar los valores del sistema
operativo (SO) o los parámetros de kubelet para que se adapten a las necesidades de las cargas de trabajo. Al
crear un clúster de AKS o agregar un grupo de nodos al clúster, puede personalizar un subconjunto de los
valores de configuración de kubelet y del sistema operativo más usados. Para configurar otros valores aparte de
los de este subconjunto, use un demonio establecido para personalizar las configuraciones necesarias sin perder
la compatibilidad de AKS con los nodos.
Registro de la característica en vista previa (GB)

CustomNodeConfigPreview
Para crear un clúster o un grupo de nodos de AKS para personalizar los parámetros de kubelet o la
configuración del sistema operativo, debe habilitar la marca de características CustomNodeConfigPreview .
Registre la marca de la característica CustomNodeConfigPreview con el comando az feature register, como se
muestra en el siguiente ejemplo:
az feature register --namespace "Microsoft.ContainerService" --name "CustomNodeConfigPreview"
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/CustomNodeConfigPreview')].

IMPORTANT
Para crear un clúster o un grupo de nodos de AKS para personalizar los parámetros de kubelet o la
configuración del sistema operativo, necesita la extensión más reciente de la CLI de Azure: aks-preview . Instale la

Uso de la configuración de nodos personalizada

Configuración personalizada de kubelet
A continuación, se enumeran los parámetros admitidos y los valores aceptados de kubelet.
VA LO RES O IN T ERVA LO
PA RÁ M ET RO P ERM IT IDO S DEFA ULT DESC RIP C IÓ N
cpuManagerPolicy ninguno, estático ninguno La directiva estática permite

que los contenedores de
pods garantizados con un
número entero de
solicitudes de CPU accedan
a las CPU exclusivas del
nodo.
cpuCfsQuota true, false true Habilita o deshabilita la

aplicación de cuotas de CFS
de CPU para contenedores
que especifican límites de
CPU.
cpuCfsQuotaPeriod Intervalo en milisegundos 100ms Establece el valor del

(ms) período de cuota de CFS de
CPU.
imageGcHighThreshold 0-100 85 Porcentaje de uso del disco

después del cual siempre se
ejecuta la recolección de
elementos no utilizados de
la imagen. Uso mínimo de
disco que desencadenará
la recolección de elementos
no utilizados. Para
deshabilitar la recolección
de elementos no utilizados
de la imagen, establezca
este valor en 100.
PA RÁ M ET RO P ERM IT IDO S DEFA ULT DESC RIP C IÓ N
imageGcLowThreshold 0-100, no mayor que 80 Porcentaje de uso del disco

imageGcHighThreshold . antes del cual la recolección
de elementos no utilizados
de la imagen nunca se
ejecuta. Uso mínimo de
disco que puede
desencadenar la recolección
de elementos no utilizados.
topologyManagerPolicy ninguno, mejor esfuerzo, ninguno Optimiza la alineación de

restringido, un solo nodo nodos NUMA. Consulte
numa aquí para más información.
Solo kubernetes v1.18+.
allowedUnsafeSysctls kernel.shm* , None Lista permitida de patrones

kernel.msg* , no seguros sysctls o sysctl.
kernel.sem ,
fs.mqueue.* , net.*
Configuración personalizada del sistema operativo Linux

A continuación, se enumeran las configuraciones del sistema admitidas y los valores aceptados.
Límites del identificador de archivo
Cuando se atiende mucho tráfico, es habitual que el tráfico que se atiende provenga de un gran número de
archivos locales. Puede modificar los siguientes valores del kernel y los límites integrados para que pueda
administrar una mayor cantidad, a cambio de usar algo más de memoria del sistema.
C O N F IGURA C IÓ N P ERM IT IDO S DEFA ULT DESC RIP C IÓ N
fs.file-max 8192 - 12000500 709620 Número máximo de

identificadores de archivo
que asignará el kernel de
Linux; si aumenta este valor,
puede aumentar el número
máximo de archivos
abiertos permitidos.
fs.inotify.max_user_watches 781250 - 2097152 1 048 576 Número máximo de

inspecciones de archivos
permitidos por el sistema.
Cada inspección tiene
aproximadamente 90 bytes
en un kernel de 32 bits y
unos 160 bytes en un
kernel de 64 bits.
fs.aio-max-nr 65536 - 6553500 65536 El elemento aio-nr muestra

el número actual de
solicitudes io asincrónicas
en todo el sistema. aio-
max-nr permite cambiar el
valor máximo hasta el que
puede aumentar aio-nr.
fs.nr_open 8192 - 20000500 1 048 576 El número máximo de

identificadores de archivo
que un proceso puede
asignar.
Ajuste de socket y red

En el caso de los nodos de agente, que se espera que administren un gran número de sesiones simultáneas,
puede usar el subconjunto de opciones de red y TCP que se muestra a continuación, que puede modificar en
cada grupo de nodos.
net.core.somaxconn 4096 - 3240000 16384 Número máximo de

solicitudes de conexión que
se pueden poner en cola
para cualquier socket de
escucha determinado. Un
límite superior para el valor
del parámetro de trabajo
pendiente que se pasa a la
función listen(2). Si el
argumento de trabajo
pendiente es mayor que
somaxconn , se trunca de
forma silenciosa hasta este
límite.
net.core.netdev_max_backlog 1000 - 3240000 1000 Número máximo de

paquetes, en cola en el lado
INPUT, cuando la interfaz
recibe paquetes a una
velocidad mayor de la que
el kernel puede procesarlos.
net.core.rmem_max 212992 - 134217728 212992 Tamaño máximo del búfer

de sockets de recepción en
bytes.
net.core.wmem_max 212992 - 134217728 212992 Tamaño máximo del búfer

de sockets de envío en
bytes.
net.core.optmem_max 20480 - 4194304 20480 Tamaño máximo del búfer

auxiliar (búfer de memoria
de opción) permitido por
socket. La memoria de
opción de socket se utiliza
en algunos casos para
almacenar estructuras
adicionales relacionadas con
el uso del socket.
net.ipv4.tcp_max_syn_backlog128 - 3240000 16384 Número máximo de

solicitudes de conexión en
cola que todavía no han
recibido una confirmación
del cliente que se está
conectando. Si se supera
este número, el kernel
comenzará a rechazar
solicitudes.
net.ipv4.tcp_max_tw_buckets 8000 - 1440000 32 768 Número máximo de sockets

timewait retenidos por el
sistema simultáneamente. Si
se supera este número, el
socket time-wait se
destruye inmediatamente y
se imprime la advertencia.
net.ipv4.tcp_fin_timeout 5 - 120 60 La cantidad de tiempo que

una conexión huérfana
(ninguna aplicación hace
referencia a ella)
permanecerá en el estado
FIN_WAIT_2 antes de que
se anule en el extremo local.
net.ipv4.tcp_keepalive_time 30 - 432000 7200 Frecuencia con la que TCP

envía mensajes keepalive
cuando keepalive está
habilitado.
1-
net.ipv4.tcp_keepalive_probes 15 9 Número de sondeos
keepalive que envía TCP,
hasta que decide que la
conexión se ha
interrumpido.
net.ipv4.tcp_keepalive_intvl1 - 75 75 Frecuencia con la que se

envían los sondeos.
Multiplicado por
tcp_keepalive_probes
constituye el tiempo para
terminar una conexión que
no responde, después de
que se inicien los sondeos.
net.ipv4.tcp_tw_reuse 0o1 0 Permite reutilizar sockets

TIME-WAIT con nuevas
conexiones cuando sea
seguro desde el punto de
vista del protocolo.
net.ipv4.ip_local_port_rangePrimero: 1024 - 60999 y Primero: 32768 y Último: El intervalo de puertos local

Último: 32768 - 65000] 60999 que utiliza el tráfico TCP y
UDP para elegir el puerto
local. Formado por dos
números: el primer número
es el primer puerto local
que permite tráfico TCP y
UDP en el nodo de agente,
el segundo es el último
número de puerto local.
128 - 80000
net.ipv4.neigh.default.gc_thresh1 4096 Número mínimo de
entradas que pueden
encontrarse en la caché de
ARP. La recolección de
elementos no utilizados no
se desencadena si el
número de entradas está
por debajo de este valor.
512 - 90000
net.ipv4.neigh.default.gc_thresh2 8192 Número máximo temporal
de entradas que pueden
encontrarse en la caché de
ARP. Esta configuración es
posiblemente la más
importante, ya que la
recolección de elementos
no utilizados ARP se
desencadenará unos
5 segundos después de
alcanzar este máximo.
1024 -
net.ipv4.neigh.default.gc_thresh3 100000 16384 Número máximo fijo de
entradas en la caché de ARP.
131072
net.netfilter.nf_conntrack_max - 589824 131 072 nf_conntrack es un
módulo que realiza un
seguimiento de las entradas
de conexión de NAT en
Linux. El módulo
nf_conntrack usa una
tabla hash para anotar el
registro de la conexión
establecida del protocolo
TCP. nf_conntrack_max es
el número máximo de
nodos de la tabla hash, es
decir, el número máximo de
conexiones admitidas por el
módulo nf_conntrack o
el tamaño de la tabla de
seguimiento de la conexión.
65536 -
net.netfilter.nf_conntrack_buckets 147456 65536 nf_conntrack es un
módulo que realiza un
seguimiento de las entradas
de conexión de NAT en
Linux. El módulo
nf_conntrack usa una
tabla hash para anotar el
registro de la conexión
establecida del protocolo
TCP.
nf_conntrack_buckets es
el tamaño de la tabla hash.
Límites de trabajo
Al igual que los límites del descriptor de archivos, el número de trabajos o subprocesos que un proceso puede
crear está limitado por la configuración del kernel y los límites de usuarios. El límite de usuarios en AKS es
ilimitado.
kernel.threads-max 20 - 513785 55601 Los procesos pueden iniciar

los subprocesos de trabajo.
El número máximo de
subprocesos que se pueden
crear se establece con la
configuración del kernel
kernel.threads-max .
Memoria virtual
La configuración siguiente se puede usar para optimizar el funcionamiento del subsistema de memoria virtual
(VM) del kernel de Linux y el valor de writeout de datos sucios en el disco.
vm.max_map_count 65530 - 262144 65530 Este archivo contiene el

número máximo de áreas
de asignación de memoria
que puede tener un
proceso. Las áreas de
asignación de memoria se
usan como efectos
secundarios de la llamada a
malloc , directamente
mediante mmap ,
mprotect y madvise , y
también cuando se cargan
bibliotecas compartidas.
vm.vfs_cache_pressure 1 - 500 100 Este valor de porcentaje

controla la tendencia del
kernel a reclamar la
memoria, que se usa para el
almacenamiento en caché
de objetos de directorio e
inode.
vm.swappiness 0 - 100 60 Este control se usa para

definir la intensidad con la
que el kernel cambiará las
páginas de memoria. Los
valores más altos
aumentarán la intensidad y
los valores más bajos
reducirán la cantidad de
intercambio. Un valor de 0
indica al kernel que no inicie
el intercambio hasta que la
cantidad de páginas libres y
de copia de seguridad de
archivos sea menor que la
marca de límite superior de
una zona.
swapFileSizeMB 1 MB: tamaño del disco None SwapFileSizeMB especifica

temporal (/dev/sdb) que se creará un tamaño en
MB de un archivo de
intercambio en los nodos
de agente de este grupo de
nodos.
transparentHugePageEnabled always , madvise , always Transparent Hugepages es

never una característica del kernel
de Linux diseñada para
mejorar el rendimiento al
hacer un uso más eficaz del
hardware de asignación de
memoria del procesador.
Cuando está habilitada, el
kernel intenta asignar
elementos hugepages
siempre que sea posible y
cualquier proceso de Linux
recibirá páginas de 2 MB si
la región mmap tiene una
alineación natural de 2 MB.
En determinados casos,
cuando están habilitados
elementos hugepages en
todo el sistema, las
aplicaciones pueden acabar
asignando más recursos de
memoria. Una aplicación
puede usar mmap con una
región grande, pero solo
tocar 1 byte de ella, en cuyo
caso, es posible que se
asigne una página de 2 MB
en lugar de una página de
4k por falta de una buena
razón para hacerlo. Este
caso es el motivo por el que
es posible deshabilitar
elementos hugepages en
todo el sistema o solo
tenerlos dentro de regiones
MADV_HUGEPAGE madvise .
transparentHugePageDefrag always , defer , madvise Este valor controla si el

defer+madvise , madvise kernel debe hacer un uso
, never intensivo de la
compactación de memoria
para que haya más
elementos hugepages
disponibles.
IMPORTANT
Para facilitar la búsqueda y la legibilidad, la configuración del sistema operativo se muestra en este documento por su
nombre, pero debe agregarse al archivo JSON de configuración o a la API AKS mediante la convención de uso de
mayúsculas camelCase.
Cree un archivo kubeletconfig.json con el siguiente contenido:

{
"cpuManagerPolicy": "static",
"cpuCfsQuota": true,
"cpuCfsQuotaPeriod": "200ms",
"imageGcHighThreshold": 90,
"imageGcLowThreshold": 70,
"topologyManagerPolicy": "best-effort",
"allowedUnsafeSysctls": [
"kernel.msg*",
"net.*"
],
"failSwapOn": false
}
Cree un archivo linuxosconfig.json con el siguiente contenido:
{
"transparentHugePageEnabled": "madvise",
"transparentHugePageDefrag": "defer+madvise",
"swapFileSizeMB": 1500,
"sysctls": {
"netCoreSomaxconn": 163849,
"netIpv4TcpTwReuse": true,
"netIpv4IpLocalPortRange": "32000 60000"
}
}
Cree un clúster que especifique las configuraciones de kublet y del sistema operativo con los archivos JSON
creados en el paso anterior.
NOTE
Al crear un clúster, puede especificar la configuración de kubelet, la configuración del sistema operativo, o ambas. Si
especifica una configuración al crear un clúster, solo se aplicará esa configuración a los nodos del grupo de nodos inicial.
Cualquier valor que no esté configurado en el archivo JSON conservará el valor predeterminado.
az aks create --name myAKSCluster --resource-group myResourceGroup --kubelet-config ./kubeletconfig.json --

linux-os-config ./linuxosconfig.json
Agregue un nuevo grupo de nodos que especifique los parámetros de Kubelet mediante el archivo JSON que
creó.
NOTE
Al agregar un grupo de nodos a un clúster existente, puede especificar la configuración de kubelet, la configuración del
sistema operativo, o ambas. Si especifica una configuración al agregar un grupo de nodos, solo se aplicará esa
configuración a los nodos del grupo de nodos nuevo. Cualquier valor que no esté configurado en el archivo JSON
conservará el valor predeterminado.
az aks nodepool add --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --

kubelet-config ./kubeletconfig.json
Pasos siguientes
Aprenda a configurar su clúster de AKS.
Aprenda a actualizar las imágenes de nodo del clúster.
Consulte Actualización de un clúster de Azure Kubernetes Service (AKS) para más información sobre cómo
actualizar el clúster a la versión más reciente de Kubernetes.
Consulte la lista de Preguntas más frecuentes sobre AKS para encontrar respuestas a algunas preguntas
comunes sobre AKS.
Autenticación con Azure Container Registry desde
Cuando se usa Azure Container Registry (ACR) con Azure Kubernetes Service (AKS), es preciso establecer un
mecanismo de autenticación. Esta operación se implementa como parte de la experiencia de la CLI y del portal
mediante la concesión de los permisos necesarios para ACR. En este artículo se proporcionan ejemplos para
configurar la autenticación entre estos dos servicios de Azure.
Puede configurar la integración de AKS en ACR con unos pocos comandos sencillos con la CLI de Azure. Esta
integración asigna el rol AcrPull a la identidad administrada asociada al clúster de AKS.
NOTE
En este artículo se trata la autenticación automática entre AKS y ACR. Si necesita extraer una imagen de un registro
externo privado, use un secreto de extracción de imágenes.
Antes de empezar
Estos ejemplos requieren:
Rol de propietario o administrador de cuenta de Azure en la suscripción de Azure .
La CLI de Azure, versión 2.7.0 o posterior
Para evitar la necesidad de un rol Propietario o Administrador de cuenta de Azure , puede configurar una
identidad administrada manualmente o usar una identidad administrada existente para autenticar ACR desde
AKS. Para obtener más información, consulte Use la identidad administrada de Azure para autenticarse en Azure
Container Registry.
Creación de un nuevo clúster de AKS con integración de ACR

Puede configurar la integración de AKS y ACR durante la creación inicial del clúster de AKS. Para permitir que un
clúster de AKS interactúe con ACR, se usa una identidad administrada de Azure Active Directory. El siguiente
comando de la CLI permite autorizar un ACR existente en su suscripción y configura el rol ACRPull adecuado
para la identidad administrada. Proporcione valores válidos para los parámetros siguientes.
# set this to the name of your Azure Container Registry. It must be globally unique
MYACR=myContainerRegistry
# Run the following line to create an Azure Container Registry if you do not already have one
az acr create -n $MYACR -g myContainerRegistryResourceGroup --sku basic
# Create an AKS cluster with ACR integration

az aks create -n myAKSCluster -g myResourceGroup --generate-ssh-keys --attach-acr $MYACR
De forma alternativa, el nombre de ACR se puede especificar mediante un identificador de recursos de ACR, que
tiene el siguiente formato:
/subscriptions/\<subscription-id\>/resourceGroups/\<resource-group-
name\>/providers/Microsoft.ContainerRegistry/registries/\<name\>
NOTE
Si usa un ACR que se encuentra en una suscripción diferente del clúster de AKS, use el identificador de recurso de ACR al
asociar o desasociar de un clúster de AKS.
az aks create -n myAKSCluster -g myResourceGroup --generate-ssh-keys --attach-acr

/subscriptions/<subscription-
id>/resourceGroups/myContainerRegistryResourceGroup/providers/Microsoft.ContainerRegistry/registries/myConta
inerRegistry
Este paso puede tardar varios minutos en completarse.
Configuración de la integración de ACR para clústeres de AKS

existentes
Para integrar un ACR existente con clústeres de AKS existentes, proporcione valores válidos para acr-name o
acr-resource-id , como se indica a continuación.
az aks update -n myAKSCluster -g myResourceGroup --attach-acr <acr-name>
o bien,
az aks update -n myAKSCluster -g myResourceGroup --attach-acr <acr-resource-id>
También puede quitar la integración entre un grupo de ACR y un clúster de AKS con lo siguiente
az aks update -n myAKSCluster -g myResourceGroup --detach-acr <acr-name>
or
az aks update -n myAKSCluster -g myResourceGroup --detach-acr <acr-resource-id>
Uso de ACR y AKS

Importación de una imagen en ACR
Importe una imagen de Docker Hub en ACR mediante la ejecución del código siguiente:
az acr import -n <acr-name> --source docker.io/library/nginx:latest --image nginx:v1
Implementación de la imagen de ejemplo de ACR en AKS

Asegúrese de que tiene las credenciales de AKS adecuadas
az aks get-credentials -g myResourceGroup -n myAKSCluster
Cree un archivo llamado acr-nginx.yaml que contenga el código siguiente. Sustituya el nombre del recurso del
registro por acr-name . Ejemplo: myContainerRegistry.
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx0-deployment
labels:
app: nginx0-deployment
spec:
replicas: 2
selector:
matchLabels:
app: nginx0
template:
metadata:
labels:
app: nginx0
spec:
containers:
- name: nginx
image: <acr-name>.azurecr.io/nginx:v1
ports:
- containerPort: 80
Después, ejecute esta implementación en el clúster de AKS:
kubectl apply -f acr-nginx.yaml
Para supervisar la implementación, ejecute:
kubectl get pods
Debe tener dos pods en ejecución.

nginx0-deployment-669dfc4d4b-x74kr 1/1 Running 0 20s
nginx0-deployment-669dfc4d4b-xdpd6 1/1 Running 0 20s
Ejecute el comando az aks check-acr para validar que el registro es accesible desde el clúster de AKS.
Obtenga más información sobre diagnósticos de ACR
Obtenga más información sobre el mantenimiento de ACR
Creación y configuración de un clúster de Azure
Kubernetes Service (AKS) para usar nodos virtuales
Para escalar rápidamente las cargas de trabajo de aplicaciones en un clúster de AKS, puede usar nodos virtuales.
Con los nodos virtuales, tiene un aprovisionamiento rápido de pods y solo paga por segundo para el tiempo de
ejecución. No es necesario que espere a que el escalador automático del clúster de Kubernetes implemente
nodos de proceso de máquina virtual para ejecutar los pods adicionales. Los nodos virtuales solo son
compatibles con los nodos y pods de Linux.
El complemento de nodos virtuales para AKS se basa en el proyecto de código abierto Virtual Kubelet.
En este artículo se ofrece información general sobre la disponibilidad regional y los requisitos de red para usar
nodos virtuales, así como las limitaciones conocidas.
Disponibilidad regional
Todas las regiones en las que ACI admita SKU de red virtual, se admiten para implementaciones de nodos
virtuales.
Para conocer las SKU de CPU y memoria disponibles en cada región, consulte Disponibilidad de recursos para
Azure Container Instances en las regiones de Azure: Grupos de contenedores de Linux.
Requisitos de red
Los nodos virtuales permiten la comunicación de red entre los pods que se ejecutan en Azure Container
Instances (ACI) y el clúster de AKS. Para proporcionar esta comunicación, se crea una subred de red virtual y se
asignan permisos delegados. Los nodos virtuales solo funcionan con clústeres de AKS creados mediante redes
avanzadas (Azure CNI). De forma predeterminada, los clústeres de AKS se crean con redes básicas (kubenet).
Los pods que se ejecutan en Azure Container Instances (ACI) necesitan acceder al punto de conexión del
servidor de API de AKS para configurar las funciones de red.
Restricciones conocidas
La funcionalidad de nodos virtuales es muy dependiente del conjunto de características de ACI. Además de las
cuotas y los límites de Azure Container Instances, los siguientes escenarios no se admiten aún con los nodos
virtuales:
Uso de entidad de servicio para extraer imágenes de ACR. La solución alternativa consiste en usar secretos
de Kubernetes
Limitaciones de la red virtual entre las que se incluyen el emparejamiento de redes virtuales, las directivas de
red de Kubernetes y el tráfico saliente a Internet con grupos de seguridad de red.
Iniciar contenedores
Hospedaje de alias
Argumentos para la ejecución en ACI
DaemonSets no implementará pods en los nodos virtuales.
Los nodos virtuales admiten la programación de pods de Linux. Puede instalar manualmente el proveedor de
código abierto ACI de Kubelet virtual para programar contenedores de Windows Server en ACI.
Los nodos virtuales necesitan clústeres de AKS con redes de Azure CNI.
Uso de intervalos IP autorizados de servidor de API para AKS.
El montaje de volúmenes con recursos compartidos de Azure Files es compatible con las cuentas de uso
general V1. Siga las instrucciones para montar un volumen con un recurso compartido de Azure Files.
El uso de IPv6 no se admite.
Pasos siguientes
Configure nodos virtuales para los clústeres:
Creación de nodos virtuales mediante la CLI de Azure
Creación de nodos virtuales mediante el portal en Azure Kubernetes Service (AKS)
Los nodos virtuales suelen ser un componente de una solución de escalado en AKS. Para más información sobre
soluciones de escalado, consulte los siguientes artículos:
Escalador horizontal automático de pods de Kubernetes
Escalador automático de clústeres de Kubernetes
Ejemplo de escalador automático para nodos virtuales
Más información sobre la biblioteca virtual de código abierto de Kubelet
mediante la CLI de Azure
En este artículo se muestra cómo usar la CLI de Azure para crear y configurar los recursos de red virtual y un
clúster de AKS, y cómo habilitar después los nodos virtuales.
Antes de empezar
avanzadas (Azure CNI). De forma predeterminada, los clústeres de AKS se crean con redes básicas (kubenet). En
este artículo se explica cómo crear una red virtual y subredes y, después, cómo implementar un clúster de AKS
que usa redes avanzadas.
IMPORTANT
Antes de usar nodos virtuales con AKS, revise las limitaciones de los nodos virtuales de AKS y las limitaciones de redes
virtuales de ACI. Estas limitaciones afectan a la ubicación, la configuración de redes y otros detalles de configuración del
clúster de AKS y los nodos virtuales.
Si no ha utilizado anteriormente ACI, registre el proveedor de servicio con su suscripción. Puede comprobar el
estado de registro del proveedor de ACI mediante el comando az provider list, tal como se muestra en el
siguiente ejemplo:
az provider list --query "[?contains(namespace,'Microsoft.ContainerInstance')]" -o table
El proveedor Microsoft.ContainerInstance debería notificar como Registrado, tal como se muestra en el siguiente
ejemplo de salida:
Namespace RegistrationState RegistrationPolicy

--------------------------- ------------------- --------------------
Microsoft.ContainerInstance Registered RegistrationRequired
Si el proveedor se muestra como NotRegistered, registre el proveedor con el comando az provider register tal
como se muestra en el siguiente ejemplo:
az provider register --namespace Microsoft.ContainerInstance
Inicio de Azure Cloud Shell

Azure Cloud Shell es un shell interactivo gratuito que puede usar para ejecutar los pasos de este artículo. Tiene
las herramientas comunes de Azure preinstaladas y configuradas para usarlas en la cuenta.
Para abrir Cloud Shell, seleccione Pruébelo en la esquina superior derecha de un bloque de código. También
puede ir a https://shell.azure.com/bash para iniciar Cloud Shell en una pestaña independiente del explorador.
Seleccione Copiar para copiar los bloques de código, péguelos en Cloud Shell y, luego, presione Entrar para
ejecutarlos.
Si prefiere instalar y usar la CLI en un entorno local, para este artículo se requiere la versión 2.0.49 de la CLI de
Azure o una versión posterior. Ejecute az --version para encontrar la versión. Si necesita instalarla o
actualizarla, vea Instalación de la CLI de Azure.

Para crear un grupo de recursos, use el comando az group create. En el ejemplo siguiente, se crea un grupo de
recursos denominado myResourceGroup en la ubicación westus.
az group create --name myResourceGroup --location westus
Creación de una red virtual

Cree una red virtual con el comando az network vnet create. En el ejemplo siguiente se crea una red virtual
denominada myVnet con un prefijo de dirección de 10.0.0.0/8 y una subred llamada myAKSSubnet. El valor
predeterminado del prefijo de la dirección de esta subred es 10.240.0.0/16:
az network vnet create \

--name myVnet \
--address-prefixes 10.0.0.0/8 \
--subnet-name myAKSSubnet \
--subnet-prefix 10.240.0.0/16
Ahora cree una subred adicional para los nodos virtuales mediante el comando az network vnet subnet create.
En el ejemplo siguiente se crea una subred llamada myVirtualNodeSubnet con el prefijo de dirección
10.241.0.0/16.
az network vnet subnet create \

--vnet-name myVnet \
--name myVirtualNodeSubnet \
--address-prefixes 10.241.0.0/16
Creación de una entidad de servicio o uso de una identidad

administrada
Para permitir que un clúster de AKS interactúe con otros recursos de Azure, se usa una identidad de clúster. Esta
identidad de clúster se puede crear automáticamente mediante la CLI de Azure o el portal, o puede crear una
previamente y asignar permisos adicionales. De manera predeterminada, esta identidad de clúster es una
identidad administrada. Para más información, consulte Uso de identidades administradas. También puede usar
una entidad de servicio como identidad de clúster. En los pasos siguientes se muestra cómo crear y asignar
manualmente la entidad de servicio al clúster.
Cree una entidad de servicio mediante el comando az ad sp create-for-rbac. El parámetro --skip-assignment
impide que se asignen permisos adicionales.
az ad sp create-for-rbac --skip-assignment
La salida es similar a la del ejemplo siguiente:
{
"appId": "bef76eb3-d743-4a97-9534-03e9388811fc",
"displayName": "azure-cli-2018-11-21-18-42-00",
"name": "http://azure-cli-2018-11-21-18-42-00",
"password": "1d257915-8714-4ce7-a7fb-0e5a5411df7f",
"tenant": "72f988bf-86f1-41af-91ab-2d7cd011db48"
}
Anote el valor de appId y password. Estos valores se usan en los pasos siguientes.
Asignación de permisos a la red virtual

Para permitir que el clúster use y administre la red virtual, debe conceder a la entidad de servicio de AKS los
derechos apropiados para usar los recursos de red.
En primer lugar, obtenga el identificador de recurso de red virtual mediante az network vnet show:
az network vnet show --resource-group myResourceGroup --name myVnet --query id -o tsv
Para conceder el acceso correcto al clúster de AKS para usar la red virtual, cree una asignación de roles
mediante el comando az role assignment create. Reemplace <appId > y <vnetId> por los valores recopilados
en los dos pasos anteriores.
az role assignment create --assignee <appId> --scope <vnetId> --role Contributor

Implemente el clúster de AKS en la subred de AKS creada en un paso anterior. Obtenga el identificador de esta
subred mediante az network vnet subnet show:
az network vnet subnet show --resource-group myResourceGroup --vnet-name myVnet --name myAKSSubnet --query
id -o tsv
denominado myAKSCluster con un nodo. Reemplace <subnetId> con el identificador obtenido en el paso
anterior y, a continuación, <appId> y <password> con los valores recopilados en la sección anterior.
az aks create \
--node-count 1 \
--network-plugin azure \
--service-cidr 10.0.0.0/16 \
--dns-service-ip 10.0.0.10 \
--docker-bridge-address 172.17.0.1/16 \
--vnet-subnet-id <subnetId> \
--service-principal <appId> \
--client-secret <password>
En unos minutos, terminará de ejecutarse el comando, que devuelve información con formato JSON sobre el
clúster.
Habilitar complemento de nodos virtuales

Para habilitar los nodos virtuales, ahora use el comando az aks enable-addons. En el ejemplo siguiente se usa la
subred denominada myVirtualNodeSubnet creada en un paso anterior:
az aks enable-addons \
--addons virtual-node \
--subnet-name myVirtualNodeSubnet
Para configurar kubectl para conectarse a su clúster de Kubernetes, use el comando az aks get-credentials. Con
este paso se descargan las credenciales y se configura la CLI de Kubernetes para usarlas.
Para comprobar la conexión al clúster, use el comando kubectl get para devolver una lista de los nodos del
clúster.
kubectl get nodes
La salida de ejemplo siguiente muestra el nodo de máquina virtual único creado y luego el nodo virtual para
Linux, virtual-node-aci-linux:

virtual-node-aci-linux Ready agent 28m v1.11.2
Implementación de una aplicación de ejemplo

Cree un archivo denominado virtual-node.yaml y cópielo en el siguiente código YAML. Para programar el
contenedor en el nodo, se definen nodeSelector y toleration.
apiVersion: apps/v1
kind: Deployment
metadata:
name: aci-helloworld
spec:
replicas: 1
selector:
matchLabels:
app: aci-helloworld
template:
metadata:
labels:
app: aci-helloworld
spec:
containers:
- name: aci-helloworld
image: mcr.microsoft.com/azuredocs/aci-helloworld
ports:
- containerPort: 80
nodeSelector:
kubernetes.io/role: agent
beta.kubernetes.io/os: linux
type: virtual-kubelet
tolerations:
- key: virtual-kubelet.io/provider
operator: Exists
- key: azure.com/aci
effect: NoSchedule
Ejecute la aplicación con el comando kubectl apply.
kubectl apply -f virtual-node.yaml
Use el comando kubectl get pods con el argumento -o wide para generar una lista de los pods y el nodo
programado. Observe que el pod aci-helloworld se ha programado en el nodo virtual-node-aci-linux .
kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE

aci-helloworld-9b55975f-bnmfl 1/1 Running 0 4m 10.241.0.4 virtual-node-aci-linux
Se asigna una dirección IP interna al pod de la subred de red virtual de Azure delegada para su uso con los
nodos virtuales.
NOTE
Si usa imágenes almacenadas en Azure Container Registry, configure y use un secreto de Kubernetes. Una limitación
actual de los nodos virtuales es que no se puede usar la autenticación de entidad de servicio de Azure AD integrada. Si no
usa un secreto, los pods programados en los nodos virtuales no se pueden iniciar y se notifica el error
HTTP response status code 400 error code "InaccessibleImage" .
Prueba del pod del nodo virtual

Para probar el pod que se ejecuta en el nodo virtual, vaya a la aplicación de demostración con un cliente web.
Como se asigna una dirección IP interna al pod, puede probar rápidamente esta conectividad desde otro pod en
el clúster de AKS. Cree un pod de prueba y asóciele una sesión de terminal:
kubectl run -it --rm testvk --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
Instale curl en el pod mediante apt-get :
apt-get update && apt-get install -y curl
Ahora acceda a la dirección de su pod mediante curl , como http://10.241.0.4 . Proporcione su propia dirección
IP interna mostrada en el comando kubectl get pods anterior:
curl -L http://10.241.0.4
Se muestra la aplicación de demostración, tal como se muestra en la siguiente salida de ejemplo reducida:
<html>
<head>
<title>Welcome to Azure Container Instances!</title>
</head>
[...]
Cierre la sesión de terminal en su pod de prueba con exit . Cuando la sesión finaliza, el pod se elimina.
Quitar nodos virtuales

Si ya no desea usar los nodos virtuales, puede deshabilitarlos mediante el comando az aks disable-addons.
Si es necesario, vaya a https://shell.azure.com para abrir Azure Cloud Shell en el explorador.
En primer lugar, elimine el pod aci-helloworld que se ejecuta en el nodo virtual:
kubectl delete -f virtual-node.yaml
En el comando de ejemplo siguiente se deshabilitan los nodos virtuales de Linux:
az aks disable-addons --resource-group myResourceGroup --name myAKSCluster --addons virtual-node
Ahora, quite los recursos de red virtual y el grupo de recursos:

# Change the name of your resource group, cluster and network resources as needed
RES_GROUP=myResourceGroup
AKS_CLUSTER=myAKScluster
AKS_VNET=myVnet
AKS_SUBNET=myVirtualNodeSubnet
# Get AKS node resource group

NODE_RES_GROUP=$(az aks show --resource-group $RES_GROUP --name $AKS_CLUSTER --query nodeResourceGroup --
output tsv)
# Get network profile ID

NETWORK_PROFILE_ID=$(az network profile list --resource-group $NODE_RES_GROUP --query [0].id --output tsv)
# Delete the network profile

az network profile delete --id $NETWORK_PROFILE_ID -y
# Delete the subnet delegation to Azure Container Instances

az network vnet subnet update --resource-group $RES_GROUP --vnet-name $AKS_VNET --name $AKS_SUBNET --remove
delegations 0
Pasos siguientes
En este artículo, se programó un pod en el nodo virtual y se le asignó una dirección IP privada o interna. En su
lugar, podría crear una implementación de servicio y enrutar el tráfico a su pod a través de un equilibrador de
carga o controlador de entrada. Para más información, consulte Creación de un controlador de entrada en Azure
Los nodos virtuales suelen ser un componente de una solución de escalado en AKS. Para más información sobre
en Azure Portal
En este artículo se muestra cómo usar Azure Portal para crear y configurar los recursos de red virtual y un
clúster de AKS con nodos virtuales habilitados.
NOTE
En este artículo se ofrece información general sobre la disponibilidad y las limitaciones de regiones usando nodos
virtuales.
Antes de empezar
avanzadas (Azure CNI). De forma predeterminada, los clústeres de AKS se crean con redes básicas (kubenet). En
este artículo se explica cómo crear una red virtual y subredes y, después, cómo implementar un clúster de AKS
que usa redes avanzadas.
Si no ha utilizado anteriormente ACI, registre el proveedor de servicio con su suscripción. Puede comprobar el
estado de registro del proveedor de ACI mediante el comando az provider list, tal como se muestra en el
siguiente ejemplo:
az provider list --query "[?contains(namespace,'Microsoft.ContainerInstance')]" -o table
El proveedor Microsoft.ContainerInstance debería notificar como Registrado, tal como se muestra en el siguiente
ejemplo de salida:
Namespace RegistrationState RegistrationPolicy

--------------------------- ------------------- --------------------
Microsoft.ContainerInstance Registered RegistrationRequired
Si el proveedor se muestra como NotRegistered, registre el proveedor con el comando az provider register tal
az provider register --namespace Microsoft.ContainerInstance
Inicio de sesión en Azure

Inicie sesión en Azure Portal en https://portal.azure.com.

En la esquina superior izquierda de Azure Portal, seleccione Crear un recurso > Kubernetes Ser vice .
En la página Datos básicos , configure las siguientes opciones:
DETALLES DEL PROYECTO: seleccione una suscripción de Azure y, a continuación, seleccione o cree un grupo
de recursos de Azure, como myResourceGroup. Escriba un Nombre del clúster de Kubernetes , como
myAKSCluster.
DETALLES DEL CLÚSTER: seleccione una región y una versión de Kubernetes para el clúster de AKS.
GRUPO DE NODOS PRINCIPAL: seleccione un tamaño de máquina virtual para los nodos de AKS. El tamaño
de VM no puede cambiarse una vez que se ha implementado un clúster de AKS.
Seleccione el número de nodos que se van a implementar en el clúster. Para este artículo, establezca
Número de nodos en 1. El número de nodos puede ajustarse después de implementar el clúster.
Haga clic en Next: Node Pools (Siguiente: Grupos de nodos).
En la página Node Pools (Grupos de nodos), seleccione Enable virtual nodes (Habilitar nodos virtuales).
De forma predeterminada, se crea una identidad del clúster. Esta identidad del clúster se usa para la
comunicación del clúster y la integración con otros servicios de Azure. De forma predeterminada, esta identidad
del clúster es una identidad administrada. Para más información, consulte Uso de identidades administradas.
También puede usar una entidad de servicio como identidad del clúster.
El clúster también se configurado para redes avanzadas. Los nodos virtuales están configurados para usar su
propia subred de red virtual de Azure. Esta subred tiene permisos delegados para conectarse a recursos de
Azure entre el clúster de AKS. Si aún no tiene una subred delegada, Azure Portal crea y configura la red virtual
de Azure y la subred para su uso con los nodos virtuales.
Seleccione Revisar + crear . Una vez completada la validación, seleccione Crear .
Se tardan unos minutos en crear el clúster de AKS y en prepararlo para usarlo.
Azure Cloud Shell es un shell interactivo gratuito que puede usar para ejecutar los pasos de este artículo. Tiene
las herramientas comunes de Azure preinstaladas y configuradas para usarlas en la cuenta. Para administrar un
clúster de Kubernetes, use kubectl, el cliente de línea de comandos de Kubernetes. El cliente kubectl viene
preinstalado en Azure Cloud Shell.
Para abrir Cloud Shell, seleccione Pruébelo en la esquina superior derecha de un bloque de código. También
puede ir a https://shell.azure.com/bash para iniciar Cloud Shell en una pestaña independiente del explorador.
Seleccione Copiar para copiar los bloques de código, péguelos en Cloud Shell y, luego, presione Entrar para
ejecutarlos.
Use el comando az aks get-credentials para configurar kubectl para conectarse a su clúster de Kubernetes. En
el ejemplo siguiente se obtienen credenciales para el nombre de clúster myAKSCluster del grupo de recursos
denominado myResourceGroup:
clúster.
kubectl get nodes
La salida de ejemplo siguiente muestra el nodo de máquina virtual único creado y luego el nodo virtual para
Linux, virtual-node-aci-linux:

virtual-node-aci-linux Ready agent 28m v1.11.2
Implementación de una aplicación de ejemplo

En Azure Cloud Shell, cree un archivo denominado virtual-node.yaml y cópielo en el siguiente código YAML.
Para programar el contenedor en el nodo, se definen nodeSelector y toleration. Estas configuraciones permiten
que el pod se programe en el nodo virtual y confirmen que la característica está habilitada correctamente.
apiVersion: apps/v1
kind: Deployment
metadata:
name: aci-helloworld
spec:
replicas: 1
selector:
matchLabels:
app: aci-helloworld
template:
metadata:
labels:
app: aci-helloworld
spec:
containers:
- name: aci-helloworld
image: mcr.microsoft.com/azuredocs/aci-helloworld
ports:
- containerPort: 80
nodeSelector:
kubernetes.io/role: agent
type: virtual-kubelet
tolerations:
- key: virtual-kubelet.io/provider
operator: Exists
Ejecute la aplicación con el comando kubectl apply.
kubectl apply -f virtual-node.yaml
Use el comando kubectl get pods con el argumento -o wide para generar una lista de los pods y el nodo
programado. Observe que el pod virtual-node-helloworld se ha programado en el nodo virtual-node-linux .
kubectl get pods -o wide

virtual-node-helloworld-9b55975f-bnmfl 1/1 Running 0 4m 10.241.0.4 virtual-node-
aci-linux
Se asigna una dirección IP interna al pod de la subred de red virtual de Azure delegada para su uso con los
nodos virtuales.
NOTE
Si usa imágenes almacenadas en Azure Container Registry, configure y use un secreto de Kubernetes. Una limitación
actual de los nodos virtuales es que no se puede usar la autenticación de entidad de servicio de Azure AD integrada. Si no
usa un secreto, los pods programados en los nodos virtuales no se pueden iniciar y se notifica el error
HTTP response status code 400 error code "InaccessibleImage" .
Prueba del pod del nodo virtual

Para probar el pod que se ejecuta en el nodo virtual, vaya a la aplicación de demostración con un cliente web.
Como se asigna una dirección IP interna al pod, puede probar rápidamente esta conectividad desde otro pod en
el clúster de AKS. Cree un pod de prueba y asóciele una sesión de terminal:
kubectl run -it --rm virtual-node-test --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
Ahora acceda a la dirección de su pod mediante curl , como http://10.241.0.4 . Proporcione su propia dirección
IP interna mostrada en el comando kubectl get pods anterior:
curl -L http://10.241.0.4
Se muestra la aplicación de demostración, tal como se muestra en la siguiente salida de ejemplo reducida:
<html>
<head>
<title>Welcome to Azure Container Instances!</title>
</head>
[...]
Cierre la sesión de terminal en su pod de prueba con exit . Cuando la sesión finaliza, el pod se elimina.
Pasos siguientes
En este artículo, se programó un pod en el nodo virtual y se le asignó una dirección IP privada o interna. En su
lugar, podría crear una implementación de servicio y enrutar el tráfico a su pod a través de un equilibrador de
carga o controlador de entrada. Para más información, consulte Creación de un controlador de entrada en Azure
Los nodos virtuales son un componente de una solución de escalado en AKS. Para más información sobre
Escalar automáticamente un clúster para satisfacer
las necesidades de la aplicación en Azure
Para satisfacer las necesidades de la aplicación en Azure Kubernetes Service (AKS), es posible que deba ajustar el
número de nodos que ejecutan las cargas de trabajo. El componente de escalado automático de clústeres puede
supervisar los pods del clúster que no pueden programarse debido a las restricciones de los recursos. Cuando
se detectan problemas, la cantidad de nodos de un grupo de nodos aumenta para satisfacer las necesidades de
la aplicación. Asimismo, los nodos también se comprueban regularmente para detectar la falta de pods en
ejecución y, en consecuencia, la cantidad de nodos se reduce según sea necesario. Esta capacidad de ampliar o
reducir automáticamente la cantidad de nodos en su clúster de AKS le permite ejecutar un clúster de forma
eficaz y rentable.
En este artículo se muestra cómo habilitar y administrar el escalado automático de clústeres en un clúster de
AKS.
Antes de empezar
Para este artículo, es necesario usar la versión 2.0.76 de la CLI de Azure o posterior. Ejecute az --version para
Acerca del escalado automático de clústeres

Para adaptarse a las cambiantes necesidades de las aplicaciones, como detallar los horarios entre la jornada
laboral y la noche o un fin de semana, los clústeres a menudo necesitan una forma de realizar automáticamente
el escalado. Los clústeres de AKS pueden escalarse mediante una de dos maneras:
El escalado automático de clústeres busca pods que no puedan programarse en nodos debido a las
restricciones de los recursos. Luego, el clúster aumenta automáticamente la cantidad de nodos.
El escalado automático horizontal de pods usa el servidor de métricas en un clúster de Kubernetes para
supervisar la demanda de recursos de los pods. Si una aplicación necesita más recursos, el número de pods
aumenta automáticamente para satisfacer la demanda.
Tanto Horizontal Pod Autoscaler como Cluster Autoscaler pueden reducir el número de pods y nodos según sea
necesario. El escalado automático de clústeres reduce el número de nodos cuando no se usa toda la capacidad
durante un período de tiempo. Los pods de un nodo que quitará el escalado automático de clústeres se
programan con seguridad en otra parte del clúster. El escalado automático de clústeres no se puede reducir
verticalmente si no se pueden mover los pods, tal como se detalla en las situaciones siguientes:
Un pod se crea directamente y no lo respalda un objeto de controlador, como una implementación o un
conjunto de réplicas.
Un presupuesto de interrupciones de pods (PDB) es demasiado restrictivo y no permite que la cantidad de
pods sea menor que el umbral definido.
Un pod usa selectores de nodo o antiafinidad que no se pueden respetar si se programan en un nodo
diferente.
Para obtener más información acerca de cómo el escalado automático de clústeres no puede realizar
reducciones verticales, consulte What types of pods can prevent the cluster autoscaler from removing a node?
(¿Qué tipos de pods pueden evitar que el escalado automático de clústeres elimine un nodo?)
El escalado automático de clústeres usa parámetros de inicio para cosas como intervalos de tiempo entre
eventos de escalado y umbrales de recursos. Para más información sobre los parámetros que usa el escalado
automático de clústeres, consulte Uso del perfil del escalador automático.
Horizontal Pod Autoscaler y Cluster Autoscaler pueden funcionar juntos y a menudo se implementan en un
clúster. Cuando se combinan, el escalado automático horizontal de pods se centra en ejecutar el número de pods
necesario para satisfacer las exigencias de la aplicación. El escalado automático de clústeres se centra en ejecutar
el número de nodos necesario para admitir los pods programados.
NOTE
El escalado manual está deshabilitado cuando se usa el escalado automático de clústeres. Permita que el escalado
automático de clústeres determine el número de nodos. Si quiere escalar manualmente el clúster, deshabilite el escalado
automático de clústeres.
Crear un clúster de AKS y habilitar el escalado automático de

clústeres
Si necesita crear un clúster de AKS, use el comando az aks create. Para habilitar y configurar el escalado
automático de clústeres en el grupo de nodos del clúster, use el parámetro --enable-cluster-autoscaler y
especifique un nodo --min-count y --max-count .
IMPORTANT
El escalador automático del clúster es un componente de Kubernetes. Aunque el clúster de AKS usa un conjunto de
escalado de máquinas virtuales para los nodos, no habilite ni edite manualmente la configuración de escalado automático
del conjunto de escalado en Azure Portal o mediante la CLI de Azure. Permita que el escalador automático del clúster de
Kubernetes administre la configuración del escalado necesaria. Para más información, consulte ¿Puedo modificar los
recursos de AKS en el grupo de recursos del nodo?
En el ejemplo siguiente se crea un clúster de AKS con un único grupo de nodos respaldado por un conjunto de
escalado de máquinas virtuales. También habilita la escalabilidad automática del clúster en el grupo de nodos
para el clúster y establece un mínimo de 1 y un máximo de 3 nodos:
# First create a resource group
# Now create the AKS cluster and enable the cluster autoscaler
az aks create \
--node-count 1 \
--min-count 1 \
--max-count 3
Tardará unos minutos en crear el clúster y configurar las opciones del escalado automático de clústeres.
Actualización de un clúster de AKS existente para habilitar el

escalador automático de clústeres
Use el comando az aks update para habilitar y configurar el escalador automático de clústeres en el grupo de
nodos para el clúster existente. Use el parámetro --enable-cluster-autoscaler y especifique un nodo
--min-count y --max-count .
IMPORTANT
El escalador automático del clúster es un componente de Kubernetes. Aunque el clúster de AKS usa un conjunto de
escalado de máquinas virtuales para los nodos, no habilite ni edite manualmente la configuración de escalado automático
del conjunto de escalado en Azure Portal o mediante la CLI de Azure. Permita que el escalador automático del clúster de
Kubernetes administre la configuración del escalado necesaria. Para más información, consulte ¿Puedo modificar los
recursos de AKS en el grupo de recursos del nodo?
En el ejemplo siguiente se actualiza un clúster de AKS existente para habilitar el escalador automático de
clústeres en el grupo de nodos para el clúster y se establece un mínimo de 1 y un máximo de 3 nodos:
az aks update \
--min-count 1 \
--max-count 3
Tardará unos minutos en actualizar el clúster y configurar las opciones del escalador automático de clústeres.
Cambiar la configuración del escalado automático de clústeres

IMPORTANT
Si tiene varios grupos de nodos en el clúster de AKS, vaya a la sección de escalado automático con varios grupos de
agentes. Los clústeres con varios grupos de agentes habilitados requieren el uso del conjunto de comandos
az aks nodepool para cambiar las propiedades específicas del grupo de nodos en lugar de az aks .
En el paso anterior para crear un clúster de AKS o actualizar un grupo de nodos existente, el número mínimo de
nodos del escalado automático de clústeres se estableció en 1, y el número máximo de nodos se estableció en 3.
Como las necesidades de la aplicación van cambiando, es posible que deba ajustar el número de nodos del
escalado automático de clústeres.
Para cambiar el número de nodos, use el comando az aks update.
az aks update \
--update-cluster-autoscaler \
--min-count 1 \
--max-count 5
En el ejemplo anterior se actualiza el escalado automático del clúster en el único grupo de nodos de
myAKSCluster a un mínimo de 1 y un máximo de 5 nodos.
NOTE
El escalador automático del clúster toma sus decisiones de escalado en función de los recuentos mínimo y máximo
establecidos en cada grupo de nodos, pero no los aplica después de actualizar los recuentos mínimo o máximo. Por
ejemplo, si se establece un recuento mínimo de 5 cuando el recuento de nodos actual es 3, no se escala inmediatamente
el grupo hasta 5. Si el recuento mínimo en el grupo de nodos tiene un valor superior al número actual de nodos, la nueva
configuración mínima o máxima se respeta si hay suficientes pods que no se pueden programar que requieren dos
nuevos nodos más y desencadenan un evento del escalador automático. Tras el evento de escala, se respetan los nuevos
límites de recuento.
Supervise el rendimiento de las aplicaciones y los servicios y ajuste la cantidad de nodos del escalado
automático de clústeres para que coincida con el rendimiento necesario.
Uso del perfil del escalador automático

También puede configurar detalles más pormenorizados del escalador automático de clúster si cambia los
valores predeterminados en el perfil del escalador automático para todo el clúster. Por ejemplo, se produce un
evento de reducción vertical una vez que los nodos se infrautilizan después de 10 minutos. Si tenía cargas de
trabajo que se ejecutaban cada 15 minutos, puede que quiera cambiar el perfil del escalador automático para
reducir verticalmente bajo los nodos que se infrautilizan después de 15 o 20 minutos. Cuando se habilita el
escalador automático del clúster, se usa un perfil predeterminado a menos que se especifiquen otros valores. El
perfil del escalador automático del clúster tiene esta configuración que puede actualizar:
C O N F IGURA C IÓ N DESC RIP C IÓ N VA LO R P REDET ERM IN A DO
scan-interval Frecuencia con la que se vuelve a 10 segundos

evaluar el clúster para escalar o reducir
verticalmente
scale-down-delay-after-add Cuánto tiempo después del escalado 10 minutos

vertical se reanuda la evaluación de la
reducción horizontal
scale-down-delay-after-delete Cuánto tiempo después de la scan-interval

eliminación del nodo se reanuda la
evaluación de la reducción horizontal
scale-down-delay-after-failure Cuánto tiempo después de la 3 minutos

reducción vertical se reanuda la
evaluación de la reducción horizontal
scale-down-unneeded-time Cuánto tiempo debe ser innecesario 10 minutos

un nodo antes de que sea válido para
la reducción vertical
scale-down-unready-time Cuánto tiempo debe ser innecesario 20 minutos

un nodo no listo antes de que sea
válido para la reducción vertical
scale-down-utilization-threshold Nivel de uso del nodo, definido como 0.5

la suma de los recursos solicitados
dividida por la capacidad, por debajo
del cual se puede considerar un nodo
para la reducción vertical
max-graceful-termination-sec Número máximo de segundos que la 600 segundos

escalabilidad automática del clúster
espera la terminación del pod al
intentar reducir verticalmente un
nodo.
balance-similar-node-groups Detecta grupos de nodos similares y false

equilibra el número de nodos entre
ellos
expander Tipo de grupo de nodos expander que random

se va a usar en el escalado vertical.
Valores posibles: most-pods ,
random , least-waste , priority
skip-nodes-with-local-storage Si es true, el escalador automático del true

clúster no eliminará nunca nodos con
pods con almacenamiento local, por
ejemplo, EmptyDir o HostPath
skip-nodes-with-system-pods Si es true, el escalador automático del true

clúster nunca eliminará los nodos con
pods de kube-system (excepto para
DaemonSet o mirror)
max-empty-bulk-delete Número máximo de nodos vacíos que 10 nodos

se pueden eliminar al mismo tiempo.
new-pod-scale-up-delay En escenarios como la escala de 0 segundos

ráfagas y lotes en los que no quiere
que la CA actúe antes de que el
programador de Kubernetes programe
todos los pods, puede indicarle a la CA
que ignore los pods no programados
antes de que tengan una antigüedad
concreta.
max-total-unready-percentage Porcentaje máximo de nodos no leídos 45 %

en el clúster. Una vez que se haya
superado este porcentaje, la CA
detiene las operaciones
max-node-provision-time Tiempo máximo que la escalabilidad 15 minutos

automática espera a que se
aprovisione un nodo.
ok-total-unready-count Número de nodos no leídos 3 nodos

permitidos, con independencia del
valor de max-total-unready-
percentage
IMPORTANT
El perfil del escalador automático del clúster afecta a todos los grupos de nodos que usan el escalador automático del
clúster. No se puede establecer un perfil del escalador automático por grupo de nodos.
El perfil de escalabilidad automática del clúster requiere la versión 2.11.1 o superior de la CLI de Azure. Si necesita
instalarla o actualizarla, vea Instalación de la CLI de Azure.
Establecimiento del perfil del escalador automático del clúster en un clúster de AKS existente
Use el comando az aks update con el parámetro cluster-autoscaler-profile para establecer el perfil del escalador
automático del clúster en el clúster. En el ejemplo siguiente se configura el valor de intervalo de detección como
30 segundos en el perfil.
az aks update \
--cluster-autoscaler-profile scan-interval=30s
Al habilitar el escalador automático del clúster en los grupos de nodos del clúster, esos clústeres también usarán
el perfil del escalador automático del clúster. Por ejemplo:
az aks nodepool update \

--name mynodepool \
--min-count 1 \
--max-count 3
IMPORTANT
Al establecer el perfil del escalador automático del clúster, los grupos de nodos existentes con el escalador automático del
clúster habilitado comenzarán a usar el perfil de inmediato.
Establecimiento del perfil del escalador automático del clúster al crear un clúster de AKS
También puede usar el parámetro cluster-autoscaler-profile al crear el clúster. Por ejemplo:
az aks create \
--node-count 1 \
--min-count 1 \
--max-count 3 \
--cluster-autoscaler-profile scan-interval=30s
El comando anterior crea un clúster de AKS y define el intervalo de detección como 30 segundos para el perfil
del escalador automático de todo el clúster. El comando también habilita el escalador automático del clúster en
el grupo de nodos inicial, establece el número mínimo de nodos en 1 y el número máximo de nodos en 3.
Restablecimiento del perfil de escalador automático del clúster a los valores predeterminados
Use el comando az aks update para restablecer el perfil del escalador del clúster en el clúster.
az aks update \
--cluster-autoscaler-profile ""
Deshabilitar el escalado automático de clústeres

Si ya no quiere usar el escalado automático de clústeres, puede deshabilitarlo mediante el comando az aks
update, especificando el parámetro --disable-cluster-autoscaler . Los nodos no se quitan cuando se deshabilita
el escalado automático de clústeres.
az aks update \
--disable-cluster-autoscaler
Puede escalar manualmente el clúster después de deshabilitar el escalado automático del clúster mediante el
comando az aks scale. Si usa el escalado automático horizontal de pods, esa característica continúa ejecutándose
con el escalado automático de clústeres deshabilitado, pero es posible que los pods no puedan programarse si
todos los recursos de nodo están en uso.
Volver a habilitar un escalado automático de clústeres deshabilitado

Si quiere volver a habilitar el escalado automático de clústeres en un clúster existente, puede hacerlo mediante
el comando az aks update, si especifica los parámetros --enable-cluster-autoscaler , --min-count y
--max-count .
Recuperación de registros y estado del escalador automático del

clúster
Para diagnosticar y depurar los eventos del escalador automático, los registros y el estado se pueden recuperar
desde el complemento del escalador automático.
AKS administra el escalador automático del clúster en su nombre y lo ejecuta en el plano de control
administrado. Puede habilitar el nodo del plano de control para ver los registros y las operaciones de la CA.
Para configurar los registros que se van a insertar desde el escalador automático del clúster en Log Analytics,
siga estos pasos.
1. Configure una regla para que los registros de recursos inserten registros del escalador automático del
clúster en Log Analytics. Las instrucciones se detallan aquí, asegúrese de activar la casilla correspondiente a
cluster-autoscaler al seleccionar las opciones para "Registros".
2. Seleccione la sección "Registros" del clúster mediante Azure Portal.
3. Escriba la consulta de ejemplo siguiente en Log Analytics:
AzureDiagnostics
| where Category == "cluster-autoscaler"
Debería ver devueltos registros similares al ejemplo siguiente, siempre y cuando haya registros para recuperar.
El escalador automático del clúster también escribirá el estado de mantenimiento en un objeto configmap
llamado cluster-autoscaler-status . Para recuperar estos registros, ejecute el comando siguiente kubectl . Se
informará del estado de mantenimiento para cada grupo de nodos configurado con el escalador automático del
clúster.
kubectl get configmap -n kube-system cluster-autoscaler-status -o yaml
Para más información sobre lo que se registra del escalador automático, consulte las preguntas más frecuentes
sobre el proyecto de GitHub Kubernetes/autoscaler.
Uso del escalado automático de clústeres con varios grupos de nodos

habilitados
El escalado automático de clústeres también se puede usar con varios grupos de nodos habilitados. Siga este
documento para aprender a habilitar varios grupos de nodos y agregar grupos de nodos adicionales a un
clúster existente. Cuando se utilizan ambas características juntas, se activa el escalado automático de clústeres
en cada grupo de nodos individuales del clúster y se pueden pasar reglas de escalado automático únicas a cada
uno de ellos.
En el comando siguiente se supone que ha seguido las instrucciones iniciales anteriores de este documento y
desea actualizar el número máximo de grupos de nodos existentes de 3 a 5. Use el comando az aks nodepool
update para actualizar la configuración de un grupo de nodos existente.
--name nodepool1 \
--update-cluster-autoscaler \
--min-count 1 \
--max-count 5
El escalado automático de clústeres se puede deshabilitar con az aks nodepool update y al pasar el parámetro
--disable-cluster-autoscaler .

--name nodepool1 \
--disable-cluster-autoscaler
Si quiere volver a habilitar el escalado automático de clústeres en un clúster existente, puede volver a habilitarlo
mediante el comando az aks nodepool update, especificando los parámetros --enable-cluster-autoscaler ,
--min-count y --max-count .
NOTE
Si tiene previsto usar el escalador automático de clústeres con grupos de nodos que abarcan varias zonas y aprovechan
características de programación relacionadas con zonas como, por ejemplo, la programación topológica de volumen, se
recomienda tener un grupo de nodos por zona y habilitar --balance-similar-node-groups a través del perfil del
escalador automático. Esto garantizará que el escalador automático se escale verticalmente con éxito y mantenga
equilibrados los tamaños de los grupos de nodos.
Pasos siguientes
En este artículo le mostramos cómo escalar automáticamente el número de nodos de AKS. Asimismo, también
puede usar el escalado automático horizontal de pods para ajustar automáticamente el número de pods
ejecutan la aplicación. Para obtener instrucciones sobre cómo usar el escalado automático horizontal de pods,
consulte Escalado de aplicaciones en AKS.
Creación de un clúster de Azure Kubernetes Service
(AKS) que use zonas de disponibilidad
Un clúster de Azure Kubernetes Service (AKS) distribuye recursos como nodos y almacenamiento en secciones
lógicas de infraestructura subyacente de Azure. Este modelo de implementación con zonas de disponibilidad
garantiza que los nodos de una zona de disponibilidad determinada estén físicamente separados de los
definidos en otra zona de disponibilidad. Los clústeres de AKS implementados con varias zonas de
compatibilidad configuradas en un clúster proporcionan un alto nivel de disponibilidad para proteger frente a
errores de hardware o eventos de mantenimiento planeados.
Si se definen los grupos de nodos de un clúster de modo que abarquen varias zonas, los nodos de un grupo de
nodos determinado pueden seguir funcionando aunque una zona esté fuera de servicio. Las aplicaciones
pueden seguir estando disponibles aunque se produzca un error físico en un único centro de datos, siempre que
este esté orquestado para tolerar errores de un subconjunto de nodos.
En este artículo le mostraremos cómo crear un clúster de AKS y distribuir los componentes del nodo en las
zonas de disponibilidad.
Antes de empezar
Es preciso que esté instalada y configurada la versión 2.0.76 de la CLI de Azure, o cualquier otra posterior.
Azure.
Limitaciones y disponibilidad de región

Los clústeres de AKS se pueden crear actualmente mediante zonas de disponibilidad en las siguientes regiones:
Este de Australia
Sur de Brasil
Centro de Canadá
Centro de EE. UU.
Este de EE. UU.
Este de EE. UU. 2
Centro de Francia
Centro-oeste de Alemania
Japón Oriental
Norte de Europa
Sudeste de Asia
Centro-sur de EE. UU.
Sur de Reino Unido 2
US Gov - Virginia
Oeste de Europa
Oeste de EE. UU. 2
Las siguientes limitaciones se aplican cuando crea un clúster de AKS mediante zonas de disponibilidad:
Solo se pueden definir zonas de disponibilidad cuando se crea el clúster o grupo de nodos.
La configuración de la zona de disponibilidad no se puede actualizar después de crear el clúster. Tampoco
puede actualizar un clúster de zona sin disponibilidad para usar zonas de disponibilidad.
El tamaño de nodo (SKU de VM) seleccionado debe estar disponible en todas las zonas de disponibilidad
seleccionadas.
Los clústeres con zonas de disponibilidad habilitadas requieren el uso de equilibradores de carga estándar de
Azure para la distribución entre zonas. Este tipo de equilibrador de carga solo se puede definir en el
momento de la creación del clúster. Para obtener más información y las limitaciones del equilibrador de
carga estándar, consulte las limitaciones de la SKU estándar del equilibrador de carga de Azure.
Limitaciones de los discos de Azure
Los volúmenes que usan discos administrados de Azure actualmente no son recursos con redundancia de zona.
Los volúmenes no se pueden conectar entre zonas y deben estar ubicados en la misma zona que el nodo
concreto que hospeda al pod de destino.
Kubernetes tiene en cuenta las zonas de disponibilidad de Azure desde la versión 1.12. Puede implementar un
objeto PersistentVolumeClaim que haga referencia a un disco administrado de Azure en un clúster de AKS de
varias zonas y Kubernetes se encargará de programar cualquier pod que reclame este objeto PVC en la zona de
disponibilidad correcta.
Introducción a las zonas de disponibilidad para los clústeres de AKS

Las zonas de disponibilidad son una oferta de alta disponibilidad que protege las aplicaciones y datos de los
errores del centro de datos. Las zonas son ubicaciones físicas exclusivas dentro de una región de Azure. Cada
zona de disponibilidad consta de uno o varios centros de datos equipados con alimentación, refrigeración y
redes independientes. Para garantizar la resistencia, siempre hay más de una zona en todas las regiones
habilitadas para zonas. La separación física de las zonas de disponibilidad dentro de una región protege las
aplicaciones y los datos frente a los errores del centro de datos.
Para más información, consulte ¿Qué son las zonas de disponibilidad en Azure?
Los clústeres de AKS que se implementan mediante zonas de disponibilidad que pueden distribuir nodos en
varias zonas dentro de una sola región. Por ejemplo, un clúster en la región Este de EE. UU. 2puede crear nodos
en las tres zonas de disponibilidad del Este de EE. UU. 2. Esta distribución de los recursos del clúster de AKS
mejora la disponibilidad del clúster, ya que son resistentes a los errores de una zona específica.
Si una sola zona deja de estar disponible, las aplicaciones siguen ejecutándose siempre que el clúster esté
distribuido entre varias zonas.
Crear un clúster de AKS en zonas de disponibilidad

Cuando crea un clúster con el comando az aks create, el parámetro --zones define en qué zonas se
implementan los nodos de agente. Los componentes del plano de control, como etcd o la API, se reparten entre
las zonas disponibles en la región si define el parámetro --zones en el momento de la creación del clúster. Las
zonas específicas entre las que se han distribuido los componentes del plano de control son independientes de
las zonas explícitas que se han seleccionado para el grupo de nodos inicial.
Si no se define ninguna zona para el grupo de agentes predeterminado al crear un clúster de AKS, no se
garantiza que los componentes del plano de control se distribuyan entre zonas de disponibilidad. Puede agregar
grupos de nodos adicionales mediante el comando az aks nodepool add y especificar --zones para los nuevos
nodos, pero esto no cambia la forma en que se ha distribuido el plano de control entre zonas. La configuración
de zonas de disponibilidad solo se puede definir en el momento de la creación del clúster o el grupo de nodos.
En el ejemplo siguiente se crea un clúster de AKS denominado myAKSCluster en el grupo de recursos
denominado myResourceGroup. Se crean un total de 3 nodos: un agente en la zona 1, uno en la 2 y otro en la 3.
az group create --name myResourceGroup --location eastus2
az aks create \
--node-count 3 \
--zones 1 2 3
El clúster de AKS tarda unos minutos en crearse.

A la hora de decidir la zona a la que debe pertenecer un nodo nuevo, un grupo de nodos determinado de AKS
usa la mejor opción de equilibrio de zonas ofrecida por la instancia subyacente de Azure Virtual Machine Scale
Sets. Un grupo de nodos dado de AKS se considera "equilibrado" si cada zona tiene el mismo número de
máquinas virtuales o +- 1 máquina virtual en todas las demás zonas del conjunto de escalado.
Comprobar la distribución de nodos entre zonas

Cuando el clúster esté listo, enumere los nodos de agente en el conjunto de escalado para ver en qué zona de
disponibilidad se implementarán.
Primero, obtenga las credenciales del clúster de AKS mediante el comando az aks get-credentials:
A continuación, use el comando kubectl describe para enumerar los nodos del clúster y filtrar por el valor de
failure-domain.beta.kubernetes.io/zone. El ejemplo siguiente es para un shell de Bash.
kubectl describe nodes | grep -e "Name:" -e "failure-domain.beta.kubernetes.io/zone"
El siguiente resultado de ejemplo muestra los tres nodos distribuidos en la región especificada y las zonas de
disponibilidad, como eastus2-1 para la primera zona de disponibilidad y eastus2-2 para la segunda zona de
disponibilidad:
Name: aks-nodepool1-28993262-vmss000000
failure-domain.beta.kubernetes.io/zone=eastus2-1
A medida que agrega nodos adicionales a un grupo de agentes, la plataforma Azure distribuye
automáticamente las VM subyacentes en las zonas de disponibilidad especificadas.
Tenga en cuenta que en las versiones más recientes de Kubernetes (1.17.0 y versiones posteriores), AKS usa la
etiqueta topology.kubernetes.io/zone más reciente además de la failure-domain.beta.kubernetes.io/zone en
desuso. Puede obtener el mismo resultado que antes ejecutando el siguiente script:
kubectl get nodes -o custom-

columns=NAME:'{.metadata.name}',REGION:'{.metadata.labels.topology\.kubernetes\.io/region}',ZONE:'{metadata.
labels.topology\.kubernetes\.io/zone}'
Que le proporcionará una salida más concisa:
NAME REGION ZONE

aks-nodepool1-34917322-vmss000000 eastus eastus-1
Comprobar la distribución de pods entre zonas

Como se documenta en Etiquetas, anotaciones y taints ampliamente conocidas, Kubernetes usa la etiqueta
failure-domain.beta.kubernetes.io/zone para distribuir automáticamente los pods en un controlador o servicio
de replicación en las diferentes zonas disponibles. Para probarlo, puede escalar verticalmente el clúster de 3 a
5 nodos para comprobar la propagación correcta del pod:
az aks scale \
--node-count 5
Cuando la operación de escalado se complete después de unos minutos, el comando

kubectl describe nodes | grep -e "Name:" -e "failure-domain.beta.kubernetes.io/zone" de un shell de Bash debe
proporcionar una salida similar a la de este ejemplo:
Ahora hay dos nodos adicionales en las zonas 1 y 2. Puede implementar una aplicación que consta de tres
réplicas. Se va a usar NGINX como ejemplo:
kubectl create deployment nginx --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine

kubectl scale deployment nginx --replicas=3
Si se miran los nodos en los que se están ejecutando los pods, se observa que estos se ejecutan en los nodos
correspondientes a tres zonas de disponibilidad diferentes. Por ejemplo, con el comando
kubectl describe pod | grep -e "^Name:" -e "^Node:" de un shell de Bash se obtendría una salida similar a esta:
Name: nginx-6db489d4b7-ktdwg
Node: aks-nodepool1-28993262-vmss000000/10.240.0.4
Name: nginx-6db489d4b7-v7zvj
Name: nginx-6db489d4b7-xz6wj
Como puede ver en la salida anterior, el primer pod se ejecuta en el nodo 0, que se encuentra en la zona de
disponibilidad eastus2-1 . El segundo pod se ejecuta en el nodo 2, que corresponde a eastus2-3 , y el tercero,
en el nodo 4, en eastus2-2 . Sin necesidad de configuración adicional, Kubernetes extiende los pods
correctamente en las tres zonas de disponibilidad.
Pasos siguientes
En este artículo se detalla cómo crear un clúster de AKS que usa zonas de disponibilidad. Para obtener más
información sobre los clústeres de alta disponibilidad, consulte Best practices for business continuity and
disaster recovery in AKS (Procedimientos recomendados para la continuidad empresarial y recuperación ante
desastres en AKS).
Creación y administración de varios grupos de
nodos para un clúster de Azure Kubernetes Service
(AKS)
En Azure Kubernetes Service, los nodos de la misma configuración se agrupan en grupos de nodos. Estos
grupos de nodos contienen las máquinas virtuales subyacentes que ejecutan las aplicaciones. El número de
nodos y su tamaño (SKU) inicial se definen al crear un clúster de AKS, lo cual crea un grupo de nodos del
sistema. Para admitir aplicaciones con diferentes necesidades de proceso o almacenamiento, puede crear
grupos de nodos de usuario. Los grupos de nodos del sistema tienen el propósito principal de hospedar los
pods críticos del sistema, como CoreDNS y tunnelfront. Los grupos de nodos de usuario tienen el propósito
principal de hospedar los pods de aplicación. Sin embargo, se pueden programar pods de aplicación en grupos
de nodos del sistema si quiere tener solo un grupo en el clúster de AKS. En los grupos de nodos del usuario es
donde se colocan los pods específicos de la aplicación. Por ejemplo, puede usar estos grupos de nodos de
usuario adicionales para proporcionar GPU para aplicaciones de proceso intensivo o acceso a almacenamiento
SSD de alto rendimiento.
NOTE
Esta característica le permite obtener un mayor control sobre cómo crear y administrar varios grupos de nodos. Como
resultado, se requieren comandos separados para crear, actualizar y eliminar elementos. Anteriormente, las operaciones de
clúster a través de az aks create o az aks update usaban la API managedCluster y eran la única opción para
cambiar el plano de control y un grupo de nodo único. Esta característica expone un conjunto de operaciones
independiente para los grupos de agentes a través de la API agentPool y requiere el uso del conjunto de comandos
az aks nodepool para ejecutar operaciones en un grupo de nodos individual.
Este artículo le muestra cómo crear y administrar grupos de varios nodos en un clúster de AKS.
Antes de empezar
Es preciso que esté instalada y configurada la versión 2.2.0 de la CLI de Azure, o cualquier otra posterior. Ejecute
Limitaciones
Se aplican las siguientes limitaciones cuando crea y administra clústeres de AKS que admiten varios grupos de
nodos:
Consulte Cuotas, restricciones de tamaño de máquinas virtuales y disponibilidad de regiones en Azure
Puede eliminar grupos de nodos del sistema, siempre que disponga de otro grupo de nodos del sistema que
ocupe su lugar en el clúster de AKS.
Los grupos del sistema deben contener al menos un nodo mientras que los grupos de nodos del usuario
pueden contener varios nodos o ninguno.
El clúster de AKS debe usar el equilibrador de carga de SKU estándar para usar varios grupos de nodos; la
característica no es compatible con los equilibradores de carga de SKU básica.
El clúster de AKS debe usar conjuntos de escalado de máquinas virtuales para los nodos.
El nombre de un grupo de nodos solo puede contener caracteres alfanuméricos en minúsculas y debe
comenzar con una letra minúscula. En el caso de los grupos de nodos de Linux, la longitud debe estar
comprendida entre 1 y 12 caracteres. Para los grupos de nodos de Windows, la longitud debe estar
comprendida entre 1 y 6 caracteres.
Todos los grupos de nodos deben residir en la misma red virtual.
Al crear varios grupos de nodos durante la creación del clúster, todas las versiones de Kubernetes que se
usen en los grupos de nodos deben coincidir con la versión establecida para el plano de control. Se puede
actualizar después de aprovisionar el clúster mediante operaciones en función del grupo de nodos.

IMPORTANT
Si ejecuta un único grupo de nodos del sistema para el clúster de AKS en un entorno de producción, se recomienda usar
al menos tres nodos para el grupo de nodos.
Para empezar, cree un clúster de AKS con un grupo de nodo único. El ejemplo siguiente usa el comando az
group create para crear un grupo de recursos denominado myResourceGroup en la región eastus. Se crea un
clúster de AKS denominado myAKSCluster mediante el comando az aks create.
NOTE
No se admite la SKU Básico del equilibrador de carga cuando se usan varios grupos de nodos. De forma
predeterminada, los clústeres de AKS se crean con el SKU de equilibrador de carga Estándar de la CLI de Azure y Azure
Portal.
# Create a resource group in East US

# Create a basic single-node AKS cluster

az aks create \
--node-count 2 \
--load-balancer-sku standard
La operación de creación del clúster tarda unos minutos.
NOTE
Para asegurarse de que el clúster funciona de forma confiable, debe ejecutar al menos dos nodos en el grupo de nodos
predeterminado, ya que los servicios esenciales del sistema se ejecutan en este grupo de nodos.
Cuando el clúster esté listo, utilice el comando az aks get-credentials para obtener las credenciales del clúster
para su uso con kubectl :
Adición de un grupo de nodos

El clúster creado en el paso anterior tiene un grupo de nodo único. Vamos a agregar un segundo grupo de
nodos mediante el comando az aks node pool add. En el ejemplo siguiente se crea un grupo de nodos
denominado mynodepool que ejecuta 3 nodos:

--name mynodepool \
--node-count 3
NOTE
El nombre de un grupo de nodos debe empezar con una letra minúscula y solo puede contener caracteres alfanuméricos.
En el caso de los grupos de nodos de Linux, la longitud debe estar comprendida entre 1 y 12 caracteres. Para los grupos
de nodos de Windows, la longitud debe estar comprendida entre 1 y 6 caracteres.
Para ver el estado de los grupos de nodos, use el comando az aks node pool list y especifique el nombre del
clúster y del grupo de recursos:
az aks nodepool list --resource-group myResourceGroup --cluster-name myAKSCluster
En la siguiente salida de ejemplo se puede ver que mynodepool se ha creado correctamente con tres nodos en
el grupo de nodos. Cuando se creó el clúster de AKS en el paso anterior, también se creó un grupo de nodos
predeterminado denominado nodepool1 con 2 nodos.
[
{
...
"count": 3,
...
"name": "mynodepool",
"orchestratorVersion": "1.15.7",
...
...
},
{
...
"count": 2,
...
...
...
}
]
TIP
Si no se especifica VmSize al agregar un grupo de nodos, el tamaño predeterminado será Standard_D2s_v3 para los
grupos de nodos de Windows y Standard_DS2_v2 para los grupos de nodos de Linux. Si no se especifica
OrchestratorVersion, se establecerá de forma predeterminada en la misma versión que el plano de control.
Adición de un grupo de nodos con una subred única (versión preliminar)

Una carga de trabajo puede requerir la división de los nodos de un clúster en grupos independientes para el
aislamiento lógico. Este aislamiento se puede admitir con subredes independientes dedicadas a cada grupo de
nodos del clúster. Esto puede satisfacer requisitos tales como tener un espacio de direcciones de red virtual no
contiguo para dividirlo en grupos de nodos.
Limitaciones
Todas las subredes asignadas a grupos de nodos deben pertenecer a la misma red virtual.
Los pods del sistema deben tener acceso a todos los nodos o pods del clúster para proporcionar
funcionalidad crítica, como la resolución de DNS y la tunelización de logs/exec/port-forward proxy de
kubectl.
Si expande la red virtual después de crear el clúster, debe actualizarlo (es decir, debe realizar cualquier
operación de clúster administrado, aunque no cuentan las operaciones del grupo de nodos) antes de agregar
una subred fuera del CIDR original. AKS generará un error con la opción Agregar ahora en el grupo de
agentes aunque originalmente se hubiera permitido. Si no sabe cómo conciliar el clúster, abra una incidencia
de soporte técnico.
No se admite la directiva de red de Calico.
No se admite la directiva de red de Azure.
Kube-proxy espera un único CIDR contiguo y lo usa para tres optimizaciones. Consulte esta propuesta de
mejora de Kubernetes y -cluster-cidr aquí para obtener más información. En Azure CNI, la subred del primer
grupo de nodos se asignará a kube-proxy.
Para crear un grupo de nodos con una subred dedicada, pase el identificador de recurso de subred como
parámetro adicional al crear un grupo de nodos.

--name mynodepool \
--node-count 3 \
--vnet-subnet-id <YOUR_SUBNET_RESOURCE_ID>
Actualización de un grupo de nodos

NOTE
Las operaciones de actualización y escalado en un grupo de clústeres o nodos no se pueden realizar simultáneamente. Si
se intenta, se devuelve un error. En su lugar, cada tipo de operación debe completarse en el recurso de destino antes de la
siguiente solicitud en ese mismo recurso. Obtenga más información al respecto en nuestra guía de solución de problemas.
Los comandos de esta sección explican cómo actualizar un único grupo de nodos específico. La relación entre
actualizar la versión de Kubernetes del plano de control y el grupo de nodos se explica en la sección que tiene a
continuación.
NOTE
La versión de la imagen del sistema operativo del grupo de nodos está vinculada a la versión de Kubernetes del clúster.
Solo obtendrá actualizaciones de la imagen del sistema operativo cuando se haya realizado una actualización del clúster.
Como en este ejemplo hay dos grupos de nodos, debemos usar az aks nodepool upgrade para actualizar un
grupo de nodos. Para ver las actualizaciones disponibles, use az aks get-upgrades

Vamos a actualizar mynodepool. Use el comando az aks nodepool upgrade para actualizar el grupo de nodos tal
como se muestra en el ejemplo siguiente:

--name mynodepool \
--kubernetes-version KUBERNETES_VERSION \
--no-wait
Muestre el estado de los grupos de nodos de nuevo mediante el comando az aks node pool list. En el ejemplo
siguiente, se muestra que mynodepool se encuentra en el estado Actualizando a KUBERNETES_VERSION:
az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster
[
{
...
"count": 3,
...
"orchestratorVersion": "KUBERNETES_VERSION",
...
"provisioningState": "Upgrading",
...
...
},
{
...
"count": 2,
...
...
...
...
}
]
Tarda unos minutos en actualizar los nodos a la versión especificada.

Se recomienda que actualice todos los grupos de nodos de un clúster de AKS a la misma versión de Kubernetes.
El comportamiento predeterminado de az aks upgrade es actualizar todos los grupos de nodos junto con el
plano de control para lograr esta alineación. La posibilidad de actualizar grupos de nodos individuales le
permite realizar una actualización gradual y programar pods entre grupos de nodos para mantener el tiempo de
actividad de las aplicaciones dentro de las restricciones antes mencionadas.
Actualización del plano de control de un clúster con varios grupos de

nodos
NOTE
Kubernetes usa el esquema de versiones estándar de Versionamiento Semántico. El número de versión se expresa como
x.y.z, donde x es la versión principal, y es la versión secundaria y z es la versión de revisión. Por ejemplo, en la
versión 1.12.6, 1 es la versión principal, 12 es la versión secundaria y 6 es la versión de revisión. Las versiones de
Kubernetes del plano de control y del grupo de nodos inicial se establecen durante la creación del clúster. Todos los
grupos de nodos adicionales tienen establecida la versión de Kubernetes cuando se agregan al clúster. Las versiones de
Kubernetes pueden diferir entre los grupos de nodos, así como entre un grupo de nodos y el plano de control.
Un clúster de AKS tiene dos objetos de recursos de clúster con las versiones de Kubernetes asociadas.
1. Un plano de control del clúster con una versión de Kubernetes.
2. Un grupo de nodos con una versión de Kubernetes.
Un plano de control se asigna a uno o varios grupos de nodos. El comportamiento de una operación de
actualización depende del comando de la CLI de Azure que se use.
La actualización de un plano de control de AKS requiere el uso de az aks upgrade . Este comando actualiza la
versión del plano de control y todos los grupos de nodos del clúster.
Si se emite el comando az aks upgrade con la marca --control-plane-only , solo se actualiza el plano de control
del clúster. No se cambia ninguno de los grupos de nodos asociados del clúster.
La actualización de los grupos de nodos individuales requiere el uso de az aks nodepool upgrade . Este comando
actualiza solo el grupo de nodos de destino con la versión de Kubernetes especificada.
Reglas de validación para actualizaciones
Las actualizaciones válidas de Kubernetes del plano de control o de los grupos de nodos de un clúster se validan
mediante los siguientes conjuntos de reglas.
Reglas de versiones válidas para actualizar grupos de nodos:
La versión del grupo de nodos debe tener la misma versión principal que el plano de control.
La versión del grupo de nodos secundaria debe estar dentro de dos versiones secundarias de la
versión del plano de control.
La versión del grupo de nodos no puede ser mayor que la versión major.minor.patch de control.
Reglas para enviar una operación de actualización:
No se puede cambiar a la versión anterior de Kubernetes en el plano de control ni en el grupo de
nodos.
Si no se especifica una versión de Kubernetes del grupo de nodos, el comportamiento depende del
cliente que se use. La declaración en las plantillas de Resource Manager revierte a versión existente
definida para el grupo de nodos. Si no se establece ninguna, se usa la versión del plano de control
para la reversión.
Puede actualizar o escalar un plano de control o un grupo de nodos en un momento dado, pero no
puede enviar simultáneamente varias operaciones en un único recurso de plano de control o de grupo
de nodos.
Escalado manual de un grupo de nodos

A medida que la carga de trabajo de las aplicaciones cambia, puede que tenga que escalar el número de nodos
de un grupo de nodos. El número de nodos se puede escalar o reducir verticalmente.
Para escalar el número de nodos de un grupo de nodos, use el comando az aks node pool scale. En el ejemplo
siguiente se escala el número de nodos de mynodepool a 5:
az aks nodepool scale \
--name mynodepool \
--node-count 5 \
--no-wait
Muestre el estado de los grupos de nodos de nuevo mediante el comando az aks node pool list. El ejemplo
siguiente muestra que mynodepool está en el estado Escalando con un nuevo recuento de 5 nodos:
[
{
...
"count": 5,
...
...
"provisioningState": "Scaling",
...
...
},
{
...
"count": 2,
...
...
...
...
}
]
La operación de escalado tarda unos minutos en completarse.
Escalar un grupo de nodos específico automáticamente habilitando

para ello la escalabilidad automática del clúster
AKS ofrece una característica independiente para escalar automáticamente grupos de nodos con una
característica denominada cluster autocaler. Esta característica se puede habilitar en función del grupo de nodos
con recuentos de escala mínimos y máximos únicos por grupo de nodos. Aprenda a usar la escalabilidad
automática del clúster en función del grupo de nodos.
Eliminación de un grupo de nodos

Si ya no necesita un grupo, puede eliminarlo y quitar los nodos de máquinas virtuales subyacentes. Para
eliminar un grupo de nodos, use el comando az aks node pool delete y especifique el nombre del grupo de
nodos. El ejemplo siguiente elimina el grupo mynoodepool que se creó en los pasos anteriores:
Cau t i on
No hay ninguna opción de recuperación para la pérdida de datos que se puede producir cuando se elimina un
grupo de nodos. Si no se pueden programar pods en otros grupos de nodos, esas aplicaciones dejarán de estar
disponibles. Asegúrese de que no elimina un grupo de nodos si las aplicaciones en uso no disponen de copias
de seguridad de los datos o de la posibilidad de ejecutarse en otros grupos de nodos del clúster.
az aks nodepool delete -g myResourceGroup --cluster-name myAKSCluster --name mynodepool --no-wait
En la siguiente salida de ejemplo del comando az aks node pool list se puede ver que mynodepool se encuentra
en el estado Eliminando:
[
{
...
"count": 5,
...
...
"provisioningState": "Deleting",
...
...
},
{
...
"count": 2,
...
...
...
...
}
]
Tarda unos minutos en eliminar los nodos y el grupo de nodos.
Especificación de un tamaño de máquina virtual para un grupo de

nodos
En los ejemplos anteriores para crear un grupo de nodos, se usó un tamaño de máquina virtual predeterminado
para los nodos creados en el clúster. Un escenario habitual consiste en crear grupos de nodos con diferentes
tamaños y funcionalidades de máquina virtual. Por ejemplo, puede crear un grupo de nodos que contenga
nodos con grandes cantidades de memoria o CPU, o un grupo de nodos que proporcione compatibilidad con
GPU. En el paso siguiente, se usan taints y tolerations para indicar al programador de Kubernetes cómo limitar
el acceso a los pods que se pueden ejecutar en esos nodos.
En el ejemplo siguiente, cree un grupo de nodos basado en GPU que use el tamaño de máquina virtual
Standard_NC6. Estas máquinas virtuales disponen de una tarjeta Tesla K80 de NVIDIA. Para más información
sobre los tamaños de máquina virtual disponibles, consulte Tamaños de las máquinas virtuales Linux en Azure.
Cree un grupo de nodos mediante el comando az aks node pool add de nuevo. Esta vez, especifique el nombre
gpunodepool y use el parámetro --node-vm-size para especificar el tamaño Standard_NC6:
--name gpunodepool \
--node-count 1 \
--node-vm-size Standard_NC6 \
--no-wait
En la siguiente salida de ejemplo del comando az aks node pool list se puede ver que gpunodepool está
Creando nodos con el VmSize especificado:
[
{
...
"count": 1,
...
"name": "gpunodepool",
...
"provisioningState": "Creating",
...
"vmSize": "Standard_NC6",
...
},
{
...
"count": 2,
...
...
...
...
}
]
Tarda unos minutos en crear correctamente gpunodepool.
Especificación de un valor taint o una etiqueta para un grupo de

nodos
Al crear un grupo de nodos, puede agregar valores taint o etiquetas a ese grupo de nodos. Al agregar un valor
taint o una etiqueta, todos los nodos de ese grupo de nodos también obtienen ese valor taint o etiqueta.
IMPORTANT
Se deben agregar valores taint o etiquetas a los nodos para todo el grupo de nodos mediante az aks nodepool . No se
recomienda aplicar valores taint o etiquetas a nodos individuales de un grupo de nodos mediante kubectl .
Configuración de las intolerancias de un grupo de nodos

Para crear un grupo de nodos con un valor taint, use az aks nodepool add. Especifique el nombre taintnp y use
el parámetro --node-taints para especificar sku=gpu:NoSchedule para el valor taint.
--name taintnp \
--node-count 1 \
--node-taints sku=gpu:NoSchedule \
--no-wait
NOTE
Solo pueden crearse intolerancias para los grupos de nodos cuando estos se crean.
En la siguiente salida de ejemplo del comando az aks nodepool list se puede ver que taintnp está creando
(Creating) nodos con el valor nodeTaints especificado:
$ az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster
[
{
...
"count": 1,
...
"name": "taintnp",
...
...
"nodeTaints": [
"sku=gpu:NoSchedule"
],
...
},
...
]
La información del valor taint está visible en Kubernetes para controlar las reglas de programación de los nodos.
El programador de Kubernetes puede utilizar taints y tolerations para limitar las cargas de trabajo que se
pueden ejecutar en los nodos.
Un valor taint se aplica a un nodo que indica que solo se pueden programar pods específicos en él.
Luego se aplica un valor toleration a un pod que le permite tolerar el valor taint de un nodo.
Para más información sobre cómo usar las características avanzadas programadas de Kubernetes, consulte Best
practices for advanced scheduler features in AKS (Procedimientos recomendados para las características
avanzadas del programador en AKS).
En el paso anterior, aplicó el valor taint sku=gpu:NoSchedule cuando creó el grupo de nodos. El siguiente
manifiesto YAML básico de ejemplo usa un valor toleration para permitir al programador de Kubernetes ejecutar
un pod NGINX en un nodo de ese grupo de nodos.
Cree un archivo denominado nginx-toleration.yaml y cópielo en el ejemplo siguiente de YAML:
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- image: mcr.microsoft.com/oss/nginx/nginx:1.15.9-alpine
name: mypod
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 1
memory: 2G
tolerations:
- key: "sku"
operator: "Equal"
value: "gpu"
Programe el pod mediante el comando kubectl apply -f nginx-toleration.yaml :
kubectl apply -f nginx-toleration.yaml
Se tarda unos segundos en programar el pod y extraer la imagen NGINX. Use el comando kubectl describe pod
para ver el estado del pod. En la siguiente salida de ejemplo reducida se puede ver que se aplica el valor
sku=gpu:NoSchedule a toleration. En la sección de eventos, el programador ha asignado el pod al nodo aks-
taintnp-28993262-vmss000000:
kubectl describe pod mypod
[...]
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
sku=gpu:NoSchedule
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 4m48s default-scheduler Successfully assigned default/mypod to aks-taintnp-28993262-
vmss000000
Normal Pulling 4m47s kubelet pulling image "mcr.microsoft.com/oss/nginx/nginx:1.15.9-
alpine"
Normal Pulled 4m43s kubelet Successfully pulled image
"mcr.microsoft.com/oss/nginx/nginx:1.15.9-alpine"
Normal Created 4m40s kubelet Created container
Normal Started 4m40s kubelet Started container
Solo los pods a los que se ha aplicado este valor toleration se pueden programar en los nodos de taintnp.
Cualquier otro pod se tendría que programar en el grupo de nodos nodepool1. Si crea grupos de nodos
adicionales, puede usar valores taint y toleration adicionales para limitar los pods que se pueden programar en
esos recursos del nodo.
Configuración de etiquetas de grupos de nodos
También puede agregar etiquetas a un grupo de nodos durante la creación del mismo. Las etiquetas
establecidas en el grupo de nodos se agregan a cada nodo del grupo de nodos. Estas etiquetas están visibles en
Kubernetes para controlar las reglas de programación de los nodos.
Para crear un grupo de nodos con una etiqueta, use az aks nodepool add. Especifique el nombre labelnp y use el
parámetro --labels para especificar dept=IT y costcenter=9999 para las etiquetas.

--name labelnp \
--node-count 1 \
--labels dept=IT costcenter=9999 \
--no-wait
NOTE
La etiqueta solo se puede establecer para los grupos de nodos durante la creación de estos. Las etiquetas también deben
ser un par clave-valor y tener una sintaxis válida.
En la siguiente salida de ejemplo del comando az aks nodepool list se puede ver que labelnp está creando
(Creating) nodos con el valor nodeLabels especificado:
$ az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster
[
{
...
"count": 1,
...
"name": "labelnp",
...
...
"nodeLabels": {
"dept": "IT",
"costcenter": "9999"
},
...
},
...
]
Configuración de etiquetas de Azure para grupos de nodos

Puede aplicar una etiqueta de Azure a grupos de nodos en su clúster de AKS. Las etiquetas aplicadas a un grupo
de nodos se aplican a cada nodo del grupo y se conservan de una actualización a otra. También se aplican
etiquetas a los nuevos nodos que se agregan a un grupo durante las operaciones de escalado horizontal.
Agregar una etiqueta puede ayudar con tareas como el seguimiento de directivas o la estimación de costos.
Las etiquetas de Azure tienen claves que no distinguen mayúsculas y minúsculas en las operaciones; por
ejemplo, cuando se recupera una etiqueta buscando la clave. En este caso, una etiqueta con la clave especificada
se actualizará o recuperará independientemente del uso de mayúsculas y minúsculas. Los valores de etiqueta
distinguen mayúsculas de minúsculas.
En AKS, si varias etiquetas están configuradas con claves que son idénticas salvo por el uso de mayúsculas y
minúsculas, la etiqueta que se utilizará será la primera en orden alfabético. Por ejemplo, si se utiliza
{"Key1": "val1", "kEy1": "val2", "key1": "val3"} , se configurará Key1 y val1 .
Cree un grupo de nodos mediante el comando az aks nodepool add. Especifique el nombre tagnodepool y use
el parámetro --tag para especificar dept=IT y costcenter=9999 para las etiquetas.
--name tagnodepool \
--node-count 1 \
--tags dept=IT costcenter=9999 \
--no-wait
NOTE
También puede usar el parámetro --tags cuando use el comando az aks nodepool update, y también durante la
creación del clúster. Durante la creación del clúster, el parámetro --tags aplica la etiqueta al grupo de nodos inicial que
se crea con el clúster. Todos los nombres de etiqueta deben cumplir las limitaciones de Uso de etiquetas para organizar los
recursos de Azure. Al actualizar un grupo de nodos con el parámetro --tags , se actualizan los valores de etiqueta
existentes y se anexan las etiquetas nuevas. Por ejemplo, si el grupo de nodos tuviera dept=IT y costcenter=9999 en las
etiquetas y lo actualizara a team=dev y costcenter=111, el grupo de nodos tendría dept=IT, costcenter=111 y team=dev
como etiquetas.
En la siguiente salida de ejemplo del comando az aks nodepool list se puede ver que tagnodepool está creando
(Creating) nodos con el valor de tag especificado:
[
{
...
"count": 1,
...
"name": "tagnodepool",
...
...
"tags": {
"dept": "IT",
"costcenter": "9999"
},
...
},
...
]
Administración de grupos de nodos con una plantilla de Resource

Manager
Cuando usa una plantilla de Azure Resource Manager para crear y administrar recursos, normalmente puede
actualizar la configuración de la plantilla y volver a implementarla para actualizar el recurso. Con grupos de
nodos de AKS, el perfil del grupo de nodos inicial no se podrá actualizar una vez que se haya creado el clúster de
AKS. Este comportamiento significa que no se puede actualizar una plantilla de Resource Manager existente,
realizar un cambio en los grupos de nodos y volver a implementar. En su lugar, debe crear una plantilla de
Resource Manager independiente que actualice solo los grupos de nodos de un clúster de AKS existente.
Cree una plantilla como aks-agentpools.json y pegue el siguiente ejemplo de manifiesto. Esta plantilla de
ejemplo configura los valores siguientes:
Actualiza el grupo de nodos de Linux denominado myagentpool para que ejecute tres nodos.
Establece los nodos del grupo para ejecutar la versión de Kubernetes 1.15.7.
Define el tamaño del nodo como Standard_DS2_v2.
Edite estos valores para actualizar, agregar o eliminar grupos de nodos según sea necesario:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"clusterName": {
"type": "string",
"metadata": {
"description": "The name of your existing AKS cluster."
}
},
"location": {
"type": "string",
"metadata": {
"description": "The location of your existing AKS cluster."
}
},
"agentPoolName": {
"type": "string",
"defaultValue": "myagentpool",
"metadata": {
"description": "The name of the agent pool to create or update."
}
},
"vnetSubnetId": {
"type": "string",
"defaultValue": "",
"metadata": {
"description": "The Vnet subnet resource ID for your existing AKS cluster."
}
}
},
"variables": {
"apiVersion": {
"aks": "2020-01-01"
},
"agentPoolProfiles": {
"maxPods": 30,
"osDiskSizeGB": 0,
"agentCount": 3,
"agentVmSize": "Standard_DS2_v2",
"osType": "Linux",
"vnetSubnetId": "[parameters('vnetSubnetId')]"
}
},
"resources": [
{
"apiVersion": "2020-01-01",
"type": "Microsoft.ContainerService/managedClusters/agentPools",
"name": "[concat(parameters('clusterName'),'/', parameters('agentPoolName'))]",
"location": "[parameters('location')]",
"properties": {
"maxPods": "[variables('agentPoolProfiles').maxPods]",
"osDiskSizeGB": "[variables('agentPoolProfiles').osDiskSizeGB]",
"count": "[variables('agentPoolProfiles').agentCount]",
"vmSize": "[variables('agentPoolProfiles').agentVmSize]",
"osType": "[variables('agentPoolProfiles').osType]",
"type": "VirtualMachineScaleSets",
"vnetSubnetID": "[variables('agentPoolProfiles').vnetSubnetId]",
"orchestratorVersion": "1.15.7"
}
}
]
}
Implemente esta plantilla mediante el comando az deployment group create, tal como se muestra en el ejemplo
siguiente. Se le solicitará el nombre y la ubicación del clúster de AKS existente:
az deployment group create \

--template-file aks-agentpools.json
TIP
Para agregar una etiqueta al grupo de nodos, utilice la propiedad tag en la plantilla, tal y como se muestra en el ejemplo
siguiente.
...
"resources": [
{
...
"properties": {
...
"tags": {
"name1": "val1"
},
...
}
}
...
Puede que tarde unos minutos en actualizarse el clúster de AKS según la configuración del grupo de nodos y las
operaciones que defina en la plantilla de Resource Manager.
Asignación de una dirección IP pública por cada nodo para el grupo

de nodos
Los nodos de AKS no necesitan sus propias direcciones IP públicas para la comunicación. Sin embargo, los
escenarios pueden requerir que los nodos de un grupo de nodos reciban sus propias direcciones IP públicas
dedicadas. Un escenario común es para las cargas de trabajo de juegos, en las que se necesita una consola para
tener una conexión directa a una máquina virtual en la nube para minimizar los saltos. Este escenario se puede
conseguir en AKS mediante el uso de la dirección IP pública del nodo.
En primer lugar, cree un nuevo grupo de recursos.
az group create --name myResourceGroup2 --location eastus
Cree un clúster de AKS y conecte una dirección IP pública para los nodos. Cada uno de los nodos del grupo de
nodos recibe una dirección IP pública única. Puede comprobarlo si examina las instancias del conjunto de
escalado de máquinas virtuales.
az aks create -g MyResourceGroup2 -n MyManagedCluster -l eastus --enable-node-public-ip
En el caso de los clústeres de AKS que ya existan, también puede agregar un nuevo grupo de nodos y asociar
una dirección IP pública para los nodos.
az aks nodepool add -g MyResourceGroup2 --cluster-name MyManagedCluster -n nodepool2 --enable-node-public-ip
Uso de un prefijo de dirección IP pública

Existen varias ventajas al usar un prefijo de dirección IP pública. AKS admite el uso de direcciones de un prefijo
de dirección IP pública existente para los nodos pasando el identificador de recurso con la marca
node-public-ip-prefix al crear un nuevo clúster o agregar un grupo de nodos.
En primer lugar, cree un prefijo de dirección IP pública mediante az network public-ip prefix create:
az network public-ip prefix create --length 28 --location eastus --name MyPublicIPPrefix --resource-group
MyResourceGroup3
Vea la salida y tome nota de id para el prefijo:
{
...
"id": "/subscriptions/<subscription-
id>/resourceGroups/myResourceGroup3/providers/Microsoft.Network/publicIPPrefixes/MyPublicIPPrefix",
...
}
Por último, al crear un nuevo clúster o al agregar un nuevo grupo de nodos, use la marca
node-public-ip-prefix y pase el identificador de recurso del prefijo:
az aks create -g MyResourceGroup3 -n MyManagedCluster -l eastus --enable-node-public-ip --node-public-ip-

prefix /subscriptions/<subscription-
id>/resourcegroups/MyResourceGroup3/providers/Microsoft.Network/publicIPPrefixes/MyPublicIPPrefix
Búsqueda de direcciones IP públicas para nodos

Puede buscar las direcciones IP públicas de los nodos de varias maneras:
Use el comando az vmss list-instance-public-ips de la CLI de Azure.
Use comandos de PowerShell o Bash.
También puede ver las direcciones IP públicas en Azure Portal visualizando las instancias del conjunto de
IMPORTANT
El grupo de recursos de nodo contiene los nodos y sus direcciones IP públicas. Use el grupo de recursos de nodo al
ejecutar comandos para buscar las direcciones IP públicas de los nodos.
az vmss list-instance-public-ips -g MC_MyResourceGroup2_MyManagedCluster_eastus -n

YourVirtualMachineScaleSetName
En este artículo, ha creado un clúster de AKS que incluye nodos basados en GPU. Para reducir costos
innecesarios, puede que desee eliminar gpunodepool o todo el clúster de AKS.
Para eliminar el grupo de nodos basado en GPU, use el comando az aks nodepool delete tal como se muestra en
el ejemplo siguiente:
az aks nodepool delete -g myResourceGroup --cluster-name myAKSCluster --name gpunodepool
Para eliminar el clúster propiamente dicho, use el comando az group delete para eliminar el grupo de recursos
de AKS:
También puede eliminar el clúster adicional que creó para el escenario de IP pública de los grupos de nodos.
az group delete --name myResourceGroup2 --yes --no-wait
Pasos siguientes
Más información sobre los grupos de nodos del sistema.
En este artículo ha aprendido a crear y administrar grupos de varios nodos en un clúster de AKS. Para más
información sobre cómo controlar pods en grupos de nodos, consulte Best practices for advanced scheduler
features in AKS (Procedimientos recomendados para las características avanzadas del programador en AKS).
Para crear y usar grupos de nodos de contenedores de Windows Server, consulte Creación de un contenedor de
Windows Server en AKS.
Use grupos con ubicación por proximidad para disminuir la latencia de las aplicaciones de AKS.
Incorporación de un grupo de nodos de Spot a un
clúster de Azure Kubernetes Service (AKS)
Un grupo de nodos de Spot está respaldado por un conjunto de escalado de máquinas virtuales de Spot. El uso
de máquinas virtuales de Spot para los nodos con el clúster de AKS permite aprovechar la capacidad no
utilizada en Azure con un importante ahorro en los costos. La capacidad disponible no utilizada variará en
función de muchos factores, incluidos el tamaño del nodo, la región y la hora del día.
Al implementar un grupo de nodos de Spot, Azure asigna los nodos de Spot si hay capacidad disponible. Sin
embargo, no hay ningún Acuerdo de Nivel de Servicio para los nodos de Spot. Un conjunto de escalado de Spot
que respalda un grupo de nodos de Spot se implementa en un dominio de error único y no ofrece garantías de
alta disponibilidad. Siempre que Azure necesite recuperar la capacidad, su infraestructura expulsará los nodos
de Spot.
Los nodos de Spot son ideales para cargas de trabajo que controlen las interrupciones, las finalizaciones
tempranas o las expulsiones. Por ejemplo, los trabajos de procesamiento por lotes, los entornos de desarrollo y
pruebas, y las cargas de trabajo de proceso grandes pueden ser buenos candidatos para la programación en un
grupo de nodos de Spot.
En este artículo se agrega un grupo de nodos de Spot secundarios a un clúster de Azure Kubernetes Service
(AKS) existente.
Se presupone que tiene un conocimiento básico de los conceptos de Kubernetes y Azure Load Balancer. Para
más información, consulte Conceptos básicos de Kubernetes de Azure Kubernetes Service (AKS).
Antes de empezar
Al crear un clúster para que use un grupo de nodos de Spot, este también debe usar Virtual Machine Scale Sets
para los grupos de nodos y el equilibrador de carga de la SKU estándar. También debe agregar un grupo de
nodos adicional después de crear el clúster para que pueda usar el grupo de nodos de Spot. La incorporación de
un grupo de nodos adicional se trata en un paso posterior.
Para este artículo es preciso usar la versión 2.14 o posterior de la CLI de Azure. Ejecute az --version para
Limitaciones
Al crear y administrar clústeres de AKS con un grupo de nodos de Spot se aplican las limitaciones siguientes:
Un grupo de nodos de Spot no puede ser el predeterminado del clúster. Un grupo de nodos de Spot solo se
puede usar como secundario.
Los grupos de nodos de Spot no se pueden actualizar, ya que no pueden garantizar el acordonamiento y la
purga. Debe reemplazar el grupo de nodos de Spot existente por uno nuevo para las operaciones como la
actualización de la versión de Kubernetes. Para reemplazar un grupo de nodos de Spot, cree uno nuevo con
una versión diferente de Kubernetes, espere hasta que su estado sea Listo y elimine el anterior.
No se pueden actualizar los grupos de nodos y el plano de control al mismo tiempo. Debe actualizarlos por
separado o quitar el grupo de nodos de Spot para actualizar el plano de control y los grupos de nodos
restantes al mismo tiempo.
Los grupos de nodos de Spot deben usar Virtual Machine Scale Sets.
Una vez creados ScaleSetPriority y SpotMaxPrice no se pueden modificar.
Al establecer SpotMaxPrice, el valor debe ser -1 o un valor positivo con hasta cinco decimales.
Un grupo de nodos de Spot tendrá la etiqueta kubernetes.azure.com/scalesetpriority:spot y un valor taint
kubernetes.azure.com/scalesetpriority=spot:NoSchedule, y los pods del sistema, antiafinidad.
Para programar cargas de trabajo en un grupo de nodos de Spot, debe agregar el valor toleration
correspondiente.
Incorporación de un grupo de nodos de Spot a un clúster de AKS

Debe agregar un grupo de nodos de Spot a un clúster existente que tenga habilitados varios grupos de nodos.
Aquí encontrará más información sobre cómo crear un clúster de AKS con varios grupos de nodos.
Cree un grupo de nodos mediante el comando az aks nodepool add.

--name spotnodepool \
--priority Spot \
--eviction-policy Delete \
--spot-max-price -1 \
--min-count 1 \
--max-count 3 \
--no-wait
De forma predeterminada, al crear un clúster con varios grupos de nodos, se crea un grupo de nodos con
priority Regular en el clúster de AKS. El comando anterior agrega un grupo de nodos auxiliar a un clúster de AKS
existente con priority Spot. priority Spot hace que el grupo de nodos sea un grupo de nodos de Spot. El
parámetro eviction-policy está establecido en Delete en el ejemplo anterior, que es el valor predeterminado. Al
establecer eviction-policy en Delete, los nodos del grupo de escalado subyacente del grupo de nodos se
eliminan al ser expulsados. También puede establecer eviction-policy en Deallocate. Al establecer eviction-policy
en Deallocate, los nodos del conjunto de escalado subyacente se establecen en estado stopped-deallocated
durante la expulsión. Los nodos en estado stopped-deallocated se consideran también a efectos de la cuota de
proceso, lo cual puede generar problemas de escalado o actualización del clúster. Los valores de priority y
eviction-policy solo se pueden establecer durante la creación del grupo de nodos. Estos valores no se pueden
actualizar más adelante.
El comando también habilita el escalador automático de clúster, recomendado para los grupos de nodos de
Spot. En función de las cargas de trabajo que se ejecuten en el clúster, el escalador automático de clúster escala y
reduce verticalmente el número de nodos del grupo. En el caso de los grupos de nodos de Spot, el escalador
automático de clúster escala verticalmente el número de nodos después de una expulsión si aún se necesitan
nodos adicionales. Si cambia el máximo de nodos que puede tener un grupo, también debe ajustar el valor de
maxCount relativo al escalador automático de clúster. Si no usa un escalador automático de clúster, en la
expulsión el grupo de Spot disminuirá a cero y requerirá una operación manual para recibir nodos de Spot
adicionales.
IMPORTANT
Programe solo las cargas de trabajo en grupos de nodos de Spot que puedan controlar las interrupciones, como los
trabajos de procesamiento por lotes y los entornos de prueba. Se recomienda que configure los valores de taint y
toleration en el grupo de nodos de Spot para asegurarse de que en un grupo de nodos de Spot solo estén programadas
las cargas de trabajo que pueden controlar las expulsiones de nodos. Por ejemplo, el comando anterior agrega de forma
predeterminada un valor taint de kubernetes.azure.com/scalesetpriority=spot:NoSchedule para que solo se programen los
pods con el valor toleration correspondiente en este nodo.
Comprobación del grupo de nodos de Spot

Para comprobar que el grupo de nodos se ha agregado como grupo de nodos de Spot:
az aks nodepool show --resource-group myResourceGroup --cluster-name myAKSCluster --name spotnodepool
Confirme que scaleSetPriority sea Spot.

Para programar que un pod se ejecute en un nodo de zona de Spot, agregue un valor toleration que
corresponda al valor taint que se aplica al nodo de Spot. En el ejemplo siguiente se muestra una parte de un
archivo YAML que define un valor toleration que corresponde a un valor taint
kubernetes.azure.com/scalesetpriority=spot:NoSchedule que se usa en el paso anterior.
spec:
containers:
- name: spot-example
tolerations:
- key: "kubernetes.azure.com/scalesetpriority"
operator: "Equal"
value: "spot"
...
Al implementar un pod con este valor toleration, Kubernetes programa el pod correctamente en los nodos
donde se ha aplicado el valor taint.
Precio máximo de un grupo de Spot

Los precios de las instancias de Spot varían en función de la región y la SKU. Para más información, consulte los
precios para Linux y Windows.
La variabilidad en los precios permite establecer un precio máximo, en dólares estadounidenses (USD), con un
máximo de 5 decimales. Por ejemplo, el valor 0.98765 correspondería a un precio máximo de 0,98765 USD por
hora. Si establece el precio máximo en -1, la instancia no se expulsará según el precio. El precio de la instancia
será el actual de Spot o el de una instancia estándar, el menor de los dos, siempre que haya capacidad y cuota
disponibles.
Pasos siguientes
En este artículo ha aprendido a agregar un grupo de nodos de Spot a un clúster de AKS. Para más información
sobre cómo controlar pods en grupos de nodos, consulte Best practices for advanced scheduler features in AKS
(Procedimientos recomendados para las características avanzadas del programador en AKS).
Administración de grupos de nodos del sistema en
En Azure Kubernetes Service, los nodos de la misma configuración se agrupan en grupos de nodos. Los grupos
de nodos contienen las máquinas virtuales subyacentes que ejecutan las aplicaciones. Los grupos de nodos del
sistema y los grupos de nodos del usuario son dos modos de grupos de nodos diferentes para los clústeres de
AKS. Los grupos de nodos del sistema tienen el propósito principal de hospedar los pods críticos del sistema,
como CoreDNS y metrics-server . Los grupos de nodos de usuario tienen el propósito principal de hospedar los
pods de aplicación. Sin embargo, se pueden programar pods de aplicación en grupos de nodos del sistema si
quiere tener solo un grupo en el clúster de AKS. Cada clúster de AKS debe contener al menos un grupo de
nodos del sistema con al menos un nodo.
IMPORTANT
Si ejecuta un único grupo de nodos del sistema para el clúster de AKS en un entorno de producción, se recomienda usar
al menos tres nodos para el grupo de nodos.
Antes de empezar
Ejecute az --version para encontrar la versión. Si necesita instalarla o actualizarla, vea Instalación de la CLI
de Azure.
Limitaciones
Se aplican las siguientes limitaciones cuando crea y administra clústeres de AKS que admiten grupos de nodos
del sistema.
Consulte Cuotas, restricciones de tamaño de máquinas virtuales y disponibilidad de regiones en Azure
El clúster de AKS debe compilarse con conjuntos de escalado de máquinas virtuales como tipo de máquina
virtual y el equilibrador de carga de SKU estándar.
El nombre de un grupo de nodos solo puede contener caracteres alfanuméricos en minúsculas y debe
comenzar con una letra minúscula. En el caso de los grupos de nodos de Linux, la longitud debe estar
comprendida entre 1 y 12 caracteres. En el caso de los grupos de nodos de Windows, la longitud debe estar
comprendida entre 1 y 6 caracteres.
Se debe usar una versión de API de 2020-03-01 o superior para establecer un modo de grupo de nodos. Los
clústeres creados con versiones de API anteriores a la 2020-03-01 solo contienen grupos de nodos de
usuario, pero se pueden migrar para que contengan grupos de nodos del sistema si sigue las instrucciones
del actualización del modo de grupo.
El modo de un grupo de nodos es una propiedad obligatoria y se debe establecer explícitamente cuando se
usan plantillas de Resource Manager o llamadas API directas.
Grupos de nodos del sistema y del usuario

Para un grupo de nodos del sistema, AKS asigna automáticamente la etiqueta kubernetes.azure.com/mode:
system a sus nodos. Esto hace que AKS prefiera programar pods del sistema en grupos de nodos que
contengan esta etiqueta. Esta etiqueta no impide que se programen pods de aplicación en grupos de nodos del
sistema. Sin embargo, se recomienda aislar los pods del sistema críticos de los pods de aplicación para evitar
que los pods de aplicación mal configurados o no autorizados eliminen accidentalmente los pods del sistema.
Puede aplicar este comportamiento mediante la creación de un grupo de nodos del sistema dedicado. Use el
valor de taint CriticalAddonsOnly=true:NoSchedule para evitar que los pods de aplicación se programen en
grupos de nodos del sistema.
Los grupos de nodos del sistema tienen las siguientes restricciones:
El valor de osType para los grupos del sistema debe ser Linux.
En el caso de los grupos de nodos del usuario puede ser Linux o Windows.
Los grupos del sistema deben contener al menos un nodo mientras que los grupos de nodos del usuario
pueden contener varios nodos o ninguno.
Los grupos de nodos del sistema requieren una SKU de máquina virtual de 2 vCPUs y 4 GB de memoria
como mínimo. Sin embargo, no se recomienda una máquina virtual ampliable de la serie B.
Se recomienda un mínimo de dos nodos y 4 vCPU (por ejemplo, Standard_DS4_v2), especialmente para
clústeres de gran tamaño (varias réplicas de pod de CoreDNS, 3-4 + complementos, etc.).
Los grupos de nodos del sistema deben admitir al menos 30 pods como se indica en la fórmula del valor
mínimo y máximo de los pods.
Los grupos de nodos de zona requieren grupos de nodos del usuario.
La adición de un grupo de nodos del sistema adicional o el cambio del grupo de nodos que es un grupo de
nodos del sistema NO moverá automáticamente los pods del sistema. Los pods del sistema pueden
continuar ejecutándose en el mismo grupo de nodos, incluso si se cambia a un grupo de nodos de usuario. Si
elimina o reduce verticalmente un grupo de nodos que ejecuta pods del sistema que anteriormente era un
grupo de nodos del sistema, esos pods del sistema se implementan de nuevo con la programación preferida
en el nuevo grupo de nodos del sistema.
Puede hacer las siguientes operaciones con los grupos de nodos:
Crear un grupo de nodos del sistema dedicado (se prefiere la programación de pods del sistema a grupos de
nodos de mode:system ).
Cambiar un grupo de nodos del sistema para que sea un grupo de nodos del usuario, siempre que disponga
de otro grupo de nodos del sistema que ocupe su lugar en el clúster de AKS.
Cambiar un grupo de nodos del usuario para que sea un grupo de nodos del sistema.
Eliminar grupos de nodos del usuario.
Puede eliminar grupos de nodos del sistema, siempre que disponga de otro grupo de nodos del sistema que
ocupe su lugar en el clúster de AKS.
Un clúster de AKS puede incluir varios grupos de nodos del sistema y requiere uno como mínimo.
Si quiere cambiar varias opciones de configuración inmutables en los grupos de nodos existentes, puede
crear nuevos grupos de nodos para reemplazarlas. Por ejemplo, puede agregar un nuevo grupo de nodos
con una nueva opción de configuración maxPods y eliminar el grupo de nodos anterior.
Creación de un nuevo clúster de AKS con un grupo de nodos del

sistema
Cuando crea un nuevo clúster de AKS, crea automáticamente un grupo de nodos del sistema con un único nodo.
De forma predeterminada, el grupo de nodos inicial es del tipo sistema. Cuando crea nuevos grupos de nodos
con az aks nodepool add , estos serán grupos de nodos del usuario a menos que especifique explícitamente lo
contrario en el parámetro de modo.
En el ejemplo siguiente, se crea un grupo de recursos denominado myResourceGroup en la región eastus.
denominado myAKSCluster con un grupo del sistema dedicado que contiene un nodo. Para las cargas de trabajo
de producción, asegúrese de que usa grupos de nodos del sistema con al menos tres nodos. Esta operación
puede tardar varios minutos en completarse.
# Create a new AKS cluster with a single system pool

az aks create -g myResourceGroup --name myAKSCluster --node-count 1 --generate-ssh-keys
Incorporación de un grupo de nodos del sistema dedicado a un

clúster de AKS existente
IMPORTANT
No se pueden cambiar los valores de taint del nodo a través de la CLI una vez creado el grupo de nodos.
Puede agregar uno o varios grupos de nodos del sistema a los clústeres de AKS existentes. Se recomienda
programar los pods de aplicación en grupos de nodos de usuario y dedicar grupos de nodos del sistema a los
pods del sistema imprescindibles. Esto evita que los pods de aplicaciones no autorizadas eliminen por accidente
los pods del sistema. Aplique este comportamiento con el taint CriticalAddonsOnly=true:NoSchedule de los
grupos de nodos del sistema.
El siguiente comando le permite agregar un grupo de nodos del tipo sistema dedicado con un número
predeterminado de tres nodos.

--name systempool \
--node-count 3 \
--node-taints CriticalAddonsOnly=true:NoSchedule \
--mode System
Visualización de detalles del grupo de nodos

Puede comprobar los detalles del grupo de nodos con el siguiente comando.
az aks nodepool show -g myResourceGroup --cluster-name myAKSCluster -n systempool
Un modo del tipo sistema se define para los grupos de nodos del sistema y uno del tipo usuario para los del
usuario. En el caso de un grupo de sistemas, compruebe que el sistema está establecido en
CriticalAddonsOnly=true:NoSchedule , lo que impedirá que los pods de aplicación estén programados en este
grupo de nodos.
{
"agentPoolType": "VirtualMachineScaleSets",
"availabilityZones": null,
"count": 1,
"enableAutoScaling": null,
"enableNodePublicIp": false,
"id":
"/subscriptions/yourSubscriptionId/resourcegroups/myResourceGroup/providers/Microsoft.ContainerService/manag
edClusters/myAKSCluster/agentPools/systempool",
"maxCount": null,
"maxPods": 110,
"minCount": null,
"mode": "System",
"name": "systempool",
"nodeImageVersion": "AKSUbuntu-1604-2020.06.30",
"nodeLabels": {},
"nodeTaints": [
"CriticalAddonsOnly=true:NoSchedule"
],
"osDiskSizeGb": 128,
"osType": "Linux",
"provisioningState": "Failed",
"proximityPlacementGroupId": null,
"scaleSetEvictionPolicy": null,
"scaleSetPriority": null,
"spotMaxPrice": null,
"tags": null,
"type": "Microsoft.ContainerService/managedClusters/agentPools",
"upgradeSettings": {
"maxSurge": null
},
}
Actualización de los grupos de nodos de usuario y del sistema en

clústeres existentes
NOTE
Se debe usar la versión de API 2020-03-01 o posterior para configurar el modo de grupo de nodos del sistema. Como
resultado, los clústeres creados en versiones de API anteriores a la 2020-03-01 solo contienen grupos de nodos de
usuario. Para obtener la funcionalidad y las ventajas del grupo de nodos del sistema en clústeres anteriores, actualice el
modo de los grupos de nodos existentes con los siguientes comandos en la última versión de la CLI de Azure.
Puede cambiar los modos para los grupos de nodos del sistema y del usuario. Solo puede cambiar un grupo de
nodos del sistema para que sea uno del usuario si ya existe otro grupo de nodos del sistema en el clúster de
AKS.
Este comando cambia un grupo de nodos del sistema en un grupo de nodos del usuario.
az aks nodepool update -g myResourceGroup --cluster-name myAKSCluster -n mynodepool --mode user
Este comando cambia un grupo de nodos del usuario en un grupo de nodos del sistema.
az aks nodepool update -g myResourceGroup --cluster-name myAKSCluster -n mynodepool --mode system

Eliminación de un grupo de nodos del sistema
NOTE
Para usar grupos de nodos del sistema en clústeres de AKS con una versión de API anterior a 2020-03-02, agregue un
nuevo grupo de nodos del sistema y, a continuación, elimine el grupo de nodos predeterminado original.
Debe contar con al menos dos grupos de nodos del sistema en el clúster de AKS antes de poder eliminar uno de
ellos.
az aks nodepool delete -g myResourceGroup --cluster-name myAKSCluster -n mynodepool
Para eliminar el clúster, use el comando az group delete para eliminar el grupo de recursos de AKS:
Pasos siguientes
En este artículo ha aprendido a crear y administrar grupos de nodos del sistema en un clúster de AKS. Para más
información acerca de cómo usar varios grupos de nodos, consulte Uso de grupos de varios nodos.
Acceso a recursos de Kubernetes en Azure Portal
Azure Portal incluye un visor de recursos de Kubernetes para facilitar el acceso a los recursos de Kubernetes en
el clúster de Azure Kubernetes Service (AKS). Ver los recursos de Kubernetes en Azure Portal reduce la
necesidad de cambiar de contexto entre el Azure Portal y la herramienta de línea de comandos kubectl . De este
modo, se simplifican la visualización y edición de recursos de Kubernetes. El visor de recursos actualmente
incluye varios tipos de recursos, como implementaciones, pods y conjuntos de réplicas.
La vista de recursos de Kubernetes en Azure Portal reemplaza al complemento del panel de AKS, que ha
quedado en desuso.
Prerrequisitos
Para visualizar los recursos de Kubernetes en Azure Portal, necesita un clúster de AKS. Cualquier clúster puede
valer, pero si se utiliza la integración de Azure Active Directory (Azure AD), el clúster tiene que utilizar la
integración de Azure AD administrado por AKS. Si su clúster utiliza la integración de Azure AD heredada, puede
actualizarlo en el portal o mediante la CLI de Azure. También puede usar Azure Portal para crear un nuevo
clúster de AKS.
Visualización de recursos de Kubernetes

Para ver los recursos de Kubernetes, acceda al clúster de AKS en Azure Portal. El panel de navegación de la
izquierda se usa para acceder a los recursos. Los recursos incluyen:
Espacios de nombres muestra los espacios de nombres del clúster. El filtro situado en la parte superior de
la lista de espacios de nombres permite filtrar y visualizar de forma rápida los recursos del espacio de
nombres.
Cargas de trabajo muestra información sobre implementaciones, pods, conjuntos de réplicas, objetos
StatefulSet, conjuntos de demonios, trabajos y trabajos cron que se han implementado en el clúster. La
siguiente captura de pantalla muestra los pods del sistema predeterminados en un clúster de AKS de
ejemplo.
Ser vicios y entradas muestra todos los recursos de entrada y servicio del clúster.
Almacenamiento muestra las clases de almacenamiento de Azure y la información del volumen
persistente.
Configuración muestra los secretos y objetos ConfigMap del clúster.
Implementar una aplicación
En este ejemplo, usaremos el clúster de AKS de ejemplo para implementar la aplicación Azure Vote desde el
inicio rápido de AKS.
1. Seleccione Agregar desde cualquiera de las vistas de recursos (espacio de nombres, cargas de trabajo,
servicios y entradas, almacenamiento o configuración).
2. Pegue el archivo YAML de la aplicación Azure Vote desde el inicio rápido de AKS.
3. Seleccione Agregar en la parte inferior del editor YAML para implementar la aplicación.
Una vez que se añade el archivo YAML, el visor de recursos muestra los dos servicios de Kubernetes creados: el
servicio interno (azure-vote-back) y el servicio externo (azure-vote-front) para acceder a la aplicación Azure
Vote. El servicio externo incluye una dirección IP externa vinculada para que pueda ver fácilmente la aplicación
en el explorador.
Supervisión de la información de implementación

Los clústeres de AKS que tengan activado Azure Monitor para contenedores pueden ver rápidamente la
implementación y otra información. En la vista de recursos de Kubernetes, los usuarios pueden ver el estado
activo de implementaciones individuales, incluido el uso de la CPU y de la memoria, además de cambiar a Azure
Monitor para ver información más detallada sobre contenedores y nodos específicos. A continuación, se incluye
un ejemplo de información de implementación de un clúster de AKS de ejemplo:
Edición de YAML
La vista de recursos de Kubernetes también incluye un editor YAML. Tener un editor YAML integrado significa
que puede actualizar o crear servicios e implementaciones desde el portal y aplicar los cambios
inmediatamente.
Después de editar el archivo YAML, los cambios se aplicarán al seleccionar revisar + guardar , confirmarlos y, a
continuación, volver a guardar.
WARNING
No se recomienda hacer cambios de producción directamente a través de la interfaz de usuario o la CLI. Siga los
procedimientos recomendados de integración continua (CI) y de implementación continua (CD). La funcionalidad de
administración de Kubernetes en Azure Portal y el editor YAML se han creado para aprender sobre nuevas
implementaciones y lanzarlas en una configuración de desarrollo y pruebas.
En esta sección se abordan problemas comunes y los pasos para solucionarlos.
Acceso no autorizado
Para acceder a recursos de Kubernetes, debe tener acceso al clúster, la API y los objetos de Kubernetes. El usuario
debe ser administrador de clústeres o tener los permisos adecuados para acceder al clúster de AKS. Para
obtener más información sobre la seguridad de clúster, consulte Opciones de acceso e identidad en Azure
NOTE
La vista de recursos de Kubernetes en Azure Portal solo se admite en clústeres habilitados administrados con AAD o en
clústeres habilitados no administrados con AAD. Si usa un clúster habilitado administrado con AAD, el usuario o la
identidad de AAD debe tener los roles o enlaces de rol correspondientes para tener acceso a la API de Kubernetes,
además de los permisos para extraer el usuario kubeconfig .
Activación de la vista de recursos

En el caso de clústeres existentes, es posible que tenga que activar la vista de recursos de Kubernetes. Para
activar la vista de recursos, siga las indicaciones del portal para el clúster.
TIP
La característica de inter valos de IP autorizados del ser vidor de API de AKS se puede agregar para limitar el acceso
del servidor de API solo al punto de conexión público del firewall. Otra opción para estos clústeres es actualizar
--api-server-authorized-ip-ranges para incluir el acceso de un equipo cliente local o un intervalo de direcciones IP
(desde la que se examina el portal). Para permitir este acceso, necesita la dirección IPv4 pública del equipo. Para encontrar
esta dirección, use el siguiente comando o busque "cuál es mi dirección IP" en un explorador de Internet.
# Retrieve your IP address

CURRENT_IP=$(dig @resolver1.opendns.com ANY myip.opendns.com +short)
# Add to AKS approved list

az aks update -g $RG -n $AKSNAME --api-server-authorized-ip-ranges $CURRENT_IP/32
Pasos siguientes
En este artículo se ha mostrado cómo acceder a recursos de Kubernetes para el clúster de AKS. Consulte
Implementaciones y manifiestos YAML para familiarizarse con los recursos de clúster y los archivos YAML a los
que accede mediante el visor de recursos de Kubernetes.
Acceso al panel web de Kubernetes en Azure
Kubernetes incluye un panel web que se puede usar para operaciones básicas de administración. Este panel le
permite ver el estado de mantenimiento básico y las métricas para sus aplicaciones, crear e implementar
servicios, y modificar las aplicaciones existentes. Este artículo muestra cómo acceder al panel de Kubernetes
mediante la CLI de Azure y luego lo guía por algunas operaciones básicas del panel.
Para más información sobre el panel de Kubernetes, consulte la información sobre el panel de la interfaz de
usuario web de Kubernetes. AKS usa la versión 2.0 y posterior del panel de código abierto.
WARNING
El complemento del panel de AKS está programado para quedar en desuso. Use la vista de recursos de
Kubernetes en Azure Por tal (versión preliminar) en su lugar.
El panel de Kubernetes está habilitado de forma predeterminada para los clústeres que ejecutan una versión de
Kubernetes inferior a la 1.18.
El complemento de panel se deshabilitará de forma predeterminada para todos los nuevos clústeres creados en
Kubernetes 1.18 o posterior.
A partir de Kubernetes 1.19 en versión preliminar, AKS ya no admitirá la instalación del complemento administrado
kube-dashboard.
Los clústeres actuales con el complemento habilitado no se verán afectados. Los usuarios seguirán pudiendo instalar
manualmente el panel de código abierto como software instalado por el usuario.
Antes de empezar
En los pasos que se detallan en este documento se da por hecho que ha creado un clúster de AKS y que ha
establecido una conexión kubectl con dicho clúster. Si necesita crear un clúster de AKS, consulte Inicio rápido:
Implementación de un clúster de Azure Kubernetes Service mediante la CLI de Azure.
Azure.
Deshabilitación del panel de Kubernetes

El complemento kube-dashboard está habilitado de forma predeterminada en los clústeres anteriores
a K8s 1.18 . El complemento se puede deshabilitar ejecutando el siguiente comando.
az aks disable-addons -g myRG -n myAKScluster -a kube-dashboard
Inicio del panel de Kubernetes

WARNING
El complemento del panel de AKS está en desuso para las versiones 1.19 +. Use la vista de recursos de Kubernetes en
Azure Portal (versión preliminar) en su lugar.
El siguiente comando abrirá ahora la vista de recursos de Azure Portal en lugar del panel de Kubernetes para las
versiones 1.19 y posteriores.
Para iniciar el panel de Kubernetes en un clúster, use el comando az aks browse. Este comando requiere la
instalación del complemento kube-dashboard en el clúster, que se incluye de forma predeterminada en los
clústeres que ejecutan cualquier versión anterior a Kubernetes 1.18.
El ejemplo siguiente abre el panel para el clúster denominado myAKSCluster en el grupo de recursos
az aks browse --resource-group myResourceGroup --name myAKSCluster
Este comando crea a un proxy entre el sistema de desarrollo y la API de Kubernetes y abre un explorador web en
el panel de Kubernetes. Si un explorador web no se abre en el panel de Kubernetes, copie y pegue la dirección
URL que anotó en la CLI de Azure, normalmente http://127.0.0.1:8001 .
NOTE
Si no ve el panel en http://127.0.0.1:8001 , puede enrutar manualmente a las siguientes direcciones. Los clústeres que
ejecutan la versión 1.16 o posterior usan HTTPS y requieren un punto de conexión independiente.
K8s 1.16 o posterior:
http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy
K8s 1.15 y anterior:
http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard:/proxy
Inicio de sesión en el panel (kubernetes 1.16 o posterior)

IMPORTANT
A partir de la versión 1.10.1 del panel de Kubernetes o la versión 1.16 o posterior de Kubernetes, la cuenta de servicio
"kubernetes-dashboard" ya no se puede usar para recuperar recursos debido a una corrección de seguridad en esa
versión. Como resultado, las solicitudes sin información de autenticación devuelven un error 401 no autorizado. Un token
de portador recuperado de una cuenta de servicio puede seguir utilizándose como en este ejemplo del panel de
Kubernetes, pero esto afecta al flujo de inicio de sesión del complemento del panel en comparación con versiones
anteriores.
Si sigue ejecutando una versión anterior a la 1.16, todavía puede conceder permisos a la cuenta de servicio "kubernetes-
dashboard", pero no se recomienda :
kubectl create clusterrolebinding kubernetes-dashboard --clusterrole=cluster-admin --

serviceaccount=kube-system:kubernetes-dashboard
La pantalla inicial presentada requiere un archivo kubeconfig o un token. Ambas opciones requieren permisos
de recursos para mostrar esos recursos en el panel.
Uso de un archivo kubeconfig
En el caso de los clústeres tanto habilitados como no habilitados para Azure AD, se puede pasar un archivo
kubeconfig. Asegúrese de que los tokens de acceso sean válidos. Si los tokens han expirado, puede actualizarlos
a través de kubectl.
1. Establezca el archivo kubeconfig de administración con
az aks get-credentials -a --resource-group <RG_NAME> --name <CLUSTER_NAME> .
2. Seleccione Kubeconfig y haga clic en Choose kubeconfig file para abrir el selector de archivos.
3. Seleccione el archivo kubeconfig (de forma predeterminada, se encuentra en $HOME/.kube/config).
4. Haga clic en Sign In
Uso de un token
1. En el caso de los clústeres no habilitados para Azure AD , ejecute kubectl config view y copie el token
asociado a la cuenta de usuario del clúster.
2. Péguelo en la opción de token en el inicio de sesión.
En el caso de los clústeres habilitados para Azure AD, recupere el token de AAD con el siguiente comando.
Compruebe que ha reemplazado el grupo de recursos y el nombre del clúster en el comando.
## Update <RESOURCE_GROUP and <AKS_NAME> with your input.
kubectl config view -o jsonpath='{.users[?(@.name == "clusterUser_<RESOURCE GROUP>_<AKS_NAME>")].user.auth-

provider.config.access-token}'
Una vez que se realiza correctamente, se mostrará una página similar a la siguiente.
Crear una aplicación
Los pasos siguientes requieren que el usuario tenga permisos para los recursos respectivos.
Para ver cómo el panel de Kubernetes puede reducir la complejidad de las tareas de administración, vamos a
crear una aplicación. Puede crear una aplicación desde el panel de Kubernetes, ya sea proporcionando la entrada
de texto, un archivo YAML o mediante un asistente gráfico.
Para crear una aplicación, realice los pasos siguientes:
1. Seleccione el botón Crear de la ventana superior derecha.
2. Para usar el asistente para gráficos, elija Crear una aplicación .
3. Proporcione un nombre para la implementación, por ejemplo nginx
4. Escriba el nombre de la imagen de contenedor que se utilizará, como nginx:1.15.5
5. Para exponer el puerto 80 para el tráfico web, cree un servicio de Kubernetes. En Ser vice (Servicio),
seleccione External (Externo) y escriba 80 tanto para el puerto como para el puerto de destino.
6. Cuando esté preparado, seleccione Implementar para crear la aplicación.
Se tarda un minuto o dos en que una dirección IP externa pública se asigne al servicio de Kubernetes. A la
izquierda, bajo Discover y and Load Balancing (Detección y equilibrio de carga), seleccione Ser vicios . Se
muestra el servicio de la aplicación, incluidos los puntos de conexión externos, como se muestra en el ejemplo
siguiente:
Seleccione la dirección de punto de conexión para abrir una ventana del explorador web con la página
predeterminada de NGINX:
Visualización de la información de pod
El panel de Kubernetes puede proporcionar métricas de supervisión básicas e información para solución de
problemas como los registros.
Para más información acerca de los pods de aplicación, seleccione Pods en el menú izquierdo. Se muestra una
lista de los pods disponibles. Elija su pod nginx para ver información, por ejemplo, del consumo de recursos:
Edición de aplicación
Además de crear y visualizar las aplicaciones, el panel de Kubernetes puede utilizarse para editar y actualizar las
implementaciones de aplicaciones. Para proporcionar redundancia adicional para la aplicación, vamos a
aumentar el número de réplicas de NGINX.
Para editar una implementación:
1. Seleccione Deployments (Implementaciones) en el menú izquierdo y, a continuación, elija su
implementación de nginx.
2. Seleccione Edit (Editar) en la barra de navegación superior derecha.
3. Busque el valor de spec.replica , en torno a la línea 20. Para aumentar el número de réplicas de la
aplicación, cambie este valor de 1 a 3.
4. Seleccione Update (Actualizar) cuando esté listo.
Se tarda unos minutos en que los nuevos pods se creen dentro de un conjunto de réplicas. En el menú
izquierdo, elija Replica Sets (Conjuntos de réplicas) y, a continuación, elija su conjunto de réplicas de nginx. La
lista de los pods ahora refleja el número de réplicas actualizado, como se muestra en la salida del ejemplo
siguiente:
Pasos siguientes
Para más información sobre el panel de Kubernetes, consulte el panel de la interfaz de usuario web de
Kubernetes.
Creación dinámica y uso de un volumen persistente
con discos de Azure en Azure Kubernetes Service
(AKS)
Un volumen persistente representa un fragmento de almacenamiento aprovisionado para su uso con pods de
Kubernetes. Un volumen persistente puede usarse en uno o varios pods y puede aprovisionarse de forma
dinámica o estática. En este artículo se muestra cómo crear dinámicamente volúmenes persistentes con discos
de Azure para usarlos en un solo pod de un clúster de Azure Kubernetes Service (AKS).
NOTE
Un disco de Azure solo se puede montar con el tipo de Modo de acceso establecido en ReadWriteOnce, lo que hace que
esté disponible para un nodo en AKS. Si tiene que compartir un volumen persistente entre varios nodos, use Azure Files.
Para más información sobre los volúmenes de Kubernetes, consulte Opciones de almacenamiento para
aplicaciones en AKS.
Antes de empezar
Azure.
Clases de almacenamiento integradas

Una clase de almacenamiento se usa para definir cómo se crea dinámicamente una unidad de almacenamiento
con un volumen persistente. Para más información sobre las clases de almacenamiento de Kubernetes, consulte
las clases de almacenamiento de Kubernetes.
Cada clúster de AKS incluye cuatro clases de almacenamiento creadas previamente, dos de las cuales están
configuradas para funcionar con discos de Azure:
La clase de almacenamiento predeterminada aprovisiona un disco SSD de Azure estándar.
Standard Storage está respaldado por SSD estándar y ofrece un almacenamiento rentable, al tiempo
que proporciona un rendimiento fiable.
La clase de almacenamiento Premium administrada aprovisiona un disco de Azure premium.
Los discos Premium están respaldados por un disco de latencia reducida y alto rendimiento basado en
SSD. Es perfecto para máquinas virtuales que ejecutan cargas de trabajo de producción. Si los nodos
de AKS del clúster usan almacenamiento Premium, seleccione la clase administrada Premium.
Si usa una de las clases de almacenamiento predeterminadas, no puede actualizar el tamaño del volumen una
vez creada la clase de almacenamiento. Para poder actualizar el tamaño del volumen después de crear una clase
de almacenamiento, agregue la línea allowVolumeExpansion: true a una de las clases de almacenamiento
predeterminadas o también puede crear su propia clase de almacenamiento personalizada. Tenga en cuenta que
no se admite para reducir el tamaño de una PVC (para evitar la pérdida de datos). Puede editar una clase de
almacenamiento existente con el comando kubectl edit sc .
Por ejemplo, si desea usar un disco de 4 TiB de tamaño, debe crear una clase de almacenamiento que defina
cachingmode: None , porque el almacenamiento en caché de discos no se admite en discos de 4 TiB y más
grandes.
Para más información sobre las clases de almacenamiento y la creación de la suya propia, consulte Opciones de
almacenamiento de aplicaciones en AKS.
Use el comando kubectl get sc para ver las clases de almacenamiento que se crearon previamente. El ejemplo
siguiente muestra las clases de almacenamiento creadas previamente disponibles dentro de un clúster de AKS:
$ kubectl get sc
NAME PROVISIONER AGE

default (default) kubernetes.io/azure-disk 1h
managed-premium kubernetes.io/azure-disk 1h
NOTE
Las notificaciones de volumen persistente se especifican en GiB, pero los discos administrados de Azure se facturan por
SKU para un tamaño específico. Estas SKU varían de 32 GiB para discos S4 o P4 a 32 TiB para discos S80 o P80 (en
versión preliminar). El rendimiento de transferencia de datos de red y el rendimiento IOPS de un disco administrado
Premium depende de la SKU y del tamaño de instancia de los nodos en el clúster de AKS. Para más información, consulte
Precios y rendimiento de Managed Disks.
Creación de una notificación de volumen persistente

Una notificación de volumen persistente (PVC) se usa para aprovisionar automáticamente el almacenamiento en
función de una clase de almacenamiento. En ese caso, una PVC puede usar una de las clases de almacenamiento
que crearon previamente para crear un disco administrado de Azure estándar o premium.
Cree un archivo denominado azure-premium.yaml y cópielo en el siguiente código manifiesto. La notificación
solicita un disco llamado azure-managed-disk esto es 5GB de tamaño con acceso ReadWriteOnce. La clase
Premium administrada se especifica como la clase de almacenamiento.
apiVersion: v1
metadata:
name: azure-managed-disk
spec:
accessModes:
- ReadWriteOnce
storageClassName: managed-premium
resources:
requests:
storage: 5Gi
TIP
Para crear un disco que usa almacenamiento estándar, use storageClassName: default en lugar de la clase Premium
administrada.
Cree la notificación del volumen persistente con el comando kubectl apply y especifique su archivo azure-
premium.yaml:
$ kubectl apply -f azure-premium.yaml
persistentvolumeclaim/azure-managed-disk created
Uso del volumen persistente

Una vez que se haya creado la notificación de volumen persistente y tras el aprovisionamiento correcto del
disco, se puede crear un pod con acceso al disco. El siguiente manifiesto crea un pod NGINX básico que utiliza la
notificación de volumen persistente azure-managed-disk para montar el disco de Azure en la ruta de acceso
/mnt/azure . Para los contenedores de Windows Server, especifique un elemento mountPath con la convención
de ruta de acceso de Windows, como "D:" .
Cree un archivo denominado azure-pvc-disk.yaml y cópielo en el siguiente código manifiesto.
kind: Pod
apiVersion: v1
metadata:
name: mypod
spec:
containers:
- name: mypod
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
volumeMounts:
name: volume
volumes:
- name: volume
claimName: azure-managed-disk
Cree el pod con el comando kubectl apply, tal como se muestra en el ejemplo siguiente:
$ kubectl apply -f azure-pvc-disk.yaml
pod/mypod created
Ahora tiene un pod en ejecución con el disco de Azure montado en el directorio /mnt/azure . Esta configuración
puede verse al examinar el pod mediante kubectl describe pod mypod , tal y como se muestra en el siguiente
ejemplo reducido:
$ kubectl describe pod mypod
[...]
Volumes:
volume:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: azure-managed-disk
ReadOnly: false
default-token-smm2n:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-smm2n
Optional: false
[...]
Events:
---- ------ ---- ---- -------
Normal Scheduled 2m default-scheduler Successfully assigned mypod to
aks-nodepool1-79590246-0
Normal SuccessfulMountVolume 2m kubelet, aks-nodepool1-79590246-0 MountVolume.SetUp succeeded for
volume "default-token-smm2n"
volume "pvc-faf0f176-8b8d-11e8-923b-deb28c58d242"
[...]
Uso de Ultra Disks

Para utilizar el almacenamiento en disco Ultra, vea Uso de Ultra Disks en Azure Kubernetes Service (AKS).
Realización de una copia de seguridad de un volumen persistente

Para realizar una copia de seguridad de los datos de su volumen persistente, tome una instantánea del disco
administrado para el volumen. A continuación, puede usar esta instantánea para crear un disco restaurado y
asociarlo a los pods como un medio para restaurar los datos.
En primer lugar, obtenga el nombre del volumen con el comando kubectl get pvc , como por ejemplo para la
clase PVC denominada azure-managed-disk:
$ kubectl get pvc azure-managed-disk
NAME STATUS VOLUME CAPACITY ACCESS MODES

STORAGECLASS AGE
azure-managed-disk Bound pvc-faf0f176-8b8d-11e8-923b-deb28c58d242 5Gi RWO managed-
premium 3m
Este nombre de volumen constituye el nombre de disco de Azure subyacente. Realice una consulta para el
identificador del disco con az disk list y proporcione el nombre del volumen PVC, tal como se muestra en el
ejemplo siguiente:
$ az disk list --query '[].id | [?contains(@,`pvc-faf0f176-8b8d-11e8-923b-deb28c58d242`)]' -o tsv
/subscriptions/<guid>/resourceGroups/MC_MYRESOURCEGROUP_MYAKSCLUSTER_EASTUS/providers/MicrosoftCompute/disks
/kubernetes-dynamic-pvc-faf0f176-8b8d-11e8-923b-deb28c58d242
Use el identificador del disco para crear un disco de instantánea con az snapshot create. El ejemplo siguiente
crea una instantánea denominada pvcSnapshot en el mismo grupo de recursos que el clúster de AKS
(MC_myResourceGroup_myAKSCluster_eastus). Puede tener algún problema con los permisos si crea
instantáneas y restaura discos en grupos de recursos a los que el clúster de AKS no tenga acceso.
$ az snapshot create \
--resource-group MC_myResourceGroup_myAKSCluster_eastus \
--name pvcSnapshot \
--source
/subscriptions/<guid>/resourceGroups/MC_myResourceGroup_myAKSCluster_eastus/providers/MicrosoftCompute/disks
/kubernetes-dynamic-pvc-faf0f176-8b8d-11e8-923b-deb28c58d242
Según la cantidad de datos en el disco, la instantánea puede tardar unos minutos en crearse.
Restauración y uso de una instantánea

Para restaurar el disco y usarlo con un pod de Kubernetes, utilice la instantánea como un origen al crear un
disco con az disk create. Esta operación conserva el recurso original si luego necesita tener acceso a la
instantánea de datos original. En el ejemplo siguiente se crea un disco llamado pvcRestored desde la instantánea
denominada pvcSnapshot:
az disk create --resource-group MC_myResourceGroup_myAKSCluster_eastus --name pvcRestored --source

pvcSnapshot
Para usar el disco restaurado con un pod, especifique el identificador del disco en el manifiesto. Obtenga el
identificador del disco con el comando az disk show. En el ejemplo siguiente se obtiene el identificador del disco
para pvcRestored creado en el paso anterior:
az disk show --resource-group MC_myResourceGroup_myAKSCluster_eastus --name pvcRestored --query id -o tsv
Cree un manifiesto de pod llamado azure-restored.yaml y especifique el URI de disco obtenido en el paso
anterior. En el ejemplo siguiente se crea un servidor web NGINX básico, con el disco restaurado montado como
un volumen en /mnt/azure:
kind: Pod
apiVersion: v1
metadata:
name: mypodrestored
spec:
containers:
- name: mypodrestored
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
volumeMounts:
name: volume
volumes:
- name: volume
azureDisk:
kind: Managed
diskName: pvcRestored
diskURI:
/subscriptions/<guid>/resourceGroups/MC_myResourceGroupAKS_myAKSCluster_eastus/providers/Microsoft.Compute/d
isks/pvcRestored
$ kubectl apply -f azure-restored.yaml
pod/mypodrestored created
Puede usar kubectl describe pod mypodrestored para ver los detalles del pod, como el siguiente ejemplo
reducido que muestra la información de volumen:
$ kubectl describe pod mypodrestored
[...]
Volumes:
volume:
Type: AzureDisk (an Azure Data Disk mount on the host and bind mount to the pod)
DiskName: pvcRestored
DiskURI: /subscriptions/19da35d3-9a1a-4f3b-9b9c-
3c56ef409565/resourceGroups/MC_myResourceGroupAKS_myAKSCluster_eastus/providers/Microsoft.Compute/disks/pvcR
estored
Kind: Managed
FSType: ext4
CachingMode: ReadWrite
ReadOnly: false
[...]
Pasos siguientes
Obtenga más información sobre los volúmenes persistentes de Kubernetes con discos de Azure.
Complemento de Kubernetes para discos de Azure
Creación manual y uso de un volumen con discos
de Azure en Azure Kubernetes Service (AKS)
Las aplicaciones que usan contenedores a menudo necesitan acceder a un volumen de datos externo y
conservar datos en él. Si un solo pod necesita acceso al almacenamiento, puede utilizar discos de Azure para
presentar un volumen nativo y usarlo en la aplicación. Este artículo muestra cómo crear manualmente un disco
de Azure y asociarlo a un pod en AKS.
NOTE
Un disco de Azure solo se puede montar en un solo pod a la vez. Si tiene que compartir un volumen persistente en varios
pods, use Azure Files.
Antes de empezar
Azure.
Creación de un disco de Azure

Cuando crea un disco de Azure para usarlo con AKS, puede crear el recurso de disco en el grupo de recursos del
nodo . Este enfoque permite que el clúster AKS acceda y administre el recurso de disco. Si en cambio crea el
disco en un grupo de recursos distinto, debe conceder a la identidad administrada de Azure Kubernetes Service
(AKS) del clúster el rol Contributor en el grupo de recursos del disco.
En este artículo, se crea el disco en el grupo de recursos del nodo. En primer lugar, obtenga el nombre del grupo
de recursos con el comando az aks show y agregue el parámetro de consulta --query nodeResourceGroup . En
este ejemplo se obtiene el grupo de recursos del nodo para el nombre de clúster de AKS myAKSCluster en el
grupo de recursos denominado myResourceGroup:
$ az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv
MC_myResourceGroup_myAKSCluster_eastus
Ahora cree un disco mediante el comando az disk create. Especifique el nombre del grupo de recursos del nodo
que obtuvo en el comando anterior y, después, un nombre para el recurso de disco, como miDiscoAKS . En el
ejemplo siguiente, se crea un disco de 20 GiB y se obtiene como salida el identificador del disco una vez creado.
Si tiene que crear un disco para su uso con contenedores de Windows Server, agregue el parámetro
--os-type windows para formatear correctamente el disco.
az disk create \
--name myAKSDisk \
--size-gb 20 \
--query id --output tsv
NOTE
Los discos de Azure se facturan por SKU de un tamaño específico. Estas SKU varían de 32 GiB para discos S4 o P4 a 32 TiB
para discos S80 o P80 (en versión preliminar). El rendimiento de transferencia de datos de red y el rendimiento IOPS de
un disco administrado Premium depende de la SKU y del tamaño de instancia de los nodos en el clúster de AKS. Consulte
Precios y rendimiento de Managed Disks.
El identificador de recurso de disco se muestra una vez que se ha completado correctamente el comando, como
se muestra en la siguiente salida de ejemplo. Este identificador de disco se utiliza para montar el disco en el
paso siguiente.
/subscriptions/<subscriptionID>/resourceGroups/MC_myAKSCluster_myAKSCluster_eastus/providers/Microsoft.Compu
te/disks/myAKSDisk
Montaje del disco como un volumen

Para montar el disco de Azure en el pod, configure el volumen en las especificaciones del contenedor. Cree un
nuevo archivo denominado azure-disk-pod.yaml con el contenido siguiente. Actualice diskName con el nombre
del disco creado en el paso anterior y diskURI con el identificador del disco que se muestra en la salida del
comando para crear el disco. Además, actualice mountPath , que es la ruta de acceso en la que se monta el disco
de Azure en el pod. Para los contenedores de Windows Server, especifique un elemento mountPath con la
convención de ruta de acceso de Windows, como "D:" .
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
name: mypod
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
volumeMounts:
- name: azure
mountPath: /mnt/azure
volumes:
- name: azure
azureDisk:
kind: Managed
diskName: myAKSDisk
diskURI:
/subscriptions/<subscriptionID>/resourceGroups/MC_myAKSCluster_myAKSCluster_eastus/providers/Microsoft.Compu
te/disks/myAKSDisk
Use el comando kubectl para crear el pod.

kubectl apply -f azure-disk-pod.yaml
Ahora tiene un pod en ejecución con un disco de Azure montado en /mnt/azure . Puede usar
kubectl describe pod mypod para comprobar que el disco se montó correctamente. La siguiente salida de
ejemplo condensada muestra el volumen montado en el contenedor:
[...]
Volumes:
azure:
Type: AzureDisk (an Azure Data Disk mount on the host and bind mount to the pod)
DiskName: myAKSDisk
DiskURI:
/subscriptions/<subscriptionID/resourceGroups/MC_myResourceGroupAKS_myAKSCluster_eastus/providers/Microsoft.
Compute/disks/myAKSDisk
Kind: Managed
FSType: ext4
CachingMode: ReadWrite
ReadOnly: false
default-token-z5sd7:
SecretName: default-token-z5sd7
Optional: false
[...]
Events:
---- ------ ---- ---- -------
volume "default-token-z5sd7"
Normal SuccessfulMountVolume 41s kubelet, aks-nodepool1-79590246-0 MountVolume.SetUp succeeded for
volume "azure"
[...]
Pasos siguientes
Para más información acerca de la interactuación de los clústeres AKS con los discos de Azure, consulte el
complemento de Kubernetes para los discos de Azure.
Creación dinámica y uso de un volumen persistente
con Azure Files en Azure Kubernetes Service (AKS)
Un volumen persistente representa un fragmento de almacenamiento aprovisionado para su uso con pods de
Kubernetes. Un volumen persistente puede usarse en uno o varios pods y puede aprovisionarse de forma
dinámica o estática. Si varios pods necesitan acceso simultáneo al mismo volumen de almacenamiento, puede
usar Azure Files para conectarse mediante el protocolo Bloque de mensajes del servidor (SMB). Este artículo
muestra cómo crear dinámicamente un recurso compartido de Azure Files para ser usado por varios pods en un
clúster de Azure Kubernetes Service (AKS).
Antes de empezar
Azure.
Creación de una clase de almacenamiento

Una clase de almacenamiento se utiliza para definir cómo se crea un recurso compartido de archivos de Azure.
En el grupo de recursos node, se crea automáticamente una cuenta de almacenamiento para utilizarla con la
clase de almacenamiento donde van a guardarse los recursos compartidos de archivos de Azure. Seleccione una
de las siguientes redundancias de Azure Storage para skuName:
Standard_LRS : almacenamiento estándar con redundancia local (LRS)
Standard_GRS : almacenamiento estándar con redundancia geográfica (GRS)
Standard_ZRS : almacenamiento estándar con redundancia de zona (ZRS)
Standard_RAGRS : almacenamiento estándar con redundancia geográfica con acceso de lectura (RA-GRS)
Premium_LRS : almacenamiento con redundancia local premium (LRS)
Premium_ZRS : almacenamiento con redundancia de zona premium (ZRS)
NOTE
Azure Files admite el almacenamiento premium en clústeres de AKS que ejecutan Kubernetes 1.13 o versiones posteriores.
El uso compartido de archivos premium mínimo es de 100 GB.
Para más información sobre las clases de almacenamiento de Kubernetes para Azure Files, consulte las clases de
almacenamiento de Kubernetes.
Cree un archivo denominado azure-file-sc.yaml y cópielo en el ejemplo siguiente de manifiesto. Para más
información sobre mountOptions, consulte la sección Opciones de montaje.
kind: StorageClass
metadata:
name: my-azurefile
provisioner: kubernetes.io/azure-file
mountOptions:
- dir_mode=0777
- file_mode=0777
- uid=0
- gid=0
- mfsymlinks
- cache=strict
- actimeo=30
parameters:
skuName: Standard_LRS
Cree la clase de almacenamiento con el comando kubectl apply:
kubectl apply -f azure-file-sc.yaml

Una notificación de volumen persistente (PVC) usa el objeto de clase de almacenamiento para aprovisionar de
forma dinámica un recurso compartido de archivos de Azure. El siguiente código de YAML puede utilizarse para
crear una notificación de volumen persistente con un tamaño de 5 GB y con acceso ReadWriteMany. Para más
información sobre los modos de acceso, consulte la documentación sobre volúmenes persistentes de
Kubernetes.
Ahora cree un archivo denominado azure-file-pvc.yaml y cópielo en el siguiente código YAML. Asegúrese de
que storageClassName coincide con la clase de almacenamiento creada en el último paso:
apiVersion: v1
metadata:
name: my-azurefile
spec:
accessModes:
- ReadWriteMany
storageClassName: my-azurefile
resources:
requests:
storage: 5Gi
NOTE
Si usa la SKU Premium_LRS para la clase de almacenamiento, el valor mínimo de storage debe ser 100Gi.
Cree la notificación del volumen persistente con el comando kubectl apply:
kubectl apply -f azure-file-pvc.yaml
Una vez completado, se creará el recurso compartido de archivos. También se crea un secreto de Kubernetes
que incluye las credenciales y la información de conexión. Puede usar el comando kubectl get para ver el estado
de la PVC:
$ kubectl get pvc my-azurefile
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS

AGE
my-azurefile Bound pvc-8436e62e-a0d9-11e5-8521-5a8664dc0477 5Gi RWX my-azurefile
5m

El siguiente código de YAML crea un pod que utiliza la notificación de volumen persistente my-azurefile para
montar el recurso compartido de archivos de Azure en la ruta de acceso /mnt/azure. En el caso de los
contenedores de Windows Server, especifique un elemento mountPath con la convención de ruta de acceso de
Windows, como "D:" .
Cree un archivo denominado azure-pvc-files.yaml y cópielo en el siguiente código YAML. Asegúrese de que
claimName coincide con la clase PVC creada en el último paso.
kind: Pod
apiVersion: v1
metadata:
name: mypod
spec:
containers:
- name: mypod
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
volumeMounts:
name: volume
volumes:
- name: volume
claimName: my-azurefile
Cree el pod con el comando kubectl apply.
kubectl apply -f azure-pvc-files.yaml
Ahora tiene un pod en ejecución con el recurso compartido de Azure Files montado en el directorio /mnt/azure.
Esta configuración puede verse al examinar el pod mediante kubectl describe pod mypod . La siguiente salida de
ejemplo condensada muestra el volumen montado en el contenedor:
Containers:
mypod:
Container ID: docker://053bc9c0df72232d755aa040bfba8b533fa696b123876108dec400e364d2523e
Image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
Image ID: docker-
pullable://nginx@sha256:d85914d547a6c92faa39ce7058bd7529baacab7e0cd4255442b04577c4d1f424
State: Running
Started: Fri, 01 Mar 2019 23:56:16 +0000
Ready: True
Mounts:
/mnt/azure from volume (rw)
/var/run/secrets/kubernetes.io/serviceaccount from default-token-8rv4z (ro)
[...]
Volumes:
volume:
ClaimName: my-azurefile
ReadOnly: false
[...]
Opciones de montaje
El valor predeterminado de fileMode y dirMode es 0777 para Kubernetes 1.13.0 y versiones posteriores. Si crea
dinámicamente el volumen persistente con una clase de almacenamiento, las opciones de montaje se pueden
especificar en el objeto de la clase de almacenamiento. En el ejemplo siguiente se establece 0777:
kind: StorageClass
metadata:
name: my-azurefile
mountOptions:
- dir_mode=0777
- file_mode=0777
- uid=0
- gid=0
- mfsymlinks
- cache=strict
- actimeo=30
parameters:
Pasos siguientes
Para obtener información sobre los parámetros de clase de almacenamiento, consulte Aprovisionamiento
dinámico.
Obtenga más información sobre los volúmenes persistentes de Kubernetes con Azure Files.
Complemento de Kubernetes para Azure Files
Creación manual y uso de un volumen con un
recurso compartido de Azure Files en Azure
Las aplicaciones que usan contenedores a menudo necesitan acceder a un volumen de datos externo y
conservar datos en él. Si varios pods necesitan acceso simultáneo al mismo volumen de almacenamiento, puede
usar Azure Files para conectarse mediante el protocolo Bloque de mensajes del servidor (SMB). Este artículo
muestra cómo crear manualmente un recurso compartido de Azure Files y asociarlo a un pod en AKS.
Antes de empezar
Azure.
Creación de un recurso compartido de archivos de Azure

Para poder utilizar Azure Files como volumen de Kubernetes, es preciso crear una cuenta de Azure Storage y el
recurso compartido de archivos. Los comandos siguientes crean un grupo de recursos denominado
myAKSShare, una cuenta de almacenamiento y un recurso compartido de Azure Files denominado aksshare:
# Change these four parameters as needed for your own environment
AKS_PERS_STORAGE_ACCOUNT_NAME=mystorageaccount$RANDOM
AKS_PERS_RESOURCE_GROUP=myAKSShare
AKS_PERS_LOCATION=eastus
AKS_PERS_SHARE_NAME=aksshare

az group create --name $AKS_PERS_RESOURCE_GROUP --location $AKS_PERS_LOCATION
# Create a storage account

az storage account create -n $AKS_PERS_STORAGE_ACCOUNT_NAME -g $AKS_PERS_RESOURCE_GROUP -l
$AKS_PERS_LOCATION --sku Standard_LRS
# Export the connection string as an environment variable, this is used when creating the Azure file share
export AZURE_STORAGE_CONNECTION_STRING=$(az storage account show-connection-string -n
$AKS_PERS_STORAGE_ACCOUNT_NAME -g $AKS_PERS_RESOURCE_GROUP -o tsv)
# Create the file share

az storage share create -n $AKS_PERS_SHARE_NAME --connection-string $AZURE_STORAGE_CONNECTION_STRING
# Get storage account key

STORAGE_KEY=$(az storage account keys list --resource-group $AKS_PERS_RESOURCE_GROUP --account-name
$AKS_PERS_STORAGE_ACCOUNT_NAME --query "[0].value" -o tsv)
# Echo storage account name and key

echo Storage account name: $AKS_PERS_STORAGE_ACCOUNT_NAME
echo Storage account key: $STORAGE_KEY
Tome nota del nombre de la cuenta de almacenamiento y la clave que se muestran al final de la salida del script.
Estos valores son necesarios cuando se crea el volumen de Kubernetes en uno de los pasos siguientes.
Creación de un secreto de Kubernetes

Kubernetes necesita credenciales para acceder al recurso compartido de archivos creado en el paso anterior.
Estas credenciales se almacenan en un secreto de Kubernetes, al que se hace referencia al crear un pod de
Kubernetes.
Use el comando kubectl create secret para crear el secreto. En el ejemplo siguiente se crea un recurso
compartido denominado azure-secret y rellena los valores de azurestorageaccountname y
azurestorageaccountkey en el paso anterior. Para usar una cuenta de almacenamiento de Azure existente,
proporcione su nombre y su clave.
kubectl create secret generic azure-secret --from-

literal=azurestorageaccountname=$AKS_PERS_STORAGE_ACCOUNT_NAME --from-
literal=azurestorageaccountkey=$STORAGE_KEY
Montaje de un recurso compartido de archivos como volumen

insertado
Nota: A partir de 1.18.15, 1.19.7, 1.20.2 y 1.21.0, el espacio de nombres secreto en el volumen insertado
azureFile solo se puede establecer como espacio de nombres default para especificar otro espacio de
nombres secreto. Use en su lugar el siguiente ejemplo de volumen persistente.
Para montar el recurso compartido de Azure Files en el pod, configure el volumen en las especificaciones del
contenedor. Cree un nuevo archivo denominado azure-files-pod.yaml con el contenido siguiente. Si ha
cambiado el nombre del recurso compartido de Azure Files o el nombre del secreto, actualice los valores
shareName y secretName. Además, actualice el valor de mountPath , que es la ruta de acceso en la que se monta
el recurso compartido de Azure Files en el pod. Para los contenedores de Windows Server, especifique un
elemento mountPath con la convención de ruta de acceso de Windows, como "D:" .
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
name: mypod
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
volumeMounts:
- name: azure
volumes:
- name: azure
azureFile:
secretName: azure-secret
shareName: aksshare
readOnly: false
Use el comando kubectl para crear el pod.
kubectl apply -f azure-files-pod.yaml
Ahora tiene un pod en ejecución con un recurso compartido de Azure Files montado en /mnt/azure. Puede usar
kubectl describe pod mypod para comprobar que el recuso compartido se montó correctamente. La siguiente
salida de ejemplo condensada muestra el volumen montado en el contenedor:
Containers:
mypod:
Container ID: docker://86d244cfc7c4822401e88f55fd75217d213aa9c3c6a3df169e76e8e25ed28166
Image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
Image ID: docker-
pullable://nginx@sha256:9ad0746d8f2ea6df3a17ba89eca40b48c47066dfab55a75e08e2b70fc80d929e
State: Running
Started: Sat, 02 Mar 2019 00:05:47 +0000
Ready: True
Mounts:
/mnt/azure from azure (rw)
/var/run/secrets/kubernetes.io/serviceaccount from default-token-z5sd7 (ro)
[...]
Volumes:
azure:
Type: AzureFile (an Azure File Service mount on the host and bind mount to the pod)
SecretName: azure-secret
ShareName: aksshare
ReadOnly: false
default-token-z5sd7:
SecretName: default-token-z5sd7
[...]
Montaje de un recurso compartido de archivos como volumen

persistente
Opciones de montaje
El valor predeterminado de fileMode y dirMode es 0777 para Kubernetes 1.15 y versiones posteriores. En el
ejemplo siguiente se establece 0755 en el objeto PersistentVolume:
apiVersion: v1
kind: PersistentVolume
metadata:
name: azurefile
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteMany
azureFile:
secretNamespace: default
shareName: aksshare
readOnly: false
mountOptions:
- dir_mode=0755
- file_mode=0755
- uid=1000
- gid=1000
- mfsymlinks
- nobrl
Para actualizar las opciones de montaje, cree un archivo azurefile-mount-options-pv.yaml con un objeto
PersistentVolume. Por ejemplo:
apiVersion: v1
metadata:
name: azurefile
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteMany
azureFile:
shareName: aksshare
readOnly: false
mountOptions:
- dir_mode=0777
- file_mode=0777
- uid=1000
- gid=1000
- mfsymlinks
- nobrl
Cree un archivo azurefile-mount-options-pvc.yaml con PersistentVolumeClaim que use el objeto

PersistentVolume. Por ejemplo:
apiVersion: v1
metadata:
name: azurefile
spec:
accessModes:
- ReadWriteMany
storageClassName: ""
resources:
requests:
storage: 5Gi
Use los comandos kubectl para crear el objeto PersistentVolume y PersistentVolumeClaim.
kubectl apply -f azurefile-mount-options-pv.yaml

kubectl apply -f azurefile-mount-options-pvc.yaml
Compruebe que PersistentVolumeClaim se creó y enlazó al objeto PersistentVolume.
$ kubectl get pvc azurefile
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE

azurefile Bound azurefile 5Gi RWX azurefile 5s
Actualice la especificación de contenedor para hacer referencia al objeto PersistentVolumeClaim y actualice su

pod. Por ejemplo:
...
volumes:
- name: azure
claimName: azurefile
Pasos siguientes
Para más información acerca de la interactuación de los clústeres de AKS con Azure Files, consulte el
complemento de Kubernetes para Azure Files.
Para información sobre los parámetros de clase de almacenamiento, consulte Aprovisionamiento estático (traiga
su propio recurso compartido de archivos).
Crear manualmente y usar un volumen de servidor
NFS (sistema de archivos de red) de Linux con
Compartir datos entre contenedores a menudo es un componente necesario de las aplicaciones y los servicios
basados en contenedores. Habitualmente tiene varios pods que necesitan tener acceso a la misma información
en un volumen persistente externo.
Si bien los archivos de Azure son una posibilidad, crear un servidor NFS en una máquina virtual de Azure es
otra forma de almacenamiento compartido persistente.
En este artículo se muestra cómo crear un servidor NFS en una máquina virtual de Ubuntu. Asimismo, se
explica cómo dar acceso a los contenedores de AKS a este sistema de archivos compartido.
Antes de empezar
El clúster de AKS debe residir en las mismas redes virtuales emparejadas que el servidor NFS. El clúster debe
crearse en una red virtual existente, que puede ser la misma que la de su máquina virtual.
En la documentación se describen los pasos para configurar una red virtual existente: Creación de un clúster de
AKS en la red virtual y Conexión de redes virtuales con emparejamiento de redes virtuales
También se supone que ha creado una máquina Virtual de Ubuntu Linux (por ejemplo, 18.04 LTS). La
configuración y el tamaño pueden ser a su gusto y pueden implementarse mediante Azure. En el caso del inicio
rápido de Linux, consulte el artículo sobre la administración de máquinas virtuales de Linux.
Si implementa el clúster de AKS primero, Azure automáticamente rellenará el campo de red virtual al
implementar la máquina de Ubuntu, conectándolos dentro de la misma red virtual. Sin embargo, si desea
trabajar con redes emparejadas, consulte la documentación anterior.
Implementar el servidor NFS en una máquina virtual

A continuación se muestra el script para configurar un servidor NFS dentro de la máquina virtual de Ubuntu:
#!/bin/bash
# This script should be executed on Linux Ubuntu Virtual Machine
EXPORT_DIRECTORY=${1:-/export/data}
DATA_DIRECTORY=${2:-/data}
AKS_SUBNET=${3:-*}
echo "Updating packages"

apt-get -y update
echo "Installing NFS kernel server"
apt-get -y install nfs-kernel-server
echo "Making data directory ${DATA_DIRECTORY}"

mkdir -p ${DATA_DIRECTORY}
echo "Making new directory to be exported and linked to data directory: ${EXPORT_DIRECTORY}"
mkdir -p ${EXPORT_DIRECTORY}
echo "Mount binding ${DATA_DIRECTORY} to ${EXPORT_DIRECTORY}"

mount --bind ${DATA_DIRECTORY} ${EXPORT_DIRECTORY}
echo "Giving 777 permissions to ${EXPORT_DIRECTORY} directory"

chmod 777 ${EXPORT_DIRECTORY}
parentdir="$(dirname "$EXPORT_DIRECTORY")"
echo "Giving 777 permissions to parent: ${parentdir} directory"
chmod 777 $parentdir
echo "Appending bound directories into fstab"

echo "${DATA_DIRECTORY} ${EXPORT_DIRECTORY} none bind 0 0" >> /etc/fstab
echo "Appending localhost and Kubernetes subnet address ${AKS_SUBNET} to exports configuration file"
echo "/export ${AKS_SUBNET}(rw,async,insecure,fsid=0,crossmnt,no_subtree_check)" >> /etc/exports
echo "/export localhost(rw,async,insecure,fsid=0,crossmnt,no_subtree_check)" >> /etc/exports
nohup service nfs-kernel-server restart
El servidor se reiniciará (debido al script) y podrá montar el servidor NFS en AKS.
IMPORTANT
Asegúrese de reemplazar el AKS_SUBNET por el correcto desde el clúster o, de lo contrario, "*" abrirá el servidor NFS a
todos los puertos y conexiones.
Después de crear la máquina virtual, copie el script anterior en un archivo. A continuación, puede moverlo desde
la máquina local o la ubicación donde se encuentre el script a la máquina virtual mediante:
scp /path/to/script_file username@vm-ip-address:/home/{username}
Una vez que el script se encuentra en la máquina virtual, puede acceder mediante ssh a la máquina virtual y
ejecutarla mediante este comando:
sudo ./nfs-server-setup.sh
Si se produce un error en la ejecución debido a un error de permiso denegado, establezca el permiso de

ejecución mediante el siguiente comando:
chmod +x ~/nfs-server-setup.sh
Conectar el clúster de AKS al servidor NFS

Podemos conectar el servidor NFS a nuestro clúster aprovisionando un volumen persistente y una notificación
de volumen persistente que especifique cómo acceder al volumen.
Es necesario conectar ambos servicios en la misma red virtual o en redes virtuales emparejadas. Las
instrucciones para configurar el clúster en la misma red virtual se encuentran en este artículo: Creación de un
clúster de AKS en la red virtual
Una vez que se encuentren en la misma red virtual (o en redes virtuales emparejadas), deberá aprovisionar un
volumen persistente y una notificación de volumen persistente en el clúster de AKS. A continuación, los
contenedores pueden montar la unidad NFS en su directorio local.
A continuación, se incluye un ejemplo de una definición de Kubernetes para el volumen persistente (esta
definición presupone que el clúster y la máquina virtual están en la misma red virtual):
apiVersion: v1
metadata:
name: <NFS_NAME>
labels:
type: nfs
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteMany
nfs:
server: <NFS_INTERNAL_IP>
path: <NFS_EXPORT_FILE_PATH>
Reemplace NFS_INTERNAL_IP , NFS_NAME y NFS_EXPORT_FILE_PATH con información del servidor NFS.

También necesitará un archivo de notificación de volumen persistente. A continuación se muestra un ejemplo de
lo que se debe incluir:
IMPORTANT
"storageClassName" debe seguir siendo una cadena vacía para que la notificación funcione.
apiVersion: v1
metadata:
name: <NFS_NAME>
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
selector:
matchLabels:
type: nfs
Si no puede conectarse al servidor desde un clúster, puede que haya un problema en el directorio exportado o
en su directorio primario, o bien que no tenga suficientes permisos para acceder al servidor.
Compruebe que el directorio de exportación y su directorio primario tienen 777 permisos.
Para comprobar los permisos, ejecute el comando siguiente; los directorios deberían tener los permisos
'drwxrwxrwx' :
ls -l
Más información
Para obtener un tutorial completo o ayuda para depurar la instalación del servidor NFS, consulte este tutorial
exhaustivo:
Tutorial sobre NFS
Pasos siguientes
Integración de Azure NetApp Files con Azure
Kubernetes Service
Azure NetApp Files es un servicio de almacenamiento de archivos de alto rendimiento, medido y de clase
empresarial que se ejecuta en Azure. En este artículo se le muestra cómo integrar Azure NetApp Files con Azure
Antes de empezar
IMPORTANT
Su clúster de AKS también debe estar en una región que admita Azure NetApp Files.
Azure.
Limitaciones
Las siguientes limitaciones se aplican al usar Azure NetApp Files:
Azure NetApp Files solo está disponible en regiones de Azure seleccionadas.
Para poder usar Azure NetApp Files, debe tener acceso concedido al servicio Azure NetApp Files. Para
solicitar acceso, puede usar el formulario de envío de listas de espera de Azure NetApp Files o puede ir a
https://azure.microsoft.com/services/netapp/#getting-started. No puede tener acceso al servicio Azure
NetApp Files hasta que reciba el correo electrónico de confirmación oficial del equipo de Azure NetApp Files.
Después de la implementación inicial de un clúster de AKS, solo se admite el aprovisionamiento estático para
Azure NetApp Files.
Para usar el aprovisionamiento dinámico con Azure NetApp Files, instale y configure NetApp Trident versión
19.07 o posterior.
Configuración de Azure NetApp Files

IMPORTANT
Para poder registrar el proveedor de recursos Microsoft.NetApp, debe completar el formulario de envío de listas de espera
de Azure NetApp Files o puede ir a https://azure.microsoft.com/services/netapp/#getting-started con su suscripción. No
puede registrar el recurso proporcionado hasta que reciba el correo electrónico de confirmación oficial del equipo de
Azure NetApp Files.
Registre el proveedor de recursos Microsoft.NetApp:
az provider register --namespace Microsoft.NetApp --wait

NOTE
Esta operación puede tardar un tiempo en finalizar.
Cuando crea una cuenta de Azure NetApp para usarla con AKS, debe crearla en el grupo de recursos del nodo .
En primer lugar, obtenga el nombre del grupo de recursos con el comando az aks show y agregue el parámetro
de consulta --query nodeResourceGroup . En este ejemplo se obtiene el grupo de recursos del nodo para el clúster
de AKS denominado myAKSCluster en el nombre del grupo de recursos myResourceGroup:
az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv
Cree una cuenta de Azure NetApp Files en el grupo de recursos del nodo y la misma región que su clúster de
AKS mediante az netappfiles account create. En el siguiente ejemplo se crea una cuenta denominada
myaccount1 en el grupo de recursos MC_myResourceGroup_myAKSCluster_eastus y la región eastus:
az netappfiles account create \

--location eastus \
--account-name myaccount1
Cree un nuevo grupo de capacidad mediante el comando az netappfiles pool create. En el siguiente ejemplo se
crea un nuevo grupo de capacidad denominado mypool1 con 4 TB de tamaño y nivel de servicio Premium:
az netappfiles pool create \

--location eastus \
--account-name myaccount1 \
--pool-name mypool1 \
--size 4 \
--service-level Premium
Cree una subred para delegarla a Azure NetApp Files mediante az network vnet subnet create. Esta subred debe
estar en la misma red virtual que el clúster de AKS.
RESOURCE_GROUP=MC_myResourceGroup_myAKSCluster_eastus
VNET_NAME=$(az network vnet list --resource-group $RESOURCE_GROUP --query [].name -o tsv)
VNET_ID=$(az network vnet show --resource-group $RESOURCE_GROUP --name $VNET_NAME --query "id" -o tsv)
SUBNET_NAME=MyNetAppSubnet
--resource-group $RESOURCE_GROUP \
--vnet-name $VNET_NAME \
--name $SUBNET_NAME \
--delegations "Microsoft.NetApp/volumes" \
--address-prefixes 10.0.0.0/28
Cree un volumen mediante az netappfiles volume create.

RESOURCE_GROUP=MC_myResourceGroup_myAKSCluster_eastus
LOCATION=eastus
ANF_ACCOUNT_NAME=myaccount1
POOL_NAME=mypool1
SERVICE_LEVEL=Premium
VNET_NAME=$(az network vnet list --resource-group $RESOURCE_GROUP --query [].name -o tsv)
VNET_ID=$(az network vnet show --resource-group $RESOURCE_GROUP --name $VNET_NAME --query "id" -o tsv)
SUBNET_NAME=MyNetAppSubnet
SUBNET_ID=$(az network vnet subnet show --resource-group $RESOURCE_GROUP --vnet-name $VNET_NAME --name
$SUBNET_NAME --query "id" -o tsv)
VOLUME_SIZE_GiB=100 # 100 GiB
UNIQUE_FILE_PATH="myfilepath2" # Please note that file path needs to be unique within all ANF Accounts
az netappfiles volume create \

--location $LOCATION \
--account-name $ANF_ACCOUNT_NAME \
--pool-name $POOL_NAME \
--name "myvol1" \
--service-level $SERVICE_LEVEL \
--vnet $VNET_ID \
--subnet $SUBNET_ID \
--usage-threshold $VOLUME_SIZE_GiB \
--file-path $UNIQUE_FILE_PATH \
--protocol-types "NFSv3"
Creación del volumen PersistentVolume

Enumere los detalles de su volumen mediante az netappfiles volume show
az netappfiles volume show --resource-group $RESOURCE_GROUP --account-name $ANF_ACCOUNT_NAME --pool-name

$POOL_NAME --volume-name "myvol1"
{
...
"creationToken": "myfilepath2",
...
"mountTargets": [
{
...
"ipAddress": "10.0.0.4",
...
}
],
...
}
Cree un archivo pv-nfs.yaml que defina un volumen PersistentVolume. Reemplace path por creationToken y
server por ipAddress del comando anterior. Por ejemplo:
---
apiVersion: v1
metadata:
name: pv-nfs
spec:
capacity:
storage: 100Gi
accessModes:
- ReadWriteMany
mountOptions:
- vers=3
nfs:
server: 10.0.0.4
path: /myfilepath2
Actualice el servidor y la ruta de acceso a los valores del volumen de NFS (Network File System) que creó en el
paso anterior. Cree el volumen PersistentVolume con el comando kubectl apply:
kubectl apply -f pv-nfs.yaml
Compruebe que el Estado del volumen PersistentVolume es Disponible mediante el comando kubectl describe:
kubectl describe pv pv-nfs
Creación de la notificación PersistentVolumeClaim

Cree un archivo pvc-nfs.yaml que defina un volumen PersistentVolume. Por ejemplo:
apiVersion: v1
metadata:
name: pvc-nfs
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
Cree la notificación PersistentVolumeClaim con el comando kubectl apply:
kubectl apply -f pvc-nfs.yaml
Compruebe que el Estado de la notificación PersistentVolumeClaim es Enlazado mediante el comando kubectl

describe:
kubectl describe pvc pvc-nfs
Montaje con un pod

Cree un archivo nginx-nfs.yaml que defina un pod que use la notificación PersistentVolumeClaim. Por ejemplo:
kind: Pod
apiVersion: v1
metadata:
name: nginx-nfs
spec:
containers:
name: nginx-nfs
command:
- "/bin/sh"
- "-c"
- while true; do echo $(date) >> /mnt/azure/outfile; sleep 1; done
volumeMounts:
- name: disk01
volumes:
- name: disk01
claimName: pvc-nfs
Cree el pod con el comando kubectl apply:
kubectl apply -f nginx-nfs.yaml
Compruebe que el pod se está ejecutando mediante el comando kubectl describe:
kubectl describe pod nginx-nfs
Compruebe que su volumen se ha montado en el pod mediante kubectl exec para conectarse a pod y, a
continuación, df -h para comprobar si el volumen está montado.
$ kubectl exec -it nginx-nfs -- sh
/ # df -h
Filesystem Size Used Avail Use% Mounted on
...
10.0.0.4:/myfilepath2 100T 384K 100T 1% /mnt/azure
...
Pasos siguientes
Para obtener más información sobre Azure NetApp Files, consulte ¿Qué es Azure NetApp Files? Para obtener
más información sobre el uso de NFS con AKS, consulte Crear manualmente y usar un volumen de servidor
NFS (sistema de archivos de red) de Linux con Azure Kubernetes Service (AKS).
Uso de discos Ultra de Azure en Azure Kubernetes
Service (versión preliminar)
Los discos Ultra de Azure ofrecen un alto rendimiento, IOPS elevadas y un almacenamiento en disco coherente y
de baja latencia para las aplicaciones con estado. Una ventaja importante de los discos Ultra es la posibilidad de
cambiar dinámicamente el rendimiento del disco SSD junto con sus cargas de trabajo sin tener que reiniciar los
nodos de agente. Los discos Ultra son adecuados para cargas de trabajo con un uso intensivo de datos.
Antes de empezar
Esta característica solo se puede establecer durante la creación del clúster o en el momento de creación del
grupo de nodos.
IMPORTANT
Los discos Ultra de Azure requieren grupos de nodos implementados en zonas de disponibilidad y regiones que admiten
estos discos, así como solo series de máquinas virtuales específicas. Consulte el ámbito y las limitaciones de la
disponibilidad general de los discos Ultra .
Registro de la característica en vista previa (GB ) EnableUltraSSD
Para crear un clúster de AKS o un grupo de nodos que pueda aprovechar los discos Ultra, debe habilitar la
marca de la característica EnableUltraSSD en la suscripción.
Registro de EnableUltraSSD la marca de característica con el comando de característica de registro az, tal como
se muestra en el siguiente ejemplo:
az feature register --namespace "Microsoft.ContainerService" --name "EnableUltraSSD"
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/EnableUltraSSD')].

Cuando todo esté listo, actualice el registro del proveedor de recursos Microsoft.ContainerService con el

IMPORTANT

Para crear un clúster de AKS o un grupo de nodos que pueda usar discos Ultra, necesita la extensión de la CLI
aks-preview más reciente. Instale la extensión de la CLI de Azure aks-preview con el comando az extension add
o instale las actualizaciones disponibles con el comando az extension update:

Limitaciones
Consulte el ámbito y las limitaciones de la disponibilidad general de los discos Ultra
El intervalo de tamaño admitido para los discos Ultra está comprendido entre 100 y 1500
Creación de un nuevo clúster que pueda usar discos Ultra

Cree un clúster de AKS que pueda aprovechar los discos Ultra mediante los siguientes comandos de la CLI. Use
la marca --aks-custom-headers para establecer la característica EnableUltraSSD .
Crear un grupo de recursos de Azure:

az group create --name myResourceGroup --location westus2
Cree el clúster de AKS con compatibilidad con Ultra Disks.
# Create an AKS-managed Azure AD cluster

az aks create -g MyResourceGroup -n MyManagedCluster -l westus2 --node-vm-size Standard_L8s_v2 --zones 1 2 -
-node-count 2 --aks-custom-headers EnableUltraSSD=true
Si desea crear clústeres sin la compatibilidad con disco Ultra, puede omitir el parámetro --aks-custom-headers
personalizado para hacerlo.
Habilitación de discos Ultra en un clúster existente

Puede habilitar los discos Ultra en clústeres existentes agregando un nuevo grupo de nodos al clúster que
admitan discos Ultra. Configure un nuevo grupo de nodos para usar Ultra Disks mediante la marca
--aks-custom-headers .
az aks nodepool add --name ultradisk --cluster-name myAKSCluster --resource-group myResourceGroup --node-vm-
size Standard_L8s_v2 --zones 1 2 --node-count 2 --aks-custom-headers EnableUltraSSD=true
Si desea crear grupos de nodos nuevos sin compatibilidad con los discos Ultra, puede hacerlo omitiendo el
parámetro --aks-custom-headers personalizado.
Uso de discos Ultra dinámicamente con una clase de almacenamiento

Para usar discos Ultra en nuestras implementaciones o conjuntos con estado, puede usar una clase de
almacenamiento para el aprovisionamiento dinámico.
Creación de la clase de almacenamiento
con un volumen persistente. Para más información sobre las clases de almacenamiento de Kubernetes, consulte
las clases de almacenamiento de Kubernetes.
En este caso, vamos a crear una clase de almacenamiento que haga referencia a discos Ultra. Cree un archivo
denominado azure-ultra-disk-sc.yaml y cópielo en el siguiente código manifiesto.
kind: StorageClass
metadata:
name: ultra-disk-sc
volumeBindingMode: WaitForFirstConsumer # optional, but recommended if you want to wait until the pod that
will use this disk is created
parameters:
skuname: UltraSSD_LRS
kind: managed
cachingmode: None
diskIopsReadWrite: "2000" # minimum value: 2 IOPS/GiB
diskMbpsReadWrite: "320" # minimum value: 0.032/GiB
Cree la clase de almacenamiento con el comando kubectl apply y especifique su archivo azure-ultra-disk-
sc.yaml:
$ kubectl apply -f azure-ultra-disk-sc.yaml
storageclass.storage.k8s.io/ultra-disk-sc created

Una notificación de volumen persistente (PVC) se usa para aprovisionar automáticamente el almacenamiento en
función de una clase de almacenamiento. En este caso, un PVC puede usar la clase de almacenamiento creada
anteriormente para crear un disco Ultra.
Cree un archivo denominado azure-ultra-disk-pvc.yaml y cópielo en el siguiente código manifiesto. La
notificación solicita un disco llamado ultra-disk que tiene un tamaño de 1000 GB con acceso ReadWriteOnce.
La clase de almacenamiento ultra-disk-sc se especifica como la clase de almacenamiento.
apiVersion: v1
metadata:
name: ultra-disk
spec:
accessModes:
- ReadWriteOnce
storageClassName: ultra-disk-sc
resources:
requests:
storage: 1000Gi
Cree la notificación del volumen persistente con el comando kubectl apply y especifique su archivo azure-ultra-
disk-pvc.yaml:
$ kubectl apply -f azure-ultra-disk-pvc.yaml
persistentvolumeclaim/ultra-disk created

Una vez que se haya creado la notificación de volumen persistente y tras el aprovisionamiento correcto del
disco, se puede crear un pod con acceso al disco. El siguiente manifiesto crea un pod NGINX básico que utiliza la
notificación de volumen persistente denominada ultra-disk para montar el disco de Azure en la ruta de acceso
/mnt/azure .
Cree un archivo denominado nginx-ultra.yaml y cópielo en el siguiente código manifiesto.
kind: Pod
apiVersion: v1
metadata:
name: nginx-ultra
spec:
containers:
- name: nginx-ultra
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
volumeMounts:
name: volume
volumes:
- name: volume
claimName: ultra-disk
$ kubectl apply -f nginx-ultra.yaml
pod/nginx-ultra created
Ahora tiene un pod en ejecución con el disco de Azure montado en el directorio /mnt/azure . Esta configuración
puede verse al examinar el pod mediante kubectl describe pod nginx-ultra , tal y como se muestra en el
siguiente ejemplo reducido:
$ kubectl describe pod nginx-ultra
[...]
Volumes:
volume:
ClaimName: azure-managed-disk
ReadOnly: false
default-token-smm2n:
SecretName: default-token-smm2n
Optional: false
[...]
Events:
---- ------ ---- ---- -------
volume "default-token-smm2n"
volume "pvc-faf0f176-8b8d-11e8-923b-deb28c58d242"
[...]
Pasos siguientes
Para más información sobre los discos ultra, consulte Uso de discos Ultra de Azure.
Para más información sobre los procedimientos recomendados, consulte Procedimientos recomendados
para el almacenamiento y las copias de seguridad en Azure Kubernetes Service (AKS).
Habilitar los controladores de interfaz de
almacenamiento de contenedores (CSI) para discos
de Azure y Azure Files en Azure Kubernetes Service
(AKS) (versión preliminar)
La interfaz de almacenamiento de contenedores (CSI) es un estándar para exponer sistemas de almacenamiento

de archivos y bloques arbitrarios a cargas de trabajo en contenedores en Kubernetes. Gracias a la adopción y al
uso de CSI, Azure Kubernetes Service (AKS) puede escribir, implementar e iterar complementos para exponer
nuevos sistemas de almacenamiento o mejorar los existentes en Kubernetes sin tener que tocar el código
principal de Kubernetes ni esperar a sus ciclos de versión.
La compatibilidad con el controlador de almacenamiento CSI en AKS permite el uso nativo de:
Discos de Azure, que se pueden usar para crear un recurso DataDisk de Kubernetes. Los discos de Azure
pueden usar Azure Premium Storage, respaldado por SSD de alto rendimiento, o bien Azure Standard
Storage, respaldado por HHD normales o SSD estándar. Para la mayoría de las cargas de trabajo de
producción y desarrollo, utilice Premium Storage. Los discos de Azure se montan como ReadWriteOnce, por
lo que solo están disponibles para un único pod. Para los volúmenes de almacenamiento a los que pueden
acceder varios pods simultáneamente, use Azure Files.
Azure Files, que se puede usar para montar un recurso compartido de SMB 3.0 respaldado por una cuenta de
Azure Storage en los pods. Con Azure Files, puede compartir datos entre varios nodos y pods. Azure Files
puede usar Azure Standard Storage respaldado por HDD normales, o bien Azure Premium Storage
respaldado por SSD de alto rendimiento.
IMPORTANT
A partir de la versión 1.21 de Kubernetes, Kubernetes solo usará controladores CSI de forma predeterminada. Estos
controladores son el futuro de la compatibilidad con el almacenamiento en Kubernetes.
Los controladores en árbol hacen referencia a los controladores de almacenamiento actuales que forman parte del código
principal de Kubernetes frente a los nuevos controladores CSI, que son complementos.
Limitaciones
Esta característica solo se puede establecer durante el momento de la creación del clúster.
La versión mínima secundaria de Kubernetes compatible con los controladores CSI es la 1.17.
Durante la versión preliminar, la clase de almacenamiento predeterminada seguirá siendo la misma clase de
almacenamiento en árbol. Una vez que esta característica esté disponible con carácter general, la clase de
almacenamiento predeterminada será la clase de almacenamiento managed-csi , y se quitarán las clases de
almacenamiento en árbol.
Durante la primera fase de la versión preliminar, solo se admite la CLI de Azure.
IMPORTANT
Registro de la característica en vista previa (GB ) EnableAzureDiskFileCSIDriver
Para crear un clúster de AKS que pueda usar controladores CSI para los discos de Azure y Azure Files, debe
habilitar la marca de la característica EnableAzureDiskFileCSIDriver en la suscripción.
Registre la marca de la característica EnableAzureDiskFileCSIDriver con el comando az feature register, como se
muestra en el siguiente ejemplo:
az feature register --namespace "Microsoft.ContainerService" --name "EnableAzureDiskFileCSIDriver"
az feature list -o table --query "[?contains(name,

'Microsoft.ContainerService/EnableAzureDiskFileCSIDriver')].{Name:name,State:properties.state}"
IMPORTANT

Para crear un clúster de AKS o un grupo de nodos que pueda usar los controladores de almacenamiento CSI,
necesita la extensión de la CLI de Azure aks-preview . Instale la extensión de la CLI de Azure aks-preview
mediante el comando az extension add. También puede instalar las actualizaciones disponibles mediante el
comando az extension update.
Creación de un clúster que pueda usar controladores de

almacenamiento CSI
Cree un clúster que pueda usar controladores de almacenamiento CSI para discos de Azure y Azure Files
mediante los siguientes comandos de la CLI. Use la marca --aks-custom-headers para establecer la característica
EnableAzureDiskFileCSIDriver .

az group create --name myResourceGroup --location canadacentral
Cree el clúster de AKS con compatibilidad con controladores de almacenamiento CSI:

az aks create -g MyResourceGroup -n MyManagedCluster --network-plugin azure --aks-custom-headers
EnableAzureDiskFileCSIDriver=true
Si desea crear clústeres en los controladores de almacenamiento en árbol en lugar de los controladores de
almacenamiento CSI, puede hacerlo omitiendo el parámetro personalizado --aks-custom-headers .
Compruebe cuántos volúmenes basados en disco de Azure puede conectar a este nodo mediante la ejecución
de:
$ kubectl get nodes

aks-nodepool1-25371499-vmss000000
$ echo $(kubectl get CSINode <NODE NAME> -o jsonpath="{.spec.drivers[1].allocatable.count}")

8
Pasos siguientes
Para usar el controlador CSI para discos de Azure, vea Uso de discos de Azure con controladores CSI.
Para usar el controlador CSI para Azure Files, vea Uso de Azure Files con controladores CSI.
para el almacenamiento y las copias de seguridad en Azure Kubernetes Service.
Uso de los controladores de interfaz de
almacenamiento de contenedores (CSI) para discos
de Azure en Azure Kubernetes Service (AKS)
(versión preliminar)
Un controlador de interfaz de almacenamiento de contenedores (CSI) para discos de Azure es un controlador

compatible con la especificación CSI que usa Azure Kubernetes Service (AKS) para administrar el ciclo de vida de
los discos de Azure.
CSI es un estándar para exponer sistemas de almacenamiento de archivos y bloques arbitrarios a cargas de
trabajo en contenedores en Kubernetes. Gracias a la adopción y al uso de CSI, AKS puede escribir, implementar e
iterar complementos para exponer nuevos sistemas de almacenamiento o mejorar los existentes en Kubernetes
sin tener que tocar el código principal de Kubernetes ni esperar a sus ciclos de versión.
Para crear un clúster de AKS con compatibilidad con controladores CSI, vea Habilitación de controladores de
almacenamiento CSI para discos de Azure y Azure Files en AKS.
NOTE
Uso de volúmenes persistentes de CSI con discos de Azure

Un volumen persistente (PV) representa un fragmento de almacenamiento aprovisionado para su uso con pods
de Kubernetes. Un PV puede usarse en uno o varios pods y puede aprovisionarse de forma dinámica o estática.
En este artículo se muestra cómo crear PV de forma dinámica con discos de Azure para usarlos en un solo pod
de un clúster de AKS. En el caso del aprovisionamiento estático, vea Creación manual y uso de un volumen con
discos de Azure.
IMPORTANT
Creación dinámica de PV para discos de Azure mediante las clases de

almacenamiento integradas
con un volumen persistente. Para obtener más información sobre las clases de almacenamiento de Kubernetes,
vea Clases de almacenamiento de Kubernetes. Cuando se usan controladores de CSI de almacenamiento en
AKS, hay dos StorageClasses integradas adicionales que usan los controladores de almacenamiento de CSI para
discos de Azure. Las clases de almacenamiento de CSI adicionales se crean con el clúster junto con las clases de
almacenamiento predeterminadas en árbol.
managed-csi : usa almacenamiento con redundancia local (LRS) SSD estándar de Azure para crear un disco
administrado.
managed-csi-premium : usa LRS Premium de Azure para crear un disco administrado.
La directiva de recuperación de ambas clases de almacenamiento garantiza que el disco de Azure subyacente se
elimine cuando se elimine el PV correspondiente. Las clases de almacenamiento también configuran los PV de
modo que se puedan expandir. Solo tiene que editar la notificación de volumen persistente (PVC) con el nuevo
tamaño.
Para aprovechar estas clases de almacenamiento, cree una PVC y el pod correspondiente que haga referencia a
ellas y las use. Una PVC se usa para aprovisionar automáticamente el almacenamiento en función de una clase
de almacenamiento. Una PVC puede usar una de las clases de almacenamiento creadas previamente o una clase
de almacenamiento definida por el usuario para crear un disco administrado de Azure para el tamaño y el SKU
deseados. Cuando se crea una definición de pod, se especifica la PVC para solicitar el almacenamiento deseado.
Cree un pod de ejemplo y la PVC respectiva con el comando kubectl apply:
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-

driver/master/deploy/example/pvc-azuredisk-csi.yaml
driver/master/deploy/example/nginx-pod-azuredisk.yaml
persistentvolumeclaim/pvc-azuredisk created
pod/nginx-azuredisk created
Una vez que el pod esté en ejecución, cree un nuevo archivo denominado test.txt .
$ kubectl exec nginx-azuredisk -- touch /mnt/azuredisk/test.txt
Ahora puede comprobar que el disco se ha montado correctamente; para ello, ejecute el siguiente comando y
compruebe que ve el archivo test.txt en la salida:
$ kubectl exec nginx-azuredisk -- ls /mnt/azuredisk
lost+found
outfile
test.txt
Creación de una clase de almacenamiento personalizada

Las clases de almacenamiento predeterminadas se adaptan a los escenarios más comunes, pero no a todos. En
algunos casos, puede que quiera tener una clase de almacenamiento propia personalizada con sus propios
parámetros. Por ejemplo, hay un escenario en el que es posible que quiera cambiar la clase volumeBindingMode .
Puede usar una clase volumeBindingMode: Immediate que garantiza su ejecución inmediatamente después de
crear la PVC. En los casos en los que los grupos de nodos tienen restricciones de topología (por ejemplo,
mediante zonas de disponibilidad), los PV se enlazarían o aprovisionarían sin conocimiento de los requisitos de
programación del pod (en este caso, estar en una zona determinada).
Para resolver este escenario, puede usar volumeBindingMode: WaitForFirstConsumer , que retrasa el enlace y el
aprovisionamiento de un PV hasta que se crea un pod que usa la PVC. De esta manera, el PV se ajusta a la zona
de disponibilidad (u otra topología) especificada mediante las restricciones de programación del pod y se
aprovisiona en ella. Las clases de almacenamiento predeterminadas usan la clase
volumeBindingMode: WaitForFirstConsumer .
Cree un archivo denominado sc-azuredisk-csi-waitforfirstconsumer.yaml y pegue el siguiente manifiesto. La

clase de almacenamiento es la misma que la clase de almacenamiento managed-csi , pero con una clase
volumeBindingMode diferente.
kind: StorageClass
metadata:
name: azuredisk-csi-waitforfirstconsumer
provisioner: disk.csi.azure.com
parameters:
skuname: StandardSSD_LRS
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
Cree la clase de almacenamiento con el comando kubectl apply y especifique el archivo

sc-azuredisk-csi-waitforfirstconsumer.yaml :
$ kubectl apply -f sc-azuredisk-csi-waitforfirstconsumer.yaml
storageclass.storage.k8s.io/azuredisk-csi-waitforfirstconsumer created
Instantáneas de volumen
El controlador de CSI para discos de Azure admite la creación de instantáneas de volúmenes persistentes. Como
parte de esta capacidad, el controlador puede realizar instantáneas incrementales o completas en función del
valor establecido en el parámetro incremental (de manera predeterminada, es true).
Para obtener detalles sobre todos los parámetros, vea parámetros de clase de instantánea de volumen.
Creación de una instantánea de volumen
Para obtener un ejemplo de esta capacidad, cree una clase de instantánea de volumen con el comando kubectl
apply:

driver/master/deploy/example/snapshot/storageclass-azuredisk-snapshot.yaml
volumesnapshotclass.snapshot.storage.k8s.io/csi-azuredisk-vsc created
Ahora vamos a crear una instantánea de volumen de la PVC creada dinámicamente al principio de este tutorial,
pvc-azuredisk .

driver/master/deploy/example/snapshot/azuredisk-volume-snapshot.yaml
volumesnapshot.snapshot.storage.k8s.io/azuredisk-volume-snapshot created
Compruebe que la instantánea se ha creado correctamente:
$ kubectl describe volumesnapshot azuredisk-volume-snapshot
Name: azuredisk-volume-snapshot
Namespace: default
Labels: <none>
Annotations: API Version: snapshot.storage.k8s.io/v1beta1
Kind: VolumeSnapshot
Metadata:
Creation Timestamp: 2020-08-27T05:27:58Z
Finalizers:
snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
Generation: 1
Resource Version: 714582
Self Link: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/azuredisk-
volume-snapshot
UID: dd953ab5-6c24-42d4-ad4a-f33180e0ef87
Spec:
Source:
Persistent Volume Claim Name: pvc-azuredisk
Volume Snapshot Class Name: csi-azuredisk-vsc
Status:
Bound Volume Snapshot Content Name: snapcontent-dd953ab5-6c24-42d4-ad4a-f33180e0ef87
Creation Time: 2020-08-31T05:27:59Z
Ready To Use: true
Restore Size: 10Gi
Events: <none>
Creación de una nueva PVC basada en una instantánea de volumen

Puede crear una nueva PVC basada en una instantánea de volumen. Use la instantánea creada en el paso
anterior y cree una nueva PVC y un nuevo pod para consumirla.

driver/master/deploy/example/snapshot/pvc-azuredisk-snapshot-restored.yaml

driver/master/deploy/example/snapshot/nginx-pod-restored-snapshot.yaml
persistentvolumeclaim/pvc-azuredisk-snapshot-restored created
pod/nginx-restored created
Por último, vamos a asegurarnos de que es la misma PVC creada antes; para ello, se comprueba el contenido.
$ kubectl exec nginx-restored -- ls /mnt/azuredisk
lost+found
outfile
test.txt
Como era de esperar, todavía se puede ver el archivo test.txt creado anteriormente.
Clonación de volúmenes
Un volumen clonado se define como un duplicado de un volumen de Kubernetes existente. Para obtener más
información sobre la clonación de volúmenes en Kubernetes, vea la documentación conceptual sobre clonación
de volúmenes.
El controlador de CSI para discos de Azure admite la clonación de volúmenes. Para demostrarlo, cree un
volumen clonado de la azuredisk-pvc creada anteriormente y un nuevo pod para consumirla.

driver/master/deploy/example/cloning/pvc-azuredisk-cloning.yaml

driver/master/deploy/example/cloning/nginx-pod-restored-cloning.yaml
persistentvolumeclaim/pvc-azuredisk-cloning created
pod/nginx-restored-cloning created
Ahora se puede comprobar el contenido del volumen clonado mediante la ejecución del siguiente comando y la
confirmación de que todavía se ve el archivo creado test.txt .
$ kubectl exec nginx-restored-cloning -- ls /mnt/azuredisk
lost+found
outfile
test.txt
Cambio de tamaño de un volumen persistente

También puede solicitar un volumen mayor para una PVC. Edite el objeto PVC y especifique un tamaño mayor.
Este cambio desencadena la expansión del volumen subyacente que respalda el PV.
NOTE
Nunca se crea un PV para satisfacer la notificación, sino que se cambia el tamaño de un volumen existente.
En AKS, la clase de almacenamiento managed-csi integrada ya permite la expansión, así que use la PVC creada
anteriormente con esta clase de almacenamiento. La PVC ha solicitado un volumen persistente de 10 GB. Eso se
puede confirmar mediante la ejecución de:
$ kubectl exec -it nginx-azuredisk -- df -h /mnt/azuredisk

/dev/sdc 9.8G 42M 9.8G 1% /mnt/azuredisk
IMPORTANT
Actualmente, el controlador de CSI para discos de Azure solo admite el cambio de tamaño de PVC sin ningún pod
asociado (y cuyo volumen no esté montado en un nodo específico).
Por lo tanto, vamos a eliminar el pod creado anteriormente:
$ kubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-

pod "nginx-azuredisk" deleted
Vamos a expandir la PVC mediante el aumento del campo spec.resources.requests.storage :

$ kubectl patch pvc pvc-azuredisk --type merge --patch '{"spec": {"resources": {"requests": {"storage":
"15Gi"}}}}'
persistentvolumeclaim/pvc-azuredisk patched
Vamos a confirmar que el volumen ahora es más grande:
$ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM

STORAGECLASS REASON AGE
pvc-391ea1a6-0191-4022-b915-c8dc4216174a 15Gi RWO Delete Bound default/pvc-
azuredisk managed-csi 2d2h
(...)
NOTE
La PVC no refleja el nuevo tamaño hasta que tiene un pod asociado de nuevo.
Vamos a crear un nuevo pod:

pod/nginx-azuredisk created
Por último, confirme el tamaño de la PVC y dentro del pod:
$ kubectl get pvc pvc-azuredisk

AGE
pvc-azuredisk Bound pvc-391ea1a6-0191-4022-b915-c8dc4216174a 15Gi RWO managed-csi
2d2h
$ kubectl exec -it nginx-azuredisk -- df -h /mnt/azuredisk

/dev/sdc 15G 46M 15G 1% /mnt/azuredisk
Disco compartido
Los discos compartidos de Azure son una característica de Azure Managed Disks que permite asociar un disco
de Azure a nodos de agente simultáneamente. Si asocia un disco administrado a varios nodos de agente, podrá
implementar nuevas aplicaciones en clúster o migrar las existentes a Azure.
IMPORTANT
Actualmente, el controlador CSI para discos de Azure solo admite el dispositivo de bloque sin formato (
volumeMode: Block ). Las aplicaciones deben administrar la coordinación y el control de las escrituras, lecturas, bloqueos,
cachés, montajes y barreras en el disco compartido, que se expone como un dispositivo de bloque sin formato.
Vamos a crear un archivo llamado shared-disk.yaml copiando el siguiente comando que contiene la clase de
almacenamiento en disco compartido y el PVC:
kind: StorageClass
metadata:
name: managed-csi-shared
provisioner: disk.csi.azure.com
parameters:
skuname: Premium_LRS # Currently shared disk is only available with premium SSD
maxShares: "2"
cachingMode: None # ReadOnly cache is not available for premium SSD with maxShares>1
---
apiVersion: v1
metadata:
name: pvc-azuredisk-shared
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 256Gi # minimum size of shared disk is 256GB (P15)
volumeMode: Block
storageClassName: managed-csi-shared
Cree la clase de almacenamiento con el comando kubectl apply y especifique el archivo shared-disk.yaml :
$ kubectl apply -f shared-disk.yaml
storageclass.storage.k8s.io/managed-csi-shared created
persistentvolumeclaim/pvc-azuredisk-shared created
Ahora vamos a crear un archivo llamado deployment-shared.yml copiando el comando siguiente:
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: deployment-azuredisk
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
name: deployment-azuredisk
spec:
containers:
- name: deployment-azuredisk
volumeDevices:
- name: azuredisk
devicePath: /dev/sdx
volumes:
- name: azuredisk
claimName: pvc-azuredisk-shared
Cree la implementación con el comando kubectl apply y especifique el archivo deployment-shared.yml :

$ kubectl apply -f deployment-shared.yml
deployment/deployment-azuredisk created
Por último, vamos a comprobar el dispositivo de bloqueo dentro del pod:
# kubectl exec -it deployment-sharedisk-7454978bc6-xh7jp sh

/ # dd if=/dev/zero of=/dev/sdx bs=1024k count=100
100+0 records in
100+0 records out/s
Contenedores de Windows
El controlador de CSI para discos de Azure también admite nodos y contenedores de Windows. Si quiere usar
contenedores de Windows, siga el tutorial sobre contenedores de Windows para agregar un grupo de nodos de
Windows.
Una vez que tenga un grupo de nodos de Windows, puede usar las clases de almacenamiento integradas como
managed-csi . Puede implementar un conjunto con estado basado en Windows de ejemplo que guarde marcas
de tiempo en el archivo data.txt mediante la implementación del comando siguiente con el comando kubectl
apply:

driver/master/deploy/example/windows/statefulset.yaml
statefulset.apps/busybox-azuredisk created
Ahora puede validar el contenido del volumen mediante la ejecución de:
$ kubectl exec -it busybox-azuredisk-0 -- cat c:\\mnt\\azuredisk\\data.txt # on Linux/MacOS Bash

$ kubectl exec -it busybox-azuredisk-0 -- cat c:\mnt\azuredisk\data.txt # on Windows Powershell/CMD
2020-08-27 08:13:41Z
2020-08-27 08:13:42Z
2020-08-27 08:13:44Z
(...)
Pasos siguientes
Para obtener información sobre cómo usar controladores de CSI para Azure Files, vea Uso de Azure Files con
controladores de CSI.
Para obtener más información sobre los procedimientos recomendados de almacenamiento, vea
Procedimientos recomendados para el almacenamiento y las copias de seguridad en
Uso de los controladores de interfaz de
almacenamiento de contenedores (CSI) de Azure
Files en Azure Kubernetes Service (AKS) (versión
preliminar)
Un controlador de interfaz de almacenamiento de contenedores (CSI) de Azure Files es un controlador

compatible con la especificación CSI que usa Azure Kubernetes Service (AKS) para administrar el ciclo de vida de
los recursos compartidos de Azure Files.
CSI es un estándar para exponer sistemas de almacenamiento de archivos y bloques arbitrarios a cargas de
trabajo en contenedores en Kubernetes. Gracias a la adopción y al uso de CSI, AKS ahora puede escribir,
implementar e iterar complementos para exponer nuevos sistemas de almacenamiento o mejorar los existentes
en Kubernetes sin tener que tocar el código principal de Kubernetes ni esperar a sus ciclos de versión.
Para crear un clúster de AKS con compatibilidad con controladores CSI, vea Habilitación de controladores de
almacenamiento CSI para discos de Azure y Azure Files en AKS.
NOTE
Uso de un volumen persistente con Azure Files

Un volumen persistente (PV) representa un fragmento de almacenamiento aprovisionado para su uso con pods
de Kubernetes. Un PV puede usarse en uno o varios pods y puede aprovisionarse de forma dinámica o estática.
Si varios pods necesitan acceso simultáneo al mismo volumen de almacenamiento, puede usar Azure Files para
conectarse mediante el protocolo Bloque de mensajes del servidor (SMB). En este artículo se muestra cómo
crear dinámicamente un recurso compartido de Azure Files para que lo usen varios pods en un clúster de AKS.
En el caso del aprovisionamiento estático, vea Creación manual y uso de un volumen con un recurso
compartido de Azure Files.
IMPORTANT
Creación dinámica de PV para Azure Files mediante las clases de
almacenamiento integradas
Una clase de almacenamiento se utiliza para definir cómo se crea un recurso compartido de Azure Files. En el
grupo de recursos de nodo, se crea automáticamente una cuenta de almacenamiento para utilizarla con la clase
de almacenamiento para guardar los recursos compartidos de Azure Files. Seleccione una de las siguientes SKU
de redundancia de Azure Storage para skuName:
Standard_LRS : almacenamiento con redundancia local estándar
Standard_GRS : almacenamiento con redundancia geográfica estándar
Standard_ZRS : almacenamiento con redundancia de zona
Standard_RAGRS : almacenamiento con redundancia geográfica con acceso de lectura estándar
Premium_LRS : almacenamiento con redundancia local prémium
NOTE
Azure Files es compatible con Azure Premium Storage. El recurso compartido de archivos prémium mínimo es de 100 GB.
Cuando se usan controladores CSI de almacenamiento en AKS, hay dos clases StorageClasses integradas
adicionales que usan los controladores de almacenamiento CSI para Azure Files. Las clases de almacenamiento
de CSI adicionales se crean con el clúster junto con las clases de almacenamiento predeterminadas en árbol.
azurefile-csi : usa Azure Standard Storage para crear un recurso compartido de Azure Files.
azurefile-csi-premium : usa Azure Premium Storage para crear un recurso compartido de Azure Files.
La directiva de recuperación de ambas clases de almacenamiento garantiza que el recurso compartido de Azure
Files subyacente se elimine cuando se elimine el PV correspondiente. Las clases de almacenamiento también
configuran los recursos compartidos de archivo para que se puedan expandir; solo es necesario editar la
notificación de volumen persistente (PVC) con el nuevo tamaño.
Para usar estas clases de almacenamiento, cree una PVC y el pod correspondiente que haga referencia a ellas y
las use. Una PVC se usa para aprovisionar automáticamente el almacenamiento en función de una clase de
almacenamiento. Una PVC puede usar una de las clases de almacenamiento creadas previamente o una clase de
almacenamiento definida por el usuario para crear un recurso compartido de Azure Files para el tamaño y la
SKU deseados. Cuando se crea una definición de pod, se especifica la PVC para solicitar el almacenamiento
deseado.
Cree una PVC y un pod de ejemplo que imprima la fecha actual en un elemento outfile con el comando
kubectl apply:
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-

driver/master/deploy/example/pvc-azurefile-csi.yaml
driver/master/deploy/example/nginx-pod-azurefile.yaml
persistentvolumeclaim/pvc-azurefile created
pod/nginx-azurefile created
Una vez que el pod esté en estado de ejecución, puede comprobar si el recurso compartido de archivos está
montado correctamente con la ejecución del siguiente comando y la verificación de que la salida contiene el
elemento outfile :
$ kubectl exec nginx-azurefile -- ls -l /mnt/azurefile
total 29
-rwxrwxrwx 1 root root 29348 Aug 31 21:59 outfile
Creación de una clase de almacenamiento personalizada

Las clases de almacenamiento predeterminadas se adaptan a los escenarios más comunes, pero no a todos. En
algunos casos, puede que quiera tener una clase de almacenamiento propia personalizada con sus propios
parámetros. Por ejemplo, use el siguiente manifiesto para configurar el parámetro mountOptions del recurso
compartido de archivos.
El valor predeterminado de fileMode y dirMode es 0777 para los recurso compartido de archivos montados en
Kubernetes. Puede especificar las diferentes opciones de montaje en el objeto de clase de almacenamiento.
Cree un archivo denominado azure-file-sc.yaml y pegue el siguiente manifiesto de ejemplo:
kind: StorageClass
metadata:
name: my-azurefile
provisioner: file.csi.azure.com
volumeBindingMode: Immediate
allowVolumeExpansion: true
mountOptions:
- dir_mode=0640
- file_mode=0640
- uid=0
- gid=0
- mfsymlinks
- cache=strict # https://linux.die.net/man/8/mount.cifs
- nosharesock
parameters:
Cree la clase de almacenamiento con el comando kubectl apply:
kubectl apply -f azure-file-sc.yaml
storageclass.storage.k8s.io/my-azurefile created
El controlador de CSI para Azure Files admite la creación de instantáneas de volúmenes persistentes y los
recursos compartidos de archivo subyacentes.
Cree una clase de instantánea de volumen con el comando kubectl apply:

driver/master/deploy/example/snapshot/volumesnapshotclass-azurefile.yaml
volumesnapshotclass.snapshot.storage.k8s.io/csi-azurefile-vsc created
Cree una instantánea de volumen de la PVC creada dinámicamente al principio de este tutorial, pvc-azurefile .
driver/master/deploy/example/snapshot/volumesnapshot-azurefile.yaml
volumesnapshot.snapshot.storage.k8s.io/azurefile-volume-snapshot created
Compruebe que la instantánea se ha creado correctamente:
$ kubectl describe volumesnapshot azurefile-volume-snapshot
Name: azurefile-volume-snapshot
Namespace: default
Labels: <none>
Annotations: API Version: snapshot.storage.k8s.io/v1beta1
Kind: VolumeSnapshot
Metadata:
Creation Timestamp: 2020-08-27T22:37:41Z
Finalizers:
snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
Generation: 1
Resource Version: 955091
Self Link: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/azurefile-
volume-snapshot
UID: c359a38f-35c1-4fb1-9da9-2c06d35ca0f4
Spec:
Source:
Persistent Volume Claim Name: pvc-azurefile
Volume Snapshot Class Name: csi-azurefile-vsc
Status:
Bound Volume Snapshot Content Name: snapcontent-c359a38f-35c1-4fb1-9da9-2c06d35ca0f4
Ready To Use: false
Events: <none>
Cambio de tamaño de un volumen persistente

Puede solicitar un volumen mayor para una PVC. Edite el objeto PVC y especifique un tamaño mayor. Este
cambio desencadena la expansión del volumen subyacente que respalda el PV.
NOTE
Nunca se crea un PV para satisfacer la notificación, sino que se cambia el tamaño de un volumen existente.
En AKS, la clase de almacenamiento azurefile-csi integrada ya permite la expansión, así que use la PVC creada
anteriormente con esta clase de almacenamiento. La PVC solicitó un recurso compartido de archivos 100Gi. Eso
se puede confirmar mediante la ejecución de:
$ kubectl exec -it nginx-azurefile -- df -h /mnt/azurefile
Filesystem Size Used Avail

Use% Mounted on
//f149b5a219bd34caeb07de9.file.core.windows.net/pvc-5e5d9980-da38-492b-8581-17e3cad01770 100G 128K 100G
1% /mnt/azurefile
Expanda la PVC mediante el aumento del campo spec.resources.requests.storage :

$ kubectl patch pvc pvc-azurefile --type merge --patch '{"spec": {"resources": {"requests": {"storage":
"200Gi"}}}}'
persistentvolumeclaim/pvc-azurefile patched
Compruebe que tanto la PVC como el sistema de archivos dentro del pod muestran el nuevo tamaño:
$ kubectl get pvc pvc-azurefile

AGE
pvc-azurefile Bound pvc-5e5d9980-da38-492b-8581-17e3cad01770 200Gi RWX azurefile-csi
64m
$ kubectl exec -it nginx-azurefile -- df -h /mnt/azurefile

Filesystem Size Used Avail
Use% Mounted on
//f149b5a219bd34caeb07de9.file.core.windows.net/pvc-5e5d9980-da38-492b-8581-17e3cad01770 200G 128K 200G
1% /mnt/azurefile
Recursos compartidos de archivos NFS

Azure Files ahora es compatible con el protocolo NFS v. 4.1. La compatibilidad con NFS 4.1 de Azure Files
proporciona un sistema de archivos NFS totalmente administrado como un servicio basado en una plataforma
de almacenamiento resistente distribuida de alta disponibilidad y alta durabilidad.
Esta opción está optimizada para cargas de trabajo de acceso aleatorio con actualizaciones de datos en contexto
y proporciona compatibilidad completa con el sistema de archivos POSIX. En esta sección se muestra cómo usar
recursos compartidos de archivos NFS con el controlador CSI de Azure Files en un clúster de AKS.
Asegúrese de comprobar las limitaciones y la disponibilidad de las regiones durante la fase de versión
preliminar.
Registro de la característica en vista previa (GB ) AllowNfsFileShares
Para crear un recurso compartido de archivos que aprovecha NFS 4.1, debe habilitar la marca de características
AllowNfsFileShares en su suscripción.
Registre la marca de la característica AllowNfsFileShares con el comando az feature register, como se muestra
az feature register --namespace "Microsoft.Storage" --name "AllowNfsFileShares"
az feature list -o table --query "[?contains(name, 'Microsoft.Storage/AllowNfsFileShares')].

az provider register --namespace Microsoft.Storage
Creación de una cuenta de almacenamiento para el recurso compartido de archivos NFS

Cree una cuenta de almacenamiento de Azure Premium_LRS con las siguientes configuraciones para admitir
recursos compartidos de archivos NFS:
Tipo de cuenta: FileStorage
Se requiere transferencia segura (habilite solo el tráfico HTTPS): false.
Seleccione la red virtual de los nodos de agente en firewalls y redes virtuales, por lo que es posible que
prefiera crear la cuenta de almacenamiento en el grupo MC_resource.
Creación de una clase de almacenamiento de recursos compartidos de archivos NFS
Guarde un archivo nfs-sc.yaml con el manifiesto siguiente editando los respectivos marcadores de posición.
kind: StorageClass
metadata:
name: azurefile-csi-nfs
provisioner: file.csi.azure.com
parameters:
resourceGroup: EXISTING_RESOURCE_GROUP_NAME # optional, required only when storage account is not in the
same resource group as your agent nodes
storageAccount: EXISTING_STORAGE_ACCOUNT_NAME
protocol: nfs
Después de editar y guardar el archivo, cree la clase de almacenamiento con el comando kubectl apply:
$ kubectl apply -f nfs-sc.yaml
storageclass.storage.k8s.io/azurefile-csi created
Creación de una implementación con un recurso compartido de archivos con copia de seguridad NFS
Puede implementar un conjunto con estado de ejemplo que guarde marcas de tiempo en el archivo data.txt
mediante la implementación del comando siguiente con el comando kubectl apply:

driver/master/deploy/example/statefulset.yaml
statefulset.apps/statefulset-azurefile created
Valide el contenido del volumen mediante la ejecución de:
$ kubectl exec -it statefulset-azurefile-0 -- df -h

...
/dev/sda1 29G 11G 19G
37% /etc/hosts
accountname.file.core.windows.net:/accountname/pvc-fa72ec43-ae64-42e4-a8a2-556606f5da38 100G 0 100G
0% /mnt/azurefile
...
NOTE
Tenga en cuenta que, como el recurso compartido de archivos NFS está en una cuenta Premium, el tamaño mínimo del
recurso compartido de archivos es 100 GB. Si crea un PVC con un tamaño de almacenamiento pequeño, puede que
reciba un error de tipo "No se pudo crear el recurso compartido de archivos… tamaño (5)…".
Contenedores de Windows
El controlador de CSI para Azure Files también admite nodos y contenedores de Windows. Si quiere usar
contenedores de Windows, siga el tutorial sobre contenedores de Windows para agregar un grupo de nodos de
Windows.
Una vez que tenga un grupo de nodos de Windows, puede usar las clases de almacenamiento integradas como
azurefile-csi o crear otras personalizadas. Puede implementar un conjunto con estado basado en Windows de
ejemplo que guarde marcas de tiempo en el archivo data.txt mediante la implementación del comando
siguiente con el comando kubectl apply:

driver/master/deploy/example/windows/statefulset.yaml
statefulset.apps/busybox-azurefile created
Valide el contenido del volumen mediante la ejecución de:
$ kubectl exec -it busybox-azurefile-0 -- cat c:\\mnt\\azurefile\\data.txt # on Linux/MacOS Bash

$ kubectl exec -it busybox-azurefile-0 -- cat c:\mnt\azurefile\data.txt # on Windows Powershell/CMD
2020-08-27 22:11:01Z
2020-08-27 22:11:02Z
2020-08-27 22:11:04Z
(...)
Pasos siguientes
Para obtener información sobre cómo usar controladores CSI para discos de Azure, vea Uso de discos de
Azure con controladores CSI.
para el almacenamiento y las copias de seguridad en Azure Kubernetes Service.
Uso de redes kubenet con intervalos de direcciones
IP propios en Azure Kubernetes Service (AKS)
De forma predeterminada, los clústeres de AKS usan kubenet, y una red virtual de Azure y una subred se crean
automáticamente. Con kubenet, los nodos obtienen una dirección IP de una subred de la red virtual de Azure.
Los pods reciben una dirección IP de un espacio de direcciones lógicamente distinto a la subred de red virtual
de Azure de los nodos. A continuación, se configura la traducción de direcciones de red (NAT) para que los pods
puedan acceder a los recursos en la red virtual de Azure. La dirección IP de origen del tráfico se somete a un
proceso NAT hacia la dirección IP principal del nodo. Este enfoque reduce enormemente el número de
direcciones IP que se deben reservar en el espacio de red para que los pods las usen.
Con Azure Container Networking Interface (CNI), cada pod obtiene una dirección IP de la subred, y se puede
acceder a él directamente. Estas direcciones IP deben ser únicas en el espacio de red y deben planearse de
antemano. Cada nodo tiene un parámetro de configuración para el número máximo de pods que admite. Luego,
el número equivalente de direcciones IP por nodo se reserva por adelantado para ese nodo. Este enfoque
requiere más planificación y a menudo lleva al agotamiento de direcciones IP o a la necesidad de volver a
generar los clústeres en una subred mayor, a medida que crecen las exigencias de la aplicación. Puede
configurar el número máximo de pods que se puede implementar en un nodo en el momento de la creación del
clúster o al crear nuevos grupos de nodos. Si no especifica maxPods al crear grupos de nodos nuevos, recibirá
un valor predeterminado de 110 para kubenet.
En este artículo se muestra cómo usar las redes kubenet para crear y usar la subred de una red virtual con un
clúster de AKS. Para más información sobre las opciones y consideraciones de red, consulte el artículo sobre los
conceptos de red para Kubernetes y AKS.
Requisitos previos
La red virtual del clúster AKS debe permitir la conectividad saliente de Internet.
No cree más de un clúster AKS en la misma subred.
Los clústeres de AKS no pueden usar 169.254.0.0/16 , 172.30.0.0/16 , 172.31.0.0/16 ni 192.0.2.0/24 para
el intervalo de direcciones del servicio de Kubernetes, el intervalo de direcciones de pod o el intervalo de
direcciones de la red virtual del clúster.
La identidad de clúster que usa el clúster de AKS debe tener al menos el rol de Colaborador de la red en la
subred de la red virtual. También debe tener los permisos adecuados, como propietario de la suscripción,
para crear una identidad del clúster y asignarle permisos. Si quiere definir un rol personalizado en lugar de
usar el rol integrado de colaborador de red, se requieren los permisos siguientes:
WARNING
Para usar grupos de nodos de Windows Server, es preciso utilizar Azure CNI. El uso de kubenet como modelo de red no
está disponible para contenedores de Windows Server.
Antes de empezar
Azure.
Información general sobre redes kubenet con una subred propia

En muchos entornos, ha definido subredes y redes virtuales con intervalos de direcciones IP asignados. Estos
recursos de red virtual se usan para admitir varios servicios y aplicaciones. Para proporcionar conectividad de
red, los clústeres de AKS pueden usar kubenet (redes básicas) o Azure CNI (redes avanzadas).
Con kubenet, solo los nodos reciben una dirección IP en la subred de red virtual. Los pods no pueden
comunicarse directamente entre sí. En su lugar, se usan el enrutamiento definido por el usuario (UDR) y el
reenvío de IP para la conectividad entre pods a través de los nodos. De forma predeterminada, el servicio AKS
crea y mantiene la configuración de reenvío de UDR e IP, pero tiene la opción de traer su propia tabla de rutas
para la administración personalizada de rutas. También podría implementar pods detrás de un servicio que
recibe una dirección IP asignada y equilibra la carga del tráfico de la aplicación. En el diagrama siguiente se
muestra cómo los nodos de AKS reciben una dirección IP en la subred de red virtual, pero no los pods:
Azure admite un máximo de 400 rutas en un UDR, por lo que no puede tener un clúster de AKS que tenga más
de 400 nodos. Los nodos virtuales de AKS y las directivas de red de Azure no son compatibles con kubenet.
Puede usar las directivas de red de Calico, ya que son compatibles con kubenet.
Con Azure CNI, cada pod recibe una dirección IP en la subred IP y puede comunicarse directamente con otros
pods y servicios. Los clústeres pueden ser tan grandes como el intervalo de direcciones IP que especifique. Sin
embargo, el intervalo de direcciones IP debe planearse por adelantado, y los nodos de AKS consumen todas las
direcciones IP en función del número máximo de pods que pueden admitir. Los escenarios y las características
avanzadas de red como los nodos virtuales o las directivas de red (de Azure o Calico) son compatibles con
Azure CNI.
Limitaciones y consideraciones de kubenet
El diseño de kubenet requiere un salto adicional, lo que agrega una latencia menor a la comunicación del
pod.
Para utilizar kubenet, se necesitan tablas de rutas y rutas definidas por el usuario, lo que agrega complejidad
a las operaciones.
Por su diseño, kubenet no permite el direccionamiento directo de pods.
A diferencia de los clústeres de Azure CNI, no se permite que varios clústeres de kubenet compartan una
subred.
Las características no admitidas en kubenet son:
Directivas de red de Azure, aunque sí se admiten las de Calico
Grupos de nodos de Windows
Complemento de nodos virtuales
Disponibilidad y agotamiento de las direcciones IP
Con Azure CNI, un problema común es que el intervalo de direcciones IP asignado es demasiado pequeño para
agregar nodos adicionales cuando se escala o actualiza un clúster. Puede que el equipo de red no sea capaz de
emitir un intervalo de direcciones IP lo suficientemente grande como para satisfacer las demandas esperadas de
la aplicación.
Como compromiso, puede crear un clúster de AKS que use kubenet y conectarse a una subred de red virtual
existente. Este enfoque permite que los nodos reciban direcciones IP definidas, sin necesidad de reservar un
gran número de direcciones IP por adelantado para todos los pods posibles que se podrían ejecutar en el clúster.
Con kubenet, puede usar un intervalo de direcciones IP mucho más pequeño y tener la capacidad de satisfacer
una elevada demanda de los clústeres y la aplicación. Por ejemplo, incluso con un intervalo de direcciones IP de
/27 en la subred, podría ejecutar un clúster de 20-25 nodos con espacio suficiente para escalar o actualizar. Este
tamaño de clúster admitiría hasta 2200-2750 pods (con una capacidad máxima predeterminada de 110 pods
por nodo). El número máximo de pods por nodo que se puede configurar con kubenet en AKS es 110.
Los cálculos básicos siguientes comparan la diferencia entre los modelos de red:
kubenet : un intervalo sencillo de direcciones IP de /24 puede admitir hasta 251 en el clúster (cada subred de
red virtual de Azure reserva las tres primeras direcciones IP para operaciones de administración).
Este número de nodos podría admitir hasta 27610 pods (con una capacidad máxima predeterminada
de 110 pods por nodo con kubenet).
Azure CNI : ese mismo intervalo de subred básico de /24 solo podría admitir un máximo de 8 nodos en el
clúster.
Este número de nodos podría admitir solo hasta 240 pods (con una capacidad máxima
predeterminada de 30 pods por nodo con Azure CNI).
NOTE
Estos valores máximos no tienen en cuenta las operaciones de actualización o escalado. En la práctica, no puede ejecutar
el número máximo de nodos que el intervalo de direcciones IP de la subred admite. Debe dejar algunas direcciones IP
disponibles para usarlas durante el escalado de las operaciones de actualización.
Emparejamiento de redes virtuales y conexiones de ExpressRoute

Para proporcionar conectividad en el entorno local, los dos enfoques de red kubenet y Azure-CNI pueden usar el
emparejamiento de redes virtuales de Azure o las conexiones ExpressRoute. Planee los intervalos de direcciones
IP detenidamente para evitar la superposición y un enrutamiento de tráfico incorrecto. Por ejemplo, muchas
redes locales usan un intervalo de direcciones 10.0.0.0/8 que se anuncia a través de la conexión ExpressRoute.
Es aconsejable crear los clústeres de AKS en las subredes de la red virtual de Azure fuera de este rango de
direcciones, como 172.16.0.0/16.
Selección de un modelo de red para usarlo
Elegir qué complemento de red utilizar para el clúster de AKS suele ser una cuestión de equilibrar las
necesidades de flexibilidad y configuración avanzada. Las consideraciones siguientes ayudan a indicar cuándo
puede resultar más conveniente cada modelo de red.
Use kubenet cuando:
Tenga un espacio de direcciones IP limitado.
La mayor parte de la comunicación de los pods se realice dentro del clúster.
No necesite características avanzadas de AKS como los nodos virtuales o la directiva de red de Azure. Use
directivas de red de Calico.
Use Azure CNI cuando:
Tenga espacio de direcciones IP disponible.
La mayor parte de la comunicación de los pods se realice con recursos fuera del clúster.
No desea administrar rutas definidas por el usuario para la conectividad pod.
Necesite características avanzadas de AKS como los nodos virtuales o la directiva de red de Azure. Use
directivas de red de Calico.
Para más información que le ayude a decidir qué modelo de red usar, consulte la Comparación de modelos de
red y su ámbito de soporte.
Creación de una red virtual y una subred

Para empezar a usar kubenet y su propia subred de red virtual, primero cree un grupo de recursos mediante el
comando az group create. En el ejemplo siguiente, se crea un grupo de recursos denominado myResourceGroup
en la ubicación eastus:
Si no tiene una subred y red virtual existentes para usarlas, cree estos recursos de red con el comando az
network vnet create. En el ejemplo siguiente, la red virtual se denomina myVnet y tiene el prefijo de dirección de
192.168.0.0/16. Se crea una subred llamada myAKSSubnet con el prefijo de dirección 192.168.1.0/24.

--name myAKSVnet \
Creación de una entidad de servicio y asignación de permisos

Para permitir que un clúster de AKS interactúe con otros recursos de Azure, se usa una entidad de servicio de
Azure Active Directory. La entidad de servicio debe tener permisos para administrar la red virtual y la subred
que los nodos de AKS utilizan. Para crear una entidad de servicio, use el comando az ad sp create-for-rbac:
En la salida de ejemplo siguiente se muestran la contraseña y el identificador de aplicación de la entidad de

servicio. Estos valores se usan en pasos adicionales para asignar un rol a la entidad de servicio y después crear
el clúster de AKS:
{
"appId": "476b3636-5eda-4c0e-9751-849e70b5cfad",
"displayName": "azure-cli-2019-01-09-22-29-24",
"name": "http://azure-cli-2019-01-09-22-29-24",
"password": "a1024cd7-af7b-469f-8fd7-b293ecbb174e",
"tenant": "72f998bf-85f1-41cf-92ab-2e7cd014db46"
}
Para asignar las delegaciones correctas en los pasos restantes, use los comandos az network vnet show y az
network vnet subnet show para obtener los identificadores de recursos necesarios. Estos identificadores de
recursos se almacenan como variables y se hace referencia a ellos en los pasos restantes:
VNET_ID=$(az network vnet show --resource-group myResourceGroup --name myAKSVnet --query id -o tsv)
SUBNET_ID=$(az network vnet subnet show --resource-group myResourceGroup --vnet-name myAKSVnet --name
myAKSSubnet --query id -o tsv)
Ahora, asigne la entidad de servicio para los permisos de Colaborador de red del clúster de AKS en la red virtual
mediante el comando az role assignment create. Proporcione su propio valor <appId> como se muestra en la
salida del comando anterior para crear la entidad de servicio:
az role assignment create --assignee <appId> --scope $VNET_ID --role "Network Contributor"
Creación de un clúster de AKS en la red virtual

Ya ha creado una red virtual y una subred y también ha creado y asignado permisos para que una entidad de
servicio utilice dichos recursos de red. Ahora cree un clúster de AKS en la red virtual y la subred con el comando
az aks create. Defina sus valores de <appId> y <password> de la entidad de servicio, como se muestra en la
salida del comando anterior para crear la entidad de servicio.
Los siguientes intervalos de direcciones IP también se definen como parte del proceso de creación del clúster:
--service-cidr se usa para asignar servicios internos en una dirección IP del clúster de AKS. Este intervalo
de direcciones IP debe ser un espacio de direcciones que no se esté usando en ningún otro lugar del
entorno de red, incluidos los intervalos de red locales, si conecta o tiene previsto conectar las redes
virtuales de Azure mediante ExpressRoute o una conexión VPN de sitio a sitio.
La dirección --dns-service-ip debe ser la dirección .10 del intervalo de direcciones IP del servicio.
--pod-cidr debe ser un espacio de direcciones grande que no se use en ninguna otra parte del entorno de
red. Este rango incluye todos los rangos de red local si conecta, o planea conectar, las redes virtuales de
Azure mediante ExpressRoute o una conexión VPN de sitio a sitio.
Este intervalo de direcciones debe ser lo suficientemente grande como para alojar el número de
nodos hasta el que pretende escalar verticalmente. No puede cambiar este intervalo de direcciones
una vez que el clúster se haya implementado, en caso de que necesite más direcciones para nodos
adicionales.
El intervalo de direcciones IP para pods se usa para asignar un espacio de direcciones de /24 a cada
nodo del clúster. En el ejemplo siguiente, --pod-cidr de 10.244.0.0/16 asigna el primer nodo
10.244.0.0/24, el segundo nodo 10.244.1.0/24 y el tercer nodo 10.244.2.0/24.
A medida que el clúster se escala o actualiza, la plataforma de Azure continúa asignando un intervalo
de direcciones IP para pods a cada nuevo nodo.
--docker-bridge-address permite que los nodos de AKS se comuniquen con la plataforma de
administración subyacente. Esta dirección IP no debe estar dentro del rango de direcciones IP de red
virtual del clúster, y no debe superponerse con otros rangos de direcciones en uso en la red.
az aks create \
--node-count 3 \
--network-plugin kubenet \
--service-cidr 10.0.0.0/16 \
--pod-cidr 10.244.0.0/16 \
--vnet-subnet-id $SUBNET_ID \
NOTE
Si quiere permitir que un clúster de AKS incluya una directiva de red de Calico, puede usar el siguiente comando.
az aks create \
--node-count 3 \
--network-plugin kubenet --network-policy calico \
--service-cidr 10.0.0.0/16 \
--pod-cidr 10.244.0.0/16 \
Al crear un clúster de AKS, también se crean automáticamente un grupo de seguridad de red y una tabla de
rutas. Estos recursos de red los administra el plano de control de AKS. El grupo de seguridad de red se asocia
automáticamente con la tarjetas de interfaz de red virtuales de los nodos. La tabla de ruta se asocia
automáticamente con la subred de la red virtual. Las tablas de ruta y las reglas del grupo de seguridad de red se
actualizan automáticamente cuando se crean y se exponen los servicios.
Uso de su propia subred y tabla de rutas con Kubenet

Con Kubenet, debe existir una tabla de rutas en las subredes del clúster. AKS admite la incorporación de su
subred y tabla de rutas existentes.
Si la subred personalizada no contiene ninguna tabla de rutas, AKS crea una automáticamente y le agrega reglas
desde el ciclo de vida del clúster. Si la subred personalizada contiene una tabla de rutas al crear el clúster, AKS
confirma la tabla de rutas existente durante las operaciones del clúster y agrega o actualiza reglas según
corresponde para las operaciones del proveedor de nube.
WARNING
Se pueden agregar y actualizar reglas personalizadas en la tabla de rutas personalizadas. Sin embargo, el proveedor en la
nube de Kubernetes agrega reglas que no se deben actualizar ni quitar. Las reglas como 0.0.0.0/0 deben existir siempre en
una tabla de rutas dada y asignarse al destino de la puerta de enlace de Internet, como una NVA u otra puerta de enlace
de salida. Tenga cuidado al actualizar reglas de hacerlo solo con sus reglas personalizadas.
Más información sobre la configuración de una tabla de rutas personalizada.

Las redes de Kubenet requieren reglas de tabla de rutas organizadas para redirigir las solicitudes correctamente.
Debido a este diseño, las tablas de rutas deben mantenerse cuidadosamente para cada clúster que dependa de
estas. Varios clústeres no pueden compartir una tabla de rutas porque los CIDR de pod de distintos clústeres
pueden superponerse, lo que provoca un enrutamiento inesperado y discontinuo. Al configurar varios clústeres
en la misma red virtual o dedicar una red virtual a cada clúster, asegúrese de que se tienen en cuenta las
siguientes limitaciones.
Limitaciones:
Los permisos deben asignarse antes de la creación del clúster. Asegúrese de que usa una entidad de servicio
con permisos de escritura en la subred y la tabla de rutas personalizadas.
Una tabla de rutas personalizada debe estar asociada a la subred antes de que cree el clúster de AKS.
El recurso de la tabla de rutas asociado no se puede actualizar después de crear el clúster. Aunque no se
puede actualizar el recurso de la tabla de rutas, se pueden modificar las reglas personalizadas en la tabla de
rutas.
Cada clúster de AKS debe usar una única tabla de rutas para todas las subredes asociadas con el clúster. No
se puede reutilizar una tabla de rutas con varios clústeres debido a la posibilidad de que se superpongan los
CIDR de pod y las reglas de enrutamiento en conflicto.
Después de crear una tabla de rutas personalizada y asociarla a la subred de la red virtual, puede crear un nuevo
clúster de AKS que use la tabla de rutas. Debe usar el identificador de subred desde el que tiene previsto
implementar el clúster de AKS. Esta subred también debe estar asociada a la tabla de rutas personalizada.
# Find your subnet ID

az network vnet subnet list --resource-group
--vnet-name
[--subscription]
# Create a kubernetes cluster with with a custom subnet preconfigured with a route table
az aks create -g MyResourceGroup -n MyManagedCluster --vnet-subnet-id MySubnetID
Pasos siguientes
Con un clúster de AKS implementado en la subred de red virtual existente, ahora puede usar el clúster de forma
habitual. Empiece a crear aplicaciones con Helm o a implementar aplicaciones existentes con Helm.
Configuración de redes de Azure CNI en Azure
De forma predeterminada, los clústeres de AKS usan kubenet, y una red virtual y una subred se crean
automáticamente. Con kubenet, los nodos obtienen una dirección IP de una subred de la red virtual. Luego, la
traducción de direcciones de red (NAT) se configura en los nodos, y los pods reciben una dirección IP "oculta"
detrás de la dirección IP del nodo. Este enfoque reduce el número de direcciones IP que se deben reservar en el
espacio de red para su uso por parte de los pods.
Con Azure Container Networking Interface (CNI), cada pod obtiene una dirección IP de la subred, y se puede
acceder a él directamente. Estas direcciones IP deben ser únicas en el espacio de red y deben planearse de
antemano. Cada nodo tiene un parámetro de configuración para el número máximo de pods que admite. Luego,
el número equivalente de direcciones IP por nodo se reserva por adelantado para ese nodo. Este enfoque
requiere más planificación y a menudo lleva al agotamiento de direcciones IP o a la necesidad de volver a
generar los clústeres en una subred mayor, a medida que crecen las exigencias de la aplicación.
En este artículo se muestra cómo usar las redes de Azure CNI para crear y usar la subred una red virtual con un
clúster de AKS. Para más información sobre las opciones y consideraciones de red, consulte el artículo sobre los
conceptos de red para Kubernetes y AKS.
Requisitos previos
La red virtual del clúster AKS debe permitir la conectividad saliente de Internet.
Los clústeres de AKS no pueden usar 169.254.0.0/16 , 172.30.0.0/16 , 172.31.0.0/16 ni 192.0.2.0/24 para
el intervalo de direcciones del servicio de Kubernetes, el intervalo de direcciones de pod, o el intervalo de
direcciones de la red virtual del clúster.
La identidad de clúster que usa el clúster de AKS debe tener como mínimo permisos de Colaborador de la
red en la subred de la red virtual. Si quiere definir un rol personalizado en lugar de usar el rol integrado de
colaborador de red, se requieren los permisos siguientes:
La subred asignada al grupo de nodos AKS no puede ser una subred delegada.
Planeamiento de direccionamiento IP del clúster

Los clústeres configurados con redes de Azure CNI requieren planeamiento adicional. Los tamaños de red
virtual y de subred deben ajustarse al número de pods que tiene previsto ejecutar, así como al número de nodos
del clúster.
Se asignan direcciones IP para los pods y los nodos del clúster desde la subred especificada dentro de la red
virtual. Cada nodo se configura con una dirección IP principal. De forma predeterminada, Azure CNI configura
previamente treinta direcciones IP adicionales que se asignan a los pods programados en el nodo. Cuando se
escala horizontalmente el clúster, cada nodo del mismo modo se configura de modo similar con direcciones IP
de la subred. También puede ver el número máximo de pods por nodo.
IMPORTANT
El número de direcciones IP necesarias debe incluir consideraciones sobre las operaciones de actualización y escalabilidad.
Si establece el intervalo de direcciones IP para que solo se admita un número fijo de nodos, no se podrá actualizar o
escalar el clúster.
Al actualizar el clúster de AKS, se implementa un nuevo nodo en el clúster. Los servicios y las cargas de trabajo
comienzan a ejecutarse en el nuevo nodo y el nodo antiguo se quita del clúster. Para realizar este proceso de
actualización gradual es necesario que haya disponible un bloque adicional de direcciones IP. El recuento de nodos
es entonces n + 1 .
Esta consideración es especialmente importante al utilizar grupos de nodos de Windows Server. Los nodos de
Windows Server en AKS no aplican automáticamente las actualizaciones de Windows, en su lugar, se realiza una
actualización en el grupo de nodos. Esta actualización implementa los nuevos nodos con las revisiones de
seguridad y de la imagen de nodo base de Windows Server 2019 más recientes. Para más información sobre
cómo actualizar un grupo de nodos de Windows Server, consulte el artículo de actualización de un grupo de
nodos en AKS.
Al escalar un clúster de AKS, se implementa un nuevo nodo en el clúster. Los servicios y las cargas de trabajo
comienzan a ejecutarse en el nuevo nodo. El intervalo de direcciones IP debe tener en cuenta cómo podría escalar
verticalmente el número de nodos y los pods que el clúster puede admitir. También se debe incluir un nodo
adicional para las operaciones de actualización. El recuento de nodos es entonces
n + number-of-additional-scaled-nodes-you-anticipate + 1 .
Si espera que los nodos ejecuten el número máximo de pods, y destruye e implementa pods con regularidad,
también debe contar con algunas direcciones IP adicionales por nodo. Estas direcciones IP adicionales tienen en
cuenta que la eliminación de un servicio y la implementación de la dirección IP liberada para un nuevo servicio
pueden tardar unos segundos, y adquieren la dirección.
El plan de direcciones IP de un clúster AKS consta de una red virtual, al menos una subred para los nodos y
pods, y un intervalo de direcciones del servicio de Kubernetes.
IN T ERVA LO DE DIREC C IO N ES / REC URSO DE A Z URE L ÍM IT ES Y TA M A Ñ O
Virtual network El tamaño de Azure Virtual Network puede ser de /8, pero se
limita a 65 536 direcciones IP configuradas. Antes de
configurar el espacio de direcciones, tenga en cuenta todos
sus requisitos de red, incluida la comunicación con los
servicios de otras redes virtuales. Por ejemplo, si configura
un espacio de direcciones demasiado grande, es posible que
surjan problemas de superposición con otros espacios de
direcciones dentro de la red.
IN T ERVA LO DE DIREC C IO N ES / REC URSO DE A Z URE L ÍM IT ES Y TA M A Ñ O
Subnet Debe ser lo suficientemente grande como para dar cabida a

los nodos, los pods y a todos los recursos de Kubernetes y
de Azure que se pueden aprovisionar en el clúster. Por
ejemplo, si implementa una instancia de Azure Load Balancer
interna, sus direcciones IP de front-end se asignan desde la
subred del clúster, no las direcciones IP públicas. El tamaño
de la subred también debe tener en cuenta las operaciones
de actualización o las necesidades futuras de escalabilidad.
Para calcular el tamaño mínimo de subred, incluido un
nodo adicional para operaciones de actualización:
(number of nodes + 1) + ((number of nodes + 1)
* maximum pods per node that you configure)
Ejemplo de un clúster de 50 nudos:

(51) + (51 * 30 (default)) = 1,581 (/21 o
superior)
Ejemplo de un clúster de 50 nodos que también incluye
aprovisionamiento para escalar verticalmente 10 nodos
adicionales: (61) + (61 * 30 (default)) = 1,891
(/21 o superior)
Si no especifica un número máximo de pods por nodo al
crear el clúster, el número máximo de pods por nodo se
establece en 30. El número mínimo de direcciones IP
requeridas se basa en ese valor. Si se calculan los
requisitos mínimos de dirección IP según otro valor
máximo distinto, vea cómo configurar el número
máximo de pods por nodo para establecer este valor
cuando se implementa el clúster.
Intervalo de direcciones del servicio de Kubernetes Este intervalo no lo debe usar ningún elemento de red de
esta red virtual o que esté conectado a ella. El CIDR de la
dirección del servicio debe ser menor que /12. Puede
reutilizar este intervalo en diferentes clústeres de AKS.
Dirección IP del servicio DNS de Kubernetes Dirección IP del intervalo de direcciones del servicio de
Kubernetes que se usará en la detección de servicios de
clúster. No use la primera dirección IP en el intervalo de
direcciones, como .1. La primera dirección del intervalo de la
subred se usa para la dirección
kubernetes.default.svc.cluster.local.
Dirección de puente de Docker La dirección de red del puente de Docker representa la

dirección de red del puente de docker0 predeterminada
presente en todas las instalaciones de Docker. Aunque los
pods o los clústeres de AKS no usan el puente de docker0,
debe configurar esta dirección para seguir admitiendo
escenarios como la compilación de Docker en el clúster de
AKS. Es necesario seleccionar un CIDR para la dirección de
red del puente de Docker, ya que, de lo contrario, Docker
seleccionará automáticamente una subred que podría entrar
en conflicto con otros CIDR. Debe elegir un espacio de
direcciones que no entre en conflicto con el resto de los
CIDR de las redes, incluidos el CIDR de servicio del clúster y
el CIDR del pod. El valor predeterminado es 172.17.0.1/16.
Puede reutilizar este intervalo en diferentes clústeres de AKS.
Pods máximos por nodo
El número máximo de pods por nodo en un clúster de AKS es 250. El número máximo predeterminado de pods
por nodo varía entre las redes de kubenet y de Azure CNI, y el método de implementación del clúster.
M ÉTO DO DE K UB EN ET A Z URE C N I C O N F IGURA B L E EN L A

IM P L EM EN TA C IÓ N P REDET ERM IN A DO P REDET ERM IN A DO IM P L EM EN TA C IÓ N
Azure CLI 110 30 Sí (hasta 250)
Plantilla de Resource 110 30 Sí (hasta 250)

Manager
Portal 110 110 (configurados en la No

pestaña Grupos de nodos)
Configurar máximo: nuevos clústeres

Puede configurar el número máximo de pods por nodo solo en tiempo de implementación del clúster o al
agregar nuevos grupos de nodos. Si realiza la implementación con la CLI de Azure o con una plantilla de
Resource Manager, puede establecer un valor máximo de pods por nodo de hasta 250.
Si no especifica maxPods al crear grupos de nodos nuevos, recibirá un valor predeterminado de 30 para Azure
CNI.
Se exige un valor mínimo para los pods máximos por nodo para garantizar el espacio de los pods del sistema
críticos para el estado del clúster. El valor mínimo que se puede establecer para los pods máximos por nodo es
diez si y solo si la configuración de cada grupo de nodos tiene espacio para un mínimo de treinta pods. Por
ejemplo, si se establece el número máximo de pods por nodo en el mínimo de diez, cada grupo de nodos
individual debe tener un mínimo de tres nodos. Este requisito se aplica también a cada nuevo grupo de nodos
que se crea, por lo que si se define diez como el número máximo de pods por nodo, cada grupo de nodos que
se agregue después debe tener al menos tres nodos.
REDES M ÍN IM A M Á XIM A
CNI de Azure 10 250
Kubenet 10 110
NOTE
El valor mínimo de la tabla anterior lo aplica estrictamente el servicio AKS. No se puede establecer un valor de maxPods
inferior al mínimo que se muestra; de lo contrario, podría impedirse el inicio del clúster.
CLI de Azure : especifique el argumento --max-pods cuando implemente un clúster con el comando az aks
create. El valor máximo es 250.
Plantilla de Resource Manager : especifique la propiedad maxPods del objeto
ManagedClusterAgentPoolProfile cuando implemente un clúster con una plantilla de Resource Manager. El
valor máximo es 250.
Por tal de Azure : no puede modificar el número máximo de pods por nodo cuando implemente un clúster
con Azure Portal. Los clústeres de redes de Azure CNI están limitados a 30 pods por nodo cuando se
implementan mediante Azure Portal.
Configurar máximo: clústeres existentes
La configuración de maxPod por nodo se puede definir cuando se crea un nuevo grupo de nodos. Si necesita
aumentar el valor de maxPod por nodo en un clúster existente, agregue un nuevo grupo de nodos con el nuevo
recuento de maxPod deseado. Después de migrar los pods al nuevo grupo, elimine el grupo anterior. Para
eliminar cualquier grupo anterior en un clúster, asegúrese de que está configurando los modos de grupo de
nodos tal como se define en el documento de grupos de nodos del sistema.
Parámetros de implementación
Cuando crea un clúster de AKS, los parámetros siguientes son configurables para redes de Azure CNI:
Red vir tual : la red virtual en la que desea implementar el clúster de Kubernetes. Si desea crear una red virtual
nueva para el clúster, seleccione Crear nueva y siga los pasos descritos en la sección Creación de red virtual.
Para información acerca de límites y cuotas para Azure Virtual Network, vea Límites, cuotas y restricciones de
suscripción y servicios de Microsoft Azure.
Subred : la subred dentro de la red virtual en la que desea implementar el clúster. Si desea crear una nueva
subred en la red virtual para el clúster, seleccione Crear nueva y siga los pasos descritos en la sección Creación
de subred. Para la conectividad híbrida, el intervalo de direcciones no debe solaparse con ninguna otra red
virtual de su entorno.
Complemento de red de Azure : cuando se usa el complemento de red de Azure, no se puede acceder al
servicio Load Balancer interno con "externalTrafficPolicy=Local" desde VM con una dirección IP en clusterCIDR
que no pertenezca al clúster de AKS.
Inter valo de direcciones de ser vicio de Kubernetes : es parámetro es el conjunto de direcciones IP
virtuales que Kubernetes asigna a servicios internos del clúster. Puede usar cualquier intervalo de direcciones
privado que cumpla los requisitos siguientes:
No debe estar dentro del intervalo de direcciones IP de la red virtual del clúster.
No deben superponerse con ninguna otra red virtual del mismo nivel que la red virtual del clúster.
No debe superponerse con ninguna dirección IP local.
No debe estar dentro de los intervalos 169.254.0.0/16 , 172.30.0.0/16 , 172.31.0.0/16 ni 192.0.2.0/24
Aunque es técnicamente posible especificar un intervalo de direcciones de servicio en la misma red virtual que
el clúster, no se recomienda. Puede producirse un comportamiento impredecible si se usan intervalos IP
superpuestos. Para más información, consulte la sección P+F de este artículo. Para más información sobre los
servicios de Kubernetes, consulte Servicios en la documentación de Kubernetes.
Dirección IP del ser vicio DNS de Kubernetes : la dirección IP del servicio DNS del clúster. Esta dirección
debe estar dentro del intervalo de direcciones del servicio Kubernetes. No use la primera dirección IP en el
intervalo de direcciones, como .1. La primera dirección del intervalo de la subred se usa para la dirección
kubernetes.default.svc.cluster.local.
Dirección del puente de Docker : La dirección de red del puente de Docker representa la dirección de red del
puente de docker0 predeterminada presente en todas las instalaciones de Docker. Aunque los pods o los
clústeres de AKS no usan el puente de docker0, debe configurar esta dirección para seguir admitiendo
escenarios como la compilación de Docker en el clúster de AKS. Es necesario seleccionar un CIDR para la
dirección de red del puente de Docker, ya que, de lo contrario, Docker seleccionará automáticamente una subred
que podría entrar en conflicto con otros CIDR. Debe elegir un espacio de direcciones que no entre en conflicto
con el resto de los CIDR de las redes, incluidos el CIDR de servicio del clúster y el CIDR del pod.
Configuración de redes: CLI

Al crear un clúster de AKS con la CLI de Azure, también puede configurar redes de Azure CNI. Use los siguientes
comandos para crear un nuevo clúster de AKS con las redes de Azure CNI habilitadas.
En primer lugar, obtenga el identificador de recursos de subred para la subred existente a la que se unirá el
clúster de AKS:
$ az network vnet subnet list \

--resource-group myVnet \
--vnet-name myVnet \
--query "[0].id" --output tsv
/subscriptions/<guid>/resourceGroups/myVnet/providers/Microsoft.Network/virtualNetworks/myVnet/subnets/defau
lt
Use el comando az aks create con el argumento --network-plugin azure para crear un clúster con redes
avanzadas. Actualice el valor --vnet-subnet-id con el identificador de subred recopilado en el paso anterior:
az aks create \
--vnet-subnet-id <subnet-id> \
--service-cidr 10.2.0.0/24 \
--generate-ssh-keys
Configuración de redes: portal

La siguiente captura de pantalla de Azure Portal muestra un ejemplo de la configuración de estos valores
durante la creación del clúster de AKS:
![Configuración avanzada de redes en Azure Portal][portal-01-networking-advanced]
Asignación dinámica de direcciones IP y compatibilidad mejorada con

subredes (versión preliminar)
IMPORTANT
NOTE
La característica en vista previa (GB) está disponible actualmente en las siguientes regiones:
Centro-Oeste de EE. UU.
Un inconveniente de la CNI tradicional es el agotamiento de las direcciones IP Pod a medida que crece el clúster
de AKS, de modo que se vuelve necesario recompilar todo el clúster en una subred más grande. La nueva
funcionalidad de asignación dinámica de direcciones IP de Azure CNI soluciona este problema al asignar
direcciones IP de pod de una subred independiente de la subred que hospeda el clúster de AKS. Esto reporta las
siguientes ventajas:
Mejor uso de IP : las direcciones IP se asignan dinámicamente a los pods de clúster desde la subred de
pod. Esto conduce a un mejor uso de las direcciones IP en el clúster en comparación con la solución CNI
tradicional, que realiza una asignación estática de direcciones IP para cada nodo.
Escalable y flexible : las subredes de nodo y pod se pueden escalar de manera independiente. Una sola
subred de pod puede compartirse en varios grupos de nodos de un clúster o en varios clústeres de AKS
implementados en la misma red virtual. También puede configurar una subred de pod independiente
para un grupo de nodos.
Alto rendimiento : ya que a los pods se les asignan direcciones IP de red virtual, tienen conectividad
directa con los recursos y el pod de otros clústeres de la red virtual. La solución admite clústeres muy
grandes sin ninguna reducción del rendimiento.
Directivas de red vir tual independientes para pods : dado que los pods tienen una subred
independiente, puede configurar directivas de red virtual independientes para ellas distintas de las
directivas de nodo. Esto permite muchos escenarios útiles, como la habilitación de la conectividad a
Internet solo para pods y no para los nodos, la corrección de la IP de origen para pods en un grupo de
nodos mediante una NAT de red virtual y el uso de NSG para filtrar el tráfico entre grupos de nodos.
Directivas de red de Kubernetes : las directivas de red de Azure y Calico funcionan con esta nueva
solución.
Instalación de la CLI de Azure aks-preview
Necesitará la extensión de la CLI de Azure aks-preview . Instale la extensión de la CLI de Azure aks-preview
mediante el comando az extension add. También puede instalar las actualizaciones disponibles mediante el
comando az extension update.

Registro de la característica en vista previa (GB ) PodSubnetPreview
Para usar la característica, también debe habilitar la marca de característica PodSubnetPreview en la suscripción.
Registre la marca de la característica PodSubnetPreview con el comando az feature register, como se muestra en
el siguiente ejemplo:
az feature register --namespace "Microsoft.ContainerService" --name "PodSubnetPreview"
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/PodSubnetPreview')].

Requisitos previos adicionales

Los requisitos previos ya indicados para Azure CNI siguen siendo aplicables, pero hay algunas limitaciones
adicionales:
Solo se admiten clústeres de nodo de Linux y los grupos de nodos.
No se admiten los clústeres de AKS Engine y de implementación personal.
Planeación del direccionamiento IP
Al usar esta característica, la planeación es mucho más sencilla. Dado que los nodos y pods se escalan de
manera independiente, los espacios de direcciones también se pueden planear por separado. Como las
subredes de pod se pueden configurar en la granularidad de un grupo de nodos, los clientes siempre podrán
agregar una nueva subred cuando agreguen un grupo de nodos. Los pods de sistema de un grupo de
clústeres/nodos también reciben direcciones IP de la subred de pod, por lo que es necesario tener en cuenta
este comportamiento.
La planeación de las direcciones IP para los servicios K8S y el puente de Docker permanecen sin cambios.
Máximo de pods por nodo en un clúster con asignación dinámica de direcciones IP y compatibilidad
mejorada con subredes
Los valores de pods por nodo al usar Azure CNI con asignación dinámica de direcciones IP han cambiado
ligeramente del comportamiento de CNI tradicional:
M ÉTO DO DE C O N F IGURA B L E EN L A
CNI IM P L EM EN TA C IÓ N VA LO R P REDET ERM IN A DO IM P L EM EN TA C IÓ N
Azure CNI tradicional Azure CLI 30 Sí (hasta 250)
Azure CNI con asignación Azure CLI 250 Sí (hasta 250)

dinámica de direcciones IP
Todas las demás instrucciones relacionadas con la configuración del máximo de nodos por pod siguen siendo
las mismas.
Parámetros de implementación adicionales
Los parámetros de implementación descritos anteriormente siguen siendo válidos, con una excepción:
El parámetro subnet ahora hace referencia a la subred relacionada con los nodos del clúster.
Se usa un parámetro adicional pod subnet para especificar la subred cuyas direcciones IP se asignarán
dinámicamente a los pods.
Configuración de redes: CLI con asignación dinámica de direcciones IP y compatibilidad mejorada con
subredes
El uso de la asignación dinámica de direcciones IP y la compatibilidad mejorada con subredes en el clúster es
similar al método predeterminado para configurar un clúster de Azure CNI. En el ejemplo siguiente se describe
cómo crear una nueva red virtual con una subred para nodos y una subred para pods, y cómo crear un clúster
que usa Azure CNI con asignación dinámica de direcciones IP y compatibilidad mejorada con subredes.
Asegúrese de reemplazar las variables como $subscription con sus propios valores:
En primer lugar, cree la red virtual con dos subredes:
$resourceGroup="myResourceGroup"
$vnet="myVirtualNetwork"
# Create our two subnet network

az network vnet create -g $rg --name $vnet --address-prefixes 10.0.0.0/8 -o none
az network vnet subnet create -g $rg --vnet-name $vnet --name nodesubnet --address-prefixes 10.240.0.0/16 -o
none
az network vnet subnet create -g $rg --vnet-name $vnet --name podsubnet --address-prefixes 10.241.0.0/16 -o
none
A continuación, cree el clúster. Para ello, haga referencia a la subred de nodo mediante --vnet-subnet-id y la
subred de pod con --pod-subnet-id :
$clusterName="myAKSCluster"
$location="eastus"
$subscription="aaaaaaa-aaaaa-aaaaaa-aaaa"
az aks create -n $clusterName -g $resourceGroup -l $location --max-pods 250 --node-count 2 --network-plugin

azure --vnet-subnet-id
/subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet
/subnets/nodesubnet --pod-subnet-id
/subnets/podsubnet
Adición de grupo de nodos

Al agregar un grupo de nodos, haga referencia a la subred de nodo mediante --vnet-subnet-id y la subred de
pod mediante --pod-subnet-id . En el ejemplo siguiente se crean dos nuevas subredes a las que se hace
referencia durante la creación de un nuevo grupo de nodos:
az network vnet subnet create -g $resourceGroup --vnet-name $vnet --name node2subnet --address-prefixes
10.242.0.0/16 -o none
az network vnet subnet create -g $resourceGroup --vnet-name $vnet --name pod2subnet --address-prefixes
10.243.0.0/16 -o none
az aks nodepool add --cluster-name $clusterName -g $resourceGroup -n newNodepool --max-pods 250 --node-
count 2 --vnet-subnet-id
/subnets/node2subnet --pod-subnet-id
/subnets/pod2subnet --no-wait

Las siguientes preguntas y respuestas se aplican a la configuración de red de Azure CNI .
¿Puedo implementar máquinas virtuales en la subred del clúster?
Sí.
¿Qué dirección IP de origen ven los sistemas externos para el tráfico que se origina en un pod habilitado
para Azure CNI?
Los sistemas de la misma red virtual que el clúster de AKS ven la IP del pod como la dirección de origen
para todo el tráfico del pod. Los sistemas que están fuera de la red virtual del clúster de AKS ven la IP del
nodo como la dirección de origen para todo el tráfico del pod.
¿Puedo configurar las directivas de red por pod?
Sí, la directiva de red de Kubernetes está disponible en AKS. Para comenzar, consulte Protección del
tráfico entre pods mediante directivas de red en Azure Kubernetes Service (AKS).
¿Es configurable el número máximo de pods que se puede implementar en un nodo ?
Sí, al implementar un clúster con la CLI de Azure o una plantilla de Resource Manager. Consulte Pods
máximos por nodo.
No se puede cambiar el número máximo de pods por nodo en un clúster existente.
¿Cómo se pueden configurar propiedades adicionales para la subred que he creado durante la creación
del clúster de AKS? Por ejemplo, los puntos de conexión de servicio.
La lista completa de propiedades de la red virtual y las subredes que se crean durante la creación del
clúster de AKS puede configurarse en la página de configuración de red virtual estándar en Azure Portal.
¿Puedo usar otra subred dentro de mi red virtual de clúster como inter valo de direcciones de
ser vicio de Kubernetes ?
Aunque no se recomienda, esta configuración es posible. El rango de direcciones de servicio es un
conjunto de direcciones IP virtuales (VIP) que Kubernetes asigna a los servicios internos del clúster. Las
redes de Azure no tiene ninguna visibilidad sobre el intervalo de direcciones IP de servicio del clúster de
Kubernetes. Debido a ello, es posible crear posteriormente una nueva subred en la red virtual del clúster
que se superponga con el intervalo de direcciones de servicio. Si se produce una superposición de este
tipo, Kubernetes podría asignar a un servicio una dirección IP que ya esté en uso por otro recurso de la
subred, lo que provocaría un comportamiento impredecible o errores. Al tener la seguridad de usar un
intervalo de direcciones que se encuentra fuera de la red virtual del clúster puede evitar este riesgo de
superposición.
Preguntas frecuentes sobre la asignación dinámica de direcciones IP y la compatibilidad mejorada con
subredes
Las siguientes preguntas y respuestas se aplican a la configuración de red de Azure CNI cuando se usa la
asignación dinámica de direcciones IP y la compatibilidad mejorada con subredes .
¿Puedo asignar varias subredes de pod a un grupo de clústeres/nodos?
Solo se puede asignar una subred a un grupo de clústeres o nodos. Sin embargo, varios clústeres o
grupos de nodos pueden compartir una sola subred.
¿Puedo asignar subredes de pod de una red virtual diferente?
La subred de pod debe ser de la misma red virtual que el clúster.
¿Algunos de los grupos de nodos de un clúster pueden usar el CNI tradicional mientras otros usan el
nuevo CNI?
Todo el clúster debe usar un solo tipo de CNI.
Motor de AKS
El motor de Azure Kubernetes Service (motor de AKS) es un proyecto de código abierto que genera plantillas de
Azure Resource Manager que puede usar para implementar clústeres de Kubernetes en Azure.
Los clústeres de Kubernetes creados con AKS Engine admiten los complementos kubenet y Azure CNI. Por lo
tanto, ambos escenarios de redes son compatibles con AKS Engine.
Pasos siguientes
Más información acerca de las redes en AKS en los siguientes artículos:
Uso de una dirección IP estática con el equilibrador de carga de Azure Kubernetes Service (AKS)
Uso de un equilibrador de carga interno con Azure Container Service (AKS)
Habilitación del complemento de enrutamiento de aplicación HTTP
Creación de un controlador de entrada con una dirección IP pública dinámica y configuración de Let's
Encrypt para generar certificados TLS de forma automática
Creación de un controlador de entrada con una dirección IP pública estática y configuración de Let's
[advanced-networking-diagram-01]: ./media/networking-overview/advanced-networking-diagram-01.png
[portal-01-networking-advanced]: ./media/networking-overview/portal-01-networking-advanced.png
Uso de un equilibrador de carga interno con Azure
Para restringir el acceso a las aplicaciones en Azure Kubernetes Service (AKS), puede crear y usar un
equilibrador de carga interno. Un equilibrador de carga interno permite que un servicio de Kubernetes sea
accesible solo para las aplicaciones que se ejecutan en la misma red virtual que el clúster de Kubernetes. En este
artículo se muestra cómo crear y usar un equilibrador de carga interno con Azure Kubernetes Service (AKS).
NOTE
Azure Load Balancer está disponible en dos SKU: Básica y Estándar. De forma predeterminada, la SKU Estándar se usa al
crear un clúster de AKS. Al crear un servicio con el tipo LoadBalancer, obtendrá el mismo tipo de LB que al aprovisionar el
clúster. Para más información, consulte el apartado de comparación de las SKU de Azure Load Balancer.
Antes de empezar
Azure.
Si usa una subred o un grupo de recursos existentes, la identidad de clúster de AKS necesita permiso para
administrar los recursos de red. Para más información, vea Uso de redes kubenet con intervalos de direcciones
IP propios en Azure Kubernetes Service (AKS) o Configuración de redes de Azure CNI en Azure Kubernetes
Service (AKS). Si va a configurar el equilibrador de carga para usar una dirección IP en una subred diferente,
asegúrese de que la identidad de clúster de AKS también tenga acceso de lectura a esa subred.
Para más información sobre los permisos, consulte Delegación del acceso de AKS a otros recursos de Azure.
Creación de un conjunto de equilibrador de carga interno

Para crear un equilibrador de carga interno, cree un manifiesto de servicio denominado internal-lb.yaml con
el tipo de servicio LoadBalancer y la anotación azure-load-balancer-internal, tal como se muestra en el siguiente
ejemplo:
apiVersion: v1
kind: Service
metadata:
name: internal-app
annotations:
service.beta.kubernetes.io/azure-load-balancer-internal: "true"
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: internal-app
Implemente el equilibrador de carga interno mediante kubectl apply y especifique el nombre del manifiesto de
YAML:
kubectl apply -f internal-lb.yaml
Se crea una instancia de Azure Load Balancer en el grupo de recursos del nodo, y se conecta a la misma red
virtual que el clúster de AKS.
Cuando visualiza los detalles del servicio, la dirección IP del equilibrador de carga interno se muestra en la
columna EXTERNAL-IP. En este contexto, externo es en relación con la interfaz externa del equilibrador de carga,
no es que reciba una dirección IP pública externa. La dirección IP puede tardar uno o dos minutos en cambiar de
<pending> a una dirección IP interna real, como se muestra en el ejemplo siguiente:
$ kubectl get service internal-app

internal-app LoadBalancer 10.0.248.59 10.240.0.7 80:30555/TCP 2m
Especificación de una dirección IP

Si quiere usar una dirección IP específica con el equilibrador de carga interno, agregue la propiedad
loadBalancerIP al manifiesto YAML del equilibrador de carga. En este escenario, la dirección IP especificada debe
encontrarse en la misma subred que el clúster de AKS y no se debe haber asignado ya a un recurso. Por
ejemplo, no debe usar una dirección IP en el intervalo designado para la subred de Kubernetes.
apiVersion: v1
kind: Service
metadata:
name: internal-app
annotations:
spec:
type: LoadBalancer
loadBalancerIP: 10.240.0.25
ports:
- port: 80
selector:
app: internal-app
Al implementar y ver los detalles del servicio, la dirección IP de la columna EXTERNAL-IP refleja la dirección IP
especificada:

Para más información sobre cómo configurar el equilibrador de carga en una subred diferente, vea
Especificación de una subred diferente.
Uso de redes privadas

Al crear su clúster de AKS, puede especificar la configuración de red avanzada. Este enfoque le permite
implementar el clúster en una red y subredes virtuales de Azure existentes. Un escenario es implementar el
clúster de AKS en una red privada conectada a su entorno local y ejecutar servicios solo accesibles
internamente. Para más información, consulte cómo configurar sus propias subredes de red virtual con Kubenet
o Azure CNI.
No se necesitan cambios en los pasos anteriores para implementar un equilibrador de carga interno en un
clúster de AKS que utilice una red privada. El equilibrador de carga se crea en el mismo grupo de recursos que el
clúster de AKS pero está conectado a la red virtual privada y subred, como se muestra en el siguiente ejemplo:

NOTE
Es posible que tenga que conceder a la identidad de clúster de AKS el rol Colaborador de la red para el grupo de recursos
en el que están implementados los recursos de la red virtual de Azure. Consulte la identidad de clúster con az aks show,
como az aks show --resource-group myResourceGroup --name myAKSCluster --query "identity" . Para crear una
asignación de roles, use el comando az role assignment create.
Especificación de una subred diferente

Para especificar una subred para el equilibrador de carga, agregue la anotación azure-load-balancer-internal-
subnet al servicio. La subred especificada debe estar en la misma red virtual que el clúster de AKS. Cuando se
implementa, la dirección EXTERNAL-IP del equilibrador de carga forma parte de la subred especificada.
apiVersion: v1
kind: Service
metadata:
name: internal-app
annotations:
service.beta.kubernetes.io/azure-load-balancer-internal-subnet: "apps-subnet"
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: internal-app
Eliminación del equilibrador de carga

Cuando se han eliminado todos los servicios que usan el equilibrador de carga interno, también se elimina el
propio equilibrador de carga.
También puede eliminar directamente un servicio del mismo modo que cualquier recurso de Kubernetes, como
kubectl delete service internal-app , acción que también eliminará el equilibrador de carga de Azure
subyacente.
Pasos siguientes
Más información sobre los servicios de Kubernetes en la documentación de servicios de Kubernetes.
Uso de Standard Load Balancer en
Azure Load Balancer es una instancia L4 del modelo de interconexión de sistemas abiertos (OSI) que admite
escenarios de entrada y salida. Distribuye flujos de entrada que llegan al front-end del equilibrador de carga a
las instancias del grupo de servidores back-end.
Una instancia pública de Load Balancer, cuando se integra con AKS, tiene dos propósitos:
1. Proporcionar conexiones salientes a los nodos de clúster dentro de la red virtual AKS. Logra este objetivo al
traducir la dirección IP privada de los nodos a una dirección IP pública que forma parte de su Grupo de
salida.
2. Para proporcionar acceso a las aplicaciones mediante instancias de Kubernetes Services del tipo
LoadBalancer . En ese caso, puede escalar las aplicaciones y crear servicios con alta disponibilidad fácilmente.
Un equilibrador de carga interno (o privado) se usa cuando solo se admiten direcciones IP privadas como
front-end. Los equilibradores de carga internos se usan para equilibrar la carga del tráfico dentro de una red
virtual. También se puede acceder a un servidor front-end de equilibrador de carga desde una red local en un
escenario híbrido.
En este documento se describe la integración con un equilibrador de carga público. Para la integración interna
de Load Balancer, consulte la documentación del equilibrador de carga interno de AKS.
Antes de empezar
Azure Load Balancer está disponible en dos SKU: Básica y Estándar. De forma predeterminada, se usa la SKU
estándar al crear un clúster de AKS. Use la SKU estándar para tener acceso a funcionalidad agregada, como un
grupo mayor de back-end, varios grupos de nodos , y Availability Zones . Se trata de la SKU de Load
Balancer recomendada para AKS.
Para más información sobre las SKU básicas y estándar, consulte Comparación de las SKU de Load Balancer.
En este artículo se da por sentado que tiene un clúster de AKS con Azure Load Balancer de la SKU estándar y se
le guía en el uso y la configuración de algunas de las funcionalidades y características del equilibrador de carga.
Si necesita un clúster de AKS, consulte el inicio rápido de AKS mediante la CLI de Azure o mediante Azure Portal.
IMPORTANT
Si prefiere no aprovechar Azure Load Balancer para proporcionar una conexión de salida y prefiere tener su propia puerta
de enlace, firewall o proxy para ese propósito, puede omitir la creación del grupo de salida del equilibrador de carga y el IP
del front-end respectivo si usa el tipo de salida como UserDefinedRouting (UDR) . El tipo de salida define el método
de salida para un clúster y su valor predeterminado es el tipo de equilibrador de carga.
Uso de la instancia pública de Standard Load Balancer.

Después de crear un clúster de AKS con el tipo de salida de Load Balancer (valor predeterminado), el clúster está
listo para usar el equilibrador de carga para exponer también los servicios.
Para ello, puede crear un servicio público de tipo LoadBalancer como se muestra en el ejemplo siguiente. Para
empezar, cree un manifiesto de servicio denominado public-svc.yaml :
apiVersion: v1
kind: Service
metadata:
name: public-svc
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: public-app
Para implementar el manifiesto de servicio público, use kubectl apply y especifique el nombre del manifiesto de
YAML:
kubectl apply -f public-svc.yaml
Azure Load Balancer se configurará con una nueva dirección IP pública de entrada al nuevo servicio. Dado que
Azure Load Balancer puede tener varias direcciones IP de front-end, cada nuevo servicio implementado
obtendrá una nueva dirección IP de front-end dedicada a la que podrá acceder de forma única.
Por ejemplo, para confirmar que se ha creado el servicio y que Load Balancer está configurado, ejecute:
kubectl get service public-svc
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

default public-svc LoadBalancer 10.0.39.110 52.156.88.187 80:32068/TCP 52s
Cuando visualiza los detalles del servicio, la dirección IP pública creada para este servicio en Load Balancer se
muestra en la columna EXTERNAL-IP. La dirección IP puede tardar uno o dos minutos en cambiar de <pending>
a una dirección IP pública real, como se muestra en el ejemplo anterior.
Configuración de la instancia pública de Standard Load Balancer

Cuando se usa la instancia pública de Load Balancer de la SKU estándar, hay un conjunto de opciones que se
pueden personalizar en el momento de la creación o al actualizar el clúster. Estas opciones le permiten
personalizar Load Balancer para satisfacer sus necesidades de cargas de trabajo y debe revisarse en
consecuencia. Con Standard Load Balance, puede hacer lo siguiente:
Definir o escalar el número de direcciones IP de salida administradas.
Traer su propio prefijo de IP de salida.
Personalizar el número de puertos de salida asignados a cada nodo del clúster.
Configurar el valor de tiempo de espera para las conexiones inactivas.
IMPORTANT
En un momento dado, solo se puede usar una opción de dirección IP de salida (direcciones IP administradas, traer sus
propias direcciones IP o prefijos de IP).
Escalar el número de direcciones IP públicas de salida administradas.

Azure Load Balancer proporciona conectividad de salida desde una red virtual, además de conectividad de
entrada. Las reglas de salida simplifican la configuración de la traducción de direcciones de red públicas de
salida de Standard Load Balancer.
Al igual que el resto de reglas de Load Balancer, las reglas de salida siguen la misma sintaxis conocida que las
reglas de NAT de entrada y el equilibrio de carga:
IP de front-end + parámetros + grupo de back-end
Una regla de salida configura una NAT de salida para todas las máquinas virtuales identificadas por el grupo de
back-end que se deben traducir para el front-end. Y los parámetros proporcionan un control más preciso sobre
el algoritmo de NAT de salida.
Mientras una regla de salida se puede usar con una única dirección IP pública, las reglas de salida alivian la
carga de configuración para escalar la NAT de salida. Puede usar varias direcciones IP para planear escenarios
de gran escala y puede usar reglas de salida para mitigar los patrones con tendencia a agotamiento de SNAT.
Cada dirección IP adicional que proporciona un front-end ofrece 64 000 puertos efímeros que Load Balancer
puede usar como puertos SNAT.
Cuando se usa un equilibrador de carga de SKU estándar con direcciones IP públicas de salida administradas,
que se crean de forma predeterminada, se puede escalar el número de direcciones IP públicas de salida
administradas mediante el parámetro load-balancer-managed-ip-count .
Para actualizar un clúster existente, ejecute el siguiente comando. Este parámetro también se puede establecer
en el momento de creación del clúster para tener varias direcciones IP públicas de salida administradas.
az aks update \
--load-balancer-managed-outbound-ip-count 2
En el ejemplo anterior se establece el número de direcciones IP públicas de salida administradas en 2 para el

clúster de myAKSCluster en myResourceGroup.
También puede usar el parámetro load-balancer-managed-ip-count para establecer el número inicial de
direcciones IP públicas de salida administradas al crear el clúster anexando el parámetro
--load-balancer-managed-outbound-ip-count y estableciéndolo en el valor deseado. El número predeterminado
de direcciones IP públicas de salida administradas es 1.
Proporcionar prefijos o direcciones IP públicas de salida
Cuando se usa un equilibrador de carga de SKU estándar, de forma predeterminada, el clúster de AKS crea
automáticamente una dirección IP pública en el grupo de recursos de infraestructura administrado por AKS y la
asigna al grupo de salida del equilibrador de carga.
Una dirección IP pública creada por AKS se considera un recurso administrado de AKS. Esto significa que el ciclo
de vida de la dirección IP pública está pensado para ser administrado por AKS y no requiere ninguna acción del
usuario directamente en el recurso de IP pública. Como alternativa, puede asignar su propio prefijo de dirección
IP pública personalizada o IP pública en el momento de la creación del clúster. Las direcciones IP personalizadas
también se pueden actualizar en las propiedades del equilibrador de carga de un clúster existente.
Requisitos para usar su propio prefijo o dirección IP pública:
Las direcciones IP públicas personalizadas deben crearse y ser propiedad del usuario. Las direcciones IP
públicas administradas creadas por AKS no se pueden volver a usar como una dirección IP personalizada, ya
que pueden provocar conflictos de administración.
Debe asegurarse de que la identidad de clúster de AKS (entidad de servicio o identidad administrada) tiene
permisos para acceder a la dirección IP de salida. Según la lista de permisos de dirección IP pública
requeridos.
Asegúrese de que cumple los requisitos previos y las restricciones necesarios para configurar direcciones IP
de salida o prefijos IP de salida.
Actualización del clúster con su propia dirección IP pública de salida
Use el comando az network public-ip show para enumerar los id. de las direcciones IP públicas.
az network public-ip show --resource-group myResourceGroup --name myPublicIP --query id -o tsv
El comando anterior muestra el id. de la dirección IP pública myPublicIP en el grupo de recursos

myResourceGroup.
Use el comando az aks update con el parámetro load-balancer-outbound-ips para actualizar el clúster con las
direcciones IP públicas.
En el ejemplo siguiente se usa el parámetro load-balancer-outbound-ips con los identificadores del comando
anterior.
az aks update \
--load-balancer-outbound-ips <publicIpId1>,<publicIpId2>
Actualización del clúster con su propio prefijo de dirección IP pública de salida

También puede usar prefijos de dirección IP pública para la salida con el equilibrador de carga de SKU estándar.
En el ejemplo siguiente se usa el comando az network public-ip prefix show para enumerar los id. de los prefijos
de dirección IP pública:
az network public-ip prefix show --resource-group myResourceGroup --name myPublicIPPrefix --query id -o tsv
El comando anterior muestra el id. del prefijo de dirección IP pública myPublicIPPrefix en el grupo de recursos
myResourceGroup.
En el ejemplo siguiente se usa el parámetro load-balancer-outbound-ip-prefixes con los id. del comando
anterior.
az aks update \
--load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>
Creación del clúster con su propio prefijo o dirección IP pública

Es posible que quiera traer sus propias direcciones IP o prefijos IP para la salida en el momento de la creación
del clúster para admitir escenarios como la incorporación de puntos de conexión de salida a una lista de
permitidos. Anexe los mismos parámetros mostrados anteriormente al paso de creación del clúster para definir
sus propios prefijos IP y direcciones IP públicas al inicio del ciclo de vida de un clúster.
Use el comando az aks create con el parámetro load-balancer-outbound-ips para crear un clúster con las IP
públicas en el inicio.
az aks create \
--load-balancer-outbound-ips <publicIpId1>,<publicIpId2>
Use el comando az aks create con el parámetro load-balancer-outbound-ip-prefixes para crear un clúster con los
prefijos de direcciones IP públicas en el inicio.
az aks create \
--load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>
Configuración de los puertos de salida asignados
IMPORTANT
Si tiene aplicaciones en el clúster que se espera que establezcan un gran número de conexiones con un pequeño conjunto
de destinos; p. ej., muchas instancias de front-end que se conectan a una base de datos SQL, tiene un escenario muy
susceptible al agotamiento de puertos SNAT (a quedarse sin puertos desde los que conectarse). En estos casos, se
recomienda aumentar los puertos de salida asignados y las direcciones IP de front-end salientes en el equilibrador de
carga. El aumento debe tener en cuenta que una (1) dirección IP adicional agrega 64 000 puertos adicionales que se
distribuyen entre todos los nodos de clúster.
A menos que se especifique lo contrario, AKS usará el valor predeterminado de los puertos de salida asignados
que defina Standard Load Balancer al configurarlo. Este valor es null en la API de AKS o 0 en la API de SLB, tal
como se muestra en el comando siguiente:
NODE_RG=$(az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv)
az network lb outbound-rule list --resource-group $NODE_RG --lb-name kubernetes -o table
Los comandos anteriores mostrarán la regla de salida del equilibrador de carga, por ejemplo:
AllocatedOutboundPorts EnableTcpReset IdleTimeoutInMinutes Name Protocol

ProvisioningState ResourceGroup
------------------------ ---------------- ---------------------- --------------- ---------- -----------
-------- -------------
0 True 30 aksOutboundRule All Succeeded
Esta salida no significa que tenga 0 puertos, sino que está aprovechando la asignación automática de puertos de
salida basada en el tamaño del grupo de back-end, por lo que, por ejemplo, si un clúster tiene menos de 50
nodos, se asignan 1024 puertos para cada nodo. A medida que aumente el número de nodos desde allí,
obtendrá menos puertos por nodo.
Para definir o aumentar el número de puertos de salida asignados, puede seguir el ejemplo siguiente:
az aks update \
--load-balancer-managed-outbound-ip-count 7 \
--load-balancer-outbound-ports 4000
Este ejemplo le daría 4000 puertos de salida asignados para cada nodo del clúster y, con 7 direcciones IP, tendría
4000 puertos por nodo * 100 nodos = 400 000 puertos totales < = 448 000 puertos totales = 7 IP * 64 000
puertos por IP. Esto le permite escalar de forma segura hasta 100 nodos y tener una operación de actualización
predeterminada. Es fundamental asignar suficientes puertos para los nodos adicionales necesarios para la
actualización y otras operaciones. De forma predeterminada, AKS se asigna a un nodo de búfer para la
actualización. En este ejemplo, se requieren 4000 puertos libres en cualquier momento dado. Si usa valores
maxSurge, multiplique los puertos de salida por nodo por el valor de maxSurge.
Para superar los 100 nodos con seguridad, tendría que agregar más direcciones IP.
IMPORTANT
Debe calcular la cuota necesaria y comprobar los requisitos antes de personalizar allocatedOutboundPorts para evitar
problemas de conectividad o escalado.
También puede usar los parámetros load-balancer-outbound-ports al crear un clúster, pero debe especificar
load-balancer-managed-outbound-ip-count , load-balancer-outbound-ips o load-balancer-outbound-ip-prefixes .
Por ejemplo:
az aks create \
--load-balancer-managed-outbound-ip-count 2 \
--load-balancer-outbound-ports 1024
Configuración del tiempo de espera de inactividad del equilibrador de carga

Cuando se agotan los recursos de los puertos SNAT, los flujos de salida generan errores hasta que los flujos ya
existentes liberan puertos SNAT. Load Balancer reclama puertos SNAT cuando el flujo se cierra y el equilibrador
de carga configurado con AKS usa un tiempo de espera de inactividad de 30 minutos para reclamar puertos
SNAT de los flujos inactivos. También puede usar transporte (por ejemplo, TCP keepalives ) o
application-layer keepalives para actualizar un flujo de inactividad y restablecer este tiempo de expiración en
caso necesario. Puede configurar este tiempo de expiración como en el ejemplo siguiente:
az aks update \
--load-balancer-idle-timeout 4
Si espera tener numerosas conexiones de corta duración, no hay ninguna conexión de larga duración y puede
tener tiempos de inactividad prolongados, como el uso de kubectl proxy o kubectl port-forward , considere el
uso de un valor de tiempo de expiración bajo, como 4 minutos. Además, al usar conexiones persistentes de TCP,
es suficiente habilitarlas en un lado de la conexión. Por ejemplo, es suficiente habilitarlas solo en el servidor para
restablecer el temporizador de inactividad del flujo y no se necesita que ambos lados inicien conexiones TCP
persistentes. Existen conceptos similares existen para la capa de aplicación, incluidas las configuraciones de
cliente/servidor de base de datos. Compruebe el lado del servidor para ver qué opciones existen para las
conexiones persistentes específicas de la aplicación.
IMPORTANT
AKS habilita el restablecimiento de TCP en modo inactivo de forma predeterminada y recomienda que mantenga esta
configuración y la aproveche para obtener un comportamiento de la aplicación más predecible en sus escenarios. TCP RST
solo se envía durante la conexión TCP en el estado ESTABLECIDO. Aquí encontrará más información.
Requisitos para personalizar los puertos de salida asignados y el tiempo de espera de inactividad
El valor que especifique para allocatedOutboundPorts también debe ser un múltiplo de 8.
Debe tener suficiente capacidad de IP de salida en función del número de VM de nodo y los puertos de salida
asignados que quiera. Para comprobar que tiene capacidad de IP de salida suficiente, use la fórmula
siguiente:
outboundIPs * 64 000 > nodeVMs * desiredAllocatedOutboundPorts.
Por ejemplo, si tiene 3 nodeVMs y 50 000 desiredAllocatedOutboundPorts, debe tener al menos 3 outboundIPs.
Se recomienda incorporar más capacidad de IP de salida de la necesaria. Además, debe tener en cuenta el
escalador automático del clúster y la posibilidad de que se produzcan actualizaciones del grupo de nodos al
calcular la capacidad de IP de salida. Para el escalador automático del clúster, revise el número de nodos actual y
el número máximo de nodos, y use el valor más alto. Para la actualización, tenga en cuenta una VM de nodo
adicional para cada grupo de nodos que permita la actualización.
Si establece IdleTimeoutInMinutes en un valor distinto del predeterminado de 30 minutos, tenga en cuenta el
tiempo que las cargas de trabajo necesitarán una conexión de salida. Tenga en cuenta también que el valor
de tiempo de espera predeterminado para un equilibrador de carga de SKU estándar usado fuera de AKS es
de 4 minutos. Un valor de IdleTimeoutInMinutes que refleje de forma más precisa su carga de trabajo de AKS
específica puede ayudar a reducir el agotamiento de SNAT causado por la vinculación de las conexiones ya
no se usan.
WARNING
La modificación de los valores de AllocatedOutboundPorts e IdleTimeoutInMinutes puede cambiar significativamente el
comportamiento de la regla de salida para el equilibrador de carga y no debe realizarse a la ligera sin comprender los
inconvenientes y los patrones de conexión de la aplicación. Consulte la sección Solución de problemas de SNAT que
aparece a continuación y revise las reglas de salida de Load Balancer y las conexiones salientes en Azure antes de
actualizar estos valores para comprender totalmente el impacto de los cambios.
Restricción del tráfico entrante a intervalos IP específicos

En el siguiente manifiesto se usa loadBalancerSourceRanges para especificar un nuevo intervalo IP para el
tráfico externo entrante:
apiVersion: v1
kind: Service
metadata:
spec:
type: LoadBalancer
ports:
- port: 80
selector:
loadBalancerSourceRanges:
- MY_EXTERNAL_IP_RANGE
NOTE
Los flujos de tráfico externos entrantes del equilibrador de carga a la red virtual para el clúster de AKS. La red virtual tiene
un grupo de seguridad de red (NSG) que permite todo el tráfico entrante desde el equilibrador de carga. Este NSG usa
una etiqueta de servicio de tipo LoadBalancer para permitir el tráfico desde el equilibrador de carga.
Mantenimiento de la dirección IP del cliente en las conexiones

entrantes
De forma predeterminada, un servicio de tipo LoadBalancer en Kubernetes y en AKS no conservará la dirección
IP del cliente en la conexión con el pod. La dirección IP de origen del paquete que se proporciona al pod será la
dirección IP privada del nodo. Para mantener la dirección IP del cliente, debe establecer
service.spec.externalTrafficPolicy en local en la definición del servicio. En el siguiente manifiesto se
muestra un ejemplo:
apiVersion: v1
kind: Service
metadata:
spec:
type: LoadBalancer
externalTrafficPolicy: Local
ports:
- port: 80
selector:
Personalizaciones adicionales mediante anotaciones de Kubernetes

A continuación, se muestra una lista de las anotaciones admitidas para los servicios de Kubernetes con el tipo
LoadBalancer . Estas anotaciones solo se aplican a flujos DE ENTRADA :
A N OTA C IÓ N VA L UE DESC RIP C IÓ N
service.beta.kubernetes.io/azure- true o false Especifique si el equilibrador de carga

load-balancer-internal debe ser interno. Si no se establece, el
valor predeterminado es público.
service.beta.kubernetes.io/azure- Nombre de la subred Especifique a qué subred se debe

load-balancer-internal-subnet enlazar el equilibrador de carga
interno. Si no se establece, el valor
predeterminado es la subred
configurada en el archivo de
configuración de la nube.
service.beta.kubernetes.io/azure- Nombre de la etiqueta DNS en Especifique el nombre de la etiqueta

dns-label-name direcciones IP públicas DNS para el servicio público . Si se
establece en una cadena vacía, no se
usará la entrada DNS de la dirección IP
pública.
service.beta.kubernetes.io/azure- true o false Especifique que el servicio debe

shared-securityrule exponerse mediante una regla de
seguridad de Azure que se pueda
compartir con otro servicio, con el fin
de definir la especificidad de las reglas
para un aumento en el número de
servicios que se pueden exponer. Esta
anotación depende de las característica
reglas de seguridad ampliadas de los
grupos de seguridad de red.
service.beta.kubernetes.io/azure- Nombre del grupo de recursos Especifique el grupo de recursos de

load-balancer-resource-group direcciones IP públicas del equilibrador
de carga que no están en el mismo
grupo de recursos que la
infraestructura de clúster (grupo de
recursos de nodo).
service.beta.kubernetes.io/azure- Lista de etiquetas de servicio Especifique una lista de etiquetas de

allowed-service-tags permitidas servicio permitidas separadas por
comas.
A N OTA C IÓ N VA L UE DESC RIP C IÓ N
service.beta.kubernetes.io/azure- Tiempo de expiración de inactividad de Especifique el tiempo, en minutos, para

load-balancer-tcp-idle-timeout TCP en minutos la expiración de inactividad de
conexión TCP en el equilibrador de
carga. El valor predeterminado y el
mínimo es 4. El valor máximo es 30.
Debe ser un entero.
service.beta.kubernetes.io/azure- true Deshabilite enableTcpReset para

load-balancer-disable-tcp-reset
SLB.
Solución de problemas de SNAT

Si sabe que se van a iniciar muchas conexiones TCP o UDP salientes a la misma dirección IP y puerto de destino,
y observa errores en las conexiones salientes, o el soporte técnico está avisando del agotamiento de los puertos
SNAT (puertos efímeros asignados previamente usados por PAT), dispone de varias opciones generales para
mitigar este problema. Revise estas opciones y vea cuál está disponible y resulta mejor para su escenario. Es
posible que una o varias de ellas puedan ayudar a administrar este escenario. Para obtener información
detallada, revise la guía de solución de problemas de conexiones salientes.
Con frecuencia, la causa principal del agotamiento de SNAT es un antipatrón de cómo se establece y administra
la conectividad de salida o cómo se cambian los temporizadores configurables de sus valores predeterminados.
Consulte detenidamente esta sección.
Pasos
1. Compruebe si las conexiones permanecen inactivas durante mucho tiempo y confíe en el tiempo de
expiración de inactividad predeterminado para liberar ese puerto. En tal caso, puede que el tiempo de
expiración predeterminado de 30 minutos se deba reducir para su escenario.
2. Investigue la forma en que la aplicación crea conectividad saliente (por ejemplo la revisión del código o la
captura de paquetes).
3. Determine si esta actividad es el comportamiento esperado o si la aplicación no se comporta correctamente.
Use las métricas y los registros de Azure Monitor para apoyar sus conclusiones. Use la categoría "Error" para
la métrica de conexiones SNAT como ejemplo.
4. Evalúe si se siguen los patrones adecuados.
5. Evalúe si el agotamiento de puertos SNAT debe mitigarse con direcciones IP de salida + puertos de salida
asignados adicionales .
Patrones de diseño
Aproveche la reutilización de las conexiones y la agrupación de conexiones siempre que sea posible. Estos
patrones evitarán problemas de agotamiento de los recursos y el resultado será un comportamiento predecible.
Las primitivas de estos patrones se pueden encontrar en muchas bibliotecas y marcos de desarrollo.
Las solicitudes atómicas (una solicitud por conexión) no suelen ser una buena decisión de diseño. Estos
límites de antipatrón escalan, reducen el rendimiento y disminuyen la confiabilidad. En su lugar, reutilice las
conexiones HTTP/S para reducir el número de conexiones y los puertos SNAT asociados. El escalado de la
aplicación aumentará y mejorará el rendimiento debido a la reducción de los protocolos de enlace, a la
sobrecarga y al costo de la operación criptográfica al usar TLS.
Si usa DNS personalizado o fuera del clúster, o los servidores ascendentes personalizados de coreDNS tienen
en cuenta que DNS puede introducir muchos flujos individuales en el volumen cuando el cliente no
almacena en caché el resultado de la resolución DNS. Asegúrese de personalizar coreDNS primero, en lugar
de usar servidores DNS personalizados y defina un buen valor de almacenamiento en caché.
Los flujos UDP (por ejemplo, las búsquedas de DNS) asignan puertos SNAT mientras dure el tiempo de
espera de inactividad. Cuanto mayor sea el tiempo de espera de inactividad, mayor será la presión sobre los
puertos SNAT. Use un tiempo de espera de inactividad corto (por ejemplo, 4 minutos). Use los grupos de
conexiones para dar forma al volumen de la conexión.
Nunca abandone de forma silenciosa un flujo TCP y confíe en temporizadores TCP para limpiar el flujo. Si no
permite que TCP cierre explícitamente la conexión, el estado permanecerá asignado en los sistemas y puntos
de conexión intermedios y hará que los puertos de SNAT no estén disponibles para otras conexiones. Este
patrón puede desencadenar errores en la aplicación y el agotamiento de SNAT.
No cambie los valores del temporizador relacionado con el cierre de TCP de nivel de sistema operativo sin el
conocimiento experto de impacto. Aunque la pila de TCP se recuperará, el rendimiento de la aplicación puede
verse afectado negativamente si los puntos de conexión de una conexión tienen expectativas no coincidentes.
El deseo de cambiar los temporizadores suele ser un signo de un problema de diseño subyacente. Revise las
siguientes recomendaciones.
En el ejemplo anterior se actualiza la regla para permitir solo el tráfico externo entrante del intervalo
MY_EXTERNAL_IP_RANGE. Si sustituye MY_EXTERNAL_IP_RANGE con la dirección IP de la subred interna, el
tráfico se restringe únicamente a las IP internas del clúster. Esto no permitirá que los clientes de fuera del clúster
de Kubernetes accedan al equilibrador de carga.
Traslado de un equilibrador de carga de la SKU básica a la SKU

estándar
Si tiene un clúster existente con el equilibrador de carga de SKU básica, existen diferencias de comportamiento
importantes que se deben tener en cuenta al migrar para usar un clúster con la SKU estándar.
Por ejemplo, la realización de implementaciones Blue-Green para migrar clústeres es una práctica común, dado
que el tipo load-balancer-sku de un clúster solo se puede definir en el momento de la creación del clúster. Sin
embargo, los equilibradores de carga de SKU básica usan direcciones IP de SKU básica que no son compatibles
con los equilibradores de carga de SKU estándar, que requieren direcciones IP de SKU estándar. Al migrar
clústeres para actualizar las SKU del equilibrador de carga, se necesitará una nueva dirección IP con una SKU de
dirección IP compatible.
Para conocer más detalles sobre cómo migrar clústeres, consulte nuestra documentación con consideraciones
sobre la migración para ver una lista de temas importantes que se deben tener en cuenta al realizar una
migración. Las siguientes limitaciones son también diferencias de comportamiento importantes que se deben
tener en cuenta al usar equilibradores de carga de SKU estándar en AKS.
Limitaciones
Las siguientes limitaciones se aplican al crear y administrar clústeres de AKS que admiten un equilibrador de
carga con la SKU estándar:
Se requiere al menos una dirección IP pública o un prefijo de dirección IP pública para permitir el tráfico de
salida del clúster de AKS. Esta dirección IP o el prefijo de dirección IP pública son necesarios para mantener la
conectividad entre el plano de control y los nodos de agente, así como para mantener la compatibilidad con
versiones anteriores de AKS. Tiene las siguientes opciones para especificar direcciones IP o prefijos de
dirección IP pública con un equilibrador de carga de SKU estándar:
Proporcione sus propias IP públicas.
Proporcione sus propios prefijos de dirección IP pública.
Especifique un número hasta 100 para permitir que el clúster de AKS cree esa cantidad de direcciones
IP públicas de SKU estándar en el mismo grupo de recursos que se creó como el clúster de AKS, que
normalmente se denomina con MC_ al principio. AKS asigna la dirección IP pública al equilibrador de
carga de SKU estándar. De forma predeterminada, se creará automáticamente una IP pública en el
mismo grupo de recursos que el clúster de AKS, si no se especifica ninguna dirección IP pública,
prefijo de dirección IP pública o número de direcciones IP. Asimismo, debe permitir las direcciones
públicas y evitar la creación de cualquier directiva de Azure Policy que prohíba la creación de
direcciones IP.
Una dirección IP pública creada con AKS no se puede volver a usar como dirección IP pública propia
personalizada. El usuario debe crear y administrar todas las direcciones IP públicas personalizadas.
La definición de la SKU del equilibrador de carga solo puede realizarse cuando se crea un clúster de AKS. No
se puede cambiar la SKU del equilibrador de carga una vez creado un clúster de AKS.
Solo se puede usar un tipo de SKU de equilibrador de carga (básica o estándar) en un único clúster.
Los equilibradores de carga de SKU estándar solo admiten direcciones IP de SKU estándar.
Pasos siguientes
Más información sobre los servicios de Kubernetes en la documentación de servicios de Kubernetes.
Obtenga más información sobre el uso de una instancia de Load Balancer interna para el tráfico de entrada en la
documentación de la instancia de Load Balancer interna de AKS.
Uso de una dirección IP pública estática y una
etiqueta DNS con el equilibrador de carga de Azure
De forma predeterminada, la dirección IP pública asignada a un recurso de equilibrador de carga creado por un
clúster de AKS solo es válida para la duración de ese recurso. Si elimina el servicio de Kubernetes, el
equilibrador de carga asociado y la dirección IP también se eliminan. Si quiere asignar una dirección IP
específica o conservar una dirección IP para los servicios de Kubernetes reimplementados, puede crear y usar
una dirección IP pública estática.
En este artículo se muestra cómo crear una dirección IP pública estática y asignarla al servicio de Kubernetes.
Antes de empezar
Azure.
En este artículo se describe el uso de una dirección IP de SKU Estándar con un equilibrador de carga de SKU
Estándar. Para más información, consulte Tipos de direcciones IP y métodos de asignación en Azure.
Crear una dirección IP estática

Cree una dirección IP pública estática con el comando az network public ip create. A continuación se crea un
recurso de IP estática denominado myAKSPublicIP en el grupo de recursos myResourceGroup:
az network public-ip create \

--name myAKSPublicIP \
--sku Standard \
--allocation-method static
NOTE
Si usa un equilibrador de carga de SKU Básico en el clúster de AKS, use Basic para el parámetro SKU al definir una
dirección IP pública. Solo las direcciones IP de SKU Básicas funcionan con el equilibrador de carga de SKU Básico y solo las
IP de SKU Estándar funcionan con los equilibradores de carga de SKU Estándar.
Se muestra la dirección IP, como se indica en esta salida de ejemplo reducido:

{
"publicIp": {
...
"ipAddress": "40.121.183.52",
...
}
}
Después puede obtener la dirección IP pública mediante el comando az network public-ip list. Especifique el
nombre del grupo de recursos del nodo y la dirección IP pública creados y envíe una consulta para ipAddress,
como se muestra en este ejemplo:
$ az network public-ip show --resource-group myResourceGroup --name myAKSPublicIP --query ipAddress --output
tsv
40.121.183.52
Crear un servicio mediante la dirección IP estática

Antes de crear un servicio, compruebe que la identidad de clúster que usa el clúster de AKS tenga permisos
delegados para el otro grupo de recursos. Por ejemplo:
az role assignment create \

--assignee <Client ID> \
--role "Network Contributor" \
--scope /subscriptions/<subscription id>/resourceGroups/<resource group name>
IMPORTANT
Si ha personalizado la dirección IP de salida, asegúrese de que la identidad del clúster tenga permisos tanto para la
dirección IP pública de salida como para esta dirección IP pública de entrada.
Para crear un servicio LoadBalancer con la dirección IP pública estática, agregue la propiedad loadBalancerIP y
el valor de la dirección IP pública estática al manifiesto YAML. Cree un archivo denominado
load-balancer-service.yaml y cópielo en el siguiente código YAML. Indique su propia dirección IP pública que
creó en el paso anterior. En el ejemplo siguiente también se establece el grupo de recursos denominado
myResourceGroup. Indique su propio nombre del grupo de recursos.
apiVersion: v1
kind: Service
metadata:
annotations:
service.beta.kubernetes.io/azure-load-balancer-resource-group: myResourceGroup
name: azure-load-balancer
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: azure-load-balancer
Cree el servicio y la implementación con el comando kubectl apply .

kubectl apply -f load-balancer-service.yaml
Aplicación de una etiqueta DNS al servicio

Si el servicio usa una dirección IP pública dinámica o estática, puede usar la anotación de servicio
service.beta.kubernetes.io/azure-dns-label-name para establecer una etiqueta DNS de acceso público. Esta
acción publica un nombre de dominio completo para el servicio mediante los servidores DNS públicos de Azure
y el dominio de nivel superior. El valor de la anotación debe ser único dentro de la ubicación de Azure, por lo
que se recomienda usar una etiqueta suficientemente descriptiva.
A continuación, Azure anexará automáticamente una subred predeterminada, como
<location>.cloudapp.azure.com (donde location es la región seleccionada), al nombre que proporcione para
crear el nombre DNS completo. Por ejemplo:
apiVersion: v1
kind: Service
metadata:
annotations:
service.beta.kubernetes.io/azure-dns-label-name: myserviceuniquelabel
name: azure-load-balancer
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: azure-load-balancer
NOTE
Para publicar el servicio en su propio dominio, consulte Azure DNS y el proyecto external-dns.
Si la dirección IP estática definida en la propiedad loadBalancerIP del manifiesto de servicio de Kubernetes no
existe o no se ha creado en el grupo de recursos del nodo y no se han configurado delegaciones adicionales, se
produce un error en la creación del servicio del equilibrador de carga. Para solucionar este problema, revise los
eventos de creación del servicio con el comando kubectl describe. Indique el nombre del servicio tal y como
aparece en el manifiesto de YAML, como se muestra en este ejemplo:
kubectl describe service azure-load-balancer
Se muestra información sobre el recurso de servicio de Kubernetes. Los Eventos al final de la salida de este
ejemplo indican que no se encontró la dirección IP proporcionada por el usuario. En estos casos, compruebe que
ha creado la dirección IP pública estática en el grupo de recursos del nodo y que la dirección IP especificada en
el manifiesto de servicio de Kubernetes es correcta.
Name: azure-load-balancer
Namespace: default
Labels: <none>
Annotations: <none>
Selector: app=azure-load-balancer
Type: LoadBalancer
IP: 10.0.18.125
IP: 40.121.183.52
Port: <unset> 80/TCP
TargetPort: 80/TCP
NodePort: <unset> 32582/TCP
Endpoints: <none>
Session Affinity: None
External Traffic Policy: Cluster
Events:
---- ------ ---- ---- -------
Normal CreatingLoadBalancer 7s (x2 over 22s) service-controller Creating load balancer
Warning CreatingLoadBalancerFailed 6s (x2 over 12s) service-controller Error creating load balancer
(will retry): Failed to create load balancer for service default/azure-load-balancer: user supplied IP
Address 40.121.183.52 was not found
Pasos siguientes
Para un control adicional sobre el tráfico de red a las aplicaciones, puede ser conveniente crear un controlador
de entrada. También puede crear un controlador de entrada con una dirección IP pública estática.
Creación de un controlador de entrada en Azure
Un controlador de entrada es un software que proporciona el proxy inverso, el enrutamiento del tráfico
configurable y la terminación de TLS para los servicios de Kubernetes. Los recursos de entrada de Kubernetes se
usan para configurar las reglas de entrada y las rutas de los distintos servicios de Kubernetes. Mediante reglas
de entrada y un controlador de entrada, se puede usar una sola dirección IP para enrutar el tráfico a varios
servicios en un clúster de Kubernetes.
En este artículo se muestra cómo implementar el controlador de entrada NGINX en un clúster de Azure
Kubernetes Service (AKS). Se ejecutan dos aplicaciones en el clúster de AKS, a las que se puede acceder con una
sola dirección IP.
También puede:
Antes de empezar
Este artículo usa Helm 3 para instalar el controlador de entrada NGINX. Asegúrese de usar la versión más
reciente de Helm y de tener acceso al repositorio ingress-nginx de Helm.
En este artículo también se requiere que ejecute la versión 2.0.64 de la CLI de Azure o una versión posterior.
Azure.
Crear un controlador de entrada

Para crear el controlador de entrada, use Helm para instalar nginx-ingress. Para obtener redundancia adicional,
se implementan dos réplicas de los controladores de entrada NGINX con el parámetro
--set controller.replicaCount . Para sacar el máximo provecho de las réplicas en ejecución del controlador de
entrada, asegúrese de que hay más de un nodo en el clúster de AKS.
El controlador de entrada también debe programarse en un nodo de Linux. Los nodos de Windows Server no
deben ejecutar el controlador de entrada. Un selector de nodos se especifica mediante el parámetro
--set nodeSelector para indicar al programador de Kubernetes que ejecute el controlador de entrada NGINX en
un nodo basado en Linux.
TIP
En el siguiente ejemplo se crea un espacio de nombres de Kubernetes para los recursos de entrada denominado ingress-
basic. Especifique un espacio de nombres para su propio entorno según sea necesario.
TIP
Si quiere habilitar la conservación de direcciones IP de origen del cliente para las solicitudes a los contenedores de su
clúster, agregue --set controller.service.externalTrafficPolicy=Local al comando de instalación de Helm. La
dirección IP de origen del cliente se almacena en el encabezado de la solicitud en X-Forwarded-For. Al usar un controlador
de entrada con la conservación de direcciones IP de origen del cliente habilitada, el paso a través de SSL no funcionará.
# Create a namespace for your ingress resources

kubectl create namespace ingress-basic
# Add the ingress-nginx repository

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
# Use Helm to deploy an NGINX ingress controller

helm install nginx-ingress ingress-nginx/ingress-nginx \
--namespace ingress-basic \
--set controller.replicaCount=2 \
--set controller.nodeSelector."beta\.kubernetes\.io/os"=linux \
--set defaultBackend.nodeSelector."beta\.kubernetes\.io/os"=linux \
--set controller.admissionWebhooks.patch.nodeSelector."beta\.kubernetes\.io/os"=linux
Cuando se crea el servicio del equilibrador de carga de Kubernetes para el controlador de entrada NGINX, se
asigna la dirección IP pública dinámica, como se muestra en la salida del ejemplo siguiente:
$ kubectl --namespace ingress-basic get services -o wide -w nginx-ingress-ingress-nginx-controller
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)

AGE SELECTOR
nginx-ingress-ingress-nginx-controller LoadBalancer 10.0.74.133 EXTERNAL_IP
80:32486/TCP,443:30953/TCP 44s app.kubernetes.io/component=controller,app.kubernetes.io/instance=nginx-
ingress,app.kubernetes.io/name=ingress-nginx
No se han creado reglas de entrada aún, por lo que aparece la página 404 predeterminada del controlador de
entrada NGINX si navega a la dirección IP interna. Las reglas de entrada se configuran en los pasos siguientes.
Ejecución de aplicaciones de demostración

Para ver el controlador de entrada en acción, ejecute dos aplicaciones de demostración en el clúster de AKS. En
este ejemplo, use kubectl apply para implementar dos instancias de una aplicación Hola mundo sencilla.
Cree un archivo aks-helloworld-one.yaml y cópielo en el ejemplo siguiente de YAML:
apiVersion: apps/v1
kind: Deployment
metadata:
name: aks-helloworld-one
spec:
replicas: 1
selector:
matchLabels:
app: aks-helloworld-one
template:
metadata:
labels:
spec:
containers:
- name: aks-helloworld-one
image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
ports:
- containerPort: 80
env:
- name: TITLE
value: "Welcome to Azure Kubernetes Service (AKS)"
---
apiVersion: v1
kind: Service
metadata:
spec:
type: ClusterIP
ports:
- port: 80
selector:
Cree un archivo aks-helloworld-two.yaml y cópielo en el ejemplo siguiente de YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
name: aks-helloworld-two
spec:
replicas: 1
selector:
matchLabels:
app: aks-helloworld-two
template:
metadata:
labels:
spec:
containers:
- name: aks-helloworld-two
ports:
- containerPort: 80
env:
- name: TITLE
value: "AKS Ingress Demo"
---
apiVersion: v1
kind: Service
metadata:
spec:
type: ClusterIP
ports:
- port: 80
selector:
Ejecute las dos aplicaciones de demostración mediante kubectl apply :
kubectl apply -f aks-helloworld-one.yaml --namespace ingress-basic

kubectl apply -f aks-helloworld-two.yaml --namespace ingress-basic
Creación de una ruta de entrada

Ambas aplicaciones ahora se ejecutan en el clúster de Kubernetes. Para enrutar el tráfico a cada aplicación, cree
un recurso de entrada de Kubernetes. El recurso de entrada configura las reglas de enrutamiento del tráfico a
una de las dos aplicaciones.
En el ejemplo siguiente, el tráfico a la dirección EXTERNAL_IP se enruta al servicio denominado
aks-helloworld-one . El tráfico a la dirección EXTERNAL_IP/hello-world-two se enruta al servicio
aks-helloworld-two . El tráfico a la dirección EXTERNAL_IP/static se enruta al servicio denominado
aks-helloworld-one para los recursos estáticos.
Cree un archivo denominado hello-world-ingress.yaml y cópielo en el ejemplo siguiente de YAML.

kind: Ingress
metadata:
name: hello-world-ingress
namespace: ingress-basic
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/ssl-redirect: "false"
nginx.ingress.kubernetes.io/use-regex: "true"
nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
rules:
- http:
paths:
- path: /hello-world-one(/|$)(.*)
pathType: Prefix
backend:
service:
port:
number: 80
- path: /hello-world-two(/|$)(.*)
pathType: Prefix
backend:
service:
port:
number: 80
- path: /(.*)
pathType: Prefix
backend:
service:
port:
number: 80
---
kind: Ingress
metadata:
name: hello-world-ingress-static
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /static/$2
spec:
rules:
- http:
paths:
- path:
pathType: Prefix
backend:
service:
port:
number: 80
path: /static(/|$)(.*)
Cree el recurso de entrada con el comando kubectl apply -f hello-world-ingress.yaml .
$ kubectl apply -f hello-world-ingress.yaml
ingress.extensions/hello-world-ingress created
ingress.extensions/hello-world-ingress-static created
Prueba del controlador de entrada
Para probar las rutas para el controlador de entrada, vaya a las dos aplicaciones. Abra un explorador web en la
dirección IP de su controlador de entrada NGINX, como EXTERNAL_IP. La primera aplicación de demostración
aparece en el explorador web, como se muestra en el ejemplo siguiente:
A continuación, agregue la ruta de acceso /hello-world-two a la dirección IP, como EXTERNAL_IP/hello-world-

two. Se muestra la segunda aplicación de demostración con el título personalizado:
En este artículo, se usa Helm para instalar los componentes de entrada y las aplicaciones de ejemplo. Al
implementar un gráfico de Helm, se crean algunos recursos de Kubernetes. Estos recursos incluyen pods,
implementaciones y servicios. Para limpiar estos recursos, puede eliminar el espacio de nombres de ejemplo
completo o los recursos individuales.
Eliminación del espacio de nombres de ejemplo y de todos los recursos
Para eliminar el espacio de nombres de ejemplo completo, use el comando kubectl delete y especifique el
nombre del espacio de nombres. Todos los recursos del espacio de nombres se eliminan.
kubectl delete namespace ingress-basic
Eliminación de recursos individualmente

Como alternativa, un enfoque más pormenorizado consiste en eliminar los recursos individuales creados.
Despliegue una lista de las versiones de Helm con el comando helm list . Busque los gráficos denominados
nginx-ingress y aks-helloworld, tal y como se muestra en la salida del ejemplo siguiente:
$ helm list --namespace ingress-basic
NAME NAMESPACE REVISION UPDATED STATUS

CHART APP VERSION
nginx-ingress ingress-basic 1 2020-01-06 19:55:46.358275 -0600 CST deployed
nginx-ingress-1.27.1 0.26.1
Desinstale las versiones con el comando helm uninstall . En el ejemplo siguiente se desinstala la
implementación de entrada de NGINX.
$ helm uninstall nginx-ingress --namespace ingress-basic
release "nginx-ingress" uninstalled
Luego, quitar las dos aplicaciones de ejemplo:
kubectl delete -f aks-helloworld-one.yaml --namespace ingress-basic

kubectl delete -f aks-helloworld-two.yaml --namespace ingress-basic
Elimine la ruta de entrada que dirige el tráfico a las aplicaciones de ejemplo:
kubectl delete -f hello-world-ingress.yaml
Por último, puede eliminar el propio espacio de nombres. Use el comando kubectl delete y especifique el
nombre del espacio de nombres:
Pasos siguientes
En este artículo se incluyen algunos componentes externos a AKS. Para más información sobre estos
componentes, consulte las siguientes páginas del proyecto:
CLI de Helm
Controlador de entrada NGINX
También puede:
Enrutamiento de aplicación HTTP
La solución de enrutamiento de aplicación HTTP facilita el acceso a las aplicaciones implementadas en el clúster
de Azure Kubernetes Service (AKS). Cuando se habilita la solución, configura un controlador de entrada en el
clúster de AKS. A medida que se implementan aplicaciones, la solución también crea nombres DNS accesibles
públicamente para los puntos de conexión de aplicación.
Cuando se habilita el complemento, crea una zona DNS en su suscripción. Para más información sobre el costo
de DNS, consulte los precios de DNS.
Cau t i on
El complemento de enrutamiento de aplicaciones HTTP está diseñado para permitirle crear rápidamente un
controlador de entrada y acceder a sus aplicaciones. Este complemento no está diseñado actualmente para su
uso en un entorno de producción y no se recomienda usarlo en el mismo. Para información sobre las
implementaciones de entrada listas para producción, consulte Creación de un controlador de entrada HTTPS.
Introducción a la solución de enrutamiento HTTP

El complemento implementa dos componentes, un controlador de entrada de Kubernetes y un controlador DNS
externo.
Controlador de entrada : el controlador de entrada está expuesto a Internet a través de un servicio de
Kubernetes de tipo equilibrador de carga. El controlador de entrada supervisa e implementa recursos de
entrada de Kubernetes, lo que crea rutas a los puntos de conexión de aplicación.
Controlador DNS externo : inspecciona los recursos de entrada de Kubernetes y crea registros A de DNS
en la zona DNS específica del clúster.
Implementación del enrutamiento HTTP: CLI

El complemento de enrutamiento de aplicación HTTP se puede habilitar con la CLI de Azure al implementar un
clúster de AKS. Para hacerlo, use el comando az aks create con el argumento --enable-addons .
az aks create --resource-group myResourceGroup --name myAKSCluster --enable-addons http_application_routing
TIP
Si desea habilitar varios complementos, debe proporcionarlos como una lista separada por comas. Por ejemplo, para
habilitar la supervisión y el enrutamiento de solicitudes HTTP, use el formato
--enable-addons http_application_routing,monitoring .
También puede habilitar el enrutamiento de HTTP en un clúster de AKS existente mediante el comando az aks
enable-addons. Para habilitar el enrutamiento de HTTP en un clúster existente, agregue el parámetro --addons y
especifique http_application_routing tal como se muestra en el ejemplo siguiente:
az aks enable-addons --resource-group myResourceGroup --name myAKSCluster --addons http_application_routing
Después de implementar o actualizar el clúster, use el comando az aks show para recuperar el nombre de la
zona DNS.
az aks show --resource-group myResourceGroup --name myAKSCluster --query
addonProfiles.httpApplicationRouting.config.HTTPApplicationRoutingZoneName -o table
Este nombre es necesario para implementar aplicaciones en el clúster de AKS y se muestra en la siguiente salida
de ejemplo:
9f9c1fe7-21a1-416d-99cd-3543bb92e4c3.eastus.aksapp.io
Implementación del enrutamiento HTTP: Portal

El complemento de enrutamiento de aplicación HTTP se puede habilitar mediante Azure Portal al implementar
un clúster de AKS.
Después de implementar el clúster, vaya al grupo de recursos de AKS que se creó automáticamente y seleccione
la zona DNS. Tome nota del nombre de la zona DNS. Este nombre es necesario para implementar aplicaciones
en el clúster de AKS.
Conectarse al clúster AKS
Para conectarse al clúster de Kubernetes desde su equipo local, use kubectl, el cliente de la línea de comandos de
Kubernetes.
Si usa Azure Cloud Shell, kubectl ya está instalado. También lo puede instalar localmente. Para ello debe usar el
comando az aks install-cli:
az aks install-cli
Para configurar kubectl para conectarse a su clúster de Kubernetes, use el comando az aks get-credentials. En
el ejemplo siguiente se obtienen las credenciales del clúster de AKS llamado MyAKSCluster en el grupo de
recursos MyResourceGroup:
az aks get-credentials --resource-group MyResourceGroup --name MyAKSCluster
Uso del enrutamiento HTTP

La solución de enrutamiento de aplicación HTTP solo se puede desencadenar en los recursos de entrada que se
anotan como sigue:
annotations:
kubernetes.io/ingress.class: addon-http-application-routing
Cree un archivo denominado samples-http-application-routing.yaml y cópielo en el siguiente código

YAML. En la línea 43, actualice <CLUSTER_SPECIFIC_DNS_ZONE> con el nombre de la zona DNS que se recopiló en el
paso anterior de este artículo.
apiVersion: apps/v1
kind: Deployment
metadata:
name: aks-helloworld
spec:
replicas: 1
selector:
matchLabels:
app: aks-helloworld
template:
metadata:
labels:
app: aks-helloworld
spec:
containers:
- name: aks-helloworld
ports:
- containerPort: 80
env:
- name: TITLE
---
apiVersion: v1
kind: Service
metadata:
spec:
type: ClusterIP
ports:
- port: 80
selector:
app: aks-helloworld
---
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: addon-http-application-routing
spec:
rules:
- host: aks-helloworld.<CLUSTER_SPECIFIC_DNS_ZONE>
http:
paths:
- path: /
pathType: Prefix
backend:
service:
port:
number: 80
Utilice el comando kubectl apply para crear los recursos.
kubectl apply -f samples-http-application-routing.yaml
En el siguiente ejemplo se muestran los recursos creados:

$ kubectl apply -f samples-http-application-routing.yaml
deployment.apps/aks-helloworld created
service/aks-helloworld created
ingress.networking.k8s.io/aks-helloworld created
Abra un explorador web a aks-helloworld.<CLUSTER_SPECIFIC_DNS_ZONE> , por ejemplo aks-

helloworld.9f9c1fe7-21a1-416d-99cd-3543bb92e4c3.eastus.aksapp.io y compruebe que ve la aplicación demo.
La aplicación puede tardar unos minutos en aparecer.
Eliminación del enrutamiento HTTP

La solución de enrutamiento HTTP se puede eliminar mediante la CLI de Azure. Para ello, ejecute el siguiente
comando, sustituyendo su clúster de AKS y el nombre del grupo de recursos.
az aks disable-addons --addons http_application_routing --name myAKSCluster --resource-group myResourceGroup

--no-wait
Cuando se deshabilita el complemento de enrutamiento de aplicación HTTP, algunos recursos de Kubernetes

pueden permanecer en el clúster. Estos recursos incluyen a los archivos configMaps y a los secretos y se crean
en el espacio de nombres kube-system. Para mantener un clúster limpio, es posible que quiera quitar estos
recursos.
Busque los recursos addon-http-application-routing con los siguientes comandos kubectl get:
kubectl get deployments --namespace kube-system

kubectl get services --namespace kube-system
kubectl get configmaps --namespace kube-system
kubectl get secrets --namespace kube-system
La salida del ejemplo siguiente muestra los archivos configMaps que deben eliminarse:
$ kubectl get configmaps --namespace kube-system
NAMESPACE NAME DATA AGE

kube-system addon-http-application-routing-nginx-configuration 0 9m7s
kube-system addon-http-application-routing-tcp-services 0 9m7s
kube-system addon-http-application-routing-udp-services 0 9m7s
Para eliminar los recursos, use el comando kubectl delete. Especifique el tipo de recurso, el nombre del recurso y
el espacio de nombres. En el ejemplo siguiente se elimina uno de los archivos configmaps anteriores:
kubectl delete configmaps addon-http-application-routing-nginx-configuration --namespace kube-system
Repita el paso kubectl delete anterior para todos los recursos addon-http-application-routing que aún se
encuentran en el clúster.
Use el comando kubectl logs para ver los registros de aplicación para la aplicación de DNS externo. Los registros
deben confirmar que crearon correctamente unos registros DNS A y TXT.
$ kubectl logs -f deploy/addon-http-application-routing-external-dns -n kube-system
time="2018-04-26T20:36:19Z" level=info msg="Updating A record named 'aks-helloworld' to

'52.242.28.189' for Azure DNS zone '471756a6-e744-4aa0-aa01-89c4d162a7a7.canadaeast.aksapp.io'."
time="2018-04-26T20:36:21Z" level=info msg="Updating TXT record named 'aks-helloworld' to
'"heritage=external-dns,external-dns/owner=default"' for Azure DNS zone '471756a6-e744-4aa0-aa01-
89c4d162a7a7.canadaeast.aksapp.io'."
Estos registros también se pueden ver en el recurso de zona DNS en Azure Portal.
Use el comando kubectl logs para ver los registros de aplicación para el controlador de entrada Nginx. Los
registros deben confirmar la CREATE de un recurso de entrada y la recarga del controlador. Se registra toda la
actividad HTTP.
$ kubectl logs -f deploy/addon-http-application-routing-nginx-ingress-controller -n kube-system
-------------------------------------------------------------------------------
NGINX Ingress controller
Release: 0.13.0
Build: git-4bc943a
Repository: https://github.com/kubernetes/ingress-nginx
-------------------------------------------------------------------------------
I0426 20:30:12.212936 9 flags.go:162] Watching for ingress class: addon-http-application-routing

W0426 20:30:12.213041 9 flags.go:165] only Ingress with class "addon-http-application-routing" will be
processed by this ingress controller
W0426 20:30:12.213505 9 client_config.go:533] Neither --kubeconfig nor --master was specified. Using
the inClusterConfig. This might not work.
I0426 20:30:12.213752 9 main.go:181] Creating API client for https://10.0.0.1:443
I0426 20:30:12.287928 9 main.go:225] Running in Kubernetes Cluster version v1.8 (v1.8.11) - git
(clean) commit 1df6a8381669a6c753f79cb31ca2e3d57ee7c8a3 - platform linux/amd64
I0426 20:30:12.290988 9 main.go:84] validated kube-system/addon-http-application-routing-default-http-
backend as the default backend
I0426 20:30:12.294314 9 main.go:105] service kube-system/addon-http-application-routing-nginx-ingress
validated as source of Ingress status
I0426 20:30:12.426443 9 stat_collector.go:77] starting new nginx stats collector for Ingress
controller running in namespace (class addon-http-application-routing)
I0426 20:30:12.426509 9 stat_collector.go:78] collector extracting information from port 18080
I0426 20:30:12.448779 9 nginx.go:281] starting Ingress controller
I0426 20:30:12.463585 9 event.go:218] Event(v1.ObjectReference{Kind:"ConfigMap", Namespace:"kube-
system", Name:"addon-http-application-routing-nginx-configuration", UID:"2588536c-4990-11e8-a5e1-
0a58ac1f0ef2", APIVersion:"v1", ResourceVersion:"559", FieldPath:""}): type: 'Normal' reason: 'CREATE'
ConfigMap kube-system/addon-http-application-routing-nginx-configuration
system", Name:"addon-http-application-routing-tcp-services", UID:"258ca065-4990-11e8-a5e1-0a58ac1f0ef2",
APIVersion:"v1", ResourceVersion:"561", FieldPath:""}): type: 'Normal' reason: 'CREATE' ConfigMap kube-
system/addon-http-application-routing-tcp-services
system", Name:"addon-http-application-routing-udp-services", UID:"259023bc-4990-11e8-a5e1-0a58ac1f0ef2",
APIVersion:"v1", ResourceVersion:"562", FieldPath:""}): type: 'Normal' reason: 'CREATE' ConfigMap kube-
system/addon-http-application-routing-udp-services
I0426 20:30:13.649195 9 nginx.go:302] starting NGINX process...
I0426 20:30:13.649347 9 leaderelection.go:175] attempting to acquire leader lease kube-
system/ingress-controller-leader-addon-http-application-routing...
I0426 20:30:13.649776 9 controller.go:170] backend reload required
I0426 20:30:13.649800 9 stat_collector.go:34] changing prometheus collector from to default
I0426 20:30:13.662191 9 leaderelection.go:184] successfully acquired lease kube-system/ingress-
controller-leader-addon-http-application-routing
I0426 20:30:13.662292 9 status.go:196] new leader elected: addon-http-application-routing-nginx-
ingress-controller-5cxntd6
I0426 20:30:13.763362 9 controller.go:179] ingress backend successfully reloaded...
I0426 21:51:55.249327 9 event.go:218] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"default",
Name:"aks-helloworld", UID:"092c9599-499c-11e8-a5e1-0a58ac1f0ef2", APIVersion:"extensions",
ResourceVersion:"7346", FieldPath:""}): type: 'Normal' reason: 'CREATE' Ingress default/aks-helloworld
W0426 21:51:57.908771 9 controller.go:775] service default/aks-helloworld does not have any active
endpoints
I0426 21:51:57.908951 9 controller.go:170] backend reload required
I0426 21:51:58.042932 9 controller.go:179] ingress backend successfully reloaded...
167.220.24.46 - [167.220.24.46] - - [26/Apr/2018:21:53:20 +0000] "GET / HTTP/1.1" 200 234 "" "Mozilla/5.0
(compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 197 0.001 [default-aks-helloworld-80] 10.244.0.13:8080
234 0.004 200
Limpieza
Quite los objetos Kubernetes asociados creados en este artículo mediante kubectl delete .
kubectl delete -f samples-http-application-routing.yaml

En la salida del ejemplo se muestra que los objetos Kubernetes se han quitado.
$ kubectl delete -f samples-http-application-routing.yaml
deployment "aks-helloworld" deleted

service "aks-helloworld" deleted
ingress "aks-helloworld" deleted
Pasos siguientes
Para más información sobre cómo instalar un controlador de entrada protegido con HTTPS en AKS,
consulteEntrada HTTPS en Azure Kubernetes Service (AKS).
Creación de un controlador de entrada para una
red virtual interna en Azure Kubernetes Service
(AKS)
Kubernetes Service (AKS). El controlador de entrada está configurado en una red virtual y una dirección IP
privada e interna. No se permite ningún acceso externo. Se ejecutan dos aplicaciones en el clúster de AKS, a las
que se puede acceder con una sola dirección IP.
También puede:
Antes de empezar
Este artículo usa Helm 3 para instalar el controlador de entrada NGINX. Asegúrese de usar la versión más
reciente de Helm y de tener acceso al repositorio ingress-nginx de Helm. Para obtener más información sobre
cómo configurar y usar Helm, consulte Instalación de aplicaciones con Helm en Azure Kubernetes Service (AKS).
Azure.

De manera predeterminada, se crea un controlador de entrada NGINX con una asignación de dirección IP
pública y dinámica. Un requisito de configuración común es usar una red y una dirección IP internas y privadas.
Este enfoque permite restringir el acceso a los servicios a los usuarios internos, sin acceso externo.
Cree un archivo denominado internal-ingress.yaml mediante el siguiente archivo de manifiesto de ejemplo. Este
ejemplo asigna 10.240.0.42 al recurso loadBalancerIP. Proporcione su propia dirección IP interna para su uso
con el controlador de entrada. Asegúrese de que esta dirección IP no está ya en uso dentro de la red virtual.
Además, si usa una red virtual y una subred existentes, debe configurar el clúster de AKS con los permisos
correctos para administrarlas. Para más información, consulte Uso de redes kubenet con intervalos de
direcciones IP propios en Azure Kubernetes Service (AKS) o Configuración de redes de Azure CNI en Azure
controller:
service:
annotations:
Ahora implemente el gráfico nginx-ingress con Helm. Para usar el archivo de manifiesto que creó en el paso
anterior, agregue el parámetro -f internal-ingress.yaml : Para obtener redundancia adicional, se implementan
dos réplicas de los controladores de entrada NGINX con el parámetro --set controller.replicaCount . Para sacar
el máximo provecho de las réplicas en ejecución del controlador de entrada, asegúrese de que hay más de un
nodo en el clúster de AKS.
TIP
basic. Especifique un espacio de nombres para su propio entorno según sea necesario. Si su clúster de AKS no tiene RBAC
de Kubernetes habilitado, agregue --set rbac.create=false a los comandos de Helm.
TIP
de entrada con la conservación de direcciones IP de origen del cliente habilitada, el paso a través de TLS no funciona.



-f internal-ingress.yaml \
asigna la dirección IP interna. Para obtener la dirección IP pública, use el comando kubectl get service .
kubectl --namespace ingress-basic get services -o wide -w nginx-ingress-ingress-nginx-controller
Se tarda unos minutos en asignar la dirección IP al servicio, tal como se muestra en la salida de ejemplo
siguiente:

AGE SELECTOR

este ejemplo, usar kubectl apply para implementar dos instancias de una aplicación Hola mundo sencilla.
Crear un archivo aks-helloworld.yaml y copiarlo en el ejemplo siguiente de YAML:
apiVersion: apps/v1
kind: Deployment
metadata:
spec:
replicas: 1
selector:
matchLabels:
app: aks-helloworld
template:
metadata:
labels:
app: aks-helloworld
spec:
containers:
ports:
- containerPort: 80
env:
- name: TITLE
---
apiVersion: v1
kind: Service
metadata:
spec:
type: ClusterIP
ports:
- port: 80
selector:
app: aks-helloworld
Crear un archivo ingress-demo.yaml y copiarlo en el ejemplo siguiente de YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
name: ingress-demo
spec:
replicas: 1
selector:
matchLabels:
app: ingress-demo
template:
metadata:
labels:
app: ingress-demo
spec:
containers:
- name: ingress-demo
ports:
- containerPort: 80
env:
- name: TITLE
---
apiVersion: v1
kind: Service
metadata:
name: ingress-demo
spec:
type: ClusterIP
ports:
- port: 80
selector:
app: ingress-demo
Ejecutar las dos aplicaciones de demostración mediante kubectl apply :
kubectl apply -f aks-helloworld.yaml --namespace ingress-basic

kubectl apply -f ingress-demo.yaml --namespace ingress-basic

Ambas aplicaciones ahora se ejecutan en el clúster de Kubernetes. Para enrutar el tráfico a cada aplicación, cree
un recurso de entrada de Kubernetes. El recurso de entrada configura las reglas de enrutamiento del tráfico a
una de las dos aplicaciones.
En el ejemplo siguiente, el tráfico a la dirección http://10.240.0.42/ se enruta al servicio denominado
aks-helloworld . El tráfico a la dirección http://10.240.0.42/hello-world-two se enruta al servicio ingress-demo .

kind: Ingress
metadata:
annotations:
spec:
rules:
- http:
paths:
pathType: Prefix
backend:
service:
port:
number: 80
pathType: Prefix
backend:
service:
name: ingress-demo
port:
number: 80
- path: /(.*)
pathType: Prefix
backend:
service:
port:
number: 80
kubectl apply -f hello-world-ingress.yaml
La salida de ejemplo siguiente muestra que se crea el recurso de entrada.
Prueba del controlador de entrada

Para probar las rutas para el controlador de entrada, vaya a las dos aplicaciones con un cliente web. Si es
necesario, puede probar rápidamente esta funcionalidad solo para uso interno con un pod en el clúster de AKS.
Cree un pod de prueba y asóciele una sesión de terminal:
kubectl run -it --rm aks-ingress-test --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 --

namespace ingress-basic

Ahora acceda al controlador de ingreso de Kubernetes con curl , como http://10.240.0.42 . Proporcione su
propia dirección IP interna que especificó al implementar el controlador de entrada en el primer paso de este
artículo.
curl -L http://10.240.0.42
No proporcionó ninguna ruta de acceso adicional con la dirección, por lo que el controlador de entrada se
establece de manera predeterminada en la ruta / . Se devuelve la primera aplicación de demostración, tal como
se muestra en la siguiente salida de ejemplo reducido:
$ curl -L http://10.240.0.42
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<link rel="stylesheet" type="text/css" href="/static/default.css">
<title>Welcome to Azure Kubernetes Service (AKS)</title>
[...]
A continuación, agregue la ruta de acceso /hello-world-two a la dirección, como http://10.240.0.42/hello-world-

two . Se devuelve la segunda aplicación de demostración con el título personalizado, tal como se muestra en la
siguiente salida de ejemplo reducido:
$ curl -L -k http://10.240.0.42/hello-world-two
<!DOCTYPE html>
<head>
<title>AKS Ingress Demo</title>
[...]
En este artículo, se usa Helm para instalar los componentes de entrada. Al implementar un gráfico de Helm, se
crean algunos recursos de Kubernetes. Estos recursos incluyen pods, implementaciones y servicios. Para limpiar
estos recursos, puede eliminar el espacio de nombres de ejemplo completo o los recursos individuales.

Despliegue una lista de las versiones de Helm con el comando helm list .
helm list --namespace ingress-basic

Busque los gráficos denominados nginx-ingress y aks-helloworld, tal y como se muestra en la salida del ejemplo
siguiente:

CHART APP VERSION
Desinstale las versiones con el comando helm uninstall .
helm uninstall nginx-ingress --namespace ingress-basic
En el ejemplo siguiente se desinstala la implementación de entrada de NGINX.
kubectl delete -f aks-helloworld.yaml --namespace ingress-basic

kubectl delete -f ingress-demo.yaml --namespace ingress-basic
Pasos siguientes
CLI de Helm
También puede:
Crear un controlador de entrada con una dirección IP pública estática y configurar Let's Encrypt para generar
certificados TLS de forma automática
Tutorial: Habilitación del complemento Controlador
de entrada de Application Gateway para un clúster
de AKS existente con una instancia de Application
Gateway existente
Puede usar la CLI de Azure o Azure Portal para habilitar el complemento Controlador de entrada de Application
Gateway (AGIC) para un clúster de Azure Kubernetes Services (AKS) existente. En este tutorial, aprenderá a usar
el complemento AGIC para exponer su aplicación de Kubernetes en un clúster de AKS existente a través de una
instancia de Application Gateway existente implementada en redes virtuales independientes. Comenzaremos
por crear un clúster de AKS en una red virtual y una instancia de Application Gateway en una red virtual
independiente para simular los recursos existentes. A continuación, habilitará el complemento AGIC, emparejará
las dos redes virtuales e implementará una aplicación de ejemplo que se expondrá a través de la instancia de
Application Gateway mediante el complemento AGIC. Si va a habilitar el complemento AGIC para una instancia
de Application Gateway existente un clúster de AKS existente en la misma red virtual, puede omitir el paso de
emparejamiento que aparece a continuación. El complemento proporciona una manera mucho más rápida de
implementar AGIC para el clúster de AKS que cuando se hacía previamente a través de Helm y también ofrece
una experiencia totalmente administrada.
En este tutorial, aprenderá a:
Crear una nueva instancia de Application Gateway
Habilitar el complemento AGIC en el clúster de AKS existente a través de la CLI de Azure
Habilitar el complemento AGIC para un clúster de AKS existente a través de Azure Portal
Emparejar la red virtual de Application Gateway con la red virtual del clúster de AKS
Implementar una aplicación de ejemplo mediante AGIC para la entrada en el clúster de AKS
Comprobar que la aplicación es accesible a través de Application Gateway
Requisitos previos


En Azure, puede asignar recursos relacionados a un grupo de recursos. Para crear un grupo de recursos, use az
group create. En el ejemplo siguiente se crea un grupo de recursos denominado myResourceGroup en la
ubicación canadacentral (región).
az group create --name myResourceGroup --location canadacentral
Implementación de un clúster de AKS

Ahora implementará un nuevo clúster de AKS para simular un clúster de AKS existente para el que quiere
habilitar el complemento AGIC.
En el ejemplo siguiente, va a implementar un nuevo clúster de AKS denominado myCluster mediante Azure CNI
e identidades administradas en el grupo de recursos que creó, myResourceGroup.
az aks create -n myCluster -g myResourceGroup --network-plugin azure --enable-managed-identity
Para configurar parámetros adicionales para el comando az aks create , consulte las referencias de este
vínculo.
Implementación de una nueva instancia de Application Gateway

Ahora implementará una nueva instancia de Application Gateway para simular una instancia de Application
Gateway existente que quiera usar para equilibrar la carga del tráfico en el clúster de AKS, myCluster. El nombre
de la instancia de Application Gateway será myApplicationGateway, pero tendrá que crear primero un recurso
de dirección IP pública, denominado myPublicIp, y una nueva red virtual denominada myVnet con el espacio de
direcciones 11.0.0.0/8 y una subred con el espacio de direcciones 11.1.0.0/16 llamada mySubnet e implementar
la instancia de Application Gateway en mySubnet con myPublicIp.
Cuando se usa un clúster de AKS y una instancia de Application Gateway en redes virtuales independientes, los
espacios de direcciones de las dos redes virtuales no deben superponerse. El espacio de direcciones
predeterminado que implementa un clúster de AKS es 10.0.0.0/8, por lo que establecemos el prefijo de dirección
de red virtual de la instancia de Application Gateway en 11.0.0.0/8.
az network public-ip create -n myPublicIp -g MyResourceGroup --allocation-method Static --sku Standard

az network vnet create -n myVnet -g myResourceGroup --address-prefix 11.0.0.0/8 --subnet-name mySubnet --
subnet-prefix 11.1.0.0/16
az network application-gateway create -n myApplicationGateway -l canadacentral -g myResourceGroup --sku
Standard_v2 --public-ip-address myPublicIp --vnet-name myVnet --subnet mySubnet
NOTE
El complemento del controlador de entrada de Application Gateway (AGIC) admite solo las SKU de Application Gateway
v2 (estándar y WAF) y no las SKU de Application Gateway v1.
Habilitación del complemento AGIC en un clúster de AKS existente a

través de la CLI de Azure
Si quiere seguir usando la CLI de Azure, puede seguir habilitando el complemento AGIC en el clúster de AKS que
creó, myCluster, y especificar el complemento AGIC para usar la instancia de Application Gateway existente que
creó, myApplicationGateway.
appgwId=$(az network application-gateway show -n myApplicationGateway -g myResourceGroup -o tsv --query

"id")
az aks enable-addons -n myCluster -g myResourceGroup -a ingress-appgw --appgw-id $appgwId
Habilitación del complemento AGIC para un clúster de AKS existente

a través de Azure Portal
Si desea usar Azure Portal para habilitar el complemento AGIC, vaya a (https://aka.ms/azure/portal/aks/agic) y
navegue hasta el clúster de AKS a través del vínculo de Azure Portal. Desde allí, vaya a la pestaña Redes del
clúster de AKS. Verá la sección del controlador de entrada de Application Gateway, que le permite habilitar o
deshabilitar el complemento de controlador de entrada mediante la interfaz de usuario de Azure Portal. Active la
casilla situada junto a "Enable ingress controller" (Habilitar el controlador de entrada) y seleccione la instancia
de Application Gateway que creó, myApplicationGateway en el menú desplegable.
<a name="peer-the-two-virtual-networks-
together">Emparejamiento de dos redes virtuales juntas
Dado que hemos implementado el clúster de AKS en su propia red virtual y la instancia de Application Gateway
en otra red virtual, deberá emparejar las dos redes virtuales juntas para que el tráfico fluya de la instancia de
Application Gateway a los pods del clúster. Emparejar las dos redes virtuales requiere ejecutar el comando de la
CLI de Azure dos veces independientes para asegurarse de que la conexión sea bidireccional. El primer comando
creará una conexión de emparejamiento desde la red virtual de Application Gateway a la red virtual de AKS; el
segundo comando creará una conexión de emparejamiento en la otra dirección.
nodeResourceGroup=$(az aks show -n myCluster -g myResourceGroup -o tsv --query "nodeResourceGroup")

aksVnetName=$(az network vnet list -g $nodeResourceGroup -o tsv --query "[0].name")
aksVnetId=$(az network vnet show -n $aksVnetName -g $nodeResourceGroup -o tsv --query "id")

az network vnet peering create -n AppGWtoAKSVnetPeering -g myResourceGroup --vnet-name myVnet --remote-vnet
$aksVnetId --allow-vnet-access
appGWVnetId=$(az network vnet show -n myVnet -g myResourceGroup -o tsv --query "id")

az network vnet peering create -n AKStoAppGWVnetPeering -g $nodeResourceGroup --vnet-name $aksVnetName --
remote-vnet $appGWVnetId --allow-vnet-access
Implementación de una aplicación de ejemplo mediante AGIC

Ahora implementará una aplicación de ejemplo en el clúster de AKS creado que usará el complemento AGIC
para la entrada y conectará la instancia de Application Gateway al clúster de AKS. En primer lugar, obtendrá las
credenciales para el clúster de AKS que implementó mediante la ejecución del comando az aks get-credentials
.
az aks get-credentials -n myCluster -g myResourceGroup
Una vez que tiene las credenciales para el clúster que creó, ejecute el siguiente comando para configurar una
aplicación de ejemplo que use AGIC para la entrada al clúster. AGIC actualizará la instancia de Application
Gateway que configuró anteriormente con las reglas de enrutamiento correspondientes a la nueva aplicación de
ejemplo que implementó.
kubectl apply -f https://raw.githubusercontent.com/Azure/application-gateway-kubernetes-

ingress/master/docs/examples/aspnetapp.yaml
Comprobación de que la aplicación sea accesible

Ahora que Application Gateway está configurada para enviar el tráfico al clúster de AKS, vamos a comprobar
que la aplicación sea accesible. Primero, obtenga la dirección IP de la entrada.
kubectl get ingress
Compruebe que la aplicación de ejemplo que ha creado está en funcionamiento; para ello, visite la dirección IP
de la instancia de Application Gateway que obtuvo al ejecutar el comando anterior o consulte curl . Application
Gateway puede tardar un minuto en obtener la actualización, por lo que si su instancia de Application Gateway
todavía está en el estado "Actualizando" en el portal, permita que finalice antes de intentar conectarse a la
dirección IP.
Cuando ya no los necesite, quite el grupo de recursos, la puerta de enlace de aplicaciones y todos los recursos
relacionados.
az group delete --name myResourceGroup
Pasos siguientes
Más información sobre cómo deshabilitar el complemento AGIC
Creación de un controlador de entrada HTTPS y
uso de sus propios certificados TLS en Azure
Kubernetes Service (AKS). Generará sus propios certificados y creará un secreto de Kubernetes para su uso con
la ruta de entrada. Por último, en el clúster de AKS se ejecutan dos aplicaciones, a las que se puede acceder con
una sola dirección IP.
También puede:
Antes de empezar
Este artículo usa Helm 3 para instalar el controlador de entrada NGINX. Asegúrese de que usa la versión más
reciente de Helm y de que tiene acceso al repositorio de Helm ingress-nginx. Para instrucciones de actualización,
consulte la documentación de instalación de Helm. Para obtener más información sobre cómo configurar y usar
Helm, consulte Instalación de aplicaciones con Helm en Azure Kubernetes Service (AKS).
Azure.

Para crear el controlador de entrada, use Helm para instalar nginx-ingress. Para obtener redundancia adicional,
se implementan dos réplicas de los controladores de entrada NGINX con el parámetro
TIP
TIP



Durante la instalación se crea una dirección IP pública de Azure para el controlador de entrada. Esta dirección IP
pública es estática durante el período de vida del controlador de entrada. Si elimina el controlador de entrada, se
pierde la asignación de dirección IP pública. Si después crea un controlador de entrada adicional, se asigna una
dirección IP pública nueva. Si quiere conservar el uso de la dirección IP pública, en su lugar puede crear un
controlador de entrada con una dirección IP pública estática.
Para obtener la dirección IP pública, use el comando kubectl get service .
kubectl --namespace ingress-basic get services -o wide -w nginx-ingress-ingress-nginx-controller
La asignación de la dirección IP al servicio puede tardar hasta un minuto.

AGE SELECTOR
Anote esta dirección IP pública, ya que se utiliza en el último paso para probar la implementación.
Todavía no se creó ninguna regla de entrada. Si navega a la dirección IP pública, se muestra la página 404
predeterminada del controlador de entrada NGINX.
Generación de certificados TLS

En este artículo, vamos a generar un certificado autofirmado con openssl . Para su uso en producción, debe
solicitar un certificado de confianza firmado mediante un proveedor o su propia entidad de certificación (CA). En
el paso siguiente, generará un secreto de Kubernetes utilizando el certificado TLS y la clave privada que ha
generado OpenSSL.
En el ejemplo siguiente, se genera un certificado X509 RSA de 2048 bits válido durante 365 días denominado
aks-ingress-tls.crt. El archivo de clave privada se denomina aks-ingress-tls.key. Un secreto de Kubernetes TLS
requiere ambos archivos.
Este artículo utiliza el nombre común del asunto demo.azure.com, que no es necesario cambiar. Para su uso en
producción, especifique los valores de su propia organización para el parámetro -subj :
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \

-out aks-ingress-tls.crt \
-keyout aks-ingress-tls.key \
-subj "/CN=demo.azure.com/O=aks-ingress-tls"
Creación de un secreto de Kubernetes para el certificado TLS

Para permitir que Kubernetes use el certificado TLS y la clave privada para el controlador de entrada, debe crear
y usar un secreto. El secreto se define una vez y usa el certificado y el archivo de clave que creó en el paso
anterior. A continuación, hará referencia a este secreto al definir las rutas de entrada.
En el ejemplo siguiente se crea un secreto llamado aks-ingress-tls:
kubectl create secret tls aks-ingress-tls \

--key aks-ingress-tls.key \
--cert aks-ingress-tls.crt

Se han configurado un controlador de entrada y un secreto con su certificado. Ahora vamos a ejecutar dos
aplicaciones de demostración en el clúster de AKS. En este ejemplo, Helm se usa para implementar dos
instancias de una aplicación "Hola mundo" sencilla.
apiVersion: apps/v1
kind: Deployment
metadata:
spec:
replicas: 1
selector:
matchLabels:
app: aks-helloworld
template:
metadata:
labels:
app: aks-helloworld
spec:
containers:
ports:
- containerPort: 80
env:
- name: TITLE
---
apiVersion: v1
kind: Service
metadata:
spec:
type: ClusterIP
ports:
- port: 80
selector:
app: aks-helloworld

apiVersion: apps/v1
kind: Deployment
metadata:
name: ingress-demo
spec:
replicas: 1
selector:
matchLabels:
app: ingress-demo
template:
metadata:
labels:
app: ingress-demo
spec:
containers:
ports:
- containerPort: 80
env:
- name: TITLE
---
apiVersion: v1
kind: Service
metadata:
name: ingress-demo
spec:
type: ClusterIP
ports:
- port: 80
selector:
app: ingress-demo


Ambas aplicaciones se ejecutan ahora en el clúster de Kubernetes, sin embargo, están configuradas con un
servicio de tipo ClusterIP . Por lo tanto, no se puede acceder a ellas desde Internet. Para que estén disponibles
de manera pública, cree un recurso de entrada de Kubernetes. El recurso de entrada configura las reglas de
enrutamiento del tráfico a una de las dos aplicaciones.
En el ejemplo siguiente, el tráfico a la dirección https://demo.azure.com/ se enruta al servicio denominado
aks-helloworld . El tráfico a la dirección https://demo.azure.com/hello-world-two se enruta al servicio
ingress-demo . En este artículo, no es necesario cambiar los nombres de host de demostración. Para su uso en
producción, proporcione los nombres especificados como parte del proceso de solicitud y generación del
certificado.
TIP
Si el nombre de host especificado durante el proceso de solicitud de certificado (el nombre CN) no coincide con el host
definido en la ruta de entrada, el controlador de entrada muestra la advertencia Certificado falso de controlador de
entrada de Kubernetes. Asegúrese de que los nombres de host de la ruta de entrada y el certificado coinciden.
La sección tls indica la ruta de entrada para usar el secreto llamado aks-ingress-tls para el host demo.azure.com.
De nuevo, para su uso en producción, especifique su propia dirección de host.
kind: Ingress
metadata:
annotations:
spec:
tls:
- hosts:
- demo.azure.com
secretName: aks-ingress-tls
rules:
- host: demo.azure.com
http:
paths:
pathType: Prefix
backend:
service:
port:
number: 80
pathType: Prefix
backend:
service:
name: ingress-demo
port:
number: 80
- path: /(.*)
pathType: Prefix
backend:
service:
port:
number: 80
kubectl apply -f hello-world-ingress.yaml
La salida de ejemplo muestra que se crea el recurso de entrada.
Prueba de la configuración de entrada

Para probar los certificados con nuestro host demo.azure.com falso, utilice curl y especifique el parámetro --
resolver. Este parámetro le permite asignar el nombre demo.azure.com a la dirección IP pública de su
controlador de entrada. Especifique la dirección IP pública de su propio controlador de entrada, como se
muestra en el ejemplo siguiente:
curl -v -k --resolve demo.azure.com:443:EXTERNAL_IP https://demo.azure.com
No proporcionó ninguna ruta de acceso adicional con la dirección, por lo que el controlador de entrada se
establece de manera predeterminada en la ruta / . Se devuelve la primera aplicación de demostración, tal como
se muestra en la siguiente salida de ejemplo reducido:
$ curl -v -k --resolve demo.azure.com:443:EXTERNAL_IP https://demo.azure.com
[...]
<!DOCTYPE html>
<head>
<title>Welcome to Azure Kubernetes Service (AKS)</title>
[...]
El parámetro -v de nuestro comando curl genera información detallada, incluyendo el certificado TLS recibido.
A mitad de la salida de cURL, puede comprobar que se ha utilizado su propio certificado TLS. El parámetro -k
continúa cargando la página, aunque se esté usando un certificado autofirmado. En el siguiente ejemplo se
muestra el certificado issuer: CN=demo.azure.com; O=aks-ingress-tls que se ha utilizado:
[...]
* Server certificate:
* subject: CN=demo.azure.com; O=aks-ingress-tls
* start date: Oct 22 22:13:54 2018 GMT
* expire date: Oct 22 22:13:54 2019 GMT
* issuer: CN=demo.azure.com; O=aks-ingress-tls
* SSL certificate verify result: self signed certificate (18), continuing anyway.
[...]
A continuación, agregue la ruta de acceso /hello-world-two a la dirección, como

https://demo.azure.com/hello-world-two . Se devuelve la segunda aplicación de demostración con el título
personalizado, tal como se muestra en la siguiente salida de ejemplo reducido:
$ curl -v -k --resolve demo.azure.com:443:EXTERNAL_IP https://demo.azure.com/hello-world-two
[...]
<!DOCTYPE html>
<head>
<title>AKS Ingress Demo</title>
[...]
En este artículo, se usa Helm para instalar los componentes de entrada y las aplicaciones de ejemplo. Al
implementar un gráfico de Helm, se crean algunos recursos de Kubernetes. Estos recursos incluyen pods,
implementaciones y servicios. Para limpiar estos recursos, puede eliminar el espacio de nombres de ejemplo
completo o los recursos individuales.

Despliegue una lista de las versiones de Helm con el comando helm list .
helm list --namespace ingress-basic
Buscar el gráfico denominado nginx-ingress como se muestra en la salida del ejemplo siguiente:

CHART APP VERSION
Desinstalar las versiones con el helm uninstall comando.
helm uninstall nginx-ingress --namespace ingress-basic
En el ejemplo siguiente se desinstala la implementación de entrada de NGINX.

Elimine el secreto del certificado:
kubectl delete secret aks-ingress-tls --namespace ingress-basic
Pasos siguientes
CLI de Helm
También puede:
Creación de un controlador de entrada HTTPS en
Kubernetes Service (AKS). El proyecto cert-manager se usa para generar y configurar automáticamente
certificados Let's Encrypt. Por último, en el clúster de AKS se ejecutan dos aplicaciones, a las que se puede
acceder con una sola dirección IP.
También puede:
Crear un controlador de entrada que usa Let's Encrypt para generar automáticamente certificados TLS con
una dirección IP pública estática
Antes de empezar
En este artículo se supone que tiene un dominio personalizado con una zona DNS en el mismo grupo de
recursos que el clúster de AKS.
En este artículo se usa Helm 3 para instalar el controlador de entrada NGINX y cert-manager. Asegúrese de que
usa la versión más reciente de Helm y de que tiene acceso a los repositorios de Helm ingress-nginx y jetstack.
Para instrucciones de actualización, consulte la documentación de instalación de Helm. Para obtener más
información sobre cómo configurar y usar Helm, consulte Instalación de aplicaciones con Helm en Azure
Azure.

Para crear el controlador de entrada, use el comando helm para instalar nginx-ingress. Para obtener
redundancia adicional, se implementan dos réplicas de los controladores de entrada NGINX con el parámetro
TIP
TIP



Durante la instalación se crea una dirección IP pública de Azure para el controlador de entrada. Esta dirección IP
pública es estática durante el período de vida del controlador de entrada. Si elimina el controlador de entrada, se
pierde la asignación de dirección IP pública. Si después crea un controlador de entrada adicional, se asigna una
dirección IP pública nueva. Si quiere conservar el uso de la dirección IP pública, en su lugar puede crear un
controlador de entrada con una dirección IP pública estática.
Para obtener la dirección IP pública, use el comando kubectl get service . La asignación de la dirección IP al
servicio puede tardar hasta un minuto.

AGE SELECTOR
Todavía no se creó ninguna regla de entrada. Si navega a la dirección IP pública, se muestra la página 404
predeterminada del controlador de entrada NGINX.
Adición de un registro A a la zona DNS

Agregue un registro A a la zona DNS con la dirección IP externa del servicio de NGINX mediante az network dns
record-set a add-record.
az network dns record-set a add-record \
--zone-name MY_CUSTOM_DOMAIN \
--record-set-name * \
--ipv4-address MY_EXTERNAL_IP
NOTE
Si quiere, puede configurar un FQDN para la dirección IP del controlador de entrada en lugar de un dominio
personalizado. Tenga en cuenta que este ejemplo es para un shell de Bash.
# Public IP address of your ingress controller

IP="MY_EXTERNAL_IP"
# Name to associate with public IP address

DNSNAME="demo-aks-ingress"
# Get the resource-id of the public ip

PUBLICIPID=$(az network public-ip list --query "[?ipAddress!=null]|[?contains(ipAddress, '$IP')].[id]" -
-output tsv)
# Update public ip address with DNS name

az network public-ip update --ids $PUBLICIPID --dns-name $DNSNAME
# Display the FQDN

az network public-ip show --ids $PUBLICIPID --query "[dnsSettings.fqdn]" --output tsv
Instalar cert-manager
El controlador de entrada NGINX es compatible con la terminación de TLS. Hay varias maneras de recuperar y
configurar certificados para HTTPS. En este artículo se muestra cómo utilizar cert manager, que proporciona la
generación automática de certificados Lets Encrypt y la funcionalidad de administración.
Para instalar el controlador cert-manager:
# Label the ingress-basic namespace to disable resource validation

kubectl label namespace ingress-basic cert-manager.io/disable-validation=true
# Add the Jetstack Helm repository

helm repo add jetstack https://charts.jetstack.io

helm repo update
# Install the cert-manager Helm chart

helm install cert-manager jetstack/cert-manager \
--set installCRDs=true \
--set nodeSelector."kubernetes\.io/os"=linux \
--set webhook.nodeSelector."kubernetes\.io/os"=linux \
--set cainjector.nodeSelector."kubernetes\.io/os"=linux
Para obtener más información sobre la configuración cert-manager, consulte el proyecto cert-manager.
Creación de un emisor de clúster de entidad de certificación

Para poder emitir certificados, cert-manager requiere un recurso Issuer o ClusterIssuer. La funcionalidad de los
recursos de Kubernetes es idéntica, pero Issuer funciona en un espacio de nombres único, mientras que
ClusterIssuer funciona en todos los espacios de nombres. Para obtener más información, consulte la
documentación de cert-manager issuer.
Cree un emisor de clúster, como cluster-issuer.yaml , con el manifiesto de ejemplo siguiente. Actualice la
dirección de correo electrónico con una dirección válida de su organización:
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: MY_EMAIL_ADDRESS
privateKeySecretRef:
name: letsencrypt
solvers:
- http01:
ingress:
class: nginx
podTemplate:
spec:
nodeSelector:
"kubernetes.io/os": linux
Para crear el emisor, use el comando kubectl apply .
kubectl apply -f cluster-issuer.yaml

Se deben haber configurado una solución de administración de certificados y un controlador de entrada. Ahora
vamos a ejecutar dos aplicaciones de demostración en el clúster de AKS. En este ejemplo, Helm se usa para
implementar dos instancias de una aplicación Hola mundo sencilla.
este ejemplo, use kubectl apply para implementar dos instancias de una aplicación Hola mundo sencilla.
Cree un archivo aks-helloworld-one.yaml y cópielo en el ejemplo siguiente de YAML:
apiVersion: apps/v1
kind: Deployment
metadata:
spec:
replicas: 1
selector:
matchLabels:
template:
metadata:
labels:
spec:
containers:
- name: aks-helloworld-one
ports:
- containerPort: 80
env:
- name: TITLE
---
apiVersion: v1
kind: Service
metadata:
spec:
type: ClusterIP
ports:
- port: 80
selector:
Cree un archivo aks-helloworld-two.yaml y cópielo en el ejemplo siguiente de YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
spec:
replicas: 1
selector:
matchLabels:
template:
metadata:
labels:
spec:
containers:
- name: aks-helloworld-two
ports:
- containerPort: 80
env:
- name: TITLE
---
apiVersion: v1
kind: Service
metadata:
spec:
type: ClusterIP
ports:
- port: 80
selector:
Ejecute las dos aplicaciones de demostración mediante kubectl apply :
kubectl apply -f aks-helloworld-one.yaml --namespace ingress-basic

kubectl apply -f aks-helloworld-two.yaml --namespace ingress-basic

Ambas aplicaciones ahora se ejecutan en el clúster de Kubernetes. Sin embargo, están configuradas con un
servicio de tipo ClusterIP y no son accesibles desde Internet. Para que estén disponibles de manera pública,
cree un recurso de entrada de Kubernetes. El recurso de entrada configura las reglas de enrutamiento del tráfico
a una de las dos aplicaciones.
En el ejemplo siguiente, el tráfico a la dirección hello-world-ingress.MY_CUSTOM_DOMAIN se enruta al servicio
aks-helloworld-one. El tráfico a la dirección hello-world-ingress.MY_CUSTOM_DOMAIN/hello-world-two se
enruta al servicio aks-helloworld-two. El tráfico a hello-world-ingress.MY_CUSTOM_DOMAIN/static se enruta al
servicio denominado aks-helloworld-one para los recursos estáticos.
NOTE
Si ha configurado FQDN para la dirección IP del controlador de entrada en lugar de un dominio personalizado, use FQDN
en lugar de hello-world-ingress.MY_CUSTOM_DOMAIN. Por ejemplo, si FQDN es demo-aks-
ingress.eastus.cloudapp.azure.com, reemplace hello-world-ingress.MY_CUSTOM_DOMAIN por demo-aks-
ingress.eastus.cloudapp.azure.com en hello-world-ingress.yaml .
Cree un archivo denominado hello-world-ingress.yaml mediante el ejemplo de YAML siguiente. Actualice los
hosts y el host al nombre DNS que creó en un paso anterior.
kind: Ingress
metadata:
annotations:
cert-manager.io/cluster-issuer: letsencrypt
spec:
tls:
- hosts:
- hello-world-ingress.MY_CUSTOM_DOMAIN
secretName: tls-secret
rules:
- host: hello-world-ingress.MY_CUSTOM_DOMAIN
http:
paths:
pathType: Prefix
backend:
service:
port:
number: 80
pathType: Prefix
backend:
service:
port:
number: 80
- path: /(.*)
pathType: Prefix
backend:
service:
port:
number: 80
---
kind: Ingress
metadata:
name: hello-world-ingress-static
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /static/$2
cert-manager.io/cluster-issuer: letsencrypt
spec:
tls:
- hosts:
- hello-world-ingress.MY_CUSTOM_DOMAIN
rules:
- host: hello-world-ingress.MY_CUSTOM_DOMAIN
http:
paths:
- path:
pathType: Prefix
backend:
service:
port:
number: 80
path: /static(/|$)(.*)
Cree el recurso de entrada con el comando kubectl apply .
kubectl apply -f hello-world-ingress.yaml --namespace ingress-basic
Verificación de la creación de un objeto de certificado

A continuación, se debe crear un recurso de certificado. El recurso de certificado define el certificado X.509
deseado. Para obtener más información, consulte los certificados de cert-manager. Es probable que el elemento
cert-manager haya creado automáticamente un objeto de certificado mediante las correcciones de
compatibilidad (shim) de entrada, que se implementan automáticamente con el elemento cert-manager desde
v0.2.2. Para obtener más información, consulte la documentación sobre corrección de compatibilidad (shim) de
entrada.
Para verificar que el certificado se haya creado correctamente, use el comando
kubectl get certificate --namespace ingress-basic y compruebe que la opción LISTO esté establecida en True,
lo que puede tardar varios minutos.
$ kubectl get certificate --namespace ingress-basic
NAME READY SECRET AGE

tls-secret True tls-secret 11m

Abra un explorador web a la dirección hello-world-ingress.MY_CUSTOM_DOMAIN del controlador de entrada
de Kubernetes. Tenga en cuenta que se le redirige a usar HTTPS, que el certificado es de confianza y la aplicación
de demostración se muestra en el explorador web. Agregue la ruta de acceso /hello-world-two y observe que se
muestra la segunda aplicación de demostración con el título personalizado.
En este artículo, se usa Helm para instalar los componentes de entrada, los certificados y las aplicaciones de
ejemplo. Al implementar un gráfico de Helm, se crean algunos recursos de Kubernetes. Estos recursos incluyen
pods, implementaciones y servicios. Para limpiar estos recursos, puede eliminar el espacio de nombres de
ejemplo completo o los recursos individuales.

Como alternativa, un enfoque más pormenorizado consiste en eliminar los recursos individuales creados. En
primer lugar, quite los recursos del emisor del clúster:
kubectl delete -f cluster-issuer.yaml --namespace ingress-basic
Despliegue una lista de las versiones de Helm con el comando helm list . Busque los gráficos denominados
nginx y cert-manager, tal y como se muestra en la salida del ejemplo siguiente:

CHART APP VERSION
cert-manager ingress-basic 1 2020-01-15 10:23:36.515514 -0600 CST deployed
cert-manager-v0.13.0 v0.13.0
nginx ingress-basic 1 2020-01-15 10:09:45.982693 -0600 CST deployed
Desinstale las versiones con el comando helm uninstall . En el ejemplo siguiente se desinstalan las
implementaciones de entrada de NGINX y de cert-manager.
$ helm uninstall cert-manager nginx --namespace ingress-basic
release "cert-manager" uninstalled

release "nginx" uninstalled
Luego, quite las dos aplicaciones de ejemplo:
kubectl delete -f aks-helloworld-one.yaml --namespace ingress-basic

kubectl delete -f aks-helloworld-two.yaml --namespace ingress-basic
kubectl delete -f hello-world-ingress.yaml --namespace ingress-basic
Pasos siguientes
CLI de Helm
cert-manager
También puede:
una dirección IP pública estática
Cree un controlador de entrada con una dirección
IP pública estática en Azure Kubernetes Service
(AKS)
Kubernetes Service (AKS). El controlador de entrada se configura con una dirección IP pública estática. El
proyecto cert-manager se usa para generar y configurar automáticamente certificados Let's Encrypt. Por último,
en el clúster de AKS se ejecutan dos aplicaciones, a las que se puede acceder con una sola dirección IP.
También puede:
una dirección IP pública dinámica
Antes de empezar
En este artículo se usa Helm 3 para instalar el controlador de entrada NGINX y cert-manager. Asegúrese de que
usa la versión más reciente de Helm y de que tiene acceso a los repositorios de Helm ingress-nginx y jetstack.
Para instrucciones de actualización, consulte la documentación de instalación de Helm. Para obtener más
información sobre cómo configurar y usar Helm, consulte Instalación de aplicaciones con Helm en Azure
Azure.

De manera predeterminada, se crea un controlador de entrada NGINX con una asignación de una nueva
dirección IP pública. Esta dirección IP pública solo es estática mientras esté vigente el controlador de entrada y
se pierde si el controlador se elimina y se vuelve a crear. Un requisito de configuración común es proporcionar
una dirección IP pública estática existente al controlador de entrada NGINX. La dirección IP pública estática se
conserva si se elimina el controlador de entrada. Este enfoque permite usar los registros DNS y las
configuraciones de red existentes de manera coherente durante el ciclo de vida de las aplicaciones.
Si debe crear una dirección IP pública estática, primero obtenga el nombre del grupo de recursos del clúster AKS
con el comando az aks show:
az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv
Después, cree una dirección IP pública con el método de asignación estático mediante el comando az network
public-ip create. En el ejemplo siguiente se crea una dirección IP pública denominada myAKSPublicIP en el
grupo de recursos del clúster AKS obtenido en el paso anterior:
az network public-ip create --resource-group MC_myResourceGroup_myAKSCluster_eastus --name myAKSPublicIP --

sku Standard --allocation-method static --query publicIp.ipAddress -o tsv
NOTE
Los comandos anteriores crean una dirección IP que se eliminará si elimina el clúster de AKS. Como alternativa, puede
crear una dirección IP en otro grupo de recursos que se pueda administrar de forma independiente del clúster de AKS. Si
crea una dirección IP en otro grupo de recursos, asegúrese de que la entidad del clúster usada por el clúster de AKS tenga
permisos delegados para el otro grupo de recursos, como Colaborador de la red. Para obtener más información, consulte
Uso de una dirección IP pública estática y una etiqueta DNS con el equilibrador de carga de AKS.
Ahora implemente el gráfico nginx-ingress con Helm. Para obtener redundancia adicional, se implementan dos
réplicas de los controladores de entrada NGINX con el parámetro --set controller.replicaCount . Para sacar el
máximo provecho de las réplicas en ejecución del controlador de entrada, asegúrese de que hay más de un
nodo en el clúster de AKS.
Debe pasar dos parámetros adicionales a la versión de Helm para que el controlador de entrada tenga en cuenta
la dirección IP estática del equilibrador de carga que se va a asignar al servicio de controlador de entrada y la
etiqueta de nombre DNS que se está aplicando al recurso de dirección IP pública. Para que los certificados
HTTPS funcionen correctamente, se usa una etiqueta de nombre DNS para configurar un FQDN para la
dirección IP del controlador de entrada.
1. Agregue el parámetro --set controller.service.loadBalancerIP . Especifique su propia dirección IP pública
creada en el paso anterior.
2. Agregue el parámetro
--set controller.service.annotations."service\.beta\.kubernetes\.io/azure-dns-label-name" . Especifique una
etiqueta de nombre DNS para aplicarla a la dirección IP pública que se creó en el paso anterior.
TIP
TIP
Actualice el siguiente script con la dirección IP del controlador de entrada y el nombre único que le gustaría
usar para el prefijo de FQDN.
IMPORTANT
Debe reemplazar mediante actualización STATIC_IP y DNS_LABEL por su propia dirección IP y nombre único cuando
ejecute el comando.



--set controller.admissionWebhooks.patch.nodeSelector."beta\.kubernetes\.io/os"=linux \
--set controller.service.loadBalancerIP="STATIC_IP" \
--set controller.service.annotations."service\.beta\.kubernetes\.io/azure-dns-label-
name"="DNS_LABEL"
asigna la dirección IP estática, como se muestra en la salida del ejemplo siguiente:

AGE SELECTOR
entrada NGINX si navega a la dirección IP pública. Las reglas de entrada se configuran en los pasos siguientes.
Para comprobar que se ha aplicado la etiqueta de nombre DNS, consulte el FQDN en la dirección IP pública
como se indica a continuación:
az network public-ip list --resource-group MC_myResourceGroup_myAKSCluster_eastus --query "[?

name=='myAKSPublicIP'].[dnsSettings.fqdn]" -o tsv
El controlador de entrada ahora es accesible mediante la dirección IP o el FQDN.
Instalar cert-manager
El controlador de entrada NGINX es compatible con la terminación de TLS. Hay varias maneras de recuperar y
configurar certificados para HTTPS. En este artículo se muestra cómo utilizar cert manager, que proporciona la
generación automática de certificados Lets Encrypt y la funcionalidad de administración.
NOTE
En este artículo se usa el entorno staging para Let's Encrypt. En las implementaciones de producción, use
letsencrypt-prod y https://acme-v02.api.letsencrypt.org/directory en las definiciones de recursos y al instalar
el gráfico de Helm.
Para instalar el controlador cert-manager en un clúster de Kubernetes habilitado para RBAC, use el comando
helm install siguiente:
# Label the cert-manager namespace to disable resource validation

kubectl label namespace ingress-basic cert-manager.io/disable-validation=true
# Add the Jetstack Helm repository

helm repo add jetstack https://charts.jetstack.io

helm repo update
# Install the cert-manager Helm chart

helm install \
cert-manager \
--version v1.3.1 \
--set installCRDs=true \
--set nodeSelector."beta\.kubernetes\.io/os"=linux \
jetstack/cert-manager
Para obtener más información sobre la configuración cert-manager, consulte el proyecto cert-manager.
Creación de un emisor de clúster de entidad de certificación

Para poder emitir certificados, cert-manager requiere un recurso Issuer o ClusterIssuer. La funcionalidad de los
recursos de Kubernetes es idéntica, pero Issuer funciona en un espacio de nombres único, mientras que
ClusterIssuer funciona en todos los espacios de nombres. Para obtener más información, consulte la
documentación de cert-manager issuer.
Cree un emisor de clúster, como cluster-issuer.yaml , con el manifiesto de ejemplo siguiente. Actualice la
dirección de correo electrónico con una dirección válida de su organización:
apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
name: letsencrypt-staging
spec:
acme:
server: https://acme-staging-v02.api.letsencrypt.org/directory
email: user@contoso.com
privateKeySecretRef:
solvers:
- http01:
ingress:
class: nginx
podTemplate:
spec:
nodeSelector:
"kubernetes.io/os": linux
Para crear el emisor, use el comando kubectl apply .
kubectl apply -f cluster-issuer.yaml --namespace ingress-basic
La salida debe ser similar a la del ejemplo siguiente:
clusterissuer.cert-manager.io/letsencrypt-staging created

Se deben haber configurado una solución de administración de certificados y un controlador de entrada. Ahora
vamos a ejecutar dos aplicaciones de demostración en el clúster de AKS. En este ejemplo, Helm se usa para
implementar dos instancias de una aplicación "Hola mundo" sencilla.
apiVersion: apps/v1
kind: Deployment
metadata:
spec:
replicas: 1
selector:
matchLabels:
app: aks-helloworld
template:
metadata:
labels:
app: aks-helloworld
spec:
containers:
ports:
- containerPort: 80
env:
- name: TITLE
---
apiVersion: v1
kind: Service
metadata:
spec:
type: ClusterIP
ports:
- port: 80
selector:
app: aks-helloworld

apiVersion: apps/v1
kind: Deployment
metadata:
name: ingress-demo
spec:
replicas: 1
selector:
matchLabels:
app: ingress-demo
template:
metadata:
labels:
app: ingress-demo
spec:
containers:
ports:
- containerPort: 80
env:
- name: TITLE
---
apiVersion: v1
kind: Service
metadata:
name: ingress-demo
spec:
type: ClusterIP
ports:
- port: 80
selector:
app: ingress-demo


Ambas aplicaciones se ejecutan ahora en el clúster de Kubernetes, sin embargo, están configuradas con un
servicio de tipo ClusterIP . Por lo tanto, no se puede acceder a ellas desde Internet. Para que estén disponibles
de manera pública, cree un recurso de entrada de Kubernetes. El recurso de entrada configura las reglas de
enrutamiento del tráfico a una de las dos aplicaciones.
En el ejemplo siguiente, el tráfico a la dirección https://demo-aks-ingress.eastus.cloudapp.azure.com/ se enruta
al servicio denominado aks-helloworld . El tráfico a la dirección
https://demo-aks-ingress.eastus.cloudapp.azure.com/hello-world-two se enruta al servicio ingress-demo .
Actualice los hosts y el host al nombre DNS que creó en un paso anterior.
kind: Ingress
metadata:
annotations:
cert-manager.io/cluster-issuer: letsencrypt-staging
spec:
tls:
- hosts:
- demo-aks-ingress.eastus.cloudapp.azure.com
rules:
- host: demo-aks-ingress.eastus.cloudapp.azure.com
http:
paths:
pathType: Prefix
backend:
service:
port:
number: 80
pathType: Prefix
backend:
service:
name: ingress-demo
port:
number: 80
- path: /(.*)
pathType: Prefix
backend:
service:
port:
number: 80
Cree el recurso de entrada con el comando kubectl apply .
kubectl apply -f hello-world-ingress.yaml --namespace ingress-basic
La salida debe ser similar a la del ejemplo siguiente:
Creación de un objeto de certificado

A continuación, se debe crear un recurso de certificado. El recurso de certificado define el certificado X.509
deseado. Para obtener más información, consulte los certificados de cert-manager.
Es probable que el Administrador de certificados haya creado automáticamente un objeto de certificado
mediante la corrección de compatibilidad (shim) de entrada, que se implementa automáticamente con el
Administrador de certificados desde v0.2.2. Para obtener más información, consulte la documentación sobre
corrección de compatibilidad (shim) de entrada.
Para comprobar que el certificado se creó correctamente, use el comando
kubectl describe certificate tls-secret --namespace ingress-basic .
Si se ha emitido el certificado, verá un resultado similar al siguiente:

---- ------ ---- ---- -------
Normal CreateOrder 11m cert-manager Created new ACME order, attempting validation...
Normal DomainVerified 10m cert-manager Domain "demo-aks-ingress.eastus.cloudapp.azure.com" verified
with "http-01" validation
Normal IssueCert 10m cert-manager Issuing certificate...
Normal CertObtained 10m cert-manager Obtained certificate from ACME server
Normal CertIssued 10m cert-manager Certificate issued successfully
Si necesita crear un recurso de certificado adicional, puede hacerlo con el siguiente ejemplo de manifiesto.
Actualice dnsNames y los dominios al nombre DNS que creó en un paso anterior. Si usa un controlador de
entrada solo para uso interno, especifique el nombre DNS interno para el servicio.
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
name: tls-secret
spec:
dnsNames:
acme:
config:
- http01:
ingressClass: nginx
domains:
issuerRef:
kind: ClusterIssuer
Para crear el recurso de certificado, use el comando kubectl apply .
$ kubectl apply -f certificates.yaml
certificate.cert-manager.io/tls-secret created

Abra un explorador web en el FQDN del controlador de entrada de Kubernetes, como
https://demo-aks-ingress.eastus.cloudapp.azure.com .
Dado que estos ejemplos usan letsencrypt-staging , el explorador no confía en el certificado TLS/SSL emitido.
Acepte el mensaje de advertencia para continuar a la aplicación. La información de certificado muestra que Let’s
Encrypt emite este certificado Fake LE Intermediate X1. Este certificado falso indica que cert-manager procesó
correctamente la solicitud y recibió un certificado del proveedor:
Cuando modifica Let's Encrypt para usar prod en lugar de staging , se usa un certificado de confianza que Let's
Encrypt emite, tal como se muestra en el ejemplo siguiente:
La aplicación de demostración se muestra en el explorador web:
A continuación, agregue la ruta de acceso /hello-world-two al FQDN, como

https://demo-aks-ingress.eastus.cloudapp.azure.com/hello-world-two . Se muestra la segunda aplicación de
demostración con el título personalizado:
En este artículo, se usa Helm para instalar los componentes de entrada, los certificados y las aplicaciones de
ejemplo. Al implementar un gráfico de Helm, se crean algunos recursos de Kubernetes. Estos recursos incluyen
pods, implementaciones y servicios. Para limpiar estos recursos, puede eliminar el espacio de nombres de
ejemplo completo o los recursos individuales.

Primero, quite los recursos de certificado:
kubectl delete -f certificates.yaml

kubectl delete -f cluster-issuer.yaml
Ahora, despliegue una lista de las versiones de Helm con el comando helm list . Busque los gráficos
denominados nginx-ingress y cert-manager, tal y como se muestra en la salida del ejemplo siguiente:
$ helm list --all-namespaces
NAME NAMESPACE REVISION UPDATED STATUS CHART

APP VERSION
nginx-ingress ingress-basic 1 2020-01-11 14:51:03.454165006 deployed
cert-manager ingress-basic 1 2020-01-06 21:19:03.866212286 deployed cert-
manager-v0.13.0 v0.13.0
Desinstale las versiones con el comando helm uninstall . En el ejemplo siguiente se desinstala la
implementación de entrada de NGINX y las implementaciones del administrador de certificados.
$ helm uninstall nginx-ingress cert-manager -n ingress-basic
release "nginx-ingress" deleted

release "cert-manager" deleted
Luego, quite las dos aplicaciones de ejemplo:

Elimine el propio espacio de nombres. Use el comando kubectl delete y especifique el nombre del espacio de
nombres:
Por último, elimine la dirección IP pública estática que creó para el controlador de entrada. Proporcione su
nombre del grupo de recursos de clúster MC_ obtenido en el primer paso de este artículo; por ejemplo,
MC_miGrupoDeRecursos_miClusterAKS_eastus:
az network public-ip delete --resource-group MC_myResourceGroup_myAKSCluster_eastus --name myAKSPublicIP
Pasos siguientes
CLI de Helm
cert-manager
También puede:
Control del tráfico de salida de los nodos de clúster
en Azure Kubernetes Service (AKS)
En este artículo se proporcionan los detalles necesarios que permiten proteger el tráfico de salida desde Azure
Kubernetes Service (AKS). Contiene los requisitos del clúster para una implementación de AKS base y requisitos
adicionales para características y complementos opcionales. Al final, se proporciona un ejemplo de cómo
configurar estos requisitos con Azure Firewall. Pero puede aplicar esta información a cualquier método o
dispositivo de restricción de salida.
Información previa
Los clústeres de AKS se implementan en una red virtual. Esta red puede ser administrada (creada por AKS) o
personalizada (configurada previamente por el usuario). En cualquier caso, el clúster tiene dependencias de
salida en servicios externos a esa red virtual (el servicio no tiene dependencias de entrada).
Para fines operativos y de administración, los nodos de un clúster de AKS deben tener acceso a determinados
puertos y nombres de dominio completo (FQDN). Estos puntos de conexión son obligatorios para que los nodos
se comuniquen con el servidor de API, o bien para descargar e instalar actualizaciones de seguridad de nodos y
componentes principales de clúster de Kubernetes. Por ejemplo, el clúster debe extraer imágenes de contenedor
del sistema base desde el Registro de contenedor de Microsoft (MCR).
Las dependencias de salida de AKS se definen casi por completo mediante FQDN, que no tienen direcciones
estáticas tras ellos. La falta de direcciones estáticas significa que no se pueden usar grupos de seguridad de red
para bloquear el tráfico saliente desde un clúster de AKS.
De forma predeterminada, los clústeres de AKS tienen acceso de salida a Internet ilimitado. Este nivel de acceso
a la red permite que los nodos y servicios que ejecuta accedan a recursos externos según sea necesario. Si desea
restringir el tráfico de salida, es necesario el acceso a un número limitado de puertos y direcciones para
mantener las tareas de mantenimiento del clúster en buen estado. La solución más sencilla para proteger las
direcciones de salida consiste en usar un dispositivo de firewall que pueda controlar el tráfico saliente en
función de los nombres de dominio. Azure Firewall, por ejemplo, puede restringir el tráfico saliente HTTP y
HTTPS en función del FQDN de destino. También puede configurar las reglas de seguridad y de firewall que
prefiera para permitir estos puertos y direcciones necesarios.
IMPORTANT
En este documento solo se explica cómo bloquear el tráfico que sale de la subred de AKS. De forma predeterminada, AKS
no tiene requisitos de entrada. No se admite el bloqueo del tráfico de subred interno mediante grupos de seguridad
de red (NSG) y firewalls. Para controlar y bloquear el tráfico dentro del clúster, use directivas de red .
Reglas de red de salida y FQDN necesarios para clústeres de AKS

Las siguientes reglas de red y FQDN o aplicación son obligatorias para un clúster de AKS; puede usarlas si
quiere configurar una solución que no sea Azure Firewall.
Las dependencias de dirección IP son para tráfico que no sea HTTP/HTTPS (tráfico TCP y UDP).
Los puntos de conexión HTTP/HTTPS de FQDN se pueden colocar en el dispositivo de firewall.
Los puntos de conexión HTTP/HTTPS de carácter comodín son dependencias que pueden variar con el clúster
de AKS en función de una serie de calificadores.
AKS usa un controlador de admisión para insertar el FQDN como una variable de entorno en todas las
implementaciones en kube-system y gatekeeper-system, lo que garantiza que toda la comunicación del
sistema entre los nodos y el servidor de API usa el FQDN del servidor de API y no su dirección IP.
Si tiene una aplicación o solución que necesita comunicarse con el servidor de API, debe agregar una regla
de red adicional para permitir la comunicación TCP con el puerto 443 de la dirección IP del servidor de API.
En raras ocasiones, si hay una operación de mantenimiento, es posible que cambie la dirección IP del
servidor de API. Las operaciones de mantenimiento planeado que pueden cambiar la dirección IP del
servidor de API siempre se comunican con antelación.
Reglas de red obligatorias globales de Azure
Las reglas de red obligatorias y las dependencias de dirección IP son las siguientes:
P UN TO DE C O N EXIÓ N DE
DEST IN O P ROTO C O LO P O RT USO
*:1194 UDP 1194 Para la comunicación segura

O por túnel entre los nodos y
ServiceTag - el plano de control. Esto no
AzureCloud. es necesario para los
<Region>:1194 clústeres privados.
O
CIDR regionales -
RegionCIDRs:1194
O
APIServerPublicIP:1194
(only known after
cluster creation)
*:9000 TCP 9000 Para la comunicación segura

ServiceTag - el plano de control. Esto no
AzureCloud. es necesario para los
<Region>:9000 clústeres privados.
O
CIDR regionales -
RegionCIDRs:9000
O
(only known after
cluster creation)
*:123 o UDP 123 Obligatorio para la

ntp.ubuntu.com:123 (si sincronización de hora del
usa reglas de red Azure protocolo de tiempo de red
Firewall) (NTP) en nodos de Linux.
CustomDNSIP:53 UDP 53 Si usa servidores DNS

(if using custom DNS personalizados, debe
servers) asegurarse de que sean
accesibles para los nodos de
clúster.
APIServerPublicIP:443 TCP 443 Obligatorio si se ejecutan

(if running pods o implementaciones
pods/deployments that que acceden al servidor de
access the API Server)
API, en cuyo caso usarían la
dirección IP de la API. Esto
no es necesario para los
clústeres privados.
Reglas de aplicación o FQDN obligatorias globales de Azure

Se requieren las siguientes reglas de aplicación / FQDN:
F Q DN DE DEST IN O P O RT USO
*.hcp.<location>.azmk8s.io HTTPS:443 Obligatorio para la comunicación entre

el nodo y el servidor de API.
Reemplace <location> con la región en
la que está implementado el clúster de
AKS.
mcr.microsoft.com HTTPS:443 Obligatorio para acceder a las

imágenes del Registro de contenedor
de Microsoft (MCR). Este registro
contiene imágenes o gráficos propios
(por ejemplo, coreDNS, etc.) Estas
imágenes son necesarias para la
creación correcta y el funcionamiento
del clúster, incluidas las operaciones de
escalado y actualización.
*.data.mcr.microsoft.com HTTPS:443 Obligatorio para el almacenamiento de

MCR respaldado por Azure Content
Delivery Network (CDN).
management.azure.com HTTPS:443 Obligatorio para las operaciones de

Kubernetes en la API de Azure.
login.microsoftonline.com HTTPS:443 Obligatorio para autenticación de

Azure Active Directory.
packages.microsoft.com HTTPS:443 Esta dirección es el repositorio de

paquetes de Microsoft que se usa para
las operaciones apt-get almacenadas
en caché. Los paquetes de ejemplo
incluyen Moby, PowerShell y la CLI de
Azure.
acs-mirror.azureedge.net HTTPS:443 Esta dirección es para el repositorio

necesario para descargar e instalar los
archivos binarios necesarios, como
kubenet y Azure CNI.
Reglas de red obligatorias para Azure China 21Vianet


ServiceTag - el plano de control.
AzureCloud.Region:1194
O
CIDR regionales -
RegionCIDRs:1194
O
(only known after
cluster creation)

AzureCloud.
<Region>:9000
O
CIDR regionales -
RegionCIDRs:9000
O
(only known after
cluster creation)

AzureCloud.<Region>:22
O
CIDR regionales -
RegionCIDRs:22
O
(only known after
cluster creation)


clúster.

dirección IP de la API.
Reglas de aplicación o FQDN obligatorias para Azure China 21Vianet

*.hcp. HTTPS:443 Obligatorio para la comunicación entre

<location>.cx.prod.service.azk8s.cn el nodo y el servidor de API.
AKS.
*.tun. HTTPS:443 Obligatorio para la comunicación entre

<location>.cx.prod.service.azk8s.cn el nodo y el servidor de API.
AKS.

.data.mcr.microsoft.com HTTPS:443 Obligatorio para el almacenamiento de

management.chinacloudapi.cn HTTPS:443 Obligatorio para las operaciones de

login.chinacloudapi.cn HTTPS:443 Obligatorio para autenticación de


Azure.
*.azk8s.cn HTTPS:443 Esta dirección es para el repositorio

necesario para descargar e instalar los
archivos binarios necesarios, como
kubenet y Azure CNI.
Reglas de red obligatorias para Azure Gobierno de EE. UU.


AzureCloud.
<Region>:1194
O
CIDR regionales -
RegionCIDRs:1194
O
(only known after
cluster creation)

AzureCloud.
<Region>:9000
O
CIDR regionales -
RegionCIDRs:9000
O
(only known after
cluster creation)


clúster.

dirección IP de la API.
Reglas de aplicación o FQDN obligatorias para Azure Gobierno de EE. UU.

*.hcp. HTTPS:443 Obligatorio para la comunicación entre

<location>.cx.aks.containerservice.azure.us el nodo y el servidor de API.
AKS.

*.data.mcr.microsoft.com HTTPS:443 Obligatorio para el almacenamiento de

management.usgovcloudapi.net HTTPS:443 Obligatorio para las operaciones de

login.microsoftonline.us HTTPS:443 Obligatorio para autenticación de


Azure.
acs-mirror.azureedge.net HTTPS:443 Esta dirección es para el repositorio

necesario para instalar los archivos
binarios necesarios, como kubenet y
Azure CNI.
Reglas opcionales de FQDN o aplicación para clústeres de AKS

Las siguientes reglas de aplicación o FQDN son opcionales, pero se recomiendan para clústeres de AKS:
security.ubuntu.com , HTTP:80 Esta dirección permite a los nodos del

azure.archive.ubuntu.com , clúster de Linux descargar las
changelogs.ubuntu.com revisiones de seguridad y
actualizaciones necesarias.
Si decide bloquear o no permitir estos FQDN, los nodos solo recibirán actualizaciones del sistema operativo
cuando realice una actualización de imagen de nodo o una actualización de clústeres.
Clústeres de AKS habilitados para GPU

Reglas de aplicación o FQDN obligatorias
Los clústeres de AKS que tienen GPU habilitado necesitan las reglas de aplicación / FQDN siguientes:
nvidia.github.io HTTPS:443 Esta dirección se utiliza para la

instalación y el funcionamiento
correctos del controlador en nodos
basados en GPU.
us.download.nvidia.com HTTPS:443 Esta dirección se utiliza para la

basados en GPU.
apt.dockerproject.org HTTPS:443 Esta dirección se utiliza para la

basados en GPU.
Grupos de nodos basados en Windows Server

Los grupos de nodos basados en Windows Server necesitan las reglas de aplicación/FQDN siguientes:
onegetcdn.azureedge.net, HTTPS:443 Para instalar archivos binarios

go.microsoft.com relacionados con Windows
*.mp.microsoft.com, HTTP:80 Para instalar archivos binarios

www.msftconnecttest.com, relacionados con Windows
ctldl.windowsupdate.com
Complementos e integraciones de AKS

Azure Monitor para contenedores
Hay dos opciones para proporcionar a los contenedores acceso a Azure Monitor; puede permitir ServiceTag de
Azure Monitor, o bien proporcionar acceso a las reglas de aplicación y FQDN necesarias.
Reglas de red obligatorias
ServiceTag - TCP 443 Este punto de conexión se

AzureMonitor:443 usa para enviar datos de
métricas y registros a Azure
Monitor y Log Analytics.

Los clústeres de AKS que tienen habilitado Azure Monitor para contenedores necesitan las reglas de aplicación /
FQDN siguientes:
F Q DN P O RT USO
F Q DN P O RT USO
dc.services.visualstudio.com HTTPS:443 Este punto de conexión se usa para la

telemetría de supervisión y las
métricas mediante Azure Monitor.
*.ods.opinsights.azure.com HTTPS:443 Azure Monitor usa este punto de

conexión para la ingesta de datos de
análisis de registros.
*.oms.opinsights.azure.com HTTPS:443 omsagent usa este punto de conexión

para autenticar el servicio de análisis
de registros.
*.monitoring.azure.com HTTPS:443 Este punto de conexión se usa para

enviar datos de métricas a Azure
Monitor.
Azure Dev Spaces

Actualice el firewall o la configuración de seguridad para permitir el tráfico de red hacia y desde todos los FQDN
siguientes y los servicios de infraestructura de Azure Dev Spaces.
Reglas de red obligatorias
ServiceTag - TCP 443 Este punto de conexión se

AzureDevSpaces usa para enviar datos de
métricas y registros a Azure
Monitor y Log Analytics.

Los clústeres de AKS que tienen habilitado Azure Dev Spaces necesitan las reglas de aplicación/FQDN
siguientes:
F Q DN P O RT USO
cloudflare.docker.com HTTPS:443 Esta dirección se usa para extraer

Linux Alpine y otras imágenes de
Azure Dev Spaces
gcr.io HTTPS:443 Esta dirección se usa para extraer

imágenes de Helm/Tiller
storage.googleapis.com HTTPS:443 Esta dirección se usa para extraer

imágenes de Helm/Tiller
Azure Policy
Los clústeres de AKS que tienen habilitado Azure Policy necesitan las reglas de aplicación / FQDN siguientes.
F Q DN P O RT USO
F Q DN P O RT USO
data.policy.core.windows.net HTTPS:443 Esta dirección se usa para extraer las

directivas de Kubernetes y para
notificar el estado de cumplimiento del
clúster en el servicio de directivas.
store.policy.core.windows.net HTTPS:443 Esta dirección se usa para extraer los

artefactos de Gatekeeper de las
directivas integradas.
dc.services.visualstudio.com HTTPS:443 Complemento de Azure Policy que

envía datos de telemetría al punto de
conexión de Application Insights.
Reglas de aplicación o FQDN obligatorios para Azure China 21Vianet

F Q DN P O RT USO
data.policy.azure.cn HTTPS:443 Esta dirección se usa para extraer las

store.policy.azure.cn HTTPS:443 Esta dirección se usa para extraer los

Reglas de aplicación o FQDN obligatorios para Azure US Government

F Q DN P O RT USO
data.policy.azure.us HTTPS:443 Esta dirección se usa para extraer las

store.policy.azure.us HTTPS:443 Esta dirección se usa para extraer los

Restricción del tráfico de salida mediante el firewall de Azure

Azure Firewall proporciona una etiqueta FQDN de Azure Kubernetes Service ( AzureKubernetesService ) para
simplificar esta configuración.
NOTE
La etiqueta FQDN contiene todos los FQDN enumerados anteriormente y se mantiene actualizada de forma automática.
Se recomienda tener un mínimo de 20 direcciones IP de front-end en Azure Firewall en escenarios de producción para
evitar incurrir en problemas de agotamiento de puertos SNAT.
A continuación se muestra un ejemplo de arquitectura de la implementación:

La entrada publica se inserta en el flujo mediante filtros de firewall
Los nodos de agente de AKS están aislados en una subred dedicada.
Azure Firewall se implementa en una subred propia.
Una regla de DNAT traduce la dirección IP pública del firewall en la dirección IP de front-end del
Las solicitudes de salida parten de los nodos del agente hacia la dirección IP interna de Azure Firewall
mediante una ruta definida por el usuario
Las solicitudes de los nodos de agente de AKS siguen una UDR que se ha colocado en la subred en la
que se implementó el clúster de AKS.
El firewall de Azure sale de la red virtual de un front-end con una IP pública.
El acceso a la red pública de Internet u otros servicios de Azure fluye hacia y desde la dirección IP del
servidor front-end del firewall.
Opcionalmente, el acceso al plano de control de AKS está protegido por intervalos IP autorizados del
servidor de API, que incluye la dirección IP de front-end pública del firewall.
Tráfico interno
Opcionalmente, en lugar o además de un equilibrador de carga público, puede usar un equilibrador
de carga interno para el tráfico interno, que también se podría aislar en una subred propia.
En los pasos siguientes se usa la etiqueta de FQDN AzureKubernetesService de Azure Firewall para restringir el
tráfico de salida desde el clúster de AKS y se proporciona un ejemplo de cómo configurar el tráfico de entrada
público a través del firewall.
Configuración mediante variables de entorno
Defina el conjunto de variables de entorno que se usarán en la creación de recursos.
PREFIX="aks-egress"
RG="${PREFIX}-rg"
LOC="eastus"
PLUGIN=azure
AKSNAME="${PREFIX}"
VNET_NAME="${PREFIX}-vnet"
AKSSUBNET_NAME="aks-subnet"
# DO NOT CHANGE FWSUBNET_NAME - This is currently a requirement for Azure Firewall.
FWSUBNET_NAME="AzureFirewallSubnet"
FWNAME="${PREFIX}-fw"
FWPUBLICIP_NAME="${PREFIX}-fwpublicip"
FWIPCONFIG_NAME="${PREFIX}-fwconfig"
FWROUTE_TABLE_NAME="${PREFIX}-fwrt"
FWROUTE_NAME="${PREFIX}-fwrn"
FWROUTE_NAME_INTERNET="${PREFIX}-fwinternet"
Creación de una red virtual con varias subredes

Aprovisione una red virtual con dos subredes independientes, una para el clúster y otra para el firewall.
Opcionalmente, también puede crear una para la entrada del servicio interno.
Cree el grupo de recursos que contendrá todos los recursos.
# Create Resource Group
az group create --name $RG --location $LOC
Cree una red virtual con dos subredes para hospedar el clúster de AKS y Azure Firewall. Cada uno tendrá su
propia subred. Comencemos con la red de AKS.
# Dedicated virtual network with AKS subnet

--resource-group $RG \
--name $VNET_NAME \
--location $LOC \
--subnet-name $AKSSUBNET_NAME \
# Dedicated subnet for Azure Firewall (Firewall name cannot be changed)

--resource-group $RG \
--vnet-name $VNET_NAME \
--name $FWSUBNET_NAME \
--address-prefix 10.42.2.0/24
Creación y configuración de un firewall de Azure con una UDR

Deben configurarse las reglas de entrada y salida del firewall de Azure. El propósito principal del firewall es que
las organizaciones puedan configurar reglas de tráfico de entrada y salida pormenorizadas hacia y desde el
clúster de AKS.
IMPORTANT
Si el clúster o la aplicación crea un gran número de conexiones de salida dirigidas al mismo subconjunto de destinos (o a
uno más reducido), es posible que necesite más direcciones IP de front-end de firewall para evitar que se agoten los
puertos por IP de front-end. Para obtener más información sobre cómo crear un firewall de Azure con varias direcciones
IP, vea esto .
Cree un recurso de SKU estándar con IP pública que se usará como dirección de front-end de Azure Firewall.
az network public-ip create -g $RG -n $FWPUBLICIP_NAME -l $LOC --sku "Standard"
Registre la extensión de la CLI en versión preliminar para crear un firewall de Azure.

# Install Azure Firewall preview CLI extension
az extension add --name azure-firewall
# Deploy Azure Firewall
az network firewall create -g $RG -n $FWNAME -l $LOC --enable-dns-proxy true
La dirección IP creada anteriormente puede asignarse ahora al front-end del firewall.
NOTE
La configuración de la dirección IP pública en el firewall de Azure puede tardar unos minutos. Para aprovechar el FQDN en
las reglas de red, es necesario habilitar el proxy DNS; cuando lo esté, el firewall escuchará en el puerto 53 y reenviará las
solicitudes DNS al servidor DNS especificado anteriormente. Esto permitirá al firewall traducir ese FQDN de forma
automática.
# Configure Firewall IP Config
az network firewall ip-config create -g $RG -f $FWNAME -n $FWIPCONFIG_NAME --public-ip-address

$FWPUBLICIP_NAME --vnet-name $VNET_NAME
Cuando el comando anterior se haya realizado correctamente, anote la dirección IP del servidor front-end del
firewall para la configuración posterior.
# Capture Firewall IP Address for Later Use
FWPUBLIC_IP=$(az network public-ip show -g $RG -n $FWPUBLICIP_NAME --query "ipAddress" -o tsv)

FWPRIVATE_IP=$(az network firewall show -g $RG -n $FWNAME --query "ipConfigurations[0].privateIpAddress" -o
tsv)
NOTE
Si utiliza el acceso seguro al servidor de la API de AKS con intervalos de direcciones IP autorizados, debe agregar la
dirección IP pública del firewall en el intervalo de IP autorizado.
Creación de una UDR con un salto al firewall de Azure

Azure enruta automáticamente el tráfico entre redes locales, las redes virtuales y las subredes de Azure. Si desea
cambiar algún enrutamiento predeterminado de Azure, debe crear una tabla de rutas.
Cree una tabla de rutas vacía para asociarla a una subred determinada. La tabla de rutas definirá el próximo
salto como el firewall de Azure creado anteriormente. Cada subred puede tener cero o una ruta de tablas de ruta
asociada.
# Create UDR and add a route for Azure Firewall
az network route-table create -g $RG -l $LOC --name $FWROUTE_TABLE_NAME

az network route-table route create -g $RG --name $FWROUTE_NAME --route-table-name $FWROUTE_TABLE_NAME --
address-prefix 0.0.0.0/0 --next-hop-type VirtualAppliance --next-hop-ip-address $FWPRIVATE_IP --subscription
$SUBID
az network route-table route create -g $RG --name $FWROUTE_NAME_INTERNET --route-table-name
$FWROUTE_TABLE_NAME --address-prefix $FWPUBLIC_IP/32 --next-hop-type Internet
Consulte en la documentación sobre las tablas de rutas de red virtual cómo invalidar las rutas del sistema
predeterminadas de Azure o agregar rutas adicionales a la tabla de rutas de una subred.
Adición de reglas de firewall
A continuación se muestran tres reglas de red que puede usar para configurar en el firewall; es posible que
tenga que adaptarlas en función de la implementación. La primera regla permite el acceso al puerto 9000 a
través de TCP. La segunda regla permite el acceso a los puertos 1194 y 123 a través de UDP (si va a implementar
en Azure China 21Vianet, es posible que necesite más). Las dos reglas solo permitirán el tráfico destinado al
CIDR de la región de Azure que se use, en este caso, Este de EE. UU. Por último, se agrega una tercera regla de
red para abrir el puerto 123 al FQDN ntp.ubuntu.com a través de UDP (la adición de un FQDN como una regla
de red es una de las características específicas de Azure Firewall y tendrá que adaptarla cuando use opciones
propias).
Después de establecer las reglas de red, también se agregará una regla de aplicación mediante
AzureKubernetesService , que abarca todos los FQDN necesarios a los que se puede acceder a través del puerto
TCP 443 y el puerto 80.
# Add FW Network Rules
az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'apiudp' --

protocols 'UDP' --source-addresses '*' --destination-addresses "AzureCloud.$LOC" --destination-ports 1194 --
action allow --priority 100
az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'apitcp' --
protocols 'TCP' --source-addresses '*' --destination-addresses "AzureCloud.$LOC" --destination-ports 9000
az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'time' --protocols
'UDP' --source-addresses '*' --destination-fqdns 'ntp.ubuntu.com' --destination-ports 123
# Add FW Application Rules
az network firewall application-rule create -g $RG -f $FWNAME --collection-name 'aksfwar' -n 'fqdn' --

source-addresses '*' --protocols 'http=80' 'https=443' --fqdn-tags "AzureKubernetesService" --action allow -
-priority 100
Para más información acerca del servicio Azure Firewall, consulte la documentación de Azure Firewall.
Asociación de la tabla de rutas a AKS
Para asociar el clúster al firewall, la subred dedicada del clúster debe hacer referencia a la tabla de rutas creada
anteriormente. Para crear la asociación, se puede emitir un comando a la red virtual que contiene el clúster y el
firewall para actualizar la tabla de rutas de la subred del clúster.
# Associate route table with next hop to Firewall to the AKS subnet
az network vnet subnet update -g $RG --vnet-name $VNET_NAME --name $AKSSUBNET_NAME --route-table
$FWROUTE_TABLE_NAME
Implementación de AKS con el tipo de salida UDR a la red existente

Ahora, un clúster de AKS se puede implementar en una red virtual existente. También se usará el tipo de salida
userDefinedRouting ; esta característica garantiza que se forzará el tráfico saliente a través del firewall y no
existirán otras rutas de salida (de forma predeterminada, se podría usar el tipo de salida Load Balancer).
Creación de una entidad de servicio con acceso de aprovisionamiento dentro de la red virtual existente
AKS usa una identidad de clúster (identidad administrada o entidad de servicio) para crear los recursos de
clúster. Una entidad de servicio que se pasa en el momento de la creación se usa para crear recursos de AKS
subyacentes, como los recursos de almacenamiento, las direcciones IP y los equilibradores de carga que AKS
utiliza (en su lugar también se puede usar una identidad administrada). Si no se le han concedido los permisos
adecuados siguientes, no podrá aprovisionar el clúster de AKS.
# Create SP and Assign Permission to Virtual Network
az ad sp create-for-rbac -n "${PREFIX}sp" --skip-assignment
Ahora, reemplace APPID y PASSWORD a continuación por el identificador de aplicación y la contraseña de la

entidad de servicio, generados automáticamente por la salida del comando anterior. Se hará referencia al
identificador de recurso de red virtual para conceder los permisos a la entidad de servicio para que AKS pueda
implementar recursos en ella.
APPID="<SERVICE_PRINCIPAL_APPID_GOES_HERE>"
PASSWORD="<SERVICEPRINCIPAL_PASSWORD_GOES_HERE>"
VNETID=$(az network vnet show -g $RG --name $VNET_NAME --query id -o tsv)
# Assign SP Permission to VNET
az role assignment create --assignee $APPID --scope $VNETID --role "Network Contributor"
Aquí puede comprobar los permisos detallados necesarios.

NOTE
Si usa el complemento de red kubenet, tendrá que conceder a la entidad de servicio de AKS o a la identidad administrada
permisos en la tabla de rutas creada previamente, ya que kubenet requiere una tabla de rutas para agregar las reglas de
enrutamiento necesarias.
RTID=$(az network route-table show -g $RG -n $FWROUTE_TABLE_NAME --query id -o tsv)

az role assignment create --assignee $APPID --scope $RTID --role "Network Contributor"
Implementación de AKS
Por último, el clúster de AKS se puede implementar en la subred existente que se ha dedicado al clúster. La
subred de destino en la que se va a realizar la implementación se define con la variable de entorno $SUBNETID .
No definimos la variable $SUBNETID en los pasos anteriores. Para establecer el valor del id. de la subred, puede
usar el comando siguiente:
SUBNETID=$(az network vnet subnet show -g $RG --vnet-name $VNET_NAME --name $AKSSUBNET_NAME --query id -o
tsv)
Definirá el tipo de salida para usar el UDR que ya existe en la subred. Esta configuración permitirá a AKS omitir
la configuración y el aprovisionamiento de IP para el equilibrador de carga.
IMPORTANT
Para obtener más información sobre el tipo de salida UDR, incluidas las limitaciones, vea UDR de tipo de salida .
TIP
Se pueden agregar otras características a la implementación del clúster, como Clúster privado .
La característica de inter valos de IP autorizados del ser vidor de API de AKS se puede agregar para limitar el acceso
del servidor de API solo al punto de conexión público del firewall. La característica de intervalos IP autorizados se indica en
el diagrama como opcional. Al habilitar la característica de intervalos de IP autorizados para limitar el acceso del servidor
de API, las herramientas de desarrollo deben usar una JumpBox desde la red virtual del firewall, o bien debe agregar
todos los puntos de conexión de desarrollador al intervalo de direcciones IP autorizado.
az aks create -g $RG -n $AKSNAME -l $LOC \

--node-count 3 --generate-ssh-keys \
--network-plugin $PLUGIN \
--outbound-type userDefinedRouting \
--service-cidr 10.41.0.0/16 \
--vnet-subnet-id $SUBNETID \
--service-principal $APPID \
--client-secret $PASSWORD \
--api-server-authorized-ip-ranges $FWPUBLIC_IP
Habilitación del acceso de desarrollador al servidor de API

Si en el paso anterior ha usado intervalos IP autorizados para el clúster, tendrá que agregar las direcciones IP de
las herramientas de desarrollador a la lista de intervalos IP autorizados del clúster de AKS para poder acceder al
servidor de API desde ahí. Otra opción consiste en configurar una JumpBox con las herramientas necesarias en
una subred independiente de la red virtual del firewall.
Agrege otra dirección IP a los intervalos autorizados con el siguiente comando:


Use el comando [az aks get-credentials][az-aks-get-credentials] para configurar kubectl a fin de conectarse al
clúster de Kubernetes recién creado.
az aks get-credentials -g $RG -n $AKSNAME
Implementación de un servicio público

Ahora puede empezar a exponer servicios e implementar aplicaciones en este clúster. En este ejemplo, se
expondrá un servicio público, pero también puede optar por exponer un servicio interno a través de un
equilibrador de carga interno.
Para implementar aplicación de votación de Azure, copie el código YAML siguiente en un archivo llamado
example.yaml .
# voting-storage-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: voting-storage
spec:
replicas: 1
selector:
matchLabels:
app: voting-storage
template:
metadata:
labels:
app: voting-storage
spec:
containers:
- name: voting-storage
image: mcr.microsoft.com/aks/samples/voting/storage:2.0
image: mcr.microsoft.com/aks/samples/voting/storage:2.0
args: ["--ignore-db-dir=lost+found"]
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
ports:
name: mysql
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_ROOT_PASSWORD
- name: MYSQL_USER
valueFrom:
secretKeyRef:
key: MYSQL_USER
- name: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
key: MYSQL_PASSWORD
- name: MYSQL_DATABASE
valueFrom:
secretKeyRef:
key: MYSQL_DATABASE
volumes:
- name: mysql-persistent-storage
claimName: mysql-pv-claim
---
# voting-storage-secret.yaml
apiVersion: v1
kind: Secret
metadata:
type: Opaque
data:
MYSQL_USER: ZGJ1c2Vy
MYSQL_PASSWORD: UGFzc3dvcmQxMg==
MYSQL_DATABASE: YXp1cmV2b3Rl
MYSQL_ROOT_PASSWORD: UGFzc3dvcmQxMg==
---
# voting-storage-pv-claim.yaml
apiVersion: v1
metadata:
name: mysql-pv-claim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
---
# voting-storage-service.yaml
apiVersion: v1
kind: Service
metadata:
labels:
app: voting-storage
spec:
ports:
- port: 3306
name: mysql
selector:
app: voting-storage
---
# voting-app-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: voting-app
spec:
replicas: 1
selector:
matchLabels:
app: voting-app
template:
metadata:
labels:
app: voting-app
spec:
containers:
- name: voting-app
image: mcr.microsoft.com/aks/samples/voting/app:2.0
imagePullPolicy: Always
ports:
name: http
env:
- name: MYSQL_HOST
value: "voting-storage"
- name: MYSQL_USER
valueFrom:
secretKeyRef:
key: MYSQL_USER
valueFrom:
secretKeyRef:
key: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
key: MYSQL_DATABASE
- name: ANALYTICS_HOST
value: "voting-analytics"
---
# voting-app-service.yaml
apiVersion: v1
kind: Service
metadata:
name: voting-app
labels:
app: voting-app
spec:
type: LoadBalancer
ports:
- port: 80
targetPort: 8080
name: http
selector:
app: voting-app
---
# voting-analytics-deployment.yaml
# voting-analytics-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: voting-analytics
spec:
replicas: 1
selector:
matchLabels:
app: voting-analytics
version: "2.0"
template:
metadata:
labels:
version: "2.0"
spec:
containers:
- name: voting-analytics
image: mcr.microsoft.com/aks/samples/voting/analytics:2.0
ports:
name: http
env:
- name: MYSQL_HOST
value: "voting-storage"
- name: MYSQL_USER
valueFrom:
secretKeyRef:
key: MYSQL_USER
valueFrom:
secretKeyRef:
key: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
key: MYSQL_DATABASE
---
# voting-analytics-service.yaml
apiVersion: v1
kind: Service
metadata:
name: voting-analytics
labels:
spec:
ports:
- port: 8080
name: http
selector:
Para implementar el servicio, ejecute:
kubectl apply -f example.yaml
Adición de una regla de DNAT al firewall de Azure

IMPORTANT
Cuando use Azure Firewall para restringir el tráfico de salida y cree una ruta definida por el usuario (UDR) para forzar todo
el tráfico de salida, asegúrese de crear una regla DNAT adecuada en el firewall para permitir correctamente el tráfico de
entrada. El uso de Azure Firewall con una UDR interrumpe la configuración de entrada debido al enrutamiento asimétrico.
(El problema se produce si la subred de AKS tiene una ruta predeterminada que va a la dirección IP privada del firewall,
pero está usando un equilibrador de carga público, de entrada o de servicio de Kubernetes del tipo: LoadBalancer). En
este caso, el tráfico entrante del equilibrador de carga se recibe a través de su dirección IP pública, pero la ruta de vuelta
pasa a través de la dirección IP privada del firewall. Dado que el firewall es con estado, quita el paquete de vuelta porque
el firewall no tiene conocimiento de una sesión establecida. Para aprender a integrar Azure Firewall con el equilibrador de
carga de entrada o de servicio, consulte Integración de Azure Firewall con Azure Standard Load Balancer.
Para configurar la conectividad de entrada, se debe escribir una regla de DNAT en el firewall de Azure. Para
probar la conectividad con el clúster, se define una regla para la dirección IP pública de front-end del firewall que
se va a enrutar a la dirección IP interna expuesta por el servicio interno.
La dirección de destino se puede personalizar porque es el puerto del firewall al que se va a acceder. La
dirección traducida debe ser la dirección IP del equilibrador de carga interno. El puerto traducido debe ser el
puerto expuesto para el servicio Kubernetes.
Tendrá que especificar la dirección IP interna asignada al equilibrador de carga creado por el servicio
Kubernetes. Para recuperar la dirección, ejecute:
kubectl get services
La dirección IP necesaria se mostrará en la columna EXTERNAL-IP y será similar a la siguiente.

kubernetes ClusterIP 10.41.0.1 <none> 443/TCP 10h
voting-analytics ClusterIP 10.41.88.129 <none> 8080/TCP 9m
voting-app LoadBalancer 10.41.185.82 20.39.18.6 80:32718/TCP 9m
voting-storage ClusterIP 10.41.221.201 <none> 3306/TCP 9m
Para obtener la IP del servicio, ejecute lo siguiente:
SERVICE_IP=$(kubectl get svc voting-app -o jsonpath='{.status.loadBalancer.ingress[*].ip}')
Para agregar la regla de NAT, ejecute lo siguiente:
az network firewall nat-rule create --collection-name exampleset --destination-addresses $FWPUBLIC_IP --

destination-ports 80 --firewall-name $FWNAME --name inboundrule --protocols Any --resource-group $RG --
source-addresses '*' --translated-port 80 --action Dnat --priority 100 --translated-address $SERVICE_IP
Validar conectividad
Vaya a la dirección IP de front-end del firewall de Azure en un explorador para validar la conectividad.
Debería ver la aplicación de votación de AKS. En este ejemplo, la dirección IP pública del firewall es
52.253.228.132 .
Para limpiar los recursos de Azure, elimine el grupo de recursos de AKS.
az group delete -g $RG
Pasos siguientes
En este artículo, ha aprendido qué puertos y direcciones se deben permitir si se quiere restringir el tráfico de
salida para el clúster. También ha visto cómo proteger el tráfico de salida mediante Azure Firewall.
Si es necesario, puede generalizar los pasos anteriores para reenviar el tráfico a la solución de salida preferida, si
sigue la documentación del tipo de salida userDefinedRoute .
Si quiere restringir cómo se comunican los pods entre sí y con las restricciones de tráfico horizontal de derecha
a izquierda en el clúster, vea Protección del tráfico entre pods mediante directivas de red en AKS.
Personalización de la salida de un clúster con una
ruta definida por el usuario
La salida de un clúster de AKS se puede personalizar para escenarios específicos. De forma predeterminada, AKS
aprovisionará un equilibrador de carga de SKU estándar, que se configurará y se usará para la salida. Sin
embargo, es posible que la configuración predeterminada no cumpla los requisitos de todos los escenarios si no
se permiten direcciones IP públicas o se requieren saltos adicionales para la salida.
En este artículo se explica cómo personalizar la ruta de salida de un clúster para admitir escenarios de red
personalizados, como los que no permiten direcciones IP públicas y requieren que el clúster se encuentre detrás
de un dispositivo virtual de red (NVA).
Requisitos previos
CLI de Azure, versión 2.0.81 o posterior.
Versión de API 2020-01-01 o posterior
Limitaciones
OutboundType solo se puede definir en el momento de crear el clúster y no se puede actualizar después.
La configuración de outboundType requiere clústeres de AKS con un valor de vm-set-type de
VirtualMachineScaleSets , y un valor de load-balancer-sku de Standard .
Para configurar outboundType en un valor de UDR , se necesita una ruta definida por el usuario con
conectividad de salida válida para el clúster.
Configurar outboundType en un valor de UDR implica que la IP de origen de la entrada enrutada al
equilibrador de carga no puede coincidir con la dirección de destino de la salida del clúster.
Introducción a los tipos de salida en AKS

Un clúster de AKS se puede personalizar con un outboundType único de tipo loadBalancer o
userDefinedRouting .
IMPORTANT
El tipo de salida afecta solo al tráfico de salida del clúster. Para obtener más información, consulte cómo configurar los
controladores de entrada.
NOTE
Puede usar su propia tabla de rutas con UDR y redes de kubenet. Asegúrese de que la identidad del clúster (entidad de
servicio o identidad administrada) tenga permisos de colaborador en la tabla de enrutamiento personalizada.
Tipo de salida de loadBalancer

Si se establece loadBalancer , AKS completa automáticamente la configuración siguiente. El equilibrador de
carga se usa para la salida a través de una dirección IP pública asignada a AKS. El tipo de salida de loadBalancer
admite los servicios de Kubernetes del tipo loadBalancer , que esperan la salida del equilibrador de carga
creado por el proveedor de recursos de AKS.
AKS realiza la siguiente configuración.
Se aprovisiona una dirección IP pública para la salida del clúster.
La dirección IP pública se asocia al recurso de equilibrador de carga.
Se configuran los grupos de back-end del equilibrador de carga para los nodos del agente en el clúster.
A continuación se muestra una topología de red implementada en clústeres de AKS de forma predeterminada,
que usa un valor de outboundType de loadBalancer .
Tipo de salida de userDefinedRouting
NOTE
El uso del tipo de salida es un escenario de redes avanzado y requiere una configuración de red adecuada.
Si se establece userDefinedRouting , AKS no configurará automáticamente las rutas de salida. El usuario debe
encargarse de la configuración de salida.
El clúster de AKS debe implementarse en una red virtual existente con una subred que se haya configurado
previamente porque, al no usar la arquitectura de equilibrador de carga estándar (SLB), debe establecer una
salida explícita. Como tal, esta arquitectura requiere el envío explícito del tráfico de salida a un dispositivo, como
un firewall, una puerta de enlace o un proxy, o para permitir que la traducción de direcciones de red (NAT) se
realice mediante una dirección IP pública asignada al equilibrador de carga estándar o dispositivo.
Creación de un equilibrador de carga con userDefinedRouting
Los clústeres de AKS con el tipo de salida UDR reciben un equilibrador de carga estándar (SLB) solo cuando se
implementa el primer servicio Kubernetes del tipo "loadBalancer". El equilibrador de carga se configura con una
dirección IP pública para las solicitudes entrantes y un grupo de back-end para las solicitudes salientes. Las
reglas de entrada se configuran mediante el proveedor de la nube de Azure, pero, como resultado de tener un
tipo de salida de UDR, no se configura ninguna dirección IP pública saliente ni tampoco reglas de
salida . El UDR seguirá siendo el único origen para el tráfico de salida.
Los equilibradores de carga de Azure no incurren en ningún cargo hasta que se coloca una regla.
Implementación de un clúster con el tipo de salida UDR y Azure

Firewall
Para ilustrar la aplicación de un clúster con un tipo de salida que usa una ruta definida por el usuario, se puede
configurar un clúster en una red virtual con una instancia de Azure Firewall en su propia subred. Consulte este
ejemplo en Restricción del tráfico de salida con Azure Firewall.
IMPORTANT
El tipo de salida de UDR requiere que haya una ruta para 0.0.0.0/0 y un destino del próximo salto de NVA (aplicación
virtual de red) en la tabla de rutas. La tabla de enrutamiento ya tiene un valor predeterminado de 0.0.0.0/0 a Internet, sin
una dirección IP pública para SNAT, simplemente agregar esta ruta no le proporcionará la salida. AKS validará que no cree
una ruta 0.0.0.0/0 que apunte a Internet, sino a NVA o a la puerta de enlace, etc. Cuando se utiliza un tipo de salida de
UDR, no se crea una dirección IP pública del equilibrador de carga para las solicitudes entrantes a menos que se
configure un servicio de tipo loadbalancer. AKS nunca crea una dirección IP pública para las solicitudes de salida si se
establece un tipo de salida de UDR.
Pasos siguientes
Consulte Información general de redes de Microsoft Azure.
Consulte cómo crear, modificar o eliminar una tabla de rutas.
Usar una dirección IP pública estática para el tráfico
de salida con un equilibrador de carga de la SKU
básico en Azure Kubernetes Service (AKS)
De forma predeterminada, la dirección IP de salida desde un clúster de Azure Kubernetes Service (AKS) se
asigna aleatoriamente. Esta configuración no es la más idónea cuando, por ejemplo, es necesario identificar una
dirección IP para acceder a servicios externos. En su lugar, es posible que tenga que asignar una dirección IP
estática que se va a agregar a una lista de permitidos de acceso al servicio.
En este artículo se muestra cómo crear y usar una dirección IP pública estática para el tráfico de salida en un
clúster de Azure Kubernetes Service (AKS).
Antes de empezar
En este artículo se supone que usa el equilibrador de carga básico de Azure. Se recomienda usar el equilibrador
de carga estándar de Azure y puede utilizar características más avanzadas para controlar el tráfico de salida de
AKS.
Azure.
IMPORTANT
En este artículo se usa el equilibrador de carga de la SKU básica con un único grupo de nodos. Esta configuración no está
disponible para varios grupos de nodos, ya que no se admite el equilibrador de carga de la SKU básica con varios grupos
de nodos. Consulte Uso de Standard Load Balancer en Azure Kubernetes Service (AKS) para más detalles sobre cómo usar
el equilibrador de carga de la SKU estándar.
Descripción del tráfico de salida

El tráfico saliente de un clúster de AKS sigue las convenciones de Azure Load Balancer. Antes de que se cree el
primer servicio Kubernetes de tipo LoadBalancer , los nodos de agente en un clúster de AKS no forman parte de
ningún grupo de Azure Load Balancer. En esta configuración, los nodos no tienen ninguna dirección IP pública
de nivel de instancia. Azure traduce el flujo de salida a una dirección IP de origen pública que no es configurable
o determinista.
Una vez que se ha creado un servicio Kubernetes de tipo LoadBalancer , los nodos de agente se agregan a un
grupo Azure Load Balancer. Load Balancer básico elige un único servidor front-end para usarlo con los flujos de
salida cuando hay varios servidores front-end de direcciones IP (públicas) candidatos para los flujos de salida.
Esta selección no es configurable y el algoritmo de selección se debe considerar aleatorio. Esta dirección IP
pública solo es válida para la duración de ese recurso. Si elimina el servicio Kubernetes LoadBalancer, el
equilibrador de carga asociado y la dirección IP también se eliminan. Si quiere asignar una dirección IP
específica o conservar una dirección IP para los servicios de Kubernetes reimplementados, puede crear y usar
una dirección IP pública estática.
Creación de una IP pública estática
Obtenga el nombre del grupo de recursos con el comando az aks show y agregue el parámetro de consulta
--query nodeResourceGroup . En este ejemplo se obtiene el grupo de recursos del nodo para el nombre de clúster
de AKS myAKSCluster en el grupo de recursos denominado myResourceGroup:
$ az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv
Cree una dirección IP pública estática con el comando az network public ip create. Especifique el nombre del
grupo de recursos del nodo que obtuvo en el comando anterior y, después, un nombre para el recurso de
dirección IP, como myAKSPublicIP:
az network public-ip create \

--name myAKSPublicIP \
--allocation-method static
Se muestra la dirección IP, como se indica en esta salida de ejemplo reducido:
{
"publicIp": {
"dnsSettings": null,
"etag": "W/\"6b6fb15c-5281-4f64-b332-8f68f46e1358\"",
"id":
"/subscriptions/<SubscriptionID>/resourceGroups/MC_myResourceGroup_myAKSCluster_eastus/providers/Microsoft.N
etwork/publicIPAddresses/myAKSPublicIP",
"idleTimeoutInMinutes": 4,
"ipAddress": "40.121.183.52",
[..]
}
Después puede obtener la dirección IP pública mediante el comando az network public-ip list. Especifique el
nombre del grupo de recursos del nodo y, después, envíe una consulta para ipAddress, como se muestra en este
ejemplo:
$ az network public-ip list --resource-group MC_myResourceGroup_myAKSCluster_eastus --query [0].ipAddress --

output tsv
40.121.183.52
Crear un servicio con la dirección IP estática

Para crear un servicio con la dirección IP pública estática, agregue la propiedad loadBalancerIP y el valor de la
dirección IP pública estática al manifiesto de YAML. Cree un archivo denominado egress-service.yaml y cópielo
en el siguiente código YAML. Indique su propia dirección IP pública que creó en el paso anterior.
apiVersion: v1
kind: Service
metadata:
name: azure-egress
spec:
type: LoadBalancer
ports:
- port: 80
Cree el servicio y la implementación con el comando kubectl apply .
kubectl apply -f egress-service.yaml
Este servicio configura una nueva dirección IP de front-end en Azure Load Balancer. Si no tiene más direcciones
IP configuradas, entonces ahora todo el tráfico de salida debería usar esta dirección. Cuando hay varias
direcciones configuradas en Azure Load Balancer, cualquiera de estas direcciones IP públicas son candidatas
para los flujos de salida y se selecciona una de forma aleatoria.
Comprobar la dirección de salida

Para comprobar que está usando la dirección IP pública estática, puede usar servicio de búsqueda DNS, como
checkip.dyndns.org .
Iniciar y asociar un pod Debian básico:
kubectl run -it --rm aks-ip --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
Para acceder a un sitio web desde dentro del contenedor, use apt-get para instalar curl en el contenedor.
apt-get update && apt-get install curl -y
Use curl para tener acceso al sitio checkip.dyndns.org. Se muestra la dirección IP de salida, como se indica en
esta salida de ejemplo: Esta dirección IP coincide con la dirección IP pública estática creada y definida para el
servicio Azure Load Balancer:
$ curl -s checkip.dyndns.org
<html><head><title>Current IP Check</title></head><body>Current IP Address: 40.121.183.52</body></html>
Pasos siguientes
Para evitar mantener varias direcciones IP públicas en Azure Load Balancer, recomendamos que use un
controlador de entrada. Los controladores de entrada proporcionan otras ventajas, como terminación SSL/TLS,
compatibilidad con reescritura de URI y cifrado SSL/TLS ascendente. Para más información, consulte Creación
de un controlador de entrada en Azure Kubernetes Service (AKS).
Personalización de CoreDNS con Azure Kubernetes
Service
Azure Kubernetes Service (AKS) usa el proyecto CoreDNS para la administración y la resolución DNS del clúster
con todos los clústeres 1.12.x y versiones superiores. Anteriormente, usaba el proyecto kube-dns. Actualmente,
este proyecto kube-dns está en desuso. Para obtener más información sobre la personalización de CoreDNS y
Kubernetes, consulte la documentación oficial del canal de subida.
Dado que AKS es un servicio administrado, no puede modificar la configuración principal para CoreDNS (un
archivo CoreFile). En vez de eso, use un archivo ConfigMap de Kubernetes para invalidar la configuración
predeterminada. Para ver los archivos ConfigMap de CoreDNS predeterminados de AKS, use el comando
kubectl get configmaps --namespace=kube-system coredns -o yaml .
En este artículo se muestra cómo usar los archivos ConfigMap para las opciones de personalización básica de
CoreDNS en AKS. Este enfoque difiere de la configuración de CoreDNS en otros contextos, como el uso de
CoreFile. Compruebe la versión de CoreDNS que ejecuta, ya que los valores de configuración pueden cambiar
entre versiones.
NOTE
kube-dns ofrecía opciones de personalización diferentes a través de una asignación de configuración de Kubernetes.
CoreDNS no es compatible con versiones anteriores de kube-dns. Todas las personalizaciones que usó anteriormente
deben actualizarse para su uso con CoreDNS.
Antes de empezar
Al crear una configuración como en los ejemplos siguientes, los nombres de la sección data deben finalizar en
.server u .override. Esta convención de nomenclatura se define en el valor predeterminado CoreDNS Configmap
de AKS, que se puede ver con el comando kubectl get configmaps --namespace=kube-system coredns -o yaml .
Elementos admitidos y no admitidos

Se admiten todos los complementos de CoreDNS integrados. No se admiten los complementos de terceros o
complementarios.
Reescritura de DNS
Un escenario que debe considerar es la reescritura de nombres DNS sobre la marcha. En el ejemplo siguiente,
reemplace <domain to be written> por su propio nombre de dominio completo. Cree un archivo denominado
corednsms.yaml y pegue la siguiente configuración de ejemplo:
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns-custom
namespace: kube-system
data:
test.server: | # you may select any name here, but it must end with the .server file extension
<domain to be rewritten>.com:53 {
errors
cache 30
rewrite name substring <domain to be rewritten>.com default.svc.cluster.local
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
upstream
fallthrough in-addr.arpa ip6.arpa
}
forward . /etc/resolv.conf # you can redirect this to a specific DNS server such as 10.0.0.10, but
that server must be able to resolve the rewritten domain name
}
IMPORTANT
Si redirige a un servidor DNS, como la dirección IP del servicio CoreDNS, ese servidor DNS debe poder resolver el nombre
de dominio reescrito.
Cree el archivo ConfigMap mediante el comando kubectl apply configmap y especifique el nombre de su
manifiesto de YAML:
kubectl apply -f corednsms.yaml
Para comprobar que las personalizaciones se han aplicado, use el comando kubectl get configmaps y
especifique su archivo ConfigMap coredns-custom:
kubectl get configmaps --namespace=kube-system coredns-custom -o yaml
Ahora, fuerce a que CoreDNS vuelva a cargar el archivo ConfigMap. El comando kubectl delete pod no es
destructivo y no provoca tiempo de inactividad. Se eliminan los pods kube-dns y el Programador de Kubernetes
vuelve a crearlos. Estos nuevos pods contienen el cambio en el valor TTL.
kubectl delete pod --namespace kube-system -l k8s-app=kube-dns
NOTE
El comando anterior es correcto. Mientras cambiamos coredns , la implementación tiene el nombre kube-dns .
Servidor de reenvío personalizado

Si tiene que especificar un servidor de reenvío para el tráfico de red, puede crear un elemento ConfigMap para
personalizar el DNS. En el ejemplo siguiente, actualice el nombre y la dirección del forward con los valores de
su propio entorno. Cree un archivo denominado corednsms.yaml y pegue la siguiente configuración de ejemplo:
apiVersion: v1
kind: ConfigMap
metadata:
data:
<domain to be rewritten>.com:53 {
forward foo.com 1.1.1.1
}
Como en los ejemplos anteriores, cree el archivo ConfigMap mediante el comando kubectl apply configmap y
especifique el nombre de su manifiesto de YAML. Después, fuerce a que CoreDNS vuelva a cargar el archivo
ConfigMap con el comando kubectl delete pod para que el programador de Kubernetes vuelva a crearlo:

kubectl delete pod --namespace kube-system --selector k8s-app=kube-dns
Uso de dominios personalizados

Es posible que le interese configurar dominios personalizados que solo se puedan resolver internamente. Por
ejemplo, tal vez quiera resolver el dominio personalizado puglife.local, que no es un dominio de nivel superior
válido. Sin un archivo ConfigMap de dominio personalizado, el clúster de AKS no puede resolver la dirección.
En el ejemplo siguiente, actualice con los valores de su propio entorno el dominio personalizado y la dirección IP
a la que se va a dirigir el tráfico. Cree un archivo denominado corednsms.yaml y pegue la siguiente
configuración de ejemplo:
apiVersion: v1
kind: ConfigMap
metadata:
data:
puglife.server: | # you may select any name here, but it must end with the .server file extension
puglife.local:53 {
errors
cache 30
forward . 192.11.0.1 # this is my test/dev DNS server
}

Dominios de código auxiliar

También se puede usar CoreDNS para configurar dominios de código auxiliar. En el ejemplo siguiente, actualice
con los valores de su propio entorno los dominios personalizados y las direcciones IP. Cree un archivo
denominado corednsms.yaml y pegue la siguiente configuración de ejemplo:
apiVersion: v1
kind: ConfigMap
metadata:
data:
abc.com:53 {
errors
cache 30
forward . 1.2.3.4
}
my.cluster.local:53 {
errors
cache 30
forward . 2.3.4.5
}

Complemento de hosts
Dado que se admiten todos los complementos integrados, también se puede personalizar el complemento de
Hosts de CoreDNS:
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns-custom # this is the name of the configmap you can overwrite with your changes
data:
test.override: | # you may select any name here, but it must end with the .override file extension
hosts example.hosts example.org { # example.hosts must be a file
10.0.0.1 example.org
fallthrough
}
Habilitación del registro de depuración de consultas de DNS

Para habilitar el registro de consultas de DNS, aplique la siguiente configuración en la instancia coredns-custom
de ConfigMap:
apiVersion: v1
kind: ConfigMap
metadata:
data:
log.override: | # you may select any name here, but it must end with the .override file extension
log
Pasos siguientes
En este artículo se han mostrado algunos escenarios de ejemplo para la personalización de CoreDNS. Para
obtener información sobre el proyecto CoreDNS, consulte la página de proyecto del canal de subida de
CoreDNS.
Para obtener más información sobre conceptos básicos de red, consulte Conceptos de redes de aplicaciones en
Entidades de servicio con Azure Kubernetes Service
(AKS)
Para interactuar con las API de Azure, un clúster de AKS requiere una entidad de servicio de
Azure Active Directory (AD) o una identidad administrada. Estos elementos se necesitan para crear y administrar
dinámicamente otros recursos de Azure, como Azure Load Balancer o Container Registry.
En este artículo se muestra cómo crear y usar una entidad de servicio para los clústeres de AKS.
Antes de empezar
Para crear una entidad de servicio de Azure AD, es preciso tener los permisos suficientes para registrar una
aplicación en un inquilino de Azure AD y asignarle un rol en una suscripción. Si no tiene los permisos
necesarios, es posible que tenga que pedir al administrador de Azure AD o de la suscripción que asigne los
permisos necesarios o crear previamente una entidad de servicio para su uso con el clúster de AKS.
Si usa una entidad de servicio de otro inquilino de Azure AD, hay consideraciones adicionales en torno a los
permisos disponibles al implementar el clúster. Puede que no tenga los permisos adecuados para leer y escribir
datos del directorio. Para obtener más información, consulte ¿Cuáles son los permisos de usuario
predeterminados en Azure Active Directory?
CLI de Azure
Azure PowerShell
Azure.
Creación y uso de una entidad de servicio automáticamente

CLI de Azure
Azure PowerShell
Cuando crea un clúster de AKS en Azure Portal o mediante el comando az aks create, Azure puede generar
automáticamente una entidad de servicio.
En el siguiente ejemplo de la CLI de Azure, no se especifica una entidad de servicio. En este escenario, la CLI de
Azure crea un entidad de servicio para el clúster de AKS. Para completar esta operación correctamente, la cuenta
debe tener los derechos apropiados para crear una entidad de servicio.
az aks create --name myAKSCluster --resource-group myResourceGroup
Creación manual de una entidad de servicio

CLI de Azure
Azure PowerShell
Para crear manualmente una entidad de servicio con la CLI de Azure, use el comando az ad sp create-for-rbac.
En el ejemplo siguiente, el parámetro --skip-assignment impide la asignación de asignaciones predeterminadas
adicionales:
az ad sp create-for-rbac --skip-assignment --name myAKSClusterServicePrincipal
La salida será similar al del ejemplo siguiente: Tome nota de sus valores appId y password . Se usan al crear un
clúster de AKS en la sección siguiente.
{
"appId": "559513bd-0c19-4c1a-87cd-851a26afd5fc",
"displayName": "myAKSClusterServicePrincipal",
"name": "http://myAKSClusterServicePrincipal",
"password": "e763725a-5eee-40e8-a466-dc88d980f415",
"tenant": "72f988bf-86f1-41af-91ab-2d7cd011db48"
}
Especificación de una entidad de servicio para un clúster de AKS

CLI de Azure
Azure PowerShell
Para usar una entidad de servicio existente al crear un clúster de AKS mediante el comando az aks create, use los
parámetros --service-principal y --client-secret para especificar los valores appId y password a partir del
resultado del comando az ad sp create-for-rbac:
az aks create \
NOTE
Si utiliza una entidad de servicio existente con secreto personalizado, asegúrese de que este no supera los 190 bytes.
Si implementa un clúster de AKS mediante Azure Portal, en la página autenticación del cuadro de diálogo
Creación de un clúster de Kubernetes , elija Configurar la entidad de ser vicio . Seleccione Usar
existente y especifique los valores siguientes:
Id. de cliente de la entidad de ser vicio es su appId
Secreto del cliente de la entidad de ser vicio es el valor de contraseña
Delegación del acceso a otros recursos de Azure
La entidad de servicio del clúster de AKS se puede utilizar para acceder a otros recursos. Por ejemplo, si quiere
implementar el clúster de AKS en una subred de red virtual de Azure o conectarse a Azure Container Registry
(ACR), debe delegar el acceso a estos recursos a la entidad de servicio.
CLI de Azure
Azure PowerShell
Para delegar permisos, cree una asignación de roles mediante el comando az role assignment create. Asigne el
elemento appId a un ámbito determinado, como un grupo de recursos o un recurso de red virtual. Un rol
define qué permisos tiene la entidad de servicio en el recurso, como se muestra en el ejemplo siguiente:
az role assignment create --assignee <appId> --scope <resourceScope> --role Contributor
El elemento --scope de un recurso debe ser un identificador de recurso completo, como

/subscriptions/<guid>/resourceGroups/myResourceGroup o
/subscriptions/<guid>/resourceGroups/myResourceGroupVnet/providers/Microsoft.Network/virtualNetworks/
myVnet
NOTE
Si ha quitado la asignación del rol Colaborador del grupo de recursos del nodo, se pueden producir errores en las
siguientes operaciones.
Las secciones siguientes detallan las delegaciones comunes que es posible que deba realizar.
Azure Container Registry
CLI de Azure
Azure PowerShell
Si usa Azure Container Registry (ACR) como el almacén de imágenes de contenedor, deberá conceder permisos
a la entidad de servicio que el clúster de AKS pueda leer y extraer imágenes. Actualmente, la configuración
recomendada es usar el comando az aks create o az aks update para integrarse con un registro y asignar el rol
adecuado a la entidad de servicio. Para ver los pasos detallados, consulte Autenticación con Azure Container
Registry desde Azure Kubernetes Service.
Redes
Puede usar redes avanzadas en las que la red virtual y la subred o las direcciones IP públicas se encuentran en
otro grupo de recursos. Asigne el rol integrado Colaborador de la red en la subred dentro de la red virtual.
Como alternativa, puede crear un rol personalizado con permisos para tener acceso a los recursos de red de ese
grupo de recursos. Consulte permisos del servicio AKS para obtener más información.
Storage
Es posible que necesite acceder a los recursos de disco existentes en otro grupo de recursos. Asigne uno de los
siguientes conjuntos de permisos de rol:
Cree un rol personalizado y defina los siguientes permisos de rol:
Microsoft.Compute/disks/read
Microsoft.Compute/disks/write
O bien, asigne el rol integrado Colaborador de la cuenta de almacenamiento en el grupo de recursos.
Azure Container Instances
Si usa Virtual Kubelet para la integración con AKS y elige ejecutar Azure Container Instances (ACI) en un grupo
de recursos separado del clúster de AKS, la entidad de servicio AKS debe tener concedidos los permisos de
Colaborador en el grupo de recursos de ACI.
Consideraciones adicionales
CLI de Azure
Azure PowerShell
Cuando use entidades de servicio de AKS y Azure AD, tenga en cuenta lo siguiente.
La entidad de servicio para Kubernetes forma parte de la configuración del clúster. Sin embargo, no use la
identidad para implementar el clúster.
De forma predeterminada, las credenciales de la entidad de servicio son válidas durante un año. Puede
actualizar o rotar las credenciales de la entidad de servicio en cualquier momento.
Cada entidad de servicio está asociada a una aplicación de Azure AD. La entidad de servicio de un clúster de
Kubernetes puede asociarse con cualquier nombre de aplicación de Azure AD válido (por ejemplo,
https://www.contoso.org/example ). La dirección URL de la aplicación no tiene por qué ser un punto de
conexión real.
Al especificar el identificador de cliente , utilice el valor de appId .
En las VM del nodo de agente del clúster de Kubernetes, las credenciales de la entidad de servicio se
almacenan en el archivo /etc/kubernetes/azure.json .
Cuando use el comando az aks create para generar la entidad de servicio automáticamente, sus credenciales
se escriben en el archivo ~/.azure/aksServicePrincipal.json de la máquina que se usa para ejecutar el
comando.
Si no pasa específicamente una entidad de servicio en comandos adicionales de la CLI de AKS, se usa la
entidad de servicio predeterminada ubicada en ~/.azure/aksServicePrincipal.json .
Opcionalmente, también puede quitar el archivo aksServicePrincipal.json y AKS creará una entidad de
servicio.
Al eliminar un clúster de AKS creado mediante az aks create, no se elimina la entidad de servicio que se ha
creado automáticamente.
Para eliminar la entidad de servicio, consulte el clúster servicePrincipalProfile.clientId y, después,
elimínelo con az ad sp delete. Reemplace los nombres de clúster y del grupo de recursos
siguientes con los suyos propios.
az ad sp delete --id $(az aks show -g myResourceGroup -n myAKSCluster --query
servicePrincipalProfile.clientId -o tsv)
CLI de Azure
Azure PowerShell
La CLI de Azure almacena en caché las credenciales de la entidad de servicio para un clúster de AKS. Si estas
credenciales han expirado, encontrará errores al implementar clústeres de AKS. El siguiente mensaje de error al
ejecutar az aks create puede indicar un problema con las credenciales de la entidad de servicio almacenadas en
caché:
Operation failed with status: 'Bad Request'.

Details: The credentials in ServicePrincipalProfile were invalid. Please see https://aka.ms/aks-sp-help for
more details.
(Details: adal: Refresh request failed. Status Code = '401'.
Compruebe la antigüedad del archivo de credenciales con el comando siguiente:
ls -la $HOME/.azure/aksServicePrincipal.json
El tiempo de expiración predeterminado para las credenciales de la entidad de servicio es de un año. Si el

archivo aksServicePrincipal.json tiene más de un año, elimine el archivo e intente volver a implementar un
clúster de AKS.
Pasos siguientes
Para obtener más información sobre las entidades de servicio de Azure Active Directory, consulte Objetos de
aplicación y de entidad de servicio.
Para obtener información sobre cómo actualizar las credenciales, vea Actualizar o rotar las credenciales de una
entidad de servicio en AKS.
Uso de identidades administradas en Azure
Kubernetes Service
Actualmente, un clúster de Azure Kubernetes Service (AKS) (específicamente, el proveedor de nube Kubernetes)
requiere una identidad para crear recursos adicionales, como equilibradores de carga y discos administrados en
Azure. Esta identidad puede ser una identidad administrada o una entidad de servicio. Si usa una entidad de
servicio, debe indicarla, o bien AKS la creará automáticamente. Si usa la identidad administrada, AKS la creará
automáticamente. Llega un momento en que los clústeres que usan entidades de servicio alcanzan un estado en
el que se debe renovar la entidad de servicio para mantener el clúster en funcionamiento. La administración de
entidades de servicio agrega complejidad, por lo que es más fácil usar identidades administradas. Se aplican los
mismos requisitos de permisos tanto en las entidades de servicio como en las identidades administradas.
Las identidades administradas son básicamente un contenedor relacionado con las entidades de servicio y
facilitan su administración. La rotación de credenciales para MI se produce automáticamente cada 46 días según
el valor predeterminado de Azure Active Directory. AKS usa tipos de identidad administrados asignados por el
sistema y asignados por el usuario. Estas identidades son inmutables actualmente. Para más información,
consulte el tema sobre identidades administradas para recursos de Azure.
Antes de empezar
Debe tener instalado el siguiente recurso:
Limitaciones
No se admite que los inquilinos trasladen o migren los clústeres habilitados para identidades administradas.
Si el clúster tiene aad-pod-identity habilitado, los pods de Identidad administrada del nodo (NMI) modifican
las tablas de IP de los nodos para interceptar las llamadas que se realizan en el punto de conexión de Azure
Instance Metadata. Esta configuración hace que NMI intercepte toda solicitud realizada al punto de conexión
de Metadata, incluso aunque el pod no utilice aad-pod-identity . La CRD de AzurePodIdentityException se
puede configurar para informar a aad-pod-identity de que las solicitudes dirigidas al punto de conexión de
Metadata que se originen en un pod que coincida con las etiquetas definidas en la CRD deben pasar por el
servidor proxy sin que se procesen en NMI. Los pods del sistema con la etiqueta
kubernetes.azure.com/managedby: aks del espacio de nombres kube-system deben excluirse en
aad-pod-identity configurando la CRD de AzurePodIdentityException. Para obtener más información,
consulte este artículo acerca de cómo deshabilitar aad-pod-identity en una aplicación o pod específicos. Para
configurar una excepción, instale mic-exception.yaml.
Resumen de identidades administradas

AKS usa varias identidades administradas para servicios integrados y complementos.
P ERM ISO S T RA IGA SU P RO P IA

IDEN T IDA D N O M B RE C A SO DE USO P REDET ERM IN A DO S IDEN T IDA D
Plano de control no visible La usan los Rol de colaborador Compatible

componentes del para un grupo de
plano de control de recursos de nodo
AKS para administrar
los recursos de
clúster, incluidos los
equilibradores de
carga de entrada y
las direcciones IP
públicas
administradas de
AKS, y las
operaciones del
escalador automático
del clúster.
Kubelet Nombre de clúster de Autenticación con N/D (para Compatible (versión

AKS-agentpool Azure Container kubernetes 1.15 y preliminar)
Registry (ACR) versiones
posteriores)
Complemento AzureNPM No se requiere N/D No

ninguna identidad
Complemento Supervisión de red No se requiere N/D No

AzureCNI ninguna identidad
Complemento azure-policy No se requiere N/D No

(gatekeeper) ninguna identidad
Complemento azure-policy No se requiere N/D No

ninguna identidad
Complemento Calico No se requiere N/D No

ninguna identidad
Complemento Panel No se requiere N/D No

ninguna identidad
Complemento HTTPApplicationRouti Administra los Rol de lector para No

ng recursos de red grupo de recursos de
necesarios nodo, rol colaborador
para zona DNS
Complemento Ingresar a la puerta Administra los Rol de colaborador No

de enlace de recursos de red para grupo de
aplicaciones necesarios recursos de nodo
Complemento omsagent Se usa para enviar Supervisión del rol No

métricas de AKS a del publicador de
Azure Monitor métricas
Complemento Nodo virtual Administra los Rol de colaborador No

(ACIConnector) recursos de red para grupo de
necesarios para recursos de nodo
Azure Container
Instances (ACI)
Proyecto de software aad-pod-identity Permite que las N/D Pasos para conceder
de código abierto aplicaciones puedan el permiso en
acceder de manera https://github.com/A
segura a los recursos zure/aad-pod-
en la nube con Azure identity#role-
Active Directory assignment.
(AAD)
Creación de un clúster de AKS con identidades administradas

Ahora puede crear un clúster de AKS con identidades administradas utilizando los siguientes comandos de la
CLI.
En primer lugar, cree un grupo de recursos de Azure:

Después, cree un clúster de AKS:
az aks create -g myResourceGroup -n myManagedCluster --enable-managed-identity
Una vez creado el clúster, puede implementar las cargas de trabajo de la aplicación en el nuevo clúster e
interactuar con él del mismo modo que con los clústeres de AKS basados en una entidad de servicio.
Por último, obtenga credenciales para acceder al clúster:
az aks get-credentials --resource-group myResourceGroup --name myManagedCluster
Actualización de un clúster de AKS a identidades administradas

Ahora puede actualizar un clúster de AKS que trabaja actualmente con entidades de servicio para trabajar con
identidades administradas mediante los siguientes comandos de la CLI.
En primer lugar, registre la marca de características para la identidad asignada por el sistema:
az feature register --namespace Microsoft.ContainerService -n MigrateToMSIClusterPreview
Actualice la identidad asignada por el sistema:
az aks update -g <RGName> -n <AKSName> --enable-managed-identity
Registre la marca de características para la identidad asignada por el usuario:

az feature register --namespace Microsoft.ContainerService -n UserAssignedIdentityPreview
Actualice la identidad asignada por el usuario:
az aks update -g <RGName> -n <AKSName> --enable-managed-identity --assign-identity

<UserAssignedIdentityResourceID>
NOTE
Una vez que se hayan actualizado las identidades asignadas por el sistema o por el usuario, realice una operación
az aks nodepool upgrade --node-image-only en los nodos para completar la actualización a la identidad administrada.
Obtención y uso de la identidad administrada asignada por el sistema

para el clúster de AKS
Confirme que el clúster de AKS usa la identidad administrada con el siguiente comando de la CLI:
az aks show -g <RGName> -n <ClusterName> --query "servicePrincipalProfile"
Si el clúster usa identidades administradas, verá un valor clientId de "msi". Un clúster que use una entidad de
servicio mostrará en su lugar el identificador de objeto. Por ejemplo:
{
"clientId": "msi"
}
Después de comprobar que el clúster usa identidades administradas, puede encontrar el identificador de objeto
de la identidad asignada por el sistema del plano de control con el siguiente comando:
az aks show -g <RGName> -n <ClusterName> --query "identity"
{
"principalId": "<object-id>",
"tenantId": "<tenant-id>",
"type": "SystemAssigned",
"userAssignedIdentities": null
},
NOTE
Para crear y usar su propia red virtual, una dirección IP estática o un disco de Azure conectado en el que los recursos
estén fuera del grupo de recursos del nodo de trabajo, use el PrincipalID del sistema de clúster asignado a la identidad
administrada para realizar una asignación de roles. Para obtener más información sobre la asignación, consulte Delegación
del acceso a otros recursos de Azure.
Las concesiones de permisos a la identidad administrada de clúster que el proveedor en la nube de Azure utiliza pueden
tardar hasta 60 minutos en rellenarse.
Traer su propia instancia administrada de plano de control

Una identidad de plano de control personalizado permite que se conceda acceso a la identidad existente antes
de la creación del clúster. Esta característica permite escenarios como el uso de una red virtual personalizada o
outboundType de UDR con una identidad administrada previamente creada.
Debe tener instalada la versión 2.15.1 de la CLI de Azure o una versión posterior.
Limitaciones
Azure Government no se admite actualmente.
Azure China 21Vianet no se admite actualmente.
Si aún no tiene una identidad administrada, debería continuar y crear una, por ejemplo, mediante az identity CLI.
az identity create --name myIdentity --resource-group myResourceGroup
El resultado debería tener este aspecto:
{
"clientId": "<client-id>",
"clientSecretUrl": "<clientSecretUrl>",
"id":
"/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssi
gnedIdentities/myIdentity",
"location": "westus2",
"name": "myIdentity",
"principalId": "<principalId>",
"tags": {},
"tenantId": "<tenant-id>>",
"type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}
Si la identidad administrada forma parte de su suscripción, puede usar el comando az identity CLI para
consultarla.
az identity list --query "[].{Name:name, Id:id, Location:location}" -o table
Ahora puede usar el siguiente comando para crear el clúster con la identidad existente:
az aks create \
--name myManagedCluster \
--service-cidr 10.2.0.0/24 \
--enable-managed-identity \
--assign-identity <identity-id> \
La creación correcta de un clúster con sus propias identidades administradas contiene esta información de perfil
de userAssignedIdentities:
"identity": {
"principalId": null,
"tenantId": null,
"type": "UserAssigned",
"userAssignedIdentities": {
gnedIdentities/myIdentity": {
"principalId": "<principal-id>"
}
}
},
Bring your own kubelet MI (versión preliminar)

IMPORTANT
Una identidad de kubelet permite que se conceda acceso a la identidad existente antes de la creación del clúster.
Esta característica permite escenarios como la conexión a ACR con una identidad administrada creada
previamente.
Requisitos previos
Debe tener instalada la versión 2.21.1 de la CLI de Azure o una versión posterior.
Debe tener instalada la versión 0.5.10 de aks-preview o una versión posterior.
Limitaciones
Solo funciona con un clúster administrado asignado por el usuario.
Azure Government no se admite actualmente.
Azure China 21Vianet no se admite actualmente.
En primer lugar, registre la marca de características para la identidad de Kubelet:
az feature register --namespace Microsoft.ContainerService -n CustomKubeletIdentityPreview
az feature list -o table --query "[?contains(name,

'Microsoft.ContainerService/CustomKubeletIdentityPreview')].{Name:name,State:properties.state}"
Creación u obtención de identidades administradas

Si aún no tiene una identidad administrada de plano de control, debería continuar y crear una. En el ejemplo
siguiente se usa el comando az identity create:
az identity create --name myIdentity --resource-group myResourceGroup
{
"id":
gnedIdentities/myIdentity",
"name": "myIdentity",
"tags": {},
}
Si aún no tiene una identidad administrada de kubelet, debería continuar y crear una. En el ejemplo siguiente se
usa el comando az identity create:
az identity create --name myKubeletIdentity --resource-group myResourceGroup
{
"id":
gnedIdentities/myKubeletIdentity",
"name": "myKubeletIdentity",
"tags": {},
}
Si la identidad administrada existente forma parte de su suscripción, puede usar el comando az identity list para
consultarla:
az identity list --query "[].{Name:name, Id:id, Location:location}" -o table
Creación de un clúster mediante la identidad de kubelet

Ahora puede usar el siguiente comando para crear el clúster con sus identidades existentes. Proporcione el
identificador de la identidad del plano de control a través de assign-identity y la identidad administrada de
kubelet a través de assign-kublet-identity :
az aks create \
--name myManagedCluster \
--service-cidr 10.2.0.0/24 \
--enable-managed-identity \
--assign-identity <identity-id> \
--assign-kubelet-identity <kubelet-identity-id> \
Una creación correcta del clúster mediante su propia identidad administrada de kubelet contiene la siguiente
salida:
"identity": {
"principalId": null,
"tenantId": null,
"type": "UserAssigned",
"userAssignedIdentities": {
"/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssig
nedIdentities/myIdentity": {
"principalId": "<principal-id>"
}
}
},
"identityProfile": {
"kubeletidentity": {
"objectId": "<object-id>",
"resourceId":
"/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/user
AssignedIdentities/myKubeletIdentity"
}
},
Pasos siguientes
Use las plantillas de Azure Resource Manager para crear clústeres habilitados para Managed Identity.
Uso de identidades administradas del pod de Azure
Active Directory en Azure Kubernetes Service
Las identidades administradas del pod de Azure Active Directory usan primitivas de Kubernetes para asociar
identidades administradas para recursos de Azure e identidades en Azure Active Directory (AAD) con pods. Los
administradores crean identidades y enlaces como primitivas de Kubernetes que permiten a los pods acceder a
los recursos de Azure que dependen de AAD como proveedor de identidades.
NOTE
Si tiene una instalación existente de AADPODIDENTITY, debe quitar la instalación existente. La habilitación de esta
característica significa que el componente MIC no es necesario.
IMPORTANT
Antes de empezar
Debe tener instalado el siguiente recurso:
CLI de Azure, versión 2.20.0 o posterior
Extensión azure-preview , versión 0.5.5 o posterior
Limitaciones
Se permite un máximo de 200 identidades de pod para un clúster.
Se permite un máximo de 200 excepciones de identidades de pod para un clúster.
Las identidades administradas del pod solo están disponibles en grupos de nodos de Linux.
Registro de EnablePodIdentityPreview
Registre la característica EnablePodIdentityPreview :
az feature register --name EnablePodIdentityPreview --namespace Microsoft.ContainerService
Instalación de la CLI de Azure aks-preview
También se necesita la versión 0.4.64 o posterior de la extensión de la CLI de Azure aks-preview . Instale la

Creación de un clúster de AKS con Azure CNI

NOTE
Esta es la configuración recomendada predeterminada.
Cree un clúster de AKS con Azure CNI y una identidad administrada del pod habilitada. Los siguientes comandos
usan az group create para crear un grupo de recursos denominado myResourceGroup y el comando az aks
create para crear un clúster de AKS denominado myAKSCluster en el grupo de recursos myResourceGroup.

az aks create -g myResourceGroup -n myAKSCluster --enable-pod-identity --network-plugin azure
Use az aks get-credentials para iniciar sesión en el clúster de AKS. Este comando también descarga y configura
el certificado de cliente kubectl en el equipo de desarrollo.
Actualización de un clúster de AKS existente con Azure CNI

Actualice un clúster de AKS existente con Azure CNI para incluir la identidad administrada del pod.
az aks update -g $MY_RESOURCE_GROUP -n $MY_CLUSTER --enable-pod-identity --network-plugin azure
Uso del complemento de red Kubenet con identidades administradas

del pod de Azure Active Directory
IMPORTANT
La ejecución de aad-pod-identity en un clúster con Kubenet no es una configuración recomendada debido a la implicación
que conlleva en materia de seguridad. Siga los pasos de mitigación y configure las directivas antes de habilitar aad-pod-
identity en un clúster con Kubenet.
Mitigación
Para mitigar la vulnerabilidad en el nivel de clúster, puede usar el controlador de admisión de OpenPolicyAgent
junto con el webhook de validación de Gatekeeper. Si ya tiene instalado Gatekeeper en el clúster, agregue un
elemento ConstraintTemplate del tipo K8sPSPCapabilities:
kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper-library/master/library/pod-
security-policy/capabilities/template.yaml
Agregue una plantilla para limitar la generación de pods con la funcionalidad NET_RAW:
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPCapabilities
metadata:
name: prevent-net-raw
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
excludedNamespaces:
- "kube-system"
parameters:
requiredDropCapabilities: ["NET_RAW"]
Creación de un clúster de AKS con el complemento de red Kubenet

Cree un clúster de AKS con complemento de red Kubenet y una identidad administrada del pod habilitada.
az aks create -g $MY_RESOURCE_GROUP -n $MY_CLUSTER --enable-pod-identity --enable-pod-identity-with-kubenet
Actualización de un clúster de AKS existente con el complemento de

red Kubenet
Actualice un clúster de AKS existente con el complemento de red Kubnet para incluir la identidad administrada
del pod.
az aks update -g $MY_RESOURCE_GROUP -n $MY_CLUSTER --enable-pod-identity --enable-pod-identity-with-kubenet
Creación de una identidad

Cree una identidad mediante az identity create y establezca las variables IDENTITY_CLIENT_ID e
IDENTITY_RESOURCE_ID.
az group create --name myIdentityResourceGroup --location eastus

export IDENTITY_RESOURCE_GROUP="myIdentityResourceGroup"
export IDENTITY_NAME="application-identity"
az identity create --resource-group ${IDENTITY_RESOURCE_GROUP} --name ${IDENTITY_NAME}
export IDENTITY_CLIENT_ID="$(az identity show -g ${IDENTITY_RESOURCE_GROUP} -n ${IDENTITY_NAME} --query
clientId -otsv)"
export IDENTITY_RESOURCE_ID="$(az identity show -g ${IDENTITY_RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id
-otsv)"
Asignación de permisos a la identidad administrada

La identidad administrada IDENTITY_CLIENT_ID debe tener permisos de lectura en el grupo de recursos que
contiene el conjunto de escalado de máquinas virtuales del clúster de AKS.
NODE_GROUP=$(az aks show -g myResourceGroup -n myAKSCluster --query nodeResourceGroup -o tsv)
NODES_RESOURCE_ID=$(az group show -n $NODE_GROUP -o tsv --query "id")
az role assignment create --role "Reader" --assignee "$IDENTITY_CLIENT_ID" --scope $NODES_RESOURCE_ID
Creación de una identidad de pod

Cree una identidad de pod para el clúster mediante az aks pod-identity add .
IMPORTANT
Debe tener los permisos adecuados, como Owner , en su suscripción para crear la identidad y el enlace de rol.
export POD_IDENTITY_NAME="my-pod-identity"
export POD_IDENTITY_NAMESPACE="my-app"
az aks pod-identity add --resource-group myResourceGroup --cluster-name myAKSCluster --namespace
${POD_IDENTITY_NAMESPACE} --name ${POD_IDENTITY_NAME} --identity-resource-id ${IDENTITY_RESOURCE_ID}
NOTE
Al habilitar la identidad administrada del pod en el clúster de AKS, se agrega una excepción AzurePodIdentityException
denominada aks-addon-exception al espacio de nombres kube-system. Una excepción AzurePodIdentityException permite
que los pods con determinadas etiquetas tengan acceso al punto de conexión de Azure Instance Metadata Service (IMDS)
sin que el servidor de identidad administrada del nodo (NMI) lo intercepte. aks-addon-exception permite que los
complementos propios de AKS, como la identidad administrada del pod de AAD, funcionen sin tener que configurar
manualmente una excepción AzurePodIdentityException. También puede agregar, quitar y actualizar una excepción
AzurePodIdentityException con az aks pod-identity exception add , az aks pod-identity exception delete ,
az aks pod-identity exception update o kubectl .
Ejecución de una aplicación de ejemplo

Para que un pod use la identidad administrada del pod de AAD, el pod necesita una etiqueta aadpodidbinding
con un valor que coincida con un selector de AzureIdentityBinding. Para ejecutar una aplicación de ejemplo
mediante la identidad administrada del pod de AAD, cree un archivo de demo.yaml con el siguiente contenido.
Reemplace POD_IDENTITY_NAME, IDENTITY_CLIENT_ID e IDENTITY_RESOURCE_GROUP por los valores de los
pasos anteriores. Reemplace SUBSCRIPTION_ID por su identificador de suscripción.
NOTE
En los pasos anteriores, creó las variables POD_IDENTITY_NAME, IDENTITY_CLIENT_ID e IDENTITY_RESOURCE_GROUP.
Puede usar un comando como echo para mostrar el valor establecido para las variables; por ejemplo,
echo $IDENTITY_NAME .
apiVersion: v1
kind: Pod
metadata:
name: demo
labels:
aadpodidbinding: POD_IDENTITY_NAME
spec:
containers:
- name: demo
image: mcr.microsoft.com/oss/azure/aad-pod-identity/demo:v1.6.3
args:
- --subscriptionid=SUBSCRIPTION_ID
- --clientid=IDENTITY_CLIENT_ID
- --resourcegroup=IDENTITY_RESOURCE_GROUP
env:
- name: MY_POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: MY_POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: MY_POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
nodeSelector:
kubernetes.io/os: linux
Observe que la definición del pod tiene una etiqueta aadpodidbinding con un valor que coincide con el nombre
de la identidad de pod que ejecutó az aks pod-identity add en el paso anterior.
Implemente demo.yaml en el mismo espacio de nombres que la identidad de pod mediante kubectl apply :
kubectl apply -f demo.yaml --namespace $POD_IDENTITY_NAMESPACE
Compruebe que la aplicación de ejemplo se ejecuta correctamente con kubectl logs .
kubectl logs demo --follow --namespace $POD_IDENTITY_NAMESPACE
Compruebe que los registros muestran que un token se ha obtenido correctamente y que la operación GET es
correcta.
...
successfully doARMOperations vm count 0
successfully acquired a token using the MSI,
msiEndpoint(http://169.254.169.254/metadata/identity/oauth2/token)
successfully acquired a token, userAssignedID MSI,
msiEndpoint(http://169.254.169.254/metadata/identity/oauth2/token) clientID(xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx)
successfully made GET on instance metadata
...
Limpieza
Para quitar la identidad administrada del pod de AAD del clúster, quite la aplicación de ejemplo y la identidad de
pod del clúster. A continuación, quite la identidad.
kubectl delete pod demo --namespace $POD_IDENTITY_NAMESPACE
az aks pod-identity delete --name ${POD_IDENTITY_NAME} --namespace ${POD_IDENTITY_NAMESPACE} --resource-
group myResourceGroup --cluster-name myAKSCluster
az identity delete -g ${IDENTITY_RESOURCE_GROUP} -n ${IDENTITY_NAME}
Pasos siguientes
Para más información sobre las identidades administradas, consulte Identidades administradas para recursos de
Azure.
Uso del control de acceso basados en rol de Azure
para definir el acceso al archivo de configuración de
Kubernetes en Azure Kubernetes Service (AKS)
Puede interactuar con los clústeres de Kubernetes mediante la herramienta kubectl . La CLI de Azure
proporciona una manera fácil de obtener las credenciales de acceso y la información de configuración para
conectarse a los clústeres de AKS mediante kubectl . Para limitar quién puede obtener esa información de
configuración de Kubernetes (kubeconfig) y los correspondientes permisos, puede usar el control de acceso
basado en rol de Azure (RBAC de Azure).
En este artículo se muestra cómo asignar roles de Azure que limiten quién puede obtener la información de
configuración para un clúster de AKS.
Antes de empezar
Azure.
Permisos de los roles de clúster disponibles

Al interactuar con un clúster de AKS mediante la herramienta kubectl , se usa un archivo de configuración que
define la información de conexión del clúster. Este archivo de configuración se almacena normalmente en
~/.kube/config. En este archivo kubeconfig se pueden definir varios clústeres. El comando kubectl config use-
context sirve para cambiar de un clúster a otro.
El comando az aks get-credentials permite obtener las credenciales de acceso para un clúster de AKS y las
combina en el archivo kubeconfig. Puede usar el control de acceso basado en rol de Azure (RBAC de Azure) para
controlar el acceso a estas credenciales. Estos roles de Azure permiten definir quién puede recuperar el archivo
kubeconfig y los permisos correspondientes en el clúster.
Los dos roles integrados son:
Rol de administrador de clúster de Azure Kubernetes Ser vice
Permite el acceso a la llamada API
Microsoft.ContainerService/managedClusters/listClusterAdminCredential/action. Esta llamada API
enumera las credenciales de administrador de clúster.
Descarga el archivo kubeconfig para el rol clusterAdmin.
Rol de usuario de clúster de Azure Kubernetes Ser vice
Permite el acceso a la llamada API
Microsoft.ContainerService/managedClusters/listClusterUserCredential/action. Esta llamada API
enumera las credenciales de usuario de clúster.
Descarga kubeconfig para el rol clusterUser.
Estos roles de Azure pueden aplicarse a un grupo o usuario de Azure Active Directory (AD).
NOTE
En los clústeres que usan Azure AD, los usuarios con el rol clusterUser tienen un archivo kubeconfig vacío que solicita un
inicio de sesión. Tras iniciar sesión, los usuarios tendrán acceso en función de la configuración de usuarios o grupos de
Azure AD. Los usuarios con el rol clusterAdmin tienen acceso de administrador.
Los clústeres que no usan Azure AD solo utilizan el rol clusterAdmin.
Asignación de permisos de rol a un usuario o un grupo

Para asignar uno de los roles disponibles, debe obtener el identificador de recurso del clúster de AKS y el del
grupo o de la cuenta de usuario de Azure AD. Los siguientes comandos de ejemplo:
Obtienen el identificador de recurso del clúster mediante el comando az aks show para el clúster
denominado myAKSCluster del grupo de recursos myResourceGroup. Proporcione los nombres de su propio
clúster y grupo de recursos según proceda.
Usan los comandos az account show y az ad user show para obtener el identificador de usuario.
Por último, asignan un rol mediante el comando az role assignment create.
En el ejemplo siguiente se asigna el rol de administrador de clústeres de Azure Kubernetes Service a una cuenta
de usuario individual:
# Get the resource ID of your AKS cluster

AKS_CLUSTER=$(az aks show --resource-group myResourceGroup --name myAKSCluster --query id -o tsv)
# Get the account credentials for the logged in user

ACCOUNT_UPN=$(az account show --query user.name -o tsv)
ACCOUNT_ID=$(az ad user show --id $ACCOUNT_UPN --query objectId -o tsv)
# Assign the 'Cluster Admin' role to the user

--assignee $ACCOUNT_ID \
--scope $AKS_CLUSTER \
--role "Azure Kubernetes Service Cluster Admin Role"
IMPORTANT
En algunos casos, el valor user.name de la cuenta es diferente del valor userPrincipalName, como sucede con los usuarios
invitados de Azure AD:
$ az account show --query user.name -o tsv

user@contoso.com
$ az ad user list --query "[?contains(otherMails,'user@contoso.com')].{UPN:userPrincipalName}" -o tsv
user_contoso.com#EXT#@contoso.onmicrosoft.com
En este caso, establezca el valor de ACCOUNT_UPN en el valor userPrincipalName del usuario de Azure AD. Por ejemplo, si
el valor user.name de la cuenta es user@contoso.com:
ACCOUNT_UPN=$(az ad user list --query "[?contains(otherMails,'user@contoso.com')].

{UPN:userPrincipalName}" -o tsv)
TIP
Si desea asignar permisos a un grupo de Azure AD, actualice el parámetro --assignee que se muestra en el ejemplo
anterior con el identificador de objeto para el grupo en lugar de un usuario. Para obtener el identificador de objeto para
un grupo, use el comando az ad group show. En el ejemplo siguiente se obtiene el identificador de objeto para el grupo
de Azure AD denominado appdev: az ad group show --group appdev --query objectId -o tsv
Puede cambiar la asignación anterior al rol Cluster User cuando proceda.

La siguiente salida de ejemplo muestra que la asignación de roles se realizó correctamente:
{
"canDelegate": null,
"id":
"/subscriptions/<guid>/resourcegroups/myResourceGroup/providers/Microsoft.ContainerService/managedClusters/m
yAKSCluster/providers/Microsoft.Authorization/roleAssignments/b2712174-5a41-4ecb-82c5-12b8ad43d4fb",
"name": "b2712174-5a41-4ecb-82c5-12b8ad43d4fb",
"principalId": "946016dd-9362-4183-b17d-4c416d1f8f61",
"roleDefinitionId": "/subscriptions/<guid>/providers/Microsoft.Authorization/roleDefinitions/0ab01a8-8aac-
4efd-b8c2-3ee1fb270be8",
"scope":
"/subscriptions/<guid>/resourcegroups/myResourceGroup/providers/Microsoft.ContainerService/managedClusters/m
yAKSCluster",
"type": "Microsoft.Authorization/roleAssignments"
}
Obtención y verificación de la información de configuración

Con los roles de Azure asignados, use el comando az aks get-credentials para obtener la definición de
kubeconfig para el clúster de AKS. En el ejemplo siguiente se obtienen las credenciales --admin, que funcionan
correctamente si se ha concedido al usuario el rol Cluster Admin:
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin
A continuación, puede usar el comando kubectl config view para comprobar que el contexto del clúster muestra
que se ha aplicado la información de configuración del administrador:
$ kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://myaksclust-myresourcegroup-19da35-4839be06.hcp.eastus.azmk8s.io:443
name: myAKSCluster
contexts:
- context:
cluster: myAKSCluster
user: clusterAdmin_myResourceGroup_myAKSCluster
name: myAKSCluster-admin
current-context: myAKSCluster-admin
kind: Config
preferences: {}
users:
- name: clusterAdmin_myResourceGroup_myAKSCluster
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
token: e9f2f819a4496538b02cefff94e61d35
Eliminación de permisos de rol

Para eliminar asignaciones de rol, use el comando az role assignment delete. Especifique el identificador de la
cuenta y del recurso de clúster, como los obtuvo con los comandos anteriores. Si ha asignado el rol a un grupo
en lugar de a un usuario, especifique el identificador del objeto de grupo adecuado en lugar del objeto de
cuenta para el parámetro --assignee :
az role assignment delete --assignee $ACCOUNT_ID --scope $AKS_CLUSTER
Pasos siguientes
Para mejorar la seguridad en el acceso a los clústeres de AKS, integre la autenticación de Azure Active Directory.
Protección del tráfico entre pods mediante
directivas de red en Azure Kubernetes Service (AKS)
Al ejecutar aplicaciones modernas basadas en microservicios en Kubernetes, con frecuenta querrá controlar qué
componentes pueden comunicarse entre sí. El principio de privilegios mínimos debe aplicarse a la manera en
que el tráfico puede fluir entre pods de un clúster de Azure Kubernetes Service (AKS). Supongamos que quiere
bloquear el tráfico directamente a las aplicaciones de back-end. La característica Directiva de red de Kubernetes
permite definir las reglas de tráfico de entrada y salida entre pods de un clúster.
En este artículo se muestra cómo instalar el motor de directiva de red y cómo crear directivas de red de
Kubernetes para controlar el flujo de tráfico entre pods en AKS. La directiva de red solo se debe usar para los
pods y los nodos basados en Linux de AKS.
Antes de empezar
Es preciso que esté instalada y configurada la versión 2.0.61 de la CLI de Azure u otra versión posterior. Ejecute
TIP
Si usó la característica de directiva de red en la versión preliminar, se recomienda que cree un clúster.
Si quiere seguir usando los clústeres de prueba existentes que usaban la directiva de red en la versión preliminar, actualice
el clúster a una nueva versión de Kubernetes para la versión de disponibilidad general más reciente y, luego, implemente
el siguiente manifiesto de YAML para corregir el bloqueo del servidor de métricas y del panel de Kubernetes. Esta
corrección solo es necesaria para los clústeres que usaban el motor de directiva de red de Calico.
Como procedimiento recomendado de seguridad, revise el contenido de este manifiesto de YAML para entender qué se
implementa en el clúster de AKS.
kubectl delete -f https://raw.githubusercontent.com/Azure/aks-engine/master/docs/topics/calico-3.3.1-
cleanup-after-upgrade.yaml
Información general sobre la directiva de red

De forma predeterminada, todos los pods de un clúster de AKS pueden enviar y recibir tráfico sin limitaciones.
Para mejorar la seguridad, puede definir reglas que controlen el flujo de tráfico. A menudo, las aplicaciones de
back-end solo se exponen a los servicios front-end necesarios, por ejemplo. Además, los componentes de base
de datos solo son accesibles para las capas de aplicación que se conectan a ellos.
La directiva de red es una especificación de Kubernetes que define las directivas de acceso para la comunicación
entre pods. Con las directivas de red, puede definir un conjunto ordenado de reglas para enviar y recibir tráfico
y aplicarlas a una colección de pods que coincidan con uno o varios selectores de etiqueta.
Estas reglas de las directivas de red se definen como manifiestos de YAML. Las directivas de red se pueden
incluir como parte de un manifiesto más amplio que también crea una implementación o un servicio.
Opciones de directivas de red en AKS
Azure ofrece dos maneras de implementar la directiva de red. Debe elegir una opción de directiva de red al crear
un clúster de AKS. La opción de directiva no se puede cambiar una vez que se ha creado el clúster:
La implementación propia de Azure, denominada directivas de red de Azure.
Directivas de red de Calico, una solución de seguridad de red y redes de código abierto fundada por Tigera.
Ambas implementaciones usan IPTables de Linux para aplicar las directivas especificadas. Las directivas se
traducen en conjuntos de pares de IP permitidas y no permitidas. Después, estos pares se programan como
reglas de filtro de IPTable.
Diferencias entre las directivas de Azure y Calico y sus funcionalidades
C A PA C IDA D A Z URE C A L IC O
Plataformas compatibles Linux Linux, Windows Server 2019 (versión

preliminar)
Opciones de redes admitidas CNI de Azure Azure CNI (Windows Server 2019 y
Linux) y kubenet (Linux)
Compatibilidad con la especificación de Se admiten todos los tipos de directiva. Se admiten todos los tipos de directiva.
Kubernetes
Características adicionales None Modelo de directiva extendida que

consta de una directiva de red global,
un conjunto de red global y un punto
de conexión de host. Para más
información sobre el uso de la CLI de
calicoctl para administrar estas
características extendidas, consulte la
referencia de usuario de calicoctl.
Soporte técnico Compatible con el soporte técnico de Soporte técnico de la comunidad de

Azure y el equipo de ingeniería Calico. Para más información sobre el
soporte técnico de pago adicional,
consulte las opciones de soporte
técnico del proyecto Calico.
Registro Las reglas agregadas o eliminadas en Para más información, consulte los
IPTables se registran en cada host en registros de los componentes de
/var/log/azure-npm.log Calico.
Creación de un clúster de AKS y habilitación de la directiva de red

Para ver las directivas de red en acción, vamos a crear y luego expandir una directiva que define el flujo de
tráfico:
Deniegue todo el tráfico al pod.
Permita el tráfico en función de las etiquetas de pod.
Permita el tráfico según el espacio de nombres.
En primer lugar, crearemos un clúster de AKS que admite la directiva de red.
IMPORTANT
La característica de directiva de red solo se puede habilitar cuando se crea el clúster. No se puede habilitar la directiva de
red en un clúster de AKS existente.
Para usar la directiva de red de Azure, debe usar el complemento CNI de Azure y definir su propia red virtual y
subredes. Para más información sobre cómo planear los rangos de subred requeridos, consulte la sección sobre
cómo configurar redes avanzadas. La directiva de red de Calico se puede usar con este mismo complemento
CNI de Azure o con el complemento CNI de Kubenet.
En el ejemplo siguiente se invoca el script:
Crea una red virtual y una subred.
Crea una entidad de servicio de Azure Active Directory (Azure AD) para usarse con el clúster de AKS.
Asigna permisos de colaborador para la entidad de servicio de clúster de AKS en la red virtual.
Crea un clúster de AKS en la red virtual definida y habilita la directiva de red.
Se usa la opción de directiva de Red de Azure. Para usar Calico como opción de directiva de red, use el
parámetro --network-policy calico . Nota: Calico se puede usar con --network-plugin azure o
--network-plugin kubenet .
Recuerde que en lugar de una entidad de servicio, puede usar una identidad administrada para los permisos.
Para más información, consulte Uso de identidades administradas.
Proporcione su propia variable segura SP_PASSWORD. Puede reemplazar las variables
RESOURCE_GROUP_NAME y CLUSTER_NAME:
RESOURCE_GROUP_NAME=myResourceGroup-NP
CLUSTER_NAME=myAKSCluster
LOCATION=canadaeast

az group create --name $RESOURCE_GROUP_NAME --location $LOCATION
# Create a virtual network and subnet

--resource-group $RESOURCE_GROUP_NAME \
--name myVnet \
# Create a service principal and read in the application ID

SP=$(az ad sp create-for-rbac --output json)
SP_ID=$(echo $SP | jq -r .appId)
SP_PASSWORD=$(echo $SP | jq -r .password)
# Wait 15 seconds to make sure that service principal has propagated

echo "Waiting for service principal to propagate..."
sleep 15
# Get the virtual network resource ID

VNET_ID=$(az network vnet show --resource-group $RESOURCE_GROUP_NAME --name myVnet --query id -o tsv)
# Assign the service principal Contributor permissions to the virtual network resource
az role assignment create --assignee $SP_ID --scope $VNET_ID --role Contributor
# Get the virtual network subnet resource ID

SUBNET_ID=$(az network vnet subnet show --resource-group $RESOURCE_GROUP_NAME --vnet-name myVnet --name
myAKSSubnet --query id -o tsv)
Creación de un clúster de AKS para las directivas de red de Azure

Cree el clúster de AKS y especifique la red virtual, la información de la entidad de servicio y azure como
complemento de red y directiva de red.
az aks create \
--name $CLUSTER_NAME \
--node-count 1 \
--service-cidr 10.0.0.0/16 \
--service-principal $SP_ID \
--client-secret $SP_PASSWORD \
--network-policy azure
La operación de creación del clúster tarda unos minutos. Cuando el clúster esté listo, configure kubectl para
conectarse a su clúster de Kubernetes con 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 --name $CLUSTER_NAME
Creación de un clúster de AKS para las directivas de red de Calico

Cree el clúster de AKS y especifique la red virtual, la información de la entidad de servicio y azure como
complemento de red y calico como directiva de red. Al usar calico como directiva de red, se habilitan las redes
de Calico en los grupos de nodos de Windows y Linux.
Si planea agregar grupos de nodos de Windows al clúster, incluya los parámetros windows-admin-username y
windows-admin-password , para que se cumplan los requisitos de contraseña de Windows Server. Para usar Calico
con grupos de nodos de Windows, también debe registrar Microsoft.ContainerService/EnableAKSWindowsCalico .
Registro de EnableAKSWindowsCalico la marca de característica con el comando de característica de registro az,
tal como se muestra en el siguiente ejemplo:
az feature register --namespace "Microsoft.ContainerService" --name "EnableAKSWindowsCalico"
Puede comprobar el estado de registro con el comando az feature list:
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/EnableAKSWindowsCalico')].

IMPORTANT
En estos momentos, el uso de directivas de red de Calico con nodos de Windows está disponible en los clústeres nuevos
que usan la versión 1.20 o posterior de Kubernetes con Calico 3.17.2 y requiere el uso de redes de Azure CNI. Los nodos
de Windows en los clústeres de AKS con Calico habilitado también tienen habilitado Direct Server Return (DSR) de manera
predeterminada.
En el caso de los clústeres que solo tienen grupos de nodos de Linux que ejecutan Kubernetes 1.20 con versiones
anteriores de Calico, la versión de Calico se actualizará automáticamente a la versión 3.17.2.
Las directivas de red de Calico con nodos de Windows se encuentran actualmente en versión preliminar.
IMPORTANT
Cree un nombre de usuario para usarlo como credenciales de administrador para los contenedores de
Windows Server en el clúster. Los comandos siguientes le solicitan un nombre de usuario y lo establecen en
WINDOWS_USERNAME para su uso en un comando posterior (recuerde que los comandos de este artículo se
incluyen en un shell de BASH).
echo "Please enter the username to use as administrator credentials for Windows Server containers on your
cluster: " && read WINDOWS_USERNAME
az aks create \
--node-count 1 \
--service-cidr 10.0.0.0/16 \
--client-secret $SP_PASSWORD \
--windows-admin-username $WINDOWS_USERNAME \
--kubernetes-version 1.20.2 \
--network-policy calico
La operación de creación del clúster tarda unos minutos. De manera predeterminada, el clúster se crea solo con
un grupo de nodos de Linux. Si desea usar grupos de nodos de Windows, puede agregarlos. Por ejemplo:

--cluster-name $CLUSTER_NAME \
--os-type Windows \
--name npwin \
--node-count 1
Cuando el clúster esté listo, configure kubectl para conectarse a su clúster de Kubernetes con 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 --name $CLUSTER_NAME

Denegación de todo el tráfico entrante a un pod
Antes de definir reglas para permitir el tráfico de red específico, primero cree una directiva de red para denegar
todo el tráfico. Esta directiva proporciona un punto inicial para empezar a crear una lista de permitidos solo para
el tráfico deseado. También puede ver claramente que el tráfico se descarta cuando se aplica la directiva de red.
En lo que respecta al entorno de aplicación de ejemplo y a las reglas de tráfico, vamos a crear un espacio de
nombres denominado development para ejecutar los pods de ejemplo:
kubectl create namespace development

kubectl label namespace/development purpose=development
Cree un pod de back-end de ejemplo que ejecute NGINX. Este pod de back-end puede usarse para simular una
aplicación web de back-end de ejemplo. Cree este pod en el espacio de nombres development y abra el puerto
80 para atender el tráfico web. Etiquete el pod con app=webapp,role=backend para que podamos utilizarlo
como destino con una directiva de red en la sección siguiente:
kubectl run backend --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --labels app=webapp,role=backend

--namespace development --expose --port 80
Cree otro pod y asocie una sesión de terminal para probar que puede llegar correctamente a la página web de
NGINX predeterminada:
kubectl run --rm -it --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 network-policy --

namespace development
Cuando se encuentre en el símbolo del sistema del shell, use wget para confirmar que puede acceder a la
página web de NGINX predeterminada:
wget -qO- http://backend
La siguiente salida de ejemplo muestra que se devuelve la página web de NGINX predeterminada:
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]
Salga de la sesión de terminal asociada. El pod de prueba se elimina automáticamente.
exit
Creación y aplicación de una directiva de red

Ahora que ha confirmado que usar la página web de NGINX básica en el pod de back-end de ejemplo, cree una
directiva de red para denegar todo el tráfico. Cree un archivo denominado backend-policy.yaml y pegue el
siguiente manifiesto de YAML. Este manifiesto usa un elemento podSelector para asociar la directiva a los pods
que tienen la etiqueta app:webapp,role:backend, como el pod de NGINX de ejemplo. No hay reglas definidas en
ingress, por lo que se deniega todo el tráfico entrante en el pod:
kind: NetworkPolicy
metadata:
namespace: development
spec:
podSelector:
matchLabels:
app: webapp
role: backend
ingress: []
Vaya a https://shell.azure.com para abrir Azure Cloud Shell en el explorador.

Aplique la directiva de red mediante el comando kubectl apply y especifique el nombre del manifiesto de YAML:
kubectl apply -f backend-policy.yaml
Prueba de la directiva de red

Comprobemos que puede usar la página web de NGINX en el pod de back-end de nuevo. Cree otro pod de
prueba y asocie una sesión de terminal:

Cuando se encuentre en el símbolo del sistema del shell, use wget para ver si puede acceder a la página web de
NGINX predeterminada. Esta vez, establezca un valor de tiempo de expiración de 2 segundos. Ahora, la directiva
de red bloquea todo el tráfico entrante, por lo que no se puede cargar la página, tal como se muestra en el
ejemplo siguiente:
wget -qO- --timeout=2 http://backend
wget: download timed out
exit
Tráfico entrante permitido en función de una etiqueta de pod

En la sección anterior, se programó un pod de NGINX de back-end y se creó una directiva de red para denegar
todo el tráfico. Vamos a crear un pod de front-end y actualizar la directiva de red para permitir el tráfico desde
los pods de front-end.
Actualice la directiva de red para permitir el tráfico desde los pods con las etiquetas app:webapp,role:frontend y
en cualquier espacio de nombres. Edite el anterior archivo backend-policy.yaml y agregue unas reglas de
entrada matchLabels para que el manifiesto sea similar al ejemplo siguiente:
kind: NetworkPolicy
metadata:
spec:
podSelector:
matchLabels:
app: webapp
role: backend
ingress:
- from:
- namespaceSelector: {}
podSelector:
matchLabels:
app: webapp
role: frontend
NOTE
Esta directiva de red usa un elemento namespaceSelector y un elemento podSelector para la regla de entrada. La sintaxis
YAML es importante para que las reglas de entrada sean aditivas. En este ejemplo, ambos elementos deben coincidir para
que se aplique la regla de entrada. Puede que las versiones de Kubernetes anteriores a 1.12 no interpreten correctamente
estos elementos y no restrinjan el tráfico de red según lo esperado. Para más información sobre este comportamiento,
consulte Behavior of to and from selectors (Comportamiento de los selectores to y from).
Aplique la política de red actualizada mediante el comando kubectl apply y especifique el nombre del manifiesto
de YAML:
Programe un pod que se etiquete como app=webapp,role=frontend y asocie una sesión de terminal:
kubectl run --rm -it frontend --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 --labels

app=webapp,role=frontend --namespace development
NGINX predeterminada:
Como la regla de entrada permite el tráfico con los pods que tengan las etiquetas app: webapp,role: frontend, se
permite el tráfico desde el pod de front-end. La siguiente salida de ejemplo muestra que se devuelve la página
web de NGINX predeterminada:
<!DOCTYPE html>
<html>
<head>
[...]
Salga de la sesión de terminal asociada. El pod se elimina automáticamente.

exit
Prueba de un pod sin una etiqueta coincidente

La directiva de red permite el tráfico desde los pods con la etiqueta app: webapp,role: frontend, pero debe
denegar todo el tráfico. Vamos a realizar una prueba para ver si otro pod sin esas etiquetas puede acceder al
pod de NGINX de back-end. Cree otro pod de prueba y asocie una sesión de terminal:

NGINX predeterminada. La directiva de red bloquea el tráfico entrante, por lo que no se puede cargar la página,
tal como se muestra en el ejemplo siguiente:
wget -qO- --timeout=2 http://backend
exit
Tráfico permitido solo desde dentro de un espacio de nombres

definido
En los ejemplos anteriores, creó una directiva de red que denegaba todo el tráfico y, después, actualizó la
directiva para permitir el tráfico desde los pods con una etiqueta específica. Otra de las cosas que se suele
necesitar es limitar el tráfico a solo dentro de un espacio de nombres especificado. Si los ejemplos anteriores
eran para el tráfico en un espacio de nombres development, cree una directiva de red que impida que el tráfico
de otro espacio de nombres, como production, llegue a los pods.
En primer lugar, cree un espacio de nombres para simular un espacio de nombres production:
kubectl create namespace production

kubectl label namespace/production purpose=production
Programe un pod de prueba en el espacio de nombres production que está etiquetado como
app=webapp,role=frontend. Asocie una sesión de terminal:

app=webapp,role=frontend --namespace production
Cuando se encuentre en el símbolo del sistema del shell, use wget para confirmar que puede acceder a la
página web de NGINX predeterminada:
wget -qO- http://backend.development
Como las etiquetas del pod coinciden con lo que actualmente está permitido en la directiva de red, se permite el
tráfico. La directiva de red no analiza los espacios de nombres, solo las etiquetas de pod. La siguiente salida de
ejemplo muestra que se devuelve la página web de NGINX predeterminada:
<!DOCTYPE html>
<html>
<head>
[...]
exit
Actualización de la directiva de red

Vamos a actualizar la sección namespaceSelector de la regla de entrada para permitir únicamente el tráfico
desde el espacio de nombres development. Edite el archivo de manifiesto backend-policy.yaml, como se
muestra en el ejemplo siguiente:
kind: NetworkPolicy
metadata:
spec:
podSelector:
matchLabels:
app: webapp
role: backend
ingress:
- from:
- namespaceSelector:
matchLabels:
purpose: development
podSelector:
matchLabels:
app: webapp
role: frontend
En ejemplos más complejos, podría definir varias reglas de entrada, como un elemento namespaceSelector y,
después, un elemento podSelector.
Aplique la política de red actualizada mediante el comando kubectl apply y especifique el nombre del manifiesto
de YAML:
Prueba de la directiva de red actualizada

Programe otro pod en el espacio de nombres production y asocie una sesión de terminal:

app=webapp,role=frontend --namespace production
Una vez en el símbolo del sistema del shell, use wget para ver que ahora la directiva de red deniega el tráfico:
wget -qO- --timeout=2 http://backend.development
Salga del pod de prueba:
exit
Con el tráfico denegado desde el espacio de nombres production, programe de nuevo un pod de prueba en el
espacio de nombres development y asocie una sesión de terminal:

app=webapp,role=frontend --namespace development
Una vez en el símbolo del sistema del shell, use wget para ver que la directiva de red permite el tráfico:
El tráfico se permite porque el pod está programado en el espacio de nombres que coincide con lo permitido en
la directiva de red. En la siguiente salida de ejemplo se muestra que se devuelve la página web de NGINX
predeterminada:
<!DOCTYPE html>
<html>
<head>
[...]
exit
En este artículo, hemos creado dos espacios de nombres y hemos aplicado una directiva de red. Para limpiar
estos recursos, use el comando kubectl delete y especifique los nombres de recurso:
kubectl delete namespace production

kubectl delete namespace development
Pasos siguientes
Para más información sobre los recursos red, consulte Conceptos de redes de aplicaciones en Azure Kubernetes
Service (AKS).
Para más información sobre las directivas, consulte las directivas de red de Kubernetes.
Protección del clúster con Azure Policy
Para mejorar la seguridad del clúster de Azure Kubernetes Service (AKS), puede aplicar directivas de seguridad
integradas en el clúster mediante Azure Policy. Azure Policy ayuda a aplicar los estándares de la organización y a
evaluar el cumplimiento a gran escala. Después de instalar el complemento de Azure Policy para AKS, puede
aplicar definiciones de directiva individuales o grupos de definiciones de directiva denominados iniciativas (a
veces conocidos como conjuntos de directivas) al clúster. Para ver una lista completa de definiciones de directiva
e iniciativa de AKS, consulte Definiciones integradas de Azure Policy para Azure Kubernetes Service.
En este artículo se muestra cómo aplicar definiciones de directiva al clúster y comprobar que se aplican esas
asignaciones.
Requisitos previos
Un clúster de AKS existente Si necesita un clúster de AKS, consulte el inicio rápido de AKS mediante la CLI de
Azure o mediante Azure Portal.
El complemento de Azure Policy para AKS instalado en un clúster de AKS. Siga estos pasos para instalar el
complemento de Azure Policy.
Asignación de una definición o iniciativa de directiva integrada

Para aplicar una definición o iniciativa de directiva, use Azure Portal.
1. En Azure Portal, vaya al servicio Azure Policy.
2. En el panel izquierdo de la página de Azure Policy, seleccione Definitions (Definiciones).
3. En Categorías , seleccione Kubernetes .
4. Elija la definición o iniciativa de directiva que quiera aplicar. En este ejemplo, seleccione la iniciativa
Kubernetes cluster pod security baseline standards for Linux-based workloads .
5. Seleccione Asignar .
6. Establezca el valor de Ámbito en el grupo de recursos del clúster de AKS con el complemento de Azure
Policy habilitado.
7. Seleccione la página Parámetros y actualice Efecto de audit a deny para impedir que las nuevas
implementaciones infrinjan la iniciativa de línea de base. También puede agregar espacios de nombres
adicionales para excluirlos de la evaluación. En este ejemplo, conserve los valores predeterminados.
8. Seleccione Revisar y crear y, luego, Crear para enviar la asignación de directiva.
Validación de que se ejecuta Azure Policy

Confirme que las asignaciones de directiva se aplican al clúster; para ello, ejecute lo siguiente:
kubectl get constrainttemplates
NOTE
Las asignaciones de directivas pueden tardar hasta 20 minutos en sincronizarse con cada clúster.
La salida debe ser similar a:

$ kubectl get constrainttemplate
NAME AGE
k8sazureallowedcapabilities 23m
k8sazureallowedusersgroups 23m
k8sazureblockhostnamespace 23m
k8sazurecontainerallowedimages 23m
k8sazurecontainerallowedports 23m
k8sazurecontainerlimits 23m
k8sazurecontainernoprivilege 23m
k8sazurecontainernoprivilegeescalation 23m
k8sazureenforceapparmor 23m
k8sazurehostfilesystem 23m
k8sazurehostnetworkingports 23m
k8sazurereadonlyrootfilesystem 23m
k8sazureserviceallowedports 23m
Validación del rechazo de un pod con privilegios

Vamos a probar primero lo que sucede cuando se programa un pod con el contexto de seguridad
privileged: true . Este contexto de seguridad eleva los privilegios del pod. La iniciativa no permite pods con
privilegios, por lo que se denegará la solicitud, lo que provocará que se rechace la implementación.
Cree un archivo denominado nginx-privileged.yaml y pegue el siguiente manifiesto de YAML:
apiVersion: v1
kind: Pod
metadata:
name: nginx-privileged
spec:
containers:
- name: nginx-privileged
securityContext:
privileged: true
Cree el pod con el comando kubectl apply y especifique el nombre del manifiesto de YAML:
kubectl apply -f nginx-privileged.yaml
Como se esperaba, el pod no se puede incluir en la programación, como se muestra en la salida del ejemplo
siguiente:
$ kubectl apply -f privileged.yaml
Error from server ([denied by azurepolicy-container-no-privilege-

00edd87bf80f443fa51d10910255adbc4013d590bec3d290b4f48725d4dfbdf9] Privileged container is not allowed:
nginx-privileged, securityContext: {"privileged": true}): error when creating "privileged.yaml": admission
webhook "validation.gatekeeper.sh" denied the request: [denied by azurepolicy-container-no-privilege-
00edd87bf80f443fa51d10910255adbc4013d590bec3d290b4f48725d4dfbdf9] Privileged container is not allowed:
nginx-privileged, securityContext: {"privileged": true}
El pod no llega a la fase de programación, por lo que no hay recursos que eliminar para continuar.
Prueba de la creación de un pod sin privilegios
En el ejemplo anterior la imagen de contenedor intentó automáticamente utilizar la raíz para enlazar NGINX al
puerto 80. La iniciativa de directiva denegó esta solicitud, por lo que no se puede iniciar el pod. Vamos a probar
ahora a ejecutar ese mismo pod con NGINX sin acceso con privilegios.
Cree un archivo denominado nginx-unprivileged.yaml y pegue el siguiente manifiesto de YAML:
apiVersion: v1
kind: Pod
metadata:
name: nginx-unprivileged
spec:
containers:
- name: nginx-unprivileged
Cree el pod mediante el comando kubectl apply y especifique el nombre del manifiesto de YAML:
kubectl apply -f nginx-unprivileged.yaml
Se ha programado correctamente el pod. Al activar el estado del pod mediante el comando kubectl get pods, el
pod tiene el estado En ejecución:
$ kubectl get pods

nginx-unprivileged 1/1 Running 0 18s
En este ejemplo se muestra que la iniciativa de línea de base solo afecta a las implementaciones que infringen
las directivas de la colección. Las implementaciones permitidas continúan funcionando.
Elimine el pod NGIX sin privilegios mediante el comando kubectl delete y especifique el nombre del manifiesto
de YAML:
kubectl delete -f nginx-unprivileged.yaml
Deshabilitación de una directiva o iniciativa

Para eliminar la iniciativa de línea de base:
1. Vaya al panel Directiva en Azure Portal.
2. Seleccione Asignaciones en el panel izquierdo.
3. Haga clic en el botón ... situado junto a la iniciativa
Kubernetes cluster pod security baseline standards for Linux-based workloads .
4. Seleccione Eliminar asignación .
Pasos siguientes
Para más información sobre cómo funciona Azure Policy, consulte:
Introducción a Azure Policy
Iniciativas y directivas de Azure Policy para AKS
Quite el complemento de Azure Policy.
Versión preliminar: Protección del clúster con
directivas de seguridad de pod en Azure
WARNING
La característica descrita en este documento, directiva de seguridad de pods (versión preliminar),
comenzará a dejar de usar la versión 1.21 de Kubernetes, con su eliminación en la versión 1.25. A medida
que Kubernetes Upstream alcanza este hito, la comunidad de Kubernetes trabajará para documentar alternativas viables.
El anuncio de desuso anterior se hizo en el momento en que no había una opción viable para los clientes. Ahora que la
comunidad Kubernetes está trabajando en una alternativa, ya no es necesario deshacerse por adelantado de Kubernetes.
Una vez que la directiva de seguridad de pod (versión preliminar) haya quedado en desuso, deberá deshabilitar la
característica en todos los clústeres existentes que la incluyan para realizar futuras actualizaciones de clústeres y seguir
recibiendo el soporte técnico de Azure.
Para mejorar la seguridad del clúster de AKS, puede limitar los pods que se pueden programar. Los pods que
soliciten recursos que no permita no podrán ejecutarse en el clúster de AKS. Defina este acceso mediante
directivas de seguridad de pod. En este artículo se muestra cómo usar las directivas de seguridad de pod para
limitar la implementación de pods en AKS.
IMPORTANT
Antes de empezar

Para usar directivas de seguridad de pod, necesitará la versión 0.4.1 de la extensión de la CLI aks-preview o una
posterior. Instale la extensión de la CLI de Azure aks-preview con el comando az extension add y, a continuación,
busque las actualizaciones disponibles con el comando az extension update:
Registro del proveedor de características de la directiva de seguridad de pod

Este documento y esta característica quedarán en desuso el 15 de octubre de 2020.
Para crear o actualizar un clúster de AKS para que use directivas de seguridad de pod, habilite primero una
marca de características en su suscripción. Para registrar la marca de características PodSecurityPolicyPreview ,
use el comando az feature register tal como se muestra en el siguiente ejemplo:
az feature register --name PodSecurityPolicyPreview --namespace Microsoft.ContainerService
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/PodSecurityPolicyPreview')].

Introducción a las directivas de seguridad de pod

En los clústeres de Kubernetes se usa un controlador de admisión para interceptar las solicitudes al servidor de
API cuando se va a crear un recurso. El controlador de admisión puede validar la solicitud del recurso con un
conjunto de reglas, o mutar el recurso para cambiar los parámetros de implementación.
PodSecurityPolicy es un controlador de admisión que valida si una especificación de pod cumple los requisitos
definidos. Estos pueden incluir el límite del uso de contenedores con privilegios, del acceso a ciertos tipos de
almacenamiento, o del usuario o grupo que puede ejecutar el contenedor. Al intentar implementar un recurso
donde las especificaciones de pod no cumplan los requisitos descritos en la directiva de seguridad de pod, la
solicitud se deniega. Esta capacidad para controlar qué pods se pueden programar en el clúster de AKS evita
algunos puntos vulnerables de seguridad o elevaciones de privilegios.
Al habilitar la directiva de seguridad de pod en el clúster de AKS, se aplican algunas directivas predeterminadas.
Estas directivas predeterminadas proporcionan una experiencia de fábrica para definir qué pods que se puede
programar. Sin embargo, los usuarios del clúster pueden encontrarse con problemas al implementar los pods
hasta que defina sus propias directivas. El método recomendado es el siguiente:
Definición de directivas de seguridad de pod propias
Habilitación de la característica de directiva de seguridad de pod
Para mostrar cómo las directivas predeterminadas limitan la implementación de pods, en este artículo primero
se habilita la característica de las directivas de seguridad de pod y después se crea una directiva personalizada.
El comportamiento cambia entre la directiva de seguridad de pod y Azure Policy
A continuación se muestra un resumen de los cambios de comportamiento entre la directiva de seguridad de
pod y Azure Policy.
ESC EN A RIO DIREC T IVA DE SEGURIDA D DE P O D A Z URE P O L IC Y
Instalación Habilitar la característica de directiva Habilitar el complemento de Azure

de seguridad de pod Policy
Implementar directivas Implementar el recurso de la directiva Asigne las directivas de Azure al

de seguridad de pod ámbito de la suscripción o del grupo
de recursos. El complemento de Azure
Policy es necesario para las aplicaciones
de recursos de Kubernetes.
Directivas predeterminadas Cuando la directiva de seguridad de No se aplica ninguna directiva

pod está habilitada en AKS, se aplican predeterminada al habilitar el
las directivas predeterminadas Con complemento de Azure Policy. Debe
privilegios y Sin restricciones. habilitar explícitamente las directivas
en Azure Policy.
Quién puede crear y asignar directivas El administrador del clúster crea un Los usuarios deben tener un rol
recurso de directiva de seguridad de mínimo con permisos de "propietario"
pod o "colaborador de directiva de
recursos" en el grupo de recursos del
clúster de AKS. - Mediante la API, los
usuarios pueden asignar directivas en
el ámbito del recurso del clúster de
AKS. El usuario debe tener permisos
mínimos de "propietario" o
"colaborador de directiva de recursos"
en el recurso del clúster de AKS. - En
Azure Portal, las directivas se pueden
asignar en el nivel de grupo de
administración, suscripción o grupo de
recursos.
Autorizar directivas Los usuarios y las cuentas de servicio No se requiere ninguna asignación
requieren permisos explícitos para usar adicional para autorizar directivas. Una
las directivas de seguridad de pod. vez que se han asignado las directivas
en Azure, todos los usuarios del clúster
pueden usar estas directivas.
Aplicabilidad de las directivas El usuario administrador está exento Todos los usuarios (administradores y
del cumplimiento de las directivas de no administradores) ven las mismas
seguridad de pod. directivas. No hay ninguna grafía
especial basada en los usuarios. La
aplicación de las directivas se puede
excluir en el nivel de espacio de
nombres.
Ámbito de la directiva Las directivas de seguridad de pod no Las plantillas de restricción usadas por
tienen espacios de nombres Azure Policy no tienen espacios de
nombres.
Acción de Las directivas de seguridad de pod Azure Policy admite las acciones de
denegación/auditoría/mutación solo admiten acciones de denegación. denegación y de auditoría. La
La mutación se puede realizar con mutación todavía no se admite, pero
valores predeterminados en las está planeada.
solicitudes de creación. La validación se
puede realizar durante las solicitudes
de actualización.
ESC EN A RIO DIREC T IVA DE SEGURIDA D DE P O D A Z URE P O L IC Y
Cumplimiento de la directiva de No hay visibilidad del cumplimiento de Los pods no compatibles que existían
seguridad de pod los pods que existían antes de habilitar antes de aplicar las directivas de Azure
la directiva de seguridad de pod. Los se mostrarían en infracciones de
pods no compatibles creados después directivas. Los pods no compatibles
de habilitar las directivas de seguridad creados después de habilitar las
de pod se deniegan. directivas de Azure se deniegan si las
directivas se establecen con efecto de
denegación.
Cómo ver las directivas del clúster kubectl get psp kubectl get constrainttemplate :
devuelve todas las directivas.
Directiva de seguridad de pod De forma predeterminada, se crea un El modo con privilegios no implica
estándar: con privilegios recurso de directiva de seguridad de ninguna restricción, por tanto, es
pod con privilegios al habilitar la equivalente a no tener ninguna
característica. asignación de Azure Policy.
Directiva de seguridad de pod El usuario instala un recurso de línea Azure Policy proporciona una iniciativa
estándar: línea de de base de la directiva de seguridad de de línea de base integrada que se
base/predeterminada pod. asigna a la directiva de seguridad de
pod de línea de base.
Directiva de seguridad de pod El usuario instala un recurso Azure Policy proporciona una iniciativa
estándar: restringida restringido de la directiva de seguridad restringida integrada que se asigna a la
de pod. directiva de seguridad de pod de
restringida.
Habilitación de una directiva de seguridad de pod en un clúster de

AKS
Puede habilitar o deshabilitar la directiva de seguridad de pod mediante el comando az aks update. En el
siguiente ejemplo se habilita la directiva de seguridad de pod en el clúster denominado myAKSCluster del grupo
de recursos myResourceGroup.
NOTE
Para el uso en el mundo real, no habilite la directiva de seguridad de pod hasta que haya definido sus propias directivas
personalizadas. En este artículo se habilita la directiva de seguridad de pod como primer paso para mostrar cómo las
predeterminadas limitan la implementación de pods.
az aks update \
--enable-pod-security-policy
Directivas predeterminadas de AKS

Cuando se habilita la directiva de seguridad pod, AKS crea una directiva predeterminada denominada privileged.
No modifique ni elimine la directiva predeterminada. En su lugar, cree sus propias directivas que definan la
configuración que desee controlar. Primero echemos un vistazo a qué son estas directivas predeterminadas y a
cómo afectan a la implementación de pods.
Para ver las directivas disponibles, use el comando kubectl get psp, tal como se muestra en el siguiente ejemplo.
$ kubectl get psp
NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP READONLYROOTFS VOLUMES

privileged true * RunAsAny RunAsAny RunAsAny RunAsAny false *
configMap,emptyDir,projected,secret,downwardAPI,persistentVolumeClaim
La directiva de seguridad de pod provileged se aplica a cualquier usuario que se autentique en el clúster de AKS.
Esta asignación se controla mediante ClusterRoles y ClusterRoleBindings. Use el comando kubectl get
rolebindings y busque el enlace default:privileged: en el espacio de nombres kube-system:
kubectl get rolebindings default:privileged -n kube-system -o yaml
Como se muestra en la siguiente salida reducida, el valor de ClusterRole psp:privileged se asigna a cualquier
usuario system:authenticated. Esta capacidad proporciona un nivel básico de privilegio sin tener directivas
propias definidas.
kind: RoleBinding
metadata:
[...]
name: default:privileged
[...]
roleRef:
kind: ClusterRole
name: psp:privileged
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:masters
Es importante entender cómo interactúan estas directivas predeterminadas con las solicitudes de usuario para
programar los pods antes de empezar a crear directivas de seguridad de pod propias. En las siguientes
secciones programaremos algunos pods para ver estas directivas predeterminadas en acción.
Creación de un usuario de prueba en un clúster de AKS

De forma predeterminada, al usar el comando az aks get-credentials, las credenciales del administrador del
clúster de AKS se agregan a la configuración de kubectl . El usuario administrador está exento del
cumplimiento de las directivas de seguridad de pod. Si usa la integración de Azure Active Directory para los
clústeres de AKS, podría iniciar sesión con las credenciales de un usuario sin derechos de administrador para ver
el cumplimiento de directivas en acción. En este artículo vamos a crear y a usar una cuenta de usuario de prueba
en el clúster de AKS.
Cree un espacio de nombres de ejemplo denominado psp-aks para probar los recursos con el comando kubectl
create namespace. A continuación, cree una cuenta de servicio denominada nonadmin-user con el comando
kubectl create serviceaccount:
kubectl create namespace psp-aks

kubectl create serviceaccount --namespace psp-aks nonadmin-user
Ahora cree un RoleBinding para nonadmin-user para que realice acciones básicas en el espacio de nombres
mediante el comando kubectl create rolebinding:
kubectl create rolebinding \
--namespace psp-aks \
psp-aks-editor \
--clusterrole=edit \
--serviceaccount=psp-aks:nonadmin-user
Creación de comandos de alias para los usuarios administrador y no administrador

Para resaltar la diferencia entre el usuario de administrador normal al usar kubectl y el usuario sin derechos de
administrador que creó en los pasos anteriores, cree dos alias de la línea de comandos:
El alias kubectl-admin es para el usuario administrador normal, para el espacio de nombres psp-aks.
El alias kubectl nonadminuser es para el usuario no administrador creado en el paso anterior, para el
espacio de nombres psp-aks.
Cree estos dos alias tal y como se muestra en los siguientes comandos:
alias kubectl-admin='kubectl --namespace psp-aks'

alias kubectl-nonadminuser='kubectl --as=system:serviceaccount:psp-aks:nonadmin-user --namespace psp-aks'
Prueba de la creación de un pod con privilegios

Vamos a probar primero lo que sucede cuando se programa un pod con el contexto de seguridad
privileged: true . Este contexto de seguridad eleva los privilegios del pod. En la sección anterior donde se
mostraban las directivas de seguridad de pod predeterminadas de AKS, la directiva privilege debería denegar
esta solicitud.
Cree un archivo denominado nginx-privileged.yaml y pegue el siguiente manifiesto de YAML:
apiVersion: v1
kind: Pod
metadata:
name: nginx-privileged
spec:
containers:
- name: nginx-privileged
securityContext:
privileged: true
kubectl-nonadminuser apply -f nginx-privileged.yaml
El pod no se puede programar, como se muestra en la salida del ejemplo siguiente:
$ kubectl-nonadminuser apply -f nginx-privileged.yaml
Error from server (Forbidden): error when creating "nginx-privileged.yaml": pods "nginx-privileged" is
forbidden: unable to validate against any pod security policy: []
Prueba de la creación de un pod sin privilegios

En el ejemplo anterior, la especificación del pod solicitaba el escalado de privilegios. Esta solicitud la deniega la
directiva de seguridad de pod privilege predeterminada, por lo que no se puede programar el pod. Vamos a
probar ahora a ejecutar ese mismo pod NGINX sin la solicitud de elevación de privilegios.
Cree un archivo denominado nginx-unprivileged.yaml y pegue el siguiente manifiesto de YAML:
apiVersion: v1
kind: Pod
metadata:
name: nginx-unprivileged
spec:
containers:
kubectl-nonadminuser apply -f nginx-unprivileged.yaml
$ kubectl-nonadminuser apply -f nginx-unprivileged.yaml
Error from server (Forbidden): error when creating "nginx-unprivileged.yaml": pods "nginx-unprivileged" is
forbidden: unable to validate against any pod security policy: []
Creación de prueba de un pod con un contexto de usuario específico

En el ejemplo anterior la imagen de contenedor intentó automáticamente utilizar la raíz para enlazar NGINX al
puerto 80. Esta solicitud la denegó la directiva de seguridad de pod privilege predeterminada, por lo que no se
puede iniciar el pod. Vamos a probar ahora a ejecutar ese mismo pod NGINX con un contexto de usuario
específico, como runAsUser: 2000 .
Cree un archivo denominado nginx-unprivileged-nonroot.yaml y pegue el siguiente manifiesto de YAML:
apiVersion: v1
kind: Pod
metadata:
name: nginx-unprivileged-nonroot
spec:
containers:
securityContext:
runAsUser: 2000
kubectl-nonadminuser apply -f nginx-unprivileged-nonroot.yaml

$ kubectl-nonadminuser apply -f nginx-unprivileged-nonroot.yaml
Error from server (Forbidden): error when creating "nginx-unprivileged-nonroot.yaml": pods "nginx-
unprivileged-nonroot" is forbidden: unable to validate against any pod security policy: []
Creación de una directiva de seguridad de pod personalizada

Ahora que hemos visto el comportamiento de las directivas de seguridad de pod predeterminadas, vamos a
proporcionar una forma para que el usuario no administrador pueda programar pods.
Vamos a crear una directiva para rechazar los pods que soliciten acceso con privilegios. Otras opciones, como
runAsUser o los volúmenes permitidos, no se restringen explícitamente. Este tipo de directiva deniega una
solicitud de acceso con privilegios, pero permite al clúster ejecutar los pods solicitados.
Cree un archivo denominado psp-deny-privileged.yaml y pegue el siguiente manifiesto de YAML:
kind: PodSecurityPolicy
metadata:
name: psp-deny-privileged
spec:
privileged: false
seLinux:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
runAsUser:
rule: RunAsAny
fsGroup:
rule: RunAsAny
volumes:
- '*'
Cree la directiva mediante el comando kubectl apply y especifique el nombre del manifiesto de YAML:
kubectl apply -f psp-deny-privileged.yaml
Para ver las directivas disponibles, use el comando kubectl get psp, tal como se muestra en el siguiente ejemplo.
Compare la directiva psp-deny-privileged con el valor de la directiva privilege predeterminada que aplicó en los
ejemplos anteriores para crear un pod. Su directiva solo deniega el uso del escalado PRIV. No hay ninguna
restricción para el usuario o grupo relativa a la directiva psp-deny-privileged.
$ kubectl get psp
NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP READONLYROOTFS

VOLUMES
privileged true * RunAsAny RunAsAny RunAsAny RunAsAny false
*
psp-deny-privileged false RunAsAny RunAsAny RunAsAny RunAsAny false
*
Permiso par que la cuenta de usuario use la directiva de seguridad de

pod personalizada
En el paso anterior ha creado una directiva de seguridad de pod para rechazar los pods que soliciten acceso con
privilegios. Para permitir el uso de la directiva, cree un rol o ClusterRole. Asocie uno de estos roles mediante
RoleBinding o ClusterRoleBinding.
Para este ejemplo, cree un ClusterRole que le permita usar la directiva psp-deny-privileged que creó en el paso
anterior. Cree un archivo denominado psp-deny-privileged-clusterrole.yaml y pegue el siguiente manifiesto de
YAML:
kind: ClusterRole
metadata:
name: psp-deny-privileged-clusterrole
rules:
- apiGroups:
- extensions
resources:
- podsecuritypolicies
resourceNames:
- psp-deny-privileged
verbs:
- use
Cree el ClusterRole mediante el comando kubectl apply y especifique el nombre del manifiesto de YAML:
kubectl apply -f psp-deny-privileged-clusterrole.yaml
Ahora cree un ClusterRoleBinding para usar el ClusterRole que creó en el paso anterior. Cree un archivo
denominado psp-deny-privileged-clusterrolebinding.yaml y pegue el siguiente manifiesto de YAML:
kind: ClusterRoleBinding
metadata:
name: psp-deny-privileged-clusterrolebinding
roleRef:
kind: ClusterRole
name: psp-deny-privileged-clusterrole
subjects:
kind: Group
name: system:serviceaccounts
Cree un ClusterRoleBinding mediante el comando kubectl apply y especifique el nombre del manifiesto de
YAML:
kubectl apply -f psp-deny-privileged-clusterrolebinding.yaml
NOTE
En el primer paso de este artículo se ha habilitado la característica de directiva de seguridad de pod en el clúster de AKS. El
método recomendado era habilitar solo la característica de directiva de seguridad de pod una vez definidas las directivas
propias. Esta es la fase en la que habilitaría la característica de directiva de seguridad de pod. Se han definido una o varias
directivas personalizadas y las cuentas de usuario se han asociado a esas directivas. Ahora puede habilitar la característica
de directiva de seguridad de pod sin problemas y reducir los problemas causados por las directivas predeterminadas.
Segunda prueba de creación de un pod sin privilegios
Con la directiva de seguridad de pod personalizada aplicado y un enlace para la cuenta de usuario para que use
la directiva, vamos a intentar volver a crear un pod sin privilegios. Use el mismo manifiesto
nginx-privileged.yaml para crear el pod mediante el comando kubectl apply:
kubectl-nonadminuser apply -f nginx-unprivileged.yaml
Se ha programado correctamente el pod. Al activar el estado del pod mediante el comando kubectl get pods, el
pod tiene el estado En ejecución:
$ kubectl-nonadminuser get pods

nginx-unprivileged 1/1 Running 0 7m14s
En este ejemplo se muestra cómo crear directivas de seguridad de pod personalizadas para definir el acceso al
clúster de AKS para distintos usuarios o grupos. Las directivas de AKS predeterminadas proporcionan controles
estrictos sobre lo que los pods pueden ejecutar, por lo tanto, cree sus propias directivas personalizadas para
definir las restricciones que necesite correctamente.
Elimine el pod NGIX sin privilegios mediante el comando kubectl delete y especifique el nombre del manifiesto
de YAML:
kubectl-nonadminuser delete -f nginx-unprivileged.yaml
Par deshabilitar la directiva de seguridad de pod, use el comando az aks update de nuevo. En el siguiente
ejemplo se deshabilita la directiva de seguridad de pod en el clúster denominado myAKSCluster del grupo de
recursos myResourceGroup:
az aks update \
--disable-pod-security-policy
A continuación, elimine ClusterRole y ClusterRoleBinding:
kubectl delete -f psp-deny-privileged-clusterrolebinding.yaml

kubectl delete -f psp-deny-privileged-clusterrole.yaml
Elimine la directiva de seguridad mediante el comando kubectl delete y especifique el nombre del manifiesto de
YAML:
kubectl delete -f psp-deny-privileged.yaml
Por último, elimine el espacio de nombres psp-aks:
kubectl delete namespace psp-aks

Pasos siguientes
En este artículo se ha explicado cómo crear una directiva de seguridad de pod para evitar el acceso con
privilegios. Hay una gran cantidad de características que puede aplicar una directiva, como el tipo de volumen o
el usuario RunAs. Para más información sobre las opciones disponibles, consulte los documentos de referencia
de la directiva de seguridad de pod de Kubernetes.
Para más información sobre la limitación del tráfico del pod, consulte Protección del tráfico entre pods mediante
directivas de red en Azure Kubernetes Service (AKS).
Protección del acceso al servidor de API con
intervalos de direcciones IP autorizadas en Azure
En Kubernetes, el servidor de API recibe solicitudes para realizar acciones en el clúster, como crear recursos o
reducir el número de nodos. El servidor de API es la manera centralizada de interactuar con un clúster y
administrarlo. Para mejorar la seguridad del clúster y minimizar los ataques, el servidor de API solo debe ser
accesible desde un conjunto limitado de intervalos de direcciones IP.
En este artículo se muestra cómo usar los intervalos IP autorizados por el servidor de API para limitar qué
direcciones IP y CIDR pueden acceder al plano de control.
Antes de empezar
En este artículo se muestra cómo utilizar la CLI de Azure para crear un clúster de AKS.
Azure.
Limitaciones
La característica de intervalos IP autorizados por el servidor de la API tiene las siguientes limitaciones:
En los clústeres creados después de que los intervalos de direcciones IP autorizados por el servidor de API se
hayan pasado de la versión preliminar en octubre de 2019, los intervalos de direcciones IP autorizados del
servidor de API solo se admiten en el equilibrador de carga de SKU Estándar. Los clústeres existentes con la
SKU Básica del equilibrador de carga y los intervalos IP autorizados del servidor de API seguirán
funcionando tal cual, pero no se podrán migrar a un equilibrador de carga de SKU Estándar. Los clústeres
existentes también seguirán funcionando si se actualiza la versión de Kubernetes o el plano de control. Los
intervalos de direcciones IP autorizados del servidor de API no se admiten para los clústeres privados.
Esta característica no es compatible con los clústeres que usan la dirección IP pública por nodo.
Información general sobre los intervalos de direcciones IP autorizadas

por el servidor de API
El servidor de API de Kubernetes es el modo en el que se exponen las API de Kubernetes subyacentes. Este
componente proporciona la interacción de las herramientas de administración, como kubectl o el panel de
Kubernetes. AKS proporciona un plano de control de inquilino único con un servidor de API dedicado, etc. El
servidor de API se asigna de forma predeterminada a una dirección IP pública, y el usuario debe regular el
acceso mediante el control de acceso basado en rol de Kubernetes (RBAC de Kubernetes) o RBAC de Azure.
Para proteger el acceso al panel de control de AKS y al servidor de API (que, de lo contrario, serían accesibles al
público), puede habilitar y usar intervalos de direcciones IP autorizadas. De esta manera, solo se permite la
comunicación con el servidor de API a los intervalos de direcciones IP definidas. Las solicitudes al servidor de
API procedentes de direcciones IP que no formen parte de este intervalo se bloquean. Siga usando RBAC de
Kubernetes o RBAC de Azure para autorizar a los usuarios y las acciones que soliciten.
Para más información sobre el servidor de API y otros componentes del clúster, consulte los conceptos clave de
Kubernetes para AKS.
Creación de un clúster de AKS con la opción de intervalos IP

autorizados por el servidor de API habilitada
Cree un clúster con el comando az aks create y especifique el parámetro --api-server-authorized-ip-ranges
para proporcionar una lista de intervalos IP autorizados. Estos intervalos IP suelen ser intervalos de direcciones
que usan las redes locales o IP públicas. Al especificar un intervalo de CIDR, comience por la primera dirección
IP del intervalo. Por ejemplo, 137.117.106.90/29 es un intervalo válido, pero asegúrese de especificar la primera
dirección IP del intervalo, por ejemplo, 137.117.106.88/29.
IMPORTANT
De forma predeterminada, el clúster usa el equilibrador de carga de SKU estándar, que se puede usar para configurar la
puerta de enlace de salida. Cuando se habilitan intervalos IP autorizados por el servidor de API durante la creación del
clúster, además de los intervalos especificados también se permite de forma predeterminada la dirección IP pública del
clúster. Si especifica "" o ningún valor para --api-server-authorized-ip-ranges , se deshabilitarán los intervalos IP
autorizados por el servidor de API. Tenga en cuenta que si usa PowerShell, debe usar
--api-server-authorized-ip-ranges="" (con el signo igual) para evitar problemas de análisis.
En el siguiente ejemplo se crea un clúster de nodo único denominado myAKSCluster en el grupo de recursos
denominado myResourceGroup, con la opción de intervalos IP autorizados por el servidor de API habilitada. Los
intervalos de direcciones IP permitidos son 73.140.245.0/24:
az aks create \
--node-count 1 \
--api-server-authorized-ip-ranges 73.140.245.0/24 \
--generate-ssh-keys
NOTE
Debe agregar estos intervalos a una lista de permitidos:
La dirección IP pública del firewall
Cualquier intervalo que represente redes desde las que se va a administrar el clúster
Si usa Azure Dev Spaces en el clúster de AKS, tiene que permitir intervalos adicionales en función de su región.
El límite superior para el número de intervalos IP que se puede especificar es de 200.
Las reglas pueden tardar hasta 2 minutos en propagarse. Espere ese tiempo al probar la conexión.
Especificación de las direcciones IP de salida para el equilibrador de carga de SKU estándar

Al crear un clúster de AKS, si especifica direcciones IP o prefijos de salida para el clúster, estas direcciones o
prefijos también se permiten. Por ejemplo:
az aks create \
--node-count 1 \
--load-balancer-outbound-ips <publicIpId1>,<publicIpId2> \
--generate-ssh-keys
En el ejemplo anterior, todas las direcciones IP proporcionadas en el parámetro

--load-balancer-outbound-ip-prefixes están permitidas, junto con las direcciones IP en el parámetro
--api-server-authorized-ip-ranges .
También puede especificar el parámetro --load-balancer-outbound-ip-prefixes para permitir prefijos de

direcciones IP del equilibrador de carga de salida.
Permiso solo para la dirección IP pública de salida del equilibrador de carga de SKU estándar
Cuando se habilitan intervalos IP autorizados por el servidor de API durante la creación del clúster, además de
los intervalos especificados también se permite la dirección IP pública de salida para el equilibrador de carga de
SKU estándar para el clúster. Para permitir solo la dirección IP pública de salida del equilibrador de carga de SKU
estándar, use 0.0.0.0/32 al especificar el parámetro --api-server-authorized-ip-ranges .
En el ejemplo siguiente, solo se permite la dirección IP pública de salida del equilibrador de carga de SKU
estándar y solo se puede acceder al servidor de API desde los nodos del clúster.
az aks create \
--node-count 1 \
--generate-ssh-keys
Actualización de los intervalos IP autorizados por el servidor de API

de un clúster
Para actualizar los intervalos IP autorizados por el servidor de API en un clúster existente, use el comando az aks
update y los parámetros --api-server-authorized-ip-ranges ,--load-balancer-outbound-ip-prefixes ,
--load-balancer-outbound-ips y or--load-balancer-outbound-ip-prefixes.
En el siguiente ejemplo se actualizan los intervalos IP autorizados por el servidor de API en el clúster
denominado myAKSCluster del grupo de recursos denominado myResourceGroup. El intervalo de
direcciones IP que se va a autorizar es 73.140.245.0/24:
az aks update \
--api-server-authorized-ip-ranges 73.140.245.0/24
También puede usar 0.0.0.0/32 al especificar el parámetro --api-server-authorized-ip-ranges para permitir solo
la dirección IP pública del equilibrador de carga de SKU estándar.
Deshabilitación de los intervalos IP autorizados

Para deshabilitar los intervalos IP autorizados, use az aks update y especifique un intervalo vacío para
deshabilitar los intervalos IP autorizados del servidor de API. Por ejemplo:
az aks update \
--api-server-authorized-ip-ranges ""
Búsqueda de intervalos IP autorizados existentes

Para buscar los intervalos IP que se han autorizado, use az aks show y especifique el nombre del clúster y el
grupo de recursos. Por ejemplo:
az aks show \
--query apiServerAccessProfile.authorizedIpRanges'
Actualización, deshabilitación y búsqueda de intervalos IP autorizados

mediante Azure Portal
Las operaciones anteriores de agregar, actualizar, buscar y deshabilitar intervalos IP autorizados también se
pueden realizar en Azure Portal. Para acceder a ellas, vaya a Redes en Configuración en la hoja de menús del
recurso de clúster.
¿Cómo se encuentra la dirección IP que se va a incluir en
--api-server-authorized-ip-ranges ?
Debe agregar las máquinas de desarrollo, las herramientas o las direcciones IP de automatización a la lista de
clústeres de AKS de intervalos IP aprobados para tener acceso al servidor de API desde allí.
Otra opción consiste en configurar una JumpBox con las herramientas necesarias en una subred independiente
de la red virtual del firewall. Esto supone que el entorno tiene un firewall con la red correspondiente y que ha
agregado las direcciones IP del firewall a los intervalos autorizados. Del mismo modo, si se ha forzado la
tunelización de la subred AKS a la subred del firewall, el hecho de tener el jumpbox en la subred del clúster
también es correcto.
Agregue otra dirección IP a los intervalos autorizados con el siguiente comando.

NOTE
El ejemplo anterior agrega los intervalos IP autorizados de servidor de API en el clúster. Para deshabilitar los
intervalos IP autorizados, use az aks update y especifique un intervalo vacío "".
Otra opción consiste en usar el comando siguiente en los sistemas de Windows para obtener la dirección IPv4
pública, o bien puede usar los pasos descritos en Buscar su dirección IP.
Invoke-RestMethod http://ipinfo.io/json | Select -exp ip
Para encontrar esta dirección, busque "cuál es mi dirección IP" en un explorador de Internet.
Pasos siguientes
En este artículo ha habilitado intervalos de direcciones IP autorizadas por el servidor de API. Este enfoque forma
parte del modo de ejecución segura de un clúster de AKS.
Para más información, consulte Conceptos de seguridad de las aplicaciones y los clústeres en Azure Kubernetes
Service (AKS) y Procedimientos recomendados para la seguridad de clústeres y las actualizaciones en AKS.
Descripción de Azure Policy para clústeres de
Kubernetes (versión preliminar)
Azure Policy extiende Gatekeeper v3, un webhook de controlador de admisión de Open Policy Agent (OPA), a fin
de aplicar medidas de seguridad y cumplimiento a escala en los clústeres de una manera centralizada y
coherente. Azure Policy permite administrar e informar sobre el estado de cumplimiento de los clústeres de
Kubernetes desde un único lugar. El complemento realiza las funciones siguientes:
Comprueba con el servicio Azure Policy las asignaciones de directivas al clúster.
Implementa definiciones de directiva en el clúster como recursos de plantilla de restricción y restricción.
Realiza informes de auditoría y cumplimiento y los devuelve al servicio Azure Policy.
Azure Policy para Kubernetes admite los entornos de clúster siguientes:
Kubernetes habilitado para Azure Arc
AKS Engine
IMPORTANT
Los complementos para el motor de AKS y los Kubernetes habilitados para Arc están en versión preliminar . Azure
Policy para Kubernetes solo admite grupos de nodos de Linux y definiciones de directivas integradas. Las definiciones de
directivas integradas se encuentran en la categoría Kubernetes . Las definiciones de directiva de versión preliminar
limitadas con efecto EnforceOPAConstraint y EnforceRegoPolicy y la categoría ser vicio Kubernetes relacionada
están en desuso. En su lugar, use los efectos audit y deny con el modo de proveedor de recursos
Microsoft.Kubernetes.Data .
Para habilitar y usar Azure Policy con el clúster de Kubernetes, realice las acciones siguientes:
1. Configure el clúster de Kubernetes e instale el complemento:
Kubernetes habilitado para Azure Arc
AKS Engine
NOTE
Para resolver problemas de instalación comunes, consulte el tema de solución de problemas del complemento de
Azure Policy.
2. Descripción del lenguaje de Azure Policy para Kubernetes

3. Asignación de una definición integrada a un clúster de Kubernetes
4. Espere la validación
Limitaciones
Las siguientes limitaciones generales se aplican al complemento de Azure Policy en los clústeres de Kubernetes:
El complemento Azure Policy para Kubernetes es compatible con la versión 1.14 o posterior de Kubernetes.
El complemento Azure Policy para Kubernetes solo se puede implementar en grupos de nodos de Linux
Solo se admiten las definiciones de directivas integradas
Número máximo de registros no compatibles por directiva por clúster: 500
Número máximo de registros no compatibles por suscripción: 1 millón
No se admiten las instalaciones de Gatekeeper fuera del complemento de Azure Policy. Desinstale los
componentes instalados por una instalación anterior de Gatekeeper antes de habilitar el complemento de
Azure Policy.
Los motivos de la no compatibilidad no están disponibles para el Microsoft.Kubernetes.Data modo de
proveedor de recursos. Use Detalles del componente.
No se admiten exenciones para los modos de proveedor de recursos.
Las siguientes limitaciones generales solo se aplican al complemento de Azure Policy para AKS:
La directiva de seguridad de pod de AKS y el complemento de Azure Policy para AKS no se pueden habilitar
simultáneamente. Para obtener más información, consulte Limitación de seguridad de pod de AKS.
Los espacios de nombres se excluyen automáticamente mediante el complemento de Azure Policy para la
evaluación: kube-system, gatekeeper-system y aks-periscope.
Recomendaciones
A continuación se muestran recomendaciones generales para usar el complemento de Azure Policy:
El complemento de Azure Policy requiere tres componentes de Gatekeeper para ejecutarse: 1 pod de
auditoría y 2 réplicas de pods de webhook. Estos componentes consumen más recursos, ya que el
recuento de los recursos de Kubernetes y las asignaciones de directivas aumentan en el clúster, lo que
requiere operaciones de auditoría y cumplimiento.
Para menos de 500 pods en un solo clúster con un máximo de 20 restricciones: 2 vCPU y 350 MB de
memoria por componente.
Para más de 500 pods en un solo clúster con un máximo de 40 restricciones: 3 vCPU y 600 MB de
memoria por componente.
Los pods de Windows no admiten contextos de seguridad. Por lo tanto, algunas de las definiciones de
Azure Policy, como no permitir privilegios raíz, no se pueden escalar en pods de Windows y solo se
aplican a los pods de Linux.
La siguiente recomendación solo se aplica a AKS y al complemento de Azure Policy:
Use el grupo de nodos del sistema con el valor taint CriticalAddonsOnly para programar pods de
Gatekeeper. Para obtener más información, consulte Uso de pods de nodos del sistema.
Proteja el tráfico saliente de sus clústeres de AKS. Para obtener más información, consulte Control del tráfico
de salida de los nodos de clúster.
Si el clúster tiene aad-pod-identity habilitado, los pods de Identidad administrada del nodo (NMI) modifican
las tablas de IP de los nodos para interceptar las llamadas que se realizan en el punto de conexión de Azure
Instance Metadata. Esta configuración hace que NMI intercepte toda solicitud realizada al punto de conexión
de Metadata, incluso aunque el pod no utilice aad-pod-identity . La CRD de AzurePodIdentityException se
puede configurar para informar a aad-pod-identity de que las solicitudes dirigidas al punto de conexión de
Metadata que se originen en un pod que coincida con las etiquetas definidas en la CRD deben pasar por el
servidor proxy sin que se procesen en NMI. Los pods del sistema con la etiqueta
kubernetes.azure.com/managedby: aks del espacio de nombres kube-system deben excluirse en
aad-pod-identity configurando la CRD de AzurePodIdentityException. Para obtener más información,
consulte este artículo acerca de cómo deshabilitar aad-pod-identity en una aplicación o pod específicos. Para
configurar una excepción, instale mic-exception.YAML.
Instalación del complemento de Azure Policy para AKS

Antes de instalar el complemento de Azure Policy o habilitar cualquiera de las características del servicio, la
suscripción debe habilitar los proveedores de recursos Microsoft.PolicyInsights .
1. Es preciso que esté instalada y configurada la versión 2.12.0 de la CLI de Azure, o cualquier otra posterior.
Ejecute az --version para encontrar la versión. Si necesita instalarla o actualizarla, consulte Instalación
de la CLI de Azure.
2. Registre los proveedores de recursos y las características en vista previa.
Azure Portal:
Registre el proveedor de recursos Microsoft.PolicyInsights . Para conocer los pasos, consulte
Proveedores de recursos y sus tipos.
CLI de Azure:
# Log in first with az login if you're not using Cloud Shell
# Provider register: Register the Azure Policy provider

az provider register --namespace Microsoft.PolicyInsights
3. Si hay definiciones de directiva de versión preliminar limitadas instaladas, quite el complemento con el
botón Deshabilitar en el clúster de AKS en la página Directivas .
4. Se debe usar la versión del clúster de AKS 1.14 o posterior. Use el siguiente script para validar la versión
del clúster de AKS:
# Look for the value in kubernetesVersion

az aks list
5. Instale la versión 2.12.0 o superior de la CLI de Azure. Para más información, consulte Instalación de la
CLI de Azure.
Una vez que se han completado los pasos anteriores de requisitos previos, instale el complemento de Azure
Policy en el clúster de AKS que quiera administrar.
Azure portal
1. Inicie el servicio AKS en Azure Portal al seleccionar Todos los ser vicios ; a continuación, busque y
seleccione Ser vicios de Kubernetes .
2. Seleccione uno de sus clústeres de AKS.
3. Seleccione Directivas en el lado izquierdo de la página de servicio de Kubernetes.
4. En la página principal, seleccione el botón Enable add-on (Habilitar complemento).
NOTE
Si el botón Deshabilitar complemento está habilitado y se muestra un mensaje de advertencia de
migración a v2, el complemento v1 está instalado y se debe quitar antes de asignar las definiciones de
directiva v2. El complemento en desuso v1 se reemplazará automáticamente por el complemento v2 a
partir del 24 de agosto. 2020. A partir de entonces, se deben asignar las nuevas versiones v2 de las
definiciones de directiva. Para actualizar ahora, siga estos pasos:
1. Para validar que el clúster de AKS tiene instalado el complemento v1, visite la página de Directivas en
el clúster de AKS, y que tenga el mensaje "The current cluster uses Azure Policy add-on v1…" (El clúster
actual utiliza el complemento de Azure Policy v1…).
2. Quite el complemento.
3. Seleccione el botón Habilitar complemento para instalar la versión v2 del complemento.
4. Asignación de versiones V2 de las definiciones de directiva integradas v1
Azure CLI
az aks enable-addons --addons azure-policy --name MyAKSCluster --resource-group MyResourceGroup
Para comprobar que la instalación del complemento se ha realizado correctamente y que los pods azure-policy
y gatekeeper están en ejecución, ejecute el comando siguiente:
# azure-policy pod is installed in kube-system namespace

kubectl get pods -n kube-system
# gatekeeper pod is installed in gatekeeper-system namespace

kubectl get pods -n gatekeeper-system
Por último, para comprobar que el complemento más reciente está instalado, ejecute este comando de la CLI de
Azure y reemplace <rg> por el nombre del grupo de recursos y <cluster-name> por el nombre del clúster de
AKS: az aks show --query addonProfiles.azurepolicy -g <rg> -n <cluster-name> . El resultado debe ser similar al
siguiente y config.version debe ser v2 :
"addonProfiles": {
"azurepolicy": {
"config": {
"version": "v2"
},
"enabled": true,
"identity": null
},
}
Instalación del complemento de Azure Policy de Kubernetes

habilitado para Azure Arc (versión preliminar)
Antes de instalar el complemento de Azure Policy o habilitar cualquiera de las características del servicio, su
suscripción debe tener habilitados el proveedor de recursos Microsoft.PolicyInsights y crear una asignación
de roles para la entidad de servicio del clúster.
1. Es preciso que esté instalada y configurada la versión 2.12.0 de la CLI de Azure, o cualquier otra posterior.
Ejecute az --version para encontrar la versión. Si necesita instalarla o actualizarla, consulte Instalación
de la CLI de Azure.
2. Para habilitar el proveedor de recursos, siga los pasos descritos en Tipos y proveedores de recursos o
ejecute el comando de PowerShell o la CLI de Azure:
Azure CLI

az provider register --namespace 'Microsoft.PolicyInsights'
Azure PowerShell
# Log in first with Connect-AzAccount if you're not using Cloud Shell

Register-AzResourceProvider -ProviderNamespace 'Microsoft.PolicyInsights'
3. Se debe usar la versión del clúster de Kubernetes 1.14 o posterior.

4. Instale Helm 3.
5. El clúster de Kubernetes habilitado para Azure Arc. Para obtener más información, vea Incorporación de
un clúster de Kubernetes a Azure Arc.
6. Tener el identificador de recurso completo de Azure del clúster de Kubernetes habilitado para Azure Arc.
7. Abra los puertos para el complemento. El complemento de Azure Policy usa estos dominios y puertos
para obtener las definiciones de directiva y las asignaciones, y notificar a Azure Policy el cumplimiento del
clúster.
DO M A IN P O RT
gov-prod-policy-data.trafficmanager.net 443
raw.githubusercontent.com 443
login.windows.net 443
dc.services.visualstudio.com 443
8. Asigne la asignación de rol "Escritor de datos de Policy Insights (versión preliminar)" al clúster de
Kubernetes habilitado para Azure Arc. Reemplace <subscriptionId> por el identificador de la suscripción,
<rg> por el grupo de recursos del clúster de Kubernetes habilitado para Azure Arc y <clusterName> por
el nombre del clúster de Kubernetes habilitado para Azure Arc. Realice el seguimiento de los valores
devueltos para appId, password y tenant para los pasos de instalación.
Azure CLI
az ad sp create-for-rbac --role "Policy Insights Data Writer (Preview)" --scopes

"/subscriptions/<subscriptionId>/resourceGroups/<rg>/providers/Microsoft.Kubernetes/connectedC
lusters/<clusterName>"
Azure PowerShell
$sp = New-AzADServicePrincipal -Role "Policy Insights Data Writer (Preview)" -Scope
"/subscriptions/<subscriptionId>/resourceGroups/<rg>/providers/Microsoft.Kubernetes/connectedC
lusters/<clusterName>"
@{ appId=$sp.ApplicationId;password=
[System.Runtime.InteropServices.Marshal]::PtrToStringAuto([System.Runtime.InteropServices.Mars
hal]::SecureStringToBSTR($sp.Secret));tenant=(Get-AzContext).Tenant.Id } | ConvertTo-Json
Ejemplo de salida de los comandos anteriores:
{
"appId": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa",
"password": "bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb",
"tenant": "cccccccc-cccc-cccc-cccc-cccccccccccc"
}
Policy en el clúster de Kubernetes habilitado para Azure Arc:
1. Agregue el repositorio del complemento de Azure Policy a Helm:
helm repo add azure-policy https://raw.githubusercontent.com/Azure/azure-

policy/master/extensions/policy-addon-kubernetes/helm-charts
2. Instale el complemento de Azure Policy con el gráfico de Helm:
# In below command, replace the following values with those gathered above.
# <AzureArcClusterResourceId> with your Azure Arc enabled Kubernetes cluster resource Id. For
example:
/subscriptions/<subscriptionId>/resourceGroups/<rg>/providers/Microsoft.Kubernetes/connectedClusters/
<clusterName>
# <ServicePrincipalAppId> with app Id of the service principal created during prerequisites.
# <ServicePrincipalPassword> with password of the service principal created during prerequisites.
# <ServicePrincipalTenantId> with tenant of the service principal created during prerequisites.
helm install azure-policy-addon azure-policy/azure-policy-addon-arc-clusters \
--set azurepolicy.env.resourceid=<AzureArcClusterResourceId> \
--set azurepolicy.env.clientid=<ServicePrincipalAppId> \
--set azurepolicy.env.clientsecret=<ServicePrincipalPassword> \
--set azurepolicy.env.tenantid=<ServicePrincipalTenantId>
Para obtener más información sobre lo que instala el gráfico de Helm de complemento, consulte la
definición del gráfico de Helm de complemento de Azure Policy en GitHub.


Instalación del complemento de Azure Policy para AKS Engine

Antes de instalar el complemento de Azure Policy o habilitar cualquiera de las características del servicio, su
suscripción debe tener habilitados el proveedor de recursos Microsoft.PolicyInsights y crear una asignación
de roles para la entidad de servicio del clúster.
1. Es preciso que esté instalada y configurada la versión 2.0.62 de la CLI de Azure, o cualquier otra versión
posterior. Ejecute az --version para encontrar la versión. Si necesita instalarla o actualizarla, consulte
Instalación de la CLI de Azure.
2. Para habilitar el proveedor de recursos, siga los pasos descritos en Tipos y proveedores de recursos o
ejecute el comando de PowerShell o la CLI de Azure:
Azure CLI

az provider register --namespace 'Microsoft.PolicyInsights'
Azure PowerShell
# Log in first with Connect-AzAccount if you're not using Cloud Shell

Register-AzResourceProvider -ProviderNamespace 'Microsoft.PolicyInsights'
3. Cree una asignación de roles para la entidad de servicio del clúster.

Si no conoce el identificador de la aplicación de la entidad de servicio del clúster, búsquelo con el
siguiente comando.
# Get the kube-apiserver pod name

# Find the aadClientID value

kubectl exec <kube-apiserver pod name> -n kube-system cat /etc/kubernetes/azure.json
Consigne la asignación de roles "Policy Insights Data Writer (Preview)" al identificador de la

aplicación de la entidad de servicio del clúster (valor aadClientID del paso anterior) con la CLI de
Azure. Reemplace <subscriptionId> por el identificador de su suscripción y
<aks engine cluster resource group> por el grupo de recursos en el que se encuentra el clúster de
Kubernetes autoadministrado de AKS Engine.
az role assignment create --assignee <cluster service principal app ID> --scope
"/subscriptions/<subscriptionId>/resourceGroups/<aks engine cluster resource group>" --role
"Policy Insights Data Writer (Preview)"
Policy. La instalación puede realizarse durante la creación o el ciclo de actualización de una instancia de AKS
Engine o como una acción independiente en un clúster existente.
Instalación durante la creación o el ciclo de actualización
Para habilitar el complemento Azure Policy durante la creación de un nuevo clúster autoadministrado o
como una actualización de un clúster existente, incluya la definición del clúster de la propiedad addons
para AKS Engine.
"addons": [{
"name": "azure-policy",
"enabled": true
}]
Para obtener más información al respecto, consulte la guía externa de definición del clúster de AKS
Engine.
Instalación en un clúster existente con gráficos de Helm
Siga estos pasos para preparar el clúster e instalar el complemento:
1. Instale Helm 3.
2. Agregue el repositorio Azure Policy a Helm.
helm repo add azure-policy https://raw.githubusercontent.com/Azure/azure-

policy/master/extensions/policy-addon-kubernetes/helm-charts
Para obtener más información, consulte la guía de inicio rápido del gráfico de Helm.
3. Instale el complemento con un gráfico de Helm. Reemplace <subscriptionId> por el identificador
de su suscripción y <aks engine cluster resource group> por el grupo de recursos en el que se
encuentra el clúster de Kubernetes autoadministrado de AKS Engine.
helm install azure-policy-addon azure-policy/azure-policy-addon-aks-engine --set

azurepolicy.env.resourceid="/subscriptions/<subscriptionId>/resourceGroups/<aks engine cluster
resource group>"
Para obtener más información sobre lo que instala el gráfico de Helm de complemento, consulte la
definición del gráfico de Helm de complemento de Azure Policy en GitHub.
NOTE
Debido a la relación entre el complemento de Azure Policy y el identificador del grupo de recursos, Azure
Policy solo admite un clúster de AKS Engine para cada grupo de recursos.


Idioma de directiva
La estructura del lenguaje de Azure Policy para administrar Kubernetes sigue la de las definiciones de directiva
existentes. Con un modo de proveedor de recursos de Microsoft.Kubernetes.Data , se usan los efectos audit y
deny para administrar los clústeres de Kubernetes. Audit y deny deben proporcionar propiedades details
específicas para trabajar con OPA Constraint Framework y Gatekeeper v3.
Como parte de las propiedades details.constraintTemplate y details.constraint de la definición de directiva, Azure
Policy pasa los URI de estas CustomResourceDefinitions (CRD) al complemento. Rego es el lenguaje que OPA y
el equipo selector admiten para validar una solicitud al clúster de Kubernetes. Al admitir un estándar existente
para la administración de Kubernetes, Azure Policy le permite reutilizar las reglas existentes y vincularlas con
Azure Policy para obtener una experiencia de informes de cumplimiento unificada en la nube. Para obtener más
información, consulte ¿Qué es Rego?
Asignación de una definición de directiva integrada

Para asignar una definición de directiva al clúster de Kubernetes, debe tener asignadas las operaciones de
asignación de directivas de control de acceso basado en rol de Azure (RBAC de AZure) adecuadas. Los roles de
Azure integrados Colaborador de la directiva de recursos y Propietario tienen estas operaciones. Para
obtener más información, vea Permisos de RBAC de Azure en Azure Policy.
Siga estos pasos para buscar las directivas integradas para administrar el clúster mediante Azure Portal:
1. Inicie el servicio Azure Policy en Azure Portal. Seleccione All ser vices (Todos los servicios) en el panel
izquierdo y busque y seleccione la opción Policy (Directiva).
2. En el panel izquierdo de la página de Azure Policy, seleccione Definitions (Definiciones).
3. En el cuadro de lista desplegable Categoría, use Seleccionar todo para borrar el filtro y seleccione
Kubernetes .
4. Seleccione la definición de directiva y pulse el botón Assign (Asignar).
5. Establezca el Ámbito en el grupo de administración, la suscripción o el grupo de recursos del clúster de
Kubernetes al que se aplicará la asignación de directiva.
NOTE
Al asignar Azure Policy para la definición de Kubernetes, el Ámbito debe incluir el recurso de clúster. En el caso de
un clúster de AKS Engine, el ámbito debe ser el grupo de recursos del clúster.
6. Asigne un Nombre y una Descripción a la asignación de directiva que pueda usar para identificarla con
facilidad.
7. Establezca Cumplimiento de directivas en uno de los valores siguientes.
Habilitado : aplicar la directiva en el clúster. Se deniegan las solicitudes de admisión de
Kubernetes con infracciones.
Deshabilitado : no aplicar la directiva en el clúster. No se deniegan las solicitudes de admisión de
Kubernetes con infracciones. Los resultados de la evaluación de cumplimiento siguen estando
disponibles. Al implementar nuevas definiciones de directiva para ejecutar clústeres, la opción
Deshabilitado resulta útil para probar la definición de directiva, ya que las solicitudes de admisión
con infracciones no se deniegan.
8. Seleccione Next (Siguiente).
9. Establecer Valores de parámetros
Para excluir los espacios de nombres de Kubernetes de la evaluación de directivas, especifique la lista
de espacios de nombres en el parámetro Exclusiones de los espacios de nombres . Se
recomienda excluir: kube-system, gatekeeper-system y azure-arc.
10. Seleccione Revisar + crear .
Como alternativa, use el inicio rápido Asignación de una directiva: Portal para buscar y asignar una directiva de
Kubernetes. Busque una definición de directiva de Kubernetes en lugar del ejemplo "audit vms".
IMPORTANT
Las definiciones de directiva integradas están disponibles para los clústeres de Kubernetes en la categoría Kubernetes .
Para obtener una lista de las definiciones de directiva integradas, vea Ejemplos de Kubernetes.
Evaluación de directiva
El complemento se registra con el servicio Azure Policy para detectar cambios en las asignaciones de directivas
cada 15 minutos. Durante este ciclo de actualización, el complemento comprueba si hay cambios. Estos cambios
desencadenan la creación, actualización o eliminación de restricciones y plantillas de restricciones.
En un clúster de Kubernetes, si un espacio de nombres tiene alguna de las etiquetas siguientes, no se deniegan
las solicitudes de admisión con infracciones. Los resultados de la evaluación de cumplimiento siguen estando
disponibles.
control-plane
admission.policy.azure.com/ignore
NOTE
Aunque es posible que un administrador de clústeres tenga permiso para crear y actualizar los recursos de plantillas y
restricciones instalados por el complemento Azure Policy, estos no son escenarios admitidos, ya que las actualizaciones
manuales se sobrescriben. Gatekeeper sigue evaluando las directivas que existían antes de instalar el complemento y de
asignar las definiciones de directiva de Azure Policy.
Cada 15 minutos, el complemento solicita un examen completo del clúster. Después de recopilar los detalles del
examen completo y las evaluaciones en tiempo real que realiza Gatekeeper sobre los intentos de cambios en el
clúster, el complemento proporciona los resultados a Azure Policy para los agregue en los detalles de
cumplimiento como cualquier otra asignación de Azure Policy. Solo los resultados de las asignaciones de
directivas activas se devuelven durante el ciclo de auditoría. Los resultados de la auditoría también pueden verse
como infracciones enumeradas en el campo de estado de la restricción errónea. Para obtener más información
sobre recursos no compatibles, consulte Detalles de los componentes de los modos de proveedor de recursos.
NOTE
En cada informe de cumplimiento de Azure Policy para los clústeres de Kubernetes se incluyen todas las infracciones de los
últimos 45 minutos. La marca de tiempo indica cuándo se ha producido una infracción.
Otras consideraciones:
Si la suscripción del clúster se registra con Azure Security Center, las directivas de Kubernetes de Azure
Security Center se aplicarán automáticamente en el clúster.
Cuando se aplica una directiva de denegación en un clúster que ya tiene recursos de Kubernetes, aunque
estos recursos no sean compatibles con la nueva directiva, seguirán ejecutándose. Cuando un recurso
que no es compatible vuelve a programarse en un nodo diferente, Gatekeeper bloquea la creación de
recursos.
Si un clúster tiene una directiva de denegación que valida los recursos, no se mostrará ningún mensaje
de rechazo al usuario cuando cree una implementación. Por ejemplo, imagine que tiene una
implementación de Kubernetes con pods y conjuntos de réplicas. Cuando un usuario ejecute
kubectl describe deployment $MY_DEPLOYMENT , no se devolverá un mensaje de rechazo durante los eventos.
Sin embargo, kubectl describe replicasets.apps $MY_DEPLOYMENT sí devolverá los eventos relacionados
con el rechazo.
Registro
Como controlador o contenedor de Kubernetes, los pods azure-policy y gatekeeper mantienen registros en el
clúster de Kubernetes. Los registros se pueden exponer en la página Insights (Detalles) del clúster de
Kubernetes. Para obtener más información, vea Supervisión del rendimiento del clúster de Kubernetes con
Azure Monitor para contenedores.
Para ver los registros del complemento, use kubectl :
# Get the azure-policy pod name installed in kube-system namespace

kubectl logs <azure-policy pod name> -n kube-system
# Get the gatekeeper pod name installed in gatekeeper-system namespace

kubectl logs <gatekeeper pod name> -n gatekeeper-system
Para obtener más información, vea Depuración de Gatekeeper en la documentación de Gatekeeper.
Solución de problemas del complemento

Para más información acerca de cómo solucionar los problemas del complemento de Kubernetes, consulte la
sección Kubernetes en el artículo de solución de problemas de Azure Policy.
Eliminar el complemento
Eliminación del complemento de AKS
Para eliminar el complemento de Azure Policy del clúster de AKS, use Azure Portal o la CLI de Azure:
Azure portal
1. Inicie el servicio AKS en Azure Portal al seleccionar Todos los ser vicios ; a continuación, busque y
seleccione Ser vicios de Kubernetes .
2. Seleccione el clúster de AKS en el que quiera deshabilitar el complemento de Azure Policy.
3. Seleccione Directivas en el lado izquierdo de la página de servicio de Kubernetes.
4. En la página principal, pulse Disable add-on (Deshabilitar complemento).
Azure CLI
az aks disable-addons --addons azure-policy --name MyAKSCluster --resource-group MyResourceGroup
Eliminación del complemento desde Kubernetes habilitado para Azure Arc

Para quitar el complemento de Azure Policy y Gatekeeper desde el clúster de Kubernetes habilitado para Azure
Arc, ejecute el siguiente comando de Helm:
helm uninstall azure-policy-addon
Eliminación del complemento desde AKS Engine

Para quitar el complemento de Azure Policy y Gatekeeper del clúster de AKS Engine, use el método en línea con
la manera en que se ha instalado el complemento:
Si se ha instalado definiendo la propiedad addons en la definición del clúster para AKS Engine:
Vuelva a implementar la definición del clúster en AKS Engine después de cambiar la propiedad addons
de azure-policy a false:
"addons": [{
"name": "azure-policy",
"enabled": false
}]
Para obtener más información, vea AKS Engine: deshabilitación del complemento de Azure Policy.
Si se ha instalado con gráficos de Helm, ejecute el siguiente comando de Helm:
helm uninstall azure-policy-addon
Datos de diagnóstico recopilados por el complemento de Azure

Policy
El complemento de Azure Policy para Kubernetes recopila datos de diagnóstico de clúster limitados. Estos datos
de diagnóstico son datos técnicos esenciales relacionados con el software y el rendimiento. Se utiliza para lo
siguiente:
Mantener actualizado el complemento de Azure Policy
Mantener la seguridad, la confiabilidad y el rendimiento del complemento de Azure Policy
Mejorar el complemento de Azure Policy mediante el análisis agregado del uso del complemento
La información recopilada por el complemento no son datos personales. Actualmente se recopilan los detalles
siguientes:
Versión del agente del complemento de Azure Policy
Tipo de clúster
Región del clúster
Grupo de recursos del clúster
Identificador de recurso del clúster
Identificador de suscripción del clúster
Sistema operativo del clúster (ejemplo: Linux)
Ciudad del clúster (ejemplo: Seattle)
Estado o provincia del clúster (ejemplo: Washington)
País o región del clúster (ejemplo: Estados Unidos)
Excepciones o errores encontrados por el complemento de Azure Policy durante la instalación del agente en
la evaluación de directiva
Número de definiciones de directiva de Gatekeeper no instaladas por el complemento de Azure Policy
Pasos siguientes
Puede consultar ejemplos en Ejemplos de Azure Policy.
Vea la Estructura de definición de Azure Policy.
Vea la Descripción de los efectos de directivas.
Obtenga información acerca de cómo se pueden crear directivas mediante programación.
Obtenga información sobre cómo obtener datos de cumplimiento.
Obtenga información sobre cómo corregir recursos no compatibles.
En Organización de los recursos con grupos de administración de Azure, obtendrá información sobre lo que
es un grupo de administración.
Actualización o modificación de las credenciales de
un clúster de Azure Kubernetes Service (AKS)
Los clústeres de AKS creados con una entidad de servicio tiene un período de expiración de un año. A medida
que se aproxima a la fecha de expiración, puede restablecer las credenciales para ampliar la entidad de servicio
durante un período de tiempo adicional. También puede actualizar o rotar las credenciales como parte de una
directiva de seguridad definida. En este artículo se describe cómo actualizar estas credenciales para un clúster
de AKS.
Es posible que también haya integrado el clúster de AKS con Azure Active Directory y que lo utilice como
proveedor de autenticación del clúster. En ese caso, tendrá dos identidades más creadas para el clúster: la
aplicación de servidor de AAD y la aplicación cliente de AAD, y también puede restablecer esas credenciales.
También puede usar una identidad administrada para los permisos en lugar de una entidad de servicio. Las
identidades administradas son más fáciles de administrar que las entidades de servicio y no requieren
actualizaciones ni rotaciones. Para más información, consulte Uso de identidades administradas.
Antes de empezar
Azure.
Actualización o creación de una entidad de servicio nueva para el

clúster de AKS
Cuando quiera actualizar las credenciales de un clúster de AKS, puede hacer alguna de las acciones siguientes:
Actualizar las credenciales de la entidad de servicio existente.
Crear a una entidad de servicio y actualizar el clúster para usar estas nuevas credenciales.
WARNING
Si decide crear una entidad de servicio nueva, espere unos 30 minutos para que el permiso de la entidad de servicio se
propague por todas las regiones. La actualización de un clúster de AKS de gran tamaño para usar estas credenciales
puede tardar mucho en completarse.
Comprobación de la fecha de expiración de la entidad de servicio

Para comprobar la fecha de expiración de la entidad de servicio, use el comando az ad sp credential list. En el
ejemplo siguiente se obtiene el identificador de la entidad de servicio del clúster llamado myAKSCluster del
grupo de recursos myResourceGroup mediante el comando az aks show. El identificador de la entidad de
servicio se establece como una variable llamada SP_ID para su uso con el comando az ad sp credential list.
SP_ID=$(az aks show --resource-group myResourceGroup --name myAKSCluster \

--query servicePrincipalProfile.clientId -o tsv)
az ad sp credential list --id $SP_ID --query "[].endDate" -o tsv
Restablecimiento de las credenciales de una entidad de servicio existente

Para actualizar las credenciales de la entidad de servicio existente, obtenga el identificador de entidad de
servicio del clúster mediante el comando az aks show. En el ejemplo siguiente se obtiene el id. del clúster
denominado myAKSCluster en el grupo de recursos myResourceGroup. El identificador de la entidad de servicio
se establece como una variable denominada SP_ID para usarlo en un comando adicional. Estos comandos usan
la sintaxis de Bash.
WARNING
Al restablecer las credenciales del clúster en un clúster de AKS que usa Azure Virtual Machine Scale Sets, se realiza una
actualización de la imagen del nodo para actualizar los nodos con la nueva información de credenciales.
SP_ID=$(az aks show --resource-group myResourceGroup --name myAKSCluster \

--query servicePrincipalProfile.clientId -o tsv)
Con un conjunto de variables que contiene el id. de entidad de servicio, debe restablecer las credenciales
mediante az ad sp credential reset. En el ejemplo siguiente se permite a la plataforma Azure generar un nuevo
secreto seguro para la entidad de servicio. Este nuevo secreto seguro también se almacena como una variable.
SP_SECRET=$(az ad sp credential reset --name $SP_ID --query password -o tsv)
Ahora, vaya a la sección Actualización del clúster de AKS con nuevas credenciales de la entidad de servicio. Este
paso es necesario para que los cambios de la entidad de servicio se reflejen en el clúster de AKS.
Si decidió actualizar las credenciales de la entidad de servicio existente en la sección anterior, omita este paso.
Vaya a la sección Actualización del clúster de AKS con nuevas credenciales de la entidad de servicio.
Para crear una entidad de servicio y actualizar el clúster de AKS para usar estas nuevas credenciales, use el
comando az ad sp create-for-rbac. En el ejemplo siguiente, el parámetro --skip-assignment impide la
asignación de asignaciones predeterminadas adicionales:
La salida será similar al del ejemplo siguiente: Tome nota de sus valores appId y password . Estos valores se
usan en el siguiente paso.
{
"appId": "7d837646-b1f3-443d-874c-fd83c7c739c5",
"name": "7d837646-b1f3-443d-874c-fd83c7c739c",
"password": "a5ce83c9-9186-426d-9183-614597c7f2f7",
"tenant": "a4342dc8-cd0e-4742-a467-3129c469d0e5"
}
A continuación, defina las variables del identificador de la entidad de servicio y el secreto de cliente; para ello,
use el resultado del comando az ad sp create-for-rbac, tal como se muestra en el ejemplo siguiente. El valor de
SP_ID es su id. de aplicación y el valor de SP_SECRET es su contraseña:
SP_ID=7d837646-b1f3-443d-874c-fd83c7c739c5
SP_SECRET=a5ce83c9-9186-426d-9183-614597c7f2f7
Ahora, vaya a la sección Actualización del clúster de AKS con nuevas credenciales de la entidad de servicio. Este
paso es necesario para que los cambios de la entidad de servicio se reflejen en el clúster de AKS.
Actualización del clúster de AKS con nuevas credenciales de la
entidad de servicio
IMPORTANT
En el caso de los clústeres de gran tamaño, la actualización del clúster de AKS con una entidad de servicio nueva puede
tardar mucho tiempo en completarse.
Independientemente de si decide actualizar las credenciales de la entidad de servicio existente o de si crea una
entidad de servicio, debe actualizar de nuevo el clúster de AKS con sus credenciales mediante el comando az aks
update-credentials. Las variables para los valores de --service-principal y --client-secret se usan de la siguiente
manera:
az aks update-credentials \
--reset-service-principal \
--client-secret $SP_SECRET
En el caso de clústeres pequeños y medianos, las credenciales de la entidad de servicio tardan unos minutos en
actualizarse en AKS.
Actualización del clúster de AKS con nuevas credenciales de la

aplicación AAD
Puede crear una nueva aplicación cliente y una nueva aplicación de servidor de AAD siguiendo los pasos para
integrar AAD. También puede restablecer las aplicaciones de AAD existentes siguiendo el mismo método que
para restablecer la entidad de servicio. Una vez hecho esto, solo tendrá que actualizar las credenciales de la
aplicación AAD utilizando el mismo comando az aks update-credentials, pero con las variables --reset-aad.
az aks update-credentials \
--reset-aad \
--aad-server-app-id <SERVER APPLICATION ID> \
--aad-server-app-secret <SERVER APPLICATION SECRET> \
--aad-client-app-id <CLIENT APPLICATION ID>
Pasos siguientes
En este artículo, lo que se ha actualizado es la propia entidad de servicio del clúster de AKS y las propias
aplicaciones de integración de AAD. Para más información sobre cómo administrar la identidad de las cargas de
trabajo de un clúster, consulte los procedimientos recomendados para la autenticación y autorización en AKS.
Integración de Azure Active Directory administrado
por AKS
La integración de Azure AD administrado por AKS está diseñada para simplificar la experiencia de integración de
Azure AD, donde los usuarios debían crear una aplicación cliente y otra de servidor, y donde el inquilino de
Azure AD debía conceder permisos de lectura para Active Directory. En la nueva versión, el proveedor de
recursos de AKS administra las aplicaciones de cliente y servidor.
Introducción a la autenticación de Azure AD

Los administradores de clústeres pueden configurar el control de acceso basado en rol de Kubernetes (RBAC de
Kubernetes) en función de la identidad de un usuario o la pertenencia a grupos de directorios. La autenticación
de Azure AD se proporciona a los clústeres de AKS con OpenID Connect. OpenID Connect es una capa de
identidad creada basándose en el protocolo OAuth 2.0. Puede encontrar más información sobre OpenID
Connect en la documentación de OpenID Connect.
Obtenga más información sobre el flujo de integración de Azure AD en la documentación de los conceptos de la
integración de Azure Active Directory.
Limitaciones
No se puede deshabilitar la integración de Azure AD administrados por AKS.
No se admite cambiar un clúster integrado de Azure AD administrado por AKS por AAD heredado
Los clústeres habilitados para RBAC que no son de Kubernetes no se admiten para la integración de
Azure AD administrado por AKS.
No se admite el cambio del inquilino de Azure AD asociado a la integración de Azure AD administrado por
AKS.
Requisitos previos
Kubectl con la versión 1.18.1, como mínimo, o kubelogin
Si usa helm, versión mínima de helm 3.3.
IMPORTANT
Debe usar Kubectl con la versión 1.18.1, como mínimo, o kubelogin. La diferencia entre las versiones secundarias de
Kubernetes y kubectl no debe ser superior a una versión. Si no usa la versión correcta, observará problemas de
autenticación.
Para instalar kubectl y kubelogin, use los siguientes comandos:
sudo az aks install-cli

kubectl version --client
kubelogin --version
Siga estas instrucciones para otros sistemas operativos.

Antes de empezar
Para el clúster, necesita un grupo de Azure AD. Este grupo es necesario como grupo de administradores para
que el clúster conceda permisos de administrador de clústeres. Puede usar un grupo de Azure AD existente o
crear uno nuevo. Anote el identificador de objeto del grupo de Azure AD.
# List existing groups in the directory

az ad group list --filter "displayname eq '<group-name>'" -o table
Para crear un grupo de Azure AD para los administradores de clúster, use el comando siguiente:
# Create an Azure AD group

az ad group create --display-name myAKSAdminGroup --mail-nickname myAKSAdminGroup
Creación de un clúster de AKS con Azure AD habilitado

Cree un clúster de AKS con los comandos de la CLI siguientes.

az group create --name myResourceGroup --location centralus
Cree un clúster de AKS y habilite el acceso de administración para el grupo de Azure AD

az aks create -g myResourceGroup -n myManagedCluster --enable-aad --aad-admin-group-object-ids <id> [--aad-
tenant-id <id>]
Un clúster de Azure AD administrado por AKS creado correctamente contiene la sección siguiente en el cuerpo
de la respuesta
"AADProfile": {
"adminGroupObjectIds": [
"5d24****-****-****-****-****afa27aed"
],
"clientAppId": null,
"managed": true,
"serverAppId": null,
"serverAppSecret": null,
"tenantId": "72f9****-****-****-****-****d011db47"
}
Una vez creado el clúster, puede empezar a acceder a él.
Acceso a un clúster habilitado para Azure AD

Necesitará el rol integrado del usuario del clúster de Azure Kubernetes Service para realizar los pasos
siguientes.
Obtenga las credenciales de usuario para acceder al clúster:

Siga las instrucciones para iniciar sesión.
Use el comando "kubectl get nodes" para ver los nodos del clúster:
kubectl get nodes

aks-nodepool1-15306047-0 Ready agent 102m v1.15.10
Configure el control de acceso basado en rol de Azure (RBAC) para configurar grupos de seguridad adicionales
para los clústeres.
Solución de problemas de acceso con Azure AD

IMPORTANT
En los pasos que se describen a continuación se omite la autenticación de grupo de Azure AD normal. Úselos únicamente
en caso de emergencia.
Si está bloqueado permanentemente al no tener acceso a un grupo de Azure AD válido con acceso al clúster, de
todos modos puede obtener las credenciales de administrador para acceder directamente al clúster.
Para llevar a cabo estos pasos, necesitará tener acceso al rol integrado Administrador de clúster de Azure
Kubernetes Service.
az aks get-credentials --resource-group myResourceGroup --name myManagedCluster --admin
Habilitación de la integración de Azure AD administrados por AKS en

el clúster existente
Puede habilitar la integración de Azure AD administrado por AKS en el clúster habilitado para RBAC de
Kubernetes existente. Asegúrese de establecer el grupo de administradores para mantener el acceso al clúster.
az aks update -g MyResourceGroup -n MyManagedCluster --enable-aad --aad-admin-group-object-ids <id-1> [--

aad-tenant-id <id>]
Una activación correcta de un clúster de Azure AD administrado por AKS contiene la sección siguiente en el
cuerpo de la respuesta:
"AADProfile": {
"5d24****-****-****-****-****afa27aed"
],
"managed": true,
"tenantId": "72f9****-****-****-****-****d011db47"
}
Vuelva a descargar las credenciales de usuario para acceder al clúster; para ello, siga los pasos que se indican
aquí.
Actualización a la integración de Azure AD administrado por AKS
Si el clúster usa la integración de Azure AD heredada, puede actualizar a la integración de Azure AD
administrado por AKS.
az aks update -g myResourceGroup -n myManagedCluster --enable-aad --aad-admin-group-object-ids <id> [--aad-

tenant-id <id>]
Una migración correcta de un clúster de Azure AD administrado por AKS contiene la sección siguiente en el
cuerpo de la respuesta:
"AADProfile": {
"5d24****-****-****-****-****afa27aed"
],
"managed": true,
"tenantId": "72f9****-****-****-****-****d011db47"
}
Si quiere acceder al clúster, siga los pasos que se indican aquí.
Inicio de sesión no interactivo con kubelogin

Hay algunos escenarios no interactivos, como las canalizaciones de integración continua, que no están
disponibles actualmente con kubectl. Puede usar kubelogin para acceder al clúster con el inicio de sesión no
interactivo de la entidad de servicio.
Uso de acceso condicional con Azure AD y AKS

Al integrar Azure AD con el clúster de AKS, también puede usar el acceso condicional para controlar el acceso al
clúster.
NOTE
El acceso condicional de Azure AD es una capacidad de Azure AD Premium.
Para crear una directiva de acceso condicional de ejemplo para usarla con AKS, complete los siguientes pasos:
1. En la parte superior de Azure Portal, busque y seleccione Azure Active Directory.
2. En el menú de Azure Active Directory del lado izquierdo, seleccione Aplicaciones empresariales.
3. En el menú de aplicaciones empresariales del lado izquierdo, seleccione Acceso condicional.
4. En el menú de acceso condicional del lado izquierdo, seleccione Directivas y después Nueva directiva.
5. Escriba un nombre para la directiva, como aks-policy.
6. Haga clic en Usuarios y grupos y, luego, debajo de Incluir seleccione Seleccionar usuarios y grupos. Elija los
usuarios y grupos en los que quiere aplicar la directiva. En este ejemplo, elija el mismo grupo de Azure AD
que tiene acceso de administración al clúster.
7. Seleccione Aplicaciones en la nube o acciones y, después, debajo de Incluir, escoja Seleccionar aplicaciones.
Busque Azure Kubernetes Service y seleccione Azure Kubernetes Service AAD Server.
8. En Controles de acceso, seleccione Conceder. Seleccione Conceder acceso y después Requerir que el
dispositivo esté marcado como compatible.
9. En Habilitar directiva, seleccione Activar y, después, Crear.
Obtenga las credenciales de usuario para acceder al clúster, por ejemplo:
Siga las instrucciones para iniciar sesión.

Use el comando kubectl get nodes para ver los nodos del clúster:
kubectl get nodes
Siga las instrucciones para iniciar sesión de nuevo. Observe que hay un mensaje de error que indica que inició
sesión correctamente, pero el administrador requiere que el dispositivo que solicita acceso esté administrado
por su instancia de Azure AD para acceder al recurso.
En Azure Portal, vaya a Azure Active Directory, seleccione Aplicaciones empresariales y, después, en Actividad
seleccione Inicios de sesión. Observe que hay una entrada en la parte superior con un valor de Estado de Error y
un Acceso condicional Correcto. Seleccione la entrada y, a continuación, seleccione Acceso condicional en
Detalles. Observe que se muestra su directiva de acceso condicional.
Configuración del acceso Just-In-Time al clúster con Azure AD y AKS

Otra opción para el control de acceso al clúster es usar Privileged Identity Management (PIM) con las solicitudes
Just-in-Time.
NOTE
PIM es una funcionalidad de Azure AD Premium que requiere una SKU P2 prémium. Para más información sobre las SKU
de Azure AD, consulte la guía de precios.
Para integrar las solicitudes de acceso Just-in-Time con un clúster de AKS mediante la integración de Azure AD
administrado por AKS, complete los pasos siguientes:
1. En la parte superior de Azure Portal, busque y seleccione Azure Active Directory.
2. Tome nota del identificador de inquilino, al que se hace referencia en el resto de estas instrucciones como
<tenant-id>
3. En Administrar, en el menú de Azure Active Directory de la parte izquierda, seleccione Grupos y haga clic en
Nuevo grupo.
4. Asegúrese de que está seleccionado un tipo de grupo de Seguridad y especifique un nombre de grupo, como
myJITGroup. En Azure AD Roles can be assigned to this group (Preview) (Se pueden asignar roles de
Azure AD a este grupo [versión preliminar]), seleccione Sí. Por último, seleccione Crear.
5. Se le redirigirá a la página Grupos. Seleccione el grupo recién creado y tome nota del identificador de objeto,
al que se hace referencia en el resto de estas instrucciones como <object-id> .
6. Implemente un clúster de AKS con la integración de Azure AD administrado por AKS mediante los valores
<tenant-id> y <object-id> de antes:
az aks create -g myResourceGroup -n myManagedCluster --enable-aad --aad-admin-group-object-ids

<object-id> --aad-tenant-id <tenant-id>
7. De nuevo en Azure Portal, en el menú de Actividad situado a la izquierda seleccione Privileged Access
(Preview) (Acceso con privilegios [versión preliminar]) y elija Enable Privileged Access (Habilitar acceso con
privilegios).
8. Seleccione Agregar asignaciones para empezar a conceder acceso.
9. Seleccione un rol de miembro y elija los usuarios y grupos a los que desea conceder el acceso al clúster. Los
administradores de grupos pueden modificar estas asignaciones en cualquier momento. Elija Siguiente
cuando esté listo para continuar.
10. Elija un tipo de asignación Activa, la duración deseada y especifique una justificación. Cuando esté listo para
continuar, seleccione Asignar. Para más información sobre los tipos de asignación, consulte Asignación de la
elegibilidad para un grupo de acceso con privilegios (versión preliminar) en Privileged Identity Management.
Una vez que se han realizado las asignaciones, compruebe que el acceso Just-in-Time funciona mediante el
acceso al clúster. Por ejemplo:

Siga los pasos para iniciar sesión.
Use el comando kubectl get nodes para ver los nodos del clúster:
kubectl get nodes
Tenga en cuenta el requisito de autenticación y siga los pasos para autenticarse. Si todo se ha hecho
correctamente, debería ver un resultado similar al siguiente:
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code
AAAAAAAAA to authenticate.
Si kubectl get nodes devuelve un error parecido al siguiente:
Error from server (Forbidden): nodes is forbidden: User "aaaa11111-11aa-aa11-a1a1-111111aaaaa" cannot list
resource "nodes" in API group "" at the cluster scope
Asegúrese de que el administrador del grupo de seguridad haya dado a su cuenta una asignación Activa.
Pasos siguientes
Obtenga más información sobre la integración de Azure RBAC para la autorización de Kubernetes.
Aprenda sobre la integración de Azure AD con RBAC de Kubernetes.
Use kubelogin para obtener acceso a las características de autenticación de Azure que no están disponibles
en kubectl.
Obtenga más información sobre los conceptos de identidad de Kubernetes y AKS.
Use las plantillas de Azure Resource Manager (ARM) para crear clústeres habilitados para Azure AD
administrado por AKS.
Integración de Azure Active Directory con Azure
Kubernetes Service mediante la CLI de Azure
(heredado)
Es posible configurar Azure Kubernetes Service (AKS) para que utilice Azure Active Directory (AD) para la
autenticación de usuarios. En esta configuración, puede iniciar sesión en un clúster de AKS mediante un token
de autenticación de Azure AD. Los operadores del clúster también pueden configurar el control de acceso
basado en roles de Kubernetes (RBAC de Kubernetes) en función de la identidad de los usuarios o su
pertenencia a un grupo del directorio.
En este artículo se muestra cómo crear los componentes necesarios de Azure AD y, luego, implementar un
clúster habilitado para Azure AD y crear un rol básico de Kubernetes en el clúster de AKS.
Para obtener el script de ejemplo completo que se usa en este artículo, consulte Ejemplos de la CLI de Azure:
integración de AKS con Azure AD.
IMPORTANT
AKS tiene una nueva experiencia mejorada de Azure AD administrado por AKS que no requiere que administre la
aplicación cliente o de servidor. Si desea migrar, siga las instrucciones aquí.
Se aplican las siguientes limitaciones:

Azure AD solo puede habilitarse en el clúster habilitado para Kubernetes.
El servicio de integración heredado de Azure AD solo se puede habilitar durante la creación del clúster.
Antes de empezar
Vaya a https://shell.azure.com para abrir Cloud Shell en el explorador.

Para mantener la coherencia y ayudar a ejecutar los comandos en este artículo, cree una variable para el
nombre que quiera del clúster de AKS. En el ejemplo siguiente se usa el nombre myakscluster:
aksname="myakscluster"
Introducción a la autenticación de Azure AD

La autenticación de Azure AD se proporciona a los clústeres de AKS con OpenID Connect. OpenID Connect es
una capa de identidad creada basándose en el protocolo OAuth 2.0. Puede encontrar más información sobre
OpenID Connect en la documentación de OpenID Connect.
Dentro del clúster de Kubernetes, se usa la autenticación de token de webhook para verificar los tokens de
autenticación. La autenticación de token de webhook se configura y administra como parte del clúster de AKS.
Puede encontrar más información sobre la autenticación de token de Webhook en la documentación de
autenticación de webhook.
NOTE
Al configurar Azure AD para la autenticación de AKS, se configuran dos aplicaciones de Azure AD. Un administrador del
inquilino de Azure debe realizar esta operación.
Creación del componente de servidor de Azure AD

Para integrar con AKS, cree y use una aplicación de Azure AD que sirva de punto de conexión para las solicitudes
de identidad. La primera aplicación de Azure AD que se necesita obtiene la pertenencia a un grupo de Azure AD
de un usuario.
Cree el componente de aplicación de servidor mediante el comando az ad app create y, a continuación, actualice
las notificaciones de pertenencia a grupo mediante el comando az ad app update. En el ejemplo siguiente se usa
la variable aksname definida en la sección Antes de comenzar y se crea una variable.
# Create the Azure AD application

serverApplicationId=$(az ad app create \
--display-name "${aksname}Server" \
--identifier-uris "https://${aksname}Server" \
--query appId -o tsv)
# Update the application group membership claims

az ad app update --id $serverApplicationId --set groupMembershipClaims=All
Ahora, cree una entidad de servicio para la aplicación de servidor mediante el comando az ad sp create. Esta
entidad de servicio se usa para autenticarse en la plataforma Azure. A continuación, obtenga el secreto de la
entidad de servicio con el comando az ad sp credential reset y asígnelo a la variable llamada
serverApplicationSecret para su uso en uno de los pasos siguientes:
# Create a service principal for the Azure AD application

az ad sp create --id $serverApplicationId
# Get the service principal secret

serverApplicationSecret=$(az ad sp credential reset \
--name $serverApplicationId \
--credential-description "AKSPassword" \
--query password -o tsv)
La entidad de servicio de Azure AD necesita permisos para realizar las siguientes acciones:
Leer datos de directorio
Iniciar sesión y leer el perfil de usuario
Asigne estos permisos con el comando az ad app permission add:
az ad app permission add \

--id $serverApplicationId \
--api 00000003-0000-0000-c000-000000000000 \
--api-permissions e1fe6dd8-ba31-4d61-89e7-88639da4683d=Scope 06da0dbc-49e2-44d2-8312-53f166ab848a=Scope
7ab1d382-f21e-4acd-a863-ba3e13f7da61=Role
Por último, conceda los permisos asignados en el paso anterior para la aplicación de servidor con el comando az
ad app permission grant. Se producirá un error en este paso si la cuenta actual no es un administrador del
inquilino. También tendrá que agregar permisos para que la aplicación de Azure AD solicite información que, de
lo contrario, podría requerir consentimiento administrativo mediante el comando az ad app permission admin-
consent:
az ad app permission grant --id $serverApplicationId --api 00000003-0000-0000-c000-000000000000

az ad app permission admin-consent --id $serverApplicationId
Creación del componente de cliente de Azure AD

La segunda aplicación de Azure AD se usa cuando un usuario inicia sesión en el clúster de AKS con la CLI de
Kubernetes ( kubectl ). Esta aplicación cliente toma la solicitud de autenticación del usuario y comprueba sus
credenciales y permisos. Cree la aplicación de Azure AD para el componente de cliente mediante el comando az
ad app create:
clientApplicationId=$(az ad app create \

--display-name "${aksname}Client" \
--native-app \
--reply-urls "https://${aksname}Client" \
--query appId -o tsv)
Cree una entidad de servicio para la aplicación cliente mediante el comando az ad sp create:
az ad sp create --id $clientApplicationId
Obtenga el id. de oAuth2 para la aplicación de servidor con el fin de permitir el flujo de autenticación entre los
dos componentes de las aplicaciones mediante el comando az ad app show. Este id. de oAuth2 se usa en el paso
siguiente.
oAuthPermissionId=$(az ad app show --id $serverApplicationId --query "oauth2Permissions[0].id" -o tsv)
Agregue los permisos para los componentes de la aplicación cliente y la aplicación de servidor con el fin de usar
el flujo de comunicación de oAuth2 mediante el comando az ad app permission add. A continuación, conceda
permisos para que la aplicación cliente se comunique con la aplicación de servidor mediante el comando az ad
app permission grant:
az ad app permission add --id $clientApplicationId --api $serverApplicationId --api-permissions

${oAuthPermissionId}=Scope
az ad app permission grant --id $clientApplicationId --api $serverApplicationId
Implementación del clúster

Con las dos aplicaciones de Azure AD creadas, cree ahora el propio clúster de AKS. En primer lugar, cree un
grupo de recursos con el comando az group create. En el ejemplo siguiente se crea un grupo de recursos en la
región EastUS :
Cree un grupo de recursos para el clúster:
az group create --name myResourceGroup --location EastUS
Obtenga el identificador de inquilino de la suscripción de Azure mediante el comando az account show.

Después, cree el clúster de AKS con el comando az aks create. El comando para crear el clúster de AKS
proporciona los identificadores de servidor y aplicación cliente, el secreto de entidad de servicio de la aplicación
de servidor y el identificador de inquilino:
tenantId=$(az account show --query tenantId -o tsv)
az aks create \
--name $aksname \
--node-count 1 \
--aad-server-app-id $serverApplicationId \
--aad-server-app-secret $serverApplicationSecret \
--aad-client-app-id $clientApplicationId \
--aad-tenant-id $tenantId
Por último, obtenga las credenciales de administrador del clúster mediante el comando az aks get-credentials.
En uno de los pasos siguientes se obtendrán las credenciales del clúster del usuario normal para ver el flujo de
autenticación de Azure AD en acción.
az aks get-credentials --resource-group myResourceGroup --name $aksname --admin
Creación de un enlace RBAC de Kubernetes

Para poder usar una cuenta de Azure Active Directory con el clúster AKS, debe crear un enlace de rol o un enlace
de rol del clúster. Roles define los permisos para conceder, y enlaces los aplica a los usuarios deseados. Estas
asignaciones se pueden aplicar a un espacio de nombres especificado o a todo el clúster. Para obtener más
información, consulte Uso de la autorización de RBAC de Kubernetes.
Obtenga el nombre principal de usuario (UPN) para el usuario con sesión iniciada actualmente mediante el
comando az ad signed-in-user show. Esta cuenta de usuario está habilitada para la integración de Azure AD en
el paso siguiente.
az ad signed-in-user show --query userPrincipalName -o tsv
IMPORTANT
Si el usuario al que concede el enlace de RBAC de Kubernetes se encuentra en el mismo inquilino de Azure AD, asigne
permisos según userPrincipalName. Si el usuario se encuentra en un inquilino distinto de Azure AD, en su lugar, consulte y
use la propiedad objectId.
Cree un manifiesto de YAML llamado basic-azure-ad-binding.yaml y pegue el siguiente contenido. En la última

línea, reemplace userPrincipalName_or_objectId por la salida del id. de objeto o de UPN del comando anterior:
kind: ClusterRoleBinding
metadata:
name: contoso-cluster-admins
roleRef:
kind: ClusterRole
name: cluster-admin
subjects:
kind: User
name: userPrincipalName_or_objectId
Cree ClusterRoleBinding mediante el comando kubectl apply y especifique el nombre de archivo del manifiesto
de YAML:
kubectl apply -f basic-azure-ad-binding.yaml
Acceso al clúster con Azure AD

Ahora vamos a probar la integración de la autenticación de Azure AD para el clúster de AKS. Establezca el
contexto de configuración kubectl para usar las credenciales de usuario normal. Este contexto devuelve todas
las solicitudes de autenticación a través de Azure AD.
az aks get-credentials --resource-group myResourceGroup --name $aksname --overwrite-existing
Ahora use el comando kubectl get pods para ver los pods en los espacios de nombres:
kubectl get pods --all-namespaces
Recibirá un símbolo del sistema de inicio de sesión para autenticarse con las credenciales de Azure AD mediante
un explorador web. Una vez se haya autenticado correctamente, el comando kubectl muestra los pods del
clúster de AKS, tal como se muestra en la salida del ejemplo siguiente:
BYMK7UXVD to authenticate.
NAMESPACE NAME READY STATUS RESTARTS AGE

kube-system coredns-754f947b4-2v75r 1/1 Running 0 23h
kube-system coredns-754f947b4-tghwh 1/1 Running 0 23h
kube-system coredns-autoscaler-6fcdb7d64-4wkvp 1/1 Running 0 23h
kube-system heapster-5fb7488d97-t5wzk 2/2 Running 0 23h
kube-system kube-proxy-2nd5m 1/1 Running 0 23h
kube-system kube-svc-redirect-swp9r 2/2 Running 0 23h
kube-system kubernetes-dashboard-847bb4ddc6-trt7m 1/1 Running 0 23h
kube-system metrics-server-7b97f9cd9-btxzz 1/1 Running 0 23h
kube-system tunnelfront-6ff887cffb-xkfmq 1/1 Running 0 23h
El token de autenticación recibido para kubectl se almacena en caché. Solo se le solicita de nuevo iniciar sesión
cuando el token ha expirado o el archivo de configuración de Kubernetes se vuelve a crear.
Si ve un mensaje de error de autorización una vez se haya registrado correctamente en un explorador web, tal
como se muestra en la salida del ejemplo siguiente, compruebe las siguientes incidencias posibles:
error: You must be logged in to the server (Unauthorized)
Se ha definido el identificador o UPN del objeto adecuado, en función de si la cuenta de usuario está en el
mismo inquilino de Azure AD o no.
El usuario no es miembro de más de 200 grupos.
El secreto definido en el registro de aplicación del servidor coincide con el valor configurado mediante
--aad-server-app-secret
Pasos siguientes
Para obtener el script completo que contiene los comandos que se muestran en este artículo, consulte el
repositorio de ejemplos de script de integración de Azure AD en AKS.
Para usar los usuarios y grupos de Azure AD con el fin de controlar el acceso a los recursos de clúster, consulte
Control del acceso a recursos de clúster mediante el control de acceso basado en rol de Kubernetes y las
identidades de Azure AD en AKS.
Para obtener más información sobre cómo proteger los clústeres de Kubernetes, consulte Opciones de acceso e
identificación para AKS.
Para ver procedimientos recomendados sobre el control de recursos e identidades, consulte Procedimientos
recomendados para la autenticación y autorización en AKS.
Uso de Azure RBAC para la autorización de
Kubernetes (versión preliminar)
En la actualidad, ya puede aprovechar la autenticación integrada entre Azure Active Directory (Azure AD) y AKS.
Cuando está habilitada, esta integración permite a los clientes usar usuarios, grupos o entidades de servicio de
Azure AD como asuntos en RBAC de Kubernetes, más información aquí. Esta característica evita tener que
administrar por separado las identidades de usuario y las credenciales de Kubernetes. Sin embargo, todavía
tiene que configurar y administrar Azure RBAC y Kubernetes por separado. Para más información sobre la
autenticación y la autorización con RBAC en AKS, haga clic aquí.
En este documento se describe un nuevo enfoque que permite la administración unificada y el control de acceso
en los recursos de Azure, AKS y Kubernetes.
Antes de empezar
La capacidad de administrar RBAC para los recursos de Kubernetes de Azure le ofrece la opción de administrar
RBAC para los recursos del clúster mediante mecanismos de Kubernetes nativos o de Azure. Cuando está
habilitada, las entidades de seguridad de Azure AD se validarán exclusivamente con Azure RBAC, mientras que
las cuentas de servicio y los usuarios de Kubernetes normales se validan exclusivamente mediante el RBAC de
Kubernetes. Para más información sobre la autenticación y autorización con RBAC en AKS, haga clic aquí.
IMPORTANT
Requisitos previos
Asegúrese de que tiene la versión 2.9.0 de la CLI de Azure o una posterior.
Asegúrese de que tiene habilitada la EnableAzureRBACPreview marca de características.
Asegúrese de que tiene instalada la extensión de la CLI aks-preview v 0.4.55 o superior.
Asegúrese de que ha instalado kubectl v 1.18.3 +.
Registro de la característica en vista previa (GB) de EnableAzureRBACPreview
A fin de crear un clúster de AKS que use Azure RBAC para la autorización de Kubernetes, debe habilitar la marca
de característica EnableAzureRBACPreview en su suscripción.
Registro de EnableAzureRBACPreview la marca de característica con el comando de característica de registro az,
tal como se muestra en el siguiente ejemplo:
az feature register --namespace "Microsoft.ContainerService" --name "EnableAzureRBACPreview"

Puede comprobar el estado de registro con el comando az feature list:
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/EnableAzureRBACPreview')].


Para crear un clúster de AKS que use un Azure RBAC, necesita la versión 0.4.55 o superior de la extensión de la
CLI aks-preview . Instale la extensión de la CLI de Azure aks-preview con el comando az extension add o instale
las actualizaciones disponibles con el comando az extension update:

Limitaciones
Requiere integración administrada de Azure AD.
No se puede integrar Azure RBAC para la autorización de Kubernetes en clústeres existentes durante la
versión preliminar, pero podrá usar la disponibilidad general (GA).
Use kubectl v1.18.3+.
Si tiene CRDs y está realizando definiciones de roles personalizados, la única manera de abarcar CRDs hoy es
proporcionar Microsoft.ContainerService/managedClusters/*/read . AKS trabaja para proporcionar permisos
más granulares para CRDs. Para el resto de objetos, puede usar los grupos de API específicos, por ejemplo:
Microsoft.ContainerService/apps/deployments/read .
Las nuevas asignaciones de roles pueden tardar hasta 5 minutos en propagarse y actualizarse mediante el
servidor de autorización.
Es necesario que el inquilino de Azure AD configurado para la autenticación sea el mismo que el de la
suscripción que contiene el clúster de AKS.
Crear un nuevo clúster con Azure RBAC y la integración administrada

de Azure AD
Crear un clúster de AKS con los siguientes comandos de la CLI.

Cree el clúster de AKS con la integración administrada de Azure AD y Azure RBAC para la autorización de
Kubernetes.

az aks create -g MyResourceGroup -n MyManagedCluster --enable-aad --enable-azure-rbac
Una creación correcta de un clúster con la integración de Azure AD y Azure RBAC para la autorización de
Kubernetes tiene la siguiente sección en el cuerpo de respuesta:
"AADProfile": {
"adminGroupObjectIds": null,
"enableAzureRbac": true,
"managed": true,
"tenantId": "****-****-****-****-****"
}
Crear asignaciones de roles para que los usuarios accedan al clúster.

AKS proporciona los siguientes cuatro roles integrados:
Lector de RBAC de Azure Kubernetes Service Permite el acceso de solo lectura para ver la mayoría de los
objetos en un espacio de nombres. No permite la
visualización de roles o enlaces de roles. Este rol no permite
visualización Secrets , ya que leer el contenido de los
secretos permite el acceso a las credenciales de
ServiceAccount en el espacio de nombres, que permitiría el
acceso a la API como cualquier ServiceAccount en el espacio
de nombres (una forma de elevación de privilegios).
Escritura de Azure Kubernetes Service RBAC Permite el acceso de lectura y escritura para ver la mayoría
de los objetos en un espacio de nombres. Este rol no
permite la visualización o modificación de roles o enlaces de
roles. Sin embargo, este rol permite acceder a Secrets y
ejecutar pods como cualquier ServiceAccount en el espacio
de nombres, por lo que se puede usar para obtener los
niveles de acceso de la API de cualquier ServiceAccount en el
espacio de nombres.
Administrador de Azure Kubernetes Service RBAC Permite el acceso de administrador, diseñado para su
concesión dentro de un espacio de nombres. Permite el
acceso de lectura y escritura a la mayoría de los recursos de
un espacio de nombres (o ámbito de clúster), incluida la
capacidad de crear roles y enlaces de roles dentro del
espacio de nombres. Este rol no permite el acceso de
escritura a la cuota de recursos o al espacio de nombres en
sí.
Administrador de clúster de Azure Kubernetes Service RBAC Permite el acceso de superusuario para realizar cualquier
acción en cualquier recurso. Proporciona control total sobre
todos los recursos del clúster y en todos los espacios de
nombres.
Las asignaciones de roles que tienen como ámbito el clúster de AKS completo se pueden realizar en la hoja
Access Control (IAM) del recurso de clúster en Azure Portal o mediante comandos de CLI de Azure, como se
muestra a continuación:
# Get your AKS Resource ID

AKS_ID=$(az aks show -g MyResourceGroup -n MyManagedCluster --query id -o tsv)
az role assignment create --role "Azure Kubernetes Service RBAC Admin" --assignee <AAD-ENTITY-ID> --scope
$AKS_ID
donde <AAD-ENTITY-ID> podría ser un nombre de usuario (por ejemplo, user@contoso.com) o incluso el
ClientID de una entidad de servicio.
También puede crear asignaciones de roles en el ámbito de un espacio de nombres específico dentro del
clúster:
az role assignment create --role "Azure Kubernetes Service RBAC Viewer" --assignee <AAD-ENTITY-ID> --scope
$AKS_ID/namespaces/<namespace-name>
En la actualidad, las asignaciones de roles cuyo ámbito son los espacios de nombres deben configurarse
mediante CLI de Azure.
Creación de definición de roles personalizados
Opcionalmente, puede optar por crear su propia definición de rol y, a continuación, asignarla como se indicó
anteriormente.
A continuación se muestra un ejemplo de una definición de roles que permite a un usuario leer solo las
implementaciones y nada más. Puede consultar la lista completa de acciones posibles aquí.
Copie el siguiente JSON en un archivo denominado deploy-view.json .
{
"Name": "AKS Deployment Viewer",
"Description": "Lets you view all deployments in cluster/namespace.",
"Actions": [],
"NotActions": [],
"DataActions": [
"Microsoft.ContainerService/managedClusters/apps/deployments/read"
],
"NotDataActions": [],
"assignableScopes": [
"/subscriptions/<YOUR SUBSCRIPTION ID>"
]
}
Reemplace <YOUR SUBSCRIPTION ID> por el id. de la suscripción, que puede obtener al ejecutar:
az account show --query id -o tsv
Ahora se puede crear la definición de roles al ejecutar el comando siguiente desde la carpeta donde se guardó
deploy-view.json :
az role definition create --role-definition @deploy-view.json
Ahora que tiene la definición de rol, puede asignarla a un usuario u otra identidad mediante la ejecución de:
az role assignment create --role "AKS Deployment Viewer" --assignee <AAD-ENTITY-ID> --scope $AKS_ID
Uso de Azure RBAC para la autorización de Kubernetes con kubectl .

NOTE
Asegúrese de que dispone de la versión más reciente de kubectl al ejecutar el comando siguiente:
az aks install-cli
Es posible que tenga que ejecutarlo con los privilegios de sudo .
Ahora que ha asignado el rol y los permisos deseados. Puede empezar a llamar a la API de Kubernetes, por
ejemplo, desde kubectl .
Para este propósito, primero vamos a obtener el kubeconfig del clúster con el siguiente comando:
az aks get-credentials -g MyResourceGroup -n MyManagedCluster
IMPORTANT
Necesitará el rol integrado del usuario del clúster de Azure Kubernetes Service para realizar el paso anterior.
Ahora puede usar kubectl para, por ejemplo, enumerar los nodos del clúster. La primera vez que la ejecute,
deberá iniciar sesión y los comandos subsiguientes usarán el token de acceso correspondiente.
kubectl get nodes


aks-nodepool1-93451573-vmss000000 Ready agent 3h6m v1.15.11
Uso de Azure RBAC para la autorización de Kubernetes con

kubelogin .
Para desbloquear escenarios adicionales, como los inicios de sesión no interactivos, las versiones de kubectl
anteriores o el uso de SSO en varios clústeres sin necesidad de iniciar sesión en el nuevo clúster, admitiendo que
el token siga siendo válido, AKS creó un complemento exec denominado kubelogin .
Puede usarlo mediante la ejecución de:
export KUBECONFIG=/path/to/kubeconfig
kubelogin convert-kubeconfig
La primera vez, tendrá que iniciar sesión de forma interactiva como con el kubectl regular, pero después ya no
tendrá que hacerlo, incluso para los nuevos clústeres de Azure AD (siempre que el token siga siendo válido).
kubectl get nodes

Limpieza
Limpieza de asignación de roles
az role assignment list --scope $AKS_ID --query [].id -o tsv
Copie el identificador o los identificadores de todas las asignaciones que ha realizado y, a continuación,.
az role assignment delete --ids <LIST OF ASSIGNMENT IDS>
Limpieza de la definición de roles.
az role definition delete -n "AKS Deployment Viewer"
Eliminar clúster y grupo de recursos.
az group delete -n MyResourceGroup
Pasos siguientes
Obtenga más información aquí sobre la autenticación de AKS, la autorización, RBAC de Kubernetes y Azure
RBAC.
Obtenga más información sobre Azure RBAC aquí.
Obtenga más información sobre todas las acciones que puede usar para definir de un modo pormenorizado
roles de Azure personalizados para la autorización de Kubernetes aquí.
Administración del acceso a recursos de clúster
mediante el control de acceso basado en roles de
Kubernetes y las identidades de Azure Active
Directory en Azure Kubernetes Service
Es posible configurar Azure Kubernetes Service (AKS) para que utilice Azure Active Directory (AD) para la
autenticación de usuarios. En esta configuración, inicie sesión en un clúster de AKS mediante un token de
autenticación de Azure AD. También puede configurar el control de acceso basado en roles de Kubernetes (RBAC
de Kubernetes) para limitar el acceso a los recursos de clúster en función de la identidad de los usuarios o su
pertenencia a un grupo.
Este artículo muestra cómo usar la pertenencia a grupos de Azure AD para controlar el acceso a los espacios de
nombres y los recursos de clúster con Kubernetes RBAC en un clúster de AKS. Los usuarios y grupos de ejemplo
se crean en Azure AD y, a continuación, se crean roles y enlaces de roles en el clúster de AKS para conceder los
permisos adecuados para crear y ver los recursos.
Antes de empezar
En este artículo se supone que ya tiene un clúster de AKS habilitado con integración de Azure AD. Si necesita un
clúster de AKS, consulte Integración de Azure Active Directory con AKS.
Creación de grupos de demostración en Azure AD

En este artículo, vamos a crear dos roles de usuario que se pueden usar para mostrar cómo Kubernetes RBAC y
Azure AD controlan el acceso a recursos de clúster. Se usan los siguientes dos roles de ejemplo:
Desarrollador de aplicaciones
Un usuario denominado aksdev que forma parte del grupo appdev.
Ingeniero encargado de garantizar la fiabilidad del sitio (SRE, por sus siglas en inglés)
Un usuario denominado akssre que forma parte del grupo opssre.
En entornos de producción, puede usar usuarios y grupos existentes dentro de un inquilino de Azure AD.
En primer lugar, obtenga el identificador de recurso de clúster de AKS mediante el comando az aks show. Asigne
el Id. de recurso a una variable denominada AKS_ID de manera que pueda hacer referencia a los comandos
adicionales.
AKS_ID=$(az aks show \

--query id -o tsv)
Cree el primer grupo de ejemplo en Azure AD para los desarrolladores de aplicaciones mediante el comando az
ad group create. En el ejemplo siguiente se crea un grupo de recursos denominado appdev:
APPDEV_ID=$(az ad group create --display-name appdev --mail-nickname appdev --query objectId -o tsv)
Ahora, cree una asignación de roles de Azure para el grupo appdev con el comando az role assignment create.
Esta asignación permite que cualquier miembro del grupo pueda usar kubectl para interactuar con un clúster
de AKS a través de la concesión del rol de usuario de clúster de Azure Kubernetes Service.

--assignee $APPDEV_ID \
--role "Azure Kubernetes Service Cluster User Role" \
--scope $AKS_ID
TIP
Si recibe un error como
Principal 35bfec9328bd4d8d9b54dea6dac57b82 does not exist in the directory a5443dcd-cd0e-494d-a387-
3039b419f0d5.
, espere unos segundos para que el id. de objeto del grupo de Azure AD se propague través del directorio. A
continuación, pruebe el comando az role assignment create de nuevo.
Cree un segundo grupo de ejemplo, en este caso para SRE, denominado opssre:
OPSSRE_ID=$(az ad group create --display-name opssre --mail-nickname opssre --query objectId -o tsv)
De nuevo, cree una asignación de rol de Azure para conceder a los miembros del grupo el rol de usuario de
clúster de Azure Kubernetes Service:

--assignee $OPSSRE_ID \
--role "Azure Kubernetes Service Cluster User Role" \
--scope $AKS_ID
Creación de usuarios de demostración en Azure AD

Con dos grupos de ejemplo creados en Azure AD para nuestros desarrolladores de aplicaciones y SRE, ahora
permite crear dos usuarios de ejemplo. Para probar la integración de RBAC de Kubernetes al final del artículo,
inicie sesión en el clúster de AKS con estas cuentas.
Establezca el nombre principal de usuario (UPN) y la contraseña de los desarrolladores de aplicaciones. El
comando siguiente le solicita un UPN y lo establece en AAD_DEV_UPN para su uso en un comando posterior
(recuerde que los comandos de este artículo se incluyen en un shell de BASH). El UPN debe incluir el nombre de
dominio comprobado del inquilino, por ejemplo aksdev@contoso.com .
echo "Please enter the UPN for application developers: " && read AAD_DEV_UPN
El siguiente comando le pide la contraseña y la establece en AAD_DEV_PW para su uso en un comando

posterior.
echo "Please enter the secure password for application developers: " && read AAD_DEV_PW
Cree la primera cuenta de usuario en Azure AD mediante el comando az ad user create.

En el ejemplo siguiente se crea un usuario con el nombre para mostrar AKS Dev y el UPN y la contraseña segura
usando los valores de AAD_DEV_UPN y AAD_DEV_PW:
AKSDEV_ID=$(az ad user create \

--display-name "AKS Dev" \
--user-principal-name $AAD_DEV_UPN \
--password $AAD_DEV_PW \
--query objectId -o tsv)
Ahora agregue el usuario al grupo appdev creado en la sección anterior mediante el comando az ad group
member add:
az ad group member add --group appdev --member-id $AKSDEV_ID
Establezca el UPN y la contraseña de SRE. El comando siguiente le solicita un UPN y lo establece en

AAD_SRE_UPN para su uso en un comando posterior (recuerde que los comandos de este artículo se incluyen
en un shell de BASH). El UPN debe incluir el nombre de dominio comprobado del inquilino, por ejemplo
akssre@contoso.com .
echo "Please enter the UPN for SREs: " && read AAD_SRE_UPN
El siguiente comando le pide la contraseña y la establece en AAD_SRE_PW para su uso en un comando posterior.
echo "Please enter the secure password for SREs: " && read AAD_SRE_PW
Cree una nueva cuenta de usuario. El siguiente ejemplo crea un usuario con el nombre para mostrar AKS SRE y
el UPN y la contraseña segura utilizando los valores de AAD_SRE_UPN y AAD_SRE_PW:
# Create a user for the SRE role

AKSSRE_ID=$(az ad user create \
--display-name "AKS SRE" \
--user-principal-name $AAD_SRE_UPN \
--password $AAD_SRE_PW \
--query objectId -o tsv)
# Add the user to the opssre Azure AD group

az ad group member add --group opssre --member-id $AKSSRE_ID
Creación de los recursos de clúster de AKS para desarrolladores de

aplicaciones
Se han creado los usuarios y grupos de Azure AD. Además, se crearon asignaciones de roles de Azure para que
los miembros del grupo se conecten a un clúster de AKS como un usuario normal. Ahora, vamos a configurar el
clúster de AKS para permitir que estos grupos diferentes puedan obtener acceso a recursos específicos.
Primero, obtenga las credenciales de administrador del clúster mediante el comando az aks get-credentials. En
una de las siguientes secciones, obtendrá las credenciales del clúster del usuario normal para ver el flujo de
autenticación de Azure AD en acción.
Cree un espacio de nombres en el clúster de AKS mediante el comando kubectl create namespace. En el
siguiente ejemplo se crea un nuevo espacio de nombres, dev:
kubectl create namespace dev
En Kubernetes, los roles definen los permisos que conceder los enlaces de roles los aplican a los usuarios o
grupos deseados. Estas asignaciones se pueden aplicar a un espacio de nombres especificado o a todo el clúster.
Para obtener más información, consulte Uso de la autorización de RBAC Kubernetes.
En primer lugar, cree un rol para el espacio de nombres dev. Este rol concede permisos completos al espacio de
nombres. En entornos de producción, puede especificar permisos más granulares para diferentes usuarios o
grupos.
Cree un archivo denominado role-dev-namespace.yaml y pegue el siguiente manifiesto de YAML:
kind: Role
metadata:
name: dev-user-full-access
namespace: dev
rules:
- apiGroups: ["", "extensions", "apps"]
resources: ["*"]
verbs: ["*"]
- apiGroups: ["batch"]
resources:
- jobs
- cronjobs
verbs: ["*"]
Cree el rol mediante el comando kubectl apply y especifique el nombre de archivo del manifiesto de YAML:
kubectl apply -f role-dev-namespace.yaml
A continuación, obtenga el Id. de recurso para el grupo appdev mediante el comando az ad group show. Este
grupo se establece como el sujeto de un enlace de rol en el paso siguiente.
az ad group show --group appdev --query objectId -o tsv
Ahora, cree un enlace de rol para que el grupo appdev use el rol creado anteriormente para el acceso de espacio
de nombres. Cree un archivo denominado rolebinding-dev-namespace.yaml y pegue el siguiente manifiesto de
YAML. En la última línea, reemplace groupObjectId por la salida del id. de objeto de grupo del comando anterior:
kind: RoleBinding
metadata:
name: dev-user-access
namespace: dev
roleRef:
kind: Role
name: dev-user-full-access
subjects:
- kind: Group
namespace: dev
name: groupObjectId
Cree el enlace de roles mediante el comando kubectl apply y especifique el nombre de archivo del manifiesto de
YAML:
kubectl apply -f rolebinding-dev-namespace.yaml
Creación de los recursos de clúster de AKS para SRE

Ahora, repita los pasos anteriores para crear un espacio de nombres, el rol y el enlace de rol para los SRE.
En primer lugar, cree un espacio de nombres para sre con el comando kubectl create namespace:
kubectl create namespace sre
Cree un archivo denominado role-sre-namespace.yaml y pegue el siguiente manifiesto de YAML:
kind: Role
metadata:
name: sre-user-full-access
namespace: sre
rules:
- apiGroups: ["", "extensions", "apps"]
resources: ["*"]
verbs: ["*"]
- apiGroups: ["batch"]
resources:
- jobs
- cronjobs
verbs: ["*"]
Cree el rol mediante el comando kubectl apply y especifique el nombre de archivo del manifiesto de YAML:
kubectl apply -f role-sre-namespace.yaml
Obtenga el identificador de recurso para el grupo opssre mediante el comando az ad group show:
az ad group show --group opssre --query objectId -o tsv
Cree un enlace de rol para que el grupo opssre use el rol creado anteriormente para el acceso de espacio de
nombres. Cree un archivo denominado rolebinding-sre-namespace.yaml y pegue el siguiente manifiesto de
YAML. En la última línea, reemplace groupObjectId por la salida del id. de objeto de grupo del comando anterior:
kind: RoleBinding
metadata:
name: sre-user-access
namespace: sre
roleRef:
kind: Role
name: sre-user-full-access
subjects:
- kind: Group
namespace: sre
name: groupObjectId
Cree el enlace de roles mediante el comando kubectl apply y especifique el nombre de archivo del manifiesto de
YAML:
kubectl apply -f rolebinding-sre-namespace.yaml
Interactuación con recursos de clúster con identidades de Azure AD

Ahora, vamos a probar el trabajo de los permisos esperados cuando se crean y administran recursos en un
clúster de AKS. En estos ejemplos, programe y vea los pods en el espacio de nombres asignados del usuario. A
continuación, intente programar y ver los pods fuera del espacio de nombres asignado.
En primer lugar, restablezca el contexto kubeconfig mediante el comando az aks get-credentials. En una sección
anterior, establezca el contexto con las credenciales de administrador de clúster. El usuario administrador omite
las solicitudes de inicio de sesión de Azure AD. Sin el parámetro --admin , se aplica el contexto de usuario que
requiere que todas las solicitudes se autentiquen mediante Azure AD.
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing
Programación de un pod NGINX básico mediante el comando kubectl run en el espacio de nombres dev:
kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
Cuando se le solicite iniciar sesión, escriba las credenciales de su cuenta appdev@contoso.com personal creada al
principio del artículo. Una vez que se haya iniciado sesión correctamente, el token de la cuenta se almacena en
caché para futuros comandos kubectl . NGINX se programa correctamente, como se muestra en la siguiente
salida de ejemplo:
$ kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
B24ZD6FP8 to authenticate.
pod/nginx-dev created
Ahora use el comando kubectl get pods para ver los pods en el espacio de nombres dev.
kubectl get pods --namespace dev
Como se muestra en la salida del ejemplo siguiente, el pod NGINX se está ejecutando correctamente:
$ kubectl get pods --namespace dev

nginx-dev 1/1 Running 0 4m
Creación y visualización de los recursos de clúster fuera del espacio de nombres asignado
Ahora pruebe a ver los pods fuera del espacio de nombres dev. Use el comando kubectl get pods de nuevo. Esta
vez debería ver --all-namespaces así:
La pertenencia a grupos del usuario no tiene un rol de Kubernetes que permita esta acción, como se muestra en
la salida de ejemplo siguiente:
$ kubectl get pods --all-namespaces
Error from server (Forbidden): pods is forbidden: User "aksdev@contoso.com" cannot list resource "pods" in
API group "" at the cluster scope
De la misma manera, intente programar un pod en un espacio de nombres diferente, como el espacio de
nombres sre. La pertenencia a grupos del usuario no es compatible con un rol y un enlace de rol de Kubernetes
para conceder estos permisos, como se muestra en la salida de ejemplo siguiente:
$ kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre
Error from server (Forbidden): pods is forbidden: User "aksdev@contoso.com" cannot create resource "pods" in
API group "" in the namespace "sre"
Prueba del acceso de SRE a los recursos de clúster de AKS

Para confirmar que la pertenencia a grupos de Azure AD y Kubernetes RBAC funcionan correctamente entre
distintos usuarios y grupos, pruebe los comandos anteriores cuando inicie sesión como usuario opssre.
Restablezca el contexto kubeconfig mediante el comando az aks get-credentials que borra el token de
autenticación previamente almacenado en caché anteriormente para el usuario aksdev :
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing
Intente programar y ver los pods en el espacio de nombres sre asignado. Cuando se le solicite, inicie sesión con
sus credenciales personales de opssre@contoso.com creadas al principio del artículo:
kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre

kubectl get pods --namespace sre
Como se muestra en la siguiente salida de ejemplo, puede crear y ver los pods correctamente:
$ kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre
BM4RHP3FD to authenticate.
pod/nginx-sre created
$ kubectl get pods --namespace sre

nginx-sre 1/1 Running 0
Ahora, pruebe ver o programar los pods fuera del espacio de nombres de SRE asignado:

kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
No se pueden ejecutar estos comandos kubectl , como se muestra en la salida de ejemplo siguiente. La
pertenencia a grupos del usuario y el rol y los enlaces de roles de Kubernetes no conceden permisos para crear
o administrar recursos en otros espacios de nombres:
$ kubectl get pods --all-namespaces
Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot list pods at the cluster
scope
$ kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot create pods in the
namespace "dev"
En este artículo, ha creado los recursos en el clúster de AKS y los usuarios y grupos en Azure AD. Para borrar
todos estos recursos, ejecute el siguiente comando:
# Get the admin kubeconfig context to delete the necessary cluster resources
# Delete the dev and sre namespaces. This also deletes the pods, Roles, and RoleBindings
kubectl delete namespace dev
kubectl delete namespace sre
# Delete the Azure AD user accounts for aksdev and akssre

az ad user delete --upn-or-object-id $AKSDEV_ID
az ad user delete --upn-or-object-id $AKSSRE_ID
# Delete the Azure AD groups for appdev and opssre. This also deletes the Azure role assignments.
az ad group delete --group appdev
az ad group delete --group opssre
Pasos siguientes
Para obtener más información sobre cómo proteger los clústeres de Kubernetes, consulte Opciones de acceso e
identificación para AKS.
Para ver procedimientos recomendados sobre el control de recursos e identidades, consulte Procedimientos
recomendados para la autenticación y autorización en AKS.
Rotación de certificados en Azure Kubernetes
Service (AKS)
Azure Kubernetes Service (AKS) usa certificados para la autenticación con muchos de sus componentes.
Periódicamente, puede que necesite rotar esos certificados por motivos de seguridad o de directivas. Por
ejemplo, puede establecer una directiva para girar todos los certificados cada 90 días.
En este artículo se muestra cómo rotar los certificados en el clúster de AKS.
Antes de empezar
Para este artículo, es preciso usar la versión 2.0.77 de la CLI de Azure o cualquier versión posterior. Ejecute
Certificados de AKS, entidades de certificación y cuentas de servicio

AKS genera y usa los siguientes certificados, entidades de certificación y cuentas de servicio:
El servidor de API de AKS crea una entidad de certificación (CA) denominada CA del clúster.
El servidor de API tiene una CA del clúster que firma los certificados para la comunicación unidireccional
desde el servidor de API a kubelets.
Cada kubelet también crea una solicitud de firma de certificado (CSR), que está firmada por la CA del clúster,
para la comunicación desde el kubelet al servidor de la API.
El agregador de API usa la CA del clúster para emitir certificados para la comunicación con otras API. El
agregador de API también puede tener su propia CA para emitir esos certificados, pero actualmente usa la
CA del clúster.
Cada nodo usa un token de cuenta de servicio (SA), que está firmado por la CA del clúster.
El cliente kubectl tiene un certificado para comunicarse con el clúster de AKS.
NOTE
Los clústeres de AKS creados antes de marzo de 2019 tienen certificados que expiran después de dos años. Los clústeres
creados después de marzo del 2019 o cualquier clúster que tenga rotados sus certificados tienen certificados de CA del
clúster que expiran a los 30 años. El resto de certificados expira transcurridos dos años. Para comprobar cuándo se creó el
clúster, use kubectl get nodes para ver la Antigüedad de los grupos de nodos.
Además, puede comprobar la fecha de expiración del certificado del clúster. Por ejemplo, el comando de Bash siguiente
muestra los detalles del certificado para el clúster myAKSCluster.
kubectl config view --raw -o jsonpath="{.clusters[?(@.name == 'myAKSCluster')].cluster.certificate-

authority-data}" | base64 -d | openssl x509 -text | grep -A2 Validity
Rotar los certificados de clúster

WARNING
La rotación de los certificados con az aks rotate-certs puede producir un tiempo de inactividad de hasta 30 minutos
para el clúster de AKS.
Use az aks get-credentials para iniciar sesión en el clúster de AKS. Este comando también descarga y configura
el certificado de cliente kubectl en el equipo local.
az aks get-credentials -g $RESOURCE_GROUP_NAME -n $CLUSTER_NAME
Use az aks rotate-certs para rotar todos los certificados, entidades de certificación (CA) y cuentas de servicio
(SA) del clúster.
az aks rotate-certs -g $RESOURCE_GROUP_NAME -n $CLUSTER_NAME
IMPORTANT
Este proceso puede tardar hasta 30 minutos para que az aks rotate-certs se complete. Si se produce un error en el
comando antes de finalizar, use az aks show para comprobar que el estado del clúster es Certificate Rotating (Rotación
de certificados). Si el clúster se encuentra en un estado de error, vuelva a ejecutar az aks rotate-certs para rotar los
certificados otra vez.
Para comprobar que los certificados antiguos ya no son válidos, ejecute un comando kubectl . Como no ha
actualizado los certificados usados por kubectl , verá que aparece un error. Por ejemplo:
$ kubectl get no
Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of
"crypto/rsa: verification error" while trying to verify candidate authority certificate "ca")
Actualice el certificado usado por kubectl ejecutando az aks get-credentials .
az aks get-credentials -g $RESOURCE_GROUP_NAME -n $CLUSTER_NAME --overwrite-existing
Compruebe que los certificados se han actualizado mediante la ejecución de un comando kubectl , que ahora
se realizará correctamente. Por ejemplo:
kubectl get no
NOTE
Si tiene algún servicio que se ejecute sobre AKS, como Azure Dev Spaces, es posible que también tenga que actualizar los
certificados relacionados con esos servicios.
Pasos siguientes
En este artículo se ha mostrado cómo rotar automáticamente los certificados, las entidades de certificación (CA)
y las cuentas de servicio (SA) del clúster. Para obtener más información sobre los procedimientos recomendados
de seguridad de AKS, puede consultar las Prácticas recomendadas para la seguridad de los clústeres y las
actualizaciones en Azure Kubernetes Service (AKS).
Creación de un clúster privado de Azure Kubernetes
Service
En un clúster privado, el servidor de la API o el plano de control tienen direcciones IP internas que se definen en
el documento RFC1918 sobre la asignación de direcciones para conexiones privadas de Internet. Mediante el
uso de un clúster privado, puede asegurarse de que el tráfico entre el servidor de API y los grupos de nodos
permanece solo en la red privada.
El plano de control o el servidor de la API están en una suscripción de Azure administrada mediante Azure
Kubernetes Service (AKS). El grupo de clústeres o nodos de un cliente está en la suscripción del cliente. El
servidor y el grupo de clústeres o nodos pueden comunicarse entre sí a través del servicio de Azure Private Link
en la red virtual del servidor de la API y de un punto de conexión privado expuesto en la subred del clúster de
AKS del cliente.
Un clúster privado está disponible en las regiones públicas, en Azure Government y en las regiones de Azure
China 21Vianet en las que se admite AKS.
NOTE
Se admiten sitios de Azure Government, aunque en este momento no se admite US Gov Texas debido a la falta de
compatibilidad con Private Link.
Requisitos previos
CLI de Azure, versión 2.2.0 o cualquier versión posterior
El servicio Azure Private Link solo se admite en Standard Azure Load Balancer. No se admite en Basic Azure
Load Balancer.
Para usar un servidor DNS personalizado, agregue la IP 168.63.129.16 de Azure DNS como servidor DNS
ascendente en el servidor DNS personalizado.
Creación de un clúster privado de AKS

Cree un grupo de recursos o seleccione uno existente en el clúster de AKS.
az group create -l westus -n MyResourceGroup
Redes básicas predeterminadas
az aks create -n <private-cluster-name> -g <private-cluster-resource-group> --load-balancer-sku standard --

enable-private-cluster
Donde --enable-private-cluster es una marca obligatoria para un clúster privado.

Redes avanzadas
az aks create \
--resource-group <private-cluster-resource-group> \
--name <private-cluster-name> \
--enable-private-cluster \
--service-cidr 10.2.0.0/24
Donde --enable-private-cluster es una marca obligatoria para un clúster privado.
NOTE
Si la dirección CIDR del puente de Docker (172.17.0.1/16) entra en conflicto con el CIDR de la subred, cambie la dirección
del puente de Docker.
Configuración de zona de DNS privado

Se pueden aprovechar los siguientes parámetros para configurar la zona DNS privada.
"System" es el valor predeterminado. Si se omite el argumento --private-dns-zone, AKS creará una zona DNS
privada en el grupo de recursos del nodo.
Si la zona de DNS privado está en una suscripción diferente a la del clúster de AKS, debe registrar
Microsoft.ContainerServices en ambas suscripciones.
El valor "None" significa que AKS no creará una zona DNS privada. Esto requiere que Traiga su propio
servidor DNS y configure la resolución DNS para el FQDN privado. Si no configura la resolución DNS, el
DNS solo se podrá resolver dentro de los nodos del agente y provocará problemas en el clúster después de
la implementación.
"CUSTOM_PRIVATE_DNS_ZONE_RESOURCE_ID" requiere la creación de una zona DNS privada en este
formato para la nube global de Azure: privatelink.<region>.azmk8s.io . A partir de ahora, necesitará el
identificador de recurso de esa zona DNS privada. También necesitará una identidad asignada por el usuario
o una entidad de servicio que tenga como mínimo los roles private dns zone contributor y
vnet contributor .
"fqdn-subdomain" solo se puede usar con "CUSTOM_PRIVATE_DNS_ZONE_RESOURCE_ID" para
proporcionar capacidades de subdominio a privatelink.<region>.azmk8s.io .
Requisitos previos
La versión preliminar 0.5.7 de AKS o posterior.
La API, versión 2020-11-01 o posterior
Creación de un clúster de AKS privado con zona de DNS privado

enable-private-cluster --enable-managed-identity --assign-identity <ResourceId> --private-dns-zone
[system|none]
Creación de un clúster de AKS privado con una zona DNS privada

enable-private-cluster --enable-managed-identity --assign-identity <ResourceId> --private-dns-zone <custom
private dns zone ResourceId> --fqdn-subdomain <subdomain-name>
Opciones para conectarse al clúster privado
El punto de conexión del servidor de la API no tiene ninguna dirección IP pública. Para administrar el servidor de
API, necesitará una máquina virtual que tenga acceso a la red virtual de Azure (VNet) del clúster de AKS. Hay
varias opciones para establecer la conectividad de red con el clúster privado.
Crear una máquina virtual en la misma red virtual de Azure (VNet) que el clúster de AKS.
Usar una máquina virtual de una red diferente y configurar el emparejamiento de red virtual. Consulte la
sección siguiente para más información sobre esta opción.
Usar una conexión de ExpressRoute o VPN.
Use la característica Ejecutar comando de AKS.
La opción más sencilla es crear una máquina virtual en la misma red virtual que el clúster de AKS. 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.
Ejecutar comando de AKS (versión preliminar)
En la actualidad, cuando necesite tener acceso a un clúster privado, debe hacerlo dentro de la red virtual del
clúster o en una red o una máquina cliente emparejadas. Normalmente, para ello es necesario que la máquina
se conecte a través de VPN o ExpressRoute a la red virtual del clúster o que se cree un JumpBox en dicha red.
Ejecutar comando de AKS le permite invocar comandos de forma remota en un clúster de AKS mediante la API
de AKS. Esta característica proporciona una API que le permite, por ejemplo, ejecutar comandos Just-in-Time
desde un equipo portátil remoto de un clúster privado. Esta API le puede ayudar considerablemente con el
acceso rápido Just-In-Time a un clúster privado cuando la máquina cliente no está en la red privada del clúster y,
al mismo tiempo, conserva y aplica los mismos controles de RBAC y el servidor de API privado.
Registro de la característica en vista previa (GB ) RunCommandPreview
Para usar la nueva API Ejecutar comando, también debe habilitar la marca de característica RunCommandPreview
en la suscripción.
Registre la marca de la característica RunCommandPreview con el comando [az feature register][az-feature-
register], como se muestra en el siguiente ejemplo:
az feature register --namespace "Microsoft.ContainerService" --name "RunCommandPreview"
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/RunCommandPreview')].

Uso de Ejecutar comando de AKS

Comando sencillo
az aks command invoke -g <resourceGroup> -n <clusterName> -c "kubectl get pods -n kube-system"
Implementación de un manifiesto adjuntando el archivo específico

az aks command invoke -g <resourceGroup> -n <clusterName> -c "kubectl apply -f deployment.yaml -n default" -
f deployment.yaml
Implementación de un manifiesto adjuntando una carpeta completa
az aks command invoke -g <resourceGroup> -n <clusterName> -c "kubectl apply -f deployment.yaml -n default" -

f .
Realización de una instalación de Helm y paso del manifiesto de valores específico
az aks command invoke -g <resourceGroup> -n <clusterName> -c "helm repo add bitnami

https://charts.bitnami.com/bitnami && helm repo update && helm install my-release -f values.yaml
bitnami/nginx" -f values.yaml
Emparejamiento de redes virtuales de Azure

Tal y como se ha dicho, el emparejamiento de red virtual es un mecanismo para acceder a un clúster privado. Si
desea usar el emparejamiento de red virtual, tiene que configurar un vínculo entre la red virtual y la zona DNS
privada.
1. Vaya al grupo de recursos del nodo en Azure Portal.
2. Seleccione la zona DNS privada.
3. En el panel izquierdo, seleccione el vínculo red vir tual .
4. Cree un nuevo vínculo para agregar la red virtual de la máquina virtual a la zona DNS privada. El vínculo de
la zona DNS puede tardar unos minutos en estar disponible.
5. En Azure Portal, vaya al grupo de recursos que contiene la red virtual del clúster.
6. En el panel derecho, seleccione la red virtual. El nombre de la red virtual tiene el formato aks-vnet-* .
7. En el panel izquierdo, seleccione Emparejamientos .
8. Seleccione Agregar , agregue la red virtual de la máquina virtual y, después, cree el emparejamiento.
9. Vaya a la red virtual en la que tiene la máquina virtual, seleccione Emparejamientos , seleccione la red
virtual de AKS y, después, cree el emparejamiento. Si los intervalos de direcciones de la red virtual de AKS y
de la red virtual de la máquina virtual entran en conflicto, se produce un error de emparejamiento. Para más
información, vea el artículo Emparejamiento de redes virtuales.
Concentrador y radio con DNS personalizado

Las arquitecturas de concentrador y radio suelen usarse para implementar redes en Azure. En muchas de estas
implementaciones, los valores de DNS en las redes virtuales de radios están configurados para hacer referencia
a un reenviador de DNS central con el fin de permitir la resolución de DNS local y basada en Azure. Al
implementar un clúster de AKS en un entorno de red de este tipo, hay algunas consideraciones especiales que
se deben tener en cuenta.
1. De forma predeterminada, cuando se aprovisiona un clúster privado, se crean un punto de conexión
privado (1) y una zona DNS privada (2) en el grupo de recursos administrados del clúster. El clúster usa
un registro A en la zona privada a fin de resolver la dirección IP del punto de conexión privado para la
comunicación con el servidor de la API.
2. La zona DNS privada solo está vinculada a la red virtual a la que están adjuntados los nodos del clúster
(3). Esto significa que el punto de conexión privado solo lo pueden resolver los hosts de esa red virtual
vinculada. En escenarios en los que no haya ningún DNS personalizado configurado en la red virtual
(valor predeterminado), esto funciona sin incidencias, ya que los hosts apuntan a 168.63.129.16 para
DNS, que puede resolver registros en la zona DNS privada debido al vínculo.
3. En escenarios en los que la red virtual que contiene el clúster tenga una configuración de DNS
personalizada (4), se produce un error en la implementación del clúster a menos que la zona DNS
privada esté vinculada a la red virtual que contiene las resoluciones de DNS personalizadas (5). Este
vínculo se puede crear manualmente después de crear la zona privada, durante el aprovisionamiento del
clúster, o a través de la automatización si se detecta la creación de la zona usando mecanismos de
implementación basados en eventos (por ejemplo, Azure Event Grid y Azure Functions).
NOTE
Si usa Traiga su propia tabla de rutas con kubenet y Traiga su propio DNS con un clúster privado, se producirá un error en
la creación del clúster. Tendrá que asociar RouteTable en el grupo de recursos del nodo a la subred después de que se haya
producido un error en la creación del clúster, con el fin de que la creación se realice correctamente.
Limitaciones
AKS-RunCommand no funciona en clústeres que tienen habilitado AAD administrado por AKS y Private Link.
Los intervalos autorizados de direcciones IP no se pueden aplicar al punto de conexión del servidor de API
privada. Solo se aplican al servidor de API pública.
Las limitaciones del servicio Azure Private Link aplican a los clústeres privados.
No se admiten agentes hospedados por Microsoft en Azure DevOps con clústeres privados. Considere la
posibilidad de usar agentes autohospedados.
En el caso de los clientes que necesitan habilitar Azure Container Registry para trabajar con instancias
privadas de AKS, la red virtual de Container Registry debe estar emparejada con la red virtual del clúster del
agente.
No se admite la conversión de clústeres de AKS existentes en clústeres privados.
La eliminación o modificación del punto de conexión privado en la subred del cliente hará que el clúster deje
de funcionar.
Una vez que los clientes hayan actualizado el registro A en sus propios servidores DNS, esos pods seguirán
resolviendo el FQDN apiserver en la dirección IP anterior después de la migración hasta que se reinicien. Los
clientes deben reiniciar los pods de hostNetwork y de DNSPolicy predeterminados después de la migración
del plano de control.
En el caso de mantenimiento en el plano de control, es posible que cambie la IP de AKS. En este caso, tendrá
que actualizar el registro A que apunta a la dirección IP privada del servidor de la API en el servidor DNS
personalizado y reiniciar los pods o las implementaciones personalizados mediante hostNetwork.
Traiga sus propias claves (BYOK) con discos de
Azure en Azure Kubernetes Service (AKS)
Azure Storage cifra todos los datos de las cuentas de almacenamiento en reposo. De manera predeterminada,
los datos se cifran con claves administradas por Microsoft. Para tener un mayor control sobre las claves de
cifrado, puede proporcionar claves administradas por el cliente y utilizarlas para el cifrado en reposo del sistema
operativo y los discos de datos de los clústeres de AKS. Obtenga más información sobre las claves
administradas por el cliente en Linux y Windows.
Limitaciones
La compatibilidad con el cifrado de discos de datos se limita a los clústeres de AKS que ejecuten Kubernetes
versión 1.17 y posteriores.
El cifrado del sistema operativo y del disco de datos con claves administradas por el cliente solo se puede
habilitar cuando se crea un clúster de AKS.
Requisitos previos
Debe habilitar la protección contra el purgado y la eliminación temporal para Azure Key Vault al usar Key
Vault para cifrar los discos administrados.
Es necesaria la versión 2.11.1 o posterior de la CLI de Azure.
Creación de una instancia de Azure Key Vault

Use una instancia de Azure Key Vault para almacenar las claves. Opcionalmente, puede usar Azure Portal para
configurar claves administradas por el cliente con Azure Key Vault mediante Azure Portal.
Cree un nuevo grupo de recursos y luego cree una nueva instancia de Key Vault y habilite la protección contra el
purgado y la eliminación temporal. Asegúrese de usar los mismos nombres de región y grupo de recursos para
cada comando.
# Optionally retrieve Azure region short names for use on upcoming commands
az account list-locations
# Create new resource group in a supported Azure region

az group create -l myAzureRegionName -n myResourceGroup
# Create an Azure Key Vault resource in a supported Azure region

az keyvault create -n myKeyVaultName -g myResourceGroup -l myAzureRegionName --enable-purge-protection true
--enable-soft-delete true
Creación de una instancia de DiskEncryptionSet

Reemplace myKeyVaultName por el nombre del almacén de claves. También necesitará una clave almacenada
en Azure Key Vault para completar los pasos siguientes. Almacene la clave existente en la instancia de Key Vault
que creó en los pasos anteriores, o genere una nueva clave y reemplace myKeyName a continuación por el
nombre de la clave.
# Retrieve the Key Vault Id and store it in a variable
keyVaultId=$(az keyvault show --name myKeyVaultName --query "[id]" -o tsv)
# Retrieve the Key Vault key URL and store it in a variable

keyVaultKeyUrl=$(az keyvault key show --vault-name myKeyVaultName --name myKeyName --query "[key.kid]" -o
tsv)
# Create a DiskEncryptionSet
az disk-encryption-set create -n myDiskEncryptionSetName -l myAzureRegionName -g myResourceGroup --source-
vault $keyVaultId --key-url $keyVaultKeyUrl
Concesión de acceso a DiskEncryptionSet al almacén de claves

Use DiskEncryptionSet y los grupos de recursos que creó en los pasos anteriores y conceda al recurso
DiskEncryptionSet acceso a Azure Key Vault.
# Retrieve the DiskEncryptionSet value and set a variable

desIdentity=$(az disk-encryption-set show -n myDiskEncryptionSetName -g myResourceGroup --query "
[identity.principalId]" -o tsv)
# Update security policy settings

az keyvault set-policy -n myKeyVaultName -g myResourceGroup --object-id $desIdentity --key-permissions
wrapkey unwrapkey get
Creación de un nuevo clúster de AKS y cifrado del disco del sistema

operativo
Cree una nuevo grupo de recursos y el clúster de AKS y luego use la clave para cifrar el disco del sistema
operativo. Las claves administradas por el cliente solo se admiten en versiones de Kubernetes posteriores a la
1.17.
IMPORTANT
Asegúrese de crear un nuevo grupo de recursos para el clúster de AKS.
# Retrieve the DiskEncryptionSet value and set a variable

diskEncryptionSetId=$(az disk-encryption-set show -n mydiskEncryptionSetName -g myResourceGroup --query "
[id]" -o tsv)
# Create a resource group for the AKS cluster

az group create -n myResourceGroup -l myAzureRegionName
# Create the AKS cluster

az aks create -n myAKSCluster -g myResourceGroup --node-osdisk-diskencryptionset-id $diskEncryptionSetId --
kubernetes-version KUBERNETES_VERSION --generate-ssh-keys
Cuando se agregan nuevos grupos de nodos al clúster creado anteriormente, la clave administrada por el cliente
proporcionada durante la creación se usa para cifrar el disco del sistema operativo.
Cifrado del disco de datos del clúster de AKS (opcional)

La clave de cifrado del disco del sistema operativo se usará para cifrar el disco de datos si no se proporciona la
clave para el disco de datos a partir de v1.17.2, y también puede cifrar los discos de datos de AKS con las demás
claves.
IMPORTANT
Asegúrese de que tiene las credenciales de AKS adecuadas. La identidad administrada deberá tener acceso de colaborador
al grupo de recursos donde se implementa diskencryptionset. De lo contrario, obtendrá un error que sugiere que la
identidad administrada no tiene permisos.
# Retrieve your Azure Subscription Id from id property as shown below

az account list
someuser@Azure:~$ az account list

[
{
"cloudName": "AzureCloud",
"id": "666e66d8-1e43-4136-be25-f25bb5de5893",
"isDefault": true,
"name": "MyAzureSubscription",
"state": "Enabled",
"tenantId": "3ebbdf90-2069-4529-a1ab-7bdcb24df7cd",
"user": {
"cloudShellID": true,
"name": "someuser@azure.com",
"type": "user"
}
}
]
Cree un archivo llamado byok-azure-disk .yaml que contenga la siguiente información. Reemplace
myAzureSubscriptionId, myResourceGroup y myDiskEncrptionSetName por sus valores y aplique YAML.
Asegúrese de usar el grupo de recursos donde DiskEncryptionSet está implementado. Si usa Azure Cloud Shell,
este archivo se puede crear mediante vi o nano como si funcionara en un sistema físico o virtual:
kind: StorageClass
metadata:
name: hdd
parameters:
skuname: Standard_LRS
kind: managed
diskEncryptionSetID:
"/subscriptions/{myAzureSubscriptionId}/resourceGroups/{myResourceGroup}/providers/Microsoft.Compute/diskEnc
ryptionSets/{myDiskEncryptionSetName}"
Después, ejecute esta implementación en el clúster de AKS:
# Get credentials
az aks get-credentials --name myAksCluster --resource-group myResourceGroup --output table
# Update cluster
kubectl apply -f byok-azure-disk.yaml
Pasos siguientes
Revise los procedimientos recomendados para la seguridad de los clústeres de AKS.
Cifrado basado en host en Azure Kubernetes
Service (AKS)
Con el cifrado basado en host, los datos almacenados en el host de máquina virtual de las máquinas virtuales
de los nodos de agente de AKS se cifran en reposo y se transmiten cifrados al servido Storage. Esto significa que
los discos temporales se cifran en reposo con claves administradas por la plataforma. La memoria caché de los
discos de datos y del sistema operativo se cifra en reposo con claves administradas por la plataforma o por el
cliente, según el tipo de cifrado establecido en esos discos. De forma predeterminada, cuando se usa AKS, el
sistema operativo y los discos de datos se cifran en reposo con claves administradas por la plataforma, lo que
significa que las memorias caché de estos discos también se cifran de forma predeterminada en reposo con
claves administradas por la plataforma. Puede especificar sus propias claves administradas siguiendo Traiga sus
propias claves (BYOK) con discos de Azure en Azure Kubernetes Service (AKS). La memoria caché de estos
discos también se cifrará con la clave que especifique en este paso.
Antes de empezar
Esta característica solo se puede establecer durante la creación del clúster o en el momento de creación del
grupo de nodos.
NOTE
El cifrado basado en host está disponible en regiones de Azure que admiten el cifrado del lado servidor de discos
administrados de Azure y solo con tamaños de máquinas virtuales compatibles específicos.
Requisitos previos
Limitaciones
Solo se puede habilitar en grupos de nodos nuevos.
Solo se puede habilitar en regiones de Azure que admiten el cifrado del lado servidor de discos
administrados de Azure y solo con tamaños de máquinas virtuales compatibles específicos.
Requiere un clúster de AKS y un grupo de nodos basado en Virtual Machine Scale Sets (VMSS) como tipo de
conjunto de máquinas virtuales.
Uso del cifrado basado en host en clústeres nuevos

Configure los nodos de agente de clúster para usar el cifrado basado en host cuando se cree el clúster.
az aks create --name myAKSCluster --resource-group myResourceGroup -s Standard_DS2_v2 -l westus2 --enable-

encryption-at-host
Si quiere crear clústeres sin el cifrado basado en host, puede omitir el parámetro --enable-encryption-at-host
para hacerlo.
Uso del cifrado basado en host en clústeres existentes

Puede habilitar el cifrado basado en host en clústeres existentes agregando un nuevo grupo de nodos al clúster.
Configure un grupo de nodos nuevo para usar el cifrado basado en host mediante el parámetro
--enable-encryption-at-host .
az aks nodepool add --name hostencrypt --cluster-name myAKSCluster --resource-group myResourceGroup -s

Standard_DS2_v2 -l westus2 --enable-encryption-at-host
Si quiere crear grupos de nodos nuevos sin la característica de cifrado basado en host, puede hacerlo omitiendo
el parámetro --enable-encryption-at-host .
Pasos siguientes
Revise las prácticas recomendadas para la seguridad del clúster de AKS. Lea más sobre el cifrado basado en
host.
Uso del controlador Secrets Store CSI para
Kubernetes en un clúster de Azure Kubernetes
Service (AKS) (versión preliminar)
El controlador Secrets Store CSI para Kubernetes permite la integración de Azure Key Vault como un almacén de
secretos con un clúster de Kubernetes a través de un volumen CSI.
Requisitos previos
Antes de empezar, instale la versión más reciente de la CLI de Azure y la extensión aks-preview .
Características
Montaje de secretos, claves o certificados en un pod mediante un volumen CSI
Admite volúmenes CSI en línea (versión 1.15 o superior) de Kubernetes
Admite el montaje de varios objetos de almacenamiento de secretos como un solo volumen
Admite la portabilidad de pods con CRD de SecretProviderClass
Admite contenedores de Windows (versión de Kubernetes 1.18 o posterior)
Sincronización con secretos de Kubernetes (versión del controlador Secrets Store CSI 0.0.10 o posterior)
Admite la rotación automática de contenido montado y secretos de Kubernetes sincronizados (versión del
controlador Secrets Store CSI 0.0.15 o posterior)
Registro de la característica en vista previa (GB)

AKS-AzureKeyVaultSecretsProvider
IMPORTANT
Para crear un clúster de AKS que pueda usar el controlador Secrets Store CSI, debe habilitar la marca de
características AKS-AzureKeyVaultSecretsProvider en la suscripción.
Registre la marca de la característica AKS-AzureKeyVaultSecretsProvider con el comando az feature register,
az feature register --namespace "Microsoft.ContainerService" --name "AKS-AzureKeyVaultSecretsProvider"
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/AKS-

AzureKeyVaultSecretsProvider')].{Name:name,State:properties.state}"

También se necesita la versión 0.5.9 o posterior de la extensión aks-preview de la CLI de Azure. Instale la
extensión de la CLI de Azure aks-preview mediante el comando az extension add. Si ya tiene instalada la
extensión, actualice a la versión más reciente disponible mediante el comando az extension update.

Creación de un clúster de AKS con compatibilidad con el controlador

Secrets Store CSI
NOTE
Si tiene previsto proporcionar acceso al clúster mediante una identidad administrada asignada por el usuario o por el
sistema, habilite Azure Active Directory en el clúster con la marca enable-managed-identity . Para obtener más
información, consulte Uso de identidades administradas en Azure Kubernetes Service.
En primer lugar, cree un grupo de recursos de Azure:
az group create -n myResourceGroup -l westus
Para crear un clúster de AKS con la funcionalidad del controlador CSI del almacén de secretos, use el comando
az aks create con el complemento azure-keyvault-secrets-provider :
az aks create -n myAKSCluster -g myResourceGroup --enable-addons azure-keyvault-secrets-provider
Actualización de un clúster de AKS con compatibilidad con el

controlador Secrets Store CSI
NOTE
Si tiene previsto proporcionar acceso al clúster mediante una identidad administrada asignada por el usuario o por el
sistema, habilite Azure Active Directory en el clúster con la marca enable-managed-identity . Para obtener más
información, consulte Uso de identidades administradas en Azure Kubernetes Service.
Para actualizar un clúster de AKS con la funcionalidad del controlador CSI del almacén de secretos, use el
comando az aks enable-addons con el complemento azure-keyvault-secrets-provider :
az aks enable-addons --addons azure-keyvault-secrets-provider --name myAKSCluster --resource-group

myResourceGroup
Comprobación de la instalación del controlador CSI del almacén de

secretos
Estos comandos instalarán el controlador Secrets Store CSI y el proveedor de Azure Key Vault en los nodos. Para
realizar la comprobación, enumere todos los pods con las etiquetas secrets-store-csi-driver y secrets-store-
provider-azure en el espacio de nombres kube-system y asegurándose de que la salida sea similar a la siguiente:
kubectl get pods -n kube-system -l 'app in (secrets-store-csi-driver, secrets-store-provider-azure)'
NAMESPACE NAME READY STATUS RESTARTS AGE

kube-system aks-secrets-store-csi-driver-4vpkj 3/3 Running 2 4m25s
kube-system aks-secrets-store-csi-driver-ctjq6 3/3 Running 2 4m21s
kube-system aks-secrets-store-csi-driver-tlvlq 3/3 Running 2 4m24s
kube-system aks-secrets-store-provider-azure-5p4nb 1/1 Running 0 4m21s
kube-system aks-secrets-store-provider-azure-6pqmv 1/1 Running 0 4m24s
kube-system aks-secrets-store-provider-azure-f5qlm 1/1 Running 0 4m25s
Habilitación y deshabilitación de la rotación automática

NOTE
Cuando se habilita, el controlador Secrets Store CSI actualizará el montaje del pod y el secreto de Kubernetes definido en
secretObjects de SecretProviderClass sondeando los cambios cada dos minutos.
Para habilitar la rotación automática de secretos, use la marca enable-secret-rotation al crear el clúster:
az aks create -n myAKSCluster2 -g myResourceGroup --enable-addons azure-keyvault-secrets-provider --enable-

secret-rotation
O bien, actualice un clúster existente con el complemento habilitado:
az aks update -g myResourceGroup -n myAKSCluster2 --enable-secret-rotation
Para deshabilitarlo, use la marca disable-secret-rotation :
az aks update -g myResourceGroup -n myAKSCluster2 --disable-secret-rotation

Creación o uso de una instancia de Azure Key Vault
Además de un clúster de AKS, necesitará un recurso de Azure Key Vault que contenga el contenido del secreto.
Para implementar una instancia de Azure Key Vault, siga estos pasos:
1. Creación de un Almacén de claves
2. Establecimiento de un secreto en un almacén de claves
Tome nota de las siguientes propiedades para usarlas en la sección siguiente:
Nombre del objeto secreto en Key Vault
Tipo de contenido secreto (secreto, clave, certificado)
Nombre del recurso de Key Vault
Identificador de inquilino de Azure al que pertenece la suscripción
Proporcionar la identidad para acceder a Azure Key Vault

En el ejemplo de este artículo se usa una entidad de servicio, pero el proveedor de Azure Key Vault ofrece cuatro
métodos de acceso. Repáselos y elija la que mejor se adapte a su caso de uso. Tenga en cuenta que puede ser
necesario realizar otros pasos en función del método elegido, como conceder permisos a la entidad de servicio
para obtener secretos del almacén de claves.
Entidad de seguridad de servicio
Identidad del pod
Identidad administrada asignada por el usuario
Identidad administrada asignada por el sistema
Creación y aplicación de un objeto SecretProviderClass personalizado

Para usar y configurar el controlador Secrets Store CSI para el clúster de AKS, cree un recurso personalizado de
SecretProviderClass.
Este es un ejemplo en el que se usa una entidad de servicio para acceder al almacén de claves:
apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
name: azure-kvname
spec:
provider: azure
parameters:
usePodIdentity: "false" # [OPTIONAL] if not provided, will default to "false"
keyvaultName: "kvname" # the name of the KeyVault
cloudName: "" # [OPTIONAL for Azure] if not provided, azure environment will default
to AzurePublicCloud
objects: |
array:
- |
objectName: secret1
objectType: secret # object types: secret, key or cert
objectVersion: "" # [OPTIONAL] object versions, default to latest if empty
- |
objectName: key1
objectType: key
objectVersion: ""
tenantId: "<tenant-id>" # the tenant ID of the KeyVault
Para obtener más información, consulte Creación de su propio objeto SecretProviderClass. Asegúrese de usar
los valores que anotó anteriormente.
Aplicación de SecretProviderClass al clúster
A continuación, implemente el recurso SecretProviderClass que ha creado. Por ejemplo:
kubectl apply -f ./new-secretproviderclass.yaml
Actualización y aplicación del archivo YAML de implementación del

clúster
Para asegurarse de que el clúster use el nuevo recurso personalizado, actualice el archivo YAML de
implementación. Para obtener un ejemplo más completo, vea una implementación de ejemplo mediante la
entidad de servicio para acceder a Azure Key Vault. Asegúrese de seguir los pasos adicionales del método
elegido para el acceso al almacén de claves.
kind: Pod
apiVersion: v1
metadata:
name: busybox-secrets-store-inline
spec:
containers:
- name: busybox
image: k8s.gcr.io/e2e-test-images/busybox:1.29
command:
- "/bin/sleep"
- "10000"
volumeMounts:
- name: secrets-store-inline
mountPath: "/mnt/secrets-store"
readOnly: true
volumes:
- name: secrets-store-inline
csi:
driver: secrets-store.csi.k8s.io
readOnly: true
volumeAttributes:
secretProviderClass: "azure-kvname"
nodePublishSecretRef: # Only required when using service principal mode
name: secrets-store-creds # Only required when using service principal mode. The
name of the Kubernetes secret that contains the service principal credentials to access keyvault.
Aplique la implementación actualizada al clúster:
kubectl apply -f ./my-deployment.yaml
Validación de los secretos

Una vez que se inicia el pod, el contenido montado en la ruta del volumen especificada en el archivo YAML de
implementación estará disponible.
## show secrets held in secrets-store

kubectl exec busybox-secrets-store-inline -- ls /mnt/secrets-store/
## print a test secret 'secret1' held in secrets-store

kubectl exec busybox-secrets-store-inline -- cat /mnt/secrets-store/secret1
Deshabilitación del controlador CSI del almacén de secretos en un
clúster de AKS existente
Para deshabilitar la funcionalidad del controlador CSI del almacén de secretos en un clúster existente, use el
comando az aks disable-addons con la marca azure-keyvault-secrets-provider :
az aks disable-addons --addons azure-keyvault-secrets-provider -g myResourceGroup -n myAKSCluster
Pasos siguientes
Después de aprender a usar el controlador Secrets Store CSI con un clúster de AKS, consulte los siguientes
recursos:
Habilitación de controladores CSI para discos de Azure y Azure Files en AKS
Visualización de las métricas de clúster para Azure
AKS proporciona un conjunto de métricas para el plano de control, incluidos el servidor de API y el escalador
automático de clúster, además de nodos de clúster. Estas métricas permiten supervisar el estado del clúster y
solucionar problemas. Puede ver las métricas del clúster en Azure Portal.
NOTE
Estas métricas de clúster de AKS se superponen con un subconjunto de métricas proporcionadas por Kubernetes.
Visualización de las métricas del clúster de AKS en Azure Portal

Para ver las métricas del clúster de AKS:
1. Inicie sesión en Azure Portal y vaya al clúster de AKS.
2. En el lado izquierdo, en Supervisión, seleccione Métricas.
3. Cree un gráfico para las métricas que desea ver. Por ejemplo, cree un gráfico:
a. En Ámbito, elija el clúster.
b. En Espacio de nombres de métrica, elija Container service (managed) standard metrics [Métricas
estándar (administradas) del servicio de contenedor].
c. En Métrica, en Pods, elija Number of Pods by phase (Número de pods por fase).
d. En Agregación, elija Promedio.
En el ejemplo anterior se muestran las métricas del número promedio de pods para myAKSCluster.
Métricas disponibles
Están disponibles las siguientes métricas del clúster:
N O M B RE GRO UP ( GRUP O ) ID DESC RIP C IÓ N
Solicitudes en proceso Servidor de API (versión apiserver_current_inflight_re Número máximo de

preliminar) quests solicitudes en proceso
activas actualmente en el
servidor de API por tipo de
solicitud.
Estado del clúster Escalador automático del cluster_autoscaler_cluster_s Determina si el escalador

clúster (versión preliminar) afe_to_autoscale automático del clúster
realizará alguna acción en el
clúster.
Reducción vertical de Escalador automático del cluster_autoscaler_scale_do Determina si la reducción

recuperación clúster (versión preliminar) wn_in_cooldown vertical está en
recuperación: no se
quitarán nodos durante
este período de tiempo.
Nodos innecesarios Escalador automático del cluster_autoscaler_unneede El escalador automático del

clúster (versión preliminar) d_nodes_count clúster marca esos nodos
como candidatos para su
eliminación y al final se
eliminan.
N O M B RE GRO UP ( GRUP O ) ID DESC RIP C IÓ N
Pods no programables Escalador automático del cluster_autoscaler_unsched Número de pods que

clúster (versión preliminar) ulable_pods_count actualmente no se pueden
programar en el clúster.
Número total de núcleos de Nodos kube_node_status_allocatab Número total de núcleos de

CPU disponibles en un le_cpu_cores CPU disponibles en un
clúster administrado clúster administrado.
Cantidad total de memoria Nodos kube_node_status_allocatab Cantidad total de memoria

disponible en un clúster le_memory_bytes disponible en un clúster
administrado administrado.
Estados de diversas Nodos kube_node_status_conditio Estados de diversas

condiciones de nodo n condiciones de nodo
Milinúcleos de uso de CPU Nodos (versión preliminar) node_cpu_usage_millicores Medida agregada del uso
de CPU en milinúcleos en el
clúster.
Porcentaje de uso de CPU Nodos (versión preliminar) node_cpu_usage_percentag Uso medio agregado de la
e CPU del clúster en
porcentaje.
Bytes de RSS de memoria Nodos (versión preliminar) node_memory_rss_bytes Memoria RSS del
contenedor utilizada, en
bytes.
Porcentaje de memoria RSS Nodos (versión preliminar) node_memory_rss_percenta Memoria RSS del
ge contenedor utilizada, en
porcentaje.
Bytes de memoria del Nodos (versión preliminar) node_memory_working_set Memoria del conjunto de
conjunto de trabajo _bytes trabajo de contenedor
usada, en bytes.
Porcentaje de memoria de Nodos (versión preliminar) node_memory_working_set Memoria del espacio de

conjunto de trabajo _percentage trabajo del contenedor
utilizada, en porcentaje.
Bytes usados de disco Nodos (versión preliminar) node_disk_usage_bytes Espacio en disco usado en
bytes por dispositivo.
Porcentaje usado de disco Nodos (versión preliminar) node_disk_usage_percentag Espacio en disco usado en
e porcentaje por dispositivo.
Red en bytes Nodos (versión preliminar) node_network_in_bytes Bytes recibidos de la red.
Bytes de salida de la red Nodos (versión preliminar) node_network_out_bytes Bytes transmitidos de la

red.
Número de pods con Pods kube_pod_status_ready Número de pods con

estado Listo estado Listo.
Número de pods por fase Pods kube_pod_status_phase Número de pods por fase.
IMPORTANT
Las métricas en versión preliminar se pueden actualizar o cambiar, incluidos sus nombres y descripciones, durante la
versión preliminar.
Pasos siguientes
Además de las métricas de clúster para AKS, también puede usar Azure Monitor con el clúster de AKS. Para más
información sobre el uso de Azure Monitor con AKS, vea Azure Monitor para contenedores.
Introducción a Container Insights
Container Insights es una característica diseñada para supervisar el rendimiento de las cargas de trabajo de
contenedor implementadas en:
Clústeres de Kubernetes administrados que se hospedan en Azure Kubernetes Service (AKS)
Clústeres de Kubernetes autoadministrados que se hospedan en Azure con AKS Engine
Azure Container Instances
Clústeres de Kubernetes autoadministrados que se hospedan en Azure Stack o en el entorno local
Red Hat OpenShift en Azure
Kubernetes habilitado para Azure Arc (versión preliminar)
Container Insights es compatible con los clústeres que ejecutan los sistemas operativos Linux y
Windows Server 2019. Los entornos de ejecución de contenedor que admite son Docker, Moby y cualquiera
compatible con CRI, como CRI-O y ContainerD.
La supervisión de los contenedores es fundamental, sobre todo cuando se ejecuta un clúster de producción, a
escala, con varias aplicaciones.
Container Insights proporciona información sobre el rendimiento mediante la recopilación de métricas del
procesador y de la memoria procedentes de los controladores, nodos y contenedores disponibles en Kubernetes
mediante Metrics API. También se recopilan registros del contenedor. Una vez habilitada la supervisión de
clústeres de Kubernetes, se recopilan métricas y registros automáticamente mediante una versión en
contenedor del agente de Log Analytics para Linux. Las métricas se escriben en el almacén de métricas y los
datos de registro se incluyen en el almacén de registros asociado a su área de trabajo de Log Analytics.
¿Qué ofrece Container Insights?

Container Insights ofrece una experiencia de supervisión completa con diferentes características de Azure
Monitor. Estas características le permiten comprender el rendimiento y el estado del clúster de Kubernetes que
ejecuta el sistema operativo Linux y Windows Server 2019, así como las cargas de trabajo del contenedor. Con
Container Insights, puede hacer lo siguiente:
Identificar los contenedores de AKS que se ejecutan en el nodo y su utilización media tanto del
procesador como de la memoria. Este conocimiento puede ayudarle a identificar cuellos de botella en los
recursos.
Identificar el uso de procesador y memoria de grupos de contenedores y sus contenedores hospedados
en Azure Container Instances.
Identificar dónde se encuentra el contenedor en un controlador o un pod. Este conocimiento puede
ayudarle a ver el rendimiento general del controlador o del pod.
Revisar el uso de recursos de las cargas de trabajo que se ejecutan en el host que no estén relacionadas
con los procesos estándar que admite el pod.
Conocer el comportamiento del clúster tanto con cargas medias como con las más pesadas. Este
conocimiento puede ayudarle a identificar los requisitos de capacidad y determinar la carga máxima que
el clúster puede admitir.
Configure alertas para que le notifiquen de manera proactiva o registren el hecho de que el uso de la
CPU y la memoria en nodos o contenedores supera los umbrales, o cuando se produzca un cambio del
estado de mantenimiento en el clúster en la infraestructura o la acumulación de estado de los nodos.
Integrarse en Prometheus para ver las métricas de aplicaciones y de cargas de trabajo que recopila de los
nodos y de Kubernetes mediante consultas para crear alertas personalizadas y paneles y realizar análisis
detallado.
Supervise las cargas de trabajo de contenedor implementadas en AKS Engine de manera local y AKS
Engine en Azure Stack.
Supervise las cargas de trabajo de contenedor implementadas en Red Hat OpenShift en Azure.
NOTE
La compatibilidad con Red Hat OpenShift en Azure es una característica que se encuentra en versión preliminar
pública en este momento.
Supervise las cargas de trabajo de contenedor implementadas en Kubernetes habilitado para Azure Arc
(versión preliminar).
Estas son las principales diferencias al supervisar un clúster de Windows Server en comparación con un clúster
de Linux:
Windows no tiene una métrica RSS de memoria y, como resultado, no está disponible para los contenedores
y el nodo de Windows. La métrica de espacio de trabajo está disponible.
La información sobre la capacidad de almacenamiento del disco no está disponible para los nodos de
Windows.
Solo se supervisan los entornos de pods, no los entornos de Docker.
Con la versión preliminar, se admite un máximo de 30 contenedores de Windows Server. Esta limitación no
se aplica a los contenedores de Linux.
Consulte el siguiente vídeo, que proporciona un análisis detallado de nivel intermedio para ayudarle a obtener
información sobre cómo supervisar el clúster de AKS con Container Insights.
¿Cómo se obtiene acceso a esta característica?

Puede acceder a Container Insights de dos maneras: desde Azure Monitor o directamente desde el clúster de
AKS seleccionado. Desde Azure Monitor, tiene una perspectiva global de todos los contenedores implementados,
cuáles se supervisan y cuáles no. Esto le permite buscar y filtrar a través de las suscripciones y los grupos de
recursos y, después, explorar en profundidad Container Insights desde el contenedor seleccionado. En caso
contrario, puede acceder a la característica directamente desde un contenedor de AKS seleccionado desde la
página de AKS.
Si le interesan la supervisión y la administración de hosts de contenedor de Docker y Windows que se ejecutan

fuera de AKS y quiere más información sobre la configuración, la auditoría y la utilización de recursos, consulte
la solución de supervisión de contenedores.
Pasos siguientes
Para comenzar a supervisar el clúster de Kubernetes, revise Cómo habilitar Container Insights, a fin de entender
los requisitos y los métodos disponibles para habilitar la supervisión.
Habilitación y revisión de los registros del plano de
control de Kubernetes en Azure Kubernetes Service
(AKS)
Con Azure Kubernetes Service (AKS), los componentes del plano de control, como kube-apiserver y kube-
controller-manager se proporcionan como un servicio administrado. Cree y administre los nodos que ejecutan
kubelet y el entorno de tiempo de ejecución del contenedor, e implemente las aplicaciones mediante el servidor
de API de Kubernetes administrado. Para ayudar a solucionar los problemas de sus aplicaciones y servicios,
quizás deba ver los registros generados por estos componentes del plano de control. En este artículo se muestra
cómo usar registros de Azure Monitor para habilitar y consultar los registros de los componentes del plano de
control de Kubernetes.
Antes de empezar
En este artículo se requiere un clúster de AKS existente que se ejecute en su cuenta de Azure. Si todavía no tiene
un clúster de AKS, cree uno con la CLI de Azure o Azure Portal. Los registros de Azure Monitor funcionan tanto
con clústeres de AKS habilitados para RBAC de Kubernetes, RBAC de Azure y no habilitados para RBAC.
Habilitación de registros de recursos

Para ayudar a recopilar y revisar los datos de varios orígenes, registros de Azure Monitor proporciona un motor
de lenguaje y análisis de consultas que ofrece información detallada sobre su entorno. Un área de trabajo se usa
para intercalar y analizar los datos, y se puede integrar con otros servicios de Azure como Application Insights y
Security Center. Si desea utilizar una plataforma diferente para analizar los registros, puede decidir en su lugar
enviar los registros de recursos a una cuenta de almacenamiento o un centro de eventos de Azure. Para más
información, consulte el artículo sobre los registros de Azure Monitor.
Los registros de Azure Monitor se habilitan y administran en Azure Portal. Para habilitar la recopilación de
registros para los componentes del plano de control de Kubernetes en el clúster de AKS, abra Azure Portal en un
explorador web y realice los pasos siguientes:
1. Seleccione el grupo de recursos del clúster de AKS, como myResourceGroup. No seleccione el grupo de
recursos que contiene los recursos del clúster de AKS individuales, como
MC_myResourceGroup_myAKSCluster_eastus.
2. En la parte izquierda, elija Configuración de diagnóstico .
3. Seleccione el clúster de AKS, como myAKSCluster, y elija Agregar configuración de diagnóstico .
4. Escriba un nombre, como myAKSClusterLogs y seleccione la opción Send to Log Analytics workspace
(Enviar al área de trabajo de Log Analytics).
5. Seleccione un área de trabajo existente o cree uno. Al crear un área de trabajo, proporciónele un nombre,
un grupo de recursos y una ubicación.
6. En la lista de registros disponibles, seleccione los que desea habilitar. En este ejemplo, habilite los
registros kube-audit y kube-audit-admin. Los registros típicos incluyen kube-apiserver, kube-controller-
manager y kube-scheduler. Puede volver y cambiar los registros recopilados una vez que las áreas de
trabajo de Log Analytics está habilitadas.
7. Cuando esté listo, seleccione Guardar para habilitar la recopilación de los registros seleccionados.
Categorías de registro
Además de las entradas escritas por Kubernetes, los registros de auditoría del proyecto también tienen entradas
de AKS.
Los registros de auditoría se registran en tres categorías: kube-audit, kube-audit-admin y guard.
La categoría kube-audit contiene todos los datos de registro de auditoría para cada evento de auditoría, los
que incluyen get, list, create, update, delete, patch y post.
La categoría kube-audit-admin es un subconjunto de la categoría de registro kube-audit. kube-audit-admin
reduce considerablemente el número de registros al excluir los eventos de auditoría get y list del registro.
La categoría guard está administrada por Azure AD y las auditorías de Azure RBAC. En el caso de estar
administrada por Azure AD: el token debe estar dentro y la información de usuario fuera. Para Azure RBAC:
revisiones de acceso dentro y fuera.
Programación de un pod de prueba en el clúster de AKS

Para generar algunos registros, cree un nuevo pod en el clúster de AKS. El siguiente ejemplo de manifiesto de
YAML puede usarse para crear una instancia básica de NGINX. Cree un archivo denominado nginx.yaml en el
editor que prefiera y pegue el contenido siguiente:
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
nodeSelector:
containers:
- name: mypod
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
ports:
- containerPort: 80
Cree el pod con el comando kubectl create y especifique el archivo YAML, como se muestra en el ejemplo
siguiente:
$ kubectl create -f nginx.yaml
pod/nginx created
Visualización de los datos recopilados

Los registros de diagnóstico pueden tardar hasta 10 minutos en habilitarse y aparecer.
NOTE
Si necesita todos los datos de registro de auditoría para cumplimiento u otros propósitos, recopílelos y almacénelos en un
almacenamiento económico, como el almacenamiento de blobs. Use la categoría de registro kube-audit-admin para
recopilar y almacenar un conjunto significativo de datos de registro de auditoría con fines de supervisión y alerta.
En Azure Portal, vaya al clúster de AKS y seleccione Registros en el lado izquierdo. Si aparece, cierre la ventana
Consultas de ejemplo.
En el lado izquierdo, elija Registros . Para ver los registros de kube-audit, escriba la siguiente consulta en el
cuadro de texto:
AzureDiagnostics
| where Category == "kube-audit"
| project log_s
Es probable que se devuelvan muchos registros. Para reducir el ámbito de la consulta y ver los registros sobre el
pod de NGINX creado en el paso anterior, agregue una instrucción where adicional para buscar nginx, como se
muestra en la consulta de ejemplo siguiente:
AzureDiagnostics
| where Category == "kube-audit"
| where log_s contains "nginx"
| project log_s
Para ver los registros de kube-audit-admin, escriba la consulta siguiente en el cuadro de texto:
AzureDiagnostics
| where Category == "kube-audit-admin"
| project log_s
En este ejemplo, la consulta muestra todos los trabajos de creación en kube-audit-admin. Es posible que se
devuelvan muchos resultados y, para reducir el ámbito de la consulta y ver los registros sobre el pod de NGINX
creado en el paso anterior, agregue una instrucción where adicional para buscar nginx, como se muestra en la
consulta de ejemplo siguiente.
AzureDiagnostics
| where Category == "kube-audit-admin"
| where log_s contains "nginx"
| project log_s
Para más información acerca de cómo consultar y filtrar datos de registro, consulte el artículo de Visualización o
análisis de los datos recopilados con la búsqueda de registros de Log Analytics.
Esquema de evento de registro

AKS registra los siguientes eventos:
AzureActivity
AzureDiagnostics
AzureMetrics
ContainerImageInventory
ContainerInventory
ContainerLog
ContainerNodeInventory
ContainerServiceLog
Heartbeat
InsightsMetrics
KubeEvents
KubeHealth
KubeMonAgentEvents
KubeNodeInventory
KubePodInventory
KubeServices
Perf
Roles de registro
aksService El nombre para mostrar en el registro de auditoría de la

operación de plano de control (desde hcpService).
masterclient El nombre para mostrar en el registro de auditoría de

MasterClientCertificate, el certificado que obtiene desde az
aks get-credentials.
nodeclient El nombre para mostrar de ClientCertificate, que los nodos

de agente usan.
Pasos siguientes
En este artículo, aprendió a habilitar y revisar los registros de los componentes del plano de control de
Kubernetes en el clúster de AKS. Para seguir supervisando y solucionando problemas, también puede ver los
registros de Kubelet y habilitar el acceso al nodo SSH.
Obtención de registros de kubelet desde nodos de
clúster de Azure Kubernetes Service (AKS)
Como parte del funcionamiento de un clúster de AKS, puede que deba revisar los registros para solucionar un
problema. Azure Portal incorpora la posibilidad de ver los registros de los componentes maestros de AKS o de
los contenedores de un clúster AKS. En ocasiones, necesitará obtener registros de kubelet de un nodo de AKS
para solucionar problemas.
En este artículo se muestra cómo puede usar journalctl para ver los registros de kubelet en un nodo de AKS.
Antes de empezar
Creación de una conexión SSH

En primer lugar, cree una conexión SSH con el nodo en el que necesita ver los registros de kubelet. Esta
operación se describe en el documento Conexión SSH con los nodos de un clúster de Azure Kubernetes Service
(AKS).
Obtención de registros de kubelet

Una vez que se ha conectado al nodo, ejecute el siguiente comando para extraer los registros de kubelet:
sudo journalctl -u kubelet -o cat
NOTE
En el caso de los nodos de Windows, los datos de registro están en C:\k y se pueden ver con el comando more:
more C:\k\kubelet.log
La siguiente salida de ejemplo muestra los datos del registro de kubelet:

I0508 12:26:17.905042 8672 kubelet_node_status.go:497] Using Node Hostname from cloudprovider: "aks-
agentpool-11482510-0"
I0508 12:26:28.920125 8672 server.go:796] GET /stats/summary: (10.370874ms) 200 [[Ruby] 10.244.0.2:52292]
I0508 12:27:05.107680 8672 server.go:796] GET /stats/summary/: (24.853838ms) 200 [[Go-http-client/1.1]
10.244.0.3:44660]
I0508 12:27:44.015205 8672 server.go:796] GET /stats/summary: (30.236824ms) 200 [[Ruby] 10.244.0.2:52588]
I0508 12:28:05.040375 8672 server.go:796] GET /stats/summary/: (27.78503ms) 200 [[Go-http-client/1.1]
10.244.0.3:44660]
Pasos siguientes
Si necesita información adicional desde el maestro de Kubernetes, consulte Habilitación y revisión de los
registros del nodo maestro de Kubernetes en Azure Kubernetes Service (AKS).
Cómo ver los registros de Kubernetes, eventos y
métricas de pods en tiempo real
Container Insights incluye la característica de datos en directo, una característica de diagnóstico avanzada que le
permite el acceso directo a los registros de contenedor (stdout/stderror), eventos y métricas de pod de Azure
Kubernetes Service (AKS). Expone acceso directo a kubectl logs -c , eventos kubectl get y kubectl top pods .
En este panel se muestra los registros, los eventos y las métricas generados por el motor de contenedores para
ayudar a solucionar problemas en tiempo real.
En este artículo se proporciona una introducción detallada y le ayuda a entender cómo usar esta característica.
Puede obtener ayuda para configurar o solucionar problemas de la característica de datos en directo en la guía
de configuración. Esta característica accede directamente a la API Kubernetes y se puede encontrar información
adicional sobre el modelo de autenticación aquí.
Visualización de los registros en vivo de recursos de AKS

Use el siguiente procedimiento para ver los registros en vivo de pods, implementaciones y conjuntos de réplicas
con o sin Container Insights en la vista de recursos de AKS.
1. En el Azure Portal, vaya al grupo de recursos de clúster de AKS y elija el recurso de AKS.
2. Seleccione Cargas de trabajo en la sección Kubernetes resources (Recursos de Kubernetes) del
menú.
3. Seleccione un pod, implementación, conjunto de réplicas en la pestaña correspondiente.
4. Seleccione Registros en vivo en el menú del recurso.
5. Seleccione un pod para iniciar la recopilación de los datos en directo.
Ver registros
Puede ver los datos de registro en tiempo real cuando se generan con el motor de contenedores en la vista
Nodos , Controladores y Contenedores . Para comprobar los datos de registro, haga lo siguiente.
2. En el panel del clúster de AKS, en Super visión a la izquierda, elija Insights .
3. Elija la pestaña Nodos , Controladores o Contenedores .
4. Seleccione un objeto de la cuadrícula de rendimiento y, en el panel de propiedades que se encuentra en el
lado derecho, seleccione la opción Ver datos en directo . Si el clúster de AKS se configura con inicio de
sesión único mediante Azure AD, deberá autenticarse en el primer uso durante esa sesión del explorador.
Seleccione la cuenta y complete la autenticación con Azure.
NOTE
Al ver los datos desde el área de trabajo de Log Analytics seleccionando la opción Vista en Analytics en el panel
Propiedades, los resultados de la búsqueda de registros podrían mostrar nodos , conjuntos de demonio
conjuntos de réplicas , trabajos , trabajos de Cron , pods y contenedores que ya no existen. También se
producirá un error al intentar buscar registros de un contenedor que no está disponible en kubectl . Revise la
característica Vista en Analytics para más información sobre cómo ver registros históricos, eventos y métricas.
Después de autenticarse correctamente, el panel de consola de datos en directo aparecerá debajo de la

cuadrícula de datos de rendimiento y podrá ver los datos de registro en un flujo continuo. Si el indicador de
estado de captura muestra una marca de verificación verde, que se encuentra en el extremo derecho del panel,
significa que pueden recuperar los datos y comienzan a transmitirse a la consola.
El título del panel muestra el nombre del pod con el que se agrupa el contenedor.
Ver eventos
Puede ver los datos de eventos en tiempo real a medida que los genera el motor de contenedor desde Nodos ,
Controladores , Contenedores e Implementaciones cuando un contenedor, pod, nodo, ReplicaSet,
DaemonSet, trabajo, CronJob o implementación está seleccionado. Para ver los eventos, haga lo siguiente.
3. Seleccione la pestaña Nodos , Controladores , Contenedores o Implementaciones .
4. Seleccione un objeto de la cuadrícula de rendimiento y, en el panel de propiedades que se encuentra en el
lado derecho, seleccione la opción Ver datos en directo . Si el clúster de AKS se configura con inicio de
NOTE

cuadrícula de datos de rendimiento. Si el indicador de estado de captura muestra una marca de verificación
verde, que se encuentra en el extremo derecho del panel, significa que pueden recuperar los datos y comienzan
a transmitirse a la consola.
Si el objeto que seleccionó era un contenedor, elija la opción Eventos en el panel. Si ha seleccionado un nodo,
pod o controlador, la visualización de eventos se selecciona automáticamente.
El título del panel muestra el nombre del pod con el que se agrupa el contenedor.
Filtrado de eventos
Durante la visualización de eventos, puede limitar además los resultados mediante la cápsula Filtro que se
encuentra a la derecha de la barra de búsqueda. Dependiendo de qué recurso haya seleccionado, la cápsula
muestra un pod, un espacio de nombres o un clúster para elegir.
Visualización de métricas
Puede ver los datos de la métrica en tiempo real cuando se generan con el motor de contenedores en la vista
Nodos o Controladores solo cuando un pod está seleccionado. Para ver las métricas, haga lo siguiente.
3. Elija la pestaña Nodos o Controladores .
4. Seleccione un objeto pod de la cuadrícula de rendimiento y, en el panel de propiedades que se encuentra
en el lado derecho, elija la opción Ver datos en directo . Si el clúster de AKS se configura con inicio de
NOTE

cuadrícula de datos de rendimiento. Los datos de métricas se recuperan y comienzan a transmitirse a la consola
para su presentación en los dos gráficos. El título del panel muestra el nombre del pod con el que se agrupa el
contenedor.
Uso de las vistas de datos en directo

En las secciones siguientes se describe la funcionalidad que puede usar en las diferentes vistas de datos en
directo.
Search
La característica de datos en directo incluye la funcionalidad de búsqueda. En el campo Búsqueda , puede filtrar
los resultados escribiendo una palabra clave o término, los resultados coincidentes se resaltan para permitir una
revisión rápida. Durante la visualización de eventos, puede limitar además los resultados mediante la cápsula
Filtro que se encuentra a la derecha de la barra de búsqueda. Dependiendo de qué recurso haya seleccionado,
la cápsula muestra un pod, un espacio de nombres o un clúster para elegir.
Desplácese, bloquee y pause

Para suspender el desplazamiento automático y controlar el comportamiento del panel, de forma que pueda
desplazarse manualmente por lo nuevos datos leídos, haga clic en la opción Desplazar . Para volver a habilitar
el desplazamiento automático, vuelva a hacer clic en la opción Desplazar . También puede pausar la
recuperación de datos de registros o eventos si hace clic en la opción Pausar ; cuando esté listo para reanudar,
simplemente haga clic en Reproducir .
IMPORTANT
Se recomienda suspender o pausar el desplazamiento automático solo durante un breve período de tiempo mientras se
soluciona un problema. Estas solicitudes pueden afectar la disponibilidad y limitación de la API de Kubernetes en el clúster.
IMPORTANT
Durante el funcionamiento de esta característica, no se almacenan datos de forma permanente. Toda la información
capturada durante la sesión se elimina al cerrar el explorador o salir de ella. Los datos solo permanecen presentes para su
visualización en el período de cinco minutos de la característica de métricas; también se eliminan las métricas con una
antigüedad superior a cinco minutos. El búfer de datos en directo se consulta dentro de los límites de uso de memoria
razonables.
Pasos siguientes
Para continuar aprendiendo a usar Azure Monitor y supervisar otros aspectos de su clúster de AKS,
consulte Comprender el rendimiento del clúster de AKS con Azure Monitor para contenedores.
Vea ejemplos de consultas de registro para ver ejemplos y consultas predefinidas para crear alertas,
visualizaciones o realizar análisis adicionales de los clústeres.
Creación de un contenedor de Windows Server en
mediante la CLI de Azure
administrar clústeres rápidamente. En este artículo, implementará un clúster de AKS mediante la CLI de Azure.
También implementará una aplicación de ejemplo de ASP.NET en un contenedor de Windows Server en el
clúster.
En este artículo se presupone un conocimiento básico de los conceptos de Kubernetes. Para más información,
Requisitos previos

Limitaciones
nodos:
No puede eliminar el primer grupo de nodos.
Se aplican las siguientes limitaciones adicionales a los grupos de nodos de Windows Server:
El clúster de AKS puede tener un máximo de 10 grupos de nodos.
El clúster de AKS puede tener un máximo de 100 nodos en cada grupo de nodos.
El nombre del grupo de nodos de Windows Server tiene un límite de 6 caracteres.

Cuando se crea un grupo de recursos, se le pide que especifique una ubicación. Dicha ubicación es donde se
almacenan los metadatos del grupo de recursos, así como el lugar en el que los recursos se ejecutan en Azure si
no se especifica otra región al crear los recursos. Cree un grupo de recursos con el comando az group create.
En el ejemplo siguiente, se crea un grupo de recursos denominado myResourceGroup en la ubicación eastus.
NOTE
En este artículo se utiliza sintaxis de Bash para los comandos del tutorial. Si usa Azure Cloud Shell, asegúrese de que la
lista desplegable de la superior izquierda de la ventana de Cloud Shell está establecida en Bash .
En la siguiente salida de ejemplo se muestra que los recursos se crearon correctamente:
{
"id": "/subscriptions/<guid>/resourceGroups/myResourceGroup",
"managedBy": null,
"name": "myResourceGroup",
"properties": {
},
"tags": null,
"type": null
}

Para ejecutar un clúster de AKS que admita grupos de nodos para contenedores de Windows Server, el clúster
debe utilizar una directiva de red que use el complemento de red (avanzado) de Azure CNI. Para más
información que le ayude a planear los intervalos de subred necesarios y las consideraciones de red, vea
Configuración de redes de Azure CNI. Use el comando az aks create para crear un clúster de AKS denominado
myAKSCluster. Este comando creará los recursos de red necesarios en caso de que no existan.
El clúster se configura con dos nodos.
Los parámetros --windows-admin-password y --windows-admin-username establecen las credenciales de
administrador para los nodos de Windows Server del clúster y deben satisfacer los requisitos de contraseña
de Windows Server. Si no especifica el parámetro windows-admin-password, se le pedirá que proporcione
un valor.
El grupo de nodos usa VirtualMachineScaleSets .
NOTE
Para asegurarse de que el clúster funcione de forma confiable, debe ejecutar al menos 2 (dos) nodos del grupo de nodos
predeterminado.
Cree un nombre de usuario para usarlo como credenciales de administrador para los nodos de Windows Server
en el clúster. Los comandos siguientes le solicitan un nombre de usuario y lo establecen en
WINDOWS_USERNAME para su uso en un comando posterior (recuerde que los comandos de este artículo se
incluyen en un shell de BASH).
echo "Please enter the username to use as administrator credentials for Windows Server nodes on your
cluster: " && read WINDOWS_USERNAME
Cree el clúster y asegúrese de especificar el parámetro --windows-admin-username . El siguiente comando de

ejemplo crea un clúster con el valor de WINDOWS_USERNAME establecido en el comando anterior. También,
puede proporcionar un nombre de usuario diferente directamente en el parámetro, en lugar de usar
WINDOWS_USERNAME. El siguiente comando también le pedirá que cree una contraseña para las credenciales
de administrador de los nodos de Windows Server en el clúster. Como alternativa, puede usar el parámetro
windows-admin-password y especificar aquí su propio valor.
az aks create \
--node-count 2 \
--enable-addons monitoring \
--windows-admin-username $WINDOWS_USERNAME \
--network-plugin azure
NOTE
Si recibe un error de validación de contraseña, compruebe que el parámetro establecido cumple los requisitos de
contraseña de Windows Server. Si la contraseña cumple los requisitos, pruebe a crear el grupo de recursos en otra región.
A continuación, intente crear el clúster con el nuevo grupo de recursos.
Si no especifica un nombre de usuario y una contraseña de administrador al establecer
--vm-set-type VirtualMachineScaleSets y --network-plugin azure , el nombre de usuario se establece en
azureuser y la contraseña se establece en un valor aleatorio.
No se puede cambiar el nombre de usuario del administrador, pero puede cambiar la contraseña de administrador que el
clúster de AKS usa para los nodos de Windows Server mediante az aks update . Para más información, consulte
Preguntas frecuentes sobre los grupos de nodos de Windows Server.
En ocasiones, el clúster puede tardar más de unos minutos en aprovisionarse. Espere hasta 10 minutos en estos
casos.
Adición de un grupo de nodos de Windows Server
De forma predeterminada, se crea un clúster de AKS con un grupo de nodos que puede ejecutar contenedores
de Linux. Utilice el comando az aks nodepool add para agregar un grupo de nodos adicionales que pueda
ejecutar contenedores de Windows Server en combinación con el grupo de nodos de Linux.

--os-type Windows \
--name npwin \
--node-count 1
El comando anterior crea un nuevo grupo de nodos denominado npwin y lo agrega a myAKSCluster. Al crear un
grupo de nodos para ejecutar contenedores de Windows Server, el valor predeterminado para node-vm-size es
Standard_D2s_v3. Si decide establecer el parámetro node-vm-size, compruebe la lista de tamaños de máquina
virtual restringidos. El tamaño mínimo recomendado es Standard_D2s_v3. El comando anterior también usa la
subred predeterminada en la red virtual predeterminada que se crea al ejecutar az aks create .
Para administrar un clúster de Kubernetes, usará kubectl, el cliente de línea de comandos de Kubernetes. Si usa
Azure Cloud Shell, kubectl ya está instalado. Para instalar kubectl localmente, use el comando az aks install-
cli:
az aks install-cli
este comando se descargan las credenciales y se configura la CLI de Kubernetes para usarlas.
clúster.
kubectl get nodes
La siguiente salida de ejemplo muestra todos los nodos del clúster. Asegúrese de que el estado de todos los
nodos sea Listo:

aks-nodepool1-12345678-vmssfedcba Ready agent 13m v1.16.9
aksnpwin987654 Ready agent 108s v1.16.9
Un archivo de manifiesto de Kubernetes define un estado deseado del clúster, por ejemplo, qué imágenes de
contenedor se van a ejecutar. En este artículo, se utiliza un manifiesto para crear todos los objetos necesarios
para ejecutar la aplicación de ejemplo de ASP.NET en un contenedor de Windows Server. Este manifiesto incluye
una implementación de Kubernetes para la aplicación de ejemplo de ASP.NET y un servicio de Kubernetes
externo para acceder a la aplicación desde Internet.
La aplicación de ejemplo de ASP.NET se proporciona como parte de los ejemplos de .NET Framework y se
ejecuta en un contenedor de Windows Server. AKS requiere contenedores de Windows Server que se basen en
las imágenes de Windows Server 2019 u otra versión posterior. El archivo de manifiesto de Kubernetes también
debe definir un selector de nodos que le indique al clúster de AKS que ejecute el pod de la aplicación de ejemplo
de ASP.NET en un nodo que pueda ejecutar contenedores de Windows Server.
Cree un archivo denominado sample.yaml y cópielo en la siguiente definición de código YAML. Si usa Azure
Cloud Shell, este archivo se puede crear mediante vi o nano como si funcionara en un sistema físico o virtual:
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample
labels:
app: sample
spec:
replicas: 1
template:
metadata:
name: sample
labels:
app: sample
spec:
nodeSelector:
"beta.kubernetes.io/os": windows
containers:
- name: sample
image: mcr.microsoft.com/dotnet/framework/samples:aspnetapp
resources:
limits:
cpu: 1
memory: 800M
requests:
cpu: .1
memory: 300M
ports:
- containerPort: 80
selector:
matchLabels:
app: sample
---
apiVersion: v1
kind: Service
metadata:
name: sample
spec:
type: LoadBalancer
ports:
- protocol: TCP
port: 80
selector:
app: sample
Implemente la aplicación mediante el comando kubectl apply y especifique el nombre del manifiesto de YAML:
kubectl apply -f sample.yaml
En la salida de ejemplo siguiente se muestran las implementaciones y los servicios creados correctamente:
deployment.apps/sample created
service/sample created
proceso puede tardar unos minutos en completarse. En ocasiones, el servicio puede tardar más de unos
minutos en aprovisionarse. Espere hasta 10 minutos en estos casos.
kubectl get service sample --watch
En un primer momento, el parámetro EXTERNAL-IP del servicio de ejemplo se muestra como pendiente.

sample LoadBalancer 10.0.37.27 <pending> 80:30572/TCP 6s
sample LoadBalancer 10.0.37.27 52.179.23.131 80:30572/TCP 2m
Para ver la aplicación de ejemplo en acción, abra un explorador web en la dirección IP externa del servicio.
NOTE
Si se agota el tiempo de espera de conexión al intentar cargar la página, debe comprobar que la aplicación de ejemplo
esté lista con el siguiente comando [kubectl get pods --watch]. A veces, el contenedor Windows no se habrá iniciado en el
momento en que la dirección IP externa esté disponible.
Cuando el clúster ya no se necesite, puede usar el comando az group delete para eliminar el grupo de recursos,
el servicio de contenedor y todos los recursos relacionados.
NOTE
eliminación de AKS. Si usó una identidad administrada, esta está administrada por la plataforma y no requiere que la
quite.
Pasos siguientes
En este artículo, ha implementado un clúster de Kubernetes y una aplicación de ejemplo de ASP.NET en un
contenedor de Windows Server de este. Acceda al panel web de Kubernetes del clúster que acaba de crear.
Tutorial de AKS
Creación de un contenedor de Windows Server en
mediante PowerShell
administrar clústeres rápidamente. En este artículo, implementará un clúster de AKS mediante PowerShell.
También implementará una aplicación de ejemplo de ASP.NET en un contenedor de Windows Server en el
clúster.
En este artículo se presupone un conocimiento básico de los conceptos de Kubernetes. Para más información,
Prerrequisitos
Si decide usar PowerShell de forma local, para este artículo es preciso que instale el módulo Az PowerShell y
que se conecte a su cuenta de Azure con el cmdlet Connect-AzAccount. Para más información sobre cómo
instalar el módulo Az PowerShell, consulte Instalación de Azure PowerShell. También debe instalar el módulo
Az.Aks de PowerShell:
Install-Module Az.Aks
Uso de Azure Cloud Shell
En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el
explorador. Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar
los comandos preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada
en su entorno local.
Para iniciar Azure Cloud Shell:
O P C IÓ N E JEM P LO O VÍN C ULO
Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se
copia automáticamente el código en Cloud Shell.
Vaya a https://shell.azure.com o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.
Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.
Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si tiene varias suscripciones a Azure, elija la suscripción adecuada en la que se debe facturar el recurso.
Seleccione un identificador de suscripción específico con el cmdlet Set-AzContext.
Set-AzContext -SubscriptionId 00000000-0000-0000-0000-000000000000
Limitaciones
nodos:
No puede eliminar el primer grupo de nodos.
Se aplican las siguientes limitaciones adicionales a los grupos de nodos de Windows Server:
El clúster de AKS puede tener un máximo de 10 grupos de nodos.
El clúster de AKS puede tener un máximo de 100 nodos en cada grupo de nodos.
El nombre del grupo de nodos de Windows Server tiene un límite de 6 caracteres.

Cuando se crea un grupo de recursos, se le pide que especifique una ubicación. Dicha ubicación es donde se
almacenan los metadatos del grupo de recursos, así como el lugar en el que los recursos se ejecutan en Azure si
no se especifica otra región al crear los recursos. Cree un grupo de recursos con el cmdlet New-
AzResourceGroup.
En el ejemplo siguiente, se crea un grupo de recursos denominado myResourceGroup en la ubicación eastus .
NOTE
En este artículo se utiliza sintaxis de PowerShell para los comandos del tutorial. Si usa Azure Cloud Shell, asegúrese de que
la lista desplegable de la parte superior izquierda de la ventana de Cloud Shell está establecida en PowerShell.
New-AzResourceGroup -Name myResourceGroup -Location eastus
ResourceGroupName : myResourceGroup
Location : eastus
ProvisioningState : Succeeded
Tags :
ResourceId : /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup

Use la utilidad de línea de comandos ssh-keygen para generar un par de claves SSH. Para más información,
consulte Pasos rápidos: Creación y uso de un par de claves pública-privada SSH para máquinas virtuales Linux
en Azure.
Para ejecutar un clúster de AKS que admita grupos de nodos para contenedores de Windows Server, el clúster
debe utilizar una directiva de red que use el complemento de red (avanzado) de Azure CNI. Para más
información que le ayude a planear los intervalos de subred necesarios y las consideraciones de red, vea
Configuración de redes de Azure CNI. Use el cmdlet New-AzAks siguiente para crear un clúster de AKS
denominado myAKSCluster . En el ejemplo siguiente se crean los recursos de red necesarios en caso de que no
existan.
NOTE
Para asegurarse de que el clúster funcione de forma confiable, debe ejecutar al menos 2 (dos) nodos del grupo de nodos
predeterminado.
$Username = Read-Host -Prompt 'Please create a username for the administrator credentials on your Windows
Server containers: '
$Password = Read-Host -Prompt 'Please create a password for the administrator credentials on your Windows
Server containers: ' -AsSecureString
New-AzAksCluster -ResourceGroupName myResourceGroup -Name myAKSCluster -NodeCount 2 -NetworkPlugin azure -
NodeVmSetType VirtualMachineScaleSets -WindowsProfileAdminUserName $Username -
WindowsProfileAdminUserPassword $Password
NOTE
Si no puede crear el clúster de AKS porque la versión no se admite en esta región, puede usar el comando
Get-AzAksVersion -Location eastus para encontrar la lista de versiones admitidas en esta región.
En ocasiones, el clúster puede tardar más de unos minutos en aprovisionarse. Espere hasta 10 minutos en estos
casos.
Adición de un grupo de nodos de Windows Server

De forma predeterminada, se crea un clúster de AKS con un grupo de nodos que puede ejecutar contenedores
de Linux. Utilice el cmdlet New-AzAksNodePool para agregar un grupo de nodos que pueda ejecutar contenedores
de Windows Server en combinación con el grupo de nodos de Linux.
New-AzAksNodePool -ResourceGroupName myResourceGroup -ClusterName myAKSCluster -VmSetType

VirtualMachineScaleSets -OsType Windows -Name npwin
El comando anterior crea un nuevo grupo de nodos denominado npwin y lo agrega a myAKSCluster . Al crear
un grupo de nodos para ejecutar contenedores de Windows Server, el valor predeterminado para VmSize es
Standard_D2s_v3 . Si decide establecer el parámetro VmSize , compruebe la lista de tamaños de máquina
virtual restringidos. El tamaño mínimo recomendado es Standard_D2s_v3 . El comando anterior también usa
la subred predeterminada en la red virtual predeterminada que se crea al ejecutar New-AzAks .
Azure Cloud Shell, kubectl ya está instalado. Para instalar kubectl localmente, use el cmdlet
Install-AzAksKubectl :
Install-AzAksKubectl
Para configurar kubectl para conectarse al clúster de Kubernetes, use el cmdlet Import-AzAksCredential. Con
Import-AzAksCredential -ResourceGroupName myResourceGroup -Name myAKSCluster
clúster.
kubectl get nodes
La siguiente salida de ejemplo muestra todos los nodos del clúster. Asegúrese de que el estado de todos los
nodos sea Listo :

aks-nodepool1-12345678-vmssfedcba Ready agent 13m v1.16.7
aksnpwin987654 Ready agent 108s v1.16.7
contenedor se van a ejecutar. En este artículo, se utiliza un manifiesto para crear todos los objetos necesarios
para ejecutar la aplicación de ejemplo de ASP.NET en un contenedor de Windows Server. Este manifiesto incluye
una implementación de Kubernetes para la aplicación de ejemplo de ASP.NET y un servicio de Kubernetes
externo para acceder a la aplicación desde Internet.
La aplicación de ejemplo de ASP.NET se proporciona como parte de los ejemplos de .NET Framework y se
ejecuta en un contenedor de Windows Server. AKS requiere contenedores de Windows Server que se basen en
las imágenes de Windows Ser ver 2019 u otra versión posterior. El archivo de manifiesto de Kubernetes
también debe definir un selector de nodos que le indique al clúster de AKS que ejecute el pod de la aplicación de
ejemplo de ASP.NET en un nodo que pueda ejecutar contenedores de Windows Server.
Cree un archivo denominado sample.yaml y cópielo en la siguiente definición de código YAML. Si usa Azure
Cloud Shell, este archivo se puede crear mediante vi o nano como si funcionara en un sistema físico o virtual:
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample
labels:
app: sample
spec:
replicas: 1
template:
metadata:
name: sample
labels:
app: sample
spec:
nodeSelector:
"beta.kubernetes.io/os": windows
containers:
- name: sample
image: mcr.microsoft.com/dotnet/framework/samples:aspnetapp
resources:
limits:
cpu: 1
memory: 800M
requests:
cpu: .1
memory: 300M
ports:
- containerPort: 80
selector:
matchLabels:
app: sample
---
apiVersion: v1
kind: Service
metadata:
name: sample
spec:
type: LoadBalancer
ports:
- protocol: TCP
port: 80
selector:
app: sample
kubectl apply -f sample.yaml
deployment.apps/sample created
service/sample created
proceso puede tardar unos minutos en completarse. En ocasiones, el servicio puede tardar más de unos
minutos en aprovisionarse. Espere hasta 10 minutos en estos casos.
kubectl get service sample --watch
En un primer momento, el parámetro EXTERNAL-IP del servicio de ejemplo se muestra como pendiente .

sample LoadBalancer 10.0.37.27 <pending> 80:30572/TCP 6s
Cuando la dirección EXTERNAL-IP cambie de pendiente a una dirección IP pública real, use CTRL-C para
detener el proceso de inspección de kubectl . En la salida del ejemplo siguiente se muestra una dirección IP
pública válida asignada al servicio:
sample LoadBalancer 10.0.37.27 52.179.23.131 80:30572/TCP 2m
Para ver la aplicación de ejemplo en acción, abra un explorador web en la dirección IP externa del servicio.
NOTE
Si se agota el tiempo de espera de conexión al intentar cargar la página, debe comprobar que la aplicación de ejemplo
esté lista con el siguiente comando: kubectl get pods --watch . A veces, el contenedor Windows no se habrá iniciado
en el momento en que la dirección IP externa esté disponible.
Cuando el clúster ya no se necesite, use el comando Remove-AzResourceGroup para eliminar el grupo de
recursos, el servicio de contenedor y todos los recursos relacionados.
Remove-AzResourceGroup -Name myResourceGroup
NOTE
quite.
Pasos siguientes
En este artículo, ha implementado un clúster de Kubernetes y una aplicación de ejemplo de ASP.NET en un
contenedor de Windows Server de este. Acceda al panel web de Kubernetes del clúster que ha creado.
Tutorial de AKS
Conexión con RDP a los nodos de Windows Server
de clúster de Azure Kubernetes Service (AKS) para
el mantenimiento o la solución de problemas
Durante el ciclo de vida del clúster de Azure Kubernetes Service (AKS), es posible que necesite acceder a un
nodo de Windows Server de AKS. Este acceso podría ser para mantenimiento, recopilación de registros u otras
operaciones de solución de problemas. Puede acceder a los nodos de Windows Server de AKS mediante
conexión RDP. Como alternativa, si desea usar SSH para acceder a los nodos de Windows Server de AKS y tiene
acceso al mismo par de claves que se usó durante la creación del clúster, puede seguir los pasos descritos en
Conexión SSH a los nodos de clúster de Azure Kubernetes Service (AKS). Por motivos de seguridad, los nodos de
AKS no están expuestos a Internet.
En este artículo se muestra cómo crear una conexión RDP con un nodo de AKS mediante sus direcciones IP
privadas.
Antes de empezar
En este artículo se presupone que ya tiene un clúster de AKS con un nodo de Windows Server. Si necesita un
clúster de AKS, consulte el artículo sobre la creación de un clúster de AKS con un contenedor de Windows
mediante la CLI de Azure. Necesitará el nombre de usuario de administrador de Windows y la contraseña para
el nodo de Windows Server cuyos problemas quiera solucionar. Si no los recuerda, puede restablecerlos con las
instrucciones de Restablecer los Servicios de Escritorio remoto o su contraseña de administrador en una
máquina virtual Windows. También necesitará un cliente RDP, como Escritorio remoto de Microsoft.
Azure.
Implementación de una máquina virtual en la misma subred que el

clúster
Los nodos de Windows Server del clúster de AKS no tienen direcciones IP accesibles externamente. Para realizar
una conexión RDP, puede implementar una máquina virtual con una dirección IP accesible públicamente en la
misma subred que los nodos de Windows Server.
En el siguiente ejemplo se crea una máquina virtual llamada myVM en el grupo de recursos myResourceGroup.
En primer lugar, obtenga la subred que usa el grupo de nodos de Windows Server. Para obtener el identificador
de la subred, se necesita el nombre de esta. Para obtener el nombre de la subred, se necesita el nombre de la red
virtual. Obtenga el nombre de la red virtual mediante una consulta sobre su lista de redes al clúster. Para
consultar el clúster, necesita su nombre. Puede obtener todos estos datos si ejecuta lo siguiente en Azure Cloud
Shell:
CLUSTER_RG=$(az aks show -g myResourceGroup -n myAKSCluster --query nodeResourceGroup -o tsv)

VNET_NAME=$(az network vnet list -g $CLUSTER_RG --query [0].name -o tsv)
SUBNET_NAME=$(az network vnet subnet list -g $CLUSTER_RG --vnet-name $VNET_NAME --query [0].name -o tsv)
SUBNET_ID=$(az network vnet subnet show -g $CLUSTER_RG --vnet-name $VNET_NAME --name $SUBNET_NAME --query id
-o tsv)
Ahora que tiene el SUBNET_ID, ejecute el siguiente comando en la misma ventana de Azure Cloud Shell para
crear la máquina virtual:
az vm create \
--name myVM \
--image win2019datacenter \
--admin-username azureuser \
--admin-password myP@ssw0rd12 \
--subnet $SUBNET_ID \
--query publicIpAddress -o tsv
La salida del siguiente ejemplo muestra que la máquina virtual se ha creado correctamente y muestra su
dirección IP pública.
13.62.204.18
Registre la dirección IP pública de la máquina virtual, la usará en un paso posterior.
Permitir el acceso a la máquina virtual

De forma predeterminada, las subredes de los grupos de nodos de AKS están protegidas con grupos de
seguridad de red. Para obtener acceso a la máquina virtual, tendrá que habilitar el acceso en el grupo de
seguridad de red.
NOTE
Los grupos de seguridad de red se controlan mediante el servicio AKS. El plano de control sobrescribirá en cualquier
momento los cambios que realice en el grupo de seguridad de red.
En primer lugar, obtenga el grupo de recursos y el nombre del grupo de seguridad de red al que va a agregar la
regla:

NSG_NAME=$(az network nsg list -g $CLUSTER_RG --query [].name -o tsv)
A continuación, cree la regla del grupo de seguridad de red:
az network nsg rule create --name tempRDPAccess --resource-group $CLUSTER_RG --nsg-name $NSG_NAME --priority
100 --destination-port-range 3389 --protocol Tcp --description "Temporary RDP access to Windows nodes"
Obtención de la dirección del nodo

cli:
az aks install-cli
Enumere la dirección IP interna de los nodos de Windows Server con el comando kubectl get:
kubectl get nodes -o wide
La salida del ejemplo siguiente muestra las direcciones IP internas de todos los nodos del clúster, incluidos los
nodos de Windows Server.
$ kubectl get nodes -o wide

aks-nodepool1-42485177-vmss000000 Ready agent 18h v1.12.7 10.240.0.4 <none> Ubuntu
16.04.6 LTS 4.15.0-1040-azure docker://3.0.4
aksnpwin000000 Ready agent 13h v1.12.7 10.240.0.67 <none> Windows
Server Datacenter 10.0.17763.437
Registre la dirección IP interna del nodo de Windows Server cuyos problemas desee solucionar, la usará en un
paso posterior.
Conexión a la máquina virtual y al nodo

Conéctese a la dirección IP pública de la máquina virtual que creó antes mediante un cliente con conexión RDP,
como Escritorio remoto de Microsoft.
Una vez conectado a la máquina virtual, conéctese con la dirección IP interna del nodo de Windows Server
cuyos problemas quiera solucionar con un cliente con conexión RDP desde la máquina virtual.
Ahora está conectado a su nodo de Windows Server.
Ahora puede ejecutar los comandos de la solución de problemas en la ventana de cmd. Dado que los nodos de
Windows Server usan Windows Server Core, no hay una interfaz gráfica de usuario completa ni otras
herramientas de la interfaz gráfica de usuario cuando se conecta a un nodo de Windows Server mediante una
conexión RDP.
Eliminación de la conexión RDP

Cuando haya terminado, cierre la conexión RDP con el nodo de Windows Server y salga de la sesión de RDP
para ir a la máquina virtual. Después de salir ambas sesiones de RDP, elimine la máquina virtual con el comando
az vm delete:
az vm delete --resource-group myResourceGroup --name myVM
Y la regla del grupo de seguridad de red:

NSG_NAME=$(az network nsg list -g $CLUSTER_RG --query [].name -o tsv)
az network nsg rule delete --resource-group $CLUSTER_RG --nsg-name $NSG_NAME --name tempRDPAccess
Pasos siguientes
Si necesita datos adicionales para la solución de problemas, puede ver los registros del nodo maestro de
Kubernetes o Azure Monitor.
Preguntas frecuentes sobre los grupos de nodos de
Windows Server en AKS
En Azure Kubernetes Service (AKS) puede crear un grupo de nodos que ejecuta Windows Server como sistema
operativo invitado en los nodos. Estos nodos pueden ejecutar aplicaciones de contenedor nativas de Windows,
como las integradas en .NET Framework. Hay diferencias con respecto al modo en que los sistemas operativos
Linux y Windows proporcionan compatibilidad de contenedor. Algunas características comunes de Linux
relacionadas con Kubernetes y los pods no están disponibles en este momento para los grupos de nodos de
Windows.
En este artículo se esbozan algunas de las preguntas frecuentes y los conceptos de sistema operativo sobre los
nodos de Windows Server en AKS.
¿Qué sistemas operativos de Windows se admiten?

AKS usa Windows Server 2019 como la versión del sistema operativo del host y solo admite el aislamiento de
procesos. No se admiten las imágenes de contenedor compiladas con otras versiones de Windows Server. Para
obtener más información, vea Compatibilidad con versiones de contenedores de Windows.
¿Es Kubernetes diferente en Windows y Linux?

La compatibilidad del grupo de nodos de Windows Server incluye algunas limitaciones que forman parte de
Windows Server ascendente en el proyecto de Kubernetes. Estas limitaciones no son específicas de AKS. Para
obtener más información sobre esta compatibilidad ascendente con Windows Server en Kubernetes, consulte la
sección de funcionalidades y limitaciones admitidas del documento Información sobre la compatibilidad de
Windows en Kubernetes, desde el proyecto Kubernetes.
Kubernetes se ha centrado siempre en Linux. Muchos ejemplos usados en el sitio web Kubernetes.io ascendente
están diseñados para su uso en nodos de Linux. Al crear implementaciones que usan contenedores de Windows
Server, se aplican las consideraciones siguientes en el nivel de sistema operativo:
Identidad : Linux identifica a un usuario mediante un identificador de usuario numérico de enteros (UID). Los
usuarios también tienen un nombre de usuario alfanumérico para iniciar sesión, que se convierte en Linux en
su UID. De igual forma, Linux identifica a los grupos de usuarios mediante un identificador de grupo
numérico de enteros (GID) y traduce el nombre de grupo en su GID correspondiente.
Windows Server usa un identificador de seguridad binario de mayor tamaño (SID) que se almacena
en la base de datos de Windows Security Access Manager (SAM). Esta base de datos no se comparte
entre el host y los contenedores ni entre contenedores.
Permisos de archivos : Windows Server utiliza una lista de control de acceso basada en SID, en lugar de
una máscara de bits de permisos y UID+GID.
Rutas de archivo : la convención en Windows Server consiste en usar \ en lugar de /.
En las especificaciones de pod que montan los volúmenes, especifique la ruta correctamente para los
contenedores de Windows Server. Por ejemplo, en lugar de un punto de montaje de /mnt/volume en
un contenedor de Linux, especifique la letra de unidad y la ubicación como /K/Volume para montarlo
como la unidad K: .
¿Qué tipo de discos se admiten en Windows?

Azure Disks y Azure Files son los tipos de volúmenes admitidos. Se accede a ellos como volúmenes NTFS del
contenedor de Windows Server.
¿Puedo ejecutar clústeres que sean solo de Windows en AKS?

AKS hospeda los nodos maestros (esto es, el plano de control) de un clúster de AKS en el servicio, y usted no
verá el sistema operativo de los nodos que hospedan los componentes maestros. Todos los clústeres de AKS se
crean con un primer grupo de nodos predeterminado basado en Linux. Este grupo de nodos contiene los
servicios del sistema necesarios para que el clúster funcione. Se recomienda ejecutar al menos dos nodos en el
primer grupo de nodos para garantizar la confiabilidad del clúster y que tenga la capacidad de realizar
operaciones de clúster. No se puede eliminar este primer grupo de nodos basado en Linux, a menos que se
elimine el propio clúster de AKS.
¿Cómo se aplica una revisión a los nodos de Windows?

Para obtener las revisiones más recientes de los nodos de Windows, puede actualizar el grupo de nodos o
actualizar la imagen de los nodos. Las actualizaciones de Windows no están habilitadas en los nodos de AKS.
AKS publica nuevas imágenes de los grupos de nodos en cuanto hay revisiones disponibles; es responsabilidad
de los usuarios actualizar los grupos de nodos para mantenerse al día de las revisiones y correcciones. Esto
también se aplica a la versión de Kubernetes que se esté usando. Las notas de la versión de AKS indican cuándo
hay nuevas versiones disponibles. Para obtener más información sobre la actualización del grupo de nodos
completo de Windows Server, vea Actualización de un grupo de nodos en AKS. Si solo está interesado en
actualizar la imagen de los nodos, vea Actualizaciones de imágenes de nodo de AKS.
NOTE
La imagen de Windows Server actualizada solo se usa si se ha realizado una actualización del clúster (actualización del
plano de control) antes de actualizar el grupo de nodos.
¿Qué complementos de red se admiten?

Los clústeres de AKS con grupos de nodos de Windows deben usar el modelo de redes (avanzado) de Azure
CNI. No se admiten las redes Kubenet (básico). Para obtener más información sobre las diferencias en los
modelos de redes, consulte Conceptos de redes para las aplicaciones en AKS. El modelo de redes de Azure CNI
requiere una planeación y consideraciones adicionales para la administración de direcciones IP. Para obtener
más información sobre cómo planear e implementar Azure CNI, consulte Configuración de redes de Azure CNI
en AKS.
Los nodos de Windows en los clústeres de AKS también tienen habilitado Direct Server Return (DSR) de forma
predeterminada cuando Calico está habilitado.
¿Se admite la conservación de la IP de origen del cliente?

En este momento, la conservación de la IP de origen del cliente no es compatible con los nodos de Windows.
¿Puedo cambiar el número máximo de pods por nodo?

Sí. Para conocer las implicaciones y las opciones disponibles, consulte Pods máximos por nodo.
¿Por qué se muestra un error al tratar de crear un nuevo grupo de

agentes de Windows?
Si ha creado el clúster antes de febrero de 2020 y nunca ha realizado ninguna operación de actualización, este
sigue usando una imagen de Windows antigua. Es posible que se haya mostrado un error similar al siguiente:
"No se encontró la siguiente lista de imágenes a las que se hace referencia en la plantilla de implementación:
Publicador: MicrosoftWindowsServer, Oferta: WindowsServer, SKU: 2019-datacenter-core-smalldisk-2004,
Versión: más reciente. Consulte https://docs.microsoft.com/azure/virtual-machines/windows/cli-ps-findimage
para obtener instrucciones sobre cómo buscar las imágenes disponibles".
Para corregir este error:
1. Actualice el plano de control del clúster a fin de actualizar la oferta y el publicador de la imagen.
2. Cree nuevos grupos de agentes de Windows.
3. Mueva los pods de Windows de los grupos de agentes de Windows existentes a los nuevos.
4. Elimine los grupos de agentes de Windows anteriores.
¿Cómo se realiza la rotación de la entidad de servicio para el grupo de

nodos de Windows?
Los grupos de nodos de Windows no admiten la rotación de la entidad de servicio. Para actualizar la entidad de
servicio, cree un nuevo grupo de nodos de Windows y migre los pods del grupo anterior al nuevo. Cuando
termine, elimine el grupo de nodos antiguo.
En su lugar, use identidades administradas que, básicamente, son contenedores en torno a entidades de servicio.
Para obtener más información, consulte Uso de identidades administradas en Azure Kubernetes Service.
¿Cómo cambio la contraseña de administrador de los nodos de

Windows Server en el clúster?
Al crear el clúster de AKS, se especifican los parámetros --windows-admin-password y --windows-admin-username
para establecer las credenciales de administrador de los nodos de Windows Server del clúster. Si no especificó la
credenciales de administrador como, por ejemplo, al crear un clúster mediante Azure Portal o al establecer
--vm-set-type VirtualMachineScaleSets y --network-plugin azure mediante la CLI de Azure, el nombre de
usuario tiene como valor predeterminado azureuser y una contraseña aleatoria.
Para cambiar la contraseña de administrador, use el comando az aks update :
az aks update \
--windows-admin-password $NEW_PW
IMPORTANT
Al realizar esta operación, se actualizarán todos los grupos de nodos de Windows Server. Los grupos de nodos de Linux
no se ven afectados.
Al cambiar --windows-admin-password , la nueva contraseña debe tener al menos 14 caracteres y cumplir los requisitos
de contraseña de Windows Server.
¿Cuántos grupos de nodos puedo crear?

El clúster de AKS puede tener un máximo de 10 grupos de nodos. Puede tener un máximo de 1000 nodos
distribuidos entre esos grupos de nodos. Limitaciones del grupo de nodos.
¿Qué nombre puedo usar para mis grupos de nodos de Windows?
El nombre debe tener un máximo de 6 (seis) caracteres. Esta es una limitación de AKS.
¿Son todas las características compatibles con los nodos de Windows?

Kubenet actualmente no es compatible con los nodos de Windows.
¿Puedo ejecutar controladores de entrada en los nodos de Windows?

Sí, un controlador de entrada que admita contenedores de Windows Server se puede ejecutar en nodos de
Windows en AKS.
¿Puedo usar Azure Dev Spaces con los nodos de Windows?

Azure Dev Spaces actualmente solo está disponible para grupos de nodos basados en Linux.
¿Pueden usar gMSA los contenedores de Windows Server?

La compatibilidad con las cuentas de servicio administradas de grupo (gMSA) no está disponible actualmente
en AKS.
¿Puedo usar Azure Monitor para contenedores con nodos y

contenedores de Windows?
Sí puede; no obstante, Azure Monitor se encuentra en versión preliminar pública para la recopilación de
registros (stdout, stderr) y métricas de los contenedores de Windows. También puede conectarse al streaming
en vivo de registros de stdout desde un contenedor de Windows.
¿Existe alguna limitación en el número de servicios que puede haber

en un clúster con nodos de Windows?
Un clúster con nodos de Windows puede tener aproximadamente 500 servicios antes de que se agote el puerto.
¿Puedo usar Ventaja híbrida de Azure con los nodos de Windows?

Sí. Ventaja híbrida de Azure para Windows Server reduce los costes operativos, al permitirle llevar su licencia de
Windows Server local a los nodos de Windows de AKS.
Ventaja híbrida de Azure puede usarse en todo el clúster de AKS o en nodos individuales. Para los nodos
individuales, debe navegar hasta el grupo de recursos de nodos y aplicar Ventaja híbrida de Azure directamente
a los nodos. Para obtener más información sobre cómo aplicar Ventaja híbrida de Azure a nodos individuales,
consulte Ventaja híbrida de Azure para Windows Server.
Para usar Ventaja híbrida de Azure en un nuevo clúster de AKS, use el argumento --enable-ahub .
az aks create \
--load-balancer-sku Standard \
--windows-admin-password 'Password1234$' \
--windows-admin-username azure \
--network-plugin azure
--enable-ahub
Para usar Ventaja híbrida de Azure en un clúster de AKS existente, actualice el clúster con el argumento
--enable-ahub .
az aks update \
--resource-group myResourceGroup
--name myAKSCluster
--enable-ahub
Para comprobar si se ha establecido Ventaja híbrida de Azure en el clúster, use el siguiente comando:
az vmss show --name myAKSCluster --resource-group MC_CLUSTERNAME
Si el clúster tiene Ventaja híbrida de Azure habilitada, la salida de az vmss show será similar a la siguiente:
"platformFaultDomainCount": 1,
"proximityPlacementGroup": null,
"resourceGroup": "MC_CLUSTERNAME"
¿Puedo usar el panel web de Kubernetes con los contenedores de

Windows?
Sí, puede usar el panel web de Kubernetes para acceder a la información sobre los contenedores de Windows,
pero en este momento no puede ejecutar kubectl exec en un contenedor de Windows en ejecución directamente
desde el panel web de Kubernetes. Para obtener más detalles sobre la conexión al contenedor de Windows en
ejecución, vea Conexión con RDP a los nodos de Windows Server de clúster de Azure Kubernetes Service (AKS)
para el mantenimiento o la solución de problemas.
¿Qué ocurre si necesito una característica que no se admite?

Estamos trabajando día y noche para poner a su disposición todas las características que necesite para Windows
en AKS, pero si encuentra errores, el proyecto ascendente de código abierto aks-engine, proporciona una
manera fácil y totalmente personalizable de ejecutar Kubernetes en Azure e incluye el soporte técnico de
Windows. Asegúrese de consultar el plan de desarrollo de próximas características en el Plan de desarrollo de
AKS.
Pasos siguientes
Para comenzar con los contenedores de Windows Server en AKS, cree un grupo de nodos que ejecute Windows
Server en AKS.
Acceso al panel web de Kubernetes en Azure
Kubernetes incluye un panel web que se puede usar para operaciones básicas de administración. Este panel le
permite ver el estado de mantenimiento básico y las métricas para sus aplicaciones, crear e implementar
servicios, y modificar las aplicaciones existentes. Este artículo muestra cómo acceder al panel de Kubernetes
mediante la CLI de Azure y luego lo guía por algunas operaciones básicas del panel.
Para más información sobre el panel de Kubernetes, consulte la información sobre el panel de la interfaz de
usuario web de Kubernetes. AKS usa la versión 2.0 y posterior del panel de código abierto.
WARNING
El complemento del panel de AKS está programado para quedar en desuso. Use la vista de recursos de
Kubernetes en Azure Por tal (versión preliminar) en su lugar.
El panel de Kubernetes está habilitado de forma predeterminada para los clústeres que ejecutan una versión de
Kubernetes inferior a la 1.18.
El complemento de panel se deshabilitará de forma predeterminada para todos los nuevos clústeres creados en
Kubernetes 1.18 o posterior.
A partir de Kubernetes 1.19 en versión preliminar, AKS ya no admitirá la instalación del complemento administrado
kube-dashboard.
Los clústeres actuales con el complemento habilitado no se verán afectados. Los usuarios seguirán pudiendo instalar
manualmente el panel de código abierto como software instalado por el usuario.
Antes de empezar
En los pasos que se detallan en este documento se da por hecho que ha creado un clúster de AKS y que ha
establecido una conexión kubectl con dicho clúster. Si necesita crear un clúster de AKS, consulte Inicio rápido:
Implementación de un clúster de Azure Kubernetes Service mediante la CLI de Azure.
Azure.
Deshabilitación del panel de Kubernetes

El complemento kube-dashboard está habilitado de forma predeterminada en los clústeres anteriores
a K8s 1.18 . El complemento se puede deshabilitar ejecutando el siguiente comando.
az aks disable-addons -g myRG -n myAKScluster -a kube-dashboard
Inicio del panel de Kubernetes

WARNING
El complemento del panel de AKS está en desuso para las versiones 1.19 +. Use la vista de recursos de Kubernetes en
Azure Portal (versión preliminar) en su lugar.
El siguiente comando abrirá ahora la vista de recursos de Azure Portal en lugar del panel de Kubernetes para las
versiones 1.19 y posteriores.
Para iniciar el panel de Kubernetes en un clúster, use el comando az aks browse. Este comando requiere la
instalación del complemento kube-dashboard en el clúster, que se incluye de forma predeterminada en los
clústeres que ejecutan cualquier versión anterior a Kubernetes 1.18.
El ejemplo siguiente abre el panel para el clúster denominado myAKSCluster en el grupo de recursos
az aks browse --resource-group myResourceGroup --name myAKSCluster
Este comando crea a un proxy entre el sistema de desarrollo y la API de Kubernetes y abre un explorador web en
el panel de Kubernetes. Si un explorador web no se abre en el panel de Kubernetes, copie y pegue la dirección
URL que anotó en la CLI de Azure, normalmente http://127.0.0.1:8001 .
NOTE
Si no ve el panel en http://127.0.0.1:8001 , puede enrutar manualmente a las siguientes direcciones. Los clústeres que
ejecutan la versión 1.16 o posterior usan HTTPS y requieren un punto de conexión independiente.
K8s 1.16 o posterior:
http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy
K8s 1.15 y anterior:
http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard:/proxy
Inicio de sesión en el panel (kubernetes 1.16 o posterior)

IMPORTANT
A partir de la versión 1.10.1 del panel de Kubernetes o la versión 1.16 o posterior de Kubernetes, la cuenta de servicio
"kubernetes-dashboard" ya no se puede usar para recuperar recursos debido a una corrección de seguridad en esa
versión. Como resultado, las solicitudes sin información de autenticación devuelven un error 401 no autorizado. Un token
de portador recuperado de una cuenta de servicio puede seguir utilizándose como en este ejemplo del panel de
Kubernetes, pero esto afecta al flujo de inicio de sesión del complemento del panel en comparación con versiones
anteriores.
Si sigue ejecutando una versión anterior a la 1.16, todavía puede conceder permisos a la cuenta de servicio "kubernetes-
dashboard", pero no se recomienda :
kubectl create clusterrolebinding kubernetes-dashboard --clusterrole=cluster-admin --

serviceaccount=kube-system:kubernetes-dashboard
La pantalla inicial presentada requiere un archivo kubeconfig o un token. Ambas opciones requieren permisos
de recursos para mostrar esos recursos en el panel.
Uso de un archivo kubeconfig
En el caso de los clústeres tanto habilitados como no habilitados para Azure AD, se puede pasar un archivo
kubeconfig. Asegúrese de que los tokens de acceso sean válidos. Si los tokens han expirado, puede actualizarlos
a través de kubectl.
1. Establezca el archivo kubeconfig de administración con
az aks get-credentials -a --resource-group <RG_NAME> --name <CLUSTER_NAME> .
2. Seleccione Kubeconfig y haga clic en Choose kubeconfig file para abrir el selector de archivos.
3. Seleccione el archivo kubeconfig (de forma predeterminada, se encuentra en $HOME/.kube/config).
Uso de un token
1. En el caso de los clústeres no habilitados para Azure AD , ejecute kubectl config view y copie el token
asociado a la cuenta de usuario del clúster.
2. Péguelo en la opción de token en el inicio de sesión.
En el caso de los clústeres habilitados para Azure AD, recupere el token de AAD con el siguiente comando.
Compruebe que ha reemplazado el grupo de recursos y el nombre del clúster en el comando.
## Update <RESOURCE_GROUP and <AKS_NAME> with your input.
kubectl config view -o jsonpath='{.users[?(@.name == "clusterUser_<RESOURCE GROUP>_<AKS_NAME>")].user.auth-

provider.config.access-token}'
Una vez que se realiza correctamente, se mostrará una página similar a la siguiente.
Crear una aplicación
Los pasos siguientes requieren que el usuario tenga permisos para los recursos respectivos.
Para ver cómo el panel de Kubernetes puede reducir la complejidad de las tareas de administración, vamos a
crear una aplicación. Puede crear una aplicación desde el panel de Kubernetes, ya sea proporcionando la entrada
de texto, un archivo YAML o mediante un asistente gráfico.
Para crear una aplicación, realice los pasos siguientes:
1. Seleccione el botón Crear de la ventana superior derecha.
2. Para usar el asistente para gráficos, elija Crear una aplicación .
3. Proporcione un nombre para la implementación, por ejemplo nginx
4. Escriba el nombre de la imagen de contenedor que se utilizará, como nginx:1.15.5
5. Para exponer el puerto 80 para el tráfico web, cree un servicio de Kubernetes. En Ser vice (Servicio),
seleccione External (Externo) y escriba 80 tanto para el puerto como para el puerto de destino.
6. Cuando esté preparado, seleccione Implementar para crear la aplicación.
Se tarda un minuto o dos en que una dirección IP externa pública se asigne al servicio de Kubernetes. A la
izquierda, bajo Discover y and Load Balancing (Detección y equilibrio de carga), seleccione Ser vicios . Se
muestra el servicio de la aplicación, incluidos los puntos de conexión externos, como se muestra en el ejemplo
siguiente:
Seleccione la dirección de punto de conexión para abrir una ventana del explorador web con la página
predeterminada de NGINX:
Visualización de la información de pod
El panel de Kubernetes puede proporcionar métricas de supervisión básicas e información para solución de
problemas como los registros.
Para más información acerca de los pods de aplicación, seleccione Pods en el menú izquierdo. Se muestra una
lista de los pods disponibles. Elija su pod nginx para ver información, por ejemplo, del consumo de recursos:
Edición de aplicación
Además de crear y visualizar las aplicaciones, el panel de Kubernetes puede utilizarse para editar y actualizar las
implementaciones de aplicaciones. Para proporcionar redundancia adicional para la aplicación, vamos a
aumentar el número de réplicas de NGINX.
Para editar una implementación:
1. Seleccione Deployments (Implementaciones) en el menú izquierdo y, a continuación, elija su
implementación de nginx.
2. Seleccione Edit (Editar) en la barra de navegación superior derecha.
3. Busque el valor de spec.replica , en torno a la línea 20. Para aumentar el número de réplicas de la
aplicación, cambie este valor de 1 a 3.
4. Seleccione Update (Actualizar) cuando esté listo.
Se tarda unos minutos en que los nuevos pods se creen dentro de un conjunto de réplicas. En el menú
izquierdo, elija Replica Sets (Conjuntos de réplicas) y, a continuación, elija su conjunto de réplicas de nginx. La
lista de los pods ahora refleja el número de réplicas actualizado, como se muestra en la salida del ejemplo
siguiente:
Pasos siguientes
Para más información sobre el panel de Kubernetes, consulte el panel de la interfaz de usuario web de
Kubernetes.
Instalación de aplicaciones existentes con Helm en
Helm es una herramienta de empaquetado de código abierto que ayuda a instalar y administrar el ciclo de vida
de las aplicaciones de Kubernetes. Helm, que funciona de forma similar a los administradores de paquetes de
Linux como APT y Yum, se utiliza para administrar los gráficos de Kubernetes, que son paquetes de recursos de
Kubernetes preconfigurados.
En este artículo se muestra cómo configurar y usar Helm en un clúster de Kubernetes en AKS.
Antes de empezar
También necesita tener instalada la CLI de Helm, que es el cliente que se ejecuta en el sistema de desarrollo.
Permite iniciar, detener y administrar las aplicaciones con Helm. Si usa Azure Cloud Shell, la CLI de Helm ya está
instalada. Para obtener las instrucciones de instalación en su plataforma local, consulte Instalación de Helm.
IMPORTANT
Helm está diseñada para ejecutarse en nodos de Linux. Si tiene nodos de Windows Server en el clúster, debe asegurarse
de que los pods de Helm solo se programan para ejecutarse en nodos de Linux. También deberá asegurarse de que todos
los gráficos de Helm que instale están programados también para ejecutarse en los nodos correctos. Los comandos de
este artículo utilizan selectores de nodo [k8s-node-selector] para asegurarse de que los pods están programados para los
nodos correctos, pero no todos los gráficos de Helm pueden exponer un selector de nodo. También puede considerar
otras opciones en el clúster, como los valores taints.
Comprobación de la versión de Helm

Use el comando helm version para comprobar que tiene Helm 3 instalado:
helm version
En el siguiente ejemplo se muestra la versión 3.0.0 de Helm instalada:
$ helm version
version.BuildInfo{Version:"v3.0.0", GitCommit:"e29ce2a54e96cd02ccfce88bee4f58bb6e2a28b6",
GitTreeState:"clean", GoVersion:"go1.13.4"}
Instalación de una aplicación con Helm v3

Adición de repositorios de Helm
Use el comando helm repo para agregar el repositorio ingress-nginx.
Búsqueda de gráficos de Helm

Los gráficos de Helm se usan para implementar aplicaciones en un clúster de Kubernetes. Para buscar los
gráficos de Helm creados previamente, use el comando helm search:
helm search repo ingress-nginx
En la siguiente salida de ejemplo condensada se muestran algunos de los gráficos de Helm disponibles para
usar:
$ helm search repo ingress-nginx
NAME CHART VERSION APP VERSION DESCRIPTION

ingress-nginx/ingress-nginx 2.12.0 0.34.1 Ingress controller for Kubernetes using
NGINX a...
Para actualizar la lista de gráficos, use el comando helm repo update.
helm repo update
El ejemplo siguiente muestra una actualización de repositorio correcta:
$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "ingress-nginx" chart repository
Update Complete. Happy Helming!
Ejecución de gráficos de Helm

Para instalar los gráficos con Helm, use el comando helm install y especifique un nombre de versión y el
nombre del gráfico que se va a instalar. Para ver cómo funciona la instalación de un gráfico de Helm, vamos a
instalar una implementación básica de nginx mediante un gráfico de Helm.
helm install my-nginx-ingress ingress-nginx/ingress-nginx \

--set defaultBackend.nodeSelector."beta\.kubernetes\.io/os"=linux
En la siguiente salida de ejemplo condensada se muestra el estado de implementación de los recursos de

Kubernetes creados mediante el gráfico de Helm:
$ helm install my-nginx-ingress ingress-nginx/ingress-nginx \
> --set controller.nodeSelector."beta\.kubernetes\.io/os"=linux \
> --set defaultBackend.nodeSelector."beta\.kubernetes\.io/os"=linux
NAME: my-nginx-ingress
LAST DEPLOYED: Fri Nov 22 10:08:06 2019
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The nginx-ingress controller has been installed.
It may take a few minutes for the LoadBalancer IP to be available.
You can watch the status by running 'kubectl --namespace default get services -o wide -w my-nginx-ingress-
ingress-nginx-controller'
...
Use el comando kubectl get services para obtener el valor de EXTERNAL-IP del servicio.
kubectl --namespace default get services -o wide -w my-nginx-ingress-ingress-nginx-controller
Por ejemplo, el siguiente comando muestra el valor de EXTERNAL-IP para el servicio my-nginx-ingress-ingress-
nginx-controller:
$ kubectl --namespace default get services -o wide -w my-nginx-ingress-ingress-nginx-controller

AGE SELECTOR
my-nginx-ingress-ingress-nginx-controller LoadBalancer 10.0.2.237 <EXTERNAL-IP>
80:31380/TCP,443:32239/TCP 72s app.kubernetes.io/component=controller,app.kubernetes.io/instance=my-
nginx-ingress,app.kubernetes.io/name=ingress-nginx
Lista de versiones
Para ver una lista de las versiones instaladas en el clúster, use el comando helm list .
helm list
En el siguiente ejemplo se muestra la versión de my-nginx-ingress implementada en el paso anterior:
$ helm list
NAME NAMESPACE REVISION UPDATED STATUS CHART

APP VERSION
my-nginx-ingress default 1 2019-11-22 10:08:06.048477 -0600 CST deployed nginx-
ingress-1.25.0 0.26.1
Al implementar un gráfico de Helm, se crean algunos recursos de Kubernetes. Estos recursos incluyen pods,
implementaciones y servicios. Para limpiar estos recursos, use el comando helm uninstall y especifique el
nombre de la versión, tal como aparecía en el comando helm list anterior.
helm uninstall my-nginx-ingress
En el siguiente ejemplo se muestra que se ha desinstalado la versión denominada my-nginx-ingress:

$ helm uninstall my-nginx-ingress
release "my-nginx-ingress" uninstalled
Pasos siguientes
Para más información sobre cómo administrar las implementaciones de aplicaciones de Kubernetes con Helm,
consulte la documentación de Helm.
Documentación de Helm
Uso de OpenFaaS en AKS
OpenFaaS es una plataforma para la creación de funciones sin servidor mediante contenedores. Como proyecto
de código abierto, se ha adoptado a gran escala dentro de la comunidad. En este documento se detalla la
instalación y uso de OpenFaas en un clúster de Azure Kubernetes Service (AKS).
Prerrequisitos
Para completar los pasos de este artículo, necesita lo siguiente.
Conocimientos básicos sobre Kubernetes.
Un clúster de Azure Kubernetes Service (AKS) y las credenciales de AKS configuradas en el sistema de
desarrollo.
CLI de Azure instalada en el sistema de desarrollo.
Herramientas de línea de comandos GIT instaladas en el sistema.
Incorporación del repositorio de gráficos de Helm de OpenFaaS

Vaya a https://shell.azure.com para abrir Azure Cloud Shell en el explorador.
OpenFaaS mantiene sus propios gráficos de Helm para estar al día con los últimos cambios.
helm repo add openfaas https://openfaas.github.io/faas-netes/

helm repo update
Implementación de OpenFaaS
Como recomendación, OpenFaaS y sus funciones deberían almacenarse en su propio espacio de nombres de
Kubernetes.
Cree un espacio de nombres para el sistema y las funciones de OpenFaaS:
kubectl apply -f https://raw.githubusercontent.com/openfaas/faas-netes/master/namespaces.yml
Genere una contraseña para el portal de la interfaz de usuario de OpenFaaS y la API REST:
# generate a random password

PASSWORD=$(head -c 12 /dev/urandom | shasum| cut -d' ' -f1)
kubectl -n openfaas create secret generic basic-auth \

--from-literal=basic-auth-user=admin \
--from-literal=basic-auth-password="$PASSWORD"
Puede obtener el valor del secreto con echo $PASSWORD .

La contraseña que creamos aquí se usará en el gráfico de Helm para habilitar la autenticación básica en la
puerta de enlace de OpenFaaS, que se expone en Internet mediante un equilibrador de carga de nube.
En el repositorio clonado se incluye un gráfico de Helm para OpenFaaS. Utilice este gráfico para implementar
OpenFaaS en el clúster de AKS.
helm upgrade openfaas --install openfaas/openfaas \
--namespace openfaas \
--set basic_auth=true \
--set functionNamespace=openfaas-fn \
--set serviceType=LoadBalancer
Salida:
NAME: openfaas
LAST DEPLOYED: Wed Feb 28 08:26:11 2018
NAMESPACE: openfaas
STATUS: DEPLOYED
RESOURCES:
==> v1/ConfigMap
NAME DATA AGE
prometheus-config 2 20s
alertmanager-config 1 20s
{snip}
NOTES:
To verify that openfaas has started, run:
```console
kubectl --namespace=openfaas get deployments -l "release=openfaas, app=openfaas"
Se crea una dirección IP pública para tener acceso a la puerta de enlace de OpenFaaS. Para recuperar esta
dirección IP, use el comando kubectl get service. La asignación de la dirección IP al servicio puede tardar hasta
un minuto.
kubectl get service -l component=gateway --namespace openfaas
Salida.

gateway ClusterIP 10.0.156.194 <none> 8080/TCP 7m
gateway-external LoadBalancer 10.0.28.18 52.186.64.52 8080:30800/TCP 7m
Para probar el sistema OpenFaaS, vaya a la dirección IP externa en el puerto 8080, http://52.186.64.52:8080 en
este ejemplo. Se le pedirá que inicie sesión. Para capturar la contraseña, escriba echo $PASSWORD .
Por último, instale la CLI de OpenFaaS. En este ejemplo se usaba brew. Consulte la documentación de la CLI de
OpenFaaS para ver más opciones.
brew install faas-cli
Establezca $OPENFAAS_URL en la dirección IP pública que se encuentra encima.

Inicie sesión con la CLI de Azure:
export OPENFAAS_URL=http://52.186.64.52:8080
echo -n $PASSWORD | ./faas-cli login -g $OPENFAAS_URL -u admin --password-stdin
Creación de la primera función

Ahora que OpenFaaS está en funcionamiento, cree una función mediante el portal de OpenFaas.
Haga clic en Deploy New Function (Implementar nueva función) y busque Figlet . Seleccione la función Figlet
y haga clic en Deploy (Implementar).
Use curl para invocar la función. Reemplace la dirección IP en el ejemplo siguiente con la de la puerta de enlace
de OpenFaas.
curl -X POST http://52.186.64.52:8080/function/figlet -d "Hello Azure"
Salida:
_ _ _ _ _
| | | | ___| | | ___ / \ _____ _ _ __ ___
| |_| |/ _ \ | |/ _ \ / _ \ |_ / | | | '__/ _ \
| _ | __/ | | (_) | / ___ \ / /| |_| | | | __/
|_| |_|\___|_|_|\___/ /_/ \_\/___|\__,_|_| \___|
Creación de la segunda función

Ahora cree la segunda función. Este ejemplo se implementará con la CLI de OpenFaaS e incluye una imagen de
contenedor personalizada y la recuperación de datos de una instancia de Cosmos DB. Antes de crear la función,
hay que configurar varios elementos.
En primer lugar, hay que crear un grupo de recursos para Cosmos DB.
az group create --name serverless-backing --location eastus
Implemente una instancia de CosmosDB de tipo MongoDB . La instancia necesita un nombre único, actualice
openfaas-cosmos con un nombre único para su entorno.
az cosmosdb create --resource-group serverless-backing --name openfaas-cosmos --kind MongoDB
Obtenga la cadena de conexión de Cosmos DB y almacénela en una variable.

Actualice el valor del argumento --resource-group con el nombre de su grupo de recursos y el argumento
--name con el de su instancia de Cosmos DB.
COSMOS=$(az cosmosdb list-connection-strings \
--resource-group serverless-backing \
--name openfaas-cosmos \
--query connectionStrings[0].connectionString \
--output tsv)
Ahora rellene la instancia de Cosmos DB con datos de prueba. Cree un archivo denominado plans.json y
cópielo en el siguiente código json.
{
"name" : "two_person",
"friendlyName" : "Two Person Plan",
"portionSize" : "1-2 Person",
"mealsPerWeek" : "3 Unique meals per week",
"price" : 72,
"description" : "Our basic plan, delivering 3 meals per week, which will feed 1-2 people.",
"__v" : 0
}
Use la herramienta mongoimport para cargar la instancia de CosmosDB con datos.

Si es necesario, instale las herramientas de MongoDB. En el ejemplo siguiente se instalan estas herramientas
con brew. Consulte la documentación de MongoDB para ver otras opciones.
brew install mongodb
Cargue los datos en la base de datos.
mongoimport --uri=$COSMOS -c plans < plans.json
Salida:
2018-02-19T14:42:14.313+0000 connected to: localhost

2018-02-19T14:42:14.918+0000 imported 1 document
Ejecute el siguiente comando para crear la función. Actualice el valor del argumento -g con la dirección de la
puerta de enlace de OpenFaaS.
faas-cli deploy -g http://52.186.64.52:8080 --image=shanepeckham/openfaascosmos --name=cosmos-query --

env=NODE_ENV=$COSMOS
Una vez implementado, debería ver el punto de conexión de OpenFaaS recién creado para la función.
Deployed. 202 Accepted.

URL: http://52.186.64.52:8080/function/cosmos-query
Pruebe la función con curl. Actualice la dirección IP con la dirección de puerta de enlace de OpenFaaS.
curl -s http://52.186.64.52:8080/function/cosmos-query
Salida:
[{"ID":"","Name":"two_person","FriendlyName":"","PortionSize":"","MealsPerWeek":"","Price":72,"Description":
"Our basic plan, delivering 3 meals per week, which will feed 1-2 people."}]
También puede probar la función dentro de la UI de OpenFaaS.
Pasos siguientes
Para seguir aprendiendo, puede realizar el taller sobre OpenFaaS, un conjunto de laboratorios prácticos que
abarcan temas como la creación de su propio bot de GitHub, el consumo de secretos, la visualización de
métricas y el escalado automático.
Ejecución de trabajos de Apache Spark en AKS
Apache Spark es un motor rápido para el procesamiento de datos a gran escala. Desde la versión de Spark 2.3.0,
Apache Spark admite la integración nativa con clústeres de Kubernetes. Azure Kubernetes Service (AKS) es un
entorno de Kubernetes administrado que se ejecuta en Azure. Este documento detalla la preparación y ejecución
de trabajos de Apache Spark en un clúster de Azure Kubernetes Service (AKS).
Requisitos previos
Para completar los pasos de este artículo, necesita lo siguiente.
Conocimientos básicos de Kubernetes y Apache Spark.
Una cuenta de Docker Hub o un registro de Azure Container Registry.
La CLI de Azure instalada en el sistema de desarrollo.
JDK 8 instalado en el sistema.
Apache Maven instalado en el sistema.
SBT (Scala Build Tool) instalado en el sistema.
Herramientas de línea de comandos GIT instaladas en el sistema.

Spark se usa para el procesamiento de datos a gran escala y requiere que los nodos Kubernetes tengan el
tamaño adecuado para cumplir los requisitos de los recursos de Spark. Se recomienda un tamaño mínimo de
Standard_D3_v2 para los nodos de Azure Kubernetes Service (AKS).
Si necesita un clúster de AKS que cumpla esta recomendación mínima, ejecute los siguientes comandos.
Cree un grupo de recursos para el clúster.
az group create --name mySparkCluster --location eastus
Cree una entidad de servicio para el clúster. Una vez creada, necesitará el appId y la contraseña de la entidad de
servicio para el siguiente comando.
az ad sp create-for-rbac --name SparkSP
Cree el clúster de AKS con nodos de tamaño Standard_D3_v2 y con los valores de appId y contraseña pasados
como parámetros service-principal y client-secret.
az aks create --resource-group mySparkCluster --name mySparkCluster --node-vm-size Standard_D3_v2 --

generate-ssh-keys --service-principal <APPID> --client-secret <PASSWORD>
Conéctese al clúster de AKS.
az aks get-credentials --resource-group mySparkCluster --name mySparkCluster
Si usa Azure Container Registry (ACR) para almacenar las imágenes del contenedor, configure la autenticación
entre AKS y ACR. Consulte la documentación de autenticación de ACR para realizar estos pasos.
Compilación del código fuente de Spark

Antes de ejecutar trabajos de Spark en un clúster de AKS, es necesario compilar el código fuente de Spark y
empaquetarlo en una imagen de contenedor. El código fuente de Spark incluye scripts que puede utilizar para
completar este proceso.
Clone el repositorio del proyecto de Spark en el sistema de desarrollo.
git clone -b branch-2.4 https://github.com/apache/spark
Cambie al directorio del repositorio clonado y guarde la ruta de acceso al código fuente de Spark en una
variable.
cd spark
sparkdir=$(pwd)
Si tiene instaladas varias versiones del JDK, establezca JAVA_HOME para utilizar la versión 8 en la sesión actual.
export JAVA_HOME=`/usr/libexec/java_home -d 64 -v "1.8*"`
Ejecute el siguiente comando para compilar el código fuente de Spark con compatibilidad con Kubernetes.
./build/mvn -Pkubernetes -DskipTests clean package
El siguiente comando crea la imagen del contenedor de Spark y la inserta en un registro de imagen de
contenedor. Reemplace registry.example.com con el nombre de su registro de contenedor y v1 con la etiqueta
que prefiera utilizar. Si usa Docker Hub, este valor es el nombre del registro. Si utiliza Azure Container Registry
(ACR), este valor es el nombre del servidor de inicio de sesión de ACR.
REGISTRY_NAME=registry.example.com
REGISTRY_TAG=v1
./bin/docker-image-tool.sh -r $REGISTRY_NAME -t $REGISTRY_TAG build
Inserte la imagen del contenedor en el registro de imagen de contenedor.
./bin/docker-image-tool.sh -r $REGISTRY_NAME -t $REGISTRY_TAG push
Preparación de un trabajo de Spark

A continuación, prepare un trabajo de Spark. Se usa un archivo jar para contener el trabajo de Spark y es
necesario para ejecutar el comando spark-submit . El archivo jar puede hacerse accesible a través de una
dirección URL pública o preempaquetado dentro de una imagen de contenedor. En este ejemplo, se crea un
archivo jar de ejemplo para calcular el valor de Pi. Este archivo jar, a continuación, se carga en Azure Storage. Si
tiene un archivo jar existente, no dude en sustituirlo
Cree un directorio donde desea crear el proyecto para un trabajo de Spark.
mkdir myprojects
cd myprojects
Cree un nuevo proyecto de Scala desde una plantilla.
sbt new sbt/scala-seed.g8
Cuando se le solicite, escriba SparkPi como nombre del proyecto.
name [Scala Seed Project]: SparkPi
Vaya al directorio del proyecto recién creado.
cd sparkpi
Ejecute los comandos siguientes para agregar un complemento de SBT que permite empaquetar el proyecto
como un archivo jar.
touch project/assembly.sbt
echo 'addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "0.14.10")' >> project/assembly.sbt
Ejecute estos comandos para copiar el código de ejemplo en el proyecto recién creado y agregar todas las
dependencias necesarias.
EXAMPLESDIR="src/main/scala/org/apache/spark/examples"
mkdir -p $EXAMPLESDIR
cp $sparkdir/examples/$EXAMPLESDIR/SparkPi.scala $EXAMPLESDIR/SparkPi.scala
cat <<EOT >> build.sbt

// https://mvnrepository.com/artifact/org.apache.spark/spark-sql
libraryDependencies += "org.apache.spark" %% "spark-sql" % "2.3.0" % "provided"
EOT
sed -ie 's/scalaVersion.*/scalaVersion := "2.11.11"/' build.sbt

sed -ie 's/name.*/name := "SparkPi",/' build.sbt
Para empaquetar el proyecto en un archivo jar, ejecute el siguiente comando.
sbt assembly
Después de empaquetarlo correctamente, debería ver una salida similar a la siguiente.
[info] Packaging /Users/me/myprojects/sparkpi/target/scala-2.11/SparkPi-assembly-0.1.0-SNAPSHOT.jar ...

[info] Done packaging.
[success] Total time: 10 s, completed Mar 6, 2018 11:07:54 AM
Copia del trabajo a Azure Storage

Cree una cuenta de Azure Storage y un contenedor para almacenar el archivo jar.
RESOURCE_GROUP=sparkdemo
STORAGE_ACCT=sparkdemo$RANDOM
az group create --name $RESOURCE_GROUP --location eastus
az storage account create --resource-group $RESOURCE_GROUP --name $STORAGE_ACCT --sku Standard_LRS
export AZURE_STORAGE_CONNECTION_STRING=`az storage account show-connection-string --resource-group
$RESOURCE_GROUP --name $STORAGE_ACCT -o tsv`
Cargue el archivo jar en la cuenta de Azure Storage con los siguientes comandos.
CONTAINER_NAME=jars
BLOB_NAME=SparkPi-assembly-0.1.0-SNAPSHOT.jar
FILE_TO_UPLOAD=target/scala-2.11/SparkPi-assembly-0.1.0-SNAPSHOT.jar
echo "Creating the container..."

az storage container create --name $CONTAINER_NAME
az storage container set-permission --name $CONTAINER_NAME --public-access blob
echo "Uploading the file..."

az storage blob upload --container-name $CONTAINER_NAME --file $FILE_TO_UPLOAD --name $BLOB_NAME
jarUrl=$(az storage blob url --container-name $CONTAINER_NAME --name $BLOB_NAME | tr -d '"')
La variable jarUrl ahora contiene la ruta de acceso pública al archivo jar.
Envío de un trabajo de Spark

Inicie kube-proxy en otra línea de comandos con el código siguiente.
kubectl proxy
Vuelva hasta la raíz del repositorio de Spark.
cd $sparkdir
Cree una cuenta de servicio que tenga permisos suficientes para ejecutar un trabajo.
kubectl create serviceaccount spark

kubectl create clusterrolebinding spark-role --clusterrole=edit --serviceaccount=default:spark --
namespace=default
Envíe el trabajo mediante spark-submit .
./bin/spark-submit \
--master k8s://http://127.0.0.1:8001 \
--deploy-mode cluster \
--name spark-pi \
--class org.apache.spark.examples.SparkPi \
--conf spark.executor.instances=3 \
--conf spark.kubernetes.authenticate.driver.serviceAccountName=spark \
--conf spark.kubernetes.container.image=$REGISTRY_NAME/spark:$REGISTRY_TAG \
$jarUrl
Esta operación inicia el trabajo de Spark, que transmite el estado del trabajo a la sesión de shell. Mientras se
ejecuta el trabajo, puede ver el pod del controlador de Spark y los pod del ejecutor mediante el comando
kubectl get pods. Abra una segunda sesión de terminal para ejecutar estos comandos.
kubectl get pods

spark-pi-2232778d0f663768ab27edc35cb73040-driver 1/1 Running 0 16s
spark-pi-2232778d0f663768ab27edc35cb73040-exec-1 0/1 Init:0/1 0 4s
Mientras se ejecuta el trabajo, también puede acceder a la interfaz de usuario de Spark. En la segunda sesión de
terminal, use el comando kubectl port-forward para proporcionar acceso a la interfaz de usuario de Spark.
kubectl port-forward spark-pi-2232778d0f663768ab27edc35cb73040-driver 4040:4040
Para acceder a la interfaz de usuario de Spark, abra la dirección 127.0.0.1:4040 en un explorador.
Obtención de los resultados y registros del trabajo

Cuando haya finalizado el trabajo, el pod del controlador estará en un estado "Completado". Puede obtener el
nombre del pod con el siguiente comando.
kubectl get pods --show-all
Salida:

spark-pi-2232778d0f663768ab27edc35cb73040-driver 0/1 Completed 0 1m
Use el comando kubectl logs para obtener los registros del pod del controlador de Spark. Sustituya el nombre
del pod por el nombre del pod del controlador.
kubectl logs spark-pi-2232778d0f663768ab27edc35cb73040-driver
En estos registros, puede ver el resultado del trabajo de Spark, que es el valor de Pi.
Pi is roughly 3.152155760778804
Paquete jar con la imagen de contenedor

En el ejemplo anterior, el archivo jar de Spark se cargó en Azure Storage. Otra opción consiste en empaquetar el
archivo jar en imágenes de Docker personalizadas.
Para ello, busque el archivo de la imagen de Spark ubicado en el directorio
dockerfile
$sparkdir/resource-managers/kubernetes/docker/src/main/dockerfiles/spark/ . Agregue una instrucción ADD al
trabajo de Spark jar en algún lugar entre las declaraciones WORKDIR y ENTRYPOINT .
Actualice la ruta de acceso del archivo jar con la ubicación del archivo SparkPi-assembly-0.1.0-SNAPSHOT.jar en
el sistema de desarrollo. También puede utilizar su propio archivo jar personalizado.
WORKDIR /opt/spark/work-dir
ADD /path/to/SparkPi-assembly-0.1.0-SNAPSHOT.jar SparkPi-assembly-0.1.0-SNAPSHOT.jar
ENTRYPOINT [ "/opt/entrypoint.sh" ]
Compile e inserte la imagen con los scripts de Spark incluidos.
./bin/docker-image-tool.sh -r <your container repository name> -t <tag> build

./bin/docker-image-tool.sh -r <your container repository name> -t <tag> push
Cuando se ejecuta el trabajo, en lugar de indicar una dirección URL del archivo jar remoto, puede usar el
esquema local:// con la ruta de acceso al archivo jar en la imagen de Docker.
./bin/spark-submit \
--master k8s://https://<k8s-apiserver-host>:<k8s-apiserver-port> \
--deploy-mode cluster \
--name spark-pi \
--class org.apache.spark.examples.SparkPi \
--conf spark.executor.instances=3 \
--conf spark.kubernetes.authenticate.driver.serviceAccountName=spark \
--conf spark.kubernetes.container.image=<spark-image> \
local:///opt/spark/work-dir/<your-jar-name>.jar
WARNING
De la documentación de Spark: "Actualmente, el programador de Kubernetes es experimental. En versiones futuras, puede
haber cambios de comportamiento en la configuración, las imágenes de contenedor y los puntos de entrada."
Pasos siguientes
Consulte la documentación de Spark para más detalles.
Documentación de Spark
Uso de GPU para cargas de trabajo de cálculo
intensivo en Azure Kubernetes Service (AKS)
Por lo general, las unidades de procesamiento gráfico (GPU) se usan para cargas de trabajo de cálculo intensivo,
como cargas de trabajo de visualización y gráficos. AKS admite la creación de grupos de nodos compatibles con
GPU para ejecutar estas cargas de trabajo de cálculo intensivo en Kubernetes. Para obtener más información
sobre las máquinas virtuales habilitadas para GPU disponibles, consulte Tamaños de máquinas virtuales
optimizadas para GPU en Azure. Para nodos AKS, se recomienda un tamaño mínimo de Standard_NC6.
NOTE
Las máquinas virtuales habilitadas para GPU contienen hardware especializado que está sujeto a una mayor disponibilidad
de precios y región. Para obtener más información, consulte la herramienta de precios y la disponibilidad de regiones.
Actualmente, el uso de grupos de nodos habilitados para GPU solo está disponible para grupos de nodos de
Linux.
Antes de empezar
En este artículo se supone que ya tiene un clúster de AKS con nodos que admiten GPU. El clúster de AKS debe
ejecutar Kubernetes 1.10 o una versión posterior. Si necesita un clúster de AKS que cumpla estos requisitos,
consulte la primera sección de este artículo para crear un clúster de AKS.
También es preciso tener instalada y configurada la versión 2.0.64 de la CLI de Azure u otra versión posterior.
Azure.

Si necesita un clúster de AKS que cumpla los requisitos mínimos (nodo habilitado para GPU y Kubernetes
versión 1.10 o posterior), siga estos pasos. Si ya tiene un clúster de AKS que cumpla estos requisitos, vaya a la
sección siguiente.
Primero, cree un grupo de recursos para el clúster con el comando az group create. En el ejemplo siguiente, se
crea un grupo de recursos denominado myResourceGroup en la región eastus:
Ahora cree un clúster de AKS con el comando az aks create. En el ejemplo siguiente se crea un clúster con un
solo nodo de tamaño Standard_NC6 :
az aks create \
--node-vm-size Standard_NC6 \
--node-count 1
Obtenga las credenciales para el clúster de AKS mediante el comando az aks get-credentials:
Instalación del complemento de dispositivo NVIDIA

Para poder usar las GPU en los nodos, debe implementar un elemento DaemonSet para el complemento de
dispositivo NVIDIA. Este objeto DaemonSet ejecuta un pod en cada nodo para proporcionar los controladores
requeridos para las GPU.
En primer lugar, cree un espacio de nombres mediante el comando kubectl create namespace, como gpu-
resources:
kubectl create namespace gpu-resources
Cree un archivo denominado nvidia-device-plugin-ds.yaml y pegue el siguiente manifiesto YAML. Este

manifiesto se proporciona como parte del complemento de dispositivo NVIDIA para el proyecto de Kubernetes.
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: nvidia-device-plugin-daemonset
namespace: gpu-resources
spec:
selector:
matchLabels:
name: nvidia-device-plugin-ds
updateStrategy:
type: RollingUpdate
template:
metadata:
# Mark this pod as a critical add-on; when enabled, the critical add-on scheduler
# reserves resources for critical add-on pods so that they can be rescheduled after
# a failure. This annotation works in tandem with the toleration below.
annotations:
scheduler.alpha.kubernetes.io/critical-pod: ""
labels:
name: nvidia-device-plugin-ds
spec:
tolerations:
# Allow this pod to be rescheduled while the node is in "critical add-ons only" mode.
# This, along with the annotation above marks this pod as a critical add-on.
- key: CriticalAddonsOnly
operator: Exists
- key: nvidia.com/gpu
operator: Exists
effect: NoSchedule
containers:
- image: mcr.microsoft.com/oss/nvidia/k8s-device-plugin:1.11
name: nvidia-device-plugin-ctr
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop: ["ALL"]
volumeMounts:
- name: device-plugin
mountPath: /var/lib/kubelet/device-plugins
volumes:
- name: device-plugin
hostPath:
path: /var/lib/kubelet/device-plugins
Ahora, use el comando kubectl apply para crear el elemento DaemonSet y confirme que el complemento de
dispositivo NVIDIA se crea correctamente, tal como se muestra en la salida de ejemplo siguiente:
$ kubectl apply -f nvidia-device-plugin-ds.yaml
daemonset "nvidia-device-plugin" created
Uso de la imagen de GPU especializada de AKS (versión preliminar)

Como alternativa a estos pasos, AKS proporciona una imagen de AKS totalmente configurada que ya contiene el
complemento de dispositivo NVIDIA para Kubernetes.
WARNING
No debe instalar manualmente el conjunto de demonio del complemento de dispositivo NVIDIA para clústeres mediante
la nueva imagen de GPU especializada de AKS.
Registre la característica GPUDedicatedVHDPreview :
az feature register --name GPUDedicatedVHDPreview --namespace Microsoft.ContainerService
Pueden pasar unos minutos hasta que el estado aparezca como Registrado . Puede comprobar el estado del
registro con el comando az feature list:
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/GPUDedicatedVHDPreview')].

Cuando el estado se muestre como Registrado, actualice el registro del proveedor de recursos
Microsoft.ContainerService mediante el comando az provider register:
Para instalar la extensión aks-preview de la CLI, use los siguientes comandos de la CLI de Azure:
Para actualizar la extensión aks-preview de la CLI, use los siguientes comandos de la CLI de Azure:
Uso de la imagen de GPU especializada de AKS en clústeres nuevos (versión preliminar)

Configure el clúster para usar la imagen de GPU especializada de AKS cuando se cree el clúster. Use la marca
--aks-custom-headers para los nodos del agente GPU en el nuevo clúster para usar la imagen de GPU
especializada de AKS.
az aks create --name myAKSCluster --resource-group myResourceGroup --node-vm-size Standard_NC6 --node-count

1 --aks-custom-headers UseGPUDedicatedVHD=true
Para crear un clúster con imágenes normales de AKS, puede omitir la etiqueta --aks-custom-headers
personalizada. También puede optar por añadir más grupos de nodos de GPU especializados, tal y como se
indica a continuación.
Uso de la imagen de GPU especializada de AKS en clústeres existentes (versión preliminar)
Configure un grupo de nodos nuevo para usar la imagen de GPU especializada de AKS. Use la marca de
--aks-custom-headers para los nodos del agente de GPU en el nuevo grupo de nodos para usar la imagen de
GPU especializada de AKS.
az aks nodepool add --name gpu --cluster-name myAKSCluster --resource-group myResourceGroup --node-vm-size
Standard_NC6 --node-count 1 --aks-custom-headers UseGPUDedicatedVHD=true
Para crear un grupo de nodos mediante imágenes AKS normales, puede omitir la etiqueta --aks-custom-headers
personalizada.
NOTE
Si la SKU de GPU requiere máquinas virtuales de generación 2, para crearlas puede:
az aks nodepool add --name gpu --cluster-name myAKSCluster --resource-group myResourceGroup --node-vm-
size Standard_NC6s_v2 --node-count 1 --aks-custom-headers UseGPUDedicatedVHD=true,usegen2vm=true
Confirmación de que las GPU son programables

Con el clúster de AKS creado, confirme que las GPU son programables en Kubernetes. Primero, enumere los
nodos del clúster con el comando kubectl get nodes:
$ kubectl get nodes

Ahora, use el comando kubectl describe node para confirmar que las GPU son programables. En la sección
Capacidad, la GPU debe aparecer como nvidia.com/gpu: 1 .
En el siguiente ejemplo reducido se muestra que una GPU está disponible en el nodo denominado aks-
nodepool1-18821093-0:
$ kubectl describe node aks-nodepool1-28993262-0
Name: aks-nodepool1-28993262-0
Roles: agent
Labels: accelerator=nvidia
[...]
Capacity:
attachable-volumes-azure-disk: 24
cpu: 6
ephemeral-storage: 101584140Ki
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 57713784Ki
nvidia.com/gpu: 1
pods: 110
Allocatable:
attachable-volumes-azure-disk: 24
cpu: 5916m
ephemeral-storage: 93619943269
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 51702904Ki
nvidia.com/gpu: 1
pods: 110
System Info:
Machine ID: b0cd6fb49ffe4900b56ac8df2eaa0376
System UUID: 486A1C08-C459-6F43-AD6B-E9CD0F8AEC17
Boot ID: f134525f-385d-4b4e-89b8-989f3abb490b
Kernel Version: 4.15.0-1040-azure
OS Image: Ubuntu 16.04.6 LTS
Operating System: linux
Architecture: amd64
Container Runtime Version: docker://1.13.1
Kubelet Version: v1.12.7
Kube-Proxy Version: v1.12.7
PodCIDR: 10.244.0.0/24
ProviderID:
azure:///subscriptions/<guid>/resourceGroups/MC_myResourceGroup_myAKSCluster_eastus/providers/Microsoft.Comp
ute/virtualMachines/aks-nodepool1-28993262-0
Non-terminated Pods: (9 in total)
Namespace Name CPU Requests CPU Limits Memory
Requests Memory Limits AGE
--------- ---- ------------ ---------- ------------
--- ------------- ---
kube-system nvidia-device-plugin-daemonset-bbjlq 0 (0%) 0 (0%) 0 (0%)
0 (0%) 2m39s
[...]
Ejecución de una carga de trabajo habilitada para GPU

Para ver la GPU en acción, programe una carga de trabajo compatible con la GPU con la solicitud de recursos
adecuada. En este ejemplo se va a ejecutar un trabajo Tensorflow en el conjunto de datos MNIST.
Cree un archivo denominado samples-tf-mnist-demo.yaml y pegue el siguiente manifiesto YAML. El siguiente
manifiesto de trabajo incluye un límite de recursos de nvidia.com/gpu: 1 :
NOTE
Si recibe un error de coincidencia de versión al llamar a los controladores, como, por ejemplo, que la versión del
controlador CUDA no es suficiente para la versión en tiempo de ejecución de CUDA, revise el gráfico de compatibilidad de
la matriz de controladores de NVIDIA: https://docs.nvidia.com/deploy/cuda-compatibility/index.html.
apiVersion: batch/v1
kind: Job
metadata:
labels:
app: samples-tf-mnist-demo
name: samples-tf-mnist-demo
spec:
template:
metadata:
labels:
app: samples-tf-mnist-demo
spec:
containers:
- name: samples-tf-mnist-demo
args: ["--max_steps", "500"]
imagePullPolicy: IfNotPresent
resources:
limits:
nvidia.com/gpu: 1
restartPolicy: OnFailure
Use el comando kubectl apply para ejecutar el trabajo. Este comando analiza el archivo de manifiesto y crea los
objetos de Kubernetes definidos:
kubectl apply -f samples-tf-mnist-demo.yaml
Ver el estado y la salida de la carga de trabajo habilitada para GPU

Supervise el progreso del trabajo mediante el comando kubectl get jobs con el argumento --watch . Puede
tardar unos minutos en extraer primero la imagen y procesar el conjunto de datos. Cuando la columna
COMPLETIONS (FINALIZACIONES) muestra 1/1, significa que el trabajo ha finalizado correctamente. Salga del
comando kubetctl --watch con Ctrl-C:
$ kubectl get jobs samples-tf-mnist-demo --watch
NAME COMPLETIONS DURATION AGE
samples-tf-mnist-demo 0/1 3m29s 3m29s

samples-tf-mnist-demo 1/1 3m10s 3m36s
Para ver la salida de la carga de trabajo habilitada para GPU, obtenga primero el nombre del pod con el
comando kubectl get pods:
$ kubectl get pods --selector app=samples-tf-mnist-demo

samples-tf-mnist-demo-mtd44 0/1 Completed 0 4m39s
Ahora, use el comando kubectl logs para ver los registros del pod. En el siguiente ejemplo, los registros de pod
confirman que se ha descubierto el dispositivo GPU adecuado, Tesla K80 . Proporcione el nombre para su pod:
$ kubectl logs samples-tf-mnist-demo-smnr6
2019-05-16 16:08:31.258328: I tensorflow/core/platform/cpu_feature_guard.cc:137] Your CPU supports

instructions that this TensorFlow binary was not compiled to use: SSE4.1 SSE4.2 AVX AVX2 FMA
2019-05-16 16:08:31.396846: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1030] Found device 0 with
properties:
name: Tesla K80 major: 3 minor: 7 memoryClockRate(GHz): 0.8235
pciBusID: 2fd7:00:00.0
totalMemory: 11.17GiB freeMemory: 11.10GiB
2019-05-16 16:08:31.396886: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1120] Creating TensorFlow
device (/device:GPU:0) -> (device: 0, name: Tesla K80, pci bus id: 2fd7:00:00.0, compute capability: 3.7)
2019-05-16 16:08:36.076962: I tensorflow/stream_executor/dso_loader.cc:139] successfully opened CUDA library
libcupti.so.8.0 locally
Successfully downloaded train-images-idx3-ubyte.gz 9912422 bytes.
Extracting /tmp/tensorflow/input_data/train-images-idx3-ubyte.gz
Successfully downloaded train-labels-idx1-ubyte.gz 28881 bytes.
Extracting /tmp/tensorflow/input_data/train-labels-idx1-ubyte.gz
Successfully downloaded t10k-images-idx3-ubyte.gz 1648877 bytes.
Extracting /tmp/tensorflow/input_data/t10k-images-idx3-ubyte.gz
Successfully downloaded t10k-labels-idx1-ubyte.gz 4542 bytes.
Extracting /tmp/tensorflow/input_data/t10k-labels-idx1-ubyte.gz
Accuracy at step 0: 0.1081
Adding run metadata for 99
Para eliminar los objetos de Kubernetes asociados que creó en este artículo, use el comando kubectl delete job
como se muestra a continuación:
kubectl delete jobs samples-tf-mnist-demo
Pasos siguientes
Para ejecutar trabajos de Apache Spark, consulte Ejecución de trabajos de Apache Spark en AKS.
Para obtener más información acerca de la ejecución de cargas de trabajo de aprendizaje automático (ML) en
Kubernetes, vea Kubeflow Labs.
Tutorial: Implementación de una aplicación Django
en AKS con Servidor flexible de Azure Database for
PostgreSQL
En este inicio rápido se implementa una aplicación Django en el clúster de Azure Kubernetes Service (AKS) con
Servidor flexible de Azure Database for PostgreSQL (versión preliminar) mediante la CLI de Azure.
AKS es un servicio de Kubernetes administrado que permite implementar y administrar clústeres rápidamente.
Ser vidor flexible de Azure Database for PostgreSQL (versión preliminar) es un servicio de base de
datos totalmente administrado diseñado para proporcionar un control más granular y una mayor flexibilidad
sobre las funciones de administración de bases de datos y las opciones de configuración.
NOTE
Actualmente Servidor flexible de Azure Database for PostgreSQL se encuentra en versión preliminar.
En este inicio rápido se presupone un conocimiento básico de los conceptos de Kubernetes, Django y PostgreSQL.
Requisitos previos
Use Azure Cloud Shell con el entorno de Bash.
Si lo prefiere, instale la CLI de Azure para ejecutar los comandos de referencia de la CLI.
Si usa una instalación local, inicie sesión con la CLI de Azure mediante el comando az login. Siga los
información, consulte Uso de extensiones con la CLI de Azure.
Ejecute az version para buscar cuál es la versión y las bibliotecas dependientes que están instaladas.
Para realizar la actualización a la versión más reciente, ejecute az upgrade. En este artículo se necesita
la versión más reciente de la CLI de Azure. Si usa Azure Cloud Shell, ya está instalada la versión más
reciente.
NOTE
Si los comandos de este inicio rápido se ejecutan localmente (en lugar de en Azure Cloud Shell), asegúrese de ejecutarlos
como administrador.

Vamos a crear un grupo de recursos, django-project, mediante el comando [az group create][az-group-create]
en la ubicación eastus.
az group create --name django-project --location eastus
NOTE
La ubicación del grupo de recursos es donde se almacenan los metadatos del grupo de recursos. Es también el lugar en el
que se ejecutan los recursos en Azure si no se especifica otra región al crear los recursos.
{
"id": "/subscriptions/<guid>/resourceGroups/django-project",
"managedBy": null,
"name": "django-project",
"properties": {
},
"tags": null
}

denominado myAKSCluster con un nodo. Este proceso tardará varios minutos en completarse.
az aks create --resource-group django-project --name djangoappcluster --node-count 1 --generate-ssh-keys
NOTE
Consulte ¿Por qué se crean dos grupos de recursos con AKS?
cli:
az aks install-cli
az aks get-credentials --resource-group django-project --name djangoappcluster

NOTE
El comando anterior usa la ubicación predeterminada para el archivo de configuración de Kubernetes, ~/.kube/config .
Puede especificar otra ubicación para el archivo de configuración de Kubernetes con la opción --file.
clúster.
kubectl get nodes
La salida del ejemplo siguiente muestra el nodo único creado en los pasos anteriores. Asegúrese de que el
estado del nodo es Listo:

Creación de una instancia de Servidor flexible de Azure Database for

PostgreSQL
Cree un servidor flexible con el comando az postgreSQL flexible-server create. El siguiente comando crea un
servidor con los valores predeterminados de servicio y los valores del contexto local de la CLI de Azure:
az postgres flexible-server create --public-access <YOUR-IP-ADDRESS>
El servidor creado tiene los siguientes atributos:

Una nueva base de datos vacía, postgres se crea cuando se aprovisiona el servidor por primera vez. En este
inicio rápido, vamos a utilizar esta base de datos.
Nombre del servidor generado automáticamente, nombre de usuario de administrador, contraseña de
administrador, nombre del grupo de recursos (si aún no se ha especificado en el contexto local) y en la
misma ubicación que el grupo de recursos.
Valores predeterminados de servicio para las configuraciones de servidor restantes: nivel de proceso (De uso
general), tamaño de proceso/SKU (Standard_D2s_v3 que usa 2 núcleos virtuales), período de retención de
copia de seguridad (7 días) y versión de PostgreSQL (12)
El uso de un argumento de acceso público le permite crear un servidor con acceso público protegido por
reglas de firewall. Al proporcionar su dirección IP para agregar la regla de firewall, permite el acceso desde la
máquina cliente.
Como el comando utiliza el contexto local, creará el servidor en el grupo de recursos django-project y en la
región eastus .
Compilación de la imagen de Docker de Django

Cree una aplicación Django o use el proyecto Django existente. Asegúrese de que el código se encuentra en esta
estructura de carpetas.
└───my-djangoapp
└───views.py
└───models.py
└───forms.py
├───templates
. . . . . . .
├───static
. . . . . . .
└───my-django-project
└───settings.py
└───urls.py
└───wsgi.py
. . . . . . .
└─── Dockerfile
└─── requirements.txt
└─── manage.py
Actualice ALLOWED_HOSTS en settings.py para asegurarse de que la aplicación Django usa la IP externa que se
asigna a la aplicación kubernetes.
ALLOWED_HOSTS = ['*']
Actualice la sección DATABASES={ } del archivo settings.py . El siguiente fragmento de código lee el host de
base de datos, el nombre de usuario y la contraseña del archivo de manifiesto de Kubernetes.
DATABASES={
'default':{
'ENGINE':'django.db.backends.postgresql_psycopg2',
'NAME':os.getenv('DATABASE_NAME'),
'USER':os.getenv('DATABASE_USER'),
'PASSWORD':os.getenv('DATABASE_PASSWORD'),
'HOST':os.getenv('DATABASE_HOST'),
'PORT':'5432',
'OPTIONS': {'sslmode': 'require'}
}
}
Generación de un archivo requirements.txt

Cree un archivo requirements.txt para enumerar las dependencias de la aplicación Django. Este es un archivo
requirements.txt de ejemplo. Puede usar pip freeze > requirements.txt para generar un archivo
requirements.txt para la aplicación existente.
Django==2.2.17
postgres==3.0.0
psycopg2-binary==2.8.6
psycopg2-pool==1.1
pytz==2020.4

Cree un archivo llamado Dockerfile y copie el siguiente fragmento de código. Use este archivo Dockerfile al
configurar Python 3.8 e instalar todos los requisitos enumerados en el archivo requirements.txt.
# Use the official Python image from the Docker Hub
FROM python:3.8.2
# Make a new directory to put our code in.

RUN mkdir /code
# Change the working directory.

WORKDIR /code
# Copy to code folder

COPY . /code/
# Install the requirements.

RUN pip install -r requirements.txt
# Run the application:

CMD python manage.py runserver 0.0.0.0:8000
Compilación de la imagen
Asegúrese de que se encuentra en el directorio my-django-app en un terminal con el comando cd . Ejecute el
siguiente comando para compilar la imagen del tablón de anuncios:
docker build --tag myblog:latest .
Inserte la imagen en Docker hub o Azure Container Registry.
IMPORTANT
Si utiliza Azure Container Registry (ACR), ejecute el comando az aks update para asociar la cuenta de ACR con el clúster
de AKS.
az aks update -n myAKSCluster -g django-project --attach-acr <your-acr-name>
Creación del archivo de manifiesto de Kubernetes

contenedor se van a ejecutar. Vamos a crear un archivo de manifiesto denominado djangoapp.yaml y a copiarlo
en la siguiente definición de YAML.
IMPORTANT
Reemplace [DOCKER-HUB-USER/ACR ACCOUNT]/[YOUR-IMAGE-NAME]:[TAG] por el nombre y la etiqueta de la imagen
real de Docker de Django, por ejemplo docker-hub-user/myblog:latest .
Actualice la sección env siguiente con SERVERNAME , YOUR-DATABASE-USERNAME , YOUR-DATABASE-PASSWORD del
servidor flexible de Postgres.
apiVersion: apps/v1
kind: Deployment
metadata:
name: django-app
spec:
replicas: 1
selector:
matchLabels:
app: django-app
template:
metadata:
labels:
app: django-app
spec:
containers:
- name: django-app
image: [DOCKER-HUB-USER-OR-ACR-ACCOUNT]/[YOUR-IMAGE-NAME]:[TAG]
ports:
- containerPort: 80
env:
- name: DATABASE_HOST
value: "SERVERNAME.postgres.database.azure.com"
- name: DATABASE_USERNAME
value: "YOUR-DATABASE-USERNAME"
- name: DATABASE_PASSWORD
value: "YOUR-DATABASE-PASSWORD"
- name: DATABASE_NAME
value: "postgres"
affinity:
podAntiAffinity:
- labelSelector:
matchExpressions:
- key: "app"
operator: In
values:
- django-app
topologyKey: "kubernetes.io/hostname"
---
apiVersion: v1
kind: Service
metadata:
name: python-svc
spec:
type: LoadBalancer
ports:
- port: 8000
selector:
app: django-app
Implementación de Django en un clúster de AKS

kubectl apply -f djangoapp.yaml
deployment "django-app" created

service "python-svc" created
Un django-app de implementación permite describir los detalles de la implementación, como por ejemplo las
imágenes que se van a usar para la aplicación, el número de pods y su configuración. Se crea un servicio
python-svc para exponer la aplicación a través de una IP externa.
kubectl get service django-app --watch
En un primer momento, el parámetro EXTERNAL-IP del servicio de django-app se muestra como pendiente.

django-app LoadBalancer 10.0.37.27 <pending> 80:30572/TCP 6s
django-app LoadBalancer 10.0.37.27 52.179.23.131 80:30572/TCP 2m
Ahora abra un explorador web en la dirección IP externa del servicio para ver la aplicación Django.
NOTE
Actualmente, el sitio de Django no utiliza HTTPS. Se recomienda HABILITAR TLS con sus propios certificados.
Puede habilitar el enrutamiento HTTP para el clúster. Cuando se habilita el enrutamiento HTTP, configura un
controlador de entrada en el clúster de AKS. A medida que se implementan aplicaciones, la solución también crea
nombres DNS accesibles públicamente para los puntos de conexión de aplicación.
Ejecución de migraciones de base de datos

En el caso de las aplicaciones Django, debería ejecutar la migración de base de datos o recopilar archivos
estáticos. Para ejecutar estos comandos de la shell de Django se usa $ kubectl exec <pod-name> -- [COMMAND] .
Antes de ejecutar el comando debe buscar el nombre del pod mediante kubectl get pods .
$ kubectl get pods
Verá una salida similar a esta:

django-app-5d9cd6cd8-l6x4b 1/1 Running 0 2m
Una vez que haya encontrado el nombre del pod, puede ejecutar las migraciones de base de datos de Django
con el comando $ kubectl exec <pod-name> -- [COMMAND] . Tenga en cuenta que /code/ es el directorio de
trabajo del proyecto que se ha definido en Dockerfile .
$ kubectl exec django-app-5d9cd6cd8-l6x4b -- python /code/manage.py migrate

La salida sería similar a esta:
Operations to perform:
Apply all migrations: admin, auth, contenttypes, sessions
Running migrations:
Applying contenttypes.0001_initial... OK
Applying auth.0001_initial... OK
Applying admin.0001_initial... OK
Applying admin.0002_logentry_remove_auto_add... OK
Applying admin.0003_logentry_add_action_flag_choices... OK
. . . . . .
Si surgen problemas, ejecute kubectl logs <pod-name> para ver qué excepción genera la aplicación. Si la
aplicación funciona correctamente, verá una salida como la siguiente al ejecutar kubectl logs .
Watching for file changes with StatReloader

Performing system checks...
System check identified no issues (0 silenced).
You have 17 unapplied migration(s). Your project may not work properly until you apply the migrations for
app(s): admin, auth, contenttypes, sessions.
Run 'python manage.py migrate' to apply them.
December 08, 2020 - 23:24:14
Django version 2.2.17, using settings 'django_postgres_app.settings'
Starting development server at http://0.0.0.0:8000/
Quit the server with CONTROL-C.
Limpiar los recursos

Para evitar los cargos de Azure, se recomienda limpiar los recursos que no sean necesarios. Cuando el clúster ya
no se necesite, puede usar el comando az group delete para eliminar el grupo de recursos, el servicio de
contenedor y todos los recursos relacionados.
az group delete --name django-project --yes --no-wait
NOTE
quite.
Pasos siguientes
Aprenda a acceder al panel web de Kubernetes del clúster de AKS.
Aprenda a habilitar la implementación continua
Aprenda a escalar el clúster.
Aprenda a administrar el servidor flexible de Postgres.
Aprenda a configurar parámetros de servidor en el servidor de bases de datos.
Tutorial: Implementación de una aplicación
WordPress en AKS con Servidor flexible de Azure
Database for MySQL
En este inicio rápido se implementa una aplicación WordPress en el clúster de Azure Kubernetes Service (AKS)
con Servidor flexible de Azure Database for MySQL (versión preliminar) mediante la CLI de Azure. AKS es un
servicio de Kubernetes administrado que permite implementar y administrar clústeres rápidamente. Ser vidor
flexible (versión preliminar) de Azure Database for MySQL es un servicio de base de datos totalmente
administrado diseñado para proporcionar un control más pormenorizado y una mayor flexibilidad sobre las
funciones de administración de bases de datos y las opciones de configuración. Actualmente, Servidor flexible
se encuentra en versión preliminar.
NOTE
Actualmente, Azure Database for MySQL con la opción Servidor flexible está en versión preliminar pública.
En este inicio rápido se presupone un conocimiento básico de los conceptos de Kubernetes, WordPress y MySQL.
Requisitos previos

En este artículo se necesita la versión más reciente de la CLI de Azure. Si usa Azure Cloud Shell, ya está
instalada la versión más reciente.
NOTE
Si los comandos de este inicio rápido se ejecutan localmente (en lugar de en Azure Cloud Shell), asegúrese de ejecutarlos
como administrador.

Vamos a crear un grupo de recursos, wordpress-project, mediante el comando [az group create][az-group-
create] en la ubicación eastus.
az group create --name wordpress-project --location eastus
NOTE
La ubicación del grupo de recursos es donde se almacenan los metadatos del grupo de recursos. Es también el lugar en el
que se ejecutan los recursos en Azure si no se especifica otra región al crear los recursos.
{
"id": "/subscriptions/<guid>/resourceGroups/wordpress-project",
"managedBy": null,
"name": "wordpress-project",
"properties": {
},
"tags": null
}

az aks create --resource-group wordpress-project --name myAKSCluster --node-count 1 --generate-ssh-keys
NOTE
Consulte ¿Por qué se crean dos grupos de recursos con AKS?
cli:
az aks install-cli
az aks get-credentials --resource-group wordpress-project --name myAKSCluster

NOTE
clúster.
kubectl get nodes

Creación de un Servidor flexible de Azure Database for MySQL

Cree un servidor flexible con el comando az mysql flexible-server create. El siguiente comando crea un servidor
con los valores predeterminados de servicio y los valores del contexto local de la CLI de Azure:
az mysql flexible-server create --public-access <YOUR-IP-ADDRESS>
El servidor creado tiene los siguientes atributos:

Una nueva base de datos vacía, flexibleserverdb se crea cuando se aprovisiona el servidor por primera vez.
En este inicio rápido, vamos a utilizar esta base de datos.
Nombre del servidor generado automáticamente, nombre de usuario de administrador, contraseña de
administrador, nombre del grupo de recursos (si aún no se ha especificado en el contexto local) y en la
misma ubicación que el grupo de recursos.
Valores predeterminados de servicio para las configuraciones de servidor restantes: nivel de proceso
(Flexible), tamaño de proceso/SKU (B1MS), período de retención de copia de seguridad (7 días) y versión de
MySQL (5.7)
El uso de un argumento de acceso público le permite crear un servidor con acceso público protegido por
reglas de firewall. Al proporcionar su dirección IP para agregar la regla de firewall, permite el acceso desde la
máquina cliente.
Como el comando utiliza el contexto local, creará el servidor en el grupo de recursos wordpress-project y en
la región eastus .
Compilación de la imagen de Docker de WordPress
Descargue la versión de WordPress más reciente. Cree un nuevo directorio my-wordpress-app para el proyecto y
utilice esta estructura de carpetas sencilla.
└───my-wordpress-app
└───public
├───wp-admin
│ ├───css
. . . . . . .
├───wp-content
│ ├───plugins
. . . . . . .
└───wp-includes
. . . . . . .
├───wp-config-sample.php
├───index.php
. . . . . . .
└─── Dockerfile
Cambie el nombre de wp-config-sample.php a wp-config.php y reemplace las líneas de 21 a 32 por este

fragmento de código. El siguiente fragmento de código lee el host de base de datos, el nombre de usuario y la
contraseña del archivo de manifiesto de Kubernetes.
//Using environment variables for DB connection information
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
$connectstr_dbhost = getenv('DATABASE_HOST');
$connectstr_dbusername = getenv('DATABASE_USERNAME');
$connectstr_dbpassword = getenv('DATABASE_PASSWORD');
/** MySQL database name */

define('DB_NAME', 'flexibleserverdb');
/** MySQL database username */

define('DB_USER', $connectstr_dbusername);
/** MySQL database password */

define('DB_PASSWORD',$connectstr_dbpassword);
/** MySQL hostname */

define('DB_HOST', $connectstr_dbhost);
/** Database Charset to use in creating database tables. */

define('DB_CHARSET', 'utf8');
/** The Database Collate type. Don't change this if in doubt. */

define('DB_COLLATE', '');
/** SSL*/
define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL);

Cree un nuevo Dockerfile y copie este fragmento de código. Este Dockerfile configura el servidor web Apache
con PHP y habilita la extensión de mysqli.
FROM php:7.2-apache
COPY public/ /var/www/html/
RUN docker-php-ext-install mysqli
RUN docker-php-ext-enable mysqli
Compilación de la imagen de Docker

Asegúrese de que se encuentra en el directorio my-wordpress-app en un terminal con el comando cd . Ejecute el
siguiente comando para compilar la imagen:
docker build --tag myblog:latest .
Inserte la imagen en Docker hub o Azure Container Registry.
IMPORTANT
Si utiliza Azure Container Registry (ACR), ejecute el comando az aks update para asociar la cuenta de ACR con el clúster
de AKS.
az aks update -n myAKSCluster -g wordpress-project --attach-acr <your-acr-name>
Creación del archivo de manifiesto de Kubernetes

contenedor se van a ejecutar. Vamos a crear un archivo de manifiesto denominado mywordpress.yaml y a
copiarlo en la siguiente definición de YAML.
IMPORTANT
Reemplace [DOCKER-HUB-USER/ACR ACCOUNT]/[YOUR-IMAGE-NAME]:[TAG] por el nombre y la etiqueta de la imagen
real de Docker de WordPress, por ejemplo docker-hub-user/myblog:latest .
Actualice la sección env siguiente con SERVERNAME , YOUR-DATABASE-USERNAME , YOUR-DATABASE-PASSWORD del
servidor flexible de MySQL.
apiVersion: apps/v1
kind: Deployment
metadata:
name: wordpress-blog
spec:
replicas: 1
selector:
matchLabels:
app: wordpress-blog
template:
metadata:
labels:
app: wordpress-blog
spec:
containers:
- name: wordpress-blog
image: [DOCKER-HUB-USER-OR-ACR-ACCOUNT]/[YOUR-IMAGE-NAME]:[TAG]
ports:
- containerPort: 80
env:
- name: DATABASE_HOST
value: "SERVERNAME.mysql.database.azure.com"
- name: DATABASE_USERNAME
value: "YOUR-DATABASE-USERNAME"
- name: DATABASE_PASSWORD
value: "YOUR-DATABASE-PASSWORD"
- name: DATABASE_NAME
value: "flexibleserverdb"
affinity:
podAntiAffinity:
- labelSelector:
matchExpressions:
- key: "app"
operator: In
values:
- wordpress-blog
topologyKey: "kubernetes.io/hostname"
---
apiVersion: v1
kind: Service
metadata:
name: php-svc
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: wordpress-blog
Implementación de WordPress en el clúster de AKS

kubectl apply -f mywordpress.yaml
deployment "wordpress-blog" created

service "php-svc" created
kubectl get service wordpress-blog --watch
En un primer momento, el parámetro EXTERNAL-IP del servicio wordpress-blog se muestra como pendiente.

wordpress-blog LoadBalancer 10.0.37.27 <pending> 80:30572/TCP 6s
wordpress-blog LoadBalancer 10.0.37.27 52.179.23.131 80:30572/TCP 2m
Examen de WordPress
Abra un explorador web en la dirección IP externa del servicio para ver la página de instalación de WordPress.
NOTE
Actualmente, el sitio de WordPress no utiliza HTTPS. Se recomienda HABILITAR TLS con sus propios certificados.
Puede habilitar el enrutamiento HTTP para el clúster.

no se necesite, puede usar el comando az group delete para eliminar el grupo de recursos, el servicio de
contenedor y todos los recursos relacionados.
az group delete --name wordpress-project --yes --no-wait

NOTE
quite.
Pasos siguientes
Aprenda a acceder al panel web de Kubernetes del clúster de AKS.
Aprenda a escalar el clúster.
Aprenda a administrar el servidor flexible de MySQL.
Aprenda a configurar parámetros de servidor en el servidor de bases de datos.
Implementación de una aplicación Java con Open
Liberty o WebSphere Liberty en un clúster de Azure
En este artículo se explica cómo:

Ejecutar una aplicación Java, Java EE, Yakarta EE o Microprofile en el runtime en Open Liberty o WebSphere
Liberty.
Compilar la imagen de Docker de la aplicación mediante imágenes de contenedor de Open Liberty.
Implementar la aplicación contenedorizada en un clúster de AKS mediante el operador de Open Liberty.
El operador de Open Liberty simplifica la implementación y administración de las aplicaciones que se ejecutan
en clústeres de Kubernetes. Con este operador también puede realizar operaciones más avanzadas, como
recopilar seguimientos y volcados.
Para más detalles sobre Open Liberty, consulte la página del proyecto Open Liberty. Para obtener más
información sobre IBM WebSphere Liberty, consulte la página del producto WebSphere Liberty.
Requisitos previos

En este artículo se necesita la versión más reciente de la CLI de Azure. Si usa Azure Cloud Shell, ya está
instalada la versión más reciente.
Si ejecuta los comandos de esta guía de forma local (en lugar de Azure Cloud Shell):
Prepare una máquina local con un sistema operativo similar a Unix instalado (por ejemplo, Ubuntu,
macOS o Subsistema de Windows para Linux).
Instale una implementación de Java SE (por ejemplo, AdoptOpenJDK OpenJDK 8 LTS/OpenJ9).
Instale Maven 3.5.0 o una versión superior.
Instale Docker para el sistema operativo.

Cree un grupo de recursos denominado java-liberty-project mediante el comando az group create en la
ubicación eastus. Este grupo de recursos se usará más adelante para crear la instancia de Azure Container
Registry (ACR) y el clúster de AKS.
RESOURCE_GROUP_NAME=java-liberty-project
az group create --name $RESOURCE_GROUP_NAME --location eastus
Creación de una instancia de ACR

Use el comando az acr create para crear la instancia de ACR. En el ejemplo siguiente se crea una instancia de
ACR denominada youruniqueacrname. Asegúrese de que youruniqueacrname sea única en Azure.
REGISTRY_NAME=youruniqueacrname
az acr create --resource-group $RESOURCE_GROUP_NAME --name $REGISTRY_NAME --sku Basic --admin-enabled
Tras un breve período de tiempo, debería ver una salida JSON que contiene:
"publicNetworkAccess": "Enabled",
"resourceGroup": "java-liberty-project",
Conexión a la instancia de ACR

Tendrá que iniciar sesión en la instancia de ACR para poder insertar una imagen en ella. Ejecute los comandos
siguientes para comprobar la conexión:
LOGIN_SERVER=$(az acr show -n $REGISTRY_NAME --query 'loginServer' -o tsv)

USER_NAME=$(az acr credential show -n $REGISTRY_NAME --query 'username' -o tsv)
PASSWORD=$(az acr credential show -n $REGISTRY_NAME --query 'passwords[0].value' -o tsv)
docker login $LOGIN_SERVER -u $USER_NAME -p $PASSWORD
Debería ver Login Succeeded al final de la salida de los comandos si ha iniciado sesión correctamente en la
instancia de ACR.

CLUSTER_NAME=myAKSCluster
az aks create --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME --node-count 1 --generate-ssh-keys
--enable-managed-identity
Transcurridos unos minutos, el comando se completa y devuelve información en formato JSON sobre el clúster,
incluida la siguiente:
"nodeResourceGroup": "MC_java-liberty-project_myAKSCluster_eastus",
"resourceGroup": "java-liberty-project",
Conexión al clúster de AKS
cli:
az aks install-cli
az aks get-credentials --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME --overwrite-existing
NOTE
clúster.
kubectl get nodes

aks-nodepool1-xxxxxxxx-yyyyyyyyyy Ready agent 76s v1.18.10
Instalación de Operator de Open Liberty

Después de crear el clúster y conectarse a él, ejecute los comandos siguientes para instalar Operator de Open
Liberty.
OPERATOR_NAMESPACE=default
WATCH_NAMESPACE='""'
# Install Custom Resource Definitions (CRDs) for OpenLibertyApplication

kubectl apply -f https://raw.githubusercontent.com/OpenLiberty/open-liberty-
operator/master/deploy/releases/0.7.0/openliberty-app-crd.yaml
# Install cluster-level role-based access

curl -L https://raw.githubusercontent.com/OpenLiberty/open-liberty-
operator/master/deploy/releases/0.7.0/openliberty-app-cluster-rbac.yaml \
| sed -e "s/OPEN_LIBERTY_OPERATOR_NAMESPACE/${OPERATOR_NAMESPACE}/" \
| kubectl apply -f -
# Install the operator

curl -L https://raw.githubusercontent.com/OpenLiberty/open-liberty-
operator/master/deploy/releases/0.7.0/openliberty-app-operator.yaml \
| sed -e "s/OPEN_LIBERTY_WATCH_NAMESPACE/${WATCH_NAMESPACE}/" \
| kubectl apply -n ${OPERATOR_NAMESPACE} -f -
Creación de la imagen de la aplicación
Para implementar y ejecutar la aplicación de Liberty en un clúster de AKS, incluya en un contenedor la aplicación
como una imagen de Docker mediante las imágenes de contenedor de Open Liberty o las imágenes de
contenedor de WebSphere Liberty.
1. Clone el código de ejemplo de esta guía. El ejemplo se encuentra en GitHub.
2. Cambie el directorio a javaee-app-simple-cluster del clon local.
3. Ejecute mvn clean package para empaquetar la aplicación.
4. Ejecute mvn liberty:dev para probar la aplicación. Si el resultado de la operación es satisfactorio, debería ver
The defaultServer server is ready to run a smarter planet. en la salida del comando. Use CTRL-C para
detener la aplicación.
5. Ejecute uno de estos comandos para crear la imagen de la aplicación e insertarla en la instancia de ACR.
Compile con la imagen de base de Open Liberty si prefiere usar Open Liberty como Java™
Runtime ligero de código abierto:
# Build and tag application image. This will cause the ACR instance to pull the necessary Open
Liberty base images.
az acr build -t javaee-cafe-simple:1.0.0 -r $REGISTRY_NAME .
Compile con la imagen de base de WebSphere Liberty si prefiere usar una versión comercial de
Open Liberty:
# Build and tag application image. This will cause the ACR instance to pull the necessary
WebSphere Liberty base images.
az acr build -t javaee-cafe-simple:1.0.0 -r $REGISTRY_NAME --file=Dockerfile-wlp .
Implementación de una aplicación en el clúster de AKS

Siga los pasos que se indican a continuación para implementar la aplicación de Liberty en el clúster de AKS.
1. Cree un secreto de extracción para que el clúster de AKS se autentique para extraer la imagen de la
instancia de ACR.
kubectl create secret docker-registry acr-secret \

--docker-server=${LOGIN_SERVER} \
--docker-username=${USER_NAME} \
--docker-password=${PASSWORD}
2. Compruebe que el directorio de trabajo actual sea javaee-app-simple-cluster del clon local.
3. Ejecute los comandos siguientes para implementar la aplicación de Liberty con tres réplicas en el clúster
de AKS. La salida del comando también se muestra insertada.
# Create OpenLibertyApplication "javaee-app-simple-cluster"
cat openlibertyapplication.yaml | sed -e "s/\${Container_Registry_URL}/${LOGIN_SERVER}/g" | sed -e
"s/\${REPLICAS}/3/g" | kubectl apply -f -
openlibertyapplication.openliberty.io/javaee-app-simple-cluster created
# Check if OpenLibertyApplication instance is created

kubectl get openlibertyapplication javaee-app-simple-cluster
NAME IMAGE EXPOSED

RECONCILED AGE
javaee-app-simple-cluster youruniqueacrname.azurecr.io/javaee-cafe-simple:1.0.0 True
59s
# Check if deployment created by Operator is ready

kubectl get deployment javaee-app-simple-cluster --watch
NAME READY UP-TO-DATE AVAILABLE AGE

javaee-app-simple-cluster 0/3 3 0 20s
4. Espere hasta ver 3/3 en la columna READY y 3 en la columna AVAILABLE , use CTRL-C para detener el
proceso de inspección kubectl .
Cuando se ejecuta la aplicación, un servicio de equilibrador de carga de Kubernetes expone el front-end de la
aplicación a Internet. Este proceso puede tardar en completarse.
kubectl get service javaee-app-simple-cluster --watch

javaee-app-simple-cluster LoadBalancer 10.0.251.169 52.152.189.57 80:31732/TCP 68s
detener el kubectl proceso de inspección.
Abra un explorador web en la dirección IP externa del servicio ( 52.152.189.57 en el ejemplo anterior) para ver
la página principal de la aplicación. Debería ver el nombre de pod de las réplicas de la aplicación en la parte
superior izquierda de la página. Espere unos minutos y actualice la página para ver otro nombre de pod debido
al equilibrio de carga proporcionado por el clúster de AKS.
NOTE
Actualmente, la aplicación no usa HTTPS. Se recomienda HABILITAR TLS con sus propios certificados.

no se necesite, puede usar el comando az group delete para quitar el grupo de recursos, el servicio de
contenedor, el registro de contenedor y todos los recursos relacionados.
az group delete --name $RESOURCE_GROUP_NAME --yes --no-wait
Pasos siguientes
Puede obtener más información en las referencias que se usan en esta guía:
Open Liberty
Operador de Open Liberty
Configuración del servidor Open Liberty
Complemento de Maven para Liberty
Imágenes de contenedor de Open Liberty
Imágenes de contenedor de WebSphere Liberty
Uso de Azure API Management con microservicios
implementados en Azure Kubernetes Service
Los microservicios son idóneos para crear interfaces de programación de aplicaciones. Con Azure Kubernetes
Service (AKS), puede implementar y operar rápidamente una arquitectura basada en microservicios en la nube.
Después, puede aprovechar Azure API Management (API Management) para publicar sus microservicios como
interfaces de programación de aplicaciones para consumo interno y externo. En este artículo se describen las
opciones de implementación de API Management con AKS. Se presupone conocimientos básicos de las redes de
Kubernetes, API Management y Azure.
Información previa
Al publicar microservicios como interfaces de programación de aplicaciones para su consumo, puede ser difícil
administrar la comunicación entre los microservicios y los clientes que los consumen. Hay multitud de
cuestiones transversales tales como la autenticación, la autorización, la limitación, el almacenamiento en caché,
la transformación y la supervisión. Estos problemas son válidos independientemente de si los microservicios se
exponen a clientes internos o externos.
El patrón de puerta de enlace de API aborda estos problemas. Una puerta de enlace de API actúa como puerta
de entrada de los microservicios, desacopla los clientes de los microservicios, agrega una capa de seguridad
adicional y reduce la complejidad de los microservicios al eliminar la carga que supone el control de las
cuestiones transversales.
Azure API Management es una solución llave en mano que permite resolver las necesidades de la puerta de
enlace de API. Puede crear rápidamente una puerta de enlace coherente y moderna para los microservicios y
publicarlos como interfaces de programación de aplicaciones. Como solución de administración de API de ciclo
de vida completo, también proporciona funcionalidades adicionales como, por ejemplo, un portal para
desarrolladores de autoservicio para la detección de API, la administración del ciclo de vida de API y el análisis
de API.
Cuando se usan conjuntamente, AKS y API Management ofrecen una plataforma para implementar, publicar,
proteger, supervisar y administrar las interfaces de programación de aplicaciones basadas en microservicios. En
este artículo, repasaremos algunas opciones de implementación de AKS junto con API Management.
Kubernetes Services e interfaces de programación de aplicaciones

En un clúster de Kubernetes, los contenedores se implementan en Pods, que son efímeros y tienen un ciclo de
vida. Cuando se elimina un nodo de trabajo, se pierden los pods que se ejecutan en el nodo. Por lo tanto, la
dirección IP de un pod puede cambiar en cualquier momento. No podemos confiar en ella para comunicarse
con el pod.
Para solucionar este problema, Kubernetes presentó el concepto de Services. Una instancia de Kubernetes
Service es una capa de abstracción que define un grupo lógico de pods y permite la exposición del tráfico
externo, el equilibrio de carga y la detección de servicios para esos pods.
Cuando estamos preparados para publicar nuestros microservicios como interfaces de programación de
aplicaciones a través de API Management, debemos pensar en cómo asignar nuestros servicios en Kubernetes a
las API de API Management. No hay reglas establecidas. Depende de cómo haya diseñado y particionado sus
capacidades o dominios empresariales en microservicios al principio. Por ejemplo, si los pods detrás de un
servicio son responsables de todas las operaciones en un recurso determinado (por ejemplo, el cliente), el
servicio se puede asignar a una API. Si las operaciones de un recurso se particionan en varios microservicios
(por ejemplo, GetOrder, PlaceOrder), es posible que varios servicios se agreguen lógicamente en una única API
de API Management (vea la figura 1).
También se pueden desarrollar las asignaciones. Como API Management crea una fachada delante de los
microservicios, nos permite refactorizar y ajustar el tamaño de nuestros microservicios a lo largo del tiempo.
Implementación de API Management delante de AKS

Existen algunas opciones de implementación de API Management delante de un clúster de AKS.
Aunque un clúster de AKS se implementa siempre en una red virtual, no hay que implementar una instancia de
API Management en una red virtual. Cuando API Management no reside en la red virtual del clúster, el clúster de
AKS tiene que publicar puntos de conexión públicos a los que API Management se conecte. En ese caso, es
necesario proteger la conexión entre API Management y AKS. En otras palabras, debemos asegurarnos de que al
clúster solo se pueda acceder exclusivamente a través de API Management. Vamos a analizar estas opciones.
Opción 1: Exposición pública de los servicios
Los servicios de un clúster de AKS se pueden exponer públicamente con tipos de servicio de NodePort,
LoadBalancer o ExternalName. En este caso, los servicios son accesibles directamente desde Internet público.
Después de implementar API Management delante del clúster, hay que asegurarse de que todo el tráfico de
entrada pase por API Management aplicando la autenticación en los microservicios. Por ejemplo, API
Management puede incluir un token de acceso en cada solicitud realizada al clúster. Cada microservicio es
responsable de validar el token antes de procesar la solicitud.
Esta podría ser la opción más sencilla de implementar API Management delante de AKS, especialmente si ya
tiene lógica de autenticación implementada en sus microservicios.
Ventajas:
Fácil configuración en el lado de API Management porque no hay que insertarla en la red virtual del clúster
No se produce ningún cambio en el lado de AKS si los servicios ya se exponen públicamente y la lógica de
autenticación ya existe en microservicios
Inconvenientes:
Posible riesgo de seguridad debido a la visibilidad pública de los puntos de conexión de servicio
No hay un punto de entrada único para el tráfico de entrada del clúster
Complica los microservicios con lógica de autenticación duplicada
Opción 2: Instalación de un controlador de entrada
Aunque la opción 1 podría ser más fácil, tiene notables inconvenientes como se ha mencionado anteriormente.
Si una instancia de API Management no reside en la red virtual del clúster, la autenticación Mutual TLS (mTLS) es
una manera robusta de garantizar que el tráfico sea seguro y de confianza en ambas direcciones entre una
instancia de API Management y un clúster de AKS.
La autenticación Mutual TLS es compatible de forma nativa con API Management y se puede habilitar en
Kubernetes mediante la instalación de un controlador de entrada (figura 3). Como resultado, la autenticación se
realizará en el controlador de entrada, lo que simplifica los microservicios. Además, puede agregar las
direcciones IP de API Management a la lista de permitidos por entrada para asegurarse de que solo API
Management tiene acceso al clúster.
Ventajas:
Fácil configuración en el lado de API Management porque no hay que insertarla en la red virtual del clúster y
mTLS es compatible de forma nativa
Centraliza la protección del tráfico de clústeres de entrada en la capa de controlador de entrada
Reduce el riesgo de seguridad al minimizar los puntos de conexión de clúster visibles públicamente
Inconvenientes:
Aumenta la complejidad de la configuración del clúster debido al trabajo adicional de instalar, configurar y
mantener el controlador de entrada y administrar los certificados usados con mTLS
Riesgo de seguridad debido a la visibilidad pública de los puntos de conexión del controlador de entrada
Al publicar las API mediante API Management, es sencillo y frecuente proteger el acceso a ellas mediante claves
de suscripción. Los desarrolladores que necesiten usar las API publicadas deben incluir una clave de suscripción
válida en las solicitudes HTTP al realizar llamadas a esas API. De lo contrario, la puerta de enlace de API
Management rechaza las llamadas inmediatamente. No se reenvían a los servicios back-end.
Para obtener una clave de suscripción para acceder a las API se necesita una suscripción. Una suscripción es
básicamente un contenedor con nombre para un par de claves de suscripción. Los desarrolladores que
necesiten usar las API publicadas pueden obtener suscripciones. Y no necesitan aprobación de los publicadores
de API. Los publicadores de API también pueden crear suscripciones directamente para los consumidores de
API.
Opción 3: Implementación de APIM dentro de la red virtual del clúster
En algunos casos, es posible que a los clientes con restricciones normativas o estrictos requisitos de seguridad
les parezca que las opciones 1 y 2 no son soluciones viables debido a los puntos finales expuestos
públicamente. En otros, el clúster de AKS y las aplicaciones que consumen los microservicios pueden residir en
la misma red virtual; por lo tanto, no hay ninguna razón para exponer el clúster de forma pública, ya que todo el
tráfico de la API permanecerá dentro de la red virtual. En estos casos, puede implementar API Management en la
red virtual del clúster. Los niveles de desarrollador y prémium de API Management admiten la implementación
de red virtual.
Hay dos modos de implementación de API Management en una red virtual: externo e interno.
Si los consumidores de la API no residen en la red virtual del clúster, ha de usarse el modo externo (figura 4). En
este modo, la puerta de enlace de API Management se inserta en la red virtual del clúster, pero es accesible
desde Internet público a través de un equilibrador de carga externo. Ayuda a ocultar por completo el clúster
mientras sigue permitiendo a los clientes externos consumir los microservicios. Además, puede usar
funcionalidades de red de Azure tales como los grupos de seguridad de red (NSG), para restringir el tráfico.
Si todos los consumidores de la API residen dentro de la red virtual del clúster, se podría usar el modo interno
(figura 5). En este modo, la puerta de enlace de API Management se inserta en la red virtual del clúster y solo es
accesible desde el interior de esta red virtual a través de un equilibrador de carga interno. No hay forma de
llegar a la puerta de enlace de API Management o al clúster de AKS desde Internet público.
En ambos casos, el clúster de AKS no es visible públicamente. A diferencia de la opción 2, es posible que el
controlador de entrada no sea necesario. Según el escenario y la configuración, es posible que se requiera
autenticación entre API Management y los microservicios. Por ejemplo, si se adopta una malla de servicio,
siempre se requiere la autenticación Mutual TLS.
Ventajas:
Se trata de la opción más segura porque el clúster de AKS no tiene ningún punto de conexión público
Simplifica la configuración del clúster porque no tiene ningún punto de conexión público
Posibilidad de ocultar API Management y AKS dentro de la red virtual mediante el modo interno
Posibilidad de controlar el tráfico de red con funcionalidades de red de Azure tales como los grupos de
seguridad de red (NSG)
Inconvenientes:
Complica la implementación y configuración de API Management para trabajar dentro de la red virtual
Pasos siguientes
Más información sobre Conceptos de red para aplicaciones en AKS
Más información sobre el uso de API Management con redes virtuales
Acerca de las mallas de servicio
Una malla de servicio proporciona a las cargas de trabajo funcionalidades como administración del tráfico,
resistencia, directiva, seguridad, identidad sólida y observabilidad. La aplicación se desacopla de estas funciones
operativas y la malla del servicio las retira de la capa de la aplicación, bajándolas al nivel de infraestructura.
Escenarios
Estos son algunos de los escenarios que se pueden habilitar para las cargas de trabajo cuando se usa una malla
de servicio:
Cifrar todo el tráfico del clúster : habilite TLS mutuo entre los servicios especificados del clúster. Se
puede extender a la entrada y salida en el perímetro de la red. Proporciona una opción segura de forma
predeterminada sin necesidad de realizar cambios en el código y en la infraestructura de la aplicación.
Lanzamientos controlados y por fases : especifique las condiciones para que un subconjunto de
tráfico se enrute a un conjunto de nuevos servicios del clúster. Si la prueba del lanzamiento controlado es
correcta, quite el enrutamiento y la fase condicionales, aumentando gradualmente el porcentaje de tráfico
al nuevo servicio. Al final, todo el tráfico se dirigirá al nuevo servicio.
Administración y manipulación del tráfico : cree una directiva en un servicio que limite la frecuencia
de todo el tráfico a una versión de un servicio en un origen específico. O bien una directiva que aplique
una estrategia de reintento a clases de errores entre servicios especificados. Refleje el tráfico real en
nuevas versiones de servicios durante una migración o para depurar problemas. Inserte errores entre los
servicios en un entorno de prueba para probar la resistencia.
Obser vabilidad : obtenga información sobre cómo se conectan los servicios al tráfico que fluye entre
ellos. Obtenga métricas, registros y seguimientos para todo el tráfico del clúster, así como para la entrada
y la salida. Agregue funcionalidades de seguimiento distribuido a las aplicaciones.
Architecture
Una malla de servicio suele estar compuesta por el plano de control y el plano de datos.
El plano de control cuenta con una serie de componentes que dan soporte a la administración de la malla de
servicio. Por lo general, incluye una interfaz de administración, que puede ser una interfaz de usuario o una API.
También suele haber componentes que administran las definiciones de reglas y directivas que establecen cómo
la malla de servicio debe implementar funcionalidades específicas. Hay, además, componentes que administran
aspectos de seguridad como la identidad sólida y los certificados para mTLS. Las mallas de servicio también
suelen contar con un componente de métricas u observabilidad que recopila y agrega métricas y datos de
telemetría de las cargas de trabajo.
El plano de datos consta normalmente de un proxy que se inserta de forma transparente como sidecar en las
cargas de trabajo. Este proxy se configura para controlar todo el tráfico de red de entrada y salida del pod que
contiene la carga de trabajo. Esto permite configurar el proxy para proteger el tráfico a través de mTLS, enrutar
dinámicamente el tráfico, aplicar directivas al tráfico y recopilar métricas e información de seguimiento.
Capacidades
Cada una de las mallas de servicio tiene un ajuste natural y se centra en la compatibilidad con escenarios
específicos, pero verá que habitualmente la mayoría implementará varias de las siguientes funcionalidades, si
no todas.
Administración del tráfico
Protocolo : nivel 7 (http, grpc)
Enrutamiento dinámico : condicional, ponderación, creación de reflejo
Resistencia : tiempos de espera, reintentos, disyuntores
Directiva : control de acceso, límites de frecuencia, cuotas
Pruebas : inserción de errores
Seguridad
Cifrado : mTLS, administración de certificados, entidad de certificación externa
Identidad sólida : SPIFFE o similar
Autenticación : autenticación, autorización
Observabilidad
Métricas : métricas principales, Prometheus, Grafana
Seguimiento : seguimientos entre las cargas de trabajo
Tráfico : clúster, entrada y salida
Malla
Proceso compatible : Kubernetes, máquinas virtuales
Varios clústeres : puertas de enlace, federación
Criterios de selección
Antes de seleccionar una malla de servicio, asegúrese de que comprende los requisitos y las razones para
instalarla. Intente responder a las siguientes preguntas.
¿Es un controlador de entrada suficiente para mis necesidades? A veces, contar con una
funcionalidad como las pruebas A/B o la división del tráfico en la entrada es suficiente para el escenario
requerido. No agregue complejidad a su entorno si no supone una ventaja.
¿Las cargas de trabajo y el entorno actuales pueden tolerar las sobrecargas adicionales?
Todos los componentes adicionales necesarios para admitir la malla de servicio requieren recursos
adicionales, como CPU y memoria. Además, todos los proxies y sus comprobaciones de directiva
asociadas agregan latencia al tráfico. Si tiene cargas de trabajo muy sensibles a la latencia o no puede
proporcionar los recursos adicionales necesarios para cubrir los componentes de la malla de servicio,
replantéese esta opción.
¿Esta opción agrega complejidad adicional innecesaria? Si el motivo para instalar una malla de
servicio es conseguir una funcionalidad que no es necesariamente crítica para los equipos empresariales
u operativos, considere si merece la pena la complejidad adicional de la instalación, el mantenimiento y la
configuración.
¿Se puede adoptar con una estrategia incremental? Algunas de las mallas de servicio que
proporcionan una gran cantidad de funciones se pueden adoptar de modo incremental. Instale solo los
componentes que necesita para cubrir sus necesidades. Una vez que esté más seguro y se necesiten
funcionalidades adicionales, explore dichas opciones. Resista la tentación de instalar todo desde el
principio.
Si, tras una detenida consideración, decide que necesita una malla de servicio para proporcionar las
funcionalidades requeridas, la siguiente pregunta que debe plantearse es: ¿Qué malla de servicio?
Tenga en cuenta las siguientes áreas y cuáles se adaptan más a sus requisitos. Esto le ayudará a conseguir el
mejor ajuste para su entorno y sus cargas de trabajo. La sección Pasos siguientes le llevará a información más
detallada sobre mallas de servicio específicas y cómo se asignan a estas áreas.
Área técnica : administración del tráfico, directiva, seguridad, observabilidad
Área empresarial : soporte comercial, base (CNCF), licencia de OSS, gobernanza
Área operativa : instalación y actualizaciones, requisitos de recursos, requisitos de rendimiento,
integraciones (métricas, telemetría, paneles, herramientas, SMI), cargas de trabajo mixtas (grupos de
nodos de Linux y Windows), proceso (Kubernetes, máquinas virtuales), varios clústeres
Área de seguridad : autenticación, identidad, administración y rotación de certificados, entidad de
certificación externa acoplable
Pasos siguientes
La siguiente documentación proporciona más información sobre las mallas de servicio que puede probar en
Azure Kubernetes Service (AKS):
Más información sobre Istio...
Más información sobre Linkerd...
Más información sobre Consul...
También puede explorar Service Mesh Interface (SMI), una interfaz estándar para las mallas de servicio en
Kubernetes:
Service Mesh Interface (SMI)
Complemento Open Service Mesh (versión
preliminar) de AKS
Open Service Mesh (OSM) es una malla de servicio nativa ligera, extensible y en la nube que permite a los
usuarios administrar de forma uniforme características de observación para entornos de microservicios muy
dinámicos, así como protegerlas y disfrutar de ellas de inmediato.
OSM ejecuta un plano de control basado en Envoy en Kubernetes, se puede configurar con API de SMI y
funciona insertando un proxy de Envoy como un contenedor sidecar junto a cada instancia de la aplicación. El
proxy de Envoy contiene y ejecuta reglas en torno a las directivas de control de acceso, implementa la
configuración de enrutamiento y captura las métricas. El plano de control configura continuamente los
servidores proxy para asegurarse de que las directivas y las reglas de enrutamiento están actualizadas y
garantiza que los servidores proxy sean correctos.
IMPORTANT
Características y funcionalidades
OSM proporciona el siguiente conjunto de funcionalidades y características para proporcionar una malla de
servicio nativa en la nube para los clústeres de Azure Kubernetes Service (AKS):
Protección de la comunicación de servicio a servicio habilitando mTLS
Incorporación de aplicaciones a la malla con facilidad habilitando la inserción automática del sidecar del
proxy de Envoy
Configuraciones sencillas y transparentes para el desplazamiento del tráfico en las implementaciones
Capacidad de definir y ejecutar directivas de control de acceso detalladas de los servicios
Observabilidad e información detallada sobre las métricas de la aplicación para los servicios de
depuración y supervisión
Integración con servicios o soluciones externos de administración de certificados con una interfaz
acoplable
Escenarios
OSM puede ayudar a las implementaciones de AKS con los siguientes escenarios:
Provisión de comunicaciones cifradas entre los puntos de conexión de servicio implementados en el
clúster
Autorización del tráfico HTTP/HTTPS y TCP en la malla
Configuración de controles de tráfico ponderado entre dos o más servicios para implementaciones A/B o
de valor controlado
Recopilación y visualización de KPI desde el tráfico de la aplicación
Límites y cuotas de servicio de OSM (versión preliminar)

Las limitaciones de la versión preliminar de OSM respecto a las cuotas y los límites de servicio se pueden
encontrar en la página de cuotas y límites regionales de AKS.
Descarga e instalación del binario de cliente de OSM

En un shell basado en Bash en Linux o en el Subsistema de Windows para Linux, utilice curl para descargar la
versión de OSM y, a continuación, realice la extracción con tar , tal como se indica a continuación:
# Specify the OSM version that will be leveraged throughout these instructions
OSM_VERSION=v0.8.2
curl -sL "https://github.com/openservicemesh/osm/releases/download/$OSM_VERSION/osm-$OSM_VERSION-linux-

amd64.tar.gz" | tar -vxzf -
El binario de cliente osm se ejecuta en la máquina cliente y permite administrar el controlador de OSM en el
clúster de AKS. Use los comandos siguientes para instalar el binario de cliente osm de OSM en un shell basado
en Bash en Linux o en el Subsistema de Windows para Linux. Estos comandos copian el binario de cliente osm
en la ubicación del programa de usuario estándar en su PATH .
sudo mv ./linux-amd64/osm /usr/local/bin/osm

sudo chmod +x /usr/local/bin/osm
Puede comprobar que la biblioteca cliente osm se ha agregado correctamente a la ruta de acceso y su número
de versión con el siguiente comando.
osm version

En un shell basado en Bash, utilice curl para descargar la versión de OSM y, a continuación, realice la
extracción con tar , tal como se indica a continuación:
OSM_VERSION=v0.8.2
curl -sL "https://github.com/openservicemesh/osm/releases/download/$OSM_VERSION/osm-$OSM_VERSION-darwin-

amd64.tar.gz" | tar -vxzf -
clúster de AKS. Use los siguientes comandos para instalar el binario de cliente osm de OSM en un shell basado
en Bash en macOS. Estos comandos copian el binario de cliente osm en la ubicación del programa de usuario
estándar en su PATH .
sudo mv ./darwin-amd64/osm /usr/local/bin/osm

sudo chmod +x /usr/local/bin/osm
Puede comprobar que la biblioteca cliente osm se ha agregado correctamente a la ruta de acceso y su número
de versión con el siguiente comando.
osm version

En un shell basado en PowerShell en Windows, use Invoke-WebRequest para descargar la versión de Istio y, a
continuación, realice la extracción con Expand-Archive , como se indica a continuación:
$OSM_VERSION="v0.8.2"
[Net.ServicePointManager]::SecurityProtocol = "tls12"
$ProgressPreference = 'SilentlyContinue'; Invoke-WebRequest -URI
"https://github.com/openservicemesh/osm/releases/download/$OSM_VERSION/osm-$OSM_VERSION-windows-
amd64.zip" -OutFile "osm-$OSM_VERSION.zip"
Expand-Archive -Path "osm-$OSM_VERSION.zip" -DestinationPath .
clúster de AKS. Use los siguientes comandos para instalar el binario de cliente osm de OSM en un shell basado
en PowerShell en Windows. Estos comandos copian los binarios de cliente osm en una carpeta de OSM y, luego,
permiten que estén disponibles de inmediato (en el shell actual) y de forma permanente (entre reinicios del
shell) mediante PATH . No es necesario tener privilegios elevados (administrador) para ejecutar estos comandos
y no hace falta reiniciar el shell.
# Copy osm.exe to C:\OSM

New-Item -ItemType Directory -Force -Path "C:\OSM"
Move-Item -Path .\windows-amd64\osm.exe -Destination "C:\OSM\"
# Add C:\OSM to PATH.

# Make the new PATH permanently available for the current User
$USER_PATH = [environment]::GetEnvironmentVariable("PATH", "User") + ";C:\OSM\"
[environment]::SetEnvironmentVariable("PATH", $USER_PATH, "User")
# Make the new PATH immediately available in the current shell
$env:PATH += ";C:\OSM\"
WARNING
No intente instalar OSM desde el archivo binario mediante osm install . Esto producirá una instalación de OSM que no
está integrada como un complemento para AKS.
Registro de la característica en vista previa (GB ) AKS-OpenServiceMesh
Para crear un clúster de AKS que use el complemento Open Service Mesh, debe habilitar la marca de
características AKS-OpenServiceMesh en su suscripción.
Registre la marca de la característica AKS-OpenServiceMesh con el comando az feature register, como se muestra
az feature register --namespace "Microsoft.ContainerService" --name "AKS-OpenServiceMesh"
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/AKS-OpenServiceMesh')].

IMPORTANT
Instalación del complemento Open Service Mesh (OSM) de Azure

Kubernetes Service (AKS) para un nuevo clúster de AKS
Para un nuevo escenario de implementación de clústeres de AKS, comenzará con una nueva implementación de
un clúster de AKS habilitando el complemento OSM en la operación de creación del clúster.
En Azure, puede asignar recursos relacionados a un grupo de recursos. Para crear un grupo de recursos, use az
group create. En el ejemplo siguiente se crea un grupo de recursos denominado myOsmAksGroup en la
ubicación eastus2:
az group create --name <myosmaksgroup> --location <eastus2>
Implementación de un clúster de AKS con el complemento OSM habilitado

Ahora implementará un nuevo clúster de AKS con el complemento OSM habilitado.
NOTE
Tenga en cuenta que el siguiente comando de implementación de AKS utiliza discos de sistema operativo efímeros. Puede
encontrar más información aquí sobre los discos de sistema operativo efímeros para AKS
az aks create -n osm-addon-cluster -g <myosmaksgroup> --kubernetes-version 1.19.6 --node-osdisk-type

Ephemeral --node-osdisk-size 30 --network-plugin azure --enable-managed-identity -a open-service-mesh
Obtención de credenciales de acceso de clúster de AKS

Obtenga las credenciales de acceso para el nuevo clúster de Kubernetes administrado.
az aks get-credentials -n <myosmakscluster> -g <myosmaksgroup>
Habilitación del complemento Open Service Mesh (OSM) de Azure

Kubernetes Service (AKS) para un clúster de AKS existente
En un escenario de clúster de AKS existente, habilitará el complemento OSM en un clúster de AKS existente que
ya se ha implementado.
Habilitación del complemento OSM en el clúster de AKS existente
Para habilitar el complemento OSM de AKS, deberá ejecutar el comando az aks enable-addons --addons
pasando el parámetro open-service-mesh .
az aks enable-addons --addons open-service-mesh -g <resource group name> -n <AKS cluster name>
Debería ver una salida similar a la salida que se muestra a continuación para confirmar que se ha instalado el
complemento OSM de AKS.
{- Finished ..
"aadProfile": null,
"addonProfiles": {
"KubeDashboard": {
"config": null,
"enabled": false,
"identity": null
},
"openServiceMesh": {
"config": {},
"enabled": true,
"identity": {
...
Validación de la instalación del complemento OSM de AKS

Hay varios comandos que se ejecutan para comprobar que todos los componentes del complemento OSM de
AKS están habilitados y en ejecución:
En primer lugar, se pueden consultar los perfiles de complemento del clúster para comprobar el estado
habilitado de los complementos instalados. El siguiente comando debe devolver "true".
az aks list -g <resource group name> -o json | jq -r '.[].addonProfiles.openServiceMesh.enabled'
Los siguientes comandos kubectl informarán del estado del controlador de OSM.
kubectl get deployments -n kube-system --selector app=osm-controller

kubectl get pods -n kube-system --selector app=osm-controller
kubectl get services -n kube-system --selector app=osm-controller
Acceso al complemento OSM de AKS

Actualmente, puede acceder a la configuración del controlador de OSM y ajustarla a través de configmap. Para
ver las opciones de configuración del controlador de OSM, consulte el archivo configmap osm-config mediante
kubectl para ver sus opciones de configuración.
kubectl get configmap -n kube-system osm-config -o json | jq '.data'
La salida del configmap de OSM debe ser similar a la siguiente:
{
"egress": "true",
"enable_debug_server": "true",
"enable_privileged_init_container": "false",
"envoy_log_level": "error",
"outbound_ip_range_exclusion_list": "169.254.169.254/32,168.63.129.16/32,<YOUR_API_SERVER_PUBLIC_IP>/32",
"permissive_traffic_policy_mode": "true",
"prometheus_scraping": "false",
"service_cert_validity_duration": "24h",
"use_https_ingress": "false"
}
Observe que permissive_traffic_policy_mode está configurado en true . El modo de la directiva de tráfico

permisivo en OSM es un modo en el que se omite la aplicación de directivas de tráfico de SMI. En este modo,
OSM detecta automáticamente los servicios que forman parte de la malla de servicio y programa reglas de la
directiva de tráfico en cada sidecar del proxy de Envoy para comunicarse con estos servicios.
WARNING
Antes de continuar, compruebe que el modo de la directiva de tráfico permisivo está establecida en true; si no es así,
cámbiela a true mediante el comando siguiente.
kubectl patch ConfigMap -n kube-system osm-config --type merge --patch '{"data":

{"permissive_traffic_policy_mode":"true"}}'
Implementación de una nueva aplicación para que la administre el

complemento Open Service Mesh (OSM) de Azure Kubernetes
Service (AKS)
Antes de empezar
En los pasos que se detallan en este tutorial se supone que ha creado un clúster de AKS (Kubernetes 1.19+ y
versiones posteriores, con el RBAC de Kubernetes habilitado), ha establecido una conexión kubectl con el
clúster (si necesita ayuda con cualquiera de estos elementos, consulte el inicio rápido de AKS) y ha instalado el
Debe tener instalados los siguientes recursos:
Extensión aks-preview , versión 0.5.5 o posterior
Versión v.0.8.0 o posterior de OSM
apt-get install jq
Creación de espacios de nombres para la aplicación
En este tutorial, vamos a usar la aplicación de librería de OSM que tiene los siguientes servicios de Kubernetes:
bookbuyer
bookthief
bookstore
bookwarehouse
Cree espacios de nombres para cada uno de estos componentes de la aplicación.
for i in bookstore bookbuyer bookthief bookwarehouse; do kubectl create ns $i; done
Debería ver la siguiente salida:
namespace/bookstore created
namespace/bookbuyer created
namespace/bookthief created
namespace/bookwarehouse created
Incorporación de los espacios de nombres que se van a administrar mediante OSM

La adición de los espacios de nombres a la malla de OSM permitirá que el controlador de OSM inserte
automáticamente los contenedores del proxy de sidecar de Envoy en la aplicación. Ejecute el siguiente comando
para incorporar los espacios de nombres de la aplicación de librería de OSM.
osm namespace add bookstore bookbuyer bookthief bookwarehouse
Namespace [bookstore] successfully added to mesh [osm]

Namespace [bookbuyer] successfully added to mesh [osm]
Namespace [bookthief] successfully added to mesh [osm]
Namespace [bookwarehouse] successfully added to mesh [osm]
Implementación de la aplicación Bookstore en el clúster de AKS
kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-

v0.8/docs/example/manifests/apps/bookbuyer.yaml

v0.8/docs/example/manifests/apps/bookthief.yaml

v0.8/docs/example/manifests/apps/bookstore.yaml

v0.8/docs/example/manifests/apps/bookwarehouse.yaml
A continuación se resumen todas las salidas de la implementación.

serviceaccount/bookbuyer created
service/bookbuyer created
deployment.apps/bookbuyer created
serviceaccount/bookthief created
service/bookthief created
deployment.apps/bookthief created
service/bookstore created
serviceaccount/bookstore created
deployment.apps/bookstore created
serviceaccount/bookwarehouse created
service/bookwarehouse created
deployment.apps/bookwarehouse created
Punto de control: ¿qué se ha instalado?

La aplicación Bookstore de ejemplo es una aplicación de varios niveles que consta de cuatro servicios, que son
bookbuyer, bookthief, bookstore y bookwarehouse. El servicio bookbuyer y bookthief se comunican con el
servicio bookstore para recuperar libros del servicio bookstore. El servicio bookstore recupera los libros del
servicio bookwarehouse para abastecer a bookbuyer y bookthief. Se trata de una aplicación sencilla de varios
niveles que funciona bien para mostrar cómo se puede usar una malla de servicio para proteger y autorizar las
comunicaciones entre los servicios de aplicaciones. A medida que sigamos con el tutorial, se habilitarán y
deshabilitarán las directivas de Service Mesh Interface (SMI) para permitir y no permitir que los servicios se
comuniquen a través de OSM. A continuación se muestra un diagrama de arquitectura de lo que se ha instalado
para la aplicación bookstore.
Comprobación de que la aplicación Bookstore se ejecuta en el clúster de AKS

Ahora, hemos implementado la aplicación bookstore de varios contenedores, pero solo se puede acceder a ella
desde el clúster de AKS. Los tutoriales posteriores le ayudarán a exponer la aplicación fuera del clúster a través
de un controlador de entrada. Por ahora, vamos a utilizar el reenvío de puertos para acceder a la aplicación
bookbuyer dentro del clúster de AKS para comprobar que compra libros del servicio bookstore.
Para comprobar que la aplicación se ejecuta dentro del clúster, utilizaremos un reenvío de puerto para ver la
interfaz de usuario de los componentes bookbuyer y bookthief.
En primer lugar, vamos a obtener el nombre del pod de bookbuyer.
kubectl get pod -n bookbuyer
Debería ver una salida similar a la siguiente. El pod de bookbuyer tendrá un nombre único anexado.
bookbuyer-7676c7fcfb-mtnrz 2/2 Running 0 7m8s
Una vez que tenemos el nombre del pod, podemos usar el comando de reenvío de puerto para configurar un
túnel desde nuestro sistema local a la aplicación dentro del clúster de AKS. Ejecute el siguiente comando para
configurar el reenvío de puertos para el puerto del sistema local 8080. Vuelva a usar el nombre del pod de
bookbuyer especificado.
NOTE
Para todos los comandos de reenvío de puertos es mejor utilizar un terminal adicional para que pueda seguir trabajando
en este tutorial y no desconectar el túnel. También es mejor establecer el túnel de reenvío de puertos fuera de Azure
Cloud Shell.
kubectl port-forward bookbuyer-7676c7fcfb-mtnrz -n bookbuyer 8080:14001
Debería mostrarse una salida similar a esta.
Forwarding from 127.0.0.1:8080 -> 14001

Forwarding from [::1]:8080 -> 14001
Mientras la sesión de reenvío de puertos está en marcha, navegue a la siguiente URL desde un navegador
http://localhost:8080 . Ahora debería poder ver la interfaz de usuario de la aplicación bookbuyer en el
explorador, similar a la imagen siguiente.
También observará que el número total de libros comprados continúa aumentando al servicio bookstore v1.
Todavía no se ha implementado el servicio bookstore v2. Implementaremos el servicio bookstore v2 cuando se
demuestren las directivas de división del tráfico de SMI.
También puede comprobar lo mismo para el servicio bookthief.
kubectl get pod -n bookthief

Debería ver una salida similar a la siguiente. El pod de bookthief tendrá un nombre único anexado.

bookthief-59549fb69c-cr8vl 2/2 Running 0 15m54s
Reenvío de puertos al pod de bookthief.
kubectl port-forward bookthief-59549fb69c-cr8vl -n bookthief 8080:14001
Abra un explorador y vaya a la dirección URL siguiente http://localhost:8080 . Debería ver que bookthief está
robando libros del servicio bookstore. Más adelante, implementaremos una directiva de tráfico para detener a
bookthief.
Deshabilitación del modo de tráfico permisivo de OSM para la malla

Como se mencionó anteriormente al ver la configuración del clúster de OSM, la configuración de OSM tiene
habilitada de manera predeterminada la directiva del modo de tráfico permisivo. En este modo, la aplicación de
la directiva del trafico se omite y OSM detecta automáticamente los servicios que forman parte de la malla de
servicio y programa reglas de la directiva de tráfico en cada sidecar del proxy de Envoy para comunicarse con
estos servicios.
Ahora deshabilitaremos la directiva del modo de tráfico permisivo y OSM necesitará directivas de SMI explícitas
implementadas en el clúster para permitir las comunicaciones en la malla de cada servicio. Para deshabilitar el
modo de tráfico permisivo, ejecute el siguiente comando para actualizar la propiedad configmap cambiando el
valor de true a false .

{"permissive_traffic_policy_mode":"false"}}'
Debería ver una salida similar a la siguiente. El pod de bookthief tendrá un nombre único anexado.
configmap/osm-config patched
Para comprobar que se ha deshabilitado el modo de tráfico permisivo, vuelva a enviar el puerto al pod de
bookbuyer o bookthief para ver su interfaz de usuario en el explorador y ver si los libros comprados o los libros
robados ya no se incrementan. Asegúrese de actualizar el explorador. Si se ha detenido el incremento, la
directiva se aplicó correctamente. Ha conseguido impedir que bookthief robe libros, pero ni el elemento
bookbuyer puede comprar en el servicio bookstore ni este servicio bookstore puede recuperar libros del
almacén bookwarehouse. A continuación, implementaremos directivas de SMI para permitir que solo se
comuniquen los servicios de la malla que desee.
Aplicación de directivas de acceso de tráfico de Service Mesh Interface (SMI )
Ahora que hemos deshabilitado todas las comunicaciones de la malla, permitiremos que nuestro servicio
bookbuyer se comunique con nuestro servicio bookstore para comprar libros, y que nuestro servicio bookstore
se comunique con nuestro servicio bookwarehouse para recuperar los libros que se van a vender.
Implemente las siguientes directivas de SMI.
kubectl apply -f - <<EOF

---
apiVersion: access.smi-spec.io/v1alpha3
kind: TrafficTarget
metadata:
name: bookbuyer-access-bookstore
namespace: bookstore
spec:
destination:
kind: ServiceAccount
name: bookstore
rules:
- kind: HTTPRouteGroup
name: bookstore-service-routes
matches:
- buy-a-book
- books-bought
sources:
- kind: ServiceAccount
name: bookbuyer
namespace: bookbuyer
---
apiVersion: specs.smi-spec.io/v1alpha4
kind: HTTPRouteGroup
metadata:
spec:
matches:
- name: books-bought
pathRegex: /books-bought
methods:
- GET
headers:
- "user-agent": ".*-http-client/*.*"
- "client-app": "bookbuyer"
- name: buy-a-book
pathRegex: ".*a-book.*new"
methods:
- GET
- name: update-books-bought
pathRegex: /update-books-bought
methods:
- POST
---
kind: TrafficTarget
metadata:
name: bookstore-access-bookwarehouse
namespace: bookwarehouse
spec:
destination:
name: bookwarehouse
rules:
name: bookwarehouse-service-routes
matches:
- restock-books
sources:
name: bookstore
name: bookstore-v2
---
metadata:
name: bookwarehouse-service-routes
spec:
matches:
- name: restock-books
methods:
- POST
headers:
- host: bookwarehouse.bookwarehouse
EOF
Debería ver una salida similar a la siguiente.
traffictarget.access.smi-spec.io/bookbuyer-access-bookstore-v1 created
httproutegroup.specs.smi-spec.io/bookstore-service-routes created
traffictarget.access.smi-spec.io/bookstore-access-bookwarehouse created
httproutegroup.specs.smi-spec.io/bookwarehouse-service-routes created
Ahora puede configurar una sesión de reenvío de puertos en los pods de bookbuyer o bookstore y ver que las
métricas de libros comprados y libros vendidos vuelven a incrementarse. También puede hacer lo mismo con el
pod de bookthief para comprobar que aún no puede robar libros.
Aplicación de directivas de división de tráfico de Service Mesh Interface (SMI )
Para nuestra demostración final, crearemos una directiva de división de tráfico de SMI para configurar la
ponderación de las comunicaciones de un servicio a varios servicios como back-end. La función de división del
tráfico permite desplazar progresivamente las conexiones de un servicio a otro ponderando el tráfico en una
escala de 0 a 100.
El gráfico siguiente es un diagrama de la directiva de división del tráfico de SMI que se va a implementar.
Implementaremos una versión 2 adicional de bookstore y, a continuación, dividiremos el tráfico entrante de
bookbuyer, ponderando el 25 % del tráfico al servicio bookstore v1 y el 75 % al servicio bookstore v2.
Implemente el servicio bookstore V2.

---
apiVersion: v1
kind: Service
metadata:
name: bookstore-v2
labels:
app: bookstore-v2
spec:
ports:
- port: 14001
name: bookstore-port
selector:
app: bookstore-v2
---
# Deploy bookstore-v2 Service Account
apiVersion: v1
metadata:
name: bookstore-v2
---
# Deploy bookstore-v2 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: bookstore-v2
spec:
replicas: 1
selector:
matchLabels:
app: bookstore-v2
template:
metadata:
labels:
app: bookstore-v2
spec:
serviceAccountName: bookstore-v2
containers:
- name: bookstore
image: openservicemesh/bookstore:v0.8.0
ports:
name: web
command: ["/bookstore"]
args: ["--path", "./", "--port", "14001"]
env:
- name: BOOKWAREHOUSE_NAMESPACE
value: bookwarehouse
- name: IDENTITY
value: bookstore-v2
---
kind: TrafficTarget
metadata:
name: bookbuyer-access-bookstore-v2
spec:
destination:
name: bookstore-v2
rules:
matches:
- buy-a-book
- books-bought
sources:
name: bookbuyer
EOF
Debería ver la siguiente salida.
service/bookstore-v2 configured
serviceaccount/bookstore-v2 created
deployment.apps/bookstore-v2 created
traffictarget.access.smi-spec.io/bookstore-v2 created
Ahora implemente la directiva de división del tráfico para dividir el tráfico de bookbuyer entre los dos servicios
bookstore v1 y v2.

apiVersion: split.smi-spec.io/v1alpha2
kind: TrafficSplit
metadata:
name: bookstore-split
spec:
service: bookstore.bookstore
backends:
- service: bookstore
weight: 25
- service: bookstore-v2
weight: 75
EOF
trafficsplit.split.smi-spec.io/bookstore-split created
Configure un túnel de reenvío de puertos al pod de bookbuyer, y ahora debería ver los libros que se compran en
el servicio bookstore v2. Si sigue observando el incremento de las compras, debería notar un incremento más
rápido de las compras que se realizan a través del servicio bookstore v2.
Administración de aplicaciones implementadas existentes para que

las administre el complemento Open Service Mesh (OSM) de Azure
Antes de empezar
En los pasos que se detallan en este tutorial se supone que ya ha habilitado el complemento OSM de AKS para
el clúster de AKS. Si no es así, revise la sección Habilitación del complemento Open Service Mesh (OSM) de
Azure Kubernetes Service (AKS) para un clúster de AKS existente antes de continuar. Además, el clúster de AKS
debe ser de la versión Kubernetes 1.19+ o posterior, tener habilitado RBAC de Kubernetes y haber establecido
una conexión kubectl con el clúster (si necesita ayuda con cualquiera de estos elementos, consulte el inicio
rápido de AKS), además de haber instalado el complemento OSM de AKS.
apt-get install jq
Comprobación de la directiva de modo de tráfico permisivo de Open Service Mesh (OSM )
El modo de la directiva de tráfico permisivo de OSM es un modo en el que se omite la aplicación de directivas
de tráfico de SMI. En este modo, OSM detecta automáticamente los servicios que forman parte de la malla de
servicio y programa reglas de la directiva de tráfico en cada sidecar del proxy de Envoy para comunicarse con
estos servicios.
Para comprobar el modo de tráfico permisivo actual de OSM para el clúster, ejecute el siguiente comando:
La salida del configmap de OSM debe ser similar a la siguiente:

{
"egress": "true",
}
Si permissive_traffic_policy_mode está configurado en true , puede incorporar los espacios de nombres de

forma segura sin que se produzca ninguna interrupción en las comunicaciones entre servicios. Si
permissive_traffic_policy_mode está configurado en false , deberá asegurarse de que tiene los manifiestos
de directiva de acceso de tráfico de SMI correctos y de que tiene una cuenta de servicio que representa cada
servicio implementado en el espacio de nombres. Siga las instrucciones de Incorporación de aplicaciones
implementadas existentes con la directiva de tráfico permisivo de Open Service Mesh (OSM) configurada como
False.
Incorporación de aplicaciones implementadas existentes con la directiva de tráfico permisivo de Open
Service Mesh (OSM ) configurada como True
Lo primero que haremos es agregar los espacios de nombres de la aplicación implementada a OSM para
administrarlos.
osm namespace add bookstore
A continuación, echaremos un vistazo a la implementación del pod actual en el espacio de nombres. Ejecute el
siguiente comando para ver los pods en el espacio de nombres designado.
Debería ver una salida similar a la siguiente:

bookbuyer-78666dcff8-wh6wl 1/1 Running 0 43s
Observe que la columna READY muestra 1/1 , lo que significa que la aplicación del pod solo tiene un
contenedor. A continuación, será necesario reiniciar las implementaciones de la aplicación para que OSM pueda
insertar el contenedor del proxy sidecar de Envoy con el pod de la aplicación. Vamos a obtener una lista de las
implementaciones del espacio de nombres.
kubectl get deployment -n bookbuyer

bookbuyer 1/1 1 1 23h
Ahora se reiniciará la implementación para insertar el contenedor sidecar del proxy de Envoy con el pod de la
aplicación. Ejecute el siguiente comando:
kubectl rollout restart deployment bookbuyer -n bookbuyer
deployment.apps/bookbuyer restarted
Si echamos un vistazo a los pods en el espacio de nombres de nuevo:
Ahora observará que la columna READY muestra 2/2 contenedores listos para su pod. El segundo contenedor
es el proxy de sidecar de Envoy.

bookbuyer-84446dd5bd-j4tlr 2/2 Running 0 3m30s
Podemos inspeccionar más el pod para ver el proxy de Envoy mediante la ejecución del comando de descripción
para ver la configuración.
kubectl describe pod bookbuyer-84446dd5bd-j4tlr -n bookbuyer
Containers:
bookbuyer:
Container ID: containerd://b7503b866f915711002292ea53970bd994e788e33fb718f1c4f8f12cd4a88198
Image: openservicemesh/bookbuyer:v0.8.0
Image ID:
docker.io/openservicemesh/bookbuyer@sha256:813874bd2dc9c5a259b9657995348cf0822b905e29c4e86f21fdefa0ef21dcee
Port: <none>
Host Port: <none>
Command:
/bookbuyer
State: Running
Started: Tue, 23 Mar 2021 10:52:53 -0400
Ready: True
Restart Count: 0
Environment:
BOOKSTORE_NAMESPACE: bookstore
BOOKSTORE_SVC: bookstore
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from bookbuyer-token-zft2r (ro)
envoy:
Container ID: containerd://f5f1cb5db8d5304e23cc984eb08146ea162a3e82d4262c4472c28d5579c25e10
Image: envoyproxy/envoy-alpine:v1.17.1
Image ID: docker.io/envoyproxy/envoy-
alpine@sha256:511e76b9b73fccd98af2fbfb75c34833343d1999469229fdfb191abd2bbe3dfb
Ports: 15000/TCP, 15003/TCP, 15010/TCP
Host Ports: 0/TCP, 0/TCP, 0/TCP
Compruebe que la aplicación sigue siendo funcional después de la inserción del proxy de sidecar de Envoy.
Incorporación de aplicaciones implementadas existentes con la directiva de tráfico permisivo de Open
Service Mesh (OSM ) configurada como False
Cuando la configuración de OSM para la directiva de tráfico permisivo está establecida en false , OSM
requerirá directivas de acceso de tráfico de SMI explícitas implementadas para que la comunicación entre
servicios se produzca en el clúster. Actualmente, OSM también usa cuentas de servicio de Kubernetes como
parte de la autorización de comunicaciones entre servicios. Para asegurarse de que las aplicaciones
implementadas existentes se comunicarán cuando se administren mediante la malla de OSM, será necesario
comprobar la existencia de una cuenta de servicio para usarla, actualizar la implementación de la aplicación con
la información de la cuenta de servicio y aplicar las directivas de acceso de tráfico de SMI.
Comprobación de cuentas de servicio de Kubernetes
Compruebe si tiene una cuenta de servicio de Kubernetes en el espacio de nombres en el que está
implementada la aplicación.
kubectl get serviceaccounts -n bookbuyer
En el siguiente, hay una cuenta de servicio denominada bookbuyer en el espacio de nombres de bookbuyer.
NAME SECRETS AGE

bookbuyer 1 25h
default 1 25h
Si no tiene una cuenta de servicio que no sea la cuenta predeterminada, deberá crear una para la aplicación. Use
el comando siguiente como ejemplo para crear una cuenta de servicio en el espacio de nombres implementado
de la aplicación.
kubectl create serviceaccount myserviceaccount -n bookbuyer
serviceaccount/myserviceaccount created
Ver la especificación de la implementación actual de la aplicación

Si tuviera que crear una cuenta de servicio desde la sección anterior, lo más probable es que la implementación
de la aplicación no esté configurada con un valor serviceAccountName específico en las especificaciones de
implementación. Podemos ver la especificación de la implementación de la aplicación con los siguientes
comandos:
kubectl get deployment -n bookbuyer
En la salida se mostrará una lista de las implementaciones.

bookbuyer 1/1 1 1 25h
Ahora describiremos la implementación como una comprobación para ver si hay una cuenta de servicio
enumerada en la sección de plantilla de pod.
kubectl describe deployment bookbuyer -n bookbuyer
En esta implementación en particular, puede ver que hay una cuenta de servicio asociada a la implementación
enumerada en la sección de plantilla de pod. Esta implementación usa la cuenta de servicio bookbuyer. Si no ve
la propiedad Ser vice Account: , la implementación no está configurada para usar una cuenta de servicio.
Pod Template:
Labels: app=bookbuyer
version=v1
Annotations: kubectl.kubernetes.io/restartedAt: 2021-03-23T10:52:49-04:00
Service Account: bookbuyer
Containers:
bookbuyer:
Image: openservicemesh/bookbuyer:v0.8.0
Hay varias técnicas para actualizar la implementación con el fin de agregar una cuenta de servicio de
kubernetes. Revise la documentación de Kubernetes sobre cómo actualizar una implementación insertada o
configurar cuentas de servicio para pods. Una vez que haya actualizado las especificaciones de implementación
con la cuenta de servicio, vuelva a implementar (kubectl apply -f your-deployment.yaml) su implementación en
el clúster.
Implementación de las directivas de Service Mesh Interface (SMI) necesarias
El último paso para permitir que el tráfico autorizado fluya en la malla es implementar las directivas de acceso
de tráfico de SMI necesarias para la aplicación. La cantidad de configuración que se puede lograr con las
directivas de acceso de tráfico de SMI queda fuera del ámbito de este tutorial, pero se detallan algunos de los
componentes comunes de la especificación y se muestra cómo configurar una directiva sencilla de TrafficTarget
y HTTPRouteGroup para habilitar la comunicación entre servicios para la aplicación.
La especificación SMI Traffic Access Control permite a los usuarios definir la directiva de control de acceso
para sus aplicaciones. Nos centraremos en los recursos de API de TrafficTarget y HTTPRoutGroup .
El recurso TrafficTarget consta de tres valores de configuración principales: destino, reglas y orígenes. A
continuación, se muestra un ejemplo de TrafficTarget.
kind: TrafficTarget
metadata:
spec:
destination:
name: bookstore
rules:
matches:
- buy-a-book
- books-bought
sources:
name: bookbuyer
En la especificación de TrafficTarget anterior, destination denota la cuenta de servicio que está configurada para
el servicio de origen de destino. Recuerde que la cuenta de servicio que se agregó a la implementación anterior
se usará para autorizar el acceso a la implementación a la que está asociada. La sección rules , en este ejemplo
concreto, define el tipo de tráfico HTTP que se permite a través de la conexión. Puede configurar patrones regex
precisos para que los encabezados HTTP sean específicos respecto al tráfico que se permite a través de HTTP. La
sección sources es el servicio que origina las comunicaciones. Esta especificación lee que el elemento
bookbuyer necesita comunicarse con bookstore.
El recurso HTTPRouteGroup se compone de una coincidencia o una matriz de ellas de la información del
encabezado HTTP y es un requisito de la especificación TrafficTarget. En el ejemplo siguiente, puede ver que
HTTPRouteGroup está autorizando tres acciones HTTP, dos GET y una POST.
metadata:
spec:
matches:
methods:
- GET
headers:
- name: buy-a-book
methods:
- GET
methods:
- POST
Si no está familiarizado con el tipo de tráfico HTTP que la aplicación de front-end realiza a otros niveles de la
aplicación, ya que la especificación de TrafficTarget requiere una regla, puede crear el equivalente de una regla
de permitir todo con la siguiente especificación para HTTPRouteGroup.
metadata:
name: allow-all
namespace: yournamespace
spec:
matches:
- name: allow-all
pathRegex: '.*'
methods: ["GET","PUT","POST","DELETE","PATCH"]
Una vez configurada la especificación de TrafficTarget y HTTPRouteGroup, puede combinarla como un YAML e
implementarlo. A continuación se muestra la configuración del ejemplo de bookstore.
---
kind: TrafficTarget
metadata:
spec:
destination:
name: bookstore
rules:
matches:
- buy-a-book
- books-bought
sources:
name: bookbuyer
---
metadata:
spec:
matches:
methods:
- GET
headers:
- name: buy-a-book
methods:
- GET
methods:
- POST
EOF
Visite el sitio de SMI para obtener información más detallada sobre la especificación.
Administración del espacio de nombres de la aplicación con OSM
A continuación, configuraremos OSM para administrar el espacio de nombres y reiniciaremos las
implementaciones para obtener el proxy de sidecar de Envoy insertado con la aplicación.
Ejecute el siguiente comando para configurar el espacio de nombres azure-vote que se va a administrar en mi
OSM.
osm namespace add azure-vote
Namespace [azure-vote] successfully added to mesh [osm]
A continuación, reinicie las implementaciones azure-vote-front y azure-vote-back con los siguientes

comandos.
kubectl rollout restart deployment azure-vote-front -n azure-vote

kubectl rollout restart deployment azure-vote-back -n azure-vote
deployment.apps/azure-vote-front restarted
deployment.apps/azure-vote-back restarted
Si vemos los pods del espacio de nombres azure-vote , veremos la fase READY de azure-vote-front y
azure-vote-back como 2/2, lo que significa que se ha insertado el proxy de sidecar de Envoy junto a la
aplicación.
Tutorial: Implementación de una aplicación administrada por Open

Service Mesh (OSM) con entrada de NGINX
En este tutorial va a:
Ver la configuración actual del clúster de OSM
Crear los espacios de nombres de OSM para administrar las aplicaciones implementadas en los espacios de
nombres
Incorporar los espacios de nombres que se van a administrar mediante OSM
Implementación de la aplicación de ejemplo
Comprobar que la aplicación se ejecuta en el clúster de AKS
Crear un controlador de entrada de NGINX usado para aplicación
Exponer un servicio a través de la entrada de Azure Application Gateway a Internet
Antes de empezar
En los pasos que se detallan en este artículo se supone que ha creado un clúster de AKS (Kubernetes 1.19+ y
clúster (si necesita ayuda con cualquiera de estos elementos, consulte el inicio rápido de AKS) y ha instalado el
apt-get install jq
Visualización y comprobación de la configuración actual del clúster de OSM
Una vez que el complemento OSM para AKS se ha habilitado en el clúster de AKS, puede ver los parámetros de
configuración actuales en el archivo ConfigMap osm-config de Kubernetes. Ejecute el siguiente comando para
ver las propiedades de ConfigMap:
La salida muestra la configuración actual de OSM para el clúster.

{
"egress": "true",
"outbound_ip_range_exclusion_list": "169.254.169.254,168.63.129.16,20.193.57.43",
"permissive_traffic_policy_mode": "false",
}

En este tutorial, vamos a usar la aplicación bookstore de OSM que tiene los siguientes componentes:
bookbuyer
bookthief
bookstore
bookwarehouse






Actualización del servicio bookbuyer

Actualice el servicio bookbuyer a la configuración de puerto de entrada correcta con el siguiente manifiesto de
servicio.

apiVersion: v1
kind: Service
metadata:
name: bookbuyer
labels:
app: bookbuyer
spec:
ports:
- port: 14001
name: inbound-port
selector:
app: bookbuyer
EOF

desde el clúster de AKS. Más adelante se agregará el controlador de entrada de Azure Application Gateway para
exponer la aplicación fuera del clúster de AKS. Para comprobar que la aplicación se ejecuta dentro del clúster,
utilizaremos un reenvío de puertos para ver la interfaz de usuario del componente bookbuyer.

bookbuyer especificado.
Forwarding from 127.0.0.1:8080 -> 14001

Creación de un controlador de entrada de NGINX en Azure Kubernetes Service (AKS )

Usaremos el controlador de entrada para exponer la aplicación administrada por OSM a Internet. Para crear el
controlador de entrada, use Helm para instalar nginx-ingress. Para obtener redundancia adicional, se
implementan dos réplicas de los controladores de entrada NGINX con el parámetro
TIP


# Update the helm repo(s)

helm repo update
# Use Helm to deploy an NGINX ingress controller in the ingress-basic namespace

asigna la dirección IP pública dinámica, como se muestra en la salida del ejemplo siguiente:

AGE SELECTOR
Exposición del servicio bookbuyer a Internet
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: bookbuyer-ingress
annotations:
spec:
rules:
- host: bookbuyer.contoso.com
http:
paths:
- path: /
backend:
serviceName: bookbuyer
servicePort: 14001
backend:
servicePort: 14001
EOF
Warning: extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1

Ingress
ingress.extensions/bookbuyer-ingress created
Visualización de los registros de NGINX
POD=$(kubectl get pods -n ingress-basic | grep 'nginx-ingress' | awk '{print $1}')
kubectl logs $POD -n ingress-basic -f
La salida muestra el estado del controlador de entrada de NGINX cuando se ha aplicado correctamente la regla
de entrada:
I0321 <date> 6 event.go:282] Event(v1.ObjectReference{Kind:"Pod", Namespace:"ingress-basic",

Name:"nginx-ingress-ingress-nginx-controller-54cf6c8bf4-jdvrw", UID:"3ebbe5e5-50ef-481d-954d-4b82a499ebe1",
APIVersion:"v1", ResourceVersion:"3272", FieldPath:""}): type: 'Normal' reason: 'RELOAD' NGINX reload
triggered due to a change in configuration
I0321 <date> 6 event.go:282] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"bookbuyer",
Name:"bookbuyer-ingress", UID:"e1018efc-8116-493c-9999-294b4566819e",
APIVersion:"networking.k8s.io/v1beta1", ResourceVersion:"5460", FieldPath:""}): type: 'Normal' reason:
'Sync' Scheduled for sync
I0321 <date> 6 controller.go:146] "Configuration changes detected, backend reload required"
I0321 <date> 6 controller.go:163] "Backend successfully reloaded"
I0321 <date> 6 event.go:282] Event(v1.ObjectReference{Kind:"Pod", Namespace:"ingress-basic",
Name:"nginx-ingress-ingress-nginx-controller-54cf6c8bf4-jdvrw", UID:"3ebbe5e5-50ef-481d-954d-4b82a499ebe1",
APIVersion:"v1", ResourceVersion:"3272", FieldPath:""}): type: 'Normal' reason: 'RELOAD' NGINX reload
triggered due to a change in configuration
Visualización de los servicios de NGINX y el servicio bookbuyer externamente
kubectl get services -n ingress-basic

AGE
nginx-ingress-ingress-nginx-controller LoadBalancer 10.0.100.23 20.193.1.74
80:31742/TCP,443:32683/TCP 4m15s
nginx-ingress-ingress-nginx-controller-admission ClusterIP 10.0.163.98 <none> 443/TCP
4m15s
Dado que el nombre de host en el manifiesto de entrada es un pseudonombre que se usa para las pruebas, el
nombre DNS no estará disponible en Internet. También podemos usar el programa de curl y después el
encabezado de nombre de host para la dirección IP pública de NGINX y recibir un código 200 que nos conecta
correctamente con el servicio bookbuyer.
curl -H 'Host: bookbuyer.contoso.com' http://EXTERNAL-IP/

<!doctype html>
<html itemscope="" itemtype="http://schema.org/WebPage" lang="en">
<head>
<meta content="Bookbuyer" name="description">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title>Bookbuyer</title>
<style>
#navbar {
width: 100%;
height: 50px;
display: table;
border-spacing: 0;
white-space: nowrap;
line-height: normal;
background-color: #0078D4;
background-position: left top;
background-repeat-x: repeat;
background-image: none;
color: white;
font: 2.2em "Fira Sans", sans-serif;
}
#main {
padding: 10pt 10pt 10pt 10pt;
}
li {
font: 1.2em "Consolas", sans-serif;
}
</style>
<script>
setTimeout(function(){window.location.reload(1);}, 1500);
</script>
</head>
<body bgcolor="#fff">
<div id="navbar">
📖 Bookbuyer
</div>
<div id="main">
<ul>
<li>Total books bought: <strong>1833</strong>
<ul>
<li>from bookstore V1: <strong>277</strong>
</ul>
</li>
</ul>
</div>
<br/><br/><br/><br/>
Current Time: <strong>Fri, 26 Mar 2021 15:02:53 UTC</strong>

</body>
</html>
Tutorial: Implementación de una aplicación administrada por Open

Service Mesh (OSM) mediante el complemento de AKS de entrada de
Azure Application Gateway
Ver la configuración actual del clúster de OSM
Crear los espacios de nombres de OSM para administrar las aplicaciones implementadas en los espacios de
nombres
Incorporar los espacios de nombres que se van a administrar mediante OSM
Implementación de la aplicación de ejemplo
Comprobar que la aplicación se ejecuta en el clúster de AKS
Crear una instancia de Azure Application Gateway que se usará como controlador de entrada para la
aplicación
Exponer un servicio a través de la entrada de Azure Application Gateway a Internet
Antes de empezar
En los pasos que se detallan en este artículo se supone que ha creado un clúster de AKS (Kubernetes 1.19+ y
clúster (si necesita ayuda con cualquiera de estos elementos, consulte el inicio rápido de AKS), ha instalado el
complemento OSM de AKS y va a crear una nueva instancia de Azure Application Gateway para la entrada.
Clúster de AKS, versión 1.19, que use redes de Azure CNI (conectadas a una red virtual de Azure)
apt-get install jq
Visualización y comprobación de la configuración actual del clúster de OSM
Una vez que el complemento OSM para AKS se ha habilitado en el clúster de AKS, puede ver los parámetros de
configuración actuales en el archivo ConfigMap osm-config de Kubernetes. Ejecute el siguiente comando para
ver las propiedades de ConfigMap:
La salida muestra la configuración actual de OSM para el clúster.
{
"egress": "true",
"permissive_traffic_policy_mode": "false",
}

En este tutorial, vamos a usar la aplicación bookstore de OSM que tiene los siguientes componentes:
bookbuyer
bookthief
bookstore
bookwarehouse







Actualización del servicio bookbuyer

Actualice el servicio bookbuyer a la configuración de puerto de entrada correcta con el siguiente manifiesto de
servicio.

apiVersion: v1
kind: Service
metadata:
name: bookbuyer
labels:
app: bookbuyer
spec:
ports:
- port: 14001
name: inbound-port
selector:
app: bookbuyer
EOF

desde el clúster de AKS. Más adelante se agregará el controlador de entrada de Azure Application Gateway para
exponer la aplicación fuera del clúster de AKS. Para comprobar que la aplicación se ejecuta dentro del clúster,
utilizaremos un reenvío de puertos para ver la interfaz de usuario del componente bookbuyer.

bookbuyer específico.
Forwarding from 127.0.0.1:8080 -> 14001

Creación de una instancia de Azure Application Gateway para exponer la aplicación bookbuyer fuera del
clúster de AKS
NOTE
Las instrucciones siguientes crearán una nueva instancia de Azure Application Gateway que se usará para la entrada. Si ya
tiene una instancia de Azure Application Gateway que desea usar, vaya a la sección para habilitar el complemento del
controlador de entrada de Application Gateway.
Implementación de una nueva instancia de Application Gateway
NOTE
Nos estamos refiriendo a la documentación existente para habilitar el complemento de Controlador de entrada de
Application Gateway para un clúster de AKS existente. Se han realizado algunas modificaciones para adaptarse a los
materiales de OSM. Aquíencontrará documentación más detallada sobre el tema.
Ahora implementará una nueva instancia de Application Gateway para simular una instancia de Application
Gateway existente que quiera usar para equilibrar la carga del tráfico en el clúster de AKS, myCluster. El nombre
de la instancia de Application Gateway será myApplicationGateway, pero tendrá que crear primero un recurso
de dirección IP pública, denominado myPublicIp, y una nueva red virtual denominada myVnet con el espacio de
direcciones 11.0.0.0/8 y una subred con el espacio de direcciones 11.1.0.0/16 llamada mySubnet e implementar
la instancia de Application Gateway en mySubnet con myPublicIp.
Cuando se usa un clúster de AKS y una instancia de Application Gateway en redes virtuales independientes, los
espacios de direcciones de las dos redes virtuales no deben superponerse. El espacio de direcciones
predeterminado que implementa un clúster de AKS es 10.0.0.0/8, por lo que establecemos el prefijo de dirección
de red virtual de la instancia de Application Gateway en 11.0.0.0/8.
az group create --name myResourceGroup --location eastus2

az network public-ip create -n myPublicIp -g MyResourceGroup --allocation-method Static --sku Standard
az network vnet create -n myVnet -g myResourceGroup --address-prefix 11.0.0.0/8 --subnet-name mySubnet --
subnet-prefix 11.1.0.0/16
az network application-gateway create -n myApplicationGateway -l eastus2 -g myResourceGroup --sku
Standard_v2 --public-ip-address myPublicIp --vnet-name myVnet --subnet mySubnet
NOTE
El complemento del controlador de entrada de Application Gateway (AGIC) admite solo las SKU de Application Gateway
v2 (estándar y WAF) y no las SKU de Application Gateway v1.
Habilitación del complemento AGIC para un clúster de AKS existente a través de la CLI de Azure
Si quiere seguir usando la CLI de Azure, puede seguir habilitando el complemento AGIC en el clúster de AKS que
creó, myCluster, y especificar el complemento AGIC para usar la instancia de Application Gateway existente que
creó, myApplicationGateway.
appgwId=$(az network application-gateway show -n myApplicationGateway -g myResourceGroup -o tsv --query

"id")
az aks enable-addons -n myCluster -g myResourceGroup -a ingress-appgw --appgw-id $appgwId
Puede comprobar que el complemento de AKS de Azure Application Gateway se ha habilitado mediante el
siguiente comando.
az aks list -g osm-aks-rg -o json | jq -r .[].addonProfiles.ingressApplicationGateway.enabled
Este comando debería mostrar la salida como true .

Emparejamiento de dos redes virtuales juntas
Dado que hemos implementado el clúster de AKS en su propia red virtual y la instancia de Application Gateway
en otra red virtual, deberá emparejar las dos redes virtuales juntas para que el tráfico fluya de la instancia de
Application Gateway a los pods del clúster. Emparejar las dos redes virtuales requiere ejecutar el comando de la
CLI de Azure dos veces independientes para asegurarse de que la conexión sea bidireccional. El primer comando
creará una conexión de emparejamiento desde la red virtual de Application Gateway a la red virtual de AKS; el
segundo comando creará una conexión de emparejamiento en la otra dirección.
nodeResourceGroup=$(az aks show -n myCluster -g myResourceGroup -o tsv --query "nodeResourceGroup")

aksVnetName=$(az network vnet list -g $nodeResourceGroup -o tsv --query "[0].name")
aksVnetId=$(az network vnet show -n $aksVnetName -g $nodeResourceGroup -o tsv --query "id")

az network vnet peering create -n AppGWtoAKSVnetPeering -g myResourceGroup --vnet-name myVnet --remote-vnet
$aksVnetId --allow-vnet-access
appGWVnetId=$(az network vnet show -n myVnet -g myResourceGroup -o tsv --query "id")

az network vnet peering create -n AKStoAppGWVnetPeering -g $nodeResourceGroup --vnet-name $aksVnetName --
remote-vnet $appGWVnetId --allow-vnet-access
Exposición del servicio bookbuyer a Internet

Aplique el siguiente manifiesto de entrada al clúster de AKS para exponer el servicio bookbuyer a Internet a
través de Azure Application Gateway.
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: bookbuyer-ingress
annotations:
kubernetes.io/ingress.class: azure/application-gateway
spec:
rules:
- host: bookbuyer.contoso.com
http:
paths:
- path: /
backend:
servicePort: 14001
backend:
servicePort: 14001
EOF
Warning: extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1

Ingress
ingress.extensions/bookbuyer-ingress created
Dado que el nombre de host en el manifiesto de entrada es un pseudonombre que se usa para las pruebas, el
nombre DNS no estará disponible en Internet. También podemos usar el programa de curl y después el
encabezado de nombre de host para la dirección IP pública de Azure Application Gateway y recibir un
código 200 que nos conecta correctamente con el servicio bookbuyer.
appGWPIP=$(az network public-ip show -g MyResourceGroup -n myPublicIp -o tsv --query "ipAddress")

curl -H 'Host: bookbuyer.contoso.com' http://$appGWPIP/

<!doctype html>
<html itemscope="" itemtype="http://schema.org/WebPage" lang="en">
<head>
<meta content="Bookbuyer" name="description">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title>Bookbuyer</title>
<style>
#navbar {
width: 100%;
height: 50px;
display: table;
border-spacing: 0;
white-space: nowrap;
line-height: normal;
background-color: #0078D4;
background-position: left top;
background-repeat-x: repeat;
background-image: none;
color: white;
}
#main {
}
li {
font: 1.2em "Consolas", sans-serif;
}
</style>
<script>
setTimeout(function(){window.location.reload(1);}, 1500);
</script>
</head>
<body bgcolor="#fff">
<div id="navbar">
📖 Bookbuyer
</div>
<div id="main">
<ul>
<li>Total books bought: <strong>5969</strong>
<ul>
</ul>
</li>
</ul>
</div>
Current Time: <strong>Fri, 26 Mar 2021 16:34:30 UTC</strong>

</body>
</html>
Documentación de solución de problemas de AGIC
Hay otras herramientas de solución de problemas disponibles en el repositorio de GitHub de AGIC.
Supervisión y observabilidad de Open Service Mesh (OSM) mediante

Azure Monitor y Application Insights
Azure Monitor y Azure Application Insights ayudan a maximizar la disponibilidad y el rendimiento de las
aplicaciones y los servicios con una completa solución que permite recopilar datos de telemetría tanto en la
nube como en entornos locales, así como analizarlos y actuar sobre ellos.
El complemento OSM de AKS tendrá integraciones profundas en ambos servicios de Azure y proporcionará una
experiencia de Azure aparentemente ininterrumpida para ver los KPI críticos proporcionados por las métricas de
OSM y responder a ellos. Para obtener más información sobre cómo habilitar y configurar estos servicios para
el complemento OSM de AKS, visite la página Azure Monitor para OSM para obtener más información.
Tutorial: Implementación manual de Prometheus, Grafana y Jaeger

para ver las métricas de Open Service Mesh (OSM) con fines de
observabilidad
WARNING
La instalación de Prometheus, Grafana y Jaeger se proporciona como guía general para mostrar cómo se pueden usar
estas herramientas para ver los datos de métricas de OSM. La guía de instalación no se utiliza para una configuración de
producción. Consulte la documentación de cada herramienta sobre la mejor manera de adaptarse a sus necesidades de
instalación. Lo más notable es la falta de almacenamiento persistente, lo que significa que todos los datos se pierden una
vez que se cierra un pod de Prometheus Grafana o Jaeger.
Open Service Mesh (OSM) genera métricas detalladas relacionadas con todo el tráfico dentro de la malla. Estas
métricas proporcionan información sobre el comportamiento de las aplicaciones de la malla, ayudando a los
usuarios a solucionar, mantener y analizar sus aplicaciones.
Hoy, OSM recopila las métricas directamente de los servidores proxy de sidecar (Envoy). OSM proporciona
métricas enriquecidas para el tráfico entrante y saliente de todos los servicios de la malla. Con estas métricas, el
usuario puede obtener información sobre el volumen total de tráfico, los errores dentro del tráfico y el tiempo
de respuesta de las solicitudes.
OSM usa Prometheus para recopilar y almacenar estadísticas y métricas de tráfico coherentes para todas las
aplicaciones que se ejecutan en la malla. Prometheus es un kit de herramientas de supervisión y alertas de
código abierto, que se usa normalmente en entornos de Kubernetes y de malla de servicio (pero no
exclusivamente).
Cada aplicación que forma parte de la malla se ejecuta en un pod que contiene un sidecar de Envoy que expone
las métricas (métricas de proxy) en el formato de Prometheus. Además, cada pod que forma parte de la malla
tiene anotaciones de Prometheus, lo que permite que el servidor de Prometheus desbloquee la aplicación de
forma dinámica. Este mecanismo habilita automáticamente la extracción de métricas cada vez que se agrega un
nuevo espacio de nombres/pod/servicio a la malla.
Las métricas de OSM se pueden ver con Grafana, que es un software de análisis y visualización de código
abierto. Permite consultar, visualizar, enviar alertas y explorar las métricas.
Crear e implementar una instancia de Prometheus
Configurar OSM para permitir la extracción de Prometheus
Actualizar el archivo Configmap de Prometheus
Crear e implementar una instancia de Grafana
Configurar Grafana con el origen de datos de Prometheus
Importar el panel de OSM para Grafana
Crear e implementar una instancia de Jaeger
Configurar el seguimiento de Jaeger para OSM
Implementación y configuración de una instancia de Prometheus para OSM
Usaremos Helm para implementar la instancia de Prometheus. Ejecute los siguientes comandos para instalar
Prometheus a través de Helm:
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

helm repo update
helm install stable prometheus-community/prometheus
Debería ver una salida similar a la siguiente si la instalación se realizó correctamente. Anote el puerto del
servidor de Prometheus y el nombre DNS del clúster. Esta información se usará más adelante para configurar
Prometheus como un origen de datos para Grafana.
NAME: stable
LAST DEPLOYED: Fri Mar 26 13:34:51 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The Prometheus server can be accessed via port 80 on the following DNS name from within your cluster:
stable-prometheus-server.default.svc.cluster.local
Get the Prometheus server URL by running these commands in the same shell:
export POD_NAME=$(kubectl get pods --namespace default -l "app=prometheus,component=server" -o jsonpath="
{.items[0].metadata.name}")
kubectl --namespace default port-forward $POD_NAME 9090
The Prometheus alertmanager can be accessed via port 80 on the following DNS name from within your cluster:
stable-prometheus-alertmanager.default.svc.cluster.local
Get the Alertmanager URL by running these commands in the same shell:
export POD_NAME=$(kubectl get pods --namespace default -l "app=prometheus,component=alertmanager" -o
jsonpath="{.items[0].metadata.name}")
#################################################################################
###### WARNING: Pod Security Policy has been moved to a global property. #####
###### use .Values.podSecurityPolicy.enabled with pod-based #####
###### annotations #####
###### (e.g. .Values.nodeExporter.podSecurityPolicy.annotations) #####
#################################################################################
The Prometheus PushGateway can be accessed via port 9091 on the following DNS name from within your cluster:
stable-prometheus-pushgateway.default.svc.cluster.local
Get the PushGateway URL by running these commands in the same shell:
export POD_NAME=$(kubectl get pods --namespace default -l "app=prometheus,component=pushgateway" -o
jsonpath="{.items[0].metadata.name}")
For more information on running Prometheus, visit:

https://prometheus.io/
Configuración de OSM para permitir la extracción de Prometheus

Para asegurarse de que los componentes de OSM estén configurados para las extracciones de Prometheus,
queremos comprobar la configuración de prometheus_scraping ubicada en el archivo de configuración de
osm-config. Vea la configuración con el siguiente comando:
kubectl get configmap -n kube-system osm-config -o json | jq '.data.prometheus_scraping'
La salida del comando anterior debe devolver true si OSM está configurado para la extracción de Prometheus.
Si el valor devuelto es false , es necesario actualizar la configuración para que sea true . Ejecute el siguiente
comando para activar la extracción de Prometheus en OMS:

{"prometheus_scraping":"true"}}'
Actualización del archivo Configmap de Prometheus

La instalación predeterminada de Prometheus contendrá dos configmaps de Kubernetes. Puede ver la lista de
configmaps de Prometheus con el siguiente comando.
kubectl get configmap | grep prometheus
stable-prometheus-alertmanager 1 4h34m
stable-prometheus-server 5 4h34m
Tendremos que reemplazar la configuración de prometheus.yml que se encuentra en el configmap stable-

prometheus-ser ver por la siguiente configuración de OSM. Hay varias técnicas de edición de archivos para
realizar esta tarea. Una manera sencilla y segura es exportar el configmap, crear una copia de seguridad y, a
continuación, editarlo con un editor como Visual Studio Code.
NOTE
Si no tiene Visual Studio Code instalado, puede descargarlo e instalarlo aquí.
Vamos a exportar primero el configmap stable-prometheus-ser ver y luego realizar una copia de seguridad.
kubectl get configmap stable-prometheus-server -o yaml > cm-stable-prometheus-server.yml

cp cm-stable-prometheus-server.yml cm-stable-prometheus-server.yml.copy
A continuación, vamos a abrir el archivo con Visual Studio Code para editarlo.
code cm-stable-prometheus-server.yml
Una vez que tenga el configmap abierto en el editor de Visual Studio Code, reemplace el archivo
prometheus.yml por la configuración OSM que aparece a continuación y guarde el archivo.
WARNING
Es muy importante asegurarse de que mantiene la estructura de la sangría del archivo YAML. Cualquier cambio en la
estructura del archivo YAML podría provocar que el configmap no se pudiera volver a aplicar.
prometheus.yml: |
global:
scrape_interval: 10s
scrape_timeout: 10s
evaluation_interval: 1m
scrape_configs:
- job_name: 'kubernetes-apiservers'
kubernetes_sd_configs:
- role: endpoints
scheme: https
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
# TODO need to remove this when the CA and SAN match
insecure_skip_verify: true
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
metric_relabel_configs:
- source_labels: [__name__]
regex: '(apiserver_watch_events_total|apiserver_admission_webhook_rejection_count)'
action: keep
relabel_configs:
- source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name,
__meta_kubernetes_endpoint_port_name]
action: keep
regex: default;kubernetes;https
- job_name: 'kubernetes-nodes'
scheme: https
tls_config:
- role: node
relabel_configs:
- action: labelmap
regex: __meta_kubernetes_node_label_(.+)
- target_label: __address__
replacement: kubernetes.default.svc:443
- source_labels: [__meta_kubernetes_node_name]
regex: (.+)
target_label: __metrics_path__
replacement: /api/v1/nodes/${1}/proxy/metrics
- job_name: 'kubernetes-pods'
- role: pod
regex:
'(envoy_server_live|envoy_cluster_upstream_rq_xx|envoy_cluster_upstream_cx_active|envoy_cluster_upstream_cx_
tx_bytes_total|envoy_cluster_upstream_cx_rx_bytes_total|envoy_cluster_upstream_cx_destroy_remote_with_active
_rq|envoy_cluster_upstream_cx_connect_timeout|envoy_cluster_upstream_cx_destroy_local_with_active_rq|envoy_c
luster_upstream_rq_pending_failure_eject|envoy_cluster_upstream_rq_pending_overflow|envoy_cluster_upstream_r
q_timeout|envoy_cluster_upstream_rq_rx_reset|^osm.*)'
action: keep
relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
action: keep
regex: true
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
action: replace
regex: (.+)
- source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
action: replace
regex: ([^:]+)(?::\d+)?;(\d+)
replacement: $1:$2
target_label: __address__
- source_labels: [__meta_kubernetes_namespace]
action: replace
target_label: source_namespace
- source_labels: [__meta_kubernetes_pod_name]
action: replace
target_label: source_pod_name
- regex: '(__meta_kubernetes_pod_label_app)'
action: labelmap
replacement: source_service
- regex:
'(__meta_kubernetes_pod_label_osm_envoy_uid|__meta_kubernetes_pod_label_pod_template_hash|__meta_kubernetes_
pod_label_version)'
action: drop
# for non-ReplicaSets (DaemonSet, StatefulSet)
# __meta_kubernetes_pod_controller_kind=DaemonSet
# __meta_kubernetes_pod_controller_name=foo
# =>
# workload_kind=DaemonSet
# workload_name=foo
- source_labels: [__meta_kubernetes_pod_controller_kind]
action: replace
target_label: source_workload_kind
- source_labels: [__meta_kubernetes_pod_controller_name]
action: replace
target_label: source_workload_name
# for ReplicaSets
# __meta_kubernetes_pod_controller_kind=ReplicaSet
# __meta_kubernetes_pod_controller_name=foo-bar-123
# =>
# workload_kind=Deployment
# workload_name=foo-bar
# deplyment=foo
- source_labels: [__meta_kubernetes_pod_controller_kind]
action: replace
regex: ^ReplicaSet$
target_label: source_workload_kind
replacement: Deployment
- source_labels:
- __meta_kubernetes_pod_controller_kind
- __meta_kubernetes_pod_controller_name
action: replace
regex: ^ReplicaSet;(.*)-[^-]+$
target_label: source_workload_name
- job_name: 'smi-metrics'
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
action: keep
regex: true
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
action: replace
regex: (.+)
- source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
action: replace
regex: ([^:]+)(?::\d+)?;(\d+)
replacement: $1:$2
regex: 'envoy_.*osm_request_(total|duration_ms_(bucket|count|sum))'
action: keep
action: replace
regex:
envoy_response_code_(\d{3})_source_namespace_.*_source_kind_.*_source_name_.*_source_pod_.*_destination_name
space_.*_destination_kind_.*_destination_name_.*_destination_pod_.*_osm_request_total
target_label: response_code
action: replace
regex:
envoy_response_code_\d{3}_source_namespace_(.*)_source_kind_.*_source_name_.*_source_pod_.*_destination_name
action: replace
regex:
envoy_response_code_\d{3}_source_namespace_.*_source_kind_(.*)_source_name_.*_source_pod_.*_destination_name
target_label: source_kind
action: replace
regex:
envoy_response_code_\d{3}_source_namespace_.*_source_kind_.*_source_name_(.*)_source_pod_.*_destination_name
target_label: source_name
action: replace
regex:
envoy_response_code_\d{3}_source_namespace_.*_source_kind_.*_source_name_.*_source_pod_(.*)_destination_name
target_label: source_pod
action: replace
regex:
envoy_response_code_\d{3}_source_namespace_.*_source_kind_.*_source_name_.*_source_pod_.*_destination_namesp
ace_(.*)_destination_kind_.*_destination_name_.*_destination_pod_.*_osm_request_total
target_label: destination_namespace
action: replace
regex:
ace_.*_destination_kind_(.*)_destination_name_.*_destination_pod_.*_osm_request_total
target_label: destination_kind
action: replace
regex:
ace_.*_destination_kind_.*_destination_name_(.*)_destination_pod_.*_osm_request_total
target_label: destination_name
action: replace
regex:
ace_.*_destination_kind_.*_destination_name_.*_destination_pod_(.*)_osm_request_total
target_label: destination_pod
action: replace
regex: .*(osm_request_total)
target_label: __name__
action: replace
regex:
envoy_source_namespace_(.*)_source_kind_.*_source_name_.*_source_pod_.*_destination_namespace_.*_destination
_kind_.*_destination_name_.*_destination_pod_.*_osm_request_duration_ms_(bucket|sum|count)
action: replace
regex:
envoy_source_namespace_.*_source_kind_(.*)_source_name_.*_source_pod_.*_destination_namespace_.*_destination
target_label: source_kind
action: replace
regex:
regex:
envoy_source_namespace_.*_source_kind_.*_source_name_(.*)_source_pod_.*_destination_namespace_.*_destination
target_label: source_name
action: replace
regex:
envoy_source_namespace_.*_source_kind_.*_source_name_.*_source_pod_(.*)_destination_namespace_.*_destination
target_label: source_pod
action: replace
regex:
envoy_source_namespace_.*_source_kind_.*_source_name_.*_source_pod_.*_destination_namespace_(.*)_destination
target_label: destination_namespace
action: replace
regex:
envoy_source_namespace_.*_source_kind_.*_source_name_.*_source_pod_.*_destination_namespace_.*_destination_k
ind_(.*)_destination_name_.*_destination_pod_.*_osm_request_duration_ms_(bucket|sum|count)
target_label: destination_kind
action: replace
regex:
ind_.*_destination_name_(.*)_destination_pod_.*_osm_request_duration_ms_(bucket|sum|count)
target_label: destination_name
action: replace
regex:
ind_.*_destination_name_.*_destination_pod_(.*)_osm_request_duration_ms_(bucket|sum|count)
target_label: destination_pod
action: replace
regex: .*(osm_request_duration_ms_(bucket|sum|count))
target_label: __name__
- job_name: 'kubernetes-cadvisor'
scheme: https
tls_config:
- role: node
regex: '(container_cpu_usage_seconds_total|container_memory_rss)'
action: keep
relabel_configs:
- action: labelmap
regex: __meta_kubernetes_node_label_(.+)
- target_label: __address__
replacement: kubernetes.default.svc:443
- source_labels: [__meta_kubernetes_node_name]
regex: (.+)
replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor
Aplique el archivo YAML de configmap actualizado con el siguiente comando.
kubectl apply -f cm-stable-prometheus-server.yml

configmap/stable-prometheus-server configured
NOTE
Es posible que reciba un mensaje que indica que falta una anotación kubernetes necesaria. Esto puede pasarse por alto
por ahora.
Comprobación de que Prometheus está configurado para extraer los puntos de conexión de la API y la malla de OSM
Para comprobar que Prometheus está correctamente configurado para extraer los puntos de conexión de la API
y la malla de OSM, haremos un reenvío de puertos al pod de Prometheus y veremos la configuración de
destino. Ejecute los comandos siguientes:
PROM_POD_NAME=$(kubectl get pods -l "app=prometheus,component=server" -o jsonpath="

kubectl --namespace <promNamespace> port-forward $PROM_POD_NAME 9090
Abra un explorador en http://localhost:9090/targets .

Si se desplaza hacia abajo, debería ver que el estado de los puntos de conexión de la métrica de SMI es UP , así
como otras métricas de OSM definidas como se muestra a continuación.
<a name="deploy-and-configure -a-grafana-instance -for-osm">Implementación y configuración de una

instancia de Grafana para OSM
Usaremos Helm para implementar la instancia de Grafana. Ejecute los siguientes comandos para instalar
Grafana a través de Helm:
helm repo add grafana https://grafana.github.io/helm-charts

helm repo update
helm install osm-grafana grafana/grafana
A continuación, recuperaremos la contraseña predeterminada de Grafana para iniciar sesión en el sitio de
Grafana.
kubectl get secret --namespace default osm-grafana -o jsonpath="{.data.admin-password}" | base64 -

-decode ; echo
Anote la contraseña de Grafana.

A continuación, recuperaremos el pod de Grafana para hacer un reenvío de puertos al panel de Grafana para
iniciar sesión.
GRAF_POD_NAME=$(kubectl get pods -l "app.kubernetes.io/name=grafana" -o jsonpath="

kubectl port-forward $GRAF_POD_NAME 3000
Abra un explorador en http://localhost:3000 .

En la pantalla de inicio de sesión que se muestra a continuación, escriba admin como nombre de usuario y use
la contraseña de Grafana capturada anteriormente.
Configuración del origen de datos de Prometheus en Grafana

Una vez que haya iniciado sesión correctamente en Grafana, el siguiente paso es agregar Prometheus como
orígenes de datos para Grafana. Para ello, vaya al icono de configuración en el menú de la izquierda y seleccione
Orígenes de datos, como se muestra a continuación.
Haga clic en el botón Agregar origen de datos y seleccione Prometheus en las bases de datos de serie
temporal.
En la página para configurar el origen de datos de Prometheus , escriba el FQDN del clúster de Kubernetes
para el servicio Prometheus para la configuración de la dirección URL de HTTP. El FQDN predeterminado debe
ser stable-prometheus-server.default.svc.cluster.local . Una vez que haya escrito ese punto de conexión de
servicio Prometheus, desplácese hasta la parte inferior de la página y seleccione Guardar y probar . Debe
recibir una casilla verde que indica que el origen de datos funciona.
Importación de paneles de OSM
Los paneles de OSM están disponibles a través de:
Nuestro repositorio, y son importables como blobs de JSON a través del portal de administración web;
o en línea en Grafana.com.
Para importar un panel, busque el signo + en el menú de la izquierda y seleccione import . Puede importar
directamente el panel por su identificador en Grafana.com . Por ejemplo, el panel OSM Mesh Details usa el
identificador 14145 , puede usar el identificador directamente en el formulario y seleccionar import :
En cuanto seleccione importar, se le llevará automáticamente al panel importado.
Implementación y configuración de un operador de Jaeger en Kubernetes para OSM

Jaeger es un sistema de seguimiento de código abierto que se usa para supervisar sistemas distribuidos y
solucionar sus problemas. Se puede implementar con OSM como una nueva instancia o puede traer su propia
instancia. Las instrucciones siguientes implementan una nueva instancia de Jaeger en el espacio de nombres
jaeger del clúster de AKS.
Implementación de Jaeger en el clúster de AKS

Aplique el siguiente manifiesto para instalar Jaeger:
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: jaeger
namespace: jaeger
labels:
app: jaeger
spec:
replicas: 1
selector:
matchLabels:
app: jaeger
template:
metadata:
labels:
app: jaeger
spec:
containers:
- name: jaeger
image: jaegertracing/all-in-one
args:
- --collector.zipkin.host-port=9411
imagePullPolicy: IfNotPresent
ports:
resources:
limits:
cpu: 500m
memory: 512M
requests:
cpu: 100m
memory: 256M
---
kind: Service
apiVersion: v1
metadata:
name: jaeger
namespace: jaeger
labels:
app: jaeger
spec:
selector:
app: jaeger
ports:
- protocol: TCP
# Service port and target port are the same
port: 9411
type: ClusterIP
EOF
deployment.apps/jaeger created
service/jaeger created
Habilitación del seguimiento para el complemento OSM

A continuación, deberá habilitar el seguimiento para el complemento OSM.
NOTE
Las propiedades de seguimiento no son visibles en el configmap osm-config en este momento. Esto se hará visible en una
nueva versión del complemento OSM de AKS.
Ejecute el comando siguiente para habilitar el seguimiento para el complemento OSM:
kubectl patch configmap osm-config -n kube-system -p '{"data":{"tracing_enable":"true",

"tracing_address":"jaeger.jaeger.svc.cluster.local", "tracing_port":"9411",
"tracing_endpoint":"/api/v2/spans"}}' --type=merge
Visualización de la interfaz de usuario de Jaeger con el reenvío de puertos

La interfaz de usuario de Jaeger se está ejecutando en el puerto 16686. Para ver la interfaz de usuario web,
puede usar el reenvío de puertos de kubectl:
JAEGER_POD=$(kubectl get pods -n jaeger --no-headers --selector app=jaeger | awk 'NR==1{print $1}')
kubectl port-forward -n jaeger $JAEGER_POD 16686:16686
http://localhost:16686/
En el explorador, debería ver un desplegable de servicio, que le permite seleccionar entre las distintas
aplicaciones implementadas por el servicio bookstore de demostración. Seleccione un servicio para ver todos
sus intervalos. Por ejemplo, si selecciona bookbuyer con una retrospectiva de una hora, puede ver sus
interacciones con bookstore-v1 y bookstore-v2 ordenadas por hora.
Seleccione cualquier elemento para verlo con más detalle. Seleccione varios elementos para comparar los
seguimientos. Por ejemplo, puede comparar las interacciones de bookbuyer con bookstore y bookstore-v2 en
un momento determinado en el tiempo.
También puede seleccionar la pestaña de arquitectura del sistema para ver un gráfico de cómo las distintas
aplicaciones han estado interactuando o comunicándose. Esto proporciona una idea de cómo fluye el tráfico
entre las aplicaciones.
Guías de solución de problemas del complemento Open Service
Mesh (OSM) de AKS
Al implementar el complemento OSM de AKS, ocasionalmente puede experimentar algún problema. Las guías
siguientes le ayudarán a solucionar errores y resolver problemas comunes.
Comprobación y solución de problemas de componentes de OSM
Comprobación de la implementación del controlador de OSM
kubectl get deployment -n kube-system --selector app=osm-controller
Un controlador de OSM correcto tendría el siguiente aspecto:

osm-controller 1/1 1 1 59m
Comprobación del pod del controlador de OSM
kubectl get pods -n kube-system --selector app=osm-controller
Un pod de OSM correcto tendría el siguiente aspecto:

osm-controller-b5bd66db-wglzl 0/1 Evicted 0 61m
osm-controller-b5bd66db-wvl9w 1/1 Running 0 31m
A pesar de que un controlador fue expulsado en algún momento, tenemos otro con el estado READY 1/1 y en
ejecución con 0 reinicios. Si el valor de la columna READY es distinto de 1/1, la malla del servicio estaría en un
estado interrumpido. La columna READY con 0/1 indica que el contenedor del plano de control se está
bloqueando: necesitamos obtener registros. Consulte la sección de obtención de registros del controlador de
OSM del centro de soporte técnico de Azure a continuación. Una columna READY con un número mayor que 1
después de / indicaría que hay sidecars instalados. Lo más probable es que el controlador de OSM no funcione
con los sidecars conectados a él.
NOTE
A partir de la versión v0.8.2, el controlador de OSM no está en modo de alta disponibilidad y se ejecutará en una
implementación con un número de réplicas de 1(pod individual). El pod tiene sondeos de estado y el kubelet lo reiniciará
si es necesario.
Comprobación del servicio de controlador de OSM
kubectl get service -n kube-system osm-controller
Un servicio de controlador de OSM correcto tendría el siguiente aspecto:

osm-controller ClusterIP 10.0.31.254 <none> 15128/TCP,9092/TCP 67m
NOTE
CLUSTER-IP sería diferente. Los valores NAME y PORT(S) del servicio deben ser iguales al ejemplo anterior.
Comprobación de los puntos de conexión del controlador de OSM
kubectl get endpoints -n kube-system osm-controller
Un punto de conexión del controlador de OSM correcto tendría un aspecto similar al siguiente:
NAME ENDPOINTS AGE

osm-controller 10.240.1.115:9092,10.240.1.115:15128 69m
Comprobación de la implementación del inyector de OSM
kubectl get pod -n kube-system --selector app=osm-injector
Una implementación correcta del inyector de OSM tendría el siguiente aspecto:

osm-injector-5986c57765-vlsdk 1/1 Running 0 73m
Comprobación del pod del inyector de OSM
kubectl get pod -n kube-system --selector app=osm-injector
Un pod correcto del inyector de OSM tendría el siguiente aspecto:

osm-injector-5986c57765-vlsdk 1/1 Running 0 73m
Comprobación del servicio del inyector de OSM
kubectl get service -n kube-system osm-injector

Un servicio correcto del inyector de OSM tendría el siguiente aspecto:

osm-injector ClusterIP 10.0.39.54 <none> 9090/TCP 75m
Comprobación de puntos de conexión de OSM
kubectl get endpoints -n kube-system osm-injector
Un punto de conexión de OSM correcto tendría el siguiente aspecto:
NAME ENDPOINTS AGE

osm-injector 10.240.1.172:9090 75m
Comprobación de los webhooks de validación y mutación
kubectl get ValidatingWebhookConfiguration --selector app=osm-controller
Un webhook de validación de OSM correcto tendría el siguiente aspecto:
NAME WEBHOOKS AGE

aks-osm-webhook-osm 1 81m
kubectl get MutatingWebhookConfiguration --selector app=osm-injector
Un webhook de mutación de OSM correcto tendría el siguiente aspecto:
NAME WEBHOOKS AGE

aks-osm-webhook-osm 1 102m
Comprobación del servicio y el paquete de CA del webhook de validación
kubectl get ValidatingWebhookConfiguration aks-osm-webhook-osm -o json | jq

'.webhooks[0].clientConfig.service'
Una configuración de webhook de validación bien configurada tendría un aspecto similar al siguiente:
{
"name": "osm-config-validator",
"namespace": "kube-system",
"path": "/validate-webhook",
"port": 9093
}
Comprobación del servicio y el paquete de CA del webhook de mutación
kubectl get MutatingWebhookConfiguration aks-osm-webhook-osm -o json | jq

'.webhooks[0].clientConfig.service'
Una configuración de webhook de mutación bien configurada tendría un aspecto similar al siguiente:
{
"name": "osm-injector",
"namespace": "kube-system",
"path": "/mutate-pod-creation",
"port": 9090
}
Comprobación de si el controlador de OSM ha dado al webhook de validación (o de mutación ) un paquete de CA
NOTE
A partir de v0.8.2, es importante saber que el RP de AKS instala el webhook de validación y el reconciliador de AKS
garantiza que existe, pero el controlador de OSM es el que rellena el paquete de CA.
kubectl get ValidatingWebhookConfiguration aks-osm-webhook-osm -o json | jq -r

'.webhooks[0].clientConfig.caBundle' | wc -c
kubectl get MutatingWebhookConfiguration aks-osm-webhook-osm -o json | jq -r

'.webhooks[0].clientConfig.caBundle' | wc -c
1845
Este número indica el número de bytes o el tamaño del paquete de CA. Si está vacío o es 0 o algún número por
debajo de 1000, el paquete de CA no está correctamente aprovisionado. Sin un paquete de CA correcto, se
producirá un error en el webhook de validación y se prohibirá que el usuario realice cambios en el ConfigMap
osm-config en el espacio de nombres kube-system.
Un ejemplo de error en el que el paquete de CA es incorrecto:
Intento de cambiar el ConfigMap osm-config:
kubectl patch ConfigMap osm-config -n kube-system --type merge --patch '{"data":

{"config_resync_interval":"2m"}}'
Error:
Error from server (InternalError): Internal error occurred: failed calling webhook "osm-config-
webhook.k8s.io": Post https://osm-config-validator.kube-system.svc:9093/validate-webhook?timeout=30s: x509:
certificate signed by unknown authority
Solución alternativa para cuando la configuración del webhook de validación tenga un certificado incorrecto:
Opción 1 - Reiniciar el controlador de OSM: se reiniciará el controlador de OSM. En el inicio, sobrescribirá el
paquete de CA de los webhooks de mutación y validación.
kubectl rollout restart deployment -n kube-system osm-controller
Opción 2 - Eliminar el webhook de validación: al quitar el webhook de validación, las mutaciones del
ConfigMap osm-config ya no se validan. Cualquier revisión se realizará. En algún momento, el reconciliador
de AKS garantiza que el webhook de validación existe y volverá a crearlo. Es posible que sea necesario
reiniciar el controlador de OSM para volver a escribir rápidamente el paquete de CA.
kubectl delete ValidatingWebhookConfiguration aks-osm-webhook-osm
Opción 3 - Eliminación y revisión: el siguiente comando eliminará el webhook de validación, lo que nos
permitirá agregar valores, e intentará aplicar una revisión de inmediato. Lo más probable es que el
reconciliador de AKS no tenga tiempo suficiente para reconciliar y restaurar el webhook de validación, lo que
nos permite aplicar un cambio como último recurso:
kubectl delete ValidatingWebhookConfiguration aks-osm-webhook-osm; kubectl patch ConfigMap osm-config -n

kube-system --type merge --patch '{"data":{"config_resync_interval":"15s"}}'
Comprobacón del ConfigMap osm-config
NOTE
El controlador de OSM no requiere que el ConfigMap osm-config esté presente en el espacio de nombres kube-system.
El controlador tiene valores predeterminados razonables para la configuración y puede funcionar sin él.
Comprobación de la existencia:
kubectl get ConfigMap -n kube-system osm-config
Comprobación del contenido del ConfigMap osm-config
kubectl get ConfigMap -n kube-system osm-config -o json | jq '.data'
{
"egress": "true",
}
Valores de ConfigMap osm-config :
VA LO RES VA LO R
C L AVE T IP O P ERM IT IDO S P REDET ERM IN A DO F UN C IÓ N
egress bool true, false "false" Habilita la salida en la

malla.
VA LO RES VA LO R
enable_debug_server bool true, false "true" Habilita un punto de

conexión de
depuración en el pod
del controlador de
OSM para mostrar
información
relacionada con la
malla, como
conexiones proxy,
certificados y
directivas de SMI.
enable_privileged_init bool true, false "false" Habilita los

_container contenedores de
inicialización con
privilegios para pods
en la malla. Cuando
es false, los
contenedores de
inicialización solo
tienen NET_ADMIN.
envoy_log_level string trace, debug, info, "error" Establece el nivel de

warning, warn, error, detalle de registro del
critical, off sidecar del proxy de
Envoy, solo es
aplicable a los pods
recién creados que se
unen a la malla. Para
actualizar el nivel de
registro de los pods
existentes, reinicie la
implementación con
kubectl rollout
restart
.
outbound_ip_range_e string lista separada por - Lista global de

xclusion_list comas de intervalos intervalos de
IP con la forma direcciones IP que se
a.b.c.d/x van a excluir de la
interceptación de
tráfico saliente por el
proxy de sidecar.
VA LO RES VA LO R
permissive_traffic_poli bool true, false "false" Si se establece en

cy_mode true , se habilita el
modo de permitir
todo en la malla; es
decir, no se aplica la
directiva de tráfico en
la malla. Si se
establece en false ,
se habilita la directiva
de tráfico de denegar
todo en la malla; es
decir,
SMI Traffic
Target
es necesario para que
los servicios se
comuniquen.
prometheus_scraping bool true, false "true" Habilita la extracción

de métricas de
Prometheus en
servidores proxy de
sidecar.
service_cert_validity_ string 24 horas, 1h30m "24h" Establece la duración

duration (cualquier duración) de la validez del
certificado de
servicio,
representada como
una secuencia de
números decimales
con una fracción
opcional y un sufijo
de unidad.
tracing_enable bool true, false "false" Habilita el

seguimiento de
Jaeger para la malla.
tracing_address string jaeger.mesh- jaeger.kube- Dirección de la

namespace.svc.cluste system.svc.cluster.local
implementación de
r.local Jaeger, si está
habilitado el
seguimiento.
tracing_endpoint string /api/v2/spans /api/v2/spans Punto de conexión

para los datos de
seguimiento, si está
habilitado el
seguimiento.
tracing_port int cualquier valor "9411" Puerto en el que está

entero distinto de habilitado el
cero seguimiento.
use_https_ingress bool true, false "false" Habilita la entrada

HTTPS en la malla.
VA LO RES VA LO R
config_resync_interva string por debajo de 0 (deshabilitado) Cuando se

l 1 minuto se proporciona un valor
deshabilita superior a 1m (60s),
el controlador de
OSM enviará toda la
configuración
disponible a cada
envío Envoy en el
intervalo
especificado.
Comprobación de espacios de nombres
NOTE
El espacio de nombres espacio de nombres kube-system nunca participará en una malla de servicio y nunca se etiquetará
ni anotará con la clave o los valores siguientes.
Usamos el comando osm namespace add para unir espacios de nombres a una malla de servicio determinada.
Cuando un espacio de nombres de K8S forma parte de la malla (o para que forme parte de la malla) debe
cumplirse lo siguiente:
Vea las anotaciones con
kubectl get namespace bookbuyer -o json | jq '.metadata.annotations'
Las siguientes anotaciones deben estar presentes:
{
"openservicemesh.io/sidecar-injection": "enabled"
}
Vea las etiquetas con
kubectl get namespace bookbuyer -o json | jq '.metadata.labels'
La siguiente etiqueta debe estar presente:
{
"openservicemesh.io/monitored-by": "osm"
}
Si un espacio de nombres no está anotado con "openservicemesh.io/sidecar-injection": "enabled" o no está

etiquetado con "openservicemesh.io/monitored-by": "osm" , el inyector de agregará sidecars de Envoy.
Nota: Después de que se llame a osm namespace add , solo se insertarán los pods nuevos con un sidecar de
Envoy. Los pods existentes deben reiniciarse con kubectl rollout restart deployment ... .
Compruebe las CRD de SMI:

Compruebe si el clúster tiene las CRD necesarias:
kubectl get crds
Debemos tener lo siguiente instalado en el clúster:

httproutegroups.specs.smi-spec.io
tcproutes.specs.smi-spec.io
trafficsplits.split.smi-spec.io
traffictargets.access.smi-spec.io
udproutes.specs.smi-spec.io
Obtenga las versiones de las CRD instaladas con este comando:
for x in $(kubectl get crds --no-headers | awk '{print $1}' | grep 'smi-spec.io'); do
kubectl get crd $x -o json | jq -r '(.metadata.name, "----" , .spec.versions[].name, "\n")'
done
Resultado esperado:
httproutegroups.specs.smi-spec.io
----
v1alpha4
v1alpha3
v1alpha2
v1alpha1
tcproutes.specs.smi-spec.io
----
v1alpha4
v1alpha3
v1alpha2
v1alpha1
trafficsplits.split.smi-spec.io
----
v1alpha2
traffictargets.access.smi-spec.io
----
v1alpha3
v1alpha2
v1alpha1
udproutes.specs.smi-spec.io
----
v1alpha4
v1alpha3
v1alpha2
v1alpha1
El controlador de OSM v0.8.2 requiere las siguientes versiones:

traffictargets.access.smi-spec.io - v1alpha3
httproutegroups.specs.smi-spec.io - v1alpha4
tcproutes.specs.smi-spec.io - v1alpha4
udproutes.specs.smi-spec.io - No compatible
trafficsplits.split.smi-spec.io - v1alpha2
*.metrics.smi-spec.io - v1alpha1
Si faltan CRD, use los siguientes comandos para instalarlas en el clúster:
kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/v0.8.2/charts/osm/crds/access.yaml
kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/v0.8.2/charts/osm/crds/specs.yaml
kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/v0.8.2/charts/osm/crds/split.yaml
Deshabilitación del complemento Open Service Mesh (OSM) para el

clúster de AKS
Para deshabilitar el complemento de OSM, ejecute el comando siguiente:
az aks disable-addons -n <AKS-cluster-name> -g <AKS-resource-group-name> -a open-service-mesh

Istio
Istio es una malla de servicio completa, personalizable y extensible.
Architecture
Istio proporciona un plano de datos compuesto por sidecars basados en Envoy. Estos proxies inteligentes
controlan todo el tráfico de red de entrada y salida de las aplicaciones y cargas de trabajo en malla.
El plano de control administra la configuración, la directiva y la telemetría a través de los siguientes
componentes:
Mixer : aplica las directivas de uso y control de acceso. Recopila datos de telemetría de los proxies que se
insertan en Prometheus.
Pilot : proporciona la configuración y la directiva de detección de servicios y administración de tráfico
para los proxies.
Citadel : proporciona funciones de identidad y seguridad que permiten la conectividad mTLS entre los
servicios.
Galley : sintetiza y proporciona la configuración a los componentes.
En el diagrama de arquitectura siguiente se muestra cómo interactúan los distintos componentes del plano de
datos y del plano de control.
A la hora de Istio para las cargas de trabajo, es importante comprender y considerar las siguientes áreas:
Objetivos de diseño
Capabilities
Escenarios
Diseño de objetivos
Los siguientes objetivos de diseño constituyen la guía del proyecto Istio:
Maximizar la transparencia : debe permitir la adopción con la mínima cantidad de trabajo, para
obtener el valor real del sistema.
Extensibilidad : debe ser capaz de crecer y adaptarse a los cambios en las necesidades.
Por tabilidad : debe ejecutarse fácilmente en diferentes tipos de entornos: la nube, el entorno local.
Uniformidad de directivas : coherencia en la definición de las directivas entre los diversos recursos.
Capacidades
Istio ofrece el siguiente conjunto de funcionalidades:
Malla : puertas de enlace (varios clústeres), máquinas virtuales (expansión de malla)
Administración del tráfico : enrutamiento, división, tiempos de espera, disyuntores, reintentos, entrada,
salida
Directiva : control de acceso, límite de frecuencia, cuota, adaptadores de directivas personalizados
Seguridad : autenticación ( jwt), autorización, cifrado (mTLS), entidad de certificación externa (HashiCorp
Vault)
Obser vabilidad : métricas principales, reflejo, seguimiento, adaptadores personalizados, Prometheus,
Grafana
Escenarios
Istio es idóneo y se sugiere para los escenarios siguientes:
Se necesita extensibilidad y un amplio conjunto de funcionalidades
Se necesita expandir la malla para incluir cargas de trabajo basadas en máquinas virtuales
Malla de servicio de varios clústeres
Pasos siguientes
En la siguiente documentación se describe cómo puede instalar Istio en Azure Kubernetes Service (AKS):
Instalación de Istio en Azure Kubernetes Service (AKS)
También puede profundizar en los conceptos y en modelos de implementación adicionales de Istio:
Conceptos de Istio
Modelos de implementación de Istio
Instalación y uso de Istio en Azure Kubernetes
Service (AKS)
Istio es una malla de servicio de código abierto que proporciona un conjunto clave de funcionalidades en los
microservicios de un clúster de Kubernetes. Estas características incluyen la administración del tráfico, la
seguridad e identidad de servicio, el cumplimiento de directivas y la observación. Para más información sobre
Istio, vea la documentación del sitio oficial ¿Qué es Istio?.
En este artículo se explica cómo instalar Istio. El binario de cliente istioctl de Istio se instala en el equipo
cliente y, a continuación, los componentes de Istio se instalan en un clúster de Kubernetes en AKS.
NOTE
Las siguientes instrucciones son aplicables a la versión 1.7.3 de Istio.
El equipo de Istio ha probado las versiones de Istio 1.7.x con la versión de Kubernetes 1.16+ . Encontrará otras
versiones de Istio en GitHub: Istio > Releases (GitHub: Istio > Versiones), información sobre cada una de las versiones en
Istio News (Novedades de Istio) y las versiones compatibles de Kubernetes en Istio General FAQ (Istio: Preguntas
frecuentes generales).
En este artículo aprenderá a:

Descargar e instalar el binario de cliente istioctl de Istio
Instalar Istio en AKS
Validar la instalación de Istio
Acceder a los complementos
Desinstalar Istio de AKS
Antes de empezar
En los pasos detallados en este artículo se da por hecho que creó un clúster de AKS (Kubernetes 1.16 y
versiones posteriores, con RBAC de Kubernetes habilitado) y que estableció una conexión kubectl con el
clúster. Si necesita ayuda con cualquiera de estos elementos, consulte el inicio rápido de AKS.
Asegúrese de leer la documentación de rendimiento y escalabilidad de Istio para comprender los requisitos de
recursos adicionales para ejecutar Istio en el clúster de AKS. Los requisitos de memoria y núcleos varían en
función de la carga de trabajo concreta. Elija el número de nodos y el tamaño de la máquina virtual adecuados
para la instalación.
En este artículo, las instrucciones de instalación de Istio se dividen en varios pasos discretos. El resultado final
presenta la misma estructura que las instrucciones de instalación oficiales de Istio.

En un shell basado en Bash en Linux o en el Subsistema de Windows para Linux, use curl para descargar la
versión de Istio y, a continuación, realice la extracción con tar , tal como se indica a continuación:
# Specify the Istio version that will be leveraged throughout these instructions
ISTIO_VERSION=1.7.3
curl -sL "https://github.com/istio/istio/releases/download/$ISTIO_VERSION/istioctl-$ISTIO_VERSION-linux-

amd64.tar.gz" | tar xz
El archivo binario cliente istioctl se ejecuta en el equipo cliente y permite instalar y administrar Istio en el
clúster de AKS. Use los comandos siguientes para instalar el binario de cliente istioctl de Istio en un shell
basado en Bash en Linux o en el Subsistema de Windows para Linux. Estos comandos copian el binario de
cliente istioctl en la ubicación del programa de usuario estándar en su PATH .
sudo mv ./istioctl /usr/local/bin/istioctl

sudo chmod +x /usr/local/bin/istioctl
Si desea completar la línea de comandos del binario de cliente istioctl de Istio, realice la siguiente
configuración:
# Generate the bash completion file and source it in your current shell
mkdir -p ~/completions && istioctl collateral --bash -o ~/completions
source ~/completions/istioctl.bash
# Source the bash completion file in your .bashrc so that the command-line completions
# are permanently available in your shell
echo "source ~/completions/istioctl.bash" >> ~/.bashrc

En un shell basado en Bash de macOS, utilice curl para descargar la versión de Istio y, a continuación, realice la
extracción con tar , tal como se indica a continuación:
ISTIO_VERSION=1.7.3
curl -sL "https://github.com/istio/istio/releases/download/$ISTIO_VERSION/istioctl-$ISTIO_VERSION-

osx.tar.gz" | tar xz
El archivo binario cliente istioctl se ejecuta en el equipo cliente y permite instalar y administrar Istio en el
clúster de AKS. Use los siguientes comandos para instalar el binario de cliente istioctl de Istio en un shell
basado en Bash en macOS. Estos comandos copian el binario de cliente istioctl en la ubicación del programa
de usuario estándar en su PATH .
sudo mv ./istioctl /usr/local/bin/istioctl

sudo chmod +x /usr/local/bin/istioctl
Si desea completar la línea de comandos del binario de cliente istioctl de Istio, realice la siguiente
configuración:
mkdir -p ~/completions && istioctl collateral --bash -o ~/completions
source ~/completions/istioctl.bash
echo "source ~/completions/istioctl.bash" >> ~/.bashrc

En un shell basado en PowerShell en Windows, use Invoke-WebRequest para descargar la versión de Istio y, a
continuación, realice la extracción con Expand-Archive , como se indica a continuación:
$ISTIO_VERSION="1.7.3"
"https://github.com/istio/istio/releases/download/$ISTIO_VERSION/istioctl-$ISTIO_VERSION-win.zip" -
OutFile "istioctl-$ISTIO_VERSION.zip"
Expand-Archive -Path "istioctl-$ISTIO_VERSION.zip" -DestinationPath .
El archivo binario cliente istioctl se ejecuta en el equipo cliente y permite instalar y administrar istio en el
clúster de AKS. Use los siguientes comandos para instalar el binario de cliente istioctl de Istio en un shell
basado en PowerShell en Windows. Estos comandos copian los archivos binarios del cliente istioctl en una
carpeta de Istio y, luego, permiten que estén disponible de inmediato (en el shell actual) y de forma permanente
(entre reinicios del shell) mediante PATH . No es necesario tener privilegios elevados (administrador) para
ejecutar estos comandos y no hace falta reiniciar el shell.
# Copy istioctl.exe to C:\Istio

New-Item -ItemType Directory -Force -Path "C:\Istio"
Move-Item -Path .\istioctl.exe -Destination "C:\Istio\"
# Add C:\Istio to PATH.

$USER_PATH = [environment]::GetEnvironmentVariable("PATH", "User") + ";C:\Istio\"
$env:PATH += ";C:\Istio\"
Instalación de Istio Operator en AKS

Istio proporciona un operador para administrar la instalación y las actualizaciones de los componentes de Istio
en el clúster de AKS. Instalaremos Istio Operator con el archivo binario istioctl del cliente.
istioctl operator init
La imagen en su pantalla debería ser similar a la siguiente salida para confirmar que se ha instalado Istio
Operator.
Using operator Deployment image: docker.io/istio/operator:1.7.3

✔ Istio operator installed
✔ Installation complete
Istio Operator se instala en el espacio de nombres istio-operator . Consulte el espacio de nombres.
kubectl get all -n istio-operator
Debería ver los siguientes componentes implementados.

pod/istio-operator-6d7958b7bf-wxgdc 1/1 Running 0 2m43s

service/istio-operator ClusterIP 10.0.8.57 <none> 8383/TCP 2m43s

deployment.apps/istio-operator 1/1 1 1 2m43s
NAME DESIRED CURRENT READY AGE

replicaset.apps/istio-operator-6d7958b7bf 1 1 1 2m43s
Puede obtener más información sobre el patrón de Operator y cómo puede ayudarle a automatizar tareas
complejas a través de kubernetes.io.
Instalar componentes de Istio
Ahora que hemos instalado correctamente Istio Operator en nuestro clúster de AKS, es hora de instalar los
componentes de Istio.
Usaremos el perfil de configuración de Istio default para compilar la especificación de Istio Operator.
Puede ejecutar el siguiente comando istioctl para ver la configuración del perfil default de configuración de
Istio.
istioctl profile dump default
NOTE
Actualmente, Istio debe programarse para su ejecución en nodos de Linux. Si tiene nodos de Windows Server en el clúster,
debe asegurarse de que los pods de Istio solo se programan para ejecutarse en nodos de Linux. Usaremos selectores de
nodo para garantizar que los pods se programan en los nodos correctos.
Cau t i on
Las características CNI de Istio se encuentran actualmente en fase alfa, por lo que debe reflexionar antes de
habilitarlas.
Cree un archivo llamado istio.aks.yaml con el siguiente contenido. Este archivo contendrá los detalles de
especificación de Istio Operator para la configuración de Istio.
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
namespace: istio-system
name: istio-control-plane
spec:
# Use the default profile as the base
# More details at: https://istio.io/docs/setup/additional-setup/config-profiles/
profile: default
# Enable the addons that we will want to use
addonComponents:
grafana:
enabled: true
prometheus:
enabled: true
tracing:
enabled: true
kiali:
enabled: true
values:
global:
# Ensure that the Istio pods are only scheduled to run on Linux nodes
defaultNodeSelector:
kiali:
dashboard:
auth:
strategy: anonymous
Cree el espacio de nombres istio-system e implemente la especificación de Istio Operator en dicho espacio de
nombres. Istio Operator estará a la espera de la especificación de Istio Operator y la usará para instalar y
configurar Istio en el clúster de AKS.
kubectl create ns istio-system
kubectl apply -f istio.aks.yaml
En este punto, ya tendrá implementado Istio en su clúster de AKS. Para asegurarse de que ha implementado
correctamente Istio, vaya a la siguiente sección para validar la instalación de Istio.
Validar la instalación de Istio

Consulte el espacio de nombres istio-system en el que se instalaron los componentes de Istio y de
complemento mediante Istio Operator:
kubectl get all -n istio-system
Debería ver los siguientes componentes:

istio* : los componentes de Istio.
jaeger-* , tracing y zipkin : complementos de seguimiento.
prometheus : complemento de métricas.
grafana : complementos de panel de supervisión y análisis.
kiali : complemento de panel de malla de servicio.
pod/grafana-7cf9794c74-mpfbp 1/1 Running 0 5m53s
pod/istio-ingressgateway-86b5dbdcb9-ndrp5 1/1 Running 0 5m57s
pod/istio-tracing-c98f4b8fc-zqklg 1/1 Running 0 82s
pod/istiod-6965c56995-4ph9h 1/1 Running 0 6m15s
pod/kiali-7b44985d68-p87zh 1/1 Running 0 81s
pod/prometheus-6868989549-5ghzz 1/1 Running 0 81s

AGE
service/grafana ClusterIP 10.0.226.39 <none> 3000/TCP
5m54s
service/istio-ingressgateway LoadBalancer 10.0.143.56 20.53.72.254
15021:32166/TCP,80:31684/TCP,443:31302/TCP,15443:30863/TCP 5m57s
service/istiod ClusterIP 10.0.211.228 <none>
15010/TCP,15012/TCP,443/TCP,15014/TCP,853/TCP 6m16s
service/jaeger-agent ClusterIP None <none> 5775/UDP,6831/UDP,6832/UDP
82s
service/jaeger-collector ClusterIP 10.0.7.62 <none>
14267/TCP,14268/TCP,14250/TCP 82s
service/jaeger-collector-headless ClusterIP None <none> 14250/TCP
82s
service/jaeger-query ClusterIP 10.0.52.172 <none> 16686/TCP
82s
service/kiali ClusterIP 10.0.71.179 <none> 20001/TCP
82s
service/prometheus ClusterIP 10.0.171.151 <none> 9090/TCP
82s
service/tracing ClusterIP 10.0.195.137 <none> 80/TCP
82s
service/zipkin ClusterIP 10.0.136.111 <none> 9411/TCP
82s

deployment.apps/grafana 1/1 1 1 5m54s
deployment.apps/istio-ingressgateway 1/1 1 1 5m58s
deployment.apps/istio-tracing 1/1 1 1 83s
deployment.apps/istiod 1/1 1 1 6m16s
deployment.apps/kiali 1/1 1 1 83s
deployment.apps/prometheus 1/1 1 1 82s
NAME DESIRED CURRENT READY AGE

replicaset.apps/grafana-7cf9794c74 1 1 1 5m54s
replicaset.apps/istio-ingressgateway-86b5dbdcb9 1 1 1 5m58s
replicaset.apps/istio-tracing-c98f4b8fc 1 1 1 83s
replicaset.apps/istiod-6965c56995 1 1 1 6m16s
replicaset.apps/kiali-7b44985d68 1 1 1 82s
replicaset.apps/prometheus-6868989549 1 1 1 82s
NAME REFERENCE TARGETS

MINPODS MAXPODS REPLICAS AGE
horizontalpodautoscaler.autoscaling/istio-ingressgateway Deployment/istio-ingressgateway 7%/80% 1
5 1 5m57s
horizontalpodautoscaler.autoscaling/istiod Deployment/istiod 1%/80% 1
5 1 6m16s
También puede obtener conclusiones adicionales sobre la instalación al observar los registros de Istio Operator.
kubectl logs -n istio-operator -l name=istio-operator -f
Si istio-ingressgateway muestra una dirección IP externa de <pending> , espere unos minutos hasta que las
redes de Azure hayan asignado una dirección IP.
Todos los pods deben mostrar un estado de Running . Si los pods no tienen estos estados, espere un minuto o
dos hasta que los tengan. Si algún pod notifica un problema, use el comando kubectl describe pod para revisar
su salida y su estado.
Acceso a complementos
Istio Operator instaló una serie de complementos que ofrecen funcionalidad adicional. Las aplicaciones web de
los complementos no se exponen de forma pública a través de una dirección IP externa.
Para acceder a las interfaces de usuario de los complementos, use el comando istioctl dashboard . Este
comando usa kubectl port-forward y un puerto aleatorio para crear una conexión segura entre la máquina
cliente y el pod correspondiente en el clúster de AKS. A continuación, abre automáticamente la aplicación web
del complemento en el explorador predeterminado.
Grafana
Los paneles de análisis y supervisión para Istio los proporciona Grafana. Recuerde usar las credenciales que creó
a través del secreto de Grafana cuando se le solicite. Para abrir el panel de Grafana de forma segura, ejecute el
siguiente comando:
istioctl dashboard grafana
Prometheus
Las métricas para Istio las proporciona Prometheus. Para abrir el panel de Prometheus de forma segura, ejecute
el siguiente comando:
istioctl dashboard prometheus
Jaeger
El seguimiento de Istio lo proporciona Jaeger. Para abrir el panel de Jaeger de forma segura, ejecute el siguiente
comando:
istioctl dashboard jaeger
Kiali
Kiali proporciona un panel de observación de malla de servicio. Recuerde usar las credenciales que creó a través
del secreto de Kiali cuando se le solicite. Para abrir el panel de Kiali de forma segura, ejecute el siguiente
comando:
istioctl dashboard kiali
Envoy
Hay disponible una interfaz simple a los proxies de Envoy. Proporciona información de configuración y métricas
de un proxy de Envoy que se ejecuta en un pod especificado. Para abrir la interfaz de Envoy de forma segura,
ejecute el siguiente comando:
istioctl dashboard envoy <pod-name>.<namespace>
Desinstalar Istio de AKS

WARNING
Eliminar Istio de un sistema en ejecución puede provocar problemas de tráfico entre sus servicios. Asegúrese de haber
hecho los aprovisionamientos necesarios para que su sistema funcione correctamente sin Istio antes de continuar.
Eliminación de Istio
Para quitar Istio del clúster de AKS, elimine el recurso IstioOperator denominado istio-control-plane que se
agregó anteriormente. Istio Operator reconocerá que se ha quitado la especificación de Istio Operator y, a
continuación, eliminará todos los componentes de Istio asociados.
kubectl delete istiooperator istio-control-plane -n istio-system
Puede ejecutar lo siguiente para comprobar que se eliminaron todos los componentes de Istio.
kubectl get all -n istio-system
Eliminación de Istio Operator

Una vez que Istio se ha desinstalado correctamente, también puede quitar Istio Operator.
istioctl operator remove
Y, por último, quite los espacios de nombres istio- .
kubectl delete ns istio-system

kubectl delete ns istio-operator
Pasos siguientes
Para explorar más opciones de instalación y configuración para Istio, consulte las siguientes guías oficiales de
Istio:
Istio - Installation Guides (Istio - Guías de instalación)
También puede seguir otros escenarios mediante:
Ejemplo de la aplicación BookInfo de Istio
Uso del enrutamiento inteligente y de las versiones
de valor controlado con Istio en Azure Kubernetes
Service (AKS)
Istio es una malla de servicio de código abierto que proporciona un conjunto clave de funcionalidades en los
microservicios de un clúster de Kubernetes. Estas características incluyen la administración del tráfico, la
seguridad e identidad de servicio, el cumplimiento de directivas y la observación. Para más información sobre
Istio, vea la documentación del sitio oficial ¿Qué es Istio?.
En este artículo se explica cómo usar la funcionalidad de administración de tráfico de Istio. Se usa una aplicación
de votación de AKS de ejemplo para explorar el enrutamiento inteligente y las versiones de valor controlado.
Actualizar la aplicación
Lanzamiento de una versión de valor controlado de la aplicación
Finalización del lanzamiento
Antes de empezar
NOTE
Este escenario se ha probado con la versión de Istio 1.3.2 .
clúster. Istio también debe estar instalado en el clúster.
Si necesita ayuda con cualquiera de estos elementos, consulte el inicio rápido de AKS y la guía de instalación de
Istio en AKS.
Acerca de este escenario de aplicación

La aplicación de votación de AKS de ejemplo proporciona dos opciones de voto (Cats [gatos] o Dogs [perros]) a
los usuarios. Hay un componente de almacenamiento que conserva el número de votos de cada opción.
Además, hay un componente de análisis que proporciona detalles sobre los votos emitidos para cada opción.
En este escenario de la aplicación, primero debe implementar la versión 1.0 de la aplicación de votación y la
versión 1.0 del componente de análisis. El componente de análisis proporciona recuentos simples del número
de votos. La aplicación de votación y el componente de análisis interactúan con la versión 1.0 del componente
de almacenamiento, que está respaldada por Redis.
Actualice el componente de análisis a la versión 1.1 , que proporciona recuentos, totales y porcentajes.
Un subconjunto de usuarios prueban la versión 2.0 de la aplicación mediante una versión de valor controlado.
Esta nueva versión usa un componente de almacenamiento respaldado por una base de datos MySQL.
Una vez que esté seguro de que la versión 2.0 funciona según lo previsto en el subconjunto de usuarios, lance
la versión 2.0 a todos los usuarios.
Vamos a empezar con la implementación de la aplicación en el clúster de Azure Kubernetes Service (AKS). En el
diagrama siguiente se muestra lo que se ejecuta al final de esta sección; la versión 1.0 de todos los
componentes con solicitudes de entrada atendidas mediante la puerta de enlace de entrada de Istio:
Los artefactos necesarios para avanzar en este artículo están disponibles en el repositorio Azure-Samples/aks-
voting-app de GitHub. Puede descargar los artefactos o clonar el repositorio como sigue:
git clone https://github.com/Azure-Samples/aks-voting-app.git
Cambie a la siguiente carpeta en el repositorio clonado o descargado y ejecute todos los pasos subsiguientes
desde esta carpeta:
cd aks-voting-app/scenarios/intelligent-routing-with-istio
Primero, cree un espacio de nombres denominado voting en el clúster de AKS para la aplicación de votación
de AKS de ejemplo como se indica a continuación:
kubectl create namespace voting
Etiquete el espacio de nombres con istio-injection=enabled . Esta etiqueta indica a Istio que inyecte
automáticamente los servidores proxy de Istio como patrones sidecar en todos los pods de este espacio de
nombres.
kubectl label namespace voting istio-injection=enabled
Ahora vamos a crear los componentes de la aplicación de votación de AKS. Cree estos componentes en el
espacio de nombres voting creado en un paso anterior.
kubectl apply -f kubernetes/step-1-create-voting-app.yaml --namespace voting
La siguiente salida de ejemplo muestra los recursos que van a crearse:
deployment.apps/voting-storage-1-0 created
service/voting-storage created
deployment.apps/voting-analytics-1-0 created
service/voting-analytics created
deployment.apps/voting-app-1-0 created
service/voting-app created
NOTE
Istio tiene algunos requisitos específicos en relación a los pods y los servicios. Para más información, consulte la
documentación sobre requisitos para pods y servicios de Istio.
Para ver los pods creados, use el comando kubectl get pods como sigue:
kubectl get pods -n voting --show-labels
En la salida de ejemplo siguiente se muestra que hay tres instancias del pod voting-app y una única instancia
de los pods voting-analytics y voting-storage . Cada pod tiene dos contenedores. Uno de estos contenedores
es el componente y el otro es istio-proxy :
NAME READY STATUS RESTARTS AGE LABELS

voting-analytics-1-0-57c7fccb44-ng7dl 2/2 Running 0 39s app=voting-analytics,pod-
template-hash=57c7fccb44,version=1.0
voting-app-1-0-956756fd-d5w7z 2/2 Running 0 39s app=voting-app,pod-template-
hash=956756fd,version=1.0
voting-app-1-0-956756fd-f6h69 2/2 Running 0 39s app=voting-app,pod-template-
voting-app-1-0-956756fd-wsxvt 2/2 Running 0 39s app=voting-app,pod-template-
voting-storage-1-0-5d8fcc89c4-2jhms 2/2 Running 0 39s app=voting-storage,pod-
template-hash=5d8fcc89c4,version=1.0
Para ver información sobre el pod, usaremos el comando kubectl describe pod con selectores de etiqueta para
seleccionar el pod voting-analytics . Filtraremos la salida para mostrar los detalles de los dos contenedores
incluidos en el pod:
kubectl describe pod -l "app=voting-analytics, version=1.0" -n voting | egrep "istio-proxy:|voting-

analytics:" -A2
Istio ha inyectado automáticamente el contenedor istio-proxy para administrar el tráfico de red hacia y desde
los componentes, como se muestra en la siguiente salida de ejemplo:
voting-analytics:
Container ID: docker://35efa1f31d95ca737ff2e2229ab8fe7d9f2f8a39ac11366008f31287be4cea4d
Image: mcr.microsoft.com/aks/samples/voting/analytics:1.0
--
istio-proxy:
Container ID: docker://1fa4eb43e8d4f375058c23cc062084f91c0863015e58eb377276b20c809d43c6
Image: docker.io/istio/proxyv2:1.3.2
kubectl describe pod -l "app=voting-analytics, version=1.0" -n voting | egrep "istio-proxy:|voting-
analytics:" -A2
voting-analytics:
--
istio-proxy:
kubectl describe pod -l "app=voting-analytics, version=1.0" -n voting | Select-String -Pattern "istio-

proxy:|voting-analytics:" -Context 0,2
> voting-analytics:
> istio-proxy:
No puede conectarse a la aplicación de votación hasta que se cree la puerta de enlace y el servicio virtual de
Istio. Los recursos de Istio enrutan el tráfico desde la puerta de enlace de entrada de Istio predeterminada hasta
nuestra aplicación.
NOTE
Una puer ta de enlace es un componente del perímetro de la malla de servicio que recibe el tráfico HTTP y TCP entrante
o saliente.
Un ser vicio vir tual define un conjunto de reglas de enrutamiento para uno o varios servicios de destino.
Use el comando kubectl apply para implementar la puerta de enlace y el servicio virtual yaml. Recuerde
especificar el espacio de nombres en el que se implementan estos recursos.
kubectl apply -f istio/step-1-create-voting-app-gateway.yaml --namespace voting
La siguiente salida de ejemplo muestra la creación de la puerta de enlace y el servicio virtual:
virtualservice.networking.istio.io/voting-app created
gateway.networking.istio.io/voting-app-gateway created
Obtenga la dirección IP de la puerta de enlace de entrada de Istio con el comando siguiente:
kubectl get service istio-ingressgateway --namespace istio-system -o

jsonpath='{.status.loadBalancer.ingress[0].ip}'
En la siguiente salida de ejemplo se muestra la dirección IP de la puerta de enlace de entrada:
20.188.211.19
Abra un explorador y pegue la dirección IP. Se muestra la aplicación de votación de AKS de ejemplo.
La información de la parte inferior de la pantalla muestra que la aplicación usa la versión 1.0 de voting-app y
la versión 1.0 de voting-storage (Redis).
Actualizar la aplicación
Vamos a implementar una versión nueva del componente de análisis. Esta nueva versión 1.1 muestra los
totales y porcentajes además del recuento de cada categoría.
En el diagrama siguiente se muestra lo que se va a ejecutar al final de esta sección; solo la versión 1.1 de
nuestro componente voting-analytics tiene tráfico enrutado desde el componente voting-app . Aunque la
versión 1.0 de nuestro componente voting-analytics continúa ejecutándose y el servicio voting-analytics
hace referencia a ella, los servidores proxy de Istio deniegan el tráfico hacia y desde dicha versión.
Vamos a implementar la versión 1.1 del componente voting-analytics . Cree este componente en el espacio
de nombres voting :
kubectl apply -f kubernetes/step-2-update-voting-analytics-to-1.1.yaml --namespace voting
La siguiente salida de ejemplo muestra los recursos que van a crearse:
Vuelva a abrir la aplicación de votación de AKS de ejemplo en un explorador con el uso de la dirección IP de la
puerta de enlace de entrada de Istio obtenida en el paso anterior.
El explorador alterna entre las dos vistas que se muestran a continuación. Puesto que utiliza un servicio de
Kubernetes para el componente voting-analytics con un único selector de etiquetas ( app: voting-analytics ),
Kubernetes usa el comportamiento predeterminado de round-robin entre los pods que coinciden con dicho
selector. En este caso, son las versiones 1.0 y 1.1 de sus pods voting-analytics .
Puede visualizar el cambio entre las dos versiones del componente voting-analytics como se muestra a
continuación. Recuerde usar la dirección IP de su propia puerta de enlace de entrada de Istio.
INGRESS_IP=20.188.211.19
for i in {1..5}; do curl -si $INGRESS_IP | grep results; done
INGRESS_IP=20.188.211.19
$INGRESS_IP="20.188.211.19"
(1..5) |% { (Invoke-WebRequest -Uri $INGRESS_IP).Content.Split("`n") | Select-String -Pattern "results" }
La salida de ejemplo siguiente muestra la parte pertinente del sitio web devuelto a medida que el sitio cambia
entre versiones:
<div id="results"> Cats: 2 | Dogs: 4 </div>

<div id="results"> Cats: 2/6 (33%) | Dogs: 4/6 (67%) </div>
Bloqueo del tráfico a la versión 1.1 de la aplicación

Ahora vamos a bloquear el tráfico únicamente a la versión 1.1 del componente voting-analytics y a la
versión 1.0 del componente voting-storage . A continuación, defina las reglas de enrutamiento de todos los
demás componentes.
Un ser vicio vir tual define un conjunto de reglas de enrutamiento para uno o varios servicios de
destino.
Una regla de destino define las directivas de tráfico y las directivas específicas de la versión.
Una directiva define qué métodos de autenticación pueden aceptarse en las cargas de trabajo.
Use el comando kubectl apply para reemplazar la definición de servicio virtual en el componente voting-app
y agregue reglas de destino y servicios virtuales para los demás componentes. Agregue también una directiva al
espacio de nombres voting para asegurarse de que todas las comunicaciones entre los servicios están
protegidas con certificados de cliente y Mutual TLS.
La directiva tiene peers.mtls.mode establecido en STRICT para garantizar la aplicación del certificado Mutual
TLS entre los servicios dentro del espacio de nombres voting .
También se establece trafficPolicy.tls.mode en ISTIO_MUTUAL en todas nuestras reglas de destino. Istio
ofrece servicios con identidades seguras y protege las comunicaciones entre los servicios con certificados
cliente y Mutual TLS que Istio administra de forma transparente.
kubectl apply -f istio/step-2-update-and-add-routing-for-all-components.yaml --namespace voting
En la siguiente salida de ejemplo se muestra la creación o actualización de la directiva, las reglas de destino y los
servicios virtuales nuevos:
virtualservice.networking.istio.io/voting-app configured
policy.authentication.istio.io/default created
destinationrule.networking.istio.io/voting-app created
destinationrule.networking.istio.io/voting-analytics created
virtualservice.networking.istio.io/voting-analytics created
destinationrule.networking.istio.io/voting-storage created
virtualservice.networking.istio.io/voting-storage created
Si vuelve a abrir la aplicación de votación de AKS en un explorador, solo la nueva versión 1.1 del componente
voting-analytics se usa en el componente voting-app .
Puede visualizar que ahora solo se le redirige a la versión 1.1 del componente voting-analytics como se
muestra a continuación. Recuerde usar la dirección IP de su propia puerta de enlace de entrada de Istio:
INGRESS_IP=20.188.211.19
INGRESS_IP=20.188.211.19
$INGRESS_IP="20.188.211.19"
(1..5) |% { (Invoke-WebRequest -Uri $INGRESS_IP).Content.Split("`n") | Select-String -Pattern "results" }
La salida de ejemplo siguiente muestra la parte pertinente del sitio web devuelto:
Ahora se debe confirmar que Istio usa los certificados Mutual TLS para proteger las comunicaciones entre cada
uno de los servicios. Para ello, usaremos el comando authn tls-check del binario de cliente istioctl , que toma
la siguiente forma.
istioctl authn tls-check <pod-name[.namespace]> [<service>]
Este conjunto de comandos proporcionan información sobre el acceso a los servicios especificados desde todos
los pods que se encuentran en un espacio de nombres y coinciden con un conjunto de etiquetas:
# mTLS configuration between each of the istio ingress pods and the voting-app service
kubectl get pod -n istio-system -l app=istio-ingressgateway | grep Running | cut -d ' ' -f1 | xargs -n1 -I{}
istioctl authn tls-check {}.istio-system voting-app.voting.svc.cluster.local
# mTLS configuration between each of the voting-app pods and the voting-analytics service
kubectl get pod -n voting -l app=voting-app | grep Running | cut -d ' ' -f1 | xargs -n1 -I{} istioctl authn
tls-check {}.voting voting-analytics.voting.svc.cluster.local
# mTLS configuration between each of the voting-app pods and the voting-storage service
tls-check {}.voting voting-storage.voting.svc.cluster.local
# mTLS configuration between each of the voting-analytics version 1.1 pods and the voting-storage service
kubectl get pod -n voting -l app=voting-analytics,version=1.1 | grep Running | cut -d ' ' -f1 | xargs -n1 -
I{} istioctl authn tls-check {}.voting voting-storage.voting.svc.cluster.local
kubectl get pod -n istio-system -l app=istio-ingressgateway | grep Running | cut -d ' ' -f1 | xargs -n1 -I{}
istioctl authn tls-check {}.istio-system voting-app.voting.svc.cluster.local
tls-check {}.voting voting-analytics.voting.svc.cluster.local
tls-check {}.voting voting-storage.voting.svc.cluster.local
kubectl get pod -n voting -l app=voting-analytics,version=1.1 | grep Running | cut -d ' ' -f1 | xargs -n1 -
I{} istioctl authn tls-check {}.voting voting-storage.voting.svc.cluster.local
(kubectl get pod -n istio-system -l app=istio-ingressgateway | Select-String -Pattern "Running").Line |% {
$_.Split()[0] |% { istioctl authn tls-check $($_ + ".istio-system") voting-app.voting.svc.cluster.local } }
(kubectl get pod -n voting -l app=voting-app | Select-String -Pattern "Running").Line |% { $_.Split()[0] |%
{ istioctl authn tls-check $($_ + ".voting") voting-analytics.voting.svc.cluster.local } }
(kubectl get pod -n voting -l app=voting-app | Select-String -Pattern "Running").Line |% { $_.Split()[0] |%
{ istioctl authn tls-check $($_ + ".voting") voting-storage.voting.svc.cluster.local } }
(kubectl get pod -n voting -l app=voting-analytics,version=1.1 | Select-String -Pattern "Running").Line |% {
$_.Split()[0] |% { istioctl authn tls-check $($_ + ".voting") voting-storage.voting.svc.cluster.local } }
La salida de ejemplo siguiente muestra que el certificado Mutual TLS se ha aplicado en todas las consultas
anteriores. La salida también muestra las reglas de directiva y destino que exige Mutual TLS:
# mTLS configuration between istio ingress pods and the voting-app service
HOST:PORT STATUS SERVER CLIENT AUTHN POLICY DESTINATION
RULE
voting-app.voting.svc.cluster.local:8080 OK mTLS mTLS default/voting voting-
app/voting
HOST:PORT STATUS SERVER CLIENT AUTHN POLICY
DESTINATION RULE
voting-analytics.voting.svc.cluster.local:8080 OK mTLS mTLS default/voting
voting-analytics/voting
DESTINATION RULE
DESTINATION RULE
DESTINATION RULE
voting-storage.voting.svc.cluster.local:6379 OK mTLS mTLS default/voting voting-
storage/voting
DESTINATION RULE
storage/voting
DESTINATION RULE
storage/voting
DESTINATION RULE
storage/voting
Lanzamiento de una versión de valor controlado de la aplicación

Vamos a implementar una nueva versión 2.0 de los componentes voting-app , voting-analytics y
voting-storage . El nuevo componente voting-storage usa MySQL en lugar de Redis y los componentes
voting-app y voting-analytics están actualizados para que puedan usar este nuevo componente
voting-storage .
El componente voting-app ahora admite la funcionalidad de marca de características. Esta marca de
características permite probar la funcionalidad de la versión de valor controlado de Istio para un subconjunto de
usuarios.
En el diagrama siguiente se muestra lo que se ejecutará al final de esta sección.
La versión 1.0 del componente voting-app , la versión 1.1 del componente voting-analytics y la versión
1.0 del componente voting-storage son capaces de comunicarse entre sí.
La versión 2.0 del componente voting-app , la versión 2.0 del componente voting-analytics y la versión
2.0 del componente voting-storage son capaces de comunicarse entre sí.
La versión 2.0 del componente voting-app solo es accesible para los usuarios que tengan un conjunto
específico de marcas de características. Este cambio se administra con una marca de características mediante
una cookie.
En primer lugar, actualice las reglas de destino y los servicios virtuales de Istio destinados a estos nuevos
componentes. Estas actualizaciones garantizan que el tráfico no se enrute incorrectamente a los nuevos
componentes y que los usuarios no tengan un acceso inesperado:
kubectl apply -f istio/step-3-add-routing-for-2.0-components.yaml --namespace voting
En la siguiente salida de ejemplo se muestran las reglas de destino y los servicios virtuales que van a
actualizarse:
destinationrule.networking.istio.io/voting-app configured
virtualservice.networking.istio.io/voting-app configured
destinationrule.networking.istio.io/voting-analytics configured
virtualservice.networking.istio.io/voting-analytics configured
destinationrule.networking.istio.io/voting-storage configured
virtualservice.networking.istio.io/voting-storage configured
A continuación, vamos a agregar los objetos de Kubernetes para los componentes de la nueva versión 2.0 .
Actualice también el servicio voting-storage para que incluya el puerto 3306 para MySQL:
kubectl apply -f kubernetes/step-3-update-voting-app-with-new-storage.yaml --namespace voting
En la siguiente salida de ejemplo se muestra que los objetos de Kubernetes se han actualizado o creado
correctamente:
service/voting-storage configured
secret/voting-storage-secret created
deployment.apps/voting-storage-2-0 created
persistentvolumeclaim/mysql-pv-claim created
deployment.apps/voting-app-2-0 created
Espere hasta que todos los pods de la versión 2.0 estén en ejecución. Use el comando kubectl get pods con el
conmutador de inspección -w para ver los cambios en todos los pods del espacio de nombres voting :
kubectl get pods --namespace voting -w
Ahora debe tener la capacidad de alternar entre la versión 1.0 y la versión 2.0 (de valor controlado) de la
aplicación de votación. El botón de alternancia de la marca de características en la parte inferior de la pantalla
establece una cookie. El servicio virtual voting-app usa esta cookie para enrutar a los usuarios a la nueva
versión 2.0 .
Los recuentos de votos son diferentes entre las versiones de la aplicación. Esta diferencia resalta que se están
usando dos back-ends de almacenamiento distintos.
Finalización del lanzamiento

Una vez que haya probado correctamente la versión de valor controlado, actualice el servicio virtual voting-app
para enrutar todo el tráfico a la versión 2.0 del componente voting-app . A continuación, todos los usuarios
verán la versión 2.0 de la aplicación, independientemente de si la marca de características está establecida o
no:
Actualice todas las reglas de destino para quitar las versiones de los componentes que ya no desea que estén
activas. A continuación, actualice todos los servicios virtuales para que dejen de hacer referencia a dichas
versiones.
Como ya no hay tráfico a ninguna de las versiones anteriores de los componentes, ahora puede eliminar con
seguridad todas las implementaciones de dichos componentes.
Ya ha lanzado correctamente una versión nueva de la aplicación de votación de AKS.
Limpieza
Para quitar la aplicación de votación de AKS utilizada en este escenario de su clúster de AKS, puede eliminar el
espacio de nombres voting como se muestra a continuación:
kubectl delete namespace voting
La siguiente salida de ejemplo muestra que se quitaron todos los componentes de la aplicación de votación de
AKS del clúster de AKS.
namespace "voting" deleted
Pasos siguientes
Puede explorar escenarios adicionales con el ejemplo de la aplicación Bookinfo en Istio.
Linkerd
Linkerd es una malla de servicio ligera y fácil de usar.
Architecture
Linkerd proporciona un plano de datos que se compone de sidecars de proxy ultraligeros y especializados de
Linkerd. Estos proxies inteligentes controlan todo el tráfico de red de entrada y salida de las aplicaciones y
cargas de trabajo en malla. Los proxies también exponen métricas a través de puntos de conexión de métricas
de Prometheus.
El plano de control administra la configuración y los datos de telemetría agregados a través de los siguientes
componentes:
Controller : proporciona una API que controla la CLI y el panel de Linkerd. Proporciona la configuración
para los proxies.
Tap : establece inspecciones en tiempo real en solicitudes y respuestas.
Identity : proporciona funcionalidades de identidad y seguridad que permiten la conectividad mTLS entre
los servicios.
Web : proporciona el panel de Linkerd.
A la hora de evaluar Linkerd para las cargas de trabajo, es importante comprender y considerar las siguientes
áreas:
Principios de diseño
Capabilities
Escenarios
Principios de diseño
Los siguientes principios constituyen la guía del proyecto Linkerd:
Conser var un diseño sencillo : debe ser fácil de usar y comprender.
Minimizar los requisitos de recursos : debe suponer un rendimiento y un costo de recursos mínimos.
Simplemente trabajo : no debe interrumpir las aplicaciones existentes ni requerir una configuración
compleja.
Capacidades
Linkerd proporciona el siguiente conjunto de funcionalidades:
Malla : opción de depuración integrada
Administración del tráfico : división, tiempos de espera, reintentos, entrada
Seguridad : cifrado (mTLS), certificados con rotación automática cada 24 horas
Obser vabilidad : métricas principales, Tap, seguimiento, perfiles de servicio y métricas por ruta, panel
web con gráficos de topología, Prometheus, Grafana
Escenarios
Linkerd es idóneo y se sugiere para los escenarios siguientes:
Uso sencillo, únicamente con el conjunto esencial de requisitos de funcionalidad
Baja latencia, baja sobrecarga, con foco en la observabilidad y una administración de tráfico simple
Pasos siguientes
En la siguiente documentación se describe cómo puede instalar Linkerd en Azure Kubernetes Service (AKS):
Instalación de Linkerd en Azure Kubernetes Service (AKS)
También puede seguir explorando las características y la arquitectura de Linkerd:
Linkerd Features (Características de Linkerd)
Linkerd Architecture (Arquitectura de Linkerd)
Instalación de Linkerd en Azure Kubernetes Service
(AKS)
Linkerd es una malla de servicio de código abierto y un proyecto en incubación de CNCF. Linkerd es una malla
de servicio ultraligera que proporciona características entre las que se incluyen la administración del tráfico, la
identidad y la seguridad de los servicios, la seguridad, la confiabilidad y la observabilidad. Para más información
sobre Linkerd, consulte la documentación oficial Linkerd FAQ (Preguntas frecuentes de Linkerd) y Linkerd
Architecture (Arquitectura de Linkerd).
En este artículo se explica cómo instalar Linkerd. El binario de cliente linkerd de Linkerd se instala en la
máquina cliente y sus componentes se instalan en un clúster de Kubernetes en AKS.
NOTE
Estas instrucciones son aplicables a la versión stable-2.6.0 de Linkerd.
Las versiones stable-2.6.x de Linkerd se pueden ejecutar en las versiones 1.13+ de Kubernetes. Puede encontrar
versiones estables y preliminares de Linkerd en GitHub - Linkerd Releases (GitHub: Linkerd > Versiones).

Descarga e instalación del binario de cliente linkerd de Linkerd
Instalación de Linkerd en AKS
Validación de la instalación de Linkerd
Acceso al panel
Desinstalación de Linkerd de AKS
Antes de empezar
clúster. Si necesita ayuda con cualquiera de estos elementos, consulte el inicio rápido de AKS.
Todos los pods de Linkerd deben estar programados para ejecutarse en nodos de Linux: esta es la configuración
predeterminada en el método de instalación que se detalla a continuación y no requiere ninguna otra
configuración.
En este artículo, las instrucciones de instalación de Linkerd se dividen en varios pasos discretos. El resultado
final presenta la misma estructura que las instrucciones de introducción oficiales de Linkerd.

En un shell basado en Bash en Linux o en el Subsistema de Windows para Linux, use curl para descargar la
versión de Linkerd tal como se indica a continuación:
# Specify the Linkerd version that will be leveraged throughout these instructions
LINKERD_VERSION=stable-2.6.0
curl -sLO "https://github.com/linkerd/linkerd2/releases/download/$LINKERD_VERSION/linkerd2-cli-

$LINKERD_VERSION-linux"
El binario de cliente linkerd se ejecuta en la máquina cliente y permite interactuar con la malla de servicio de
Linkerd. Use los comandos siguientes para instalar el binario de cliente linkerd de Linkerd en un shell basado
en Bash en Linux o en el Subsistema de Windows para Linux. Estos comandos copian el binario de cliente
linkerd en la ubicación del programa de usuario estándar en su PATH .
sudo cp ./linkerd2-cli-$LINKERD_VERSION-linux /usr/local/bin/linkerd

sudo chmod +x /usr/local/bin/linkerd
Si desea completar la línea de comandos del binario de cliente linkerd de Linkerd, realice la siguiente
configuración:
mkdir -p ~/completions && linkerd completion bash > ~/completions/linkerd.bash
source ~/completions/linkerd.bash
echo "source ~/completions/linkerd.bash" >> ~/.bashrc

En un shell basado en Bash en MacOS, use curl para descargar la versión de Linkerd como se indica a
continuación:
LINKERD_VERSION=stable-2.6.0
curl -sLO "https://github.com/linkerd/linkerd2/releases/download/$LINKERD_VERSION/linkerd2-cli-

$LINKERD_VERSION-darwin"
Linkerd. Use los siguientes comandos para instalar el binario de cliente linkerd de Linkerd en un shell basado
en Bash en MacOS. Estos comandos copian el binario de cliente linkerd en la ubicación del programa de
usuario estándar en su PATH .
sudo cp ./linkerd2-cli-$LINKERD_VERSION-darwin /usr/local/bin/linkerd

sudo chmod +x /usr/local/bin/linkerd
Si desea completar la línea de comandos del binario de cliente linkerd de Linkerd, realice la siguiente
configuración:
mkdir -p ~/completions && linkerd completion bash > ~/completions/linkerd.bash
source ~/completions/linkerd.bash
echo "source ~/completions/linkerd.bash" >> ~/.bashrc

En un shell basado en PowerShell en Windows, use Invoke-WebRequest para descargar la versión de Linkerd
como se indica a continuación:
$LINKERD_VERSION="stable-2.6.0"
# Enforce TLS 1.2

"https://github.com/linkerd/linkerd2/releases/download/$LINKERD_VERSION/linkerd2-cli-$LINKERD_VERSION-
windows.exe" -OutFile "linkerd2-cli-$LINKERD_VERSION-windows.exe"
Linkerd. Use los siguientes comandos para instalar el binario de cliente linkerd de Linkerd en un shell basado
en PowerShell en Windows. Estos comandos copian el binario de cliente linkerd en una carpeta de Linkerd y,
luego, permiten que estén disponible de inmediato (en el shell actual) y de forma permanente (entre reinicios
del shell) mediante PATH . No es necesario tener privilegios elevados (administrador) para ejecutar estos
comandos y no hace falta reiniciar el shell.
# Copy linkerd.exe to C:\Linkerd

New-Item -ItemType Directory -Force -Path "C:\Linkerd"
Copy-Item -Path ".\linkerd2-cli-$LINKERD_VERSION-windows.exe" -Destination "C:\Linkerd\linkerd.exe"
# Add C:\Linkerd to PATH.

$USER_PATH = [environment]::GetEnvironmentVariable("PATH", "User") + ";C:\Linkerd\"
$env:PATH += ";C:\Linkerd\"
Instalación de Linkerd en AKS

Antes de instalar Linkerd, ejecutaremos comprobaciones previas para determinar si el plano de control se puede
instalar en nuestro clúster de AKS:
linkerd check --pre
Debería ver algo parecido a lo siguiente, que indica que el clúster de AKS es un destino de instalación válido
para Linkerd:
kubernetes-api
--------------
√ can initialize the client
√ can query the Kubernetes API
kubernetes-version
------------------
√ is running the minimum Kubernetes API version
√ is running the minimum kubectl version
pre-kubernetes-setup
--------------------
√ control plane namespace does not already exist
√ can create Namespaces
√ can create ClusterRoles
√ can create ClusterRoleBindings
√ can create CustomResourceDefinitions
√ can create PodSecurityPolicies
√ can create ServiceAccounts
√ can create Services
√ can create Deployments
√ can create CronJobs
√ can create ConfigMaps
√ no clock skew detected
pre-kubernetes-capability
-------------------------
√ has NET_ADMIN capability
√ has NET_RAW capability
pre-linkerd-global-resources
----------------------------
√ no ClusterRoles exist
√ no ClusterRoleBindings exist
√ no CustomResourceDefinitions exist
√ no MutatingWebhookConfigurations exist
√ no ValidatingWebhookConfigurations exist
√ no PodSecurityPolicies exist
linkerd-version
---------------
√ can determine the latest version
√ cli is up-to-date
Status check results are √
Ahora es el momento de instalar los componentes de Linkerd. Use los binarios linkerd y kubectl para instalar
los componentes de Linkerd en el clúster de AKS. Se creará automáticamente un espacio de nombres linkerd y
los componentes se instalarán en este espacio de nombres.
linkerd install | kubectl apply -f -
Linkerd implementa una serie de objetos. Verá la lista en la salida del comando linkerd install anterior. La
implementación de los componentes de Linkerd debe tardar aproximadamente un minuto en completarse, en
función del entorno del clúster.
En este punto, ya ha implementado Linkerd en el clúster de AKS. Para asegurarse de que la implementación de
Linkerd ha sido correcta, vaya a la siguiente sección para validar la instalación de Linkerd.
Validación de la instalación de Linkerd

Confirme que los recursos se han creado correctamente. Use los comandos kubectl get svc y kubectl get pod
para consultar el espacio de nombres linkerd , donde se instalaron los componentes de Linkerd con el
comando linkerd install :
kubectl get svc --namespace linkerd --output wide

kubectl get pod --namespace linkerd --output wide
En la siguiente salida de ejemplo se muestran los servicios y pods (programados en nodos de Linux) que deben
estar ejecutándose ahora:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR

linkerd-controller-api ClusterIP 10.0.110.67 <none> 8085/TCP 66s
linkerd.io/control-plane-component=controller
linkerd-destination ClusterIP 10.0.224.29 <none> 8086/TCP 66s
linkerd.io/control-plane-component=controller
linkerd-dst ClusterIP 10.0.225.148 <none> 8086/TCP 66s
linkerd.io/control-plane-component=destination
linkerd-grafana ClusterIP 10.0.61.124 <none> 3000/TCP 65s
linkerd.io/control-plane-component=grafana
linkerd-identity ClusterIP 10.0.6.104 <none> 8080/TCP 67s
linkerd.io/control-plane-component=identity
linkerd-prometheus ClusterIP 10.0.27.168 <none> 9090/TCP 65s
linkerd.io/control-plane-component=prometheus
linkerd-proxy-injector ClusterIP 10.0.100.133 <none> 443/TCP 64s
linkerd.io/control-plane-component=proxy-injector
linkerd-sp-validator ClusterIP 10.0.221.5 <none> 443/TCP 64s
linkerd.io/control-plane-component=sp-validator
linkerd-tap ClusterIP 10.0.18.14 <none> 8088/TCP,443/TCP 64s
linkerd.io/control-plane-component=tap
linkerd-web ClusterIP 10.0.37.108 <none> 8084/TCP,9994/TCP 66s
linkerd.io/control-plane-component=web

NOMINATED NODE READINESS GATES
linkerd-controller-66ddc9f94f-cm9kt 3/3 Running 0 66s 10.240.0.50 aks-linux-
16165125-vmss000001 <none> <none>
linkerd-destination-c94bc454-qpkng 2/2 Running 0 66s 10.240.0.78 aks-linux-
16165125-vmss000002 <none> <none>
linkerd-grafana-6868fdcb66-4cmq2 2/2 Running 0 65s 10.240.0.69 aks-linux-
16165125-vmss000002 <none> <none>
linkerd-identity-74d8df4b85-tqq8f 2/2 Running 0 66s 10.240.0.48 aks-linux-
16165125-vmss000001 <none> <none>
linkerd-prometheus-699587cf8-k8ghg 2/2 Running 0 65s 10.240.0.41 aks-linux-
16165125-vmss000001 <none> <none>
linkerd-proxy-injector-6556447f64-n29wr 2/2 Running 0 64s 10.240.0.32 aks-linux-
16165125-vmss000000 <none> <none>
linkerd-sp-validator-56745cd567-v4x7h 2/2 Running 0 64s 10.240.0.6 aks-linux-
16165125-vmss000000 <none> <none>
linkerd-tap-5cd9fc566-ct988 2/2 Running 0 64s 10.240.0.15 aks-linux-
16165125-vmss000000 <none> <none>
linkerd-web-774c79b6d5-dhhwf 2/2 Running 0 65s 10.240.0.70 aks-linux-
16165125-vmss000002 <none> <none>
Linkerd proporciona un comando a través del binario de cliente linkerd para validar que el plano de control de
Linkerd se ha instalado y configurado correctamente.
linkerd check
Debería ver algo parecido a lo siguiente, para indicar que la instalación se realizó correctamente:
kubernetes-api
--------------
√ can query the Kubernetes API
kubernetes-version
------------------
√ is running the minimum Kubernetes API version
√ is running the minimum kubectl version
linkerd-config
--------------
√ control plane Namespace exists
√ control plane ClusterRoles exist
√ control plane ClusterRoleBindings exist
√ control plane ServiceAccounts exist
√ control plane CustomResourceDefinitions exist
√ control plane MutatingWebhookConfigurations exist
√ control plane ValidatingWebhookConfigurations exist
√ control plane PodSecurityPolicies exist
linkerd-existence
-----------------
√ 'linkerd-config' config map exists
√ heartbeat ServiceAccount exist
√ control plane replica sets are ready
√ no unschedulable pods
√ controller pod is running
√ can query the control plane API
linkerd-api
-----------
√ control plane pods are ready
√ control plane self-check
√ [kubernetes] control plane can talk to Kubernetes
√ [prometheus] control plane can talk to Prometheus
√ no invalid service profiles
linkerd-version
---------------
√ can determine the latest version
√ cli is up-to-date
control-plane-version
---------------------
√ control plane is up-to-date
√ control plane and cli versions match
Status check results are √
Acceso al panel
Linkerd incluye un panel que proporciona información sobre la malla de servicio y las cargas de trabajo. Para
acceder al panel, use el comando linkerd dashboard . Este comando utiliza kubectl port-forward para crear una
conexión segura entre la máquina cliente y los pods correspondientes en el clúster de AKS. A continuación, abre
automáticamente el panel en el explorador predeterminado.
linkerd dashboard
El comando también crea un reenvío de puerto y devuelve un vínculo para los paneles de Grafana.
Linkerd dashboard available at:
http://127.0.0.1:50750
Grafana dashboard available at:
http://127.0.0.1:50750/grafana
Opening Linkerd dashboard in the default browser
Desinstalación de Linkerd de AKS

WARNING
La eliminación de Linkerd de un sistema en ejecución puede provocar problemas relacionados con el tráfico entre los
servicios. Antes de continuar, asegúrese de que su sistema esté bien aprovisionado para funcionar correctamente sin
Linkerd.
En primer lugar, debe quitar los proxies del plano de datos. Quite de los espacios de nombres de carga de
trabajo cualquier anotación de la inserción automática de proxies y cambie las implementaciones de carga de
trabajo. Las cargas de trabajo ya no deben tener ningún componente de plano de datos asociado.
Por último, quite el plano de control, como se indica a continuación:
linkerd install --ignore-cluster | kubectl delete -f -
Pasos siguientes
Para explorar más opciones de instalación y configuración de Linkerd, consulte las siguientes guías oficiales de
Linkerd:
Linkerd - Helm installation (Linkerd: Instalación de Helm)
Linkerd - Multi-stage installation to cater for role privileges (Linkerd: Instalación en varias fases para
mantener los privilegios de rol)
Linkerd emojivoto demo (Demostración de emojivoto de Linkerd)
Linkerd books demo (Demostración de books de Linkerd)
Consul
Consul es una solución de redes de servicio que reconoce varios centros de datos y sirve para conectar y
proteger servicios entre plataformas del entorno de ejecución. Connect es el componente que proporciona
funcionalidades de malla de servicio.
Architecture
Consul proporciona un plano de datos compuesto de forma predeterminada por sidecars basados en Envoy.
Consul tiene una arquitectura de proxy acoplable. Estos proxies inteligentes controlan todo el tráfico de red de
entrada y salida de las aplicaciones y cargas de trabajo en malla.
El plano de control administra la configuración y la directiva a través de los siguientes componentes:
Ser vidor : un agente de Consul que se ejecuta en modo de servidor y que mantiene el estado de clúster
de Consul.
Cliente : un agente de Consul que se ejecuta en modo de cliente ligero. Cada nodo de proceso debe tener
un agente cliente en ejecución. Este cliente traslada la configuración y la directiva entre las cargas de
trabajo y la configuración de Consul.
A la hora de evaluar Consul para las cargas de trabajo, es importante comprender y considerar las siguientes
áreas:
Principios de Consul
Capabilities
Escenarios
Principios de Consul
Los siguientes principios constituyen la guía del proyecto Consul:
Basado en API : debe codificar toda la configuración y la directiva.
Ejecución y conexión en cualquier lugar : debe conectar cargas de trabajo en las plataformas del
entorno de ejecución (Kubernetes, máquinas virtuales, sin servidor).
Extensión e integración : debe conectar de forma segura las cargas de trabajo en la infraestructura.
Capacidades
Consul proporciona el siguiente conjunto de funcionalidades:
Malla : puerta de enlace (varios centros de datos), máquinas virtuales (fuera de nodos del clúster),
sincronización de servicios, opción de depuración integrada
Proxies : proxy L4 de Envoy integrado, acoplable, disponible para cargas de trabajo de Windows
Administración del tráfico : enrutamiento, división, resolución
Directiva : intenciones, listas de control de acceso
Seguridad : autorización, autenticación, cifrado, identidades basadas en SPIFFE, entidad de certificación
externa (Vault), administración y rotación de certificados
Obser vabilidad : métricas, panel de interfaz de usuario, Prometheus, Grafana
Escenarios
Consul es idóneo y se sugiere para los escenarios siguientes:
Extensión de las cargas de trabajo conectadas a Consul existentes
Requisitos de cumplimiento relacionados con la administración de certificados
Malla de servicio de varios clústeres
Cargas de trabajo basadas en máquinas virtuales que se van a incluir en la malla de servicio
Pasos siguientes
En la siguiente documentación se describe cómo puede instalar Consul en Azure Kubernetes Service (AKS):
Instalación de Consul en Azure Kubernetes Service (AKS)
También puede seguir explorando las características y la arquitectura de Consul:
Tutoriales de introducción a Consul
Consul Features (Características de Consul)
Consul Architecture (Arquitectura de Consul)
Consul - How Connect Works (Consul: Funcionamiento de Connect)
Instalación y uso de Consul en Azure Kubernetes
Service (AKS)
Consul es una malla de servicio de código abierto que proporciona un conjunto clave de funcionalidades en los
microservicios de un clúster de Kubernetes. Estas características incluyen la detección y segmentación de
servicios, la comprobación de estado y la observación. Para más información sobre Consul, consulte la
documentación oficial en ¿Qué es Consul?.
En este artículo se explica cómo instalar Consul. Los componentes de Consul se instalan en un clúster de
Kubernetes en AKS.
NOTE
Estas instrucciones hacen referencia a la versión 1.6.0 de Consul y utilizan al menos la versión 2.14.2 de Helm.
Las versiones 1.6.x de Consul se pueden ejecutar en las versiones 1.13+ de Kubernetes. Puede encontrar versiones
de Consul adicionales en GitHub: versiones de Consul e información sobre cada una de las versiones en Consul: notas de
la versión.

Instalar los componentes de Consul en AKS
Validar la instalación de Consul
Desinstalar Consul de AKS
Antes de empezar
clúster. Si necesita ayuda con cualquiera de estos elementos, consulte el inicio rápido de AKS. Asegúrese de que
el clúster tiene al menos tres nodos en el grupo de nodos de Linux.
Necesitará Helm para seguir estas instrucciones e instalar Consul. Es recomendable que tenga la versión estable
más reciente correctamente instalada y configurada en el clúster. Si necesita ayuda con la instalación de Helm,
consulte las instrucciones de instalación de Helm para AKS. Todos los pods de Consul también deben
programarse para ejecutarse en nodos de Linux.
En este artículo, las instrucciones de instalación de Consul se dividen en varios pasos discretos. El resultado final
presenta la misma estructura que las instrucciones de instalación oficiales de Consul.
Instalar los componentes de Consul en AKS
Comenzaremos por descargar la versión v0.10.0 del gráfico de Helm de Consul. Esta versión del gráfico
incluye la versión 1.6.0 de Consul.
En un shell basado en Bash en Linux, en el Subsistema de Windows para Linux o en MacOS, use curl para
descargar la versión del gráfico de Helm de Consul como se indica a continuación:
# Specify the Consul Helm chart version that will be leveraged throughout these instructions
CONSUL_HELM_VERSION=0.10.0
curl -sL "https://github.com/hashicorp/consul-helm/archive/v$CONSUL_HELM_VERSION.tar.gz" | tar xz

mv consul-helm-$CONSUL_HELM_VERSION consul-helm
En un shell basado en Bash en Linux, en el Subsistema de Windows para Linux o en MacOS, use curl para
descargar la versión del gráfico de Helm de Consul como se indica a continuación:
CONSUL_HELM_VERSION=0.10.0
curl -sL "https://github.com/hashicorp/consul-helm/archive/v$CONSUL_HELM_VERSION.tar.gz" | tar xz

mv consul-helm-$CONSUL_HELM_VERSION consul-helm
En un shell basado en PowerShell en Windows, use Invoke-WebRequest para descargar la versión del gráfico
Helm de Consul y, a continuación, realice la extracción con Expand-Archive , como se indica a continuación:
$CONSUL_HELM_VERSION="0.10.0"
# Enforce TLS 1.2

$ProgressPreference = 'SilentlyContinue'; Invoke-WebRequest -URI "https://github.com/hashicorp/consul-
helm/archive/v$CONSUL_HELM_VERSION.zip" -OutFile "consul-helm-$CONSUL_HELM_VERSION.zip"
Expand-Archive -Path "consul-helm-$CONSUL_HELM_VERSION.zip" -DestinationPath .
Move-Item -Path consul-helm-$CONSUL_HELM_VERSION -Destination consul-helm
Use Helm y el gráfico consul-helm descargado para instalar los componentes de Consul en el espacio de
nombres consul del clúster de AKS.
NOTE
Opciones de instalación
Vamos a usar las siguientes opciones como parte de nuestra instalación:
connectInject.enabled=true : habilita la inserción de proxies en los pods
client.enabled=true : habilita la ejecución de los clientes de Consul en todos los nodos
client.grpc=true : habilita el cliente de escucha de gRPC para connectInject
syncCatalog.enabled=true : sincroniza los servicios de Kubernetes y Consul
Selectores de nodos
Actualmente, Consul debe programarse para su ejecución en nodos de Linux. Si tiene nodos de Windows Server en el
clúster, debe asegurarse de que los pods de Consul solo se programan para ejecutarse en nodos de Linux. Usaremos
selectores de nodo para garantizar que los pods se programan en los nodos correctos.
helm install -f consul-helm/values.yaml --name consul --namespace consul ./consul-helm \

--set connectInject.enabled=true --set connectInject.nodeSelector="beta.kubernetes.io/os: linux" \
--set client.enabled=true --set client.grpc=true --set client.nodeSelector="beta.kubernetes.io/os: linux"
\
--set server.nodeSelector="beta.kubernetes.io/os: linux" \
--set syncCatalog.enabled=true --set syncCatalog.nodeSelector="beta.kubernetes.io/os: linux"
helm install -f consul-helm/values.yaml --name consul --namespace consul ./consul-helm \
--set connectInject.enabled=true --set connectInject.nodeSelector="beta.kubernetes.io/os: linux" \
\
--set server.nodeSelector="beta.kubernetes.io/os: linux" \
helm install -f consul-helm/values.yaml --name consul --namespace consul ./consul-helm `

--set connectInject.enabled=true --set connectInject.nodeSelector="beta.kubernetes.io/os: linux" `
`
--set server.nodeSelector="beta.kubernetes.io/os: linux" `
El gráfico de Helm Consul implementa una serie de objetos. Puede ver la lista de la salida del comando
helm install anterior. La implementación de los componentes de Consul puede tardar unos tres minutos,
según el entorno del clúster.
En este punto, ya tendrá implementado Consul en su clúster de AKS. Para asegurarse de que ha implementado
correctamente Consul, vaya a la siguiente sección para validar su instalación.
Validar la instalación de Consul

Confirme que los recursos se han creado correctamente. Use los comandos kubectl get svc y kubectl get pod
para consultar el espacio de nombres consul , donde se instalaron los componentes de Consul con el comando
helm install :
kubectl get svc --namespace consul --output wide

kubectl get pod --namespace consul --output wide
En la siguiente salida de ejemplo se muestran los servicios y pods (programados en nodos de Linux) que deben
estar ejecutándose ahora:
AGE SELECTOR
consul ExternalName <none> consul.service.consul <none>
38s <none>
consul-consul-connect-injector-svc ClusterIP 10.0.98.102 <none> 443/TCP
3m26s app=consul,component=connect-injector,release=consul
consul-consul-dns ClusterIP 10.0.46.194 <none> 53/TCP,53/UDP
3m26s app=consul,hasDNS=true,release=consul
consul-consul-server ClusterIP None <none>
8500/TCP,8301/TCP,8301/UDP,8302/TCP,8302/UDP,8300/TCP,8600/TCP,8600/UDP 3m26s
app=consul,component=server,release=consul
consul-consul-ui ClusterIP 10.0.50.188 <none> 80/TCP
3m26s app=consul,component=server,release=consul
NAME READY STATUS RESTARTS AGE IP

NODE NOMINATED NODE READINESS GATES
consul-consul-connect-injector-webhook-deployment-99f74fdbcr5zj 1/1 Running 0 3m9s
10.240.0.68 aks-linux-92468653-vmss000002 <none> <none>
consul-consul-jbksc 1/1 Running 0 3m9s
consul-consul-jkwtq 1/1 Running 0 3m9s
consul-consul-server-0 1/1 Running 0 3m9s
consul-consul-sync-catalog-d846b79c-8ssr8 1/1 Running 2 3m9s
consul-consul-tz2t5 1/1 Running 0 3m9s
Todos los pods deben mostrar un estado de Running . Si los pods no tienen estos estados, espere un minuto o
dos hasta que los tengan. Si algún pod notifica un problema, use el comando kubectl describe pod para revisar
su salida y su estado.
Acceso a la interfaz de usuario de Consul

La interfaz de usuario de Consul se instaló en una operación anterior y proporciona la configuración de Consul
basada en la interfaz de usuario. La interfaz de usuario de Consul no se expone públicamente a través de una
dirección IP externa. Para acceder a la interfaz de usuario de Consul, use el comando kubectl port-forward. Este
comando crea una conexión segura el equipo cliente y el pod relevante en el clúster de AKS.
kubectl port-forward -n consul svc/consul-consul-ui 8080:80
Ahora puede abrir un explorador y hacer que apunte a http://localhost:8080/ui para abrir la interfaz de
usuario de Consul. Al abrir la interfaz de usuario, verá lo siguiente:
Desinstalar Consul de AKS
WARNING
Eliminar Consul de un sistema en ejecución puede provocar problemas relacionados con el tráfico entre sus servicios.
Asegúrese de que su sistema esté bien aprovisionado de forma que pueda funcionar correctamente sin Consul antes de
continuar.
Quitar los componentes y el espacio de nombres de Consul

Para quitar Consul del clúster de AKS, use los siguientes comandos. Los comandos helm delete quitarán el
gráfico consul y el comando kubectl delete namespace quitará el espacio de nombres consul .
helm delete --purge consul

kubectl delete namespace consul
Pasos siguientes
Para explorar más opciones de instalación y configuración de Consul, consulte los siguientes artículos oficiales:
Consul: guía de instalación de Helm
Consul: opciones de instalación de Helm
Aplicación de ejemplo de Consul
Arquitectura de referencia de Kubernetes para Consul
Puertas de enlace de malla de Consul
Implementación de aplicaciones de ASP.NET Core
en Azure Kubernetes Service con Azure DevOps
Starter
Azure DevOps Starter ofrece una experiencia simplificada en la que puede utilizar su código existente y el
repositorio de Git, o elegir una aplicación de ejemplo para crear una canalización de integración continua (CI) y
entrega continua (CD) en Azure.
DevOps Starter también:
Crea automáticamente recursos de Azure, como Azure Kubernetes Service (AKS).
Crea y configura una canalización de versión en Azure DevOps que configura una canalización de
compilación y de versión de CI/CD.
Crea un recurso de Azure Application Insights para la supervisión.
Habilita Azure Monitor para contenedores para supervisar el rendimiento de las cargas de trabajo del
contenedor en el clúster de AKS
En este tutorial, aprenderá lo siguiente:
Usar DevOps Starter para implementar una aplicación de ASP.NET Core en AKS
Configuración de Azure DevOps y una suscripción de Azure
Examen del clúster de AKS
Examen de la canalización de CI
Examen de la canalización de CD
Confirmación de los cambios en Git y su implementación automática en Azure
Prerrequisitos
Suscripción a Azure. Puede obtener una gratuita mediante Visual Studio Dev Essentials.
Usar DevOps Starter para implementar una aplicación de ASP.NET

Core en AKS
DevOps Starter crea una canalización de CI/CD en Azure Pipelines. Puede crear una organización de Azure
DevOps nueva o usar una existente. DevOps Starter también crea recursos de Azure, como un clúster de AKS, en
la suscripción de Azure que prefiera.
1. Inicie sesión en Azure Portal.
2. En el cuadro de búsqueda, escriba DevOps Star ter y, después, selecciónelo. Haga clic en Agregar para
crear un recurso.
3. Seleccione .NET y después Siguiente .
4. En Elegir un marco de trabajo de la aplicación , seleccione ASP.NET Core y, después, seleccione
Siguiente .
5. Seleccione Ser vicio de Kubernetes y, después, Siguiente .

1. Cree una organización de Azure DevOps nueva o seleccione una existente.
2. Escriba el nombre del proyecto de Azure DevOps.
3. Seleccione su suscripción a Azure.
4. Para ver más valores de configuración de Azure e identificar el número de nodos del clúster de AKS,
seleccione Cambiar . Este panel muestra varias opciones para configurar el tipo y ubicación de los
servicios de Azure.
5. Salga del área de configuración de Azure y seleccione Listo . Pocos minutos después el proceso se ha
completado. Una aplicación ASP.NET Core de ejemplo se configura en un repositorio de Git de su
organización de Azure DevOps, se crea un clúster de AKS, se ejecuta una canalización de CI/CD y la
aplicación se implementa en Azure.
Cuando todo esto finaliza, se muestra el panel de Azure DevOps Starter en Azure Portal. También puede ir
al panel de DevOps Starter directamente desde la opción Todos los recursos de Azure Portal.
Este panel proporciona visibilidad del repositorio de código de Azure DevOps, la canalización de CI/CD y
el clúster de AKS. En la canalización de Azure DevOps se pueden configurar otras opciones de CI/CD. A la
derecha, seleccione Examinar para ver la aplicación en ejecución.

DevOps Starter configura automáticamente un clúster de AKS, que puede explorar y personalizar. Para
familiarizarse con el clúster de AKS, siga estos pasos:
1. Vaya al panel de inicio de DevOps Starter.
2. A la derecha, seleccione el servicio AKS. Se abre un panel para el clúster de AKS. Desde esta vista puede
realizar varias acciones, como supervisar el mantenimiento del contenedor, buscar registros y abrir el
panel de Kubernetes.
3. A la derecha, seleccione Ver el panel de Kubernetes . Opcionalmente, siga los pasos para abrir el panel
de Kubernetes.
DevOps Starter configura automáticamente una canalización de CI/CD de Azure completa en su organización de
Azure DevOps. Puede explorar y personalizar la canalización. Para familiarizarse con ella, siga estos pasos:
1. Vaya al panel de inicio de DevOps Starter.
2. En la parte superior del panel de DevOps Starter, seleccione Compilar canalizaciones . Una pestaña del
explorador muestra la canalización de compilación del nuevo proyecto.
3. Elija el campo Estado y seleccione los puntos suspensivos (...). Un menú muestra varias opciones, como
poner en cola una nueva compilación, poner en pausa una compilación y editar la canalización de
compilación.
4. Seleccione Editar .
5. En este panel puede examinar las distintas tareas de la canalización de compilación. La compilación
ejecuta varias tareas, como capturar códigos fuente del repositorio Git, restaurar dependencias y publicar
las salidas usadas para implementaciones.
6. En la parte superior de la canalización de compilación, seleccione el nombre de esta.
7. Cambie el nombre de la canalización de compilación por otro más descriptivo, seleccione Guardar y
poner en cola y, luego, Guardar .
8. En el nombre de la canalización de compilación, seleccione Historial . Este panel muestra un registro de
auditoría de los cambios recientes de la compilación. Azure DevOps realiza un seguimiento de los
cambios realizados en la canalización de compilación y permite comparar las versiones.
9. Seleccione Desencadenadores . DevOps Starter crea automáticamente un desencadenador de
integración continua y cada confirmación al repositorio inicia una compilación. Opcionalmente, puede
elegir incluir o excluir ramas del proceso de integración continua.
10. Seleccione Retención . En función del escenario, puede especificar directivas para conservar o quitar un
determinado número de compilaciones.
Examen de la canalización de versión de la implementación continua

DevOps Starter crea y configura automáticamente los pasos necesarios para implementar desde la organización
de Azure DevOps en la suscripción de Azure. Dichos pasos incluyen la configuración de una conexión de servicio
de Azure para realizar la autenticación de Azure DevOps en la suscripción de Azure. La automatización también
crea una canalización de versión, lo que proporciona la implementación continua en Azure. Para más
información acerca de la canalización de versión, siga estos pasos:
1. Seleccione Compilación y versión y, después, Versiones . DevOps Starter crea una canalización de
versión para administrar implementaciones en Azure.
2. Seleccione los puntos suspensivos (...) que se encuentran junto a la canalización de versión, y, después,
Editar . La canalización de versión contiene una canalización, que define el proceso de lanzamiento.
3. En Ar tefactos , seleccione Colocar . La canalización de compilación que ha examinado en los pasos
anteriores genera la salida que se usa para el artefacto.
4. A la derecha del icono Colocar , seleccione Desencadenador de implementación continua . Esta
canalización de versión tiene un desencadenador de implementación continua habilitado, que ejecuta una
implementación cada vez que hay un nuevo artefacto de compilación disponible. Opcionalmente, puede
deshabilitar el desencadenador, con lo que las implementaciones van a requerir una ejecución manual.
5. A la derecha, seleccione Ver versiones para mostrar un historial de las versiones.
6. Seleccione los puntos suspensivos (...) que se encuentran junto a una de las versiones y, después, Abrir .
Puede explorar varios menús, como un resumen de las versiones, elementos de trabajo asociados y las
pruebas.
7. Seleccione Confirmaciones . Esta vista muestra las confirmaciones de código que están asociadas a esta
implementación. Compare las versiones para ver las diferencias de confirmación entre las
implementaciones.
8. Seleccione Registros . Los registros contienen información útil sobre el proceso de implementación. Se
pueden ver tanto durante las implementaciones como después de ellas.
Confirmación de los cambios en Azure Repos e implementación

automática de los mismos en Azure
NOTE
El siguiente procedimiento prueba la canalización de CI/CD. Para ello, realiza un cambio de texto simple.
A partir de ese momento ya puede empezar a colaborar con un equipo en una aplicación mediante el uso de un
proceso de CI/CD que implemente automáticamente el trabajo más reciente en su sitio web. Cada cambio que
se realiza en el repositorio de Git inicia una compilación en Azure DevOps y una canalización de CD ejecuta una
implementación en Azure. Siga el procedimiento descrito en esta sección o utilice otra técnica para confirmar los
cambios en el repositorio. Por ejemplo, puede clonar el repositorio de Git en su herramienta favorita o IDE, y
luego insertar los cambios en este repositorio.
1. En el menú de Azure DevOps, seleccione Código > Archivos y, a continuación, vaya al repositorio.
2. Vaya al directorio Views\Home, seleccione los puntos suspensivos (...) que hay junto al archivo
Index.cshtml y seleccione Editar .
3. Realice un cambio en el archivo, como agregar texto dentro de una de las etiquetas div.
4. En la parte superior derecha, seleccione Confirmar y, después, seleccione Confirmar de nuevo para
insertar el cambio. Tras unos instantes, se inicia una compilación se inicia en Azure DevOps y se ejecuta
una versión para implementar los cambios. Supervise el estado de la compilación en el panel de DevOps
Starter o en el explorador con la organización de Azure DevOps.
5. Una vez que complete la versión, actualice la aplicación para comprobar los cambios.
Si va a realizar pruebas, limpie los recursos para que no se acumulen costos de facturación. Cuando dejen de ser
necesarios, puede eliminar el clúster de AKS y los recursos relacionados que ha creado en este tutorial. Para ello,
utilice la funcionalidad de eliminación del panel de DevOps Starter.
IMPORTANT
El siguiente procedimiento elimina permanentemente los recursos. La funcionalidad de Eliminación destruye los datos que
crea el proyecto en DevOps Starter tanto en Azure como en Azure DevOps y no se podrán recuperar. Utilice este
procedimiento cuando haya leído detenidamente las indicaciones.
1. En Azure Portal, vaya al panel de DevOps Starter.
2. En la parte superior derecha, seleccione Eliminar .
3. En el mensaje, seleccione Sí para eliminar permanentemente los recursos.
Pasos siguientes
Si lo desea, puede modificar estas canalizaciones de compilación y de versión para satisfacer las necesidades de
su equipo. También puede usar este patrón de CI/CD como plantilla para las demás canalizaciones. En este
tutorial, ha aprendido a:
Usar DevOps Starter para implementar una aplicación de ASP.NET Core en AKS
Confirmación de los cambios en Git y su implementación automática en Azure
Para más información acerca del uso del panel de Kubernetes, consulte:
Centro de implementación para Azure Kubernetes
En Azure DevOps, el centro de implementación simplifica la configuración de una canalización de

implementación sólida de Azure DevOps para su aplicación. De forma predeterminada, el centro de
implementación configura una canalización de Azure DevOps para implementar las actualizaciones de la
aplicación en el clúster de Kubernetes. Puede extender la canalización de Azure DevOps configurada
predeterminada y agregar funcionalidades más enriquecidas: la capacidad de conseguir la aprobación previa a
la implementación, el aprovisionamiento de recursos de Azure adicionales, la ejecución de scripts, la
actualización de la aplicación o incluso la ejecución de pruebas de validación adicionales.
En este tutorial, aprenderá lo siguiente:
Configure una canalización de Azure DevOps para implementar las actualizaciones de la aplicación en el
clúster de Kubernetes.
Examine la canalización de integración continua (CI).
Examine la canalización de entrega continua (CD).
Limpie los recursos.
Prerrequisitos
Suscripción a Azure. Puede obtener una gratuita mediante Visual Studio Dev Essentials.
Un clúster de Azure Kubernetes Service (AKS).

1. Inicie sesión en Azure Portal.
2. Seleccione la opción Cloud Shell en la barra de menús derecha de Azure Portal.
3. Para crear el clúster de AKS, ejecute los siguientes comandos:
# Create a resource group in the South India location:
az group create --name azooaks --location southindia
# Create a cluster named azookubectl with one node.
az aks create --resource-group azooaks --name azookubectl --node-count 1 --enable-addons monitoring -

-generate-ssh-keys
Implementación de actualizaciones de la aplicación en un clúster de

Kubernetes
1. Vaya al grupo de recursos que creó en la sección anterior.
2. Seleccione el clúster de AKS y Centro de implementación (versión preliminar) en la hoja de la
izquierda. Seleccione Comenzar .
3. Elija la ubicación del código y seleccione Siguiente . A continuación, seleccione uno de los repositorios
admitidos actualmente: Azure Repos o GitHub .
Azure Repos es un conjunto de herramientas de control de versiones que ayuda a administrar el código.
Independientemente de que el proyecto de software sea grande o pequeño, se recomienda usar el
control de versiones lo antes posible.
Azure Repos : elija un repositorio en el proyecto y la organización existentes.
GitHub : Autorice y seleccione el repositorio para su cuenta de GitHub.

4. El centro de implementación analiza el repositorio y detecta el Dockerfile. Si desea actualizarlo, puede
editar el número de puerto identificado.
Si el repositorio no contiene el Dockerfile, el sistema mostrará un mensaje para confirmar uno.
5. Seleccione un registro de contenedor existente o cree uno y, a continuación, seleccione Finalizar . La

canalización se crea automáticamente y pone en cola una compilación en Azure Pipelines.
Azure Pipelines es un servicio en la nube que puede usar para compilar y probar automáticamente el
proyecto del código y hacer que esté disponible para otros usuarios. Azure Pipelines combina la
integración continua y la entrega continua para probar y compilar el código de forma constante y
coherente, y enviarlo a cualquier destino.
6. Seleccione el vínculo para ver la canalización en curso.

7. Verá los registros correctos una vez que la implementación se haya completado.
El centro de implementación configura automáticamente la canalización de CI/CD de su organización de Azure
DevOps. Dicha canalización se puede explorar y personalizar.
1. Vaya al panel del centro de implementación.
2. Seleccione el número de compilación de la lista de registros correctos para ver la canalización de
compilación del proyecto.
3. Seleccione los puntos suspensivos (...) en la esquina superior derecha. Un menú muestra varias opciones,
como poner en cola una nueva compilación, conservar una compilación y editar la canalización de
compilación. Seleccione Editar canalización .
4. En este panel puede examinar las distintas tareas de la canalización de compilación. La compilación
realiza varias tareas, como recopilar los orígenes del repositorio de Git, crear una imagen, insertar una
imagen en el registro de contenedor y publicar los resultados que se usan para las implementaciones.
5. Seleccione el nombre de la canalización de compilación en la parte superior de esta.
6. Cambie el nombre de la canalización de compilación por otro más descriptivo, seleccione Guardar y
poner en cola y, luego, seleccione Guardar .
7. Seleccione Historial en la canalización de compilación. En este panel se muestra una pista de auditoría
de los últimos cambios en la compilación. Azure DevOps supervisa todos los cambios realizados en la
canalización de compilación y permite comparar las versiones.
8. Seleccione Desencadenadores . Puede elegir incluir o excluir ramas del proceso de CI.
9. Seleccione Retención . Puede especificar directivas para conservar o quitar un número determinado de
compilaciones en función del escenario.
El centro de implementación crea y configura automáticamente la relación entre su organización de Azure
DevOps y la suscripción de Azure. Esto incluye la configuración de una conexión de servicio de Azure para
realizar la autenticación en su suscripción a Azure con Azure DevOps. El proceso automatizado también crea una
canalización de versión de entrega continua a Azure.
1. Seleccione Canalizaciones y Versiones .
2. Para editar la canalización de versión, seleccione Editar .
3. Seleccione Anular en la lista Ar tifacts . En los pasos anteriores, la canalización de la construcción que ha
examinado genera la salida que se usa para el artefacto.
4. Seleccione el desencadenador Implementación continua a la derecha de la opción Anular . Esta
canalización de versión tiene un desencadenador de implementación continua habilitado que ejecuta una
implementación cuando hay un nuevo artefacto de compilación disponible. También puede deshabilitar
el desencadenador para exigir la ejecución manual de sus implementaciones.
5. Para examinar todas las tareas de la canalización, seleccione Tareas . La versión establece el entorno de
Tiller, configura el parámetro imagePullSecrets , instala las herramientas de Helm e implementa los
gráficos de Helm en el clúster de Kubernetes.
6. Para ver el historial de versiones, seleccione Ver versiones .
7. Para ver el resumen, seleccione Versión . Seleccione cualquiera de las fases para explorar varios menús,
como un resumen de las versiones, los elementos de trabajo asociados y las pruebas.
8. Seleccione Confirmaciones . Esta vista muestra las confirmaciones de código relacionadas con esta
implementación. Compare las versiones para ver las diferencias de confirmación entre las
implementaciones.
9. Seleccione Registros . Los registros contienen información de implementación útil que puede ver
durante las implementaciones y después de estas.
Cuando no necesite los recursos relacionados que haya creado puede eliminarlos. Use la funcionalidad de
eliminación del panel de DevOps Projects.
Pasos siguientes
Puede modificar estas canalizaciones de compilación y de versión para satisfacer las necesidades de su equipo.
O también puede usar este modelo de CI/CD como plantilla para las demás canalizaciones.
Acciones de GitHub para la implementación en el
servicio Kubernetes
Acciones de GitHub le ofrece la flexibilidad de compilar un flujo de trabajo del ciclo de vida de desarrollo de
software automatizado. Puede usar varias acciones de Kubernetes para realizar implementaciones en
contenedores desde el Azure Container Registry al servicio de Azure Kubernetes con Acciones de GitHub.
Prerrequisitos
Una cuenta de Azure con una suscripción activa. Cree una cuenta gratuita.
Una cuenta de GitHub. Si no tiene ninguna, regístrese gratis.
Un clúster de Kubernetes en funcionamiento
Tutorial: Preparación de una aplicación para Azure Kubernetes Service
Información general sobre el archivo de flujo de trabajo

Un archivo YAML (.yml) define un flujo de trabajo en la ruta de acceso /.github/workflows/ de su repositorio. En
esta definición se incluyen los diversos pasos y parámetros que componen el flujo de trabajo.
Para un flujo de trabajo que tiene como destino AKS, el archivo tiene tres secciones:
SEC C IÓ N TA REA S
Autenticación Inicio de sesión en un registro de contenedor privado (ACR)
Compilar Compilación e inserción de la imagen de contenedor en el

registro
Implementación 1. Establezca el clúster de AKS de destino
2. Cree un secreto genérico o del registro de Docker en el

3. Implemente el clúster de Kubernetes

Puede crear una entidad de servicio mediante el comando az ad sp create-for-rbac de la CLI de Azure. Puede
ejecutar este comando mediante Azure Cloud Shell en Azure Portal o seleccionando el botón Pruébelo .
az ad sp create-for-rbac --name "myApp" --role contributor --scopes

/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP> --sdk-auth
En el comando anterior, reemplace los marcadores de posición por el identificador de la suscripción y el grupo
de recursos. La salida son las credenciales de asignación de roles que proporcionan acceso a su aplicación. El
comando debe generar un objeto JSON similar a este.
{
"clientId": "<GUID>",
"clientSecret": "<GUID>",
"subscriptionId": "<GUID>",
"tenantId": "<GUID>",
(...)
}
Copie este objeto JSON, el cual puede usar para autenticarse desde GitHub.
Configuración de los secretos de GitHub

Siga los pasos para configurar los secretos:
1. En GitHub, examine el repositorio y seleccione Configuración > Secretos > Agregar un nuevo
secreto .
2. Pegue el contenido del comando az cli anterior como valor de la variable secreta. Por ejemplo,
AZURE_CREDENTIALS .
3. Del mismo modo, defina los siguientes secretos adicionales para las credenciales del registro de
contenedor y establézcalos en la acción de inicio de sesión de Docker.
REGISTRY_USERNAME
REGISTRY_PASSWORD
4. Verá los secretos como se muestran a continuación una vez definidos.
Creación de una imagen de contenedor e implementación en el
clúster de Azure Kubernetes Service
La compilación y la extracción de las imágenes de contenedor se realizan mediante la acción
Azure/docker-login@v1 .
env:
REGISTRY_NAME: {registry-name}
CLUSTER_NAME: {cluster-name}
CLUSTER_RESOURCE_GROUP: {resource-group-name}
NAMESPACE: {namespace-name}
APP_NAME: {app-name}
jobs:
build:
steps:
- uses: actions/checkout@main
# Connect to Azure Container Registry (ACR)

- uses: azure/docker-login@v1
with:
login-server: ${{ env.REGISTRY_NAME }}.azurecr.io
username: ${{ secrets.REGISTRY_USERNAME }}
password: ${{ secrets.REGISTRY_PASSWORD }}
# Container build and push to a Azure Container Registry (ACR)

- run: |
docker build . -t ${{ env.REGISTRY_NAME }}.azurecr.io/${{ env.APP_NAME }}:${{ github.sha }}
docker push ${{ env.REGISTRY_NAME }}.azurecr.io/${{ env.APP_NAME }}:${{ github.sha }}
Implementación en un clúster de Azure Kubernetes Service

Para implementar una imagen de contenedor en AKS, debe usar la acción Azure/k8s-deploy@v1 . Esta acción tiene
cinco parámetros:
PA RÁ M ET RO EXP L IC A C IÓ N
namespace (Opcional) Elija el espacio de nombres de Kubernetes de

destino. Si no se proporciona el espacio de nombres, los
comandos se ejecutarán en el espacio de nombres
predeterminado.
PA RÁ M ET RO EXP L IC A C IÓ N
manifests (Obligatorio) Ruta de acceso a los archivos de manifiesto que

se usará para la implementación.
images (Obligatorio) Dirección URL completa de recursos de las

imágenes que se van a usar para sustituciones sobre los
archivos de manifiesto.
imagepullsecrets (Opcional) Nombre de un secreto del registro de Docker que

ya se ha configurado dentro del clúster. Cada uno de estos
nombres de secreto se agrega en el campo imagePullSecrets
para las cargas de trabajo que se encuentran en los archivos
de manifiesto de entrada.
kubectl-version (Opcional) Instala una versión específica del archivo binario

kubectl.
NOTE
El usuario debe crear manualmente los archivos de manifiesto. Actualmente no hay herramientas que generen estos
archivos de forma automatizada. Para obtener más información, consulte este repositorio de ejemplo con archivos de
manifiesto de ejemplo.
Antes de que pueda realizar la implementación en AKS, debe establecer el espacio de nombres de Kubernetes de
destino y crear un secreto de extracción de imagen. Consulte Extracción de imágenes de Azure Container
Registry a un clúster de Kubernetes para obtener más información sobre cómo funciona la extracción de
imágenes.
# Create namespace if doesn't exist

- run: |
kubectl create namespace ${{ env.NAMESPACE }} --dry-run -o json | kubectl apply -f -
# Create image pull secret for ACR

- uses: azure/k8s-create-secret@v1
with:
container-registry-url: ${{ env.REGISTRY_NAME }}.azurecr.io
container-registry-username: ${{ secrets.REGISTRY_USERNAME }}
container-registry-password: ${{ secrets.REGISTRY_PASSWORD }}
secret-name: ${{ env.SECRET }}
namespace: ${{ env.NAMESPACE }}
arguments: --force true
Complete la implementación con la acción k8s-deploy . Reemplace las variables de entorno por los valores para
su aplicación.
on: [push]
# Environment variables available to all jobs and steps in this workflow

env:
REGISTRY_NAME: {registry-name}
CLUSTER_NAME: {cluster-name}
CLUSTER_RESOURCE_GROUP: {resource-group-name}
NAMESPACE: {namespace-name}
SECRET: {secret-name}
APP_NAME: {app-name}
jobs:
build:
steps:
- uses: actions/checkout@main
# Connect to Azure Container Registry (ACR)

- uses: azure/docker-login@v1
with:
login-server: ${{ env.REGISTRY_NAME }}.azurecr.io
username: ${{ secrets.REGISTRY_USERNAME }}
password: ${{ secrets.REGISTRY_PASSWORD }}
# Container build and push to a Azure Container Registry (ACR)

- run: |
docker build . -t ${{ env.REGISTRY_NAME }}.azurecr.io/${{ env.APP_NAME }}:${{ github.sha }}
docker push ${{ env.REGISTRY_NAME }}.azurecr.io/${{ env.APP_NAME }}:${{ github.sha }}
# Set the target Azure Kubernetes Service (AKS) cluster.

- uses: azure/aks-set-context@v1
with:
creds: '${{ secrets.AZURE_CREDENTIALS }}'
cluster-name: ${{ env.CLUSTER_NAME }}
resource-group: ${{ env.CLUSTER_RESOURCE_GROUP }}
# Create namespace if doesn't exist

- run: |
kubectl create namespace ${{ env.NAMESPACE }} --dry-run -o json | kubectl apply -f -
# Create image pull secret for ACR

- uses: azure/k8s-create-secret@v1
with:
container-registry-url: ${{ env.REGISTRY_NAME }}.azurecr.io
container-registry-username: ${{ secrets.REGISTRY_USERNAME }}
container-registry-password: ${{ secrets.REGISTRY_PASSWORD }}
secret-name: ${{ env.SECRET }}
force: true
# Deploy app to AKS

- uses: azure/k8s-deploy@v1
with:
manifests: |
manifests/deployment.yml
manifests/service.yml
images: |
${{ env.REGISTRY_NAME }}.azurecr.io/${{ env.APP_NAME }}:${{ github.sha }}
imagepullsecrets: |
${{ env.SECRET }}
Cuando el clúster de Kubernetes, el registro de contenedor y el repositorio ya no sean necesarios, limpie los
recursos que implementó eliminando el grupo de recursos y el repositorio de GitHub.
Pasos siguientes
Obtenga más información acerca de Azure Kubernetes Service
Aprenda a crear varias canalizaciones en Acciones de GitHub con AKS
Más Acciones de GitHub para Kubernetes
Instalador de la herramienta Kubectl ( azure/setup-kubectl ): instale una versión específica de kubectl en el
ejecutor.
Establecimiento del contexto en Kubernetes ( azure/k8s-set-context ): establezca el contexto del clúster de
Kubernetes de destino que usarán otras acciones o ejecute cualquier comando de kubectl.
Establecimiento del contexto en AKS ( azure/aks-set-context ): establezca el contexto del clúster de Azure
Kubernetes Service de destino.
Creación de secretos en Kubernetes ( azure/k8s-create-secret ): cree un secreto genérico o un secreto del
registro de Docker en el clúster de Kubernetes.
Implementación en Kubernetes ( azure/k8s-deploy ): incorpore e implemente manifiestos en clústeres de
Kubernetes.
Configuración de Helm ( azure/setup-helm ): instale una versión específica del archivo binario de Helm en el
ejecutor.
Simulación mediante "bake" en Kubernetes ( azure/k8s-bake ): archivo de manifiesto mediante "bake" que se
va a usar para las implementaciones con helm2, kustomize o kompose.
Acción "lint" de Kubernetes ( azure/k8s-lint ): valide/busque errores en los archivos de manifiesto.
Solución de problemas de AKS
Al crear o administrar clústeres de Azure Kubernetes Service (AKS), en ocasiones pueden surgir problemas. En
este artículo se detallan algunos problemas comunes y los pasos para solucionarlos.
En general, ¿dónde puedo encontrar información sobre la depuración

de problemas de Kubernetes?
Pruebe la guía oficial para la solución de problemas de clústeres de Kubernetes. Además, existe una guía para la
solución de problemas publicada por un ingeniero de Microsoft en torno a la solución de problemas de pods,
nodos, clústeres y otras características.
Recibo el error quota exceeded durante la creación o actualización.

¿Cuál debo hacer?
Solicitar más núcleos.
Recibo el error insufficientSubnetSize al implementar un clúster de

AKS con redes avanzadas. ¿Cuál debo hacer?
Este error indica que una subred en uso para un clúster ya no tiene direcciones IP disponibles dentro de su CIDR
para una correcta asignación de recursos. En el caso de los clústeres de Kubenet, el requisito es un espacio de IP
suficiente para cada nodo del clúster. En el caso de los clústeres de Azure CNI, el requisito es un espacio de IP
suficiente para cada nodo y pod del clúster. Obtenga más información sobre el diseño de Azure CNI para asignar
direcciones IP a pods.
Estos errores también aparecen en Diagnósticos de AKS, que muestra problemas de manera proactiva, como un
tamaño de subred insuficiente.
Los siguientes tres (3) casos provocan un error de tamaño de subred insuficiente:
1. Escala de AKS o escala del grupo de nodos de AKS
a. Si usa Kubenet, cuando el number of free IPs in the subnet es menor que el
number of new nodes requested .
b. Si usa Azure CNI, cuando el number of free IPs in the subnetes menor que el
number of nodes requested times (*) the node pool's --max-pod value .
2. Actualización de AKS o actualización del grupo de nodos de AKS

number of buffer nodes needed to upgrade .
b. Si usa Azure CNI, cuando el number of free IPs in the subnet es menor que el
number of buffer nodes needed to upgrade times (*) the node pool's --max-pod value .
De forma predeterminada, los clústeres de AKS establecen un valor de sobrecarga máxima (búfer de
actualización) de uno (1), pero este comportamiento de actualización se puede personalizar si se
establece el [valor de sobrecarga máxima de un grupo de nodos], que aumentará el número de
direcciones IP disponibles necesarias para completar una actualización.
3. Creación de AKS o incorporación del grupo de nodos de AKS
number of nodes requested for the node pool .
b. Si usa Azure CNI, cuando el number of free IPs in the subnet es menor que el
number of nodes requested times (*) the node pool's --max-pod value .
La siguiente mitigación se puede llevar a cabo mediante la creación de nuevas subredes. El permiso para crear
una nueva subred es necesario para la mitigación debido a la incapacidad de actualizar el rango de CIDR de una
subred existente.
1. Vuelva a generar una nueva subred con un rango de CIDR mayor que sea suficiente para los objetivos de la
operación:
a. Cree una nueva subred con un nuevo rango deseado que no se superponga.
b. Cree un nuevo grupo de nodos en la nueva subred.
c. Vacíe los pods del grupo de nodos antiguo que reside en la subred antigua que se va a reemplazar.
d. Elimine la antigua subred y el antiguo grupo de nodos.
Mi pod se ha atascado en el modo CrashLoopBackOff. ¿Cuál debo

hacer?
Puede haber varios motivos para que el pod se quede atascado en ese modo. Algunas soluciones posibles son:
El propio pod, mediante el comando kubectl describe pod <pod-name> .
Los registros, mediante el uso de kubectl logs <pod-name> .
Para obtener más información sobre cómo solucionar problemas de los pods, consulte cómo depurar
aplicaciones.
Recibo TCP timeouts al usar kubectl u otras herramientas de terceros

que se conectan al servidor de API
AKS tiene planos de control de alta disponibilidad que se escalan verticalmente según el número de núcleos
para garantizar los objetivos de nivel de servicio (SLO) y los acuerdos de nivel de servicio (SLA). Si se agota el
tiempo de espera de las conexiones, compruebe lo siguiente:
¿Se agota el tiempo de espera de todos los comandos de la API de manera uniforme o solo
unos pocos? Si solo sucede con unos pocos, el pod tunnelfront o el pod aks-link , responsables de la
comunicación del nodo al plano de control, puede que no estén en estado de ejecución. Asegúrese de que los
nodos que hospeden este pod no se usen de manera excesiva ni están bajo estrés. Piense en la posibilidad de
moverlos a su propio grupo de nodos del system .
¿Ha abier to todos los puer tos, FQDN y direcciones IP necesarios indicados en la
documentación de control del tráfico de salida de AKS ? De lo contrario, se pueden producir errores
en varias llamadas a comandos.
¿La dirección IP actual está incluida en los inter valos de IP autorizados de la API ? Si utiliza esta
característica y la dirección IP no está incluida en los intervalos, se bloquearán las llamadas.
¿Tiene un cliente o aplicación con fuga de llamadas al ser vidor de la API? Asegúrese de usar
inspecciones en lugar de llamadas get frecuentes, y de que las aplicaciones de terceros no estén perdiendo
dichas llamadas. Por ejemplo, un error en Mixer de Istio hace que se cree una nueva conexión de inspección
del servidor de la API cada vez que un secreto se lee internamente. Dado que este comportamiento se
produce a intervalos regulares, las conexiones de inspección se acumulan rápidamente y, finalmente, hacen
que el servidor de la API se sobrecargue sin importar el patrón de escalado.
https://github.com/istio/istio/issues/19481
¿Tiene muchas versiones en las implementaciones de Helm? En este escenario se puede hacer que
Tiller use demasiada memoria en los nodos, así como una gran cantidad de configmaps , lo que puede
provocar picos innecesarios en el servidor de la API. Considere la posibilidad de configurar --history-max en
helm init y aprovechar el nuevo Helm 3. Más información sobre los temas siguientes:
https://github.com/helm/helm/issues/4821
¿Se está bloqueando el tráfico interno entre los nodos?
Estoy recibiendo TCP timeouts , como

dial tcp <Node_IP>:10250: i/o timeout
Estos tiempos de espera pueden estar relacionados con el bloqueo del tráfico interno entre los nodos.
Compruebe que no se está bloqueando este tráfico, por ejemplo mediante grupos de seguridad de red en la
subred de los nodos del clúster.
Estoy intentando habilitar el control de acceso basado en rol de

Kubernetes (RBAC de Kubernetes) en un clúster existente. ¿Cómo
puedo hacerlo?
En este momento no se admite la habilitación del control de acceso basado en rol de Kubernetes (RBAC de
Kubernetes) en clústeres existentes; se debe configurar al crear los clústeres. RBAC de Kubernetes está habilitado
de manera predeterminada cuando se usa la CLI, el portal o una versión de API posterior a la 2020-03-01 .
No logro obtener los registros mediante kubectl logs ni puedo

conectarme al servidor de API. Recibo el mensaje "Error de servidor:
error de marcado al back-end: marcar tcp…" ¿Cuál debo hacer?
Asegúrese de que los puertos 22, 9000 y 1194 están abiertos para conectarse al servidor de la API. Compruebe
si el pod tunnelfront o aks-link se ejecutan en el espacio de nombres kube-system mediante el comando
kubectl get pods --namespace kube-system . Si no se está ejecutando, debe forzar la eliminación del pod y se
reiniciará.
Recibo "tls: client offered only unsupported versions" de mi cliente

al conectarse a la API de AKS. ¿Cuál debo hacer?
La versión de TLS mínima admitida en AKS es TLS 1.2.
Estoy intentando actualizar o escalar y recibo el error

"Changing property 'imageReference' is not allowed" . ¿Cómo se corrige
este problema?
Es posible que reciba este error porque se han modificado las etiquetas de los nodos de agente dentro del
clúster de AKS. Modificar y eliminar etiquetas y otras propiedades de recursos en el grupo de recursos MC_*
puede provocar resultados inesperados. La modificación de los recursos en el grupo MC_* en el clúster de AKS
invalida el objetivo de nivel de servicio (SLO).
Recibo errores que indican que mi clúster presenta errores y que la
actualización o el escalado no funcionarán hasta que se corrija.
Esta ayuda para solucionar problemas se dirige desde https://aka.ms/aks-cluster-failed
Este error aparece cuando los clústeres entran en un estado con errores por diversos motivos. Siga los pasos
que aparecen a continuación para solucionar el estado con errores del clúster antes de reintentar la operación
con errores anterior:
1. Hasta que el clúster deje de tener el estado failed , las operaciones upgrade y scale no se realizarán
correctamente. Los problemas y resoluciones raíz comunes incluyen:
Escalado con una cuota de proceso insuficiente (CRP) . Para solucionarlo, primero debe escalar el
clúster de vuelta a un estado objetivo estable dentro de la cuota. Luego, siga estos pasos para solicitar
un aumento de cuota de proceso antes de intentar volver a escalar verticalmente más allá de los
límites de cuota iniciales.
Escalar un clúster con redes avanzadas y recursos de subred (redes) insuficientes . Para
solucionarlo, primero debe escalar el clúster de vuelta a un estado objetivo estable dentro de la cuota.
Luego, siga estos pasos para solicitar un aumento de cuota de recursos antes de intentar volver a
escalar verticalmente más allá de los límites de cuota iniciales.
2. Una vez que se resuelve la causa subyacente de un error de actualización, el clúster debería tener un estado
correcto. Una vez que compruebe el estado correcto, vuelva a intentar la operación original.
Recibo errores cuando intento actualizar o escalar que indican que el

clúster se está actualizando o que hay un error de actualización.
Esta ayuda para solucionar problemas se dirige desde https://aka.ms/aks-pending-upgrade
No puede tener un grupo de clústeres o de nodos actualizados y escalados a la vez. En su lugar, cada tipo de
operación debe completarse en el recurso de destino antes de la siguiente solicitud en ese mismo recurso.
Como resultado, las operaciones se ven limitadas cuando tienen lugar o se han intentado operaciones de
actualización o de escala.
Para ayudar a diagnosticar el problema, ejecute az aks show -g myResourceGroup -n myAKSCluster -o table para
recuperar el estado detallado del clúster. En función del resultado:
Si el clúster se está actualizando, espere hasta que termine la operación. Si se realizó correctamente, vuelva a
intentar realizar la operación que presentó errores.
Si el clúster no se pudo actualizar, siga los pasos descritos en la sección anterior.
¿Puedo mover el clúster a otra suscripción o mi suscripción con mi

clúster a un inquilino nuevo?
Si ha migrado el clúster de AKS a otra suscripción o la suscripción del clúster a un nuevo inquilino, el clúster no
funcionará porque faltan permisos de identidad del clúster. Debido a esta restricción, AKS no admite la
migración de clústeres entre suscripciones o inquilinos .
Recibos errores cuando intento usar características que requieren

conjuntos de escalado de máquinas virtuales.
Esta ayuda para solucionar problemas se dirige desde aka.ms/aks-vmss-enablement
Puede recibir errores que indiquen que el clúster de AKS no se encuentra en un conjunto de escalado de
máquinas virtuales, como en el ejemplo siguiente:
El grupo de agentes agentpool <agentpoolname> definió el escalado automático como habilitado, pero
no se encuentra en Vir tual Machine Scale Sets .
Para usar características como el escalador automático de clústeres o varios grupos de nodos, el valor de
vm-set-type deben ser los conjuntos de escalado de máquinas virtuales.
Siga los pasos de Antes de empezar del documento adecuado para crear correctamente un clúster de AKS:
Uso del escalador automático del clúster.
Creación y uso de varios grupos de nodos.
¿Qué restricciones de nomenclatura se aplican para los parámetros y

recursos de AKS?
Esta ayuda para solucionar problemas se dirige desde aka.ms/aks-naming-rules
Tanto AKS como la plataforma de Azure implementan las restricciones de nomenclatura. Si un parámetro o
nombre de recurso infringe una de estas restricciones, se devuelve un error en el que se le pide brindar otra
entrada. Se aplican estas directrices de nomenclatura comunes:
Los nombres de clúster deben tener entre 1 y 63 caracteres. Los únicos caracteres permitidos son letras,
números, guiones y guiones bajos. El primer y el último carácter deben ser una letra o un número.
El nombre del grupo de recursos MC_ o del nodo de AKS combina el nombre del grupo de recursos y el
nombre del recurso. La sintaxis generada automáticamente de
MC_resourceGroupName_resourceName_AzureRegion no puede tener más de 80 caracteres. Si es necesario,
disminuya la longitud del nombre del grupo de recursos o del nombre del clúster de AKS. También puede
personalizar el nombre del grupo de recursos del nodo.
dnsPrefix debe empezar y terminar con valores alfanuméricos, y debe tener entre 1 y 54 caracteres. Los
caracteres válidos incluyen valores alfanuméricos y guiones (-). dnsPrefix no puede incluir caracteres
especiales, como un punto (.).
Los nombres de grupo del nodo de AKS deben estar en minúsculas y tener entre 1 y 11 caracteres, en el caso
de grupos de nodos de Linux, y entre 1 y 6 caracteres si son grupos de nodos de Windows. El nombre debe
empezar por una letra y los únicos caracteres permitidos son letras y números.
El admin-username, que establece el nombre de usuario de administrador para los nodos de Linux, debe
empezar con una letra, solo puede contener letras, números, guiones y caracteres de subrayado, y tiene una
longitud máxima de 64 caracteres.
Recibo errores cuando intento crear, actualizar, escalar, eliminar o

actualizar un clúster, donde se indica que no se permite la operación
porque hay otra en curso.
Esta ayuda para solucionar problemas se dirige desde aka.ms/aks-pending-operation
Las operaciones del clúster se limitan cuando todavía hay en curso una operación anterior. Para recuperar un
estado detallado del clúster, use el comando az aks show -g myResourceGroup -n myAKSCluster -o table . Use el
nombre de su propio clúster de AKS y de su propio grupo de recursos, en caso de ser necesario.
En función de la salida del estado del clúster:
Si el clúster está en cualquier estado de aprovisionamiento distinto de Succeeded (Correcto) o Failed (Con
errores), espere a que se termine la operación (actualización/creación/escalado/eliminación/migración).
Cuando termine la operación anterior, vuelva a intentar la operación más reciente del clúster.
Si el clúster presenta errores de actualización, siga los pasos que se describen en Recibo errores que
indican que mi clúster presenta errores y que la actualización o el escalado no funcionarán hasta que se
corrija.
Al intentar crear un clúster, ha recibido un error que indica que la

entidad de servicio no se encontró o no es válida.
Al crear un clúster de AKS, se requiere una entidad de servicio o una identidad administrada para crear recursos
en su nombre. AKS puede crear automáticamente una entidad de servicio en el momento de la creación del
clúster o recibir una existente. Cuando se usa una creada automáticamente, Azure Active Directory tiene que
propagarla a todas las regiones para que la creación se realice correctamente. Si esta propagación tarda
demasiado, se producirá un error al validar la creación del clúster, ya que no puede encontrar ninguna entidad
de servicio disponible para hacerlo.
Para resolver este problema, use las siguientes soluciones alternativas:
Use una entidad de servicio existente que ya se haya propagado entre distintas regiones para pasarla a AKS
en el momento de la creación del clúster.
Si se usan scripts de automatización, agregue demoras entre la creación de la entidad de servicio y la
creación del clúster de AKS.
Si se usa Azure Portal, vuelva a la configuración del clúster durante la creación y reintente la página de
validación pocos minutos después.
Recibo "AADSTS7000215: Invalid client secret is provided." al usar la

API de AKS. ¿Qué debo hacer?
Este problema se debe a la expiración de las credenciales de la entidad de servicio. Actualice las credenciales de
un clúster de AKS.
No puedo acceder a mi API del clúster desde mi sistema de

automatización/máquina de desarrollo/herramientas al usar intervalo
IP autorizados por el servidor de API. ¿Cómo se corrige este
problema?
Para resolver este problema, asegúrese de que --api-server-authorized-ip-ranges incluya las direcciones IP o
los intervalos IP de los sistemas de automatización, desarrollo y herramientas que se están usando. Consulte la
sección "Cómo encontrar mi dirección IP" en Protección del acceso al servidor de API con intervalos de
direcciones IP autorizadas.
No puedo ver los recursos en el visor de recursos de Kubernetes de

Azure Portal para el clúster configurado con intervalos IP autorizados
por el servidor de API. ¿Cómo se corrige este problema?
El visor de recursos de Kubernetes requiere que --api-server-authorized-ip-ranges incluya acceso para el
equipo cliente local o el intervalo de direcciones IP (desde donde se navega el portal). Consulte la sección
"Cómo encontrar mi dirección IP" en Protección del acceso al servidor de API con intervalos de direcciones IP
autorizadas.
Recibo errores después de restringir el tráfico de salida

Cuando se restringe el tráfico de salida desde un clúster de AKS, hay puerto de salida / reglas de red y reglas de
aplicación /FQDN requeridos y recomendados opcionales para AKS. Si la configuración entra en conflicto con
alguna de estas reglas, es posible que algunos comandos kubectl no funcionen correctamente. También puede
ver errores al crear un clúster de AKS.
Compruebe que la configuración no esté en conflicto con ninguno de los puertos de salida, reglas de red ni
reglas de aplicación o FQDN requeridos o recomendados opcionales.
Recibo el error "429: Demasiadas solicitudes"

Cuando un clúster de Kubernetes en Azure (AKS o no) escala o reduce verticalmente con frecuencia o usa la
herramienta de escalabilidad automática de clúster (CA), esas operaciones pueden generar una gran cantidad de
llamadas HTTP que, a su vez, exceden la cuota de suscripción asignada, lo que causa un error. Los errores serán
similares a estos:
Service returned an error. Status=429 Code=\"OperationNotAllowed\" Message=\"The server rejected the request
because too many requests have been received for this subscription.\" Details=
[{\"code\":\"TooManyRequests\",\"message\":\"
{\\\"operationGroup\\\":\\\"HighCostGetVMScaleSet30Min\\\",\\\"startTime\\\":\\\"2020-09-
20T07:13:55.2177346+00:00\\\",\\\"endTime\\\":\\\"2020-09-
20T07:28:55.2177346+00:00\\\",\\\"allowedRequestCount\\\":1800,\\\"measuredRequestCount\\\":2208}\",\"target
\":\"HighCostGetVMScaleSet30Min\"}] InnerError={\"internalErrorCode\":\"TooManyRequestsReceived\"}"}
Estos errores de limitación se describen detalladamente aquí y aquí.

El equipo de ingeniería de AKS recomienda que se asegure de estar ejecutando al menos la versión 1.18.x, que
incluye muchas mejoras. Puede encontrar más detalles sobre estas mejoras aquí y aquí.
Como estos errores de limitación se miden en el nivel de suscripción, es posible que sigan ocurriendo si:
Hay aplicaciones de terceros que realizan solicitudes GET (por ejemplo, aplicaciones de supervisión, etc.). La
recomendación es reducir la frecuencia de estas llamadas.
Hay muchos grupos de nodos o clústeres de AKS que usan conjuntos de escalado de máquinas virtuales.
Intente dividir el número de clústeres en distintas suscripciones, en concreto, si espera que estén muy activos
(por ejemplo, un escalador automático de clúster activo) o que tengan varios clientes (por ejemplo, Rancher,
Terraform, etc.).
El estado de aprovisionamiento de mi clúster cambiaba de Listo a

Error realizara o no alguna operación. ¿Cuál debo hacer?
Si el estado de aprovisionamiento del clúster cambia de Listo a Error independientemente de si se realiza alguna
operación, pero las aplicaciones del clúster continúan ejecutándose, es posible que el servicio resuelva este
problema automáticamente y las aplicaciones no deberían verse afectadas.
Si el estado de aprovisionamiento del clúster permanece como Error o las aplicaciones del clúster dejarán de
funcionar, envíe una solicitud de soporte técnico.
Mi inspección está obsoleta o NMI de identidad del pod de Azure AD

devuelve el estado 500
Si usa Azure Firewall como en este ejemplo, puede encontrar este problema, ya que las conexiones TCP de larga
duración a través del firewall que usan las reglas de aplicación actualmente tienen un error (que se resolverá en
Q1CY21) que hace que Go keepalives se termine en el firewall. Hasta que se solucione este problema, puede
mitigarlo mediante la incorporación de una regla de red (en lugar de una regla de aplicación) a la dirección IP
del servidor de la API de AKS.
Solución de problemas de Azure Storage y AKS

Error al establecer el valor de UID y GID en mountOptions para Azure Disk
De manera predeterminada, Azure Disk usa el sistema de archivos ext4,xfs y mountOptions como uid=x,gid=x
no se pueden establecer en el momento del montaje. Por ejemplo, si intenta establecer mountOptions como
uid=999,gid=999, vería un error como:
Warning FailedMount 63s kubelet, aks-nodepool1-29460110-0

MountVolume.MountDevice failed for volume "pvc-d783d0e4-85a1-11e9-8a90-369885447933" : azureDisk -
mountDevice:FormatAndMount failed with mount failed: exit status 32
Mounting command: systemd-run
Mounting arguments: --description=Kubernetes transient mount for
/var/lib/kubelet/plugins/kubernetes.io/azure-disk/mounts/m436970985 --scope -- mount -t xfs -o
dir_mode=0777,file_mode=0777,uid=1000,gid=1000,defaults /dev/disk/azure/scsi1/lun2
/var/lib/kubelet/plugins/kubernetes.io/azure-disk/mounts/m436970985
Output: Running scope as unit run-rb21966413ab449b3a242ae9b0fbc9398.scope.
mount: wrong fs type, bad option, bad superblock on /dev/sde,
missing codepage or helper program, or other error
Para mitigar el problema, haga una de las acciones siguientes:

Configure el contexto de seguridad para un pod al establecer UID en runAsUser y GID in fsGroup. Por
ejemplo, la configuración siguiente establecerá la ejecución de pod como raíz, con lo que será accesible a
cualquier archivo:
apiVersion: v1
kind: Pod
metadata:
spec:
securityContext:
runAsUser: 0
fsGroup: 0
NOTE
Como GID y UID se montan como raíz o 0 de manera predeterminada. Si GID o UID se establecen como no raíz, por
ejemplo 1000, Kubernetes usará chown para cambiar todos los directorios y archivos de ese disco. Esta operación puede
llevar mucho tiempo y puede hacer que montar el disco sea muy lento.
Use chown in initContainers para establecer GID y UID . Por ejemplo:
initContainers:
- name: volume-mount
command: ["sh", "-c", "chown -R 100:100 /data"]
volumeMounts:
- name: <your data volume>
mountPath: /data
Error de desasociación de un disco de Azure Disk que lleva a un posible problema de condición de carrera y a
una lista de discos de datos no válida
Cuando se produce un error en la desasociación de un disco de Azure Disk, se reintentará hasta seis veces para
desasociar el disco mediante el retroceso exponencial. También retendrá un bloqueo de nivel de nodo en la lista
de discos de datos durante unos 3 minutos. Si la lista de discos se actualiza manualmente durante ese período,
la lista de discos que retiene el bloqueo de nivel de nodo quedará obsoleta y provocará inestabilidad en el nodo.
Este problema se corrigió en las versiones siguientes de Kubernetes:
VERSIÓ N DE K UB ERN ET ES VERSIÓ N C O RREGIDA
1.12 1.12.9 o posterior
1,14 1.14.2 o posterior
1.15 y posteriores N/D
Si usa una versión de Kubernetes que no tiene la solución para este problema y el nodo tiene una lista de discos
obsoletos, para resolverlo, desasocie todos los discos no existentes de la máquina virtual en una operación
masiva. Es posible que se produzca un error al desasociar manualmente los discos no existentes.
Un gran número de discos de Azure provoca asociaciones/desasociaciones lentas
Cuando el número de operaciones de asociación y desasociación de discos de Azure que tienen como destino
una máquina virtual de un solo nodo es mayor que 10 o que 3 cuando se dirigen a un único grupo de conjuntos
de escalado de máquinas virtuales, pueden ser más lentas de lo esperado, ya que se realizan de forma
secuencial. Este problema es una limitación conocida y no hay ninguna solución alternativa en este momento.
Elemento de User Voice para admitir la asociación o desasociación paralelas más allá de un número..
Error de desasociación de disco de Azure que lleva a una posible máquina virtual de nodo en estado erróneo
En algunos casos, es posible que se produzca un error en la desasociación de discos de Azure y que deje la
máquina virtual del nodo en un estado erróneo.
1.15 y posteriores N/D
Si usa una versión de Kubernetes que no tiene la solución para este problema y el nodo se encuentra en estado
de error, puede resolverlo con la actualización manual del estado de la máquina virtual de una de las maneras
siguientes:
Para un clúster basado en un conjunto de disponibilidad:
az vm update -n <VM_NAME> -g <RESOURCE_GROUP_NAME>
Para un clúster basado en VMSS:
az vmss update-instances -g <RESOURCE_GROUP_NAME> --name <VMSS_NAME> --instance-id <ID>
Solución de problemas de Azure Files y AKS

¿Cuáles son las versiones estables recomendadas de Kubernetes para Azure Files?
VERSIÓ N DE K UB ERN ET ES VERSIÓ N REC O M EN DA DA
¿Cuál es el valor predeterminado de mountOptions cuando se usa Azure Files?

Configuración recomendada:
VERSIÓ N DE K UB ERN ET ES VA LO R DE F IL EM O DE Y DIRM O DE
1.12.0 - 1.12.1 0755
1.12.2 y versiones posteriores 0777
Las opciones de montaje se pueden especificar en el objeto de clase de almacenamiento. En el ejemplo siguiente
se establece 0777:
kind: StorageClass
metadata:
name: azurefile
mountOptions:
- dir_mode=0777
- file_mode=0777
- uid=1000
- gid=1000
- mfsymlinks
- nobrl
- cache=none
parameters:
Algunos valores de mountOptions útiles adicionales:

mfsymlinks hará que el montaje de Azure Files (cifs) admita vínculos simbólicos.
nobrl impedirá las solicitudes de bloqueo de intervalo de bytes al servidor. Esta configuración es necesaria
para ciertas aplicaciones que se interrumpen con bloqueos de intervalo de bytes obligatorios de estilo CIFS.
La mayoría de los servidores CIFS todavía no admiten la solicitud de bloqueos de intervalo de bytes
aconsejables. Si no se usa nobrl , las aplicaciones que se interrumpen con bloqueos de intervalo de bytes
obligatorios de estilo CIFS pueden generar mensajes de error similares a:
Error: SQLITE_BUSY: database is locked
Error "Could not change permissions" (No se pudieron cambiar los permisos) cuando se usa Azure Files
Al ejecutar PostgreSQL en el complemento de Azure Files, puede ver un error similar al siguiente:
initdb: could not change permissions of directory "/var/lib/postgresql/data": Operation not permitted
fixing permissions on existing directory /var/lib/postgresql/data
Este error se debe al complemento de Azure Files que usa el protocolo cifs/SMB. Al usar el protocolo cifs/SMB,
no se pudieron cambiar los permisos de archivos y directorios después del montaje.
Para resolver este problema, use subPath junto con el complemento de Azure Disk.
NOTE
Para el tipo de disco ext3/4, se produce un error en el directorio perdido y encontrado después de dar formato al disco.
Azure Files tiene una latencia alta en comparación con Azure Disk al controlar muchos archivos pequeños
En algunos casos, como el control de muchos archivos pequeños, se puede experimentar una latencia elevada al
usar Azure Files en comparación con Azure Disk.
Error al habilitar la configuración "Permitir el acceso desde la red seleccionada" en la cuenta de
almacenamiento
Si habilita la opción Allow access from selected network (Permitir el acceso desde la red seleccionada) en una
cuenta de almacenamiento que se usa para el aprovisionamiento dinámico en AKS, recibirá un error cuando
AKS cree un recurso compartido de archivos:
persistentvolume-controller (combined from similar events): Failed to provision volume with StorageClass
"azurefile": failed to create share kubernetes-dynamic-pvc-xxx in account xxx: failed to create file share,
err: storage: service returned error: StatusCode=403, ErrorCode=AuthorizationFailure, ErrorMessage=This
request is not authorized to perform this operation.
Este error se debe a que persistentvolume-controller de Kubernetes no está en la red que se eligió cuando se
estableció la opción Permitir el acceso desde la red seleccionada.
Para mitigar el problema, use el aprovisionamiento estático con Azure Files.
Azure Files no se puede volver a montar en el pod de Windows
Si se elimina un pod de Windows con un montaje de Azure Files y luego se programa para volver a crearlo en el
mismo nodo, el montaje generará un error. Este error se debe a un error del comando New-SmbGlobalMapping
debido a que el montaje de Azure Files ya está montado en el nodo.
Por ejemplo, puede ver un error similar al siguiente:
E0118 08:15:52.041014 2112 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/azure-

file/42c0ea39-1af9-11e9-8941-000d3af95268-pvc-d7e1b5f9-1af3-11e9-8941-000d3af95268\" (\"42c0ea39-1af9-11e9-
8941-000d3af95268\")" failed. No retries permitted until 2019-01-18 08:15:53.0410149 +0000 GMT
m=+732.446642701 (durationBeforeRetry 1s). Error: "MountVolume.SetUp failed for volume \"pvc-d7e1b5f9-1af3-
11e9-8941-000d3af95268\" (UniqueName: \"kubernetes.io/azure-file/42c0ea39-1af9-11e9-8941-000d3af95268-pvc-
d7e1b5f9-1af3-11e9-8941-000d3af95268\") pod \"deployment-azurefile-697f98d559-6zrlf\" (UID: \"42c0ea39-1af9-
11e9-8941-000d3af95268\") : azureMount: SmbGlobalMapping failed: exit status 1, only SMB mount is supported
now, output: \"New-SmbGlobalMapping : Generic failure \\r\\nAt line:1 char:190\\r\\n+ ... ser, $PWord;New-
SmbGlobalMapping -RemotePath $Env:smbremotepath -Cred ...\\r\\n+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\\r\\n + CategoryInfo : NotSpecified:
(MSFT_SmbGlobalMapping:ROOT/Microsoft/...mbGlobalMapping) [New-SmbGlobalMa \\r\\n pping],
CimException\\r\\n + FullyQualifiedErrorId : HRESULT 0x80041001,New-SmbGlobalMapping\\r\\n \\r\\n\""

1.14 y versiones posteriores N/D
No se puede montar Azure Files debido a que la clave de la cuenta de almacenamiento cambió
Si la clave de cuenta de almacenamiento cambió, es posible que vea errores de montaje de Azure Files.
Para mitigar el problema, actualice manualmente el campo azurestorageaccountkey en el secreto del archivo de
Azure con la clave de la cuenta de almacenamiento codificada en Base64.
Para codificar la clave de cuenta de almacenamiento en Base64, puede usar base64 . Por ejemplo:
echo X+ALAAUgMhWHL7QmQ87E1kSfIqLKfgC03Guy7/xk9MyIg2w4Jzqeu60CVw2r/dm6v6E0DWHTnJUEJGVQAoPaBc== | base64
Para actualizar el archivo secreto de Azure, use kubectl edit secret . Por ejemplo:
kubectl edit secret azure-storage-account-{storage-account-name}-secret
Al cabo de unos minutos, el nodo del agente volverá a intentar el montaje de Azure Files con la clave de
almacenamiento actualizada.
El escalador automático del clúster no se puede escalar con el error que indica que no se pudieron corregir
los tamaños del grupo de nodos
Si el escalador automático del clúster no se amplía ni se reduce y aparece un error como el siguiente en los
registros del escalador automático del clúster.
E1114 09:58:55.367731 1 static_autoscaler.go:239] Failed to fix node group sizes: failed to decrease aks-
default-35246781-vmss: attempt to delete existing nodes
Este error se debe a una condición de carrera del escalador automático del clúster de subida. En tal caso, el
escalador automático del clúster termina con un valor diferente al que se encuentra realmente en el clúster. Para
salir de este estado, deshabilite y vuelva a habilitar el escalador automático del clúster.
Conexión lenta de disco, GetAzureDiskLun tarda entre 10 y 15 minutos y recibe un error
En las versiones de Kubernetes anteriores a 1.15.0 , puede recibir un error similar a Error : WaitForAttach
no encuentra el LUN del disco . Para evitar este problema, espere unos 15 minutos y vuelva a intentarlo.
¿Por qué se produce un error en las actualizaciones a Kubernetes 1.16 al usar etiquetas de nodo con un prefijo
kubernetes.io?
A partir de Kubernetes 1.16, el kubelet solo puede aplicar un subconjunto definido de etiquetas con el prefijo
kubernetes.io a los nodos. AKS no puede quitar etiquetas activas en su nombre sin consentimiento, ya que
puede provocar tiempo de inactividad en las cargas de trabajo afectadas.
Como resultado, para mitigar este problema, puede:
1. Actualizar el plano de control del clúster a 1.16 o superior
2. Agregar un nuevo grupo de nodos en 1.16 o una versión posterior sin las etiquetas de kubernetes.io no
compatibles
3. Eliminar el antiguo grupo de nodos
AKS está investigando la capacidad de mutar etiquetas activas en un grupo de nodos para mejorar esta
mitigación.
Comprobación de los procedimientos
recomendados de Kubernetes en el clúster
Hay varios procedimientos recomendados que debería seguir en las implementaciones de Kubernetes para
garantizar el mejor rendimiento y resistencia para las aplicaciones. Puede usar la herramienta kube-advisor para
buscar las implementaciones que no siguen dichas sugerencias.
Acerca de kube-advisor
La herramienta kube-advisor es un contenedor único diseñado para ejecutarse en el clúster. Consulta el servidor
de API de Kubernetes para obtener información acerca de las implementaciones y devuelve un conjunto de
mejoras sugeridas.
La herramienta kube-advisor puede informar sobre la solicitud de recursos y la falta de límites en PodSpecs
para las aplicaciones Windows, así como las aplicaciones de Linux, pero la propia herramienta kube-advisor
debe programarse en un pod de Linux. Puede programar un pod para que se ejecute en un grupo de nodos con
un sistema operativo específico mediante un selector de nodo en la configuración del pod.
NOTE
La herramienta kube-advisor es compatible con Microsoft dentro de lo posible. Los problemas y las sugerencias deben
presentarse en GitHub.
Ejecución de kube-advisor
Para ejecutar la herramienta en un clúster configurado para el control de acceso basado en rol de Kubernetes
(RBAC), deben usarse los siguientes comandos. El primer comando crea una cuenta de servicio de Kubernetes. El
segundo, ejecuta la herramienta en un pod con esa cuenta de servicio y configura el pod para su eliminación
después de salir.
kubectl apply -f https://raw.githubusercontent.com/Azure/kube-advisor/master/sa.yaml
kubectl run --rm -i -t kubeadvisor --image=mcr.microsoft.com/aks/kubeadvisor --restart=Never --overrides="{

\"apiVersion\": \"v1\", \"spec\": { \"serviceAccountName\": \"kube-advisor\" } }" --namespace default
Si no usa RBAC de Kubernetes, puede ejecutar el comando como se indica a continuación:
kubectl run --rm -i -t kubeadvisor --image=mcr.microsoft.com/aks/kubeadvisor --restart=Never
En unos pocos segundos, debería ver una tabla donde se describen posibles mejoras para las implementaciones.
Comprobaciones realizadas
La herramienta valida varios procedimientos recomendados de Kubernetes, cada uno con su propia sugerencia
de corrección.
Límites y solicitudes de recursos
Kubernetes admite la definición de límites y solicitudes de recursos en las especificaciones de pod. La solicitud
define el nivel mínimo de CPU y memoria necesario para ejecutar el contenedor. El límite define el nivel máximo
de CPU y memoria que se debe permitir.
De forma predeterminada, no se establecen límites ni solicitudes en las especificaciones de pod. Esto puede
provocar que los nodos se programen en exceso y que se priven los contenedores. La herramienta kube-advisor
resalta los pods sin establecer solicitudes ni límites.
Limpiar
Si el clúster tiene habilitado RBAC de Kubernetes, puede limpiar ClusterRoleBinding después de ejecutar la
herramienta con el comando siguiente:
kubectl delete -f https://raw.githubusercontent.com/Azure/kube-advisor/master/sa.yaml
Si ejecuta la herramienta en un clúster que no tenga habilitado RBAC de Kubernetes, no se requiere ninguna
limpieza.
Pasos siguientes
Solución de problemas de Azure Kubernetes Service
Conexión con SSH a los nodos de clúster de Azure
Kubernetes Service (AKS) para mantenimiento o
solución de problemas
Durante el ciclo de vida del clúster de Azure Kubernetes Service (AKS), es posible que necesite acceder a un
nodo de AKS. Este acceso podría ser para mantenimiento, recopilación de registros u otras operaciones de
solución de problemas. Puede acceder a los nodos de AKS mediante SSH, incluidos los nodos de
Windows Server. También puede conectarse a los nodos de Windows Server mediante conexiones de protocolo
de escritorio remoto (RDP). Por motivos de seguridad, los nodos de AKS no están expuestos a Internet. Para
conectarse mediante SSH a los nodos de AKS, use la dirección IP privada.
En este artículo se muestra cómo crear una conexión SSH con un nodo de AKS mediante sus direcciones IP
privadas.
Antes de empezar
De forma predeterminada, las claves SSH se obtienen, o generan, y luego se agregan a los nodos cuando crea
un clúster de AKS. En este artículo se muestra cómo especificar claves SSH distintas de las que se usaron al crear
el clúster de Azure Kubernetes Service. En el artículo también se muestra cómo determinar la dirección IP
privada del nodo y cómo conectarse a el mediante SSH. Si no necesita especificar otra clave SSH, puede omitir el
paso en el que se agrega la clave pública SSH al nodo.
En este artículo también se da por supuesto que tiene una clave SSH. Se pueden crear claves SSH en macOS,
Linux o Windows. Si utiliza PuTTY Gen para crear el par de claves, guarde dicho par en un formato OpenSSH en
lugar del formato de clave privada PuTTy predeterminado (archivo .ppk).
También es preciso tener instalada y configurada la versión 2.0.64 de la CLI de Azure u otra versión posterior.
Azure.
Configuración de clústeres de AKS basados en conjuntos de escalado

de máquinas virtuales para acceder a SSH
Para configurar un clúster de AKS basado en un conjunto de escalado de máquinas virtuales para acceder a SSH,
busque el nombre del conjunto de escalado de máquinas virtuales del clúster y agregue la clave pública SSH a
ese conjunto de escalado.
Use el comando az aks show para obtener el nombre del grupo de recursos del clúster de AKS y, después, el
comando vmss list para obtener el nombre del conjunto de escalado.
CLUSTER_RESOURCE_GROUP=$(az aks show --resource-group myResourceGroup --name myAKSCluster --query

nodeResourceGroup -o tsv)
SCALE_SET_NAME=$(az vmss list --resource-group $CLUSTER_RESOURCE_GROUP --query '[0].name' -o tsv)
En el ejemplo anterior se asigna el nombre del grupo de recursos del clúster para myAKSCluster en
myResourceGroup a CLUSTER_RESOURCE_GROUP. Luego, el ejemplo usa CLUSTER_RESOURCE_GROUP para
mostrar el nombre del conjunto de escalado y asignarlo a SCALE_SET_NAME.
IMPORTANT
En este punto, solo debe actualizar las claves SSH de los clústeres de AKS basados en conjuntos de escalado de máquinas
virtuales mediante la CLI de Azure.
En los nodos de Linux, las claves SSH actualmente solo se pueden agregar mediante la CLI de Azure. Si desea conectarse a
un nodo de Windows Server mediante SSH, use las claves SSH que se proporcionan al crear el clúster de AKS y omita el
siguiente conjunto de comandos para agregar la clave pública SSH. Seguirá necesitando la dirección IP del nodo cuyos
problemas desea solucionar, que se muestra en el comando final de esta sección. Como alternativa, puede conectarse a
los nodos de Windows Server mediante conexiones RDP (protocolo de escritorio remoto), en lugar de usar SSH.
Para agregar sus claves SSH a los nodos de un conjunto de escalado de máquinas virtuales, use los comandos
az vmss extension set y az vmss update-instances.
az vmss extension set \

--resource-group $CLUSTER_RESOURCE_GROUP \
--vmss-name $SCALE_SET_NAME \
--name VMAccessForLinux \
--publisher Microsoft.OSTCExtensions \
--version 1.4 \
--protected-settings "{\"username\":\"azureuser\", \"ssh_key\":\"$(cat ~/.ssh/id_rsa.pub)\"}"
az vmss update-instances --instance-ids '*' \

--name $SCALE_SET_NAME
En el ejemplo anterior se usan las variables CLUSTER_RESOURCE_GROUP y SCALE_SET_NAME de los comandos

anteriores. En el ejemplo anterior también se usa ~/.ssh/id_rsa.pub como ubicación de la clave pública SSH.
NOTE
De forma predeterminada, el nombre de usuario para los nodos de AKS es azureuser.
Después de agregar la clave pública SSH al conjunto de escalado, puede usar SSH en una máquina virtual del
nodo de ese conjunto de escalado mediante su dirección IP. Vea las direcciones IP privadas de los nodos del
clúster de AKS mediante el comando kubectl get.
kubectl get nodes -o wide
La salida del ejemplo siguiente muestra las direcciones IP internas de todos los nodos del clúster, incluido un
nodo de Windows Server.
$ kubectl get nodes -o wide

aks-nodepool1-42485177-vmss000000 Ready agent 18h v1.12.7 10.240.0.4 <none> Ubuntu
16.04.6 LTS 4.15.0-1040-azure docker://3.0.4
aksnpwin000000 Ready agent 13h v1.12.7 10.240.0.67 <none> Windows
Server Datacenter 10.0.17763.437
Registre la dirección IP interna del nodo que desea solucionar.

Para acceder a su nodo mediante SSH, siga los pasos que se indican en Creación de la conexión SSH.
Configuración de clústeres de AKS basados en conjuntos de

disponibilidad de máquinas virtuales para acceder a SSH
Para configurar un clúster de AKS basado en un conjunto de disponibilidad de máquinas virtuales para acceder
a SSH, busque el nombre del nodo Linux del clúster y agregue su clave pública SSH a ese nodo.
Use el comando az aks show para obtener el nombre del grupo de recursos del clúster de AKS y, después, el
comando az vm list para enumerar el nombre de la máquina virtual del nodo de Linux del clúster.
CLUSTER_RESOURCE_GROUP=$(az aks show --resource-group myResourceGroup --name myAKSCluster --query

nodeResourceGroup -o tsv)
az vm list --resource-group $CLUSTER_RESOURCE_GROUP -o table
En el ejemplo anterior se asigna el nombre del grupo de recursos del clúster para myAKSCluster en
myResourceGroup a CLUSTER_RESOURCE_GROUP. Luego, el ejemplo usa CLUSTER_RESOURCE_GROUP para
enumerar el nombre de la máquina virtual. La salida del ejemplo muestra el nombre de la máquina virtual:
Name ResourceGroup Location

------------------------ --------------------------------------------- ----------
aks-nodepool1-79590246-0 MC_myResourceGroupAKS_myAKSClusterRBAC_eastus eastus
Para agregar las claves SSH al nodo, utilice el comando az vm user update.
az vm user update \
--name aks-nodepool1-79590246-0 \
--username azureuser \
--ssh-key-value ~/.ssh/id_rsa.pub
En el ejemplo anterior se usa la variable CLUSTER_RESOURCE_GROUP y el nombre de la máquina virtual del

nodo de los comandos anteriores. En el ejemplo anterior también se usa ~/.ssh/id_rsa.pub como ubicación de la
clave pública SSH. También puede usar el contenido de la clave pública SSH, en lugar de especificar una ruta de
acceso.
NOTE
De forma predeterminada, el nombre de usuario para los nodos de AKS es azureuser.
Después de agregar la clave pública SSH a la máquina virtual del nodo, puede usar conectarse con SSH a esa
máquina virtual mediante su dirección IP. Vea la dirección IP privada de un nodo de clúster de AKS con el
comando az vm list-ip-addresses.
az vm list-ip-addresses --resource-group $CLUSTER_RESOURCE_GROUP -o table
En el ejemplo anterior se usa la variable CLUSTER_RESOURCE_GROUP establecida en los comandos anteriores.

En la siguiente salida de ejemplo se muestran las direcciones IP privadas de los nodos de AKS:
VirtualMachine PrivateIPAddresses
------------------------ --------------------
aks-nodepool1-79590246-0 10.240.0.4
Creación de la conexión SSH
Para crear una conexión SSH a un nodo AKS, ejecute un pod asistente en el clúster de AKS. Este pod asistente
proporciona acceso SSH al clúster y después acceso adicional al nodo SSH. Para crear y utilizar este pod
asistente, siga estos pasos:
1. Ejecute una imagen de contenedor debian y asocie a ella una sesión de terminal. Este contenedor se
puede usar para crear una sesión de SSH con cualquier nodo del clúster de AKS:
kubectl run -it --rm aks-ssh --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
TIP
Si usa nodos de Windows Server, agregue un selector de nodo al comando para programar el contenedor de
Debian en un nodo de Linux:
kubectl run -it --rm aks-ssh --image=mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11 --

overrides='{"apiVersion":"v1","spec":{"nodeSelector":{"beta.kubernetes.io/os":"linux"}}}'
2. Una vez que la sesión de terminal esté conectada al contenedor, instale un cliente SSH mediante apt-get :
apt-get update && apt-get install openssh-client -y
3. Abra una nueva ventana de terminal, no conectada al contenedor, y copie la clave SSH privada en el pod
asistente. Esta clave privada se utiliza para crear el SSH en el nodo de Azure Kubernetes Service.
Si es necesario, cambie ~/.ssh/id_rsa a la ubicación de la clave SSH privada:
kubectl cp ~/.ssh/id_rsa $(kubectl get pod -l run=aks-ssh -o

jsonpath='{.items[0].metadata.name}'):/id_rsa
4. Vuelva a la sesión de terminal en el contenedor, actualice los permisos de la clave SSH privada copiada
id_rsa para que sea de solo lectura para el usuario:
chmod 0400 id_rsa
5. Cree una conexión SSH al nodo de Azure Kubernetes Service. De nuevo, el nombre de usuario para los
nodos de AKS es azureuser. Acepte el aviso para continuar con la conexión, ya que la clave SSH es la
primera en la que se confía. A continuación, se proporcionan con el aviso de bash del nodo de AKS:
$ ssh -i id_rsa azureuser@10.240.0.4
ECDSA key fingerprint is SHA256:A6rnRkfpG21TaZ8XmQCCgdi9G/MYIMc+gFAuY9RUY70.

Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.240.0.4' (ECDSA) to the list of known hosts.
Welcome to Ubuntu 16.04.5 LTS (GNU/Linux 4.15.0-1018-azure x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
Get cloud support with Ubuntu Advantage Cloud Guest:

https://www.ubuntu.com/business/services/cloud
[...]
azureuser@aks-nodepool1-79590246-0:~$
Eliminación del acceso SSH

Cuando haya finalizado, exit la sesión de SSH y, a continuación, exit la sesión del contenedor interactiva.
Cuando esta sesión de contenedor se cierra, se elimina el pod usado para el acceso SSH desde el clúster de AKS.
Pasos siguientes
Si necesita datos adicionales para la solución de problemas, puede ver los registros de kubelet o ver los
registros del nodo maestro de Kubernetes.
Solución de problemas de rendimiento en Linux
El agotamiento de recursos de las máquinas Linux es un problema habitual que puede manifestarse con muchos
síntomas diferentes. Este documento contiene información general sobre las herramientas disponibles para
ayudar a diagnosticar estos problemas.
Muchas de estas herramientas permiten establecer el intervalo en el que se va a generar la salida gradual. Por lo
general, esta forma de salida hace que la detección de patrones resulte mucho más fácil. Si se acepta, la
invocación de ejemplo incluirá [interval] .
Muchas de estas herramientas cuentan con un amplio historial y una gran variedad de opciones de
configuración. En esta página, se incluye solo un subconjunto de invocaciones para poner de manifiesto
problemas comunes. El origen de información prioritario siempre debe ser la documentación de referencia de
cada herramienta concreta. Esa documentación será mucho más exhaustiva que la que pueda proporcionarse
aquí.
Guía
Sea sistemático en su enfoque para investigar los problemas de rendimiento. Dos enfoques comunes son USE
(uso, saturación, errores) y VED (velocidad, errores, duración). El método VED suele utilizarse en el contexto de
los servicios que realizan una supervisión basada en solicitudes. El método USE suele emplearse para
supervisar recursos. Supervise el uso, la saturación y los errores de todos los recursos de una máquina. Los
cuatro tipos principales de recursos de cualquier máquina son la CPU, la memoria, el disco y la red. Un alto
índice de uso, saturación o errores en cualquiera de estos recursos puede ser indicativo de que hay algún
problema en el sistema. Cuando existe un problema, investigue la causa principal: ¿por qué es tan alta la latencia
de entrada y salida del disco? ¿Los discos o la SKU de la máquina virtual tienen alguna limitación? ¿Qué
procesos están escribiendo en los dispositivos y en qué archivos lo hacen?
Estos son algunos ejemplos de problemas e indicadores comunes para que pueda diagnosticarlos:
Limitación de IOPS: utilice iostat para medir las IOPS de cada dispositivo. Asegúrese de que no haya ningún
disco por encima de su límite y que la suma de todos los discos sea inferior al límite de la máquina virtual.
Límite de ancho de banda: utilice iostat igual que con las IOPS, pero para medir el rendimiento de lectura y
escritura. Asegúrese de que el rendimiento de cada dispositivo y el rendimiento general estén por debajo de
los límites de ancho de banda.
Agotamiento de SNAT: puede manifestarse mediante un elevado número de conexiones activas (de salida) de
SAR.
Pérdida de paquetes: puede medirse mediante el proxy atendiendo al número de retransmisiones de TCP en
comparación con el número enviado o recibido. Tanto sar como netstat pueden mostrar esta información.
General
Estas herramientas son de uso general y cubren información básica del sistema. Constituyen un buen punto de
partida para una investigación más exhaustiva.
uptime
$ uptime
19:32:33 up 17 days, 12:36, 0 users, load average: 0.21, 0.77, 0.69
uptime indica el tiempo de actividad del sistema y las cargas medias en 1, 5 y 15 minutos. Estas cargas medias
se corresponden a grosso modo con los subprocesos que realizan el trabajo o esperan a que se complete un
trabajo ininterrumpido. En términos absolutos, estos números son difíciles de interpretar, pero con el transcurso
del tiempo, pueden aportarnos información útil:
media de 1 minuto > media de 5 minutos: significa que la carga está aumentando.
media de 1 minuto < media de 5 minutos: significa que la carga está disminuyendo.
uptime también puede ayudar a esclarecer por qué no hay información disponible: el problema puede haberse
resuelto solo o porque la máquina se reinició antes de que accediera el usuario.
Si las medias de carga son superiores al número de subprocesos de la CPU disponibles, podría indicar que hay
un problema de rendimiento con una determinada carga de trabajo.
dmesg
$ dmesg | tail
$ dmesg --level=err | tail
dmesg vuelca la memoria del búfer del kernel. Los eventos como OOMKill agregan una entrada en el búfer del
kernel. Encontrar un evento OOMKill u otros mensajes de agotamiento de recursos en los registros de dmesg es
un indicador con bastante peso de que hay un problema.
top
$ top
Tasks: 249 total, 1 running, 158 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.2 us, 1.3 sy, 0.0 ni, 95.4 id, 1.0 wa, 0.0 hi, 0.2 si, 0.0 st
KiB Mem : 65949064 total, 43415136 free, 2349328 used, 20184600 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 62739060 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

116004 root 20 0 144400 41124 27028 S 11.8 0.1 248:45.45 coredns
4503 root 20 0 1677980 167964 89464 S 5.9 0.3 1326:25 kubelet
1 root 20 0 120212 6404 4044 S 0.0 0.0 48:20.38 systemd
...
top proporciona información general sobre el estado actual del sistema. Los encabezados aportan cierta
información útil, como:
El estado de las tareas: en ejecución, en espera, detenidas.
El uso de la CPU: en este caso, suele indicar el tiempo de inactividad.
La memoria total, libre y utilizada por el sistema.
top puede pasar por alto los procesos de corta duración. Otras alternativas como htop y atop ofrecen
interfaces similares y solucionan algunas de estas limitaciones.
CPU
Estas herramientas proporcionan información sobre el uso de la CPU. Esta información resulta especialmente
útil con las salidas graduales, en las que resulta más fácil detectar patrones.
mpstat
$ mpstat -P ALL [interval]
Linux 4.15.0-1064-azure (aks-main-10212767-vmss000001) 02/10/20 _x86_64_ (8 CPU)
19:49:03 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
19:49:04 all 1.01 0.00 0.63 2.14 0.00 0.13 0.00 0.00 0.00 96.11
19:49:04 0 1.01 0.00 1.01 17.17 0.00 0.00 0.00 0.00 0.00 80.81
19:49:04 1 1.98 0.00 0.99 0.00 0.00 0.00 0.00 0.00 0.00 97.03
19:49:04 2 1.01 0.00 0.00 0.00 0.00 1.01 0.00 0.00 0.00 97.98
19:49:04 3 0.00 0.00 0.99 0.00 0.00 0.99 0.00 0.00 0.00 98.02
19:49:04 4 1.98 0.00 1.98 0.00 0.00 0.00 0.00 0.00 0.00 96.04
19:49:04 5 1.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 98.00
19:49:04 6 1.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 98.00
19:49:04 7 1.98 0.00 0.99 0.00 0.00 0.00 0.00 0.00 0.00 97.03
mpstat imprime información similar de la CPU al principio, pero desglosada por cada subproceso de la CPU.
Ver todos los núcleos a la vez puede resultar útil para detectar si el uso de la CPU está desequilibrado; por
ejemplo, cuando una aplicación con un solo subproceso utiliza un núcleo al 100 %. Este problema puede ser
más difícil de detectar cuando se observa el conjunto global de todas las CPU del sistema.
vmstat
$ vmstat [interval]
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 0 43300372 545716 19691456 0 0 3 50 3 3 2 1 95 1 0
vmstat proporciona información similar a mpstat y top , como el número de procesos de la CPU en espera
(columna r), estadísticas de memoria y el porcentaje de CPU invertido en cada estado de trabajo.
Memoria
La memoria es un recurso muy importante y sorprendentemente sencillo de utilizar para medir el rendimiento.
Algunas herramientas pueden proporcionar información sobre la CPU y la memoria, como vmstat . Sin
embargo, las herramientas como free son muy útiles para realizar tareas de depuración rápidamente.
libre
$ free -m
total used free shared buff/cache available
Mem: 64403 2338 42485 1 19579 61223
Swap: 0 0 0
free proporciona información básica sobre la memoria total, tanto la memoria utilizada como la memoria
libre. vmstat puede ser más útil para realizar análisis básicos de memoria, ya que puede proporcionar la salida
gradualmente.
Disco
Las siguientes herramientas miden las IOPS del disco, las colas de espera y el rendimiento total.
iostat
$ iostat -xy [interval] [count]
$ iostat -xy 1 1
avg-cpu: %user %nice %system %iowait %steal %idle

3.42 0.00 2.92 1.90 0.00 91.76
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await
svctm %util
loop0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00
sda 0.00 56.00 0.00 65.00 0.00 504.00 15.51 0.01 3.02 0.00 3.02
0.12 0.80
scd0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00
iostat proporciona información detallada sobre el uso del disco. Esta invocación pasa -x para mostrar
estadísticas detalladas, -y para omitir la salida inicial e imprimir las medias del sistema desde el arranque y
1 1 para especificar que queremos aplicar un intervalo de 1 segundo y terminar después de un bloque de
salida.
iostat muestra estadísticas muy útiles:
r/s y w/sson lecturas y escrituras por segundo. La suma de estos valores conforman las IOPS.
rkB/s y wkB/s son lecturas y escrituras por segundo en kilobytes. La suma de estos valores es el
rendimiento.
await es el tiempo medio de iowait en milisegundos para las solicitudes en cola.
avgqu-sz es el tamaño medio de la cola durante el intervalo proporcionado.
En una máquina virtual de Azure:

La suma de r/s y w/s en un dispositivo específico del bloque no debe superar los límites de la SKU de ese
disco.
La suma de rkB/s y wkB/s en un dispositivo específico del bloque no debe superar los límites de la SKU de
ese disco.
La suma de r/s y w/s de todos los dispositivos del bloque no puede superar los límites de la SKU de la
máquina virtual.
La suma de rkB/s y wkB/s de todos los dispositivos del bloque no puede superar los límites de la SKU de la
máquina virtual.
Tenga en cuenta que el disco del sistema operativo cuenta como un disco administrado de la SKU más pequeña
que corresponda a su capacidad. Por ejemplo, un disco del sistema operativo de 1024 GB se corresponderá con
un disco P30. Los discos de sistema operativo efímeros y los discos temporales no tienen límites de disco
individuales; solo se van afectados por los límites de toda la máquina virtual.
Los valores distintos de cero de awaitwait o avgqu-sz también son buenos indicadores de la contención de
entrada y salida.
Red
Estas herramientas miden las estadísticas de red, como el rendimiento, los errores de transmisión y el uso. Si se
realiza un análisis más profundo, pueden obtenerse estadísticas detalladas de TCP sobre la congestión y los
paquetes descartados.
sar
$ sar -n DEV [interval]
22:36:57 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
22:36:58 docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
22:36:58 azv604be75d832 1.00 9.00 0.06 1.04 0.00 0.00 0.00 0.00
22:36:58 azure0 68.00 79.00 27.79 52.79 0.00 0.00 0.00 0.00
22:36:58 azv4a8e7704a5b 202.00 207.00 37.51 21.86 0.00 0.00 0.00 0.00
22:36:58 azve83c28f6d1c 21.00 30.00 24.12 4.11 0.00 0.00 0.00 0.00
22:36:58 eth0 314.00 321.00 70.87 163.28 0.00 0.00 0.00 0.00
22:36:58 azva3128390bff 12.00 20.00 1.14 2.29 0.00 0.00 0.00 0.00
22:36:58 azvf46c95ddea3 10.00 18.00 31.47 1.36 0.00 0.00 0.00 0.00
22:36:58 enP1s1 74.00 374.00 29.36 166.94 0.00 0.00 0.00 0.00
22:36:58 lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
22:36:58 azvdbf16b0b2fc 9.00 19.00 3.36 1.18 0.00 0.00 0.00 0.00
sar es una eficaz herramienta que permite realizar una gran variedad de análisis. Aunque en este ejemplo se
usa para medir las estadísticas de red, es igualmente eficaz para medir el consumo de la CPU y la memoria. En
este ejemplo, sar se invoca con la marca -n para especificar la palabra clave DEV (dispositivo de red), que
muestra el rendimiento de la red en cada dispositivo.
La suma de rxKb/s y txKb/s es el rendimiento total de un dispositivo dado. Si este valor supera el límite de
la NIC de Azure aprovisionada, las cargas de trabajo de la máquina registrarán una mayor latencia de red.
%ifutil mide el uso en un dispositivo dado. A medida que este valor se aproxime al 100 %, las cargas de
trabajo experimentarán una mayor latencia de red.
$ sar -n TCP,ETCP [interval]

22:50:08 active/s passive/s iseg/s oseg/s

22:50:09 2.00 0.00 19.00 24.00
22:50:08 atmptf/s estres/s retrans/s isegerr/s orsts/s

22:50:09 0.00 0.00 0.00 0.00 0.00
Average: active/s passive/s iseg/s oseg/s

Average: 2.00 0.00 19.00 24.00
Average: atmptf/s estres/s retrans/s isegerr/s orsts/s

Average: 0.00 0.00 0.00 0.00 0.00
Esta invocación de sar utiliza las palabras clave TCP,ETCP para examinar las conexiones TCP. La tercera
columna de la última fila, "retrans", es el número de retransmisiones de TCP por segundo. Los elevados valores
de este campo indican que la conexión de red no es fiable. En la primera y la tercera fila, "active" significa que se
inició una conexión desde el dispositivo local, mientras que "remote" hace referencia a una conexión entrante.
Un problema frecuente en Azure es el agotamiento de puertos de SNAT, algo que sar puede ayudar a detectar.
El agotamiento de puertos de SNAT se manifestaría como valores "active" elevados, ya que el problema se debe
a un alto índice de conexiones TCP de salida que se inician localmente.
Como sar toma un intervalo, imprime la salida gradualmente y después imprime las filas finales de salida que
contienen los resultados medios de la invocación.
netstat
$ netstat -s
Ip:
71046295 total packets received
78 forwarded
0 incoming packets discarded
71046066 incoming packets delivered
83774622 requests sent out
40 outgoing packets dropped
40 outgoing packets dropped
Icmp:
103 ICMP messages received
0 input ICMP message failed.
ICMP input histogram:
destination unreachable: 103
412802 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 412802
IcmpMsg:
InType3: 103
OutType3: 412802
Tcp:
11487089 active connections openings
592 passive connection openings
1137 failed connection attempts
404 connection resets received
17 connections established
70880911 segments received
95242567 segments send out
176658 segments retransmited
3 bad segments received.
163295 resets sent
Udp:
164968 packets received
84 packets to unknown port received.
0 packet receive errors
165082 packets sent
UdpLite:
TcpExt:
5 resets received for embryonic SYN_RECV sockets
1670559 TCP sockets finished time wait in fast timer
95 packets rejects in established connections because of timestamp
756870 delayed acks sent
2236 delayed acks further delayed because of locked socket
Quick ack mode was activated 479 times
11983969 packet headers predicted
25061447 acknowledgments not containing data payload received
5596263 predicted acknowledgments
19 times recovered from packet loss by selective acknowledgements
Detected reordering 114 times using SACK
Detected reordering 4 times using time stamp
5 congestion windows fully recovered without slow start
1 congestion windows partially recovered using Hoe heuristic
5 congestion windows recovered without slow start by DSACK
111 congestion windows recovered without slow start after partial ack
73 fast retransmits
26 retransmits in slow start
311 other TCP timeouts
TCPLossProbes: 198845
TCPLossProbeRecovery: 147
480 DSACKs sent for old packets
175310 DSACKs received
316 connections reset due to unexpected data
272 connections reset due to early user close
5 connections aborted due to timeout
TCPDSACKIgnoredNoUndo: 8498
TCPSpuriousRTOs: 1
TCPSackShifted: 3
TCPSackMerged: 9
TCPSackShiftFallback: 177
IPReversePathFilter: 4
TCPRcvCoalesce: 1501457
TCPOFOQueue: 9898
TCPChallengeACK: 342
TCPSYNChallenge: 3
TCPSpuriousRtxHostQueues: 17
TCPAutoCorking: 2315642
TCPFromZeroWindowAdv: 483
TCPFromZeroWindowAdv: 483
TCPToZeroWindowAdv: 483
TCPWantZeroWindowAdv: 115
TCPSynRetrans: 885
TCPOrigDataSent: 51140171
TCPHystartTrainDetect: 349
TCPHystartTrainCwnd: 7045
TCPHystartDelayDetect: 26
TCPHystartDelayCwnd: 862
TCPACKSkippedPAWS: 3
TCPACKSkippedSeq: 4
TCPKeepAlive: 62517
IpExt:
InOctets: 36416951539
OutOctets: 41520580596
InNoECTPkts: 86631440
InECT0Pkts: 14
netstat puede proporcionar una gran variedad de estadísticas de red (aquí se ha invocado con la salida de
resumen). Hay muchos campos que pueden resultar útiles en función del problema. Uno de ellos está en la
sección TCP y es "failed connection attempts" (intentos de conexión infructuosos). Esto puede ser un indicativo
del agotamiento de los puertos de SNAT o de otros problemas con las conexiones salientes. Un elevado índice
de segmentos retransmitidos (también en la sección TCP) podría indicar problemas con la entrega de paquetes.
Comprobación de eventos de Resource Health que
afectan al clúster de AKS (versión preliminar)
Al ejecutar las cargas de trabajo de contenedor en AKS, quiere asegurarse de que puede solucionar y corregir
problemas en cuanto surjan para minimizar su impacto en la disponibilidad de las cargas de trabajo. Azure
Resource Health le ofrece visibilidad sobre diversos eventos de mantenimiento que pueden hacer que el clúster
de AKS deje de estar disponible.
IMPORTANT
Apertura de Resource Health

Para acceder a Resource Health para el clúster de AKS:
Vaya al clúster de AKS en Azure Portal.
Seleccione Resource Health en el panel de navegación izquierdo.
Para tener acceso a Resource Health en todos los clústeres de su suscripción:
Busque Ser vice Health en Azure Portal y navegue hasta dicha opción.
Seleccione Resource Health en el panel de navegación izquierdo.
Seleccione su suscripción y establezca el tipo de recurso en Azure Kubernetes Service (AKS).
Comprobación del estado de mantenimiento
Azure Resource Health ayuda a diagnosticar problemas en los servicios que afectan a los recursos de Azure y a
obtener soporte técnico para resolverlos. Resource Health informa sobre el mantenimiento actual y anterior de
los recursos y le ayuda a determinar si el problema se debe a una acción iniciada por el usuario o a un evento de
la plataforma.
Resource Health recibe señales del clúster administrado con el fin de determinar el estado de mantenimiento del
mismo. Examina el estado de mantenimiento del clúster de AKS e informa de las acciones necesarias para cada
señal de mantenimiento. Estas señales van desde problemas de resolución automática, actualizaciones
planeadas, eventos de mantenimiento no planeados y no disponibilidad generados por acciones iniciadas por el
usuario. Estas señales se clasifican mediante el estado de mantenimiento de Azure Resource Health: Disponible,
No disponible, Desconocido y Degradado.
Disponible : cuando no hay ningún problema conocido que afecte al mantenimiento del clúster, Resource
Health informará que el clúster está Disponible.
No disponible : cuando hay un evento de la plataforma o ajeno a esta que afecta al mantenimiento del
clúster, Resource Health informa que el clúster está No disponible.
Desconocido : cuando se produce una pérdida temporal de conexión a las métricas de mantenimiento
del clúster, Resource Health informa que el clúster tiene un estado Desconocido.
Degradado : cuando hay un problema de mantenimiento que requiere una acción del usuario, Resource
Health informa que el clúster está Degradado.
Para obtener información adicional sobre lo que indica cada estado de mantenimiento, visite Introducción a
Resource Health.
Visualización de datos históricos
También puede ver los últimos 30 días de información histórica de Resource Health en la sección Historial de
estado .
Pasos siguientes
Ejecute comprobaciones en el clúster para solucionar más problemas del clúster mediante los diagnósticos de
AKS.
Definiciones integradas de Azure Policy para Azure
Kubernetes Service
Esta página es un índice de las definiciones de directivas integradas de Azure Policy para
Azure Kubernetes Service. Puede encontrar elementos integrados adicionales de Azure Policy para otros
servicios en Definiciones de elementos integrados de Azure Policy.
El nombre de cada definición de directiva integrada se vincula a la definición de directiva en Azure Portal. Use el
vínculo de la columna Versión para ver el origen en el repositorio de GitHub de Azure Policy.
Iniciativas
N O M B RE DESC RIP C IÓ N DIREC T IVA S VERSIÓ N
Estándares de referencia de Esta iniciativa incluye las 5 1.1.1

seguridad de pods de directivas para los
clúster de Kubernetes para estándares de referencia de
cargas de trabajo basadas seguridad de pods de
en Linux clúster de Kubernetes. Esta
directiva está disponible con
carácter general para
Kubernetes Service (AKS) y
en versión preliminar para
el motor de AKS y
Kubernetes con Azure Arc
habilitado. Para
instrucciones sobre el uso
de esta directiva, visite
https://aka.ms/kubepolicyd
oc.
Estándares restringidos de Esta iniciativa incluye las 8 2.1.1

seguridad de pods de directivas para los
clúster de Kubernetes para estándares restringidos de
cargas de trabajo basadas seguridad de pods de
en Linux clúster de Kubernetes. Esta
el motor de AKS y
habilitado. Para
instrucciones sobre el uso
de esta directiva, visite
oc.
Definiciones de directiva
Microsoft.ContainerService
N O M B RE VERSIÓ N
( A ZURE PO RTA L) DESC RIP C IÓ N EF EC TO S ( GIT HUB)
Los intervalos IP Restrinja el acceso a la API Audit, Disabled 2.0.1

autorizados deben definirse de administración de
en los servicios de servicios de Kubernetes
Kubernetes mediante la concesión de
acceso de API solo a
direcciones IP en intervalos
específicos. Se recomienda
limitar el acceso a los
intervalos IP autorizados
para garantizar que solo las
aplicaciones de las redes
permitidas puedan acceder
al clúster.
Los clústeres privados de Habilite la característica de Audit, Deny, Disabled 1.0.0

Azure Kubernetes Service clúster privado para el
deben estar habilitados clúster de Azure Kubernetes
Service a fin de asegurarse
de que el tráfico de red
entre el servidor de API y
los grupos de nodos
permanece solo en la red
privada. Este es un requisito
común de muchos
estándares de cumplimiento
normativo y del sector.
El complemento Azure El complemento Azure Audit, Disabled 1.0.2

Policy para Kubernetes Policy para Kubernetes
Service (AKS) debería estar Service (AKS) amplía
instalado y habilitado en Gatekeeper v3, un webhook
sus clústeres del controlador de admisión
de Open Policy Agent
(OPA), para aplicar
imposiciones y medidas de
seguridad a escala en los
clústeres de forma
centralizada y coherente.
Los sistemas operativos y El cifrado de los sistemas Audit, Deny, Disabled 1.0.0
los discos de datos de los operativos y los discos de
clústeres de Azure datos mediante claves
Kubernetes Service deben administradas por el cliente
cifrarse mediante claves proporciona más control y
administradas por el cliente mayor flexibilidad para la
administración de claves.
Este es un requisito común
de muchos estándares de
cumplimiento normativo y
del sector.
DESC RIP C IÓ N EF EC TO S
Configurar clústeres de Implemente un objeto deployIfNotExists, 1.0.0

Kubernetes con la "sourceControlConfiguratio auditIfNotExists, disabled
configuración de GitOps n" en los clústeres de
especificada con secretos Kubernetes para garantizar
HTTPS que los clústeres obtienen
su origen de verdad para
las cargas de trabajo y las
configuraciones del
repositorio Git definido.
Esta definición requiere que
los secretos de usuario y
clave de HTTPS estén
almacenados en Key Vault.
Para obtener instrucciones,
visite
https://aka.ms/K8sGitOpsPo
licy.

especificada sin secretos Kubernetes para garantizar
que los clústeres obtienen
configuraciones del
Esta definición no requiere
ningún secreto. Para
obtener instrucciones, visite
licy.

especificada con secretos Kubernetes para garantizar
SSH que los clústeres obtienen
configuraciones del
Esta definición requiere un
secreto de clave privada
SSH en Key Vault. Para
obtener instrucciones, visite
licy.
Implementación: configure Implementa la DeployIfNotExists, Disabled 1.0.0

las opciones de diagnóstico configuración de
de Azure Kubernetes diagnóstico de Azure
Service en el área de trabajo Kubernetes Service para
de Log Analytics transmitir los registros de
recursos a un área de
trabajo de Log Analytics.
Implementación del Use el complemento de deployIfNotExists 1.0.0

complemento de Azure Azure Policy para
Policy en los clústeres de administrar e informar
Azure Kubernetes Service sobre el estado de
cumplimiento de los
clústeres de Azure
Para más información, vea
https://aka.ms/akspolicydoc.
Los límites de los recursos Aplique límites de recursos audit, deny, disabled 6.0.0
de memoria y CPU del de CPU y memoria de
contenedor no deben contenedor en un clúster de
superar los límites Kubernetes para evitar los
especificados en el clúster ataques de agotamiento de
de Kubernetes recursos. Esta directiva está
disponible con carácter
general para Kubernetes
Service (AKS) y en versión
preliminar para el motor de
AKS y Kubernetes con
Azure Arc habilitado. Para
más información, consulte
oc.
Los contenedores del No permita que los audit, deny, disabled 3.0.0
clúster de Kubernetes no contenedores de pods
deben compartir el compartan el espacio de
identificador de proceso del nombres de id. de proceso
host ni el espacio de de host ni el espacio de
nombres IPC del host nombres de IPC de host en
un clúster de Kubernetes.
Esta recomendación forma
parte de las versiones 5.2.2
y 5.2.3 de CIS, diseñadas
para mejorar la seguridad
de los entornos de
Kubernetes. Esta directiva
está disponible con carácter
oc.
Los contenedores de Restrinja los contenedores audit, deny, disabled 6.1.0

clústeres de Kubernetes para que escuchen solo en
solo deben escuchar en los puertos permitidos para
puertos permitidos proteger el acceso al clúster
de Kubernetes. Esta
el motor de AKS y
habilitado. Para más
información, consulte
oc.
Los contenedores de clúster Los contenedores solo audit, deny, disabled 3.0.0
de Kubernetes solo deben deben usar perfiles de
usar perfiles de AppArmor AppArmor permitidos en un
permitidos clúster de Kubernetes. Esta
recomendación forma parte
de las directivas de
seguridad de los pods,
diseñadas para mejorar la
seguridad de los entornos
de Kubernetes. Esta
el motor de AKS y
oc.
Los contenedores de clúster Restrinja las funcionalidades audit, deny, disabled 3.0.0
de Kubernetes solo deben para reducir la superficie de
usar funcionalidades contenedores expuesta a
permitidas ataques en un clúster de
Kubernetes. Esta
de las versiones 5.2.8
de los entornos de
oc.
Los contenedores de Use imágenes de registros audit, deny, disabled 6.1.0

clústeres de Kubernetes de confianza para reducir el
solo deben usar imágenes riesgo de exposición del
permitidas clúster de Kubernetes a
vulnerabilidades
desconocidas, problemas de
seguridad e imágenes
malintencionadas. Esta
el motor de AKS y
oc.
Los contenedores de clúster Los contenedores de pods audit, deny, disabled 3.0.0
de Kubernetes solo deben solo pueden usar perfiles de
usar perfiles de seccomp seccomp permitidos en los
permitidos clústeres de Kubernetes.
parte de las directivas de
de Kubernetes. Esta
el motor de AKS y
oc.
Los contenedores del Ejecute contenedores con audit, deny, disabled 3.0.0
clúster de Kubernetes un sistema de archivos raíz
deben ejecutarse con un de solo lectura para
sistema de archivos raíz de protegerlos de los cambios
solo lectura en tiempo de ejecución con
la incorporación de archivos
binarios malintencionados a
la ruta de acceso en un
clúster de Kubernetes. Esta
el motor de AKS y
oc.
Los volúmenes FlexVolume Los volúmenes FlexVolume audit, deny, disabled 3.0.0
del pod de clúster de del pod solo deben usar
Kubernetes solo deben usar controladores permitidos en
controladores permitidos los clústeres de Kubernetes.
de Kubernetes. Esta
el motor de AKS y
oc.
Los volúmenes hostPath del Limite los montajes de audit, deny, disabled 3.0.0
pod del clúster de volumen hostPath del pod a
Kubernetes solo deben usar las rutas de acceso de host
rutas de host permitidas permitidas en un clúster de
Kubernetes. Esta
de Kubernetes. Esta
el motor de AKS y
oc.
Los contenedores y pods de Controle los id. de usuario, audit, deny, disabled 3.0.0
clúster de Kubernetes solo grupo principal, grupo
deben ejecutarse con adicional y grupo de
identificadores de usuario y sistema de archivos que los
grupo aprobados pods y los contenedores
pueden usar para ejecutarse
en un clúster de
Kubernetes. Esta
de Kubernetes. Esta
el motor de AKS y
oc.
Los pods del clúster de Los pods solo pueden usar audit, deny, disabled 3.0.0
Kubernetes solo pueden tipos de volúmenes
usar tipos de volumen permitidos en los clústeres
permitidos de Kubernetes. Esta
de Kubernetes. Esta
el motor de AKS y
oc.
Los pods del clúster de Restringe el acceso de los audit, deny, disabled 3.0.0
Kubernetes solo pueden pods a la red del host y el
usar redes de host e intervalo de puertos de
intervalos de puerto host permitidos en un
de la versión 5.2.4 de CIS,
diseñada para mejorar la
de Kubernetes. Esta
el motor de AKS y
oc.
Los pods del clúster de Use las etiquetas audit, deny, disabled 6.0.0
Kubernetes deben usar especificadas para identificar
etiquetas especificadas los pods en un clúster de
oc.
Los servicios de clúster de Restrinja los servicios para audit, deny, disabled 6.1.0
Kubernetes solo deben que escuchen solo en
escuchar en los puertos puertos permitidos para
permitidos proteger el acceso al clúster
de Kubernetes. Esta
el motor de AKS y
oc.
Los servicios de clúster de Use direcciones IP externas audit, deny, disabled 3.0.0
Kubernetes solo deben usar permitidas para evitar un
direcciones IP externas ataque potencial (CVE-
permitidas 2020-8554) en un clúster
de Kubernetes. Para más
oc.
No permitir contenedores No permita la creación de audit, deny, disabled 6.0.0

con privilegios en el clúster contenedores con
de Kubernetes privilegios en un clúster de
Kubernetes. Esta
de Kubernetes. Esta
el motor de AKS y
oc.
Los clústeres de Kubernetes El uso de HTTPS garantiza la audit, deny, disabled 6.0.0
solo deben ser accesibles autenticación y protege los
mediante HTTPS datos en tránsito frente a
ataques de intercepción de
nivel de red. Esta
funcionalidad está
disponible actualmente con
el motor de AKS y
información, visite
oc
Los clústeres de Kubernetes Deshabilite las credenciales audit, deny, disabled 2.0.0-preview
deben deshabilitar las de la API de montaje
credenciales de la API de automático para evitar que
montaje automático un recurso de pod de riesgo
ejecute comandos de la API
en clústeres de Kubernetes.
Para más información,
consulte
oc.
Los clústeres de Kubernetes No permita que los audit, deny, disabled 3.0.0
no deben permitir la contenedores se ejecuten
elevación de privilegios del con elevación de privilegios
contenedor en la raíz en un clúster de
Kubernetes. Esta
de Kubernetes. Esta
el motor de AKS y
oc.
Los clústeres de Kubernetes Para reducir la superficie audit, deny, disabled 2.0.0-preview
no deben conceder expuesta a ataques de sus
funcionalidades de contenedores, restrinja las
seguridad funcionalidades
CAP_SYS_ADMIN. CAP_SYS_ADMIN de Linux.
consulte
oc.
Los clústeres de Kubernetes Evite las funcionalidades de audit, deny, disabled 2.0.0-preview
no deben usar seguridad específicas en los
funcionalidades de clústeres de Kubernetes
seguridad específicas para impedir los privilegios
no concedidos en el recurso
de pod. Para más
oc.
Los clústeres de Kubernetes Evite el uso del espacio de audit, deny, disabled 2.0.0-preview
no deben usar el espacio de nombres predeterminado
nombres predeterminado en los clústeres de
Kubernetes para proteger
del acceso no autorizado a
los tipos de recurso
ConfigMap, Pod, Secret,
Service y ServiceAccount.
consulte
oc.
Los clústeres de Kubernetes Use equilibradores de carga audit, deny, disabled 6.0.0
deben usar equilibradores internos para que un
de carga internos servicio de Kubernetes sea
accesible solo para las
aplicaciones que se ejecutan
en la misma red virtual que
el clúster de Kubernetes.
consulte
oc.
Kubernetes Services se Actualice el clúster de Audit, Disabled 1.0.2

debe actualizar a una servicio de Kubernetes a
versión de Kubernetes no una versión de Kubernetes
vulnerable posterior para protegerse
frente a vulnerabilidades
conocidas en la versión
actual de Kubernetes. La
vulnerabilidad CVE-2019-
9946 se ha revisado en las
versiones de Kubernetes
1.11.9+, 1.12.7+, 1.13.5+ y
1.14.0+
Se debe usar el control de Para proporcionar un Audit, Disabled 1.0.2

acceso basado en rol filtrado detallado de las
(RBAC) en los servicios de acciones que los usuarios
Kubernetes pueden realizar, use el
control de acceso basado
en rol (RBAC) para
administrar los permisos en
los clústeres de Kubernetes
Service y configurar las
directivas de autorización
correspondientes.
Los discos temporales y la Para mejorar la seguridad Audit, Deny, Disabled 1.0.0
memoria caché de los de los datos, los datos
grupos de nodos agente en almacenados en el host de
los clústeres de Azure las máquinas virtuales de
Kubernetes Service deben los nodos de Azure
cifrarse en el host Kubernetes Service deben
cifrarse en reposo. Este es
un requisito común de
muchos estándares de
cumplimiento normativo y
del sector.
Motor de AKS
( A ZURE PO RTA L) DESC RIP C IÓ N EF EC TO S ( GIT HUB)
Los límites de los recursos Aplique límites de recursos audit, deny, disabled 6.0.0
de memoria y CPU del de CPU y memoria de
contenedor no deben contenedor en un clúster de
superar los límites Kubernetes para evitar los
especificados en el clúster ataques de agotamiento de
de Kubernetes recursos. Esta directiva está
disponible con carácter
oc.
Los contenedores del No permita que los audit, deny, disabled 3.0.0
clúster de Kubernetes no contenedores de pods
deben compartir el compartan el espacio de
identificador de proceso del nombres de id. de proceso
host ni el espacio de de host ni el espacio de
nombres IPC del host nombres de IPC de host en
un clúster de Kubernetes.
parte de las versiones 5.2.2
de los entornos de
oc.
Los contenedores de clúster Los contenedores no deben audit, deny, disabled 4.0.0
de Kubernetes no deben usar interfaces sysctl
usar interfaces sysctl prohibidas en los clústeres
prohibidas de Kubernetes. Esta
de Kubernetes. Esta
el motor de AKS y
oc.
Los contenedores de Restrinja los contenedores audit, deny, disabled 6.1.0

clústeres de Kubernetes para que escuchen solo en
solo deben escuchar en los puertos permitidos para
puertos permitidos proteger el acceso al clúster
de Kubernetes. Esta
el motor de AKS y
oc.
Los contenedores de clúster Los contenedores solo audit, deny, disabled 3.0.0
de Kubernetes solo deben deben usar perfiles de
usar perfiles de AppArmor AppArmor permitidos en un
de Kubernetes. Esta
el motor de AKS y
oc.
Los contenedores de clúster Restrinja las funcionalidades audit, deny, disabled 3.0.0
de Kubernetes solo deben para reducir la superficie de
usar funcionalidades contenedores expuesta a
permitidas ataques en un clúster de
Kubernetes. Esta
de las versiones 5.2.8
de los entornos de
oc.
Los contenedores de Use imágenes de registros audit, deny, disabled 6.1.0

clústeres de Kubernetes de confianza para reducir el
solo deben usar imágenes riesgo de exposición del
permitidas clúster de Kubernetes a
vulnerabilidades
desconocidas, problemas de
seguridad e imágenes
malintencionadas. Esta
el motor de AKS y
oc.
de Kubernetes solo deben solo pueden usar tipos
usar el tipo ProcMountType ProcMountType permitidos
permitido en los clústeres de
Kubernetes. Esta
de Kubernetes. Esta
el motor de AKS y
oc.
de Kubernetes solo deben solo pueden usar perfiles de
usar perfiles de seccomp seccomp permitidos en los
permitidos clústeres de Kubernetes.
de Kubernetes. Esta
el motor de AKS y
oc.
Los contenedores del Ejecute contenedores con audit, deny, disabled 3.0.0
clúster de Kubernetes un sistema de archivos raíz
deben ejecutarse con un de solo lectura para
sistema de archivos raíz de protegerlos de los cambios
solo lectura en tiempo de ejecución con
la incorporación de archivos
binarios malintencionados a
la ruta de acceso en un
clúster de Kubernetes. Esta
el motor de AKS y
oc.
Los volúmenes FlexVolume Los volúmenes FlexVolume audit, deny, disabled 3.0.0
del pod de clúster de del pod solo deben usar
Kubernetes solo deben usar controladores permitidos en
controladores permitidos los clústeres de Kubernetes.
de Kubernetes. Esta
el motor de AKS y
oc.
Los volúmenes hostPath del Limite los montajes de audit, deny, disabled 3.0.0
pod del clúster de volumen hostPath del pod a
Kubernetes solo deben usar las rutas de acceso de host
rutas de host permitidas permitidas en un clúster de
Kubernetes. Esta
de Kubernetes. Esta
el motor de AKS y
oc.
Los contenedores y pods de Controle los id. de usuario, audit, deny, disabled 3.0.0
clúster de Kubernetes solo grupo principal, grupo
deben ejecutarse con adicional y grupo de
identificadores de usuario y sistema de archivos que los
grupo aprobados pods y los contenedores
pueden usar para ejecutarse
en un clúster de
Kubernetes. Esta
de Kubernetes. Esta
el motor de AKS y
oc.
Los pods y contenedores de Los pods y contenedores audit, deny, disabled 4.0.0
los clústeres de Kubernetes solo deben usar opciones
solo deben usar opciones de SELinux permitidas en
de SELinux permitidas los clústeres de Kubernetes.
de Kubernetes. Esta
el motor de AKS y
oc.
Los pods del clúster de Los pods solo pueden usar audit, deny, disabled 3.0.0
Kubernetes solo pueden tipos de volúmenes
usar tipos de volumen permitidos en los clústeres
permitidos de Kubernetes. Esta
de Kubernetes. Esta
el motor de AKS y
oc.
Los pods del clúster de Restringe el acceso de los audit, deny, disabled 3.0.0
Kubernetes solo pueden pods a la red del host y el
usar redes de host e intervalo de puertos de
intervalos de puerto host permitidos en un
de Kubernetes. Esta
el motor de AKS y
oc.
Los pods del clúster de Use las etiquetas audit, deny, disabled 6.0.0
Kubernetes deben usar especificadas para identificar
etiquetas especificadas los pods en un clúster de
oc.
Los servicios de clúster de Restrinja los servicios para audit, deny, disabled 6.1.0
Kubernetes solo deben que escuchen solo en
escuchar en los puertos puertos permitidos para
permitidos proteger el acceso al clúster
de Kubernetes. Esta
el motor de AKS y
oc.
Los servicios de clúster de Use direcciones IP externas audit, deny, disabled 3.0.0
Kubernetes solo deben usar permitidas para evitar un
direcciones IP externas ataque potencial (CVE-
permitidas 2020-8554) en un clúster
de Kubernetes. Para más
oc.
No permitir contenedores No permita la creación de audit, deny, disabled 6.0.0

con privilegios en el clúster contenedores con
de Kubernetes privilegios en un clúster de
Kubernetes. Esta
de Kubernetes. Esta
el motor de AKS y
oc.
Los clústeres de Kubernetes El uso de HTTPS garantiza la audit, deny, disabled 6.0.0
solo deben ser accesibles autenticación y protege los
mediante HTTPS datos en tránsito frente a
ataques de intercepción de
nivel de red. Esta
funcionalidad está
disponible actualmente con
el motor de AKS y
información, visite
oc
Los clústeres de Kubernetes Deshabilite las credenciales audit, deny, disabled 2.0.0-preview
deben deshabilitar las de la API de montaje
credenciales de la API de automático para evitar que
montaje automático un recurso de pod de riesgo
ejecute comandos de la API
en clústeres de Kubernetes.
consulte
oc.
Los clústeres de Kubernetes No permita que los audit, deny, disabled 3.0.0
no deben permitir la contenedores se ejecuten
elevación de privilegios del con elevación de privilegios
contenedor en la raíz en un clúster de
Kubernetes. Esta
de Kubernetes. Esta
el motor de AKS y
oc.
Los clústeres de Kubernetes Para reducir la superficie audit, deny, disabled 2.0.0-preview
no deben conceder expuesta a ataques de sus
funcionalidades de contenedores, restrinja las
seguridad funcionalidades
CAP_SYS_ADMIN. CAP_SYS_ADMIN de Linux.
consulte
oc.
Los clústeres de Kubernetes Evite las funcionalidades de audit, deny, disabled 2.0.0-preview
no deben usar seguridad específicas en los
funcionalidades de clústeres de Kubernetes
seguridad específicas para impedir los privilegios
no concedidos en el recurso
de pod. Para más
oc.
Los clústeres de Kubernetes Evite el uso del espacio de audit, deny, disabled 2.0.0-preview
no deben usar el espacio de nombres predeterminado
nombres predeterminado en los clústeres de
Kubernetes para proteger
del acceso no autorizado a
los tipos de recurso
ConfigMap, Pod, Secret,
Service y ServiceAccount.
consulte
oc.
Los clústeres de Kubernetes Use equilibradores de carga audit, deny, disabled 6.0.0
deben usar equilibradores internos para que un
de carga internos servicio de Kubernetes sea
accesible solo para las
aplicaciones que se ejecutan
en la misma red virtual que
el clúster de Kubernetes.
consulte
oc.
Pasos siguientes
Los elementos integrados se pueden encontrar en el repositorio de GitHub de Azure Policy.
Revise la estructura de definición de Azure Policy.
Vea la Descripción de los efectos de directivas.
Directivas de soporte técnico para Azure
Kubernetes Service
En este artículo se proporcionan detalles sobre las directivas de soporte técnico y las limitaciones de Azure
Kubernetes Service (AKS). En el artículo también se describen la administración de los nodos de agente, los
componentes del plano de control administrado, los componentes de código abierto de terceros y la
administración de la seguridad o las revisiones.
Actualizaciones de servicio y versiones

Para información sobre la versión, consulte las notas de la versión de AKS.
Para información sobre las características en versión preliminar, consulte AKS preview features and related
projects (Características en versión preliminar y proyectos relacionados de AKS).
Características administradas en AKS

Los componentes base de la nube de infraestructura como servicio (IaaS), como los de proceso o red,
proporcionan a los usuarios acceso a opciones de personalización y controles de nivel bajo. Por el contrario, AKS
proporciona una implementación de Kubernetes inmediata que le ofrece el conjunto habitual de
configuraciones y funcionalidades que necesita para su clúster. Como usuario de AKS, tiene opciones de
personalización e implementación limitadas. A cambio, no tiene que preocuparse de administrar directamente
los clústeres de Kubernetes.
Con AKS, obtiene un de plano de control totalmente administrado. El plano de control contiene todos los
componentes y servicios que debe ofrecer y proporciona clústeres de Kubernetes para los usuarios finales.
Todos los componentes de Kubernetes los mantiene y opera Microsoft.
Microsoft administra y supervisa los siguientes componentes mediante el panel de control:
Servidores de la API de Kubernetes o Kubelet
Etcd o un almacén de pares clave-valor compatible, que proporciona calidad de servicio (QoS), escalabilidad
y tiempo de ejecución
Servicios DNS (por ejemplo, kube-dns o CoreDNS)
Proxy o red de Kubernetes
Cualquier complemento adicional o componente del sistema que se ejecute en el espacio de nombres kube-
system
AKS no es una solución de plataforma como servicio (PaaS). Algunos componentes, como los nodos de agente,
tienen responsabilidad compartida con los usuarios para ayudar a mantener el clúster de AKS. Se requiere la
participación del usuario, por ejemplo, para aplicar una revisión de seguridad del sistema operativo en el nodo
de agente.
Los servicios son administrados en el sentido en que Microsoft y el equipo de AKS implementan y operan el
servicio, y son responsables de su disponibilidad y funcionalidad. Los clientes no pueden modificar estos
componentes administrados. Microsoft limita la personalización para garantizar una experiencia de usuario
coherente y escalable. Para una solución totalmente personalizable, consulte el motor de AKS.
Responsabilidad compartida
Cuando se crea un clúster, se definen los nodos de agente de Kubernetes que crea AKS. Las cargas de trabajo se
ejecutan en esos nodos.
Dado que los nodos de agente ejecutan código privado y almacenan información confidencial, el equipo de
Soporte técnico de Microsoft solo puede acceder a ellos con restricciones. El equipo de Soporte técnico de
Microsoft no puede iniciar sesión en estos nodos, ejecutar comandos en ellos ni ver sus registros sin el
consentimiento expreso o la asistencia del cliente.
Cualquier modificación realizada directamente en los nodos de agente mediante cualquiera de las API de IaaS
representa el clúster no compatible. Cualquier modificación realizada en los nodos del agente debe realizarse
mediante mecanismos kubernetes-native, como Daemon Sets .
Del mismo modo, aunque puede agregar metadatos al clúster y a los nodos, como etiquetas, si cambia
cualquiera de los metadatos creados por el sistema, el clúster no se admitirá.
Cobertura de soporte de AKS

Microsoft proporciona soporte técnico para lo siguiente:
Conectividad a todos los componentes de Kubernetes que el servicio Kubernetes proporciona y admite,
como el servidor de API.
La administración, el tiempo de actividad, la calidad de servicio y las operaciones de los servicios del plano
de control de Kubernetes (por ejemplo, el plano de control de Kubernetes, el servidor de API, etcd y kube-
dns).
Almacén de datos etcd. La compatibilidad incluye las copias de seguridad automatizadas y transparentes de
todos los datos de etcd cada 30 minutos para la restauración del estado del clúster y la planificación ante
desastres. Estas copias de seguridad no están directamente disponibles para los clientes o los usuarios.
Garantizan la coherencia y confiabilidad de los datos. Etcd. la reversión a petición o la restauración no se
admiten como una característica.
Los puntos de integración en el controlador del proveedor de nube de Azure para Kubernetes. Estos incluyen
las integraciones en otros servicios de Azure, como los equilibradores de carga, los volúmenes persistentes o
las redes (Kubernetes y Azure CNI).
Preguntas o problemas sobre la personalización de los componentes del plano de control, como el servidor
de API de Kubernetes, etcd y coreDNS.
Problemas relacionados con las redes, como Azure CNI, kubenet, u otros problemas de acceso de red y
funcionalidades. Podrían incluir los de resolución de DNS, pérdida de paquetes, enrutamiento, etc. Microsoft
admite diversos escenarios de redes:
Kubenet y Azure CNI mediante redes virtuales administradas o con subredes personalizadas (modelo
Traiga sus propias subredes).
Conectividad con otros servicios y aplicaciones de Azure
Controladores de entrada y las configuraciones del equilibrador de carga o de entrada
Rendimiento y latencia de la red
Directivas de red
NOTE
Todas las acciones de clúster realizadas por Microsoft/AKS se realizan con el consentimiento del usuario en un rol de
Kubernetes integrado aks-service y el enlace de roles integrado aks-service-rolebinding . Este rol permite a AKS
solucionar problemas de clústeres, pero no puede modificar permisos ni crear roles, enlaces de roles ni otras acciones de
privilegios elevados. El acceso a roles solo se habilita en incidencias de soporte técnico activos con acceso Just-in-Time
(JIT).
Microsoft no proporciona soporte técnico para lo siguiente:

Preguntas acerca de cómo usar Kubernetes. Por ejemplo, el Soporte técnico de Microsoft no aconseja sobre
la creación controladores de entrada personalizados, el uso de cargas de trabajo de aplicación o la aplicación
de herramientas o paquetes de software de código abierto de terceros.
NOTE
El Soporte técnico de Microsoft puede aconsejar sobre la funcionalidad del clúster de AKS, la personalización y los
ajustes (por ejemplo, los problemas y los procedimientos de las operaciones de Kubernetes).
Proyectos de código abierto de terceros que no se proporcionan como parte del plano de control de
Kubernetes o se implementan con clústeres de AKS. Estos proyectos pueden incluir Istio, Helm, Envoy u otros.
NOTE
Microsoft puede hacer lo posible por ayudar con proyectos de código abierto de terceros como Helm. Cuando la
herramienta de código abierto de terceros integre el proveedor de nube de Azure de Kubernetes u otros errores
específicos de AKS, Microsoft es compatible con ejemplos y aplicaciones de la documentación de Microsoft.
Software de código cerrado de terceros. Este software puede incluir herramientas de análisis de seguridad y
dispositivos o software de red.
Personalizaciones de red distintas de las que se enumeran en la documentación de AKS.
Cobertura de soporte técnico de AKS para los nodos de agente

Responsabilidades de Microsoft sobre los nodos de agente de AKS
Microsoft y los clientes comparten la responsabilidad sobre los nodos de agente de Kubernetes donde:
La imagen del sistema operativo base ha requerido adiciones (por ejemplo, agentes de red y de supervisión).
Los nodos de agente reciban automáticamente revisiones del sistema operativo.
Los problemas con los componentes del plano de control de Kubernetes que se ejecuten en los nodos de
agente se remedian automáticamente. Estos componentes incluyen lo siguiente:
Kube-proxy
Túneles de red que proporcionan rutas de acceso de comunicación para los componentes maestros de
Kubernetes
Kubelet
Moby o ContainerD
NOTE
Si un nodo de agente no está operativo, AKS podría reiniciar componentes individuales o todo el nodo de agente. Estas
operaciones de reinicio se automatizan y proporcionan corrección automática de los problemas comunes. Si desea
obtener más información sobre los mecanismos de corrección automática, consulte Reparación automática de nodo.
Responsabilidades del cliente sobre los nodos de agente de AKS

Microsoft proporciona revisiones y nuevas imágenes para los nodos de imagen semanalmente, pero no las
revisará automáticamente de forma predeterminada. Para mantener los componentes del sistema operativo y
del runtime del nodo de agente con las últimas revisiones, debe mantener una programación de actualizaciones
de imagen de nodo periódicas o automatizarlas.
De forma similar, AKS lanza periódicamente nuevas revisiones de Kubernetes y versiones secundarias. Estas
actualizaciones pueden contener mejoras de seguridad o funcionalidad para Kubernetes. Usted es el
responsable de mantener actualizada la versión de Kubernetes de los clústeres y de acuerdo con la directiva de
versión de compatibilidad con Kubernetes AKS.
Personalización de usuarios de nodos de agente
NOTE
Los nodos de agente de AKS aparecen en Azure Portal como recursos de Azure IaaS normales. No obstante, estas
máquinas virtuales se implementan en un grupo de recursos de Azure personalizado (normalmente, con el prefijo MC_*).
No se puede cambiar la imagen de sistema operativo base ni realizar ninguna personalización directa en estos nodos
mediante las API o los recursos de IaaS. Los cambios personalizados que no se realicen a través de la API de AKS no se
conservarán a través de una actualización, una escala, una actualización o un reinicio. Evite realizar cambios en los nodos
de agente a menos que el equipo de Soporte técnico de Microsoft le indique que realice cambios.
AKS administra el ciclo de vida y las operaciones de los nodos de agente en nombre de los clientes, por lo que
no admite la modificación de los recursos de IaaS asociados a los nodos de agente. Un ejemplo de una
operación no admitida es la personalización de un conjunto de escalado de máquinas virtuales del grupo de
nodos mediante la modificación manual de las configuraciones a través del portal o la API del conjunto de
En el caso de las configuraciones o paquetes específicos de la carga de trabajo, AKS recomienda usar Kubernetes
daemon sets .
El uso de contenedores de tipo init y daemon sets con privilegios de Kubernetes permite a los clientes ajustar,
modificar o instalar software de terceros en los nodos de agente del clúster. Algunos ejemplos de estas
personalizaciones incluyen agregar software personalizado de examen de seguridad o actualizar la
configuración de sysctl.
Aunque se trata de una ruta de acceso recomendada si se cumplen los requisitos anteriores, los servicios de
ingeniería y soporte técnico de AKS no pueden ayudarle en la solución de problemas, en el diagnóstico de
modificaciones que indiquen que el nodo no está disponible debido a un daemon set personalizado
implementado.
Problemas de seguridad y aplicación de revisiones
Si se encuentra un error de seguridad en uno o más componentes administrados de AKS, el equipo de AKS
revisará todos los clústeres afectados para mitigar el problema. Como alternativa, el equipo proporciona a los
usuarios instrucciones de actualización.
En el caso de los nodos de agente afectados por un error de seguridad, Microsoft le notificará con detalles sobre
el impacto y los pasos para corregir o mitigar el problema de seguridad (normalmente una actualización de
imagen de nodo o una actualización de la revisión de clúster).
Acceso a los nodos y mantenimiento
Aunque puede iniciar sesión en los nodos de agente y cambiarlos, esto no es recomendable, ya que los cambios
pueden hacer que un clúster deje de ser compatible.
Puertos de red, acceso y grupos de seguridad de red

Solo puede personalizar NSG en subredes personalizadas. No puede personalizar NSG en subredes
administradas o en el nivel de NIC de los nodos del agente. AKS tiene requisitos de salida para puntos de
conexión específicos, para controlar la salida y garantizar la conectividad necesaria; consulte Limitación del
tráfico de salida.
Clústeres detenidos o con asignación anuladas

Según se indicó anteriormente, la anulación manual de la asignación de todos los nodos de clúster a través de
las API de IaaS, la CLI o el portal representan el clúster fuera del soporte técnico. La única manera admitida de
detener y anular la asignación de todos los nodos es detener el clúster de AKS, que conservará el estado del
clúster durante 12 meses.
Los clústeres que se detienen durante más de 12 meses ya no conservarán el estado.
Los clústeres que se desasignan fuera de las API de AKS no tienen ninguna garantía de preservación del estado.
Los planes de control de los clústeres en este estado se archivarán después de 30 días y se eliminarán después
de 12 meses.
AKS se reserva el derecho de archivar los planos de control que se han configurado fuera de las directrices de
compatibilidad durante períodos prolongados iguales o superiores a 30 días. AKS mantiene copias de seguridad
de los metadatos de etcd del clúster y puede reasignar fácilmente el clúster. Esta reasignación puede iniciarse
con cualquier operación PUT haciendo que el clúster vuelva a ser compatible, como una actualización o un
escalado a los nodos de agente activos.
Si su suscripción se suspende o se elimina, el estado y el plano de control del clúster se eliminarán después de
90 días.
Características de Kubernetes alfa y beta no admitidas

Dentro del proyecto de Kubernetes ascendente, AKS solo admite características estables. A menos que se
documente lo contrario, AKS no admite características alfa que estén disponibles en el proyecto de Kubernetes
ascendente.
Características en versión preliminar o marcas de característica

Para las características y la funcionalidad que requieran pruebas ampliadas y comentarios de los usuarios,
Microsoft publica nuevas características en versión preliminar o características con una marca de característica.
Considere estas características como versión preliminar o características beta.
Las características en versión preliminar o con marca de característica no son para producción. Los cambios
continuos en las API y el comportamiento, las soluciones de errores y otros cambios pueden dar lugar a
inestabilidad en los clústeres y tiempo de inactividad.
Las características en versión preliminar pública suponen el mejor esfuerzo de soporte, por estar en versión
preliminar y no estar previstas para producción; se ocupan de ellas los equipos de soporte técnico de AKS
únicamente durante el horario comercial. Para más información, consulte:
Preguntas más frecuentes de soporte técnico de Azure
Problemas y errores ascendentes

Dada la velocidad de desarrollo del proyecto ascendente de Kubernetes, siempre se producen errores. Algunos
de estos errores no se pueden revisar o solucionar dentro del sistema de AKS. En su lugar, las correcciones de
errores requieren mayores revisiones en los proyectos ascendentes (como Kubernetes, los sistemas operativos
del nodo o de agente y kernels). Para los componentes que pertenecen a Microsoft (por ejemplo, el proveedor
de nube de Azure), el personal de AKS y Azure se comprometen a solucionar los problemas ascendentes en la
comunidad.
Cuando un problema de soporte técnico lo causa originalmente uno o más errores ascendentes, los equipos de
soporte técnico e ingeniería de AKS:
Identificarán y vincularán los errores ascendentes con detalles que lo justifiquen para intentar explicar por
qué afecta al clúster o a la carga de trabajo. Los clientes recibirán vínculos a los repositorios necesarios para
que puedan consultar los problemas y cuándo una nueva versión proporciona correcciones.
Proporcionarán posibles soluciones alternativas o mitigaciones. Si se puede mitigar el problema, se archivará
un problema conocido en el repositorio de AKS. En el archivo de problemas conocidos se explica:
El problema, con vínculos a los errores ascendentes.
La solución y los detalles sobre una actualización u otra manera de que la solución persista.
Escalas de tiempo aproximadas de la inclusión del problema en función de la cadencia de la versión
ascendente.
Preguntas más frecuentes sobre Azure Kubernetes
Service (AKS)
En este artículo se abordan las preguntas más frecuentes sobre Azure Kubernetes Service (AKS).
¿Qué regiones de Azure proporcionan actualmente AKS?

Para obtener una lista completa de las regiones disponibles, consulte AKS regions and availability (Regiones y
disponibilidad de AKS).
¿Puedo propagar un clúster de AKS entre regiones?

No. Los clústeres de AKS son recursos regionales y no pueden abarcar regiones. Consulte Procedimientos
recomendados de continuidad empresarial y recuperación ante desastres para obtener instrucciones sobre
cómo crear una arquitectura que incluya varias regiones.
¿Puedo propagar un clúster de AKS entre zonas de disponibilidad?

Sí. Puede implementar un clúster de AKS en una o más zonas de disponibilidad de regiones que las admitan.
¿Puedo limitar quién tiene acceso al servidor de API de Kubernetes?

Sí. Hay dos opciones para limitar el acceso al servidor de API:
Use intervalos de direcciones IP autorizadas del servidor de API si quiere mantener un punto de conexión
público para el servidor de API, pero restringir el acceso a un conjunto de intervalos de direcciones IP de
confianza.
Use un clúster privado si quiere limitar el servidor de API para que solo sea accesible desde dentro de la red
virtual.
¿Puedo tener diferentes tamaños de máquina virtual en un único

clúster?
Sí, puede usar diferentes tamaños de máquinas virtuales en el clúster de AKS mediante la creación de varios
grupos de nodos.
¿Se aplican las actualizaciones de seguridad a los nodos de agente de

AKS?
Azure aplica automáticamente revisiones de seguridad a los nodos de Linux del clúster siguiendo una
programación nocturna. Sin embargo, es responsabilidad suya asegurarse de que los nodos de Linux se
reinician según sea necesario. Cuenta con varias opciones para reiniciar los nodos:
Manualmente, mediante Azure Portal o la CLI de Azure.
Mediante la actualización del clúster de AKS. Las actualizaciones del clúster acordonan y purgan los nodos
automáticamente, y luego ponen un nuevo nodo en línea con la imagen de Ubuntu más reciente y una nueva
versión de revisión o una versión secundaria de Kubernetes. Para más información, consulte Actualización de
un clúster de Azure Kubernetes Service (AKS).
Mediante el uso de la actualización de imágenes de nodo.
Nodos de Windows Server
Para los nodos de Windows Server, Windows Update no ejecuta ni aplica las actualizaciones más recientes de
manera automática. En una programación normal del ciclo de versiones de Windows Update y su proceso de
validación propio, debe realizar una actualización en el clúster y los grupos de nodos de Windows Server en el
clúster de AKS. Este proceso de actualización crea nodos que ejecutan la imagen y las revisiones más recientes
de Windows Server y elimina los nodos anteriores. Para obtener más información sobre este proceso, consulte
Actualización de un grupo de nodos en AKS.
¿Por qué se crean dos grupos de recursos con AKS?

AKS se basa en diversos recursos de infraestructura de Azure, como los conjuntos de escalado de máquinas
virtuales, las redes virtuales y los discos administrados. Esto le permite utilizar muchas de las funcionalidades
básicas de la plataforma de Azure en el entorno de Kubernetes administrado que proporciona AKS. Por ejemplo,
la mayoría de los tipos de máquinas virtuales de Azure se pueden usar directamente con AKS, y Azure
Reservations se puede usar para recibir descuentos automáticamente en esos recursos.
Para habilitar esta arquitectura, cada implementación de AKS abarca dos grupos de recursos:
1. Debe cree el primer grupo de recursos. Este grupo solo contiene el recurso del servicio de Kubernetes. El
proveedor de recursos de AKS crea automáticamente el segundo grupo de recursos durante la
implementación. Un ejemplo del segundo grupo de recursos es
MC_myResourceGroup_myAKSCluster_eastus. Para obtener información sobre cómo especificar el nombre
de este segundo grupo de recursos, consulte la sección siguiente.
2. El segundo grupo de recursos, conocido como el grupo de recursos del nodo, contiene todos los recursos de
infraestructura asociados con el clúster. Estos recursos incluyen las máquinas virtuales de nodos de
Kubernetes, las redes virtuales y el almacenamiento. De forma predeterminada, el grupo de recursos del
nodo tiene un nombre como MC_myResourceGroup_myAKSCluster_eastus. AKS elimina automáticamente el
recurso del nodo cada vez que se elimina el clúster, por lo que solo se debe usar para los recursos que
comparten el ciclo de vida del clúster.
¿Puedo proporcionar mi propio nombre para el grupo de recursos del

nodo de AKS?
Sí. De forma predeterminada, AKS asignará el nombre MC_resourcegroupname_clustername_location al grupo
de recursos del nodo, pero también puede proporcionar su propio nombre.
Para especificar un nombre de su elección para el grupo de recursos, instale la versión de la extensión de la CLI
de Azure aks-preview 0.3.2 o una posterior. Cuando cree un clúster de AKS mediante el comando az aks create,
use el parámetro --node-resource-group y especifique un nombre para el grupo de recursos. Si usa una plantilla
de Azure Resource Manager para implementar un clúster de AKS, puede definir el nombre del grupo de
recursos mediante la propiedad nodeResourceGroup.
El proveedor de recursos de Azure crea automáticamente el grupo de recursos secundario en su propia
suscripción.
Solo puede especificar un nombre personalizado para el grupo de recursos cuando cree el clúster.
Cuando trabaje con el grupo de recursos del nodo, tenga en cuenta que no puede:
Especificar un grupo de recursos existente para el grupo de recursos del nodo.
Especificar otra suscripción para el grupo de recursos del nodo.
Cambiar el nombre del grupo de recursos del nodo una vez se haya creado el clúster.
Especificar los nombres de los recursos administrados del grupo de recursos del nodo.
Modificar o eliminar las etiquetas creadas en Azure de los recursos administrados del grupo de recursos del
nodo. (Puede ver la información adicional en la sección siguiente).
¿Puedo modificar etiquetas y otras propiedades de los recursos de

AKS en el grupo de recursos del nodo?
Si modifica o elimina etiquetas creadas por Azure y otras propiedades de recursos en el grupo de recursos del
nodo, es posible que obtenga resultados inesperados, como errores de escalado y actualización. AKS permite
crear y modificar etiquetas personalizadas generadas por usuarios finales, que se pueden agregar al crear un
grupo de nodos. Es posible que quiera crear o modificar etiquetas personalizadas, por ejemplo, para asignar un
centro de costos o una unidad de negocio. Esto también puede conseguirse creando directivas de Azure cuyo
ámbito sea el grupo de recursos administrado.
Sin embargo, la modificación de las etiquetas creadas por Azure en los recursos del grupo de recursos del
nodo en el clúster de AKS es una acción no admitida que interrumpe el objetivo de nivel de servicio (SLO). Para
obtener más información, consulte ¿AKS ofrece un contrato de nivel de servicio?
¿Qué controladores de admisión de Kubernetes admite AKS? ¿Se

pueden agregar o eliminar los controladores de admisión?
AKS admite los siguientes controladores de admisión:
NamespaceLifecycle
LimitRanger
ServiceAccount
DefaultStorageClass
DefaultTolerationSeconds
MutatingAdmissionWebhook
ValidatingAdmissionWebhook
ResourceQuota
PodNodeSelector
PodTolerationRestriction
ExtendedResourceToleration
Actualmente, no puede modificar la lista de controladores de admisión en AKS.
¿Puedo utilizar webhooks de controlador de admisión en AKS?

Sí, puede usar webhooks de controlador de admisión en AKS. Se recomienda excluir los espacios de nombres
internos de AKS que estén marcados con la etiqueta de plano de control . Por ejemplo, al agregar lo siguiente
a la configuración de webhook:
namespaceSelector:
matchExpressions:
- key: control-plane
operator: DoesNotExist
AKS pasa por el firewall la salida del servidor de la API, por lo que los webhooks del controlador de admisión
deben ser accesibles desde el clúster.
¿Los webhooks de controlador de admisión pueden afectar a los

espacios de nombres internos de kube-system y de AKS?
Para proteger la estabilidad del sistema y evitar que los controladores de admisión personalizados afecten a los
servicios internos de kube-system, el espacio de nombres de AKS tiene un ejecutor de admisiones , que
excluye automáticamente los espacios de nombres internos de kube-system y de AKS. Este servicio garantiza
que los controladores de admisión personalizados no afecten a los servicios que se ejecutan en kube-system.
Si tiene un caso de uso crítico por tener algo implementado en kube-system (no recomendado) que necesita
que esté incluido en el webhook de admisión personalizado, puede agregar la siguiente etiqueta o anotación
para que el factor de admisión lo omita.
Etiqueta: "admissions.enforcer/disabled": "true" o anotación: "admissions.enforcer/disabled": true
¿Azure Key Vault se integra con AKS?

AKS no está integrado de forma nativa con Azure Key Vault en estos momentos. Sin embargo, el proveedor de
Azure Key Vault para el almacén de secretos de CSI permite realizar una integración directa desde pods de
Kubernetes a los secretos de Key Vault.
¿Puedo ejecutar contenedores de Windows Server en AKS?

Sí, los contenedores de Windows Server están disponibles en AKS. Para ejecutar los contenedores de
Windows Server en AKS, cree un grupo de nodos que ejecute Windows Server como sistema operativo invitado.
Los contenedores de Windows Server solo pueden usar Windows Server 2019. Para empezar, vea Creación de
un clúster de AKS con un grupo de nodos de Windows Server.
La compatibilidad de Windows Server con el grupo de nodos incluye algunas limitaciones que forman parte de
la versión de Windows Server ascendente en el proyecto de Kubernetes. Para obtener más información sobre
estas limitaciones, consulte Windows Server containers in AKS limitations (Limitaciones de los contenedores de
Windows Server en AKS).
¿AKS ofrece un Acuerdo de Nivel de Servicio?

AKS proporciona garantías de Acuerdo de Nivel de Servicio como una característica opcional de complemento
con Acuerdo de Nivel de Servicio de tiempo de actividad.
La SKU gratuita que se ofrece de forma predeterminada no tiene ningún Acuerdo de Nivel de Servicio asociado,
pero tiene un Objetivo de Nivel de Servicio del 99,5 %. Podría suceder que aparecieran problemas de
conectividad transitorios en el caso de actualizaciones, nodos subyacentes incorrectos, mantenimiento de la
plataforma, aplicaciones que saturan el servidor de la API con solicitudes, etc. Si la carga de trabajo no tolera
reinicios del servidor de API, se recomienda usar el Acuerdo de nivel de servicio de tiempo de actividad.
¿Puedo aplicar descuentos de las reservas de Azure en mis nodos de

agente de AKS?
Los nodos de agente de AKS se facturan como máquinas virtuales de Azure estándares, por lo que, si ha
comprado reservas Azure para el tamaño de máquina virtual que está usando en AKS, los descuentos se aplican
automáticamente.
¿Puedo mover o migrar mi clúster entre inquilinos de Azure?

Actualmente, no puede mover el clúster de AKS entre inquilinos.
¿Puedo mover o migrar mi clúster entre suscripciones?

Actualmente no se admite el movimiento de clústeres entre suscripciones.
¿Puedo trasladar los clústeres de AKS de la suscripción actual de

Azure a otra?
No se admite el traslado de clústeres de AKS y de los recursos asociados entre suscripciones de Azure.
¿Puedo mover el clúster de AKS o los recursos de infraestructura de

AKS a otros grupos de recursos o cambiarles el nombre?
No se admite mover el clúster de AKS y sus recursos asociados ni cambiarles el nombre.
¿Por qué tarda tanto la eliminación del clúster?

La mayoría de los clústeres se eliminan en el momento de la solicitud del usuario; en algunos casos,
especialmente en aquellos en los que los clientes traen su propio grupo de recursos o se están realizando tareas
entre grupos de recursos, la eliminación puede tardar más tiempo o producir un error. Si tiene un problema con
las eliminaciones, compruebe que no tiene bloqueos en el grupo de recursos, que los recursos situados fuera
del grupo están desasociados de este, etc.
Si tengo un pod o implementaciones con el estado "NodeLost" (Nodo

perdido) o "Unknown" (Desconocido), ¿puedo actualizar el clúster?
Sí, pero no se recomienda en AKS. Las actualizaciones deberían realizarse si el estado del clúster es conocido o
correcto.
Si tengo un clúster con uno o varios nodos en un estado incorrecto o

apagado, ¿puedo realizar una actualización?
No, elimine o quite los nodos con un estado erróneo antes de actualizar.
Ejecuté una eliminación de clúster, pero me aparece el error

[Errno 11001] getaddrinfo failed
Normalmente, esto se debe a usuarios que tienen uno o varios grupos de seguridad de red (NSG) todavía en
uso y asociados al clúster. Quítelos e intente de nuevo la eliminación.
Ejecuté una actualización, pero ahora mis pods están en bucles de

bloqueo y se producen errores en los sondeos de preparación.
Confirme que la entidad de servicio no ha expirado. Consulte: Entidad de servicio de AKS y Credenciales de
actualización de AKS.
Mi clúster estaba funcionando, pero, de repente, no puede

aprovisionar equilibradores de carga, montar PVC, etc.
Confirme que la entidad de servicio no ha expirado. Consulte: Entidad de servicio de AKS y Credenciales de
actualización de AKS.
¿Puedo escalar el clúster de AKS a cero?

Puede detener completamente un clúster de AKS en ejecución, lo que ahorrará los costos de proceso
respectivos. Además, puede optar por escalar manual o automáticamente todos los grupos de nodos User o
algunos específicos a 0, manteniendo solo la configuración necesaria del clúster. No se pueden escalar
directamente grupos de nodos del sistema a 0.
¿Puedo usar las API del conjunto de escalado de máquinas virtuales

para escalar manualmente?
No, no se admiten las operaciones de escalado mediante el uso de las API del conjunto de escalado de máquinas
virtuales. Use las API de AKS ( az aks scale ).
¿Puedo usar conjuntos de escalado de máquinas virtuales para

escalar manualmente a 0 nodos?
No, no se admiten las operaciones de escalado mediante el uso de las API del conjunto de escalado de máquinas
virtuales. Puede usar la API de AKS para escalar a 0 grupos de nodos que no sean del sistema, o bien detener el
clúster en su lugar.
¿Puedo detener o cancelar la asignación de todas las máquinas

virtuales?
Aunque AKS tiene mecanismos de resistencia para admitir este tipo de configuración y recuperarse de él, no se
admite esta configuración. Detenga el clúster en su lugar.
¿Puedo usar extensiones de máquina virtual personalizadas?

Se admite el agente de Log Analytics porque es una extensión que administra Microsoft. De lo contrario, no, AKS
es un servicio administrado y no se admite la manipulación de los recursos de IaaS. Para instalar componentes
personalizados, use los mecanismos y las API de Kubernetes. Por ejemplo, aproveche DaemonSets para instalar
los componentes necesarios.
¿AKS guarda datos de los clientes fuera de la región del clúster?

La característica que permite almacenar los datos de clientes en una única región solo está disponible
actualmente en la región de Sudeste Asiático (Singapur) de la geoárea Asia Pacífico y en la región Sur de Brasil
(Estado de São Paulo) de la geoárea Brasil. En todas las demás regiones, los datos de clientes se almacenan en la
geoárea.
¿Las imágenes de AKS deben ejecutarse como raíz?

Excepto en el caso de las dos imágenes siguientes, no es necesario que las imágenes de AKS se ejecuten como
raíz:
mcr.microsoft.com/oss/kubernetes/coredns
mcr.microsoft.com/azuremonitor/containerinsights/ciprod
¿Qué diferencias hay entre el modo transparente de Azure CNI y el

modo puente?
A partir de la versión 1.2.0, Azure CNI tendrá habilitado el modo transparente de manera predeterminada para
las implementaciones CNI de un solo inquilino en Linux. El modo transparente va a reemplazar al modo puente.
En esta sección, indagaremos en las diferencias entre ambos modos y cuáles son las ventajas y limitaciones de
usar el modo transparente de Azure CNI.
Modo puente
Tal y como sugiere el nombre, el modo puente de Azure CNI, mediante "just-in-time", creará un puente L2
denominado "azure0". Todas las interfaces de par veth de los pods del host se conectarán a este puente. Por lo
tanto, la comunicación entre pods de las máquinas virtuales y el tráfico restante pasa a través de este puente. El
puente en cuestión es un dispositivo virtual de capa 2 que, por su cuenta, no puede recibir ni transmitir nada, a
menos que enlace uno o más dispositivos reales a él. Por este motivo, la interfaz eth0 de la máquina virtual
Linux debe convertirse en un puente subordinado a "azure0". Esto crea una topología de red compleja dentro de
la máquina virtual Linux y, como desventaja, CNI tenía que encargarse de otras funciones de red, como la
actualización del servidor DNS, etc.
A continuación se muestra un ejemplo de cuál es el aspecto de la configuración de la ruta IP en el modo puente.

Independientemente del número de pods que tenga el nodo, solo habrá dos rutas. En la primera se indica que
todo el tráfico, excluido el local en azure0, irá a la puerta de enlace predeterminada de la subred a través de la
interfaz con la dirección IP "src 10.240.0.4" (que es la dirección IP principal del nodo). En la segunda, se indica
que el espacio "10.20.x.x" es de pod a kernel, y el kernel toma la decisión.
default via 10.240.0.1 dev azure0 proto dhcp src 10.240.0.4 metric 100
10.240.0.0/12 dev azure0 proto kernel scope link src 10.240.0.4
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
root@k8s-agentpool1-20465682-1:/#
Modo transparente
El modo transparente adopta un enfoque directo para configurar redes de Linux. En este modo, Azure CNI no
cambia las propiedades de la interfaz eth0 en la máquina virtual Linux. Este enfoque mínimo para cambiar las
propiedades de red de Linux ayuda a reducir los problemas complejos que podrían encontrarse los clústeres en
el modo puente. En el modo transparente, Azure CNI creará y agregará interfaces de par veth de los pods del
host que se agregarán a la red del host. La comunicación entre pods de las máquinas virtuales se realiza a través
de las rutas IP que CNI agregará. Básicamente, la comunicación entre pods se realiza a través de la capa 3 y el
tráfico de los pods se enruta mediante reglas de enrutamiento L3.
A continuación se muestra un ejemplo de configuración de la ruta de IP del modo transparente, donde la

interfaz de cada pod obtendrá una ruta estática asociada para que el tráfico con la misma dirección IP de destino
que el pod se envíe directamente a la interfaz de par veth de los pods del host.
10.240.0.216 dev azv79d05038592 proto static

10.240.0.218 dev azv8184320e2bf proto static
10.240.0.219 dev azvc0339d223b9 proto static
10.240.0.222 dev azv722a6b28449 proto static
10.240.0.223 dev azve7f326f1507 proto static
10.240.0.224 dev azvb3bfccdd75a proto static
168.63.129.16 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
169.254.169.254 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
Ventajas del modo transparente
Proporciona mitigación para la condición de carrera paralela de DNS conntrack y evita los problemas de
latencia de DNS de 5 segundos sin necesidad de configurar el DNS local del nodo (puede seguir usándolo
por motivos de rendimiento).
Elimina la latencia inicial de 5 segundos de DNS que el modo puente de CNI causa actualmente debido a la
configuración del puente "just in time".
Uno de los casos extremos del modo puente es que Azure CNI no puede actualizar constantemente las listas
de servidores DNS personalizados que los usuarios agregan a la red virtual o la NIC. Como resultado, CNI
recoge solo la primera instancia de la lista de servidores DNS. Este problema se resuelve en el modo
transparente porque CNI no cambia las propiedades de eth0. Consulte más información aquí.
Se puede controlar mejor el tráfico UDP y se mitigan los desbordamientos de UDP cuando se agota el
tiempo de espera de ARP. En el modo puente, cuando el puente no conoce una dirección MAC del pod de
destino en la comunicación entre pods de las máquinas virtuales, de forma predeterminada, se genera una
avalancha de paquetes en todos los puertos. Este problema se resuelve en el modo transparente, ya que no
hay ningún dispositivo L2 en la ruta de acceso. Consulte más información aquí.
El modo transparente funciona mejor en la comunicación entre pods de las máquinas virtuales en términos
de rendimiento y latencia, en comparación con el modo puente.
¿Cómo evitar los problemas de lentitud debido a la configuración de

propiedad de permisos cuando el volumen tiene muchos archivos?
Tradicionalmente, si el pod se ejecuta como un usuario no raíz (como debería ser), debe especificar un elemento
fsGroup dentro del contexto de seguridad del pod para que el pod pueda leer y escribir en el volumen. Este
requisito se explica con más detalle aquí.
No obstante, un efecto secundario de la configuración fsGroup es que, cada vez que se monta un volumen,
Kubernetes debe ejecutar chown() y chmod() en todos los archivos y directorios dentro del volumen, con
algunas excepciones que se indican a continuación. Esto sucede incluso si la propiedad del grupo del volumen
ya coincide con el fsGroup solicitado y puede resultar bastante costoso para volúmenes mayores con muchos
archivos pequeños, por lo que el inicio del pod tarda mucho tiempo. Esta situación ha sido un problema
conocido antes de la versión v1.20 y la solución alternativa es configurar la ejecución del pod como raíz:
apiVersion: v1
kind: Pod
metadata:
spec:
securityContext:
runAsUser: 0
fsGroup: 0
El problema se resolvió con Kubernetes v1.20, consulte Kubernetes 1.20: Control granular de los cambios de
permisos de volumen para obtener más detalles.

Azure Kubernetes Service (AKS)

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Azure Kubernetes Service (AKS)

Cargado por

Copyright:

Formatos disponibles

Contents

Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) simplifica la implementación de un clúster de Kubernetes administrado en

AKS también admite contenedores de Windows Server.

Acceso, seguridad y supervisión

Redes virtuales y entrada

Integración de herramientas de desarrollo

Compatibilidad con imágenes de Docker y registro de contenedor

Si lo prefiere, instale la CLI de Azure para ejecutar sus comandos de referencia.

Crear un grupo de recursos

az group create --name myResourceGroup --location eastus

Salida del grupo de recursos que se creó correctamente:

Habilitación de la supervisión de clústeres

az provider show -n Microsoft.OperationsManagement -o table

Si no están registrados, use el siguiente comando para registrar Microsoft.OperationsManagement y

az provider register --namespace Microsoft.OperationsManagement

Creación de un clúster de AKS

az aks create --resource-group myResourceGroup --name myAKSCluster --node-count 1 --enable-addons monitoring

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

kubectl get nodes

NAME STATUS ROLES AGE VERSION

kubectl apply -f azure-vote.yaml

La salida muestra los servicios y las implementaciones que se crearon correctamente:

deployment "azure-vote-back" created

kubectl get service azure-vote-front --watch

La salida de EXTERNAL-IP del servicio azure-vote-front aparecerá inicialmente como pendiente.

azure-vote-front LoadBalancer 10.0.37.27 52.179.23.131 80:30572/TCP 2m

Eliminación del clúster

az group delete --name myResourceGroup --yes --no-wait

Obtención del código

Uso de Azure Cloud Shell

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

Vaya a https://shell.azure.com o seleccione el botón Iniciar

Seleccione el botón Cloud Shell en la barra de menús de la

Para ejecutar el código de este artículo en Azure Cloud Shell:

Set-AzContext -SubscriptionId 00000000-0000-0000-0000-000000000000

Crear un grupo de recursos

New-AzResourceGroup -Name myResourceGroup -Location eastus

Salida del grupo de recursos que se creó correctamente:

Creación de un clúster de AKS

New-AzAksCluster -ResourceGroupName myResourceGroup -Name myAKSCluster -NodeCount 1

Import-AzAksCredential -ResourceGroupName myResourceGroup -Name myAKSCluster

.\kubectl get nodes

NAME STATUS ROLES AGE VERSION

.\kubectl apply -f azure-vote.yaml

La salida muestra los servicios y las implementaciones que se crearon correctamente:

.\kubectl get service azure-vote-front --watch

La salida de EXTERNAL-IP del servicio azure-vote-front aparecerá inicialmente como pendiente.

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

azure-vote-front LoadBalancer 10.0.37.27 52.179.23.131 80:30572/TCP 2m

Eliminación del clúster

Remove-AzResourceGroup -Name myResourceGroup

Obtención del código

Creación de un clúster de AKS

4. Seleccione Siguiente: Grupos de nodos cuando haya terminado.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

kubectl get nodes

NAME STATUS ROLES AGE VERSION

kubectl apply -f azure-vote.yaml

La salida muestra los servicios y las implementaciones que se crearon correctamente:

kubectl get service azure-vote-front --watch

La salida de EXTERNAL-IP del servicio azure-vote-front aparecerá inicialmente como pendiente.