Gestión Eficiente de Recursos en Kubernetes. Bloque 2. Tema 2.3 del CKA.

  

 Kubernetes ofrece un ecosistema completo para gestionar la escalabilidad y optimización de recursos en aplicaciones contenedorizadas. Desde el escalado automático con HPA, VPA y Cluster Autoscaler, hasta el control de recursos con LimitRange, ResourceQuota y PodDisruptionBudget, la plataforma asegura que las aplicaciones puedan adaptarse dinámicamente a los cambios de carga y uso de recursos.

El uso eficiente de estas herramientas permite a los administradores de clústeres optimizar el rendimiento, reducir costos y garantizar la disponibilidad de las aplicaciones, tanto en entornos de producción como de desarrollo.

1. LimitRange

El recurso LimitRange se utiliza para establecer límites mínimos y máximos de CPU y memoria que los contenedores pueden solicitar en un namespace. Esto es útil para prevenir que ciertas cargas de trabajo consuman más recursos de los necesarios o sobrecarguen el clúster.

• Ejemplo de LimitRange:

  yaml:
  apiVersion: v1
  kind: LimitRange
  metadata:
    name: resource-limits
    namespace: default
  spec:
    limits:
    - default:
        cpu: 500m
        memory: 256Mi
      max:
        cpu: 1
        memory: 1Gi
      min:
        cpu: 100m
        memory: 64Mi
  

En este ejemplo, se establece un límite mínimo y máximo para el uso de CPU y memoria dentro del namespace default.

2. ResourceQuota

El ResourceQuota limita el uso total de recursos como CPU y memoria dentro de un namespace, lo que ayuda a controlar el uso global de los recursos del clúster y prevenir el acaparamiento de recursos por parte de una sola aplicación o usuario.

• Ejemplo de ResourceQuota:

  yaml:
  
  apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: compute-resources
    namespace: default
  spec:
    hard:
      requests.cpu: "4"
      requests.memory: 8Gi
      limits.cpu: "10"
      limits.memory: 16Gi
  

Este ejemplo limita el total de solicitudes de CPU a 4 cores y el uso máximo de CPU a 10 cores en el namespace default.

3. Calidad de Servicio (QoS)

Kubernetes clasifica los pods según sus solicitudes de recursos en tres clases de Calidad de Servicio (QoS): Guaranteed, Burstable, y BestEffort. Esta clasificación afecta cómo Kubernetes gestiona los recursos y determina qué pods serán expulsados primero en situaciones de presión de recursos.

• Guaranteed: Se garantiza la calidad de servicio cuando un pod tiene solicitudes y límites de recursos definidos de manera idéntica. Estos pods tienen la mayor prioridad y serán los últimos en ser expulsados.

• Burstable: Si los pods tienen solicitudes de recursos menores que los límites, caen en la clase Burstable. Estos pods tienen una prioridad media.

• BestEffort: Los pods que no tienen solicitudes ni límites de recursos caen en la clase BestEffort. Estos pods tienen la menor prioridad y son los primeros en ser expulsados si el nodo se queda sin recursos.

4. PodDisruptionBudget (PDB)

El PodDisruptionBudget (PDB) asegura que Kubernetes mantenga un número mínimo de pods en ejecución durante operaciones de mantenimiento, como actualizaciones o reinicios de nodos. Esto es fundamental para garantizar la disponibilidad continua de aplicaciones críticas.

• Ejemplo de PDB:

  yaml:
  
  apiVersion: policy/v1
  kind: PodDisruptionBudget
  metadata:
    name: pdb-example
  spec:
    minAvailable: 2
    selector:
      matchLabels:
        app: my-app
  

Este ejemplo garantiza que al menos 2 pods del deployment my-app sigan corriendo incluso durante operaciones de mantenimiento.

5. Eviction Policy (Política de Expulsión)

En Kubernetes, la Eviction Policy entra en juego cuando un nodo experimenta presión de recursos y ya no puede mantener todos los pods en ejecución. Kubernetes comienza a liberar recursos eliminando pods menos prioritarios para proteger la estabilidad general del nodo y del clúster. La política de expulsión decide qué pods deben ser eliminados según su clase de Calidad de Servicio (QoS) y su importancia dentro del clúster.

Condiciones que pueden activar una expulsión:

• Presión de memoria: Cuando un nodo se queda sin suficiente memoria para seguir ejecutando todos los pods.
• Presión de disco: Si el nodo se está quedando sin espacio en el disco, Kubernetes puede optar por eliminar pods.
• Presión de CPU: Aunque menos común que la memoria y el disco, la falta de CPU también puede ser un factor.

Prioridad de expulsión:

1. BestEffort: Los primeros en ser expulsados son los pods clasificados como BestEffort, ya que no tienen solicitudes de recursos específicas.
2. Burstable: Los pods con la clase de QoS Burstable se expulsan si la presión de recursos continúa y no se han liberado suficientes recursos.
3. Guaranteed: Los pods clasificados como Guaranteed son los últimos en ser expulsados, ya que tienen una mayor prioridad en cuanto a la asignación de recursos.

Ejemplo práctico de uso de Eviction Policy:

Cuando un nodo sufre una sobrecarga de memoria, los pods en la clase de QoS BestEffort serán los primeros en ser expulsados. Si eso no es suficiente, Kubernetes procederá a expulsar los pods Burstable, y solo en casos extremos comenzará a expulsar los pods Guaranteed.

¿Cómo se relaciona con PodDisruptionBudget?

Si un PodDisruptionBudget (PDB) está configurado para una aplicación, Kubernetes se asegurará de no expulsar más pods de los permitidos por el PDB, incluso durante situaciones de presión de recursos. Esto garantiza que siempre haya un número mínimo de pods en funcionamiento, proporcionando estabilidad y alta disponibilidad durante operaciones críticas.

Relación de todos los conceptos vistos en estos 2 últimos artículos:

• Calidad de Servicio (QoS) y Eviction Policy afectan la prioridad de los Pods cuando hay presión de recursos. Los Pods con mayor prioridad (mejor QoS) son más resistentes a la eliminación en situaciones de escasez de recursos.

• PodDisruptionBudget (PDB) asegura la disponibilidad de Pods durante operaciones planificadas (mantenimiento o actualización), mientras que los mecanismos de Affinity y Tolerations influyen en dónde se ejecutarán esos Pods.

• LimitRange, ResourceQuota, Horizontal Pod Autoscaler (HPA), y Vertical Pod Autoscaler (VPA) gestionan cuántos recursos pueden usar los Pods y cuántos Pods deben ejecutarse en un clúster o namespace específico, optimizando así el uso de recursos.

• Node Affinity, Pod Affinity/Anti-Affinity, y Taints/Tolerations determinan dónde y cómo se programan los Pods dentro de un clúster. Ayudan a gestionar la distribución de los Pods para evitar la sobrecarga en nodos específicos o asegurar que ciertas aplicaciones se ejecuten juntas o separadas.