Procedimientos recomendados para mejorar el rendimiento y el escalado de cargas de trabajo pequeñas y medianas en Azure Kubernetes Service (AKS)

Nota:

Este artículo se centra en los procedimientos recomendados generales para cargas de trabajo pequeñas a medianas. Si desea conocer los procedimientos recomendados específicos para las cargas de trabajo de gran tamaño, consulte Procedimientos recomendados para mejorar el rendimiento y el escalado de las cargas de trabajo de gran tamaño en Azure Kubernetes Service (AKS).

A medida que implementa y mantiene clústeres en AKS, puede usar los siguientes procedimientos recomendados para ayudarle a optimizar el rendimiento y el escalado.

En este artículo, aprenderá lo siguiente:

• Disyuntivas y recomendaciones para el escalado automático de las cargas de trabajo.
• Administración del escalado y la eficacia de los nodos en función de la demanda de la carga de trabajo.
• Consideraciones sobre el tráfico de entrada y salida de la red.
• Supervisión y solución de problemas del plano de control y el rendimiento de los nodos.
• Planeamiento de la capacidad, escenarios de sobrecarga y actualizaciones del clúster.
• Consideraciones sobre el almacenamiento y la red para mejorar el rendimiento del plano de datos.

Escalado automático de las aplicaciones frente a escalado automático de la infraestructura

Escalado automático de aplicaciones

El escalado automático de aplicaciones es útil cuando se quieren optimizar los costos o se tiene una infraestructura limitada. Un escalador automático bien configurado mantiene la alta disponibilidad de una aplicación al tiempo que minimiza los costos. Solo paga por los recursos necesarios para mantener la disponibilidad, independientemente de la demanda.

Por ejemplo, si un nodo tiene espacio pero no tiene suficientes direcciones IP en la subred, es posible que pueda omitir la creación de un nuevo nodo y empezar a ejecutar la aplicación inmediatamente en un nuevo pod.

Escalado horizontal automático de pods

La implementación del escalado horizontal automático de pods es útil para las aplicaciones que tienen una demanda de recursos estable y predecible. El escalador automático horizontal de pods (HPA) escala dinámicamente el número de réplicas de pod y distribuye eficazmente la carga entre varios pods y nodos. Este mecanismo de escalado suele ser más beneficioso para las aplicaciones que se pueden dividir en componentes más pequeños e independientes que pueden ejecutarse en paralelo.

HPA proporciona métricas de uso de recursos de forma predeterminada. También puede integrar métricas personalizadas o aprovechar herramientas como Kubernetes Event-Driven Autoscaler (KEDA) (en versión preliminar). Estas extensiones permiten a HPA tomar decisiones de escalado basadas en varias perspectivas y criterios, lo que proporciona una vista más holística del rendimiento de la aplicación. Esto resulta especialmente útil para las aplicaciones con requisitos de escalado complejos y cambiantes.

Nota:

Si mantener la alta disponibilidad de la aplicación es una prioridad máxima, se recomienda dejar un número mínimo de pods ligeramente superior para que HPA tenga en cuenta el tiempo de escalado.

Escalado vertical automático de pods

La implementación del escalado vertical automático de pods es útil para las aplicaciones que tienen una demanda de recursos fluctuante e impredecible. El escalador automático vertical de pods (VPA) permite ajustar las solicitudes de recursos, incluidas la CPU y la memoria, para pods individuales, lo que permite un control preciso de la asignación de recursos. Esta granularidad minimiza el desperdicio de recursos y mejora la eficacia general del uso del clúster. El VPA también simplifica la administración de las aplicaciones, porque automatiza la asignación de recursos y, de este modo, libera recursos para las tareas críticas.

Advertencia

No debe usar el VPA junto con el HPA en las mismas métricas de CPU o memoria. Esta combinación puede causar conflictos, ya que los dos escaladores automáticos intentan responder a los cambios de la demanda usando las mismas métricas. Sin embargo, puede usar el VPA para la CPU o la memoria junto con el HPA para métricas personalizadas, con el fin de evitar que se solapen y asegurarse de que cada escalador automático se centra en aspectos diferentes del escalado de la carga de trabajo.

Nota:

El VPA se basa en los datos históricos. Se recomienda esperar al menos 24 horas después de implementar el VPA antes de aplicar cambios para que le dé tiempo a recopilar datos de recomendaciones.

