Prácticas recomendadas para las características básicas del planificador 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. El programador de Kubernetes permite controlar la distribución de los recursos de proceso y limitar el impacto de los eventos de mantenimiento.

Este artículo de procedimientos recomendados se centra en las características básicas de programación de Kubernetes para operadores de clúster. En este artículo aprenderá a:

Aplicación de cuotas de recursos

Guía de procedimientos recomendados

Planee y aplique cuotas de recursos en el nivel del espacio de nombres. Use cuotas y intervalos de límite para requerir o proporcionar solicitudes y límites de recursos predeterminados para pods. Supervise el uso de recursos y ajuste las cuotas según sea necesario.

Establezca las solicitudes de recursos y los límites de recursos en la especificación del pod. Una solicitud de recurso es la cantidad de CPU o memoria que usa el programador de Kubernetes para colocar un pod. Un límite de recursos restringe la cantidad de ese recurso que puede usar un contenedor. El sistema aplica los límites de CPU mediante la limitación, mientras que aplica los límites de memoria de forma reactiva a través de la terminación fuera de memoria (OOM). Para obtener más información, consulte Definición de límites y solicitudes de recursos de pod.

Use cuotas de recursos para limitar el consumo agregado de recursos para un equipo de desarrollo o un proyecto. Defina cuotas en el nivel de espacio de nombres para:

• 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.

El programador de Kubernetes usa solicitudes de recursos para colocar pods. Los contenedores pueden usar más CPU o memoria que la solicitada cuando la capacidad está disponible y los límites de recursos pueden superar las solicitudes. Una cuota de recursos limita por separado el consumo de espacio de nombres agregado. Si la creación o actualización de un recurso superaría una cuota dura, el servidor de API rechaza la solicitud con una respuesta HTTP 403 Forbidden . Todavía puede crear un objeto de carga de trabajo, como una implementación, incluso cuando la cuota impide que su controlador cree todos los pods solicitados.

Si una cuota de recursos realiza un seguimiento de la CPU o la memoria, cada pod nuevo debe especificar una solicitud o un límite para ese recurso. De lo contrario, el servidor de API podría rechazar el pod. Puede configurar solicitudes y límites predeterminados para un espacio de nombres mediante limitRange.

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 limita las solicitudes de CPU agregadas en 10 CPU, las solicitudes de memoria agregadas en 20Gi y el número de pods no predeterminados en 10 en el espacio de nombres.

Aplique esta cuota de recursos a un 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.

Limitar el impacto en la interrupción mediante presupuestos de interrupciones de pods (PDB)

Guía de procedimientos recomendados

Defina los presupuestos de interrupciones de pods (PDB) para las aplicaciones replicadas para limitar las expulsiones voluntarias simultáneas durante eventos como purgas de nodos de AKS. Mantenga suficientes réplicas correctas y permita al menos una interrupción cuando la carga de trabajo permita para que el mantenimiento del clúster pueda continuar.

Los eventos disruptivos que quitan pods se dividen en dos categorías:

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. Algunos ejemplos son:

• Error de hardware en la máquina física
• Pánico de kernel
• Eliminación de una máquina virtual de nodo

Puede mitigar las interrupciones involuntarias mediante:

• El uso de varias réplicas de los pods en una implementación.
• Ejecución de varios nodos en el clúster de AKS.

Interrupciones voluntarias

_ Los disruptions_ voluntarios son eventos que solicita el operador de clúster o el propietario de la aplicación. Algunos ejemplos son:

• Purga de un nodo durante una actualización del clúster
• Actualización de una plantilla de implementación
• Eliminación directa de un pod

No todas las interrupciones voluntarias están restringidas por PDB. La eliminación directa de un pod o un objeto de carga de trabajo omite los archivos PDB y los controladores de carga de trabajo, como implementaciones y StatefulSets, no están limitados por PDB durante las actualizaciones graduales. Configure la estrategia de lanzamiento de la carga de trabajo por separado para mantener la disponibilidad durante las actualizaciones de la aplicación. Para más información, consulte Interrupciones en Kubernetes.

