Introducción al despliegue de aplicaciones con pods en Kubernetes gestionado
El auge de los contenedores y la orquestación de aplicaciones ha transformado la forma en que las empresas desarrollan, despliegan y mantienen sus servicios. Kubernetes se ha posicionado como la plataforma líder para la gestión de contenedores, y entender cómo desplegar aplicaciones usando pods es fundamental para aprovechar todo su potencial.
En este artículo técnico y detallado aprenderás, paso a paso, los conceptos esenciales, la estructura declarativa, las buenas prácticas y las herramientas para poner en marcha una aplicación contenida en un pod dentro de un clúster Kubernetes gestionado. La información está orientada a profesionales que buscan profundizar en Kubernetes, así como a quienes desean implementar soluciones estables y escalables en la nube.
1. Conceptos básicos: ¿Qué es un pod en Kubernetes?
Un pod es la unidad mínima ejecutable en Kubernetes. Representa una o más instancias de contenedores que comparten almacenamiento y red, y se ejecutan en un mismo nodo dentro del clúster. Aunque un pod puede contener múltiples contenedores, lo más común es que contenga uno solo, especialmente en aplicaciones simples o microservicios.
Los pods son efímeros, lo que significa que no están diseñados para ser duraderos por sí mismos. Para gestionar su ciclo de vida, se emplean objetos superiores como Deployments, que garantizan la disponibilidad y actualizaciones controladas.
Importancia de los pods en Kubernetes gestionado
- Permiten encapsular una aplicación contenida dentro de uno o varios contenedores.
- Facilitan la gestión del ciclo de vida a nivel de contenedores agrupados.
- Servidos y orquestados automáticamente por el clúster.
2. Prerrequisitos para desplegar una aplicación en pods
Antes de iniciar el despliegue, es imprescindible contar con algunos elementos esenciales para que Kubernetes pueda ejecutar correctamente los pods y los contenedores que contienen:
2.1 Imagen de contenedor (formato OCI)
La imagen debe seguir el estándar OCI (Open Container Initiative), es decir, un formato universal compatible con múltiples sistemas de gestión de contenedores.
Cabe destacar que, aunque muchas personas denominan estas imágenes “imágenes Docker”, técnicamente Kubernetes trabaja con imágenes OCI. Por ejemplo, Docker es solo uno de los tantos sistemas para construir imágenes; otros como Buildah o Kaniko también cumplen con este estándar. La imagen debe contener la aplicación lista para ejecutarse en un contenedor.
2.2 Registro de imágenes accesible
La imagen debe estar almacenada en un registro de contenedores, que puede ser público (como Docker Hub) o privado. Para accesos a registros privados, Kubernetes necesita configuraciones especiales de autenticación.
2.3 Acceso a un clúster Kubernetes gestionado
Debes disponer de acceso a un clúster Kubernetes gestionado, es decir, donde la infraestructura y las tareas de mantenimiento del clúster son administradas por un proveedor, facilitando la operación y el escalado.
3. Despliegue declarativo: el método recomendado en Kubernetes
Kubernetes ofrece dos enfoques para desplegar objetos en el clúster: imperativo y declarativo. El imperativo se limita a comandos rápidos y operaciones puntuales, mientras que el declarativo es la modalidad preferida en producción.
En el despliegue declarativo, definimos el estado deseado mediante archivos en formato YAML. Estos archivos describen objetos Kubernetes (pods, deployments, servicios, etc.) y se aplican en el clúster para que Kubernetes mantenga ese estado.