Escalado automático de la infraestructura

Escalado automático del clúster

La implementación del escalado automático de un clúster es útil si los nodos actuales no tienen capacidad suficiente, ya que ayuda a escalar el clúster verticalmente y aprovisionar nuevos nodos.

Cuando se considera el uso del escalado automático de un clúster, la decisión de cuándo quitar un nodo implica buscar un equilibrio entre optimizar el uso de los recursos y garantizar su disponibilidad. La eliminación de los nodos infrautilizados mejora el uso del clúster, pero puede dar lugar a que las nuevas cargas de trabajo tengan que esperar a que se aprovisionen recursos para poder implementarlas. Es importante encontrar un equilibrio entre estos dos factores que esté en consonancia con sus requisitos en cuanto al clúster y las cargas de trabajo, y configurar el perfil del escalador automático del clúster en consecuencia.

La configuración del perfil del escalador automático del clúster se aplica universalmente a todos los grupos de nodos habilitados para el escalador automático del clúster. Esto significa que cualquier acción de escalado que tenga lugar en un grupo de nodos habilitado para el escalador automático podría afectar al comportamiento de escalado automático de otro grupo de nodos. Es importante aplicar una configuración de perfil coherente y sincronizada en todos los grupos de nodos pertinentes, con el fin de asegurarse de que el escalador automático se comporta según lo previsto.

Aprovisionamiento en exceso

El sobreaprovisionamiento es una estrategia que ayuda a mitigar el riesgo de presión en las aplicaciones, ya que garantiza que haya un exceso de recursos disponibles. Este enfoque es especialmente útil para las aplicaciones que experimentan cargas muy variables y patrones de escalado del clúster que muestran que se escala y reduce verticalmente con frecuencia.

Para determinar la cantidad óptima de sobreaprovisionamiento, puede usar la siguiente fórmula:

1-buffer/1+traffic

Por ejemplo, supongamos que no quiere que se llegue a usar el 100 % de la CPU en el clúster. Puede optar por tener una reserva del 30 % para mantener un margen de seguridad. Si prevé una tasa media de aumento del tráfico del 40 %, puede plantearse implementar un sobreaprovisionamiento del 50 %, según lo calculado por la fórmula:

1-30%/1+40%=50%

Un método de sobreaprovisionamiento eficaz implica el uso de pods en pausa. Los pods en pausa son implementaciones de prioridad baja que se pueden reemplazar fácilmente por implementaciones de prioridad alta. Se crean pods de prioridad baja solo para reservar espacio. Cuando un pod de prioridad alta necesita espacio, se quitan los pods en pausa y se reprograman en otro nodo o en un nodo nuevo para dar cabida al pod de prioridad alta.

El siguiente código YAML muestra un ejemplo de manifiesto de pod de pausa:

apiVersion: scheduling.k8s.io/v1 
kind: PriorityClass 
metadata: 
  name: overprovisioning 
value: -1 
globalDefault: false 
description: "Priority class used by overprovisioning." 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: overprovisioning 
  namespace: kube-system 
spec: 
  replicas: 1 
  selector: 
    matchLabels: 
      run: overprovisioning 
  template: 
    metadata: 
      labels: 
        run: overprovisioning 
    spec: 
      priorityClassName: overprovisioning 
      containers: 
      - name: reserve-resources 
        image: your-custome-pause-image 
        resources: 
          requests: 
            cpu: 1 
            memory: 4Gi 

Escalado y eficiencia de los nodos

Guía de procedimientos recomendados:

Supervise cuidadosamente el uso de recursos y las directivas de programación para asegurarse de que los nodos se usan de forma eficiente.

El escalado de nodos permite ajustar dinámicamente el número de nodos del clúster en función de la demanda de la carga de trabajo. Es importante comprender que agregar más nodos a un clúster no siempre es la mejor solución para mejorar el rendimiento. Para garantizar un rendimiento óptimo, debe supervisar cuidadosamente el uso de los recursos y las directivas de programación para asegurarse de que los nodos se están usando de forma eficiente.

Imágenes de nodo

Guía de procedimientos recomendados:

Use la versión más reciente de la imagen de un nodo para asegurarse de que tiene las últimas revisiones de seguridad y correcciones de errores.

