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 de 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; entonces, el pod se borra y se expulsa 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 de un nodo por algún motivo.

Cada pod tiene un objeto de la API PodStatus, que se representa mediante 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, el 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 type y un campo status. conditions indica con más exactitud las condiciones dentro del pod que causan su estado actual.

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

Crea 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.

Solicitudes de pods

Cuando un pod comienza a ejecutarse, solicita una cantidad de CPU y memoria. Esto ayuda a Kubernetes a programar el pod en un nodo apropiado para ejecutar la carga de trabajo. Un Pod no se programará en un nodo que no tenga los recursos para cumplir con la solicitud del pod. Una solicitud es la cantidad mínima de CPU o memoria que Kubernetes garantiza a un pod.

Puedes configurar las solicitudes de CPU y memoria para un pod, en función de los recursos que necesiten tus aplicaciones. También puedes especificar solicitudes para contenedores individuales que se ejecutan en el pod. Ten en cuenta lo siguiente:

  • La solicitud predeterminada para la CPU es de 100 M. Esto es demasiado pequeño para muchas aplicaciones, y es probable sea mucho más pequeño que la cantidad de CPU disponible en el nodo.
  • No hay ninguna solicitud predeterminada para la memoria. Un pod sin una solicitud de memoria predeterminada se podría programar en un nodo sin suficiente memoria para ejecutar las cargas de trabajo del pod.
  • Configurar un valor demasiado pequeño para las solicitudes de CPU o memoria podría causar que se programen demasiados pods o una combinación subóptima de pods en un nodo determinado y reducir el rendimiento.
  • Si se configura un valor demasiado grande para las solicitudes de CPU o memoria, el pod podría no poder programarse y aumentar el costo de los recursos del clúster.
  • Además de, o en lugar de, configurar los recursos de un pod, puedes especificar recursos para contenedores individuales que se ejecutan en el pod. Si solo especificas recursos para los contenedores, las solicitudes del pod son la suma de las solicitudes especificadas para los contenedores. Si especifican ambos, la suma de solicitudes para todos los contenedores no debe exceder las solicitudes de pod.

Se recomienda que configures las solicitudes para los pods en función de los requisitos de las cargas de trabajo reales. Para obtener más información, consulta las recomendaciones de Kubernetes sobre solicitudes y límites de recursos en el blog de GCP.

Límites de pods

De forma predeterminada, un pod no tiene límite superior en la cantidad máxima de CPU o memoria que puede usar en un nodo. Puedes configurar límites para controlar la cantidad de CPU o memoria que el pod puede usar en un nodo. Un límite es la cantidad máxima de CPU o memoria que Kubernetes garantiza a un pod.

Además de, o en lugar de, configurar los límites de un pod, puedes especificar límites para contenedores individuales que se ejecutan en el pod. Si solo especificas límites para los contenedores, los límites del pod son la suma de los límites especificados para los contenedores. Sin embargo, cada contenedor solo puede acceder a los recursos hasta su límite. Por lo tanto, si decides especificar los límites solo en contenedores, debes especificar límites para cada contenedor. Si se especifican ambos, la suma de límites para todos los contenedores no debe exceder las solicitudes de pods.

Los límites no se tienen en cuenta cuando se programan pods, pero pueden evitar la contención de recursos entre pods en el mismo nodo y evitar que un pod cause inestabilidad del sistema en el nodo mediante la privación de recursos al sistema operativo subyacente.

Se recomienda que configures límites para los pods en función de los requisitos de las cargas de trabajo reales. Para obtener más información, consulta las recomendaciones de Kubernetes sorbe solicitudes y límites de recursos en el blog de GCP.

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 la página sobre cómo crear una implementación en la documentación de Kubernetes.

Controla en qué nodos se ejecuta un pod

Por defecto, los pods se ejecutan en nodos en el grupo de nodos predeterminado 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 varios 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 única: 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 única 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. Kubernetes impone un período de finalización ordenado predeterminado de 30 segundos. Cuando borras un pod, puedes anular este período de orden si configuras la marca --grace-period en la cantidad de segundos que esperará a que el Pod termine antes de terminarlo por la fuerza.

Pasos siguientes

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

Enviar comentarios sobre...

Documentación de Kubernetes Engine