Ampliar el tiempo de ejecución de los pods de Autopilot

En esta página se explica cómo solicitar tiempos de ejecución ampliados para los pods antes de que Google Kubernetes Engine (GKE) los expulse.

Acerca del desalojo de pods iniciado por GKE

El desalojo de pods es una parte normal de la ejecución de cargas de trabajo en Kubernetes. GKE expulsa cargas de trabajo durante eventos programados, como las actualizaciones automáticas de nodos y las reducciones de escala del autoescalado, para asegurarse de 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, tras lo cual el contenedor tiene un periodo de gracia para finalizar antes de que Kubernetes expulse el pod. En el caso de las actualizaciones automáticas de nodos, el periodo de gracia puede ser de hasta una hora. En el caso de los eventos de reducción, el periodo de gracia puede ser de hasta 10 minutos.

Kubernetes tiene funciones integradas que los contenedores pueden usar para gestionar las expulsiones correctamente, como PodDisruptionBudgets y periodos de finalización correcta. Sin embargo, algunas cargas de trabajo, como las colas de lotes o los servidores de juegos multijugador, deben ejecutarse durante más tiempo antes de que se expulsen. Es posible que el periodo de gracia predeterminado que concede GKE durante las expulsiones iniciadas por GKE no sea suficiente para estas cargas de trabajo. En estas situaciones, puedes indicar a Autopilot que evite desalojar cargas de trabajo específicas durante un máximo de 7 días.

Casos prácticos

Estas son algunas situaciones en las que puede querer indicar a GKE que evite desalojar cargas de trabajo:

  • Gestionas servidores de juegos multijugador que expulsarían a los jugadores de sus sesiones si los servidores se cerraran antes de tiempo.
  • Ejecutas un software de audioconferencia o videoconferencia que interrumpiría las reuniones en curso si se cerraran los servidores.
  • Ejecutas tareas que necesitan tiempo para completarse y, si se terminan antes de tiempo, se perdería el trabajo en curso.
  • Ejecutas un servicio con estado que tolera menos las interrupciones y quieres minimizar la frecuencia con la que se producen.

Precios

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

  • Los clústeres de Autopilot aplican valores mínimos más altos a las solicitudes de recursos de los pods de larga duración. Los clústeres 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 los nodos que no utilices.
  • Usar pods de duración ampliada puede aumentar el número de nodos de tu clúster, lo que puede afectar al uso de direcciones IP y a la escalabilidad. Si tienes DaemonSets que se ejecutan en todos los nodos, habrá más DaemonSets en el clúster.

Para obtener más información sobre los precios, consulta la página Precios de Autopilot.

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.

Limitaciones

  • No puedes solicitar tiempos de ejecución ampliados para tus pods esporádicos.
  • Los tiempos de extracción de imágenes se tienen en cuenta al calcular el tiempo de ejecución ampliado.
  • Puedes tener un máximo de 50 cargas de trabajo de duración ampliada (con diferentes solicitudes de CPU) en cada clúster. Esto significa que, en cada clúster, se pueden prolongar hasta 50 conjuntos diferentes de valores de solicitud de CPU, después de superar los mínimos, las proporciones y los incrementos de los recursos de Autopilot.
  • No puedes usar la afinidad entre pods de Kubernetes en pods de larga duración.
  • Siempre que sea posible, GKE coloca cada pod con tiempo de ejecución ampliado en su propio nodo. De esta forma, los nodos pueden reducirse si no se utilizan lo suficiente.
  • No puedes solicitar tiempos de ejecución ampliados para los pods que tengan como destino clases de computación personalizadas.

Solicitar una duración más larga

Para solicitar un tiempo de ejecución ampliado de un pod, asigna el valor false a la anotación de Kubernetes cluster-autoscaler.kubernetes.io/safe-to-evict en la especificación del pod.

  1. Guarda el siguiente archivo de 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 despliegue:

    kubectl create -f extended-deployment.yaml

Los pods siguen ejecutándose durante al menos 7 días antes de que se pueda reducir la escala o actualizar automáticamente un nodo.

Consideraciones y recomendaciones

Cuando uses esta función, ten en cuenta lo siguiente:

  • Los pods de duración ampliada no están protegidos frente al desalojo basado en la prioridad. Si usas PriorityClasses de Kubernetes, ten en cuenta los siguientes métodos para minimizar la probabilidad de que se produzca un desalojo basado en la prioridad:
    • Asegúrate de que tus pods de larga duración usen la clase 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 larga duración por separado de otros pods.
  • Los pods del sistema se ejecutan con la prioridad más alta y siempre podrán desalojar pods de larga duración. Para minimizar la probabilidad de que esto ocurra, GKE programa los pods del sistema en el nodo antes de programar el pod de duración ampliada.
  • Los pods de duración ampliada se pueden desalojar antes de tiempo en las siguientes situaciones:
    • Desalojo para dejar espacio a los pods de usuario de mayor prioridad (con una PriorityClass más alta)
    • Desalojo para dejar espacio a los componentes del sistema de Kubernetes
    • Desalojo por falta de memoria de kubelet si el pod usa más memoria de la que ha solicitado (OOMKill)
    • Eventos de mantenimiento de VMs de Compute Engine. Es más probable que los tipos de máquina optimizados para aceleradores se vean afectados por estos eventos porque no admiten la migración en vivo.
    • Reparación automática 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 clústeres estándar, pero el resultado no es el mismo. Los pods se ejecutan indefinidamente, incluso si se produce un evento de reducción de escala, lo que impide que se eliminen los nodos infrautilizados y hace que sigas pagando por ellos. Los pods tampoco están protegidos frente a las expulsiones causadas por las actualizaciones automáticas de nodos.

Siguientes pasos