El uso de la versión más reciente de la imagen de un nodo proporciona el mayor rendimiento. AKS incluye mejoras de rendimiento en las versiones semanales de las imágenes. Las imágenes de DaemonSet más recientes se almacenan en caché en la última imagen de VHD, lo que proporciona la ventaja de una latencia menor para el aprovisionamiento y el arranque de los nodos. Si no se está al día de las actualizaciones, puede afectar al rendimiento, por lo que es importante evitar grandes intervalos entre versiones.

Azure Linux

El host de contenedor de Azure Linux en AKS usa una imagen nativa de AKS y proporciona un único lugar de desarrollo para Linux. Cada paquete se crea a partir del origen y se valida, lo que garantiza que los servicios se ejecuten en componentes probados.

Azure Linux es ligero, incluye solamente el conjunto de paquetes indispensables para ejecutar cargas de trabajo de contenedor. Proporciona una superficie menos expuesta a ataques y elimina la aplicación de revisiones y el mantenimiento de paquetes innecesarios. En la capa base tiene un kernel reforzado por Microsoft y optimizado para Azure. Esta imagen es ideal para cargas de trabajo sensibles al rendimiento y operadores e ingenieros de la plataforma que administran flotas de clústeres de AKS.

Ubuntu 2204

Ubuntu 2204 es la imagen de nodo predeterminada para AKS. Es un sistema operativo ligero y eficaz optimizado para ejecutar cargas de trabajo contenedorizadas. Esto significa que puede ayudar a reducir el uso de recursos y a mejorar el rendimiento general. La imagen incluye las actualizaciones y revisiones de seguridad más recientes, lo que ayuda a garantizar que las cargas de trabajo están protegidas frente a vulnerabilidades.

La imagen de Ubuntu 2204 es totalmente compatible con Microsoft, Canonical y la comunidad de Ubuntu, y puede ayudarle a mejorar el rendimiento y la seguridad de las cargas de trabajo contenedorizadas.

Máquinas virtuales (VM)

Guía de procedimientos recomendados:

Al seleccionar una máquina virtual, asegúrese de que no haya una gran discrepancia entre el tamaño y el rendimiento del disco del sistema operativo y la SKU de la máquina virtual. Una discrepancia en el tamaño o el rendimiento puede provocar problemas de rendimiento y contención de recursos.

El rendimiento de las aplicaciones está estrechamente vinculado a las SKU de máquina virtual que se usan en las cargas de trabajo. Las máquinas virtuales más grandes y eficaces suelen proporcionar un mejor rendimiento. Para las cargas de trabajo críticas o de producto, se recomienda usar máquinas virtuales con al menos una CPU de 8 núcleos. Las máquinas virtuales con generaciones de hardware más recientes, como v4 y v5, también pueden mejorar el rendimiento. Tenga en cuenta que la latencia de creación y escalado puede variar en función de las SKU de máquina virtual que use.

Uso de grupos de nodos del sistema dedicados

Para escalar el rendimiento y la confiabilidad, se recomienda usar un grupo de nodos del sistema dedicado. Con esta configuración, el grupo de nodos del sistema dedicado reserva espacio para recursos críticos del sistema, como demonios del sistema operativo del sistema. Después, la carga de trabajo de la aplicación se puede ejecutar en un grupo de nodos de usuario para aumentar la disponibilidad de los recursos que se pueden usar para la aplicación. Esta configuración también ayuda a mitigar el riesgo de competencia por los recursos entre el sistema y la aplicación.

Crear operaciones

Revise las extensiones y los complementos que ha habilitado durante la creación del aprovisionamiento. Las extensiones y los complementos pueden agregar latencia a la duración total de las operaciones de creación. Si no necesita una extensión o un complemento, se recomienda quitarlos para mejorar la latencia de creación.

También puede usar zonas de disponibilidad para proporcionar un mayor nivel de disponibilidad para protegerse frente a posibles errores de hardware o eventos de mantenimiento planeado. Los clústeres de AKS distribuyen los recursos en secciones lógicas de la infraestructura de Azure subyacente. Las zonas de disponibilidad separan físicamente los nodos de otros nodos para ayudar a garantizar que un único error no afecte a la disponibilidad de la aplicación. Las zonas de disponibilidad solo están disponible en algunas regiones. Para más información, consulte Zonas de disponibilidad en Azure.

Servidor de la API de Kubernetes

Operaciones LIST y WATCH

