Acerca de los Pods
Los Pods son la unidad API más pequeña en Kubernetes. En términos más técnicos, los Pods son la unidad de programación atómica en Kubernetes. Pero, ¿por qué necesitamos Pods? Para responder a esta pregunta, primero debemos entender la esencia de un contenedor: un contenedor es esencialmente un proceso. Así es. Los contenedores son procesos en un sistema de computación en la nube, y las imágenes de contenedores son esencialmente paquetes de instalación “.exe” para este sistema. Kubernetes, en esta analogía, actúa como el sistema operativo.
Procesos y grupos de procesos
Ingresemos a una máquina Linux y ejecutemos el siguiente comando:
$ pstree -g
Este comando muestra la estructura de árbol de los procesos que se están ejecutando actualmente en el sistema. La salida podría verse así:
systemd(1)-+-accounts-daemon(1984)-+-{gdbus}(1984)
| `-{gmain}(1984)
|-acpid(2044)
...
|-lxcfs(1936)-+-{lxcfs}(1936)
| `-{lxcfs}(1936)
|-mdadm(2135)
|-ntpd(2358)
|-polkitd(2128)-+-{gdbus}(2128)
| `-{gmain}(2128)
|-rsyslogd(1632)-+-{in:imklog}(1632)
| |-{in:imuxsock) S 1(1632)
| `-{rs:main Q:Reg}(1632)
|-snapd(1942)-+-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
Como se puede ver, en un sistema operativo real, los procesos no se ejecutan de forma aislada. En cambio, se organizan en grupos de procesos. Por ejemplo, el programa rsyslogd es responsable del procesamiento de registros en Linux. El programa principal de rsyslogd, main, y el módulo del kernel de registro imklog que utiliza pertenecen al grupo de procesos 1632. Estos procesos colaboran para cumplir con las responsabilidades del programa rsyslogd. Kubernetes esencialmente asigna este concepto de “grupos de procesos” a la tecnología de contenedores y lo convierte en un “ciudadano de primera clase” en este “sistema operativo” de computación en la nube. Kubernetes adopta este enfoque porque los ingenieros de Google se dieron cuenta de que las aplicaciones que implementaban a menudo mostraban relaciones similares a las de “procesos y grupos de procesos”. Específicamente, estas aplicaciones requerían una colaboración estrecha, lo que hacía necesario implementarlas en la misma máquina. Gestionar dichas relaciones operativas sin el concepto de “grupos” sería increíblemente difícil. Tomemos rsyslogd como ejemplo. Consta de tres procesos: un módulo imklog, un módulo imuxsock y la función principal del proceso de rsyslogd. Estos tres procesos deben ejecutarse en la misma máquina; de lo contrario, su comunicación basada en sockets y el intercambio de archivos tendrían problemas.
Comunicación entre contenedores
Como se muestra en el diagrama anterior, este Pod contiene dos contenedores de usuario, A y B, y un contenedor Infra. En Kubernetes, el contenedor Infra está diseñado para consumir recursos mínimos y utiliza una imagen especial llamada k8s.gcr.io/pause. Esta imagen representa un contenedor, escrito en lenguaje ensamblador, que permanece perpetuamente en un estado “pausado”, con un tamaño sin comprimir de solo 100-200 KB. Una vez que el contenedor Infra “posee” el Namespace de red, los contenedores de usuario pueden unirse a este namespace. Por lo tanto, si examinas los archivos de Namespace de estos contenedores en la máquina host (la ruta de este archivo se mencionó anteriormente), apuntarán exactamente al mismo valor. Esto significa que, para los contenedores A y B dentro del Pod, pueden comunicarse directamente usando localhost. Perciben los mismos dispositivos de red que el contenedor Infra. Un Pod tiene solo una dirección IP, que es la dirección IP asociada con el Namespace de red del Pod. Naturalmente, todos los demás recursos de red se asignan por Pod y son compartidos por todos los contenedores dentro de ese Pod. El ciclo de vida de un Pod está únicamente ligado al contenedor Infra y es independiente de los contenedores A y B. Además, para todos los contenedores de usuario dentro del mismo Pod, su tráfico entrante y saliente puede considerarse que pasa a través del contenedor Infra. Este aspecto es crucial porque si desarrollas un plugin de red para Kubernetes en el futuro, tu enfoque principal debe ser configurar el Namespace de red del Pod, no cómo cada contenedor de usuario utiliza tu configuración de red. Esto último es irrelevante. Esto implica que si tu plugin de red depende de instalar paquetes o configuraciones dentro del contenedor, no es una solución viable. El sistema de archivos raíz de la imagen del contenedor Infra está prácticamente vacío, sin dejar espacio para personalización. Por el contrario, esto también significa que tu plugin de red no necesita preocuparse por el estado de inicio de los contenedores de usuario, sino únicamente por configurar el Pod, es decir, el Namespace de red del contenedor Infra.
Con este diseño, compartir volúmenes se vuelve mucho más sencillo. Kubernetes puede definir todas las configuraciones de volumen a nivel de Pod. En consecuencia, el directorio host correspondiente a un volumen es único para el Pod, y cualquier contenedor dentro del Pod solo necesita declarar el montaje de ese directorio.
Esta filosofía de diseño detrás de los Pods, que fomenta una “relación superestrecha” entre los contenedores, tiene como objetivo alentar a los usuarios a considerar si las aplicaciones con múltiples componentes funcionalmente no relacionados que se ejecutan en un solo contenedor podrían representarse mejor como múltiples contenedores dentro de un Pod.
Para comprender esta mentalidad, intenta aplicarla a escenarios que son difíciles de resolver con un solo contenedor. Por ejemplo, imagina una aplicación que envía continuamente archivos de registro al directorio /var/log dentro del contenedor. En este caso, puedes montar un volumen dentro del Pod en el directorio /var/log del contenedor de la aplicación. Luego, dentro del mismo Pod, ejecuta un contenedor sidecar que también declare montar el mismo volumen en su directorio /var/log. A partir de ahí, la única tarea del contenedor sidecar es leer continuamente los archivos de registro de su directorio /var/log y reenviarlos a soluciones de almacenamiento como MongoDB o Elasticsearch. Esta configuración establece un mecanismo básico de recolección de registros.
Similar al primer ejemplo, la función principal del sidecar en este escenario también gira en torno al uso del volumen compartido para operaciones de archivos. Sin embargo, no se debe pasar por alto la otra característica crucial de los Pods: todos los contenedores dentro de un Pod comparten el mismo Namespace de red. Esto permite delegar muchas configuraciones y tareas de gestión relacionadas con la red del Pod al sidecar, sin necesidad de interferir con los contenedores de usuario. Un ejemplo destacado de esto es el proyecto Istio service mesh.
Resumen
En esta discusión, profundizamos en las razones detrás de la necesidad de los Pods. En esencia, un Pod sirve como la unidad fundamental dentro de un clúster de Kubernetes, encapsulando uno o más contenedores (generalmente contenedores Docker). Estos contenedores comparten recursos de red y almacenamiento. Desde la perspectiva de los procesos y grupos de procesos, un Pod puede verse como un grupo de procesos ligero. Permite implementar, escalar y gestionar múltiples procesos que colaboran estrechamente (contenedores) como una unidad cohesiva, simplificando la implementación y operación de aplicaciones complejas. En el próximo artículo, proporcionaremos una explicación más profunda de los Pods.
Novita AI es la plataforma integral en la nube que potencia tus ambiciones de IA. Con API integradas sin problemas, computación sin servidor y aceleración GPU, proporcionamos las herramientas rentables que necesitas para construir y escalar rápidamente tu negocio impulsado por IA. Elimina los problemas de infraestructura y comienza gratis: Novita AI hace realidad tus sueños de IA.
Lectura recomendada:
