Pod

La unidad más pequeña que puede utilizar Kubernetes es el Pod. En inglés, Pod significa "vaina", y podemos entender un Pod como una envoltura que contiene uno o varios contenedores (en la mayoría de los casos, un solo contenedor). De forma genérica, un Pod representa un conjunto de contenedores que comparten almacenamiento y una única IP.

Este diagrama muestra un Pod que contiene dos contenedores, cada uno ejecutando un proceso diferente. El Contenedor 1 ejecuta el Proceso 1 y el Contenedor 2 ejecuta el Proceso 2.

Un aspecto muy importante que hay que asumir es que los Pods son efímeros; se lanzan y, en determinadas circunstancias, se paran o se destruyen, creando en muchos casos nuevos Pods que sustituyen a los anteriores. Esto tiene importantes ventajas a la hora de realizar modificaciones en los despliegues en producción, pero tiene una consecuencia directa sobre la información que pueda tener almacenada el Pod. Por lo tanto, necesitaremos utilizar algún mecanismo adicional cuando necesitemos que la información sobreviva a un Pod. Aunque Kubernetes es un orquestador de contenedores, la unidad mínima de ejecución es el Pod, que contendrá uno o más contenedores según las necesidades:

• En la mayoría de los casos, y siguiendo el principio de un proceso por contenedor, evitamos tener sistemas (como máquinas virtuales) ejecutando docenas de procesos. Lo más habitual será tener un Pod en cuyo interior se define un contenedor que ejecuta un solo proceso.
• En determinadas circunstancias, será necesario ejecutar más de un proceso en el mismo "sistema", como en los casos de procesos fuertemente acoplados. En esos casos, tendremos más de un contenedor dentro del Pod, cada uno ejecutando un solo proceso, pero pudiendo compartir almacenamiento y una misma dirección IP como si se tratase de un sistema ejecutando múltiples procesos.

Existen además algunas razones que hacen conveniente tener esta capa adicional por encima de la definición de contenedor:

• Kubernetes puede trabajar con distintos sistemas de gestión de contenedores (Docker, containerd, Rocket, CRI-O, etc.), por lo que es muy conveniente añadir una capa de abstracción que permita utilizar Kubernetes de una forma homogénea e independiente del sistema de contenedores interno asociado.
• Esta capa de abstracción añade información adicional necesaria en Kubernetes, como por ejemplo, políticas de reinicio, comprobaciones de que la aplicación esté inicializada (readiness probe) o comprobaciones de que la aplicación haya realizado alguna acción especificada (liveness probe).

Pod con un solo contenedor

En la situación más habitual, se definirá un Pod con un contenedor en su interior para ejecutar un solo proceso, y este Pod estará ejecutándose mientras lo haga el correspondiente proceso dentro del contenedor. Algunos ejemplos pueden ser: ejecución en modo demonio de un servidor web, ejecución de un servidor de aplicaciones Java, ejecución de una tarea programada, ejecución en modo demonio de un servidor DNS, etc.

Pod multicontenedor

En algunos casos, la ejecución de un solo proceso por contenedor no es la solución ideal, ya que existen procesos fuertemente acoplados que no pueden comunicarse entre sí fácilmente si se ejecutan en diferentes sistemas. En esos casos, la solución planteada es definir un Pod multicontenedor y ejecutar cada proceso en un contenedor, pero que puedan comunicarse entre sí como si lo estuvieran haciendo en el mismo sistema, utilizando un dispositivo de almacenamiento compartido si fuese necesario (para leer y escribir archivos entre ellos) y compartiendo externamente una misma dirección IP. Un ejemplo típico de un Pod multicontenedor es un servidor web Nginx con un servidor de aplicaciones PHP-FPM, que se implementaría mediante un solo Pod, pero ejecutando un proceso de Nginx en un contenedor y otro proceso de PHP-FPM en otro contenedor.