Kubernetes usa las operaciones LIST y WATCH para interactuar con el servidor de API de Kubernetes y supervisar la información sobre los recursos del clúster. Estas operaciones son fundamentales para la forma en la que Kubernetes administra los recursos.

La operación LIST recupera una lista de recursos que coinciden con determinados criterios, por ejemplo, todos los pods de un espacio de nombres específico o todos los servicios del clúster. Esta operación es útil cuando desea obtener una visión general de los recursos del clúster o cuando necesita operar con varios recursos a la vez.

La operación LIST puede recuperar grandes cantidades de datos, especialmente en clústeres grandes con varios recursos. Tenga en cuenta el hecho de que realizar llamadas LIST ilimitadas o frecuentes coloca una carga considerable en el servidor de API y puede cerrar los tiempos de respuesta.

La operación WATCH supervisa los recursos en tiempo real. Cuando configura una operación WATCH en un recurso, el servidor de API le envía actualizaciones a usted cada vez que hay cambios en ese recurso. Esto es importante para los controladores, como ReplicaSet, que dependen de WATCH para mantener el estado deseado de los recursos.

Tenga en cuenta el hecho de que inspeccionar demasiados recursos mutables o hacer demasiadas solicitudes WATCH simultáneas puede sobrecargar el servidor de API y provocar un consumo excesivo de recursos.

Para evitar posibles problemas y garantizar la estabilidad del plano de control de Kubernetes, puede usar las siguientes estrategias:

Cuotas de recursos

Implemente cuotas de recursos para limitar el número de recursos que un usuario o espacio de nombres determinado puede mostrar o inspeccionar para evitar llamadas excesivas.

Prioridad de API y equidad

Kubernetes introdujo el concepto de prioridad y equidad de API (APF) para priorizar y administrar las solicitudes de API. Puede usar APF en Kubernetes para proteger el servidor de API del clúster y reducir el número de respuestas HTTP 429 Too Many Requests que ven las aplicaciones cliente.

Recurso personalizado	Características clave
PriorityLevelConfigurations	• Define diferentes niveles de prioridad para las solicitudes de API. • Especifica un nombre único y asigna un valor entero que representa el nivel de prioridad. Los niveles de prioridad más altos tienen valores enteros más bajos, lo que indica que son más críticos. • Puede usar varios para clasificar las solicitudes en diferentes niveles de prioridad en función de su importancia. • Permite especificar si las solicitudes en un nivel de prioridad determinado deben estar sujetas a límites de frecuencia.
FlowSchemas	• Define cómo se deben enrutar las solicitudes de API a diferentes niveles de prioridad en función de los atributos de cada solicitud. • Especifica reglas que coinciden con solicitudes basadas en criterios como grupos de API, versiones y recursos. • Cuando una solicitud coincide con una regla determinada, la solicitud se dirige al nivel de prioridad especificado en el elemento PriorityLevelConfiguration asociado. • Se puede usar para establecer el orden de evaluación cuando varios FlowSchemas coinciden con una solicitud para asegurarse de que ciertas reglas tienen prioridad.

La configuración de API con PriorityLevelConfigurations y FlowSchemas permite dar prioridad a solicitudes de API críticas sobre solicitudes menos importantes. Esto garantiza que las operaciones esenciales no experimenten retrasos debido a solicitudes de prioridad inferior.

Optimización del etiquetado y los selectores

Cuando use operaciones LIST, optimice los selectores de etiquetas para restringir el ámbito de los recursos que desea consultar para reducir la cantidad de datos devueltos y la carga en el servidor de API.

En las operaciones CREATE y UPDATE de Kubernetes, consulte las acciones que administran y modifican los recursos del clúster.

Operaciones CREATE y UPDATE

La operación CREATE crea nuevos recursos en el clúster de Kubernetes, como pods, servicios, implementaciones, ConfigMaps y secretos. Durante una operación CREATE, un cliente, como kubectl o un controlador, envía una solicitud al servidor de API de Kubernetes para crear el nuevo recurso. El servidor de API valida la solicitud, garantiza el cumplimiento de las directivas de controlador de admisión y, a continuación, crea el recurso en el estado deseado del clúster.

