Pods en Kubernetes: dos contenedores en un Pod

Resumen y flujo de tráfico en Kubernetes: cliente a Pod explicado paso a paso. Cuando un cliente hace una petición por DNS o por el nombre del host, esa petición llega al IP publico del balanceador que expone el ingress nginx. El ingreso llega al Pod del ingress nginx (Nginx) y el recurso Ingress evalúa el host y el path para decidir qué Service debe recibir la petición. El Service actúa en L4 con un ClusterIP y puerto y consulta sus Endpoints, que son las IPs de Pod con los targetPort correspondientes. El Service selecciona Pods mediante labels y enruta hacia PodIP:targetPort. Dentro de un Pod los contenedores comparten la misma IP de red, lo que cambia son las puertas de entrada por puerto.

Qué es un Pod. El Pod es la unidad mínima desplegable en Kubernetes y puede contener uno o varios contenedores. Los contenedores del mismo Pod comparten el mismo namespace de red y por tanto el mismo Pod IP y localhost común. También pueden compartir volúmenes si están montados. Importante: en producción no se suelen crear Pods de forma directa, sino que se crean Deployments que gestionan ReplicaSets y éstos crean los Pods.

Por qué usar Namespaces. Los namespaces aíslan nombres y contextos, por ejemplo poder tener api1 en dev y api1 en prod sin conflicto. Además sirven para controlar accesos con RBAC, aplicar quotas y políticas de red. El ciclo de vida es simple: borrar un namespace elimina todos los recursos dentro de él.

Ejemplo práctico de dos APIs en el mismo Pod. Es habitual agrupar dos procesos estrechamente relacionados en el mismo Pod para que compartan red y almacenamiento. Imaginemos un Deployment que crea un Pod con dos contenedores, api3a escuchando en el puerto 8080 y api3b en el puerto 8081. Cada contenedor define variables de entorno y probes de disponibilidad y liveness que permiten a Kubernetes saber cuándo enviar tráfico o reiniciar el contenedor si falla. Las readinessProbe y livenessProbe suelen usar peticiones HTTP a la ruta raiz o endpoints de salud con delays y periodos para dar tiempo a arranques lentos.

Por qué dos puertos. Dado que los contenedores del mismo Pod comparten la IP, cada contenedor debe exponer puertos distintos para evitar conflictos. El Service que expone cada API puede usar selectors basados en labels o en anotaciones para diferenciar qué tráfico dirigir a qué puerto del Pod. Esta arquitectura es útil para sidecars, proxies o microservicios que requieren comunicación local de baja latencia.

Buenas prácticas. Usar Deployments en lugar de Pods sueltos para mantener replicas, actualizaciones y rollbacks. Diseñar probes de readiness y liveness adecuadas. Aplicar namespaces para separar entornos y RBAC para controlar accesos. Evitar mezclar responsabilidades demasiado distintas en un mismo Pod y preferir sidecars para funcionalidades de soporte como logging, proxy o autenticación.

Sobre Q2BSTUDIO. En Q2BSTUDIO somos una empresa de desarrollo de software especializada en aplicaciones a medida y software a medida, con experiencia en inteligencia artificial, ciberseguridad y servicios cloud. Ofrecemos arquitecturas modernas que incluyen despliegues en Kubernetes y gestión de infraestructuras en la nube. Si buscas migrar o desplegar soluciones en la nube contamos con servicios cloud aws y azure que te ayudan a escalar y asegurar tus aplicaciones, revisa nuestras opciones en servicios cloud aws y azure. Además desarrollamos aplicaciones a medida y multiplataforma pensadas para negocio, puedes ver ejemplos y servicios en desarrollo de aplicaciones a medida.

También prestamos servicios de inteligencia de negocio, implementaciones con power bi y soluciones de ia para empresas incluyendo agentes IA y automatización que impulsan la toma de decisiones. Nuestros servicios integran ciberseguridad y prácticas de pentesting para proteger los despliegues y la infraestructura. Si necesitas una consultoría o un proyecto llave en mano en Kubernetes, despliegue cloud, inteligencia artificial o BI, en Q2BSTUDIO acompañamos desde el diseño a la operación.

Continuará en el siguiente post con ejemplos de manifestos, selectors y configuración de Services y Endpoints para este tipo de despliegues.