# Kubernetes: Pods, Services y Deployments para Entrevistas Técnicas > Guía completa de Kubernetes para entrevistas técnicas. Domina Pods, Services, Deployments, HPA y las preguntas más frecuentes en entrevistas DevOps. - Published: 2026-04-04 - Updated: 2026-04-04 - Author: SharpSkill - Tags: kubernetes, devops, pods, services, deployments, entrevista - Reading time: 12 min --- Conseguir una posición DevOps o de ingeniería de plataformas en el mercado latinoamericano actual requiere demostrar conocimientos sólidos en Kubernetes. Las empresas tecnológicas de la región, desde startups fintech hasta grandes corporativos, evalúan candidatos con preguntas prácticas sobre la orquestación de contenedores. Este artículo cubre los conceptos fundamentales que todo profesional debe dominar: Pods, Services y Deployments, junto con ejemplos de código listos para producción. > **Referencia rápida para la entrevista** > > Los tres recursos más consultados en entrevistas de Kubernetes son: **Pod** (unidad mínima de ejecución), **Deployment** (gestión declarativa de réplicas) y **Service** (abstracción de red para descubrimiento). Tener claras estas diferencias marca la diferencia entre aprobar o reprobar la entrevista técnica. ## Pods: La Unidad Fundamental de Kubernetes Un Pod representa la unidad de ejecución más pequeña en Kubernetes. Contrario a lo que muchos candidatos responden en entrevistas, un Pod no es simplemente "un contenedor". Un Pod es una abstracción que encapsula uno o más contenedores que comparten el mismo namespace de red, almacenamiento y ciclo de vida. En la práctica de producción, la mayoría de los Pods ejecutan un solo contenedor. Sin embargo, existen patrones válidos como el sidecar (contenedor auxiliar para logging o proxies) donde múltiples contenedores coexisten en el mismo Pod. El siguiente manifiesto YAML ilustra un Pod configurado correctamente para un ambiente de producción, incluyendo solicitudes de recursos, límites y health checks: ```yaml # api-pod.yaml apiVersion: v1 kind: Pod metadata: name: api-server labels: app: api version: v2 spec: containers: - name: api image: registry.example.com/api:3.1.0 ports: - containerPort: 8080 resources: requests: cpu: "250m" # 0.25 CPU core reserved memory: "256Mi" # 256 MB reserved limits: cpu: "500m" # hard cap at 0.5 core memory: "512Mi" # OOMKilled beyond this readinessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 10 livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 15 periodSeconds: 20 ``` Los labels son particularmente importantes. Funcionan como metadata clave-valor que permite a otros recursos de Kubernetes identificar y seleccionar Pods específicos. En el ejemplo, `app: api` será utilizado por Services y Deployments para enrutar tráfico y gestionar réplicas. > **Trampa común en entrevistas** > > Cuando el entrevistador pregunta "qué pasa si un Pod falla", muchos candidatos responden que Kubernetes lo reinicia automáticamente. **Esto es incorrecto si el Pod fue creado directamente**. Solo los Pods gestionados por un controller (como Deployment o StatefulSet) se recrean automáticamente. Los Pods creados manualmente con `kubectl apply -f pod.yaml` permanecen en estado Failed hasta ser eliminados manualmente. ## Fases del Ciclo de Vida y Políticas de Reinicio Comprender el ciclo de vida de un Pod es esencial para diagnosticar problemas en producción y responder preguntas de entrevista. Un Pod atraviesa varias fases desde su creación hasta su terminación: | Fase | Descripción | Siguiente acción típica | |------|-------------|-------------------------| | **Pending** | El Pod fue aceptado pero los contenedores no se ejecutan | Verificar scheduling, imágenes, recursos | | **Running** | Al menos un contenedor está ejecutándose | Monitorear health checks | | **Succeeded** | Todos los contenedores terminaron exitosamente | Cleanup automático según config | | **Failed** | Al menos un contenedor terminó con error | Revisar logs, restartPolicy | | **Unknown** | No se puede determinar el estado del Pod | Verificar conectividad del nodo | La política de reinicio (`restartPolicy`) determina cómo Kubernetes maneja contenedores que terminan. Las opciones disponibles son: - **Always** (default): Reinicia el contenedor sin importar el código de salida - **OnFailure**: Reinicia solo si el contenedor termina con código diferente a cero - **Never**: No reinicia el contenedor bajo ninguna circunstancia Para trabajos batch o migraciones de datos, la configuración OnFailure es la más apropiada: ```yaml # batch-job-pod.yaml apiVersion: v1 kind: Pod metadata: name: data-migration spec: restartPolicy: OnFailure # restart only on crash containers: - name: migrate image: registry.example.com/migrate:1.0.0 command: ["python", "migrate.py"] env: - name: DATABASE_URL valueFrom: secretKeyRef: name: db-credentials key: connection-string ``` Este ejemplo también demuestra el uso de Secrets para manejar credenciales sensibles, otro tema frecuente en entrevistas de Kubernetes. ## Deployments: Gestión Declarativa de Aplicaciones Mientras los Pods representan instancias individuales, los Deployments proporcionan la capa de abstracción necesaria para aplicaciones de producción. Un Deployment gestiona un conjunto de Pods idénticos (ReplicaSet) y garantiza que el número deseado de réplicas esté siempre disponible. Las características principales que hacen a los Deployments indispensables incluyen: - **Escalamiento horizontal**: Ajustar el número de réplicas según demanda - **Actualizaciones rolling**: Desplegar nuevas versiones sin downtime - **Rollback automático**: Revertir a versiones anteriores cuando se detectan problemas - **Self-healing**: Recrear Pods fallidos automáticamente El siguiente manifiesto configura un Deployment con estrategia rolling update: ```yaml # api-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: api-server labels: app: api spec: replicas: 3 # run 3 identical Pods revisionHistoryLimit: 5 # keep 5 old ReplicaSets for rollback selector: matchLabels: app: api # must match Pod template labels strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 # at most 1 Pod down during update maxSurge: 1 # at most 1 extra Pod during update template: metadata: labels: app: api version: v2 spec: containers: - name: api image: registry.example.com/api:3.1.0 ports: - containerPort: 8080 resources: requests: cpu: "250m" memory: "256Mi" limits: cpu: "500m" memory: "512Mi" readinessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 10 ``` La configuración `maxUnavailable: 1` y `maxSurge: 1` significa que durante una actualización, Kubernetes mantendrá al menos 2 de 3 Pods disponibles mientras crea temporalmente hasta 4 Pods en total. ### Rollback de Deployments Una de las preguntas favoritas de los entrevistadores es cómo revertir un deployment problemático. Kubernetes mantiene un historial de revisiones que permite volver a estados anteriores: ```bash # Check rollout status kubectl rollout status deployment/api-server # View revision history kubectl rollout history deployment/api-server # Roll back to previous version kubectl rollout undo deployment/api-server # Roll back to specific revision kubectl rollout undo deployment/api-server --to-revision=3 ``` El campo `revisionHistoryLimit: 5` en el manifiesto determina cuántas revisiones anteriores conserva Kubernetes para rollback. ## Services: Abstracción de Red y Descubrimiento Los Pods son efímeros por naturaleza: sus direcciones IP cambian cada vez que se recrean. Los Services resuelven este problema proporcionando una dirección IP virtual estable y un nombre DNS que persiste independientemente del ciclo de vida de los Pods individuales. Un Service utiliza selectores de labels para identificar qué Pods deben recibir tráfico. Esta abstracción permite escalar Pods horizontalmente sin modificar la configuración de los clientes: ```yaml # api-service.yaml apiVersion: v1 kind: Service metadata: name: api-service spec: type: ClusterIP # internal-only by default selector: app: api # routes to Pods with this label ports: - name: http port: 80 # Service port (what clients use) targetPort: 8080 # Pod port (where container listens) protocol: TCP ``` Dentro del cluster, otros Pods pueden acceder a este Service usando el nombre DNS `api-service` o `api-service..svc.cluster.local`. Esta es la forma recomendada de comunicación entre microservicios en Kubernetes. ## Tipos de Service y Casos de Uso Kubernetes ofrece diferentes tipos de Service según los requisitos de exposición: | Tipo | Alcance | Caso de uso | |------|---------|-------------| | **ClusterIP** | Solo interno | Comunicación entre microservicios | | **NodePort** | Nodo externo (puerto 30000-32767) | Desarrollo, testing | | **LoadBalancer** | Balanceador cloud externo | Producción con tráfico público | | **ExternalName** | Alias DNS a servicio externo | Integración con servicios legacy | Para exponer una aplicación a internet en un ambiente cloud, LoadBalancer es la opción estándar: ```yaml # api-loadbalancer.yaml apiVersion: v1 kind: Service metadata: name: api-public annotations: service.beta.kubernetes.io/aws-load-balancer-type: "nlb" # AWS NLB spec: type: LoadBalancer selector: app: api ports: - name: https port: 443 targetPort: 8080 protocol: TCP ``` Las anotaciones específicas del proveedor cloud permiten configurar características avanzadas del balanceador de carga. > **Gateway API: El futuro del ingress** > > Aunque Ingress sigue siendo ampliamente utilizado, la comunidad de Kubernetes está migrando hacia **Gateway API** como el nuevo estándar para gestión de tráfico de entrada. Gateway API ofrece mayor expresividad, soporte nativo para protocolos HTTP/2 y gRPC, y mejor separación de roles entre administradores de infraestructura y desarrolladores de aplicaciones. ## Conexión entre Deployments y Services La verdadera potencia de Kubernetes emerge cuando Deployments y Services trabajan en conjunto. El Service actúa como balanceador de carga interno, distribuyendo automáticamente el tráfico entre todos los Pods que coinciden con su selector. Este patrón permite implementar estrategias de despliegue avanzadas como canary releases. Al crear un segundo Deployment con el mismo label `app: api`, el Service automáticamente incluye los nuevos Pods en la rotación de tráfico: ```yaml # canary-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: api-server-canary spec: replicas: 1 selector: matchLabels: app: api # same label as main Deployment template: metadata: labels: app: api # Service picks this up automatically version: v3-canary spec: containers: - name: api image: registry.example.com/api:3.2.0-rc1 ports: - containerPort: 8080 ``` Con 3 Pods del Deployment principal y 1 Pod canary, aproximadamente el 25% del tráfico llegará a la nueva versión. Esta proporción se ajusta modificando el número de réplicas de cada Deployment. ## Horizontal Pod Autoscaler (HPA) El autoescalamiento es un tema recurrente en entrevistas porque demuestra comprensión de operaciones a escala. El Horizontal Pod Autoscaler ajusta automáticamente el número de réplicas basándose en métricas observadas: ```yaml # api-hpa.yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: api-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: api-server minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 # scale up above 70% CPU - type: Resource resource: name: memory target: type: Utilization averageUtilization: 80 behavior: scaleDown: stabilizationWindowSeconds: 300 # wait 5 min before scaling down ``` El campo `stabilizationWindowSeconds` evita fluctuaciones rápidas (flapping) al requerir que las métricas permanezcan bajas durante 5 minutos antes de reducir réplicas. Para que el HPA funcione correctamente, los Pods deben declarar requests de recursos. Sin requests definidos, Kubernetes no puede calcular el porcentaje de utilización. ## Preguntas Frecuentes en Entrevistas de Kubernetes Las siguientes preguntas aparecen consistentemente en entrevistas técnicas para posiciones DevOps y SRE en empresas latinoamericanas: **¿Cuál es la diferencia entre un Pod y un contenedor?** Un Pod es una abstracción de Kubernetes que puede contener uno o más contenedores. Los contenedores dentro del mismo Pod comparten namespace de red (misma IP), almacenamiento y ciclo de vida. **¿Por qué no se deben crear Pods directamente en producción?** Los Pods creados directamente no tienen controller que los gestione. Si el Pod falla o el nodo donde corre se cae, el Pod no se recrea automáticamente. Los Deployments resuelven esto manteniendo el estado deseado. **¿Qué sucede durante un rolling update?** Kubernetes crea Pods nuevos con la nueva configuración mientras termina gradualmente los Pods antiguos. Los parámetros maxUnavailable y maxSurge controlan la velocidad y capacidad durante la transición. **¿Cómo un Service descubre los Pods disponibles?** El Service utiliza selectores de labels para identificar Pods elegibles. Kubernetes mantiene un objeto Endpoints (o EndpointSlice) que lista las IPs de todos los Pods saludables que coinciden con el selector. **¿Cuál es la diferencia entre readinessProbe y livenessProbe?** ReadinessProbe determina si el Pod puede recibir tráfico (se remueve del Service si falla). LivenessProbe determina si el contenedor está vivo (se reinicia si falla). Un Pod puede estar vivo pero no listo para recibir tráfico. **¿Cómo se implementa un despliegue blue-green en Kubernetes?** Se crean dos Deployments completos (blue y green) y se cambia el selector del Service para apuntar a uno u otro. Esto permite switchover instantáneo y rollback inmediato. Para practicar estas y otras preguntas de Kubernetes, se recomienda utilizar recursos especializados como las [preguntas de entrevista DevOps](/technologies/devops/interview-questions/kubernetes-basics) disponibles en SharpSkill. ## Conclusión Dominar Kubernetes para entrevistas técnicas requiere comprender tanto los conceptos teóricos como su aplicación práctica. Los puntos clave cubiertos en este artículo incluyen: - **Pods** son la unidad mínima de ejecución, pero no deben crearse directamente en producción - **Labels y selectores** son el mecanismo fundamental de conexión entre recursos - **Deployments** gestionan el ciclo de vida de aplicaciones con rolling updates y rollback - **Services** proporcionan descubrimiento y balanceo de carga interno - **HPA** permite autoescalamiento basado en métricas de utilización - Los **health checks** (readiness y liveness) son esenciales para aplicaciones robustas La clave para destacar en entrevistas de Kubernetes no es memorizar comandos, sino comprender cómo estos recursos interactúan para mantener aplicaciones disponibles y escalables. Practicar con manifiestos YAML reales y explicar el razonamiento detrás de cada configuración demuestra la profundidad de conocimiento que los entrevistadores buscan. --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/es/blog/devops/kubernetes-interview-pods-services-deployments-explained