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. Luego, el contenedor tiene un período de gracia para finalizar antes de que Kubernetes expulsa el Pod. Para las actualizaciones automáticas de nodos, el período de gracia puede ser de 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 manejar las expulsiones con facilidad, como PodDisruptionBudgets y los períodos de finalización ordenados. 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 largo antes de expulsarse. El período de gracia predeterminado que GKE otorga durante las expulsiones iniciadas por GKE podría no ser 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

En algunas situaciones, es posible que desees indicarle a GKE que evites 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 videoconferencia o audio que interrumpa las reuniones en curso si los servidores finalizan.
  • Ejecutas tareas que necesitan tiempo y la finalización temprana 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 las interrupciones.

Precios

Puedes solicitar tiempos de ejecución extendidos para tus Pods sin cargo adicional. Sin embargo, considera 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 los Pods en ejecución. No se te cobrará 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 puede afectar el uso y la escalabilidad de la dirección IP. Si tienes DaemonSets que se ejecutan en cada nodo, esto da como resultado 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 Kubernetes Engine de Google.
    • Habilitar la API de Kubernetes Engine de Google
  • 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 Spot Pods.
  • Los tiempos de extracción de imagen se cuentan 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.

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 los Pods de duración extendida usen la PriorityClass de mayor prioridad para que otros Pods de usuario no expulsen los Pods de duración extendida.
    • Usa la separación de cargas de trabajo para ejecutar los 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 los 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 pueden expulsarse antes en las siguientes situaciones:
    • Expulsión para dejar espacio para Pods de usuario de mayor prioridad (con una PriorityClass más alta)
    • Expulsión para liberar espacio para los componentes del sistema de Kubernetes
    • Expulsión de memoria insuficiente de kubelet si el Pod usa más memoria de la que solicitó (OOMKill).
    • Eventos de mantenimiento de VM de Compute Engine. Los tipos de máquina optimizados para acelerador tienen más probabilidades de verse afectados por estos eventos porque esas máquinas no admiten la migración en vivo.
    • Reparaciones automáticas de nodos
    • Eventos iniciados por el usuario, como el desvío 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?