Ventajas del enfoque declarativo
- Control de versiones y reproducibilidad
- Automatización en CI/CD
- Mayor facilidad en auditorías y mantenibilidad
4. Estructura de un archivo YAML para pods
Los archivos YAML que describen objetos Kubernetes siguen una estructura similar con cuatro secciones principales:
Sección | Descripción | Ejemplo |
---|---|---|
apiVersion | Indica la versión de la API que se está utilizando para ese objeto | v1 |
kind | Tipo de objeto que se va a crear (ej. Pod, Deployment, Service) | Pod |
metadata | Información descriptiva que incluye nombre, etiquetas, etc. | name: demo labels: app: demo |
spec | Especificación del objeto: configuración concreta, puertos, contenedores, etc. | containers: – name: nginx image: nginx ports: – containerPort: 80 |
Explicación detallada de cada sección
apiVersion debe ser compatible con el objeto que se está definiendo. Por ejemplo, para pods, siempre será v1
. El campo kind determina qué tipo de objeto se está creando.
En la sección metadata, el campo name
es el identificador único dentro del espacio de nombres, y las labels (etiquetas) permiten categorizar y seleccionar objetos mediante consultas.
Finalmente, la sección spec define la configuración específica. En un pod, es obligatorio definir los contenedores que alojará, indicando nombre, imagen y puertos expuestos.
5. Ejemplo práctico: despliegue de un pod con NGINX
Veamos un ejemplo básico de un archivo YAML para desplegar un pod con la imagen oficial de NGINX:
apiVersion: v1 kind: Pod metadata: name: demo labels: app: demo spec: containers: - name: nginx-container image: nginx ports: - containerPort: 80
Con este archivo, indicamos a Kubernetes que cree un pod llamado demo
que contenga un único contenedor ejecutando la imagen nginx
expuesta por el puerto 80.
6. Aplicando el archivo YAML al clúster
Para crear el recurso definido en el archivo usamos la herramienta de línea de comandos kubectl
, que interactúa con el clúster de Kubernetes.
kubectl apply -f pod-demo.yaml
Este comando aplicará la definición y creará el pod en el clúster. Para verificar que el pod está en ejecución, podemos usar:
kubectl get pods
La salida mostrará el estado actual de los pods, incluyendo el nombre, estado, y tiempos de ejecución.
Diferencia entre estado “Created” y “Running”
Es importante entender que una vez que Kubernetes crea el pod, el contenedor puede tardar en arrancar. La condición Running
indica que el contenedor está ejecutándose correctamente. Si el contenedor falla, Kubernetes mantiene el pod, pero el contenedor puede estar en estado CrashLoopBackOff
o Error
.
7. Dirección IP y acceso a los pods
Cada pod recibe una dirección IP interna del clúster, conocida como IP Cluster. Esta IP es privada y solo accesible desde dentro del clúster. Esto significa que no es posible acceder a un pod directamente desde el exterior sin configuraciones adicionales.

Por defecto, la IP se sitúa en rangos privados, típicamente 10.x.x.x, lo que aísla el pod del tráfico externo.
Métodos para acceder a pods
- Port Forwarding: Crear un túnel TCP entre tu máquina local y el puerto de un pod dentro del clúster.
- Servicios (Services): Exponer el pod mediante un servicio que gestiona el tráfico de red, como servicios ClusterIP, NodePort o LoadBalancer.
- Acceder desde otro pod: Pod permite que la comunicación interna entre pods utilice las IPs privadas.
8. Port Forwarding para pruebas rápidas
El comando kubectl port-forward
es útil para depuración y pruebas temporales. Establece un túnel desde un puerto local hacia un puerto específico en el pod.
kubectl port-forward demo 8888:80
Con este comando, la aplicación que corre dentro del pod demo
en el puerto 80 queda accesible en el puerto 8888 de tu máquina.
Para verificar el acceso, desde otra terminal puedes ejecutar:
curl http://localhost:8888/
Este método es temporal y solo funciona mientras el comando esté activo.
9. Comunicación entre pods dentro del clúster
Los pods en Kubernetes pueden comunicarse entre sí mediante las IPs privadas del clúster. Para probar esto, podemos crear un segundo pod con herramientas de red que nos permitan interactuar con otros pods.
Creación de un pod de diagnóstico con BusyBox
El siguiente comando crea un pod que ejecuta BusyBox
, una imagen ligera con utilidades básicas de Linux, lanzando un shell interactivo:
kubectl run busybox --image=busybox -it --rm --restart=Never -- sh
Esta sesión interactiva permite ejecutar comandos para verificar la conectividad interna, por ejemplo con:
wget -qO- http://IP_DEL_POD_DEMO
Desde dentro de este pod, se puede acceder a la IP privada del pod demo
y obtener la respuesta esperada.
10. Desplegando aplicaciones reales: consideraciones y objetos adicionales
El ejemplo con pods es ideal para introducir conceptos, pero en aplicaciones reales se requiere mayor complejidad para garantizar resiliencia, escalabilidad y administración.
Entre los principales recursos imprescindibles para producción se encuentran:

- Deployments: Gestionan actualizaciones, escalado y mantenimiento de pods replicados.
- Services: Exponen pods para acceso interno o externo, asignan IPs virtuales y balanceo de carga.
- ConfigMaps y Secrets: Manejo de configuración externa y credenciales.
- Ingress Controllers: Ofrecen reglas avanzadas de acceso externo al clúster.
Comparativa de recursos básicos para despliegue
Recurso | Función | Uso común |
---|---|---|
Pod | Unidad mínima con contenedores | Desplegar contenedor simple, pruebas rápidas |
Deployment | Gestiona réplicas, actualizaciones | Aplicaciones en producción |
Service | Exposición y acceso | Aislar, balancear y exponer pods |
ConfigMap/Secret | Configuración externa y credenciales | Separar configuración del código |
11. Buenas prácticas al desplegar pods
- Usar Deployments en lugar de pods directos para producción: garantizan alta disponibilidad y escalabilidad.
- Etiquetar correctamente todos los recursos: facilita organización y selección.
- Gestionar imágenes con versiones explícitas: evitar usar la etiqueta
latest
para evitar problemas en producción. - Definir recursos y límites de CPU y memoria: mejora la estabilidad del clúster.
- Monitorear el estado de los pods y logs: prevenir fallos y optimizar desempeño.
12. Herramientas para la gestión y resolución de incidencias
- kubectl logs <pod>: para consultar los logs de contenedores.
- kubectl describe pod <pod>: muestra detalles del pod y eventos.
- kubectl exec <pod> — sh: para entrar al shell del contenedor y diagnosticar internamente.
- Ports forward y creación de pods temporales para pruebas internas.
13. Integración con registros privados y autenticación
Cuando sus imágenes están en registros privados es necesario configurar las credenciales para que Kubernetes pueda descargar las imágenes correctamente. Esto se realiza creando un objeto llamado Secret
de tipo docker-registry
y asociándolo a los pods.
Ejemplo básico para crear un Secret Docker Registry:
kubectl create secret docker-registry registry-secret --docker-server=REGISTRY_URL --docker-username=USER --docker-password=PASSWORD --docker-email=EMAIL
Y en el YAML del pod se añade dentro de spec:
imagePullSecrets: - name: registry-secret
14. Escalado y actualizaciones continuas
El despliegue de aplicaciones en Kubernetes gestionado permite aprovechar herramientas como Helm para gestionar releases, además de estrategias de escalado automático (Horizontal Pod Autoscaling) para ajustar la cantidad de pods según la carga.
Actualizar una aplicación consiste en crear una nueva versión de la imagen y modificar el deployment para que Kubernetes realice un “rolling update”, evitando interrupciones.
15. Palabras clave importantes en el contexto de Kubernetes y pods
Pod
El elemento básico que ejecuta uno o más contenedores. Entender su ciclo de vida y características es fundamental para desplegar aplicaciones efectivas.
ClusterIP
Dirección IP interna que Kubernetes asigna a los pods y servicios para la comunicación dentro del clúster.
Deployment
Objeto que administra pods replicados, controla la actualización y garantiza disponibilidad.
kubectl
Herramienta de línea de comandos para interactuar con el clúster Kubernetes; vital para desplegar y administrar recursos.
OCI (Open Container Initiative)
El estándar que garantiza compatibilidad entre diferentes sistemas de contenedores y asegura la portabilidad de imágenes.
YAML
Formato de archivo para describir recursos declarativamente en Kubernetes; clave para la gestión de infraestructuras como código.

¿Quieres comprender en profundidad los procesos de despliegue en Kubernetes? Te invitamos a ver este recurso adicional donde se explica paso a paso con ejemplos prácticos.
Preguntas frecuentes (FAQ)
¿Cómo puedo acceder a un pod en Kubernetes?
Para acceder a un pod, se pueden usar herramientas como kubectl port-forward
que crea un túnel TCP desde la máquina local hacia el puerto del pod, permitiendo acceso temporal. También se puede acceder mediante la creación de un objeto Service que exponga el pod internamente o externamente. Desde otro pod dentro del clúster, es posible acceder directamente a la IP privada del pod. Kubernetes gestiona el ciclo y la orquestación para mantener el estado deseado.
¿Cuál es la diferencia entre pods e implementaciones en Kubernetes?
Un pod representa una instancia única de contenedores corriendo juntos; es la unidad mínima de ejecución. Un Deployment es un objeto que gestiona réplicas de pods, garantiza su disponibilidad, permite actualizaciones continuas (rolling updates) y facilita el escalado automático. Por lo tanto, el deployment controla el ciclo de vida y la cantidad de pods que deben estar activos, proporcionando estabilidad y resiliencia a la aplicación.
¿Qué comando se utiliza para ver los logs de un pod en Kubernetes?
El comando kubectl logs <pod-name>
permite recuperar y mostrar los registros de un contenedor específico dentro del pod. Esto es útil para depurar problemas, monitorear la aplicación o analizar comportamientos inesperados dentro del clúster.
¿Qué debo considerar al definir un pod en YAML?
Es fundamental definir correctamente la versión de api (apiVersion
), el tipo de objeto (kind
), el nombre y etiquetas en metadata
, y especialmente la sección spec
, que incluye la lista de contenedores, imágenes precisas y puertos expuestos. Adicionalmente, la gestión de recursos y políticas de reinicio también son importantes para producción.
¿Es recomendable desplegar aplicaciones directamente con pods sin deployment?
Para pruebas rápidas y entornos de desarrollo, el despliegue de pods directamente es útil. Sin embargo, para entornos de producción, se recomienda usar deployments u otros controladores que gestionen la escalabilidad, la actualización continua y recuperación de fallos, asegurando así la estabilidad del servicio.
¿Cómo manejo la autenticación para registros privados de imágenes?
Debes crear un secreto tipo docker-registry
que contenga las credenciales para acceder al registro privado y luego asociarlo a tus pod o deployments mediante imagePullSecrets
. Esto garantiza que Kubernetes pueda descargar la imagen privada sin problemas.
¿Puedo exponer un pod de forma directa a internet?
No directamente. Los pods tienen IPs internas no accesibles desde internet. Para exponer una aplicación al exterior, se debe crear un Service de tipo NodePort
o LoadBalancer
, o configurar un Ingress Controller que gestione el acceso externo de manera segura y escalable.
¿Cómo escalar una aplicación desplegada en Kubernetes?
Se puede escalar un deployment aumentando el número de réplicas especificadas en el archivo YAML o usando el comando kubectl scale
. Para escalado automático, se configura un Horizontal Pod Autoscaler (HPA) que ajusta el número de pods según métricas de uso de CPU u otras.
¿Qué pasa si un pod falla en ejecución?
Si un pod falla, Kubernetes intenta reiniciarlo automáticamente según la política de reinicio especificada. En deployments o controladores superiores, también se crean nuevos pods para mantener la cantidad deseada replicada. Es importante monitorear logs y eventos para diagnosticar y corregir la causa raíz.
¿Cómo puedo depurar problemas de conectividad entre pods?
Una práctica común es desplegar pods temporales con imágenes ligeras (como BusyBox o Alpine) que permitan ejecutar shells y herramientas de red como wget
o curl
. Esto facilita probar conectividad interna y diagnosticar errores en la red del clúster.

Conclusión
El despliegue de aplicaciones mediante pods en Kubernetes gestionado es un proceso fundamental para todos aquellos que quieren aprovechar las ventajas de la orquestación de contenedores. Aunque empezar con pods simples es ideal para entender conceptos, para aplicar soluciones robustas en producción es indispensable usar objetos como Deployments y Services, y emplear buenas prácticas en la gestión de imágenes, autenticación y monitoreo.
¿Buscás implementar este tipo de soluciones en tu empresa? En Código6 podemos ayudarte. Somos especialistas en automatización, inteligencia artificial y transformación digital. Contactanos para comenzar tu proyecto hoy.
Leave A Comment