Los ARCHIVOS PDF limitan las expulsiones voluntarias simultáneas para los pods seleccionados a través de la API de expulsión de Kubernetes. Durante una actualización gradual de AKS, AKS agrega capacidad de sobrecarga según la configuración del grupo de nodos, acordona y purga un nodo y, a continuación, vuelve a crear imágenes o reemplaza el nodo purgado. La API de expulsión evalúa el PDB durante el drenaje. Después de una expulsión, el controlador de carga de trabajo crea un pod de reemplazo y el programador lo coloca en un nodo con capacidad disponible. Una PDB restrictiva, réplicas correctas insuficientes o una capacidad de clúster insuficiente puede retrasar o bloquear el drenaje.

Establecimiento de un número mínimo de pods disponibles

Considere un objeto ReplicaSet con cinco pods NGINX etiquetados app: nginx-frontend. Durante un evento de interrupción voluntaria, como una actualización del clúster, al menos tres pods deben permanecer disponibles. El siguiente PodDisruptionBudget manifiesto define este requisito:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  minAvailable: 3
  unhealthyPodEvictionPolicy: AlwaysAllow
  selector:
    matchLabels:
      app: nginx-frontend

Este presupuesto requiere al menos tres pods con la etiqueta app: nginx-frontend para mantener el estado correcto durante una expulsión voluntaria.

Puede especificar un porcentaje, como 60%, por lo que el presupuesto se ajusta cuando se escala ReplicaSet.

Establecimiento de un número máximo de pods no disponibles

Un PDB puede definir o minAvailablemaxUnavailable, pero no ambos. Para restringir las expulsiones voluntarias en función de pods no disponibles, especifique maxUnavailable como un entero o un porcentaje. El manifiesto siguiente solo permite una expulsión voluntaria cuando no habría más de dos pods en ReplicaSet no disponibles después de la expulsión:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  maxUnavailable: 2
  unhealthyPodEvictionPolicy: AlwaysAllow
  selector:
    matchLabels:
      app: nginx-frontend

Este presupuesto solo permite una expulsión voluntaria cuando no más de dos pods con la etiqueta app: nginx-frontend no estaría disponible después de la expulsión. Las interrupciones involuntarias todavía pueden provocar que la disponibilidad caiga por debajo de este umbral.

La AlwaysAllow directiva de expulsión de pods incorrecta permite expulsar los pods en ejecución que no están en buen estado. Sin esta configuración, la directiva predeterminada IfHealthyBudget puede bloquear un drenaje mientras espera a que los pods incorrectos se vuelvan correctos. Use AlwaysAllow cuando la capacidad de purga es más importante que proporcionar un pod incorrecto más tiempo para recuperarse.

Guarde el manifiesto de PDB que desea usar como nginx-pdb.yaml y, a continuación, aplíquelo al clúster de AKS:

kubectl apply -f nginx-pdb.yaml

Antes del mantenimiento del clúster, compruebe que cada PDB permite la expulsión esperada:

kubectl get poddisruptionbudgets --namespace <namespace>

Un ALLOWED DISRUPTIONS valor de puede bloquear el drenaje de 0 un nodo de AKS. Trabaje con los desarrolladores y propietarios de aplicaciones para mantener suficientes réplicas correctas y elija un presupuesto que equilibre la disponibilidad de la aplicación con los requisitos de mantenimiento.

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.

Contenido relacionado

Este artículo se centra en las características básicas del programador de Kubernetes. Para más información sobre las operaciones de clúster en AKS, consulte los siguientes artículos de procedimientos recomendados:

• Aislamiento de clúster y de multiinquilinato
• Características avanzadas del programador de Kubernetes
• Autenticación y autorización