Pod

En esta página, se describen objetos de pods de Kubernetes y sus usos en Google Kubernetes Engine.

¿Qué es un pod?

Los pods son los objetos más pequeños y básicos que se pueden implementar en Kubernetes. Un pod representa una instancia única de un proceso en ejecución en tu clúster.

Los pods contienen uno o más contenedores, como los contenedores de Docker. Cuando un pod ejecuta varios contenedores, estos se administran como una sola entidad y comparten los recursos del pod. En general, ejecutar varios contenedores en un solo pod representa un caso práctico avanzado.

Los pods también poseen recursos compartidos de red y almacenamiento para sus contenedores:

  • Red: a los pods se les asignan direcciones IP únicas de manera automática. Los contenedores de pod comparten el mismo espacio de nombres de red, incluida la dirección IP y los puertos de red. Los contenedores en un pod se comunican entre sí dentro del pod en localhost.
  • Almacenamiento: los pods pueden especificar un conjunto de volúmenes de almacenamiento compartido que se puede compartir entre los contenedores.

Puedes pensar que un pod es un “host lógico” autónomo y aislado que posee las necesidades sistémicas de la aplicación para la que funciona.

El objetivo de un pod es ejecutar una única instancia de tu aplicación en tu clúster. Sin embargo, no se recomienda crear pods individuales de forma directa. En su lugar, puedes crear un conjunto de pods idénticos, llamados réplicas, para ejecutar tu aplicación. Un controlador, como una Implementación, crea y administra ese conjunto de pods replicados. Los controladores administran el ciclo de vida de sus pods constituyentes, y pueden realizar escalamientos horizontales y cambiar el número de pods según sea necesario.

Aunque puede que, de forma ocasional, interactúes con pods directamente a fin de depurar, solucionar problemas o inspeccionarlos, se recomienda que uses un controlador para administrar tus pods.

Los pods se ejecutan en los nodos en tu clúster. Una vez creado, un pod permanece en su nodo hasta que se completa su proceso, el pod se borra, es expulsado del nodo debido a falta de recursos o hasta que el nodo falla. Si un nodo falla, los pods en el nodo se programan para su eliminación de manera automática.

Ciclo de vida del pod

Los pods son efímeros. No están diseñados con el fin de funcionar para siempre y cuando un pod se termina, no se puede recuperar. En general, los pods no desaparecen hasta que un usuario o un controlador los borra.

Los pods no se “curan” ni se reparan por sí mismos. Por ejemplo, si un pod se programa en un nodo que luego falla, el pod se borra. De forma similar, un pod no se reemplaza a sí mismo si se lo expulsa a de un nodo por algún motivo.

Cada pod tiene un objeto de la API de PodStatus, que se representa con el campo status de un pod. Los pods publican su fase en el campo status: phase. La fase de un pod es un resumen de alto nivel del pod en su estado actual.

Cuando ejecutas kubectl get pod para inspeccionar un pod que se ejecuta en tu clúster, un pod puede estar en una de las siguientes fases:

  • Pendiente: el clúster creó y aceptó al pod, pero uno o más de sus contenedores aún no se ejecutan. En esta fase, se incluye el tiempo dedicado a la programación en un nodo y la descarga de imágenes.
  • En ejecución: el pod se vinculó a un nodo y se crearon todos los contenedores. Al menos un contenedor está en ejecución, está en proceso de iniciarse o se está reiniciando.
  • Exitoso: todos los contenedores en el pod terminaron con éxito. Los pods terminados no se reinician.
  • Con errores: todos los contenedores en el pod terminaron y al menos un contenedor falló. Un contenedor “falla” si sale con un estado que no es cero.
  • Desconocido: el estado del pod no se puede determinar.

Además, PodStatus contiene un arreglo llamado PodConditions, que se representa en el manifiesto del pod como conditions. El campo tiene un campo de type y status. conditions indica con más exactitud cuáles son las condiciones dentro del pod que causan su estado actual.

El campo de type puede contener PodScheduled, Ready, Initialized y Unschedulable. El campo de status se corresponde con el campo de type y puede contener True, False o Unknown.

Cómo crear pods

Debido a que los pods son efímeros, no es necesario crear pods de forma directa. Del mismo modo, como los pods no pueden repararse o reemplazarse por sí mismos, no se recomienda crear pods directamente.

En su lugar, puedes usar un controlador, como una Implementación, que crea y administra pods por ti. Los controladores también son útiles para implementar actualizaciones, como cambiar la versión de una aplicación que se ejecuta en un contenedor, ya que el controlador administra todo el proceso de actualización por ti.

Plantillas de pod

Los objetos de controlador, como Implementaciones y StatefulSets, contienen un campo de plantilla de pod. Las plantillas de pod contienen una especificación de pod que determina cómo debe ejecutarse cada pod, así como qué contenedores deben ejecutarse dentro de los pods y qué volúmenes deben activar los pods.

Los objetos de controlador usan plantillas de pod para crear pods y administrar su “estado deseado” dentro de tu clúster. Cuando se cambia una plantilla de pod, todos los pods futuros usarán la plantilla nueva, pero no así todos los pods existentes.

Para obtener más información sobre cómo funcionan las plantillas de pod, consulta Crea una implementación en la documentación de Kubernetes.

Controla en qué nodos se ejecuta un pod

De forma predeterminada, los pods se ejecutan en nodos en el grupo de nodos por defecto para el clúster. Puedes configurar el grupo de nodos que un pod selecciona de forma explícita o implícita:

  • Puedes forzar de forma explícita a un pod para que se implemente en un grupo de nodos específico mediante la configuración de nodeSelector en el manifiesto del pod. Esto fuerza a un pod a ejecutarse solo en nodos de ese grupo de nodos.

  • Puedes especificar las solicitudes de recursos para los contenedores que ejecutes. El pod se ejecutará solo en los nodos que cumplan con las solicitudes de recursos. Por ejemplo, si la definición del pod incluye un contenedor que requiere cuatro CPU, el servicio no seleccionará a los pods que se ejecutan en nodos con dos CPU.

Patrones de uso de pods

Hay dos formas principales de usar pods:

  • Pods que ejecutan un solo contenedor. El patrón de pod más simple y común es un contenedor único por pod, en el que el contenedor único representa una aplicación completa. En este caso, puedes pensar en un pod como un wrapper.
  • Pods que ejecutan múltiples contenedores que deben trabajar en conjunto. Los pods con múltiples contenedores se usan principalmente para admitir programas de ubicación y administración conjunta que deben compartir recursos. Estos contenedores de ubicación conjunta pueden formar una unidad de servicio coherente: un contenedor entrega archivos desde un volumen compartido mientras que otro contenedor actualiza esos archivos. El pod une estos contenedores y recursos de almacenamiento y forma una sola entidad administrable.

El objetivo de cada pod es ejecutar una única instancia de una aplicación dada. Si quieres ejecutar varias instancias, debes usar un pod por cada instancia de la aplicación. En general, esto se conoce como replicación. Un controlador, como una Implementación, crea y administra los pods replicados.

Finalización de un pod

Los pods finalizan de forma estable cuando sus procesos se completan. De forma predeterminada, todas las terminaciones son estables por 30 segundos.

Puedes borrar un pod de forma manual con el comando kubectl delete. La marca --grace-period del comando te permite anular el período de gracia predeterminado.

Pasos siguientes

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...