La operación UPDATE modifica los recursos actuales del clúster de Kubernetes, incluidos los cambios en las especificaciones de recursos, como el número de réplicas, las imágenes de contenedor, las variables de entorno o las etiquetas. Durante una operación UPDATE, un cliente envía una solicitud al servidor de API para actualizar un recurso. El servidor de API valida la solicitud, aplica los cambios a la definición del recurso y actualiza el recurso del clúster.

Las operaciones CREATE y UPDATE pueden afectar al rendimiento del servidor de API de Kubernetes en las siguientes condiciones:

• Alta simultaneidad: cuando varios usuarios o aplicaciones realizan solicitudes CREATE o UPDATE simultáneas, puede provocar un aumento en las solicitudes de API que llegan al servidor al mismo tiempo. Esto puede aplicar demasiada presión a la capacidad de procesamiento del servidor de API y causar problemas de rendimiento.
• Definiciones de recursos complejas: las definiciones de recursos que son demasiado complejas o implican varios objetos anidados pueden aumentar el tiempo que tarda el servidor de API en validar y procesar las solicitudes CREATE y UPDATE, lo que puede producir una degradación del rendimiento.
• Control de admisión y validación de recursos: Kubernetes aplica varias directivas de control de admisión y comprobaciones de validación a las solicitudes CREATE y UPDATE entrantes. Las definiciones de recursos grandes, como las que incluyen anotaciones o configuraciones extensas, pueden requerir más tiempo de procesamiento.
• Controladores personalizados: los controladores personalizados que inspeccionan si se producen cambios en los recursos, como los controladores de implementaciones o StatefulSet, pueden generar un número considerable de actualizaciones cuando se escalan o implementan cambios. Estas actualizaciones pueden someter a demasiada presión los recursos del servidor de API.

Para obtener más información, consulte Solución de problemas de servidor de API y etcd en Azure Kubernetes Services.

Rendimiento del plano de datos

El plano de datos de Kubernetes es responsable de administrar el tráfico de red entre contenedores y servicios. Los problemas en el plano de datos pueden dar lugar a tiempos de respuesta lentos, rendimiento degradado y tiempo de inactividad de las aplicaciones. Es importante supervisar y optimizar cuidadosamente la configuración del plano de datos, como la latencia de red, la asignación de recursos, la densidad de contenedores y las directivas de red, para asegurarse de que las aplicaciones contenedorizadas se ejecutan de forma fluida y eficiente.

Tipos de almacenamiento

AKS recomienda y usa de forma predeterminada discos de SO efímeros. Los discos de SO efímeros se crean en el almacenamiento de máquina virtual local y no se guardan en el almacenamiento remoto de Azure como los discos de SO administrados. Tienen tiempos de restablecimiento de imagen y arranque más rápidos, lo que permite operaciones de clúster más rápidas, y proporcionan menos latencia de lectura y escritura en el disco del sistema operativo de los nodos del agente de AKS. Estos discos están indicados para cargas de trabajo sin estado, donde las aplicaciones toleran errores de máquinas virtuales individuales, pero no del tiempo de implementación de las máquinas virtuales ni de instancias de restablecimiento de imagen de máquinas virtuales individuales. Solo algunas SKU de máquinas virtuales admiten discos de SO efímeros, por lo que debe asegurarse de que la generación y el tamaño deseados de la SKU sean compatibles. Para obtener más información, consulte Uso del sistema operativo efímero en clústeres nuevos.

Si la carga de trabajo no puede usar discos de SO efímeros, AKS usa de forma predeterminada discos SSD prémium. Si los discos del sistema operativo SSD prémium no son compatibles con la carga de trabajo, AKS toma como valor predeterminado discos SSD estándar. Actualmente, el único tipo de disco de sistema operativo disponible es HDD estándar. Para obtener más información, consulte Opciones de almacenamiento de aplicaciones en Azure Kubernetes Service (AKS).

En la tabla siguiente se proporciona un desglose de los casos de uso sugeridos para los discos de sistema operativo admitidos en AKS:

Tipo de disco del sistema operativo	Características clave	Casos de uso sugeridos
Discos de sistema operativo efímero	• Tiempos de restablecimiento de imagen y arranque más rápidos. • Menor latencia de lectura y escritura en el disco del sistema operativo de los nodos del agente de AKS. • Alto rendimiento y alta disponibilidad.	• Cargas de trabajo empresariales exigentes, como SQL Server, Oracle, Dynamics, Exchange Server, MySQL, Cassandra, MongoDB, SAP Business Suite, etc. • Cargas de trabajo de producción sin estado que requieren alta disponibilidad y baja latencia.
Discos del sistema operativo SSD prémium	• Rendimiento coherente y baja latencia. • Alta disponibilidad.	• Cargas de trabajo empresariales exigentes, como SQL Server, Oracle, Dynamics, Exchange Server, MySQL, Cassandra, MongoDB, SAP Business Suite, etc. • Cargas de trabajo empresariales con un gran numero de operaciones de entrada y salida (E/S).
Discos de sistema operativo SSD estándar	• Rendimiento coherente. • Mejor disponibilidad y latencia en comparación con los discos HDD estándar.	• Servidores web. • Servidores de aplicaciones con pocas operaciones de entrada y salida por segundo (IOPS). • Aplicaciones empresariales poco usadas. • Cargas de trabajo de desarrollo y pruebas.
Discos HDD estándar	• Bajo costo. • Presenta variabilidad en el rendimiento y la latencia.	• Almacenamiento de copia de seguridad. • Almacenamiento masivo con acceso poco frecuente.

IOPS y rendimiento

El término "operaciones de entrada y salida por segundo" (IOPS) hace referencia al número de operaciones de lectura y escritura que un disco puede realizar en un segundo. El rendimiento hace referencia a la cantidad de datos que se pueden transferir en un período de tiempo determinado.

Los discos del sistema operativo son responsables de almacenar el sistema operativo y los archivos asociados, y las máquinas virtuales son responsables de ejecutar las aplicaciones. Al seleccionar una máquina virtual, asegúrese de que no haya una gran discrepancia entre el tamaño y el rendimiento del disco del sistema operativo y la SKU de la máquina virtual. Una discrepancia en el tamaño o el rendimiento puede provocar problemas de rendimiento y contención de recursos. Por ejemplo, si el disco del sistema operativo es considerablemente más pequeño que las máquinas virtuales, puede limitar la cantidad de espacio disponible para los datos de la aplicación y hacer que el sistema se quede sin espacio en disco. Si el disco del sistema operativo tiene un rendimiento inferior al de las máquinas virtuales, puede convertirse en un cuello de botella y limitar el rendimiento general del sistema. Asegúrese de que el tamaño y el rendimiento están equilibrados para garantizar un rendimiento óptimo en Kubernetes.

Puede usar los siguientes pasos para supervisar los medidores de IOPS y de ancho de banda en discos del sistema operativo en Azure Portal:

1. Acceda a Azure Portal.
2. Busque Conjuntos de escalado de máquinas virtuales y seleccione su conjunto de escalado de máquinas virtuales.
3. En Supervisión, seleccione Métricas.

Los discos de SO efímeros pueden proporcionar IOPS y rendimiento dinámicos para la aplicación, mientras que los discos administrados tienen IOPS y rendimiento limitados. Para más información, consulte Discos de SO efímeros para máquinas virtuales de Azure.

Azure SSD prémium v2 está diseñado para cargas de trabajo empresariales que tienen muchas operaciones de E/S que requieren latencias de disco inferiores a un segundo y un alto número de IOPS, además de un rendimiento a bajo costo. Es adecuado para una amplia gama de cargas de trabajo, como SQL Server, Oracle, MariaDB, SAP, Cassandra, MongoDB, macrodatos y análisis, juegos, etc. Este tipo de disco es la opción de mayor rendimiento disponible actualmente para volúmenes persistentes.

Programación de pods

La memoria y los recursos de CPU asignados a una máquina virtual afectan directamente al rendimiento de los pods que se ejecutan en la máquina virtual. Cuando se crea un pod, se le asigna una determinada cantidad de recursos de memoria y CPU, que se usan para ejecutar la aplicación. Si la máquina virtual no tiene suficiente memoria o recursos de CPU disponibles, puede hacer que los pods se ralenticen e incluso se bloqueen. Si la máquina virtual tiene demasiada memoria o recursos de CPU disponibles, puede hacer que los pods se ejecuten ineficazmente, desperdiciando recursos y aumentando los costos. Se recomienda supervisar el total de solicitudes de pods en las cargas de trabajo con respecto al total de recursos que se pueden asignar para programar mejor la predicción y el rendimiento. Establezca el número máximo de pods por nodo en función del planeamiento de capacidad con --max-pods.