Procedimientos recomendados de implementación y confiabilidad del clúster para Azure Kubernetes Service (AKS)
En este artículo se proporcionan procedimientos recomendados para la confiabilidad del clúster implementado en un nivel de implementación y clúster para las cargas de trabajo de Azure Kubernetes Service (AKS). El artículo está destinado a operadores de clúster y desarrolladores responsables de implementar y administrar aplicaciones en AKS.
Los procedimientos recomendados de este artículo se organizan en las siguientes categorías:
Procedimientos recomendados de nivel de implementación
Los siguientes procedimientos recomendados de nivel de implementación ayudan a garantizar la alta disponibilidad y confiabilidad de las cargas de trabajo de AKS. Estos procedimientos recomendados son configuraciones locales que puede implementar en los archivos YAML para los pods e implementaciones.
Nota:
Asegúrese de implementar estos procedimientos recomendados cada vez que implemente una actualización en la aplicación. Si no es así, es posible que experimente problemas con la disponibilidad y confiabilidad de la aplicación, como el tiempo de inactividad accidental de la aplicación.
Presupuestos de interrupciones de pods (PDB)
Guía de procedimientos recomendados
Use los presupuestos de interrupciones de pods (PDB) para asegurarse de que un número mínimo de pods permanece disponible durante interrupciones voluntarias, como las operaciones de actualización o las eliminaciones accidentales del pod.
Los presupuestos de interrupciones de pods (PDB) le permiten definir cómo responden las implementaciones o conjuntos de réplicas durante interrupciones voluntarias, como las operaciones de actualización o las eliminaciones accidentales del pod. Con los archivos PDB, puede definir un recuento mínimo o máximo de recursos no disponible. Los archivos PDB solo afectan a la API de expulsión para interrupciones voluntarias.
Por ejemplo, supongamos que necesita realizar una actualización del clúster y que ya tiene un PDB definido. Antes de realizar la actualización del clúster, el programador de Kubernetes garantiza que el número mínimo de pods definidos en los PDB estén disponibles. Si la actualización haría que el número de pods disponibles estuviera por debajo del mínimo definido en los archivo PDB, el programador programa pods adicionales en otros nodos antes de permitir que la actualización continúe. Si no establece un PDB, el programador no tiene restricciones en el número de pods que pueden no estar disponibles durante la actualización, lo que puede provocar una falta de recursos y posibles interrupciones de clúster.
En el siguiente archivo de definición de PDB de ejemplo, el campo minAvailable establece el número mínimo de pods que deben permanecer disponibles durante las interrupciones voluntarias. El valor puede ser un número absoluto (por ejemplo, 3) o un porcentaje del número deseado de pods (por ejemplo, 10 %).
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: mypdb
spec:
minAvailable: 3 # Minimum number of pods that must remain available during voluntary disruptions
selector:
matchLabels:
app: myapp
Para obtener más información, consulte Planeación de disponibilidad mediante PDB y Especificar un presupuesto de interrupciones para la aplicación.
Límites de CPU/memoria de pod
Guía de procedimientos recomendados
Establezca los límites de CPU y memoria de pod para todos los pods para que no consuman todos los recursos de un nodo y para proporcionar protección durante las amenazas de servicio, como los ataques DDoS.
Los límites de CPU y memoria del pod definen la cantidad máxima de CPU y memoria que puede usar un pod. Cuando un pod supera sus límites definidos, se marca para su eliminación. Para obtener más información, consulte Unidades de recursos de CPU en Kubernetes y Unidades de recursos de memoria en Kubernetes.
Establecer límites de CPU y memoria le ayuda a mantener el estado del nodo y minimiza el impacto en otros pods del nodo. 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. Si establece un límite de pods superior al que el nodo puede soportar, su aplicación podría intentar consumir demasiados recursos e impactar negativamente en otros pods del nodo. 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 más información, consulte Aplicación de cuotas de recursos en AKS.
En el siguiente archivo de definición de pod de ejemplo, la sección resources establece los límites de CPU y memoria para el pod:
kind: Pod
apiVersion: v1
metadata:
name: mypod
spec:
containers:
- name: mypod
image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
Sugerencia
Puede usar el comando kubectl describe node para ver la capacidad de CPU y memoria de los nodos, como se muestra en el ejemplo siguiente:
kubectl describe node <node-name>
# Example output
Capacity:
cpu: 8
ephemeral-storage: 129886128Ki
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 32863116Ki
pods: 110
Allocatable:
cpu: 7820m
ephemeral-storage: 119703055367
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 28362636Ki
pods: 110
Para obtener más información, consulte Asignar recursos de CPU a contenedores y pods y Asignar recursos de memoria a contenedores y pods.
Enlaces previos a la detención
Guía de procedimientos recomendados
Cuando proceda, use enlaces previos a la detención para garantizar la terminación correcta de un contenedor.
Se llama a un enlace PreStop inmediatamente antes de que un contenedor finalice debido a una solicitud de API o evento de administración, como el adelantamiento, la contención de recursos o un error de sondeo de ejecución o inicio. Se produce un error en una llamada al enlace de PreStop si el contenedor ya está en un estado terminado o completado, y el enlace debe completarse antes de que se envíe la señal TERM para detener el contenedor. La cuenta atrás del período de gracia de finalización del pod comienza antes de que se ejecute el enlace de PreStop, por lo que el contenedor termina finalmente dentro del período de gracia de terminación.
En el siguiente archivo de definición de pod de ejemplo se muestra cómo usar un enlace de PreStop para garantizar una terminación correcta de un contenedor:
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-demo
spec:
containers:
- name: lifecycle-demo-container
image: nginx
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
preStop:
exec:
command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"]
Para obtener más información, consulte Enlaces de ciclo de vida del contenedor y Terminación de pods.
maxUnavailable
Guía de procedimientos recomendados
Defina el número máximo de pods que pueden no estar disponibles durante una actualización gradual mediante el campo
maxUnavailablede la implementación para asegurarse de que un número mínimo de pods permanece disponible durante la actualización.
El campo maxUnavailable especifica el número máximo de pods que pueden no estar disponibles durante el proceso de actualización. El valor puede ser un número absoluto (por ejemplo, 3) o un porcentaje del número deseado de pods (por ejemplo, 10 %). maxUnavailable pertenece a la API de eliminación, que se usa durante las actualizaciones graduales.
En el siguiente manifiesto de implementación de ejemplo se usa el campo maxAvailable para establecer el número máximo de pods que pueden no estar disponibles durante el proceso de actualización:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1 # Maximum number of pods that can be unavailable during the upgrade
Para más información, consulte Máximo no disponible.
Restricciones de propagación de topología de pod
Guía de procedimientos recomendados
Use restricciones de propagación de topología de pod para asegurarse de que los pods se distribuyen entre distintos nodos o zonas para mejorar la disponibilidad y la confiabilidad.
Puede usar restricciones de propagación de topología de pod para controlar cómo se distribuyen los pods en el clúster en función de la topología de los nodos y distribuir pods entre distintos nodos o zonas para mejorar la disponibilidad y la fiabilidad.
En el siguiente archivo de definición de pod de ejemplo se muestra cómo usar el campo topologySpreadConstraints para distribuir pods entre distintos nodos:
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
# Configure a topology spread constraint
topologySpreadConstraints:
- maxSkew: <integer>
minDomains: <integer> # optional
topologyKey: <string>
whenUnsatisfiable: <string>
labelSelector: <object>
matchLabelKeys: <list> # optional
nodeAffinityPolicy: [Honor|Ignore] # optional
nodeTaintsPolicy: [Honor|Ignore] # optional
Para obtener más información, consulte Restricciones de propagación de topología de pod.
Sondeos de preparación, ejecución e inicio
Guía de procedimientos recomendados
Configure los sondeos de preparación, ejecución e inicio cuando sea aplicable para mejorar la resistencia de las cargas altas y reducir los reinicios de contenedores.
Sondeos de preparación
En Kubernetes, kubelet usa sondeos de preparación para saber cuándo un contenedor está listo para empezar a aceptar el tráfico. Un pod se considera listo cuando todos sus contenedores estén listos. Cuando un pod no está listo, se quita de los equilibradores de carga de servicio. Para más información, consulte Sondeos de preparación en Kubernetes.
En el siguiente archivo de definición de pod de ejemplo se muestra una configuración de sondeo de preparación:
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
Para más información, consulte Configuración de los sondeos de preparación.
Sondeos de ejecución
En Kubernetes, kubelet usa sondeos de ejecución para saber cuándo reiniciar un contenedor. Si se produce un error en el sondeo de ejecución de un contenedor, se reinicia el contenedor. Para más información, consulte Sondeos de ejecución en Kubernetes.
En el siguiente archivo de definición de pod de ejemplo se muestra una configuración de sondeo de ejecución:
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
Otro tipo de sondeo de ejecución usa una solicitud HTTP GET. En el siguiente archivo de definición de pod de ejemplo se muestra una configuración de sondeo de ejecución de solicitud HTTP GET:
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-http
spec:
containers:
- name: liveness
image: registry.k8s.io/liveness
args:
- /server
livenessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: Custom-Header
value: Awesome
initialDelaySeconds: 3
periodSeconds: 3
Para obtener más información, consulte Configurar sondeos de ejecución y Definir una solicitud HTTP de ejecución.
Sondeos de inicio
En Kubernetes, kubelet usa sondeos de inicio para saber cuándo se ha iniciado una aplicación contenedora. Al configurar un sondeo de inicio, los sondeos de preparación y ejecución no se inician hasta que el sondeo de inicio se realiza correctamente, lo que garantiza que los sondeos de preparación y ejecución no interfieren con el inicio de la aplicación. Para más información, consulte Sondeos de inicio en Kubernetes.
En el siguiente archivo de definición de pod de ejemplo se muestra una configuración de sondeo de inicio:
startupProbe:
httpGet:
path: /healthz
port: 8080
failureThreshold: 30
periodSeconds: 10
Aplicaciones multiréplica
Guía de procedimientos recomendados
Implemente al menos dos réplicas de la aplicación para garantizar la alta disponibilidad y resistencia en escenarios de nodo inactivo.
En Kubernetes, puede usar el campo replicas de la implementación para especificar el número de pods que desea ejecutar. La ejecución de varias instancias de la aplicación ayuda a garantizar la alta disponibilidad y resistencia en escenarios de nodo inactivo. Si tiene zonas de disponibilidad habilitadas, puede usar el campo replicas para especificar el número de pods que desea ejecutar en varias zonas de disponibilidad.
En el siguiente archivo de definición de pod de ejemplo se muestra cómo usar el campo replicas para especificar el número de pods que desea ejecutar:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
Para obtener más información, consulte Descripción general de la solución de alta disponibilidad activa-activa recomendada para AKS y Réplicas en especificaciones de implementación.
Procedimientos recomendados de nivel de clúster y grupo de nodos
Los siguientes procedimientos recomendados de nivel de clúster y grupo de nodos ayudan a garantizar la alta disponibilidad y confiabilidad de las cargas de trabajo de AKS. Puede implementar estos procedimientos recomendados al crear o actualizar los clústeres de AKS.
Zonas de disponibilidad
Guía de procedimientos recomendados
Use varias zonas de disponibilidad al crear un clúster de AKS para garantizar la alta disponibilidad en escenarios de zona descendiente. Tenga en cuenta que no puede cambiar la configuración de la zona de disponibilidad después de crear el clúster.
Las zonas de disponibilidad son grupos separados de centros de datos dentro de una región. Estas zonas están lo suficientemente cerca como para tener conexiones de baja latencia las unas con las otras, pero están lo suficientemente separadas como para reducir la probabilidad de que más de una zona se vea afectada por interrupciones locales o el tiempo. El uso de zonas de disponibilidad ayuda a que los datos permanezcan sincronizados y accesibles en escenarios de zona descendente. Para obtener más información, consulte Ejecución en varias zonas.
Escalado automático del clúster
Guía de procedimientos recomendados
Use el escalado automático del clúster para asegurarse de que el clúster puede controlar una mayor carga y reducir los costos durante una carga baja.
Para satisfacer las necesidades de la aplicación en 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 supervisa los pods del clúster que no pueden programarse debido a las restricciones de los recursos. Cuando la escalabilidad automática de clústeres detecta problemas, escala verticalmente el número de nodos del grupo de nodos para satisfacer la demanda de la aplicación. Además, comprueba periódicamente los nodos por si faltan pods en ejecución y reduce verticalmente la cantidad de nodos según sea necesario. Para más información, consulte Autoescalado de clústeres en AKS.
Puede usar el parámetro --enable-cluster-autoscaler al crear un clúster de AKS para habilitar el escalador automático del clúster, como se muestra en el ejemplo siguiente:
az aks create \
--resource-group myResourceGroup \
--name myAKSCluster \
--node-count 2 \
--vm-set-type VirtualMachineScaleSets \
--load-balancer-sku standard \
--enable-cluster-autoscaler \
--min-count 1 \
--max-count 3 \
--generate-ssh-keys
También puede habilitar el escalador automático de clústeres en un grupo de nodos existente y 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.
Para más información, consulte Uso de la escalabilidad automática en AKS.
Standard Load Balancer
Guía de procedimientos recomendados
Use Standard Load Balancer para proporcionar mayor confiabilidad y recursos, compatibilidad con varias zonas de disponibilidad, sondeos HTTP y funcionalidad en varios centros de datos.
En Azure, el SKU de Standard Load Balancer está diseñado para estar equipado para equilibrar la carga del tráfico de la capa de red cuando se necesitan un alto rendimiento y una baja latencia. El Standard Load Balancer enruta el tráfico dentro y entre regiones, y a zonas de disponibilidad para lograr una alta resistencia. La SKU estándar es la SKU recomendada y predeterminada que se usará al crear un clúster de AKS.
Importante
El 30 de septiembre de 2025, se retirará Basic Load Balancer. Para obtener más información, consulte el anuncio oficial. Se recomienda usar Standard Load Balancer para nuevas implementaciones y actualizar las implementaciones existentes a Standard Load Balancer. Para más información, consulte Actualización desde el Load Balancer básico.
En el ejemplo siguiente se muestra un manifiesto de servicio de LoadBalancer que usa Standard Load Balancer:
apiVersion: v1
kind: Service
metadata:
annotations:
service.beta.kubernetes.io/azure-load-balancer-ipv4 # Service annotation for an IPv4 address
name: azure-load-balancer
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: azure-load-balancer
Para más información, consulte Uso de un equilibrador de carga estándar en AKS.
Sugerencia
También puede usar un controlador de entrada o una malla de servicio para administrar el tráfico de red, con cada opción que proporciona características y funcionalidades diferentes.
Grupos de nodos de sistema
Uso de grupos de nodos del sistema dedicados
Guía de procedimientos recomendados
Use grupos de nodos del sistema para asegurarse de que ninguna otra aplicación de usuario se ejecute en los mismos nodos, lo que puede causar escasez de recursos y afectar a los pods del sistema.
Use grupos de nodos del sistema dedicados para garantizar que ninguna otra aplicación de usuario se ejecute en los mismos nodos, lo que puede provocar escasez de recursos y posibles interrupciones de clúster debido a condiciones de carrera. Para usar un grupo de nodos del sistema dedicado, puede usar la intolerancia CriticalAddonsOnly en el grupo de nodos del sistema. Para obtener más información, consulte Uso de pods de nodos del sistema en AKS.
Escalado automático de grupos de nodos del sistema
Guía de procedimientos recomendados
Configure el escalador automático para los grupos de nodos del sistema para establecer los límites de escalado mínimo y máximo para el grupo de nodos.
Use el escalador automático en los grupos de nodos para configurar los límites de escalado mínimo y máximo para el grupo de nodos. El grupo de nodos del sistema siempre debe ser capaz de escalar para satisfacer las demandas de los pods del sistema. Si el grupo de nodos del sistema no puede escalarse, el clúster se queda sin recursos para ayudar a administrar la programación, el escalado y el equilibrio de carga, lo que puede provocar que un clúster no responda.
Para obtener más información, consulte Uso del escalador automático de clústeres en grupos de nodos.
Al menos tres nodos por grupo de nodos del sistema
Guía de procedimientos recomendados
Asegúrese de que los grupos de nodos del sistema tienen al menos tres nodos para garantizar la resistencia frente a escenarios de inmovilización o actualización, lo que puede provocar que los nodos se reinicien o apaguen.
Los grupos de nodos del sistema se usan para ejecutar pods del sistema, como kube-proxy, coredns y el complemento de Azure CNI. Le recomendamos que se asegure de que los grupos de nodos del sistema tienen al menos tres nodos para garantizar la resistencia frente a escenarios de inmovilización o actualización, lo que puede provocar que los nodos se reinicien o apaguen. Para obtener más información, consulte Administración de pods de nodos del sistema en AKS.
Redes aceleradas
Guía de procedimientos recomendados
Use redes aceleradas para proporcionar una menor latencia, una vibración reducida y una disminución del uso de la CPU en las máquinas virtuales.
Las redes aceleradas permiten la virtualización de E/S de raíz única (SR-IOV) en los tipos de máquina virtual compatibles, lo que mejora considerablemente el rendimiento de las redes.
En el diagrama siguiente, se muestra la comunicación entre dos VM con y sin redes aceleradas:
Para más información, consulte Introducción a las redes aceleradas.
Versiones de la imagen
Guía de procedimientos recomendados
Las imágenes no debe usar la etiqueta
latest.
Etiquetas de imágenes de contenedor
El uso de la etiqueta latest para imágenes de contenedor puede provocar un comportamiento impredecible y dificulta el seguimiento de la versión de la imagen que se ejecuta en el clúster. Puede minimizar estos 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. Para obtener más información, consulte Procedimientos recomendados para la administración de las imágenes de contenedor en AKS.
Actualizaciones de imágenes de nodo
AKS proporciona varios canales de actualización automática para las actualizaciones de imágenes del sistema operativo del nodo. Puede usar estos canales para controlar el tiempo de las actualizaciones. Se recomienda unir estos canales de actualización automática para asegurarse de que los nodos ejecutan las actualizaciones y parches de seguridad más recientes. Para más información, consulte Actualización automática de imágenes del sistema operativo del nodo en AKS.
Nivel estándar para cargas de trabajo de producción
Guía de procedimientos recomendados
Use el nivel estándar para cargas de trabajo de producto para mayor confiabilidad y recursos del clúster, compatibilidad con hasta 5000 nodos en un clúster y el Acuerdo de Nivel de Servicio de tiempo de actividad habilitado de forma predeterminada. Si necesita LTS, considere la posibilidad de usar el nivel Premium.
El nivel estándar para Azure Kubernetes Service (AKS) proporciona un acuerdo de nivel de servicio (SLA) de tiempo de actividad del 99,9 % con respaldo financiero para sus cargas de trabajo de producción. El nivel estándar también ofrece una mayor confiabilidad y recursos del clúster, compatibilidad con hasta 5000 nodos en un clúster y el Acuerdo de Nivel de Servicio de tiempo de actividad habilitado de forma predeterminada. Para más información, consulte Planes de tarifa para la administración de clústeres de AKS.
Azure CNI para la asignación dinámica de IP
Guía de procedimientos recomendados
Configure Azure CNI para la asignación dinámica de IP para mejorar el uso de IP y evitar el agotamiento de IP para clústeres de AKS.
La capacidad de asignación dinámica de direcciones IP de Azure CNI asigna direcciones IP de pods de una subred que es independiente de la subred que hospeda el clúster de AKS y ofrece 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 virtual 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 los pods y no para los nodos, la corrección de la IP de origen para los pods en un grupo de nodos mediante Azure NAT Gateway 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.
Para más información, consulte Configuración de redes de Azure CNI para la asignación dinámica de direcciones IP y compatibilidad mejorada con subredes.
Máquinas virtuales de SKU v5
Guía de procedimientos recomendados
Use SKU de máquina virtual v5 para mejorar el rendimiento durante y después de las actualizaciones, reducir el impacto general y tener una conexión más confiable para las aplicaciones.
En el caso de los grupos de nodos de AKS, use máquinas virtuales de SKU v5 con discos de SO efímeros para proporcionar recursos de proceso suficientes para pods kube-system. Para obtener más información, consulte Procedimientos recomendados para el rendimiento y el escalado de cargas de trabajo grandes en AKS.
No usar máquinas virtuales de la serie B
Guía de procedimientos recomendados
No use máquinas virtuales de la serie B para clústeres de AKS porque son de bajo rendimiento y no funcionan bien con AKS.
Las máquinas virtuales de la serie B son de bajo rendimiento y no funcionan bien con AKS. En su lugar, se recomienda usar máquinas virtuales de SKU v5.
Discos premium
Guía de procedimientos recomendados
Use discos prémium para lograr una disponibilidad del 99,9 % en una máquina virtual (VM).
Los discos prémium de Azure ofrecen una latencia de disco inferior a milisegundos coherente, y un alto rendimiento e IOPS. Los discos prémium están diseñados para proporcionar un rendimiento de disco coherente, de baja latencia y de alto rendimiento para las máquinas virtuales.
En el siguiente manifiesto YAML de ejemplo se muestra una definición de clase de almacenamiento para un disco prémium:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: premium2-disk-sc
parameters:
cachingMode: None
skuName: PremiumV2_LRS
DiskIOPSReadWrite: "4000"
DiskMBpsReadWrite: "1000"
provisioner: disk.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
Para más información, consulte Uso de discos SSD prémium v2 de Azure en AKS.
Información sobre Container
Guía de procedimientos recomendados
Habilite Container Insights para supervisar y diagnosticar el rendimiento de las aplicaciones en contenedor.
Container Insights es una característica de Azure Monitor que recopila y analiza los registros de contenedor de AKS. Puede analizar los datos recopilados con una colección de vistas y libros creados previamente.
Puede habilitar la supervisión de Container Insights en el clúster de AKS mediante varios métodos. En el ejemplo siguiente se muestra cómo habilitar la supervisión de Container Insights en un clúster existente mediante la CLI de Azure:
az aks enable-addons -a monitoring --name myAKSCluster --resource-group myResourceGroup
Para más información, consulte Habilitar la supervisión de clústeres de Kubernetes.
Azure Policy
Guía de procedimientos recomendados
Aplique y haga cumplir los requisitos de seguridad y cumplimiento de los clústeres de AKS mediante Azure Policy.
Puede aplicar y hacer cumplir directivas de seguridad integradas en sus clústeres de AKS mediante Azure Policy. Azure Policy ayuda a hacer cumplir los estándares de la organización y evalúa el cumplimiento a escala. Después de instalar el complemento de Azure Policy para AKS, puede aplicar a su clúster definiciones de políticas individuales o grupos de definiciones de políticas denominadas iniciativas para sus clústeres.
Para más información, consulte Proteger los clústeres de AKS con Azure Policy.
Pasos siguientes
Este artículo se ha centrado en los procedimientos recomendados de implementación y fiabilidad de clústeres para clústeres de Azure Kubernetes Service (AKS). Consulte los siguientes artículos para obtener más procedimientos recomendados:
Azure Kubernetes Service