Extiende el tiempo de ejecución de los Pods de Autopilot

En esta página, se muestra cómo solicitar tiempos de ejecución extendidos para los Pods antes de que Google Kubernetes Engine (GKE) los expulse.

Acerca de la expulsión de Pods iniciada por GKE

Las expulsiones de Pods son una parte normal de la ejecución de cargas de trabajo en Kubernetes. GKE expulsa las cargas de trabajo durante los eventos programados, como las actualizaciones automáticas de nodos y las reducciones verticales automáticas de escala, para garantizar que tus nodos estén actualizados y optimizados para un uso eficiente de los recursos. De forma predeterminada, GKE envía una señal de finalización al contenedor en cuanto se produce el evento, después de lo cual el contenedor tiene un período de gracia para finalizar antes de que Kubernetes expulse el Pod. En el caso de las actualizaciones automáticas de nodos, el período de gracia puede durar hasta una hora. Para los eventos de reducción de escala, el período de gracia puede ser de hasta 10 minutos.

Kubernetes tiene funciones integradas que los contenedores pueden usar para controlar las expulsiones de forma correcta, como los PodDisruptionBudgets y los períodos de finalización correctos. Sin embargo, algunas cargas de trabajo, como las colas de lotes o los servidores de juegos multijugador, deben ejecutarse durante un período más prolongado antes de que se desalojen. Es posible que el período de gracia predeterminado que otorga GKE durante las expulsiones iniciadas por GKE no sea suficiente para estas cargas de trabajo. En estas situaciones, puedes indicarle a Autopilot que evites expulsar cargas de trabajo específicas durante un máximo de 7 días.

Casos de uso

Estas son algunas situaciones en las que tal vez quieras indicarle a GKE que evite expulsar cargas de trabajo:

  • Ejecutas servidores de juego multijugador para juegos que saturan a los jugadores de sus sesiones si los servidores finalizan de forma anticipada.
  • Ejecutas software de videoconferencias o audioconferencias que interrumpirían las reuniones en curso si se cerraran los servidores.
  • Ejecutas tareas que necesitan tiempo para completarse, y la finalización anticipada causaría una pérdida del trabajo en curso.
  • Ejecutas un servicio con estado que es menos tolerante a las interrupciones y deseas minimizar la frecuencia con la que ocurren.

Precios

Puedes solicitar tiempos de ejecución extendidos para tus Pods sin cargo adicional. Sin embargo, ten en cuenta los siguientes cambios de comportamiento que podrían afectar tus precios:

  • Los clústeres de Autopilot aplican valores mínimos más altos para las solicitudes de recursos de los Pods de duración extendida. Los clústeres de Autopilot te cobran por las solicitudes de recursos de tus Pods en ejecución. No se te cobra por la sobrecarga del sistema ni por la capacidad de nodos sin usar.
  • El uso de Pods de duración extendida puede aumentar la cantidad de nodos en tu clúster, lo que podría afectar el uso de direcciones IP y la escalabilidad. Si tienes DaemonSets que se ejecutan en cada nodo, esto genera más DaemonSets en el clúster.

Para obtener detalles sobre los precios, consulta Precios de Autopilot.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.

Limitaciones

  • No puedes solicitar tiempos de ejecución extendidos para tus Pods Spot.
  • Los tiempos de extracción de imágenes se tienen en cuenta cuando se calcula el tiempo de ejecución extendido.
  • Puedes tener un máximo de 50 cargas de trabajo de duración extendida (con solicitudes de CPU diferentes) en cada clúster. Esto significa que hasta 50 conjuntos diferentes de valores de solicitud de CPU, después de pasar las cantidades mínimas de recursos de Autopilot, las proporciones y las verificaciones de tamaño de incremento, pueden tener una duración prolongada en cada clúster.
  • No puedes usar la afinidad entre Pods de Kubernetes en Pods de duración extendida.
  • Siempre que sea posible, GKE coloca cada Pod de tiempo de ejecución extendido en su propio nodo. Este comportamiento garantiza que los nodos puedan reducir la escala si no se usan lo suficiente.
  • No puedes solicitar tiempos de ejecución extendidos para los Pods que tienen como objetivo clases de procesamiento personalizadas.

Solicita un tiempo de ejecución extendido

Para solicitar un tiempo de ejecución extendido para un Pod, configura la anotación cluster-autoscaler.kubernetes.io/safe-to-evict de Kubernetes como false en la especificación del Pod.

  1. Guarda el siguiente manifiesto como extended-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: extended-pods
  labels:
    duration: extended
spec:
  selector:
    matchLabels:
      duration: extended
  template:
    metadata:
      annotations:
        cluster-autoscaler.kubernetes.io/safe-to-evict: "false"
      labels:
        duration: extended
    spec:
      containers:
      - name: example-container
        image: registry.k8s.io/pause
        resources:
          requests:
            cpu: 200m

  2. Crea el Deployment:

    kubectl create -f extended-deployment.yaml

Los Pods continúan ejecutándose durante al menos 7 días antes de que se pueda reducir la escala verticalmente o una actualización automática de nodo.

Consideraciones y recomendaciones

Cuando uses esta funcionalidad, ten en cuenta lo siguiente:

  • Los Pods de duración extendida no están protegidos contra la expulsión basada en la prioridad. Si usas PriorityClasses de Kubernetes, considera los siguientes métodos para minimizar la probabilidad de expulsión basada en la prioridad:
    • Asegúrate de que tus Pods de duración extendida usen la PriorityClass de mayor prioridad para que otros Pods de usuario no los expulsen.
    • Usa la separación de cargas de trabajo para ejecutar Pods de duración extendida por separado de otros Pods.
  • Los Pods del sistema se ejecutan con la prioridad más alta y siempre podrán expulsar Pods de duración extendida. Para minimizar la probabilidad de que esto suceda, GKE programa los Pods del sistema en el nodo antes de programar el Pod de duración extendida.
  • Los Pods de duración extendida aún se pueden desalojar antes de tiempo en las siguientes situaciones:
    • Expulsión para dejar espacio para Pods de usuario de mayor prioridad (con una PriorityClass más alta)
    • Desalojo para dejar espacio a los componentes del sistema de Kubernetes
    • Expulsión por falta de memoria de kubelet si el Pod usa más memoria de la que solicitó (OOMKill)
    • Eventos de mantenimiento de VM de Compute Engine Es más probable que los tipos de máquinas optimizados para aceleradores se vean afectados por estos eventos, ya que esas máquinas no admiten la migración en vivo.
    • Reparaciones automáticas de nodos
    • Eventos iniciados por el usuario, como el drenaje de un nodo
  • Puedes usar la anotación cluster-autoscaler.kubernetes.io/safe-to-evict en los clústeres estándar, pero el resultado no es el mismo. Los pods se ejecutan de forma indefinida, incluso si ocurre un evento de reducción de escala, lo que evita que se borren los nodos con poco uso y que continúes pagando por esos nodos. Los Pods tampoco están protegidos de las expulsiones causadas por las actualizaciones automáticas de nodos.

¿Qué sigue?