Kubernetes: Orquestación de Contenedores Grado Producción

Un Pod es la unidad desplegable más pequeña en Kubernetes. Envuelve uno o más contenedores que comparten namespace de red (misma IP, mismo localhost) y volúmenes de almacenamiento. En la práctica, la mayoría de los Pods corren un solo contenedor de aplicación, pero patrones sidecar — como el proxy Envoy de Istio — agregan un segundo contenedor para concerns transversales.

Los Pods son efímeros por diseño. Pueden ser eliminados, reprogramados o reemplazados en cualquier momento. Esto significa que tu aplicación debe ser stateless a nivel de Pod, almacenando datos persistentes en sistemas externos (bases de datos, object storage, PersistentVolumes). Los health checks vía livenessProbe y readinessProbe son críticos: el liveness probe reinicia un contenedor colgado, mientras el readiness probe lo remueve del tráfico del Service hasta que esté saludable.

Los lifecycle hooks del Pod (postStart, preStop) te permiten ejecutar comandos durante la creación y terminación. El hook preStop es especialmente importante para shutdown graceful: le da tiempo a tu aplicación para terminar requests en curso y cerrar conexiones de base de datos antes de que llegue el SIGTERM.

Nunca creas Pods sueltos en producción. En cambio, declaras un Deployment que gestiona un ReplicaSet, que a su vez gestiona los Pods. El controlador del Deployment asegura que el número deseado de réplicas esté siempre corriendo, reemplazando cualquier Pod que crashee o sea desalojado. Cuando actualizas la imagen del contenedor, el Deployment crea un nuevo ReplicaSet y gradualmente mueve el tráfico, dándote updates sin downtime.

Los campos clave del Deployment incluyen replicas (cantidad deseada de Pods), strategy (RollingUpdate o Recreate), revisionHistoryLimit (cuántos ReplicaSets viejos mantener para rollback), y minReadySeconds (demora antes de considerar un Pod nuevo como disponible). En la plataforma, cada microservicio corre como Deployment con al menos 2 réplicas para alta disponibilidad, y el historial de revisiones se mantiene en 5 para rollback rápido.

Los parámetros maxUnavailable y maxSurge controlan la velocidad del rollout. Configurar maxUnavailable: 0 y maxSurge: 1 asegura que no se pierda capacidad durante las actualizaciones — los Pods nuevos arrancan antes de que los viejos terminen. Para servicios sensibles a latencia, esta es la configuración más segura.

Los StatefulSets gestionan workloads stateful que necesitan identidades de red estables y almacenamiento persistente. A diferencia de los Deployments, los StatefulSets garantizan despliegue y escalado ordenado y graceful. Cada Pod recibe un identificador persistente (ej: mysql-0, mysql-1) que sobrevive al rescheduling. Combinado con un Service headless, los Pods obtienen nombres DNS estables. Los StatefulSets también soportan volumeClaimTemplates para provisionar un PersistentVolumeClaim dedicado por réplica. Usa StatefulSets para bases de datos, message brokers y cualquier workload donde la identidad del Pod importa.

Los DaemonSets aseguran que una copia de un Pod corra en cada nodo (o un subconjunto seleccionado). Son el controlador correcto para agentes a nivel de nodo: recolectores de logs (Fluentd/Fluent Bit), exporters de monitoreo (node-exporter), plugins de red (Calico, Cilium) y drivers de almacenamiento. Cuando un nuevo nodo se une al cluster, el DaemonSet automáticamente agenda un Pod en él. En producción, los DaemonSets corren Fluent Bit para reenvío de logs a Cloud Logging y node-exporter para métricas de host en Prometheus.

Un Service provee un endpoint de red estable para un conjunto de Pods. Como las IPs de los Pods cambian en cada reinicio, los Services abstraen la capa de ruteo vía selectores de labels. ClusterIP (por defecto) expone el Service internamente, NodePort mapea un puerto estático en cada nodo, y LoadBalancer provisiona un balanceador de carga en la nube. En GKE, los Services LoadBalancer crean automáticamente un Network Load Balancer de Google Cloud con IP pública.

Para tráfico HTTP/HTTPS, los objetos Ingress definen reglas de ruteo que mapean hostnames y rutas URL a Services backend. Un Ingress controller (NGINX, Traefik o Istio Gateway) observa los recursos Ingress y configura el reverse proxy real. En el cluster de producción, el Gateway de Istio reemplaza al Ingress controller tradicional, proveyendo mTLS, traffic splitting y ruteo avanzado en una sola capa.

Los Headless Services (clusterIP: None) retornan IPs individuales de Pods vía DNS en vez de una sola IP virtual. Esto es esencial para workloads stateful como bases de datos o caches donde los clientes necesitan conectarse a instancias específicas. Combinado con un StatefulSet, los headless Services habilitan identidades DNS estables como mysql-0.mysql.default.svc.cluster.local.

Los Namespaces particionan un cluster en sub-clusters virtuales. Proveen alcance para nombres (dos Deployments pueden compartir el mismo nombre en diferentes namespaces), cuotas de recursos y políticas de red. Un cluster de producción típicamente tiene namespaces para production, staging, monitoring e istio-system. El cluster de producción corre 6 namespaces separando workloads por ambiente y función.

RBAC (Control de Acceso Basado en Roles) restringe quién puede hacer qué en el cluster. Un Role define permisos dentro de un namespace (ej: "puede listar Pods y leer logs"), y un RoleBinding asigna ese Role a un usuario o ServiceAccount. Para permisos a nivel de cluster, usa ClusterRole y ClusterRoleBinding. Nunca le des cluster-admin a los desarrolladores — acota permisos a los recursos y verbos exactos que necesitan.

Los ServiceAccounts son el mecanismo de identidad para Pods. Cada namespace tiene un ServiceAccount default, pero deberías crear ServiceAccounts dedicados para cada workload y asignar roles RBAC mínimos. Esto sigue el principio de menor privilegio y limita el radio de explosión si un Pod es comprometido. En producción, cada microservicio corre bajo su propio ServiceAccount con permisos acotados solo a los Secrets y ConfigMaps que necesita.

Los ConfigMaps almacenan datos de configuración no sensibles como pares clave-valor. Desacoplan la configuración de las imágenes de contenedor, permitiéndote cambiar settings sin rebuild. Los ConfigMaps pueden montarse como archivos o inyectarse como variables de entorno. Para config estructurada (YAML, JSON, archivos .env), monta el ConfigMap entero como directorio de volumen.

Los Secrets almacenan datos sensibles (API keys, credenciales de base de datos, certificados TLS) con codificación base64. Si bien base64 no es encriptación, el etcd de Kubernetes puede configurarse con encryption-at-rest (habilitado por defecto en GKE). Para mayor seguridad, usa secret managers externos como Google Secret Manager o HashiCorp Vault con el External Secrets Operator, que sincroniza secrets externos en objetos Secret de Kubernetes automáticamente.

Los ConfigMaps y Secrets inmutables (configurar immutable: true) previenen cambios accidentales y mejoran el rendimiento del cluster al eliminar la necesidad de que el kubelet vigile actualizaciones. En producción, todos los ConfigMaps de producción son inmutables — los cambios de config requieren crear un nuevo ConfigMap con nombre versionado y actualizar la referencia del Deployment, asegurando un rollout limpio.

El Horizontal Pod Autoscaler (HPA) escala automáticamente la cantidad de réplicas de Pod basado en métricas observadas. La métrica más común es utilización de CPU, pero HPA v2 soporta memoria, métricas custom (desde Prometheus vía la API de métricas custom), y métricas externas (como profundidad de cola de Cloud Pub/Sub). HPA evalúa métricas cada 15 segundos por defecto y ajusta réplicas para mantener la métrica objetivo cerca del umbral especificado.

Configurar la utilización objetivo correcta es crítico. Muy baja (ej: 30% CPU) desperdicia recursos manteniendo demasiadas réplicas. Muy alta (ej: 90%) no deja margen para picos de tráfico. Un objetivo de 60-70% CPU es un punto de partida seguro para la mayoría de servicios HTTP. Para workloads batch, escala por métricas custom como longitud de cola en vez de CPU.

HPA requiere que los resource requests estén configurados en los contenedores — sin requests, no hay línea base para calcular porcentajes de utilización. El campo behavior te permite controlar la velocidad de scale-up y scale-down. En producción, el scale-down es conservador (ventana de estabilización de 300 segundos) para evitar flapping durante fluctuaciones de tráfico, mientras el scale-up es agresivo (0 segundos de estabilización) para manejar picos repentinos.

El Vertical Pod Autoscaler (VPA) complementa al HPA ajustando automáticamente los requests/limits de CPU y memoria en contenedores individuales. VPA observa el uso real de recursos a lo largo del tiempo y recomienda (o aplica) valores correctamente dimensionados. Opera en tres modos: Off (solo recomendación), Initial (configura requests en la creación del Pod), y Auto (desaloja y recrea Pods con requests actualizados). VPA es invaluable para workloads donde las necesidades de recursos son impredecibles o cambian con el tiempo. En GKE, VPA está disponible como add-on del cluster.

No uses HPA y VPA sobre la misma métrica (ej: ambos escalando por CPU). Van a entrar en conflicto. Un patrón común es HPA para escalado horizontal por CPU/métricas custom y VPA en modo recomendación para dimensionar correctamente los requests de memoria. En producción, VPA corre en modo Off en todos los namespaces, alimentando recomendaciones en una revisión semanal de tuning de recursos que previene tanto el sobreaprovisionamiento como los OOM kills.

Los resource requests y limits son los settings de Kubernetes más incomprendidos y de mayor impacto. Los requests definen los recursos mínimos que un contenedor necesita — el scheduler los usa para colocar Pods en nodos con capacidad suficiente. Los limits definen el máximo — el kubelet los aplica con cgroups. Si un contenedor excede su límite de memoria, recibe OOM-kill. Si excede su límite de CPU, se le aplica throttling (no se lo mata).

La brecha entre request y limit importa. Configurarlos iguales (clase QoS Guaranteed) da rendimiento predecible pero desperdicia recursos. Configurar requests más bajos que limits (QoS Burstable) permite overcommit pero arriesga problemas de noisy-neighbor. Nunca omitas requests completamente (QoS BestEffort) — estos Pods son los primeros en ser desalojados bajo presión de memoria.

Para encontrar los valores correctos, observa el uso real con kubectl top pods y métricas de Prometheus por al menos una semana bajo tráfico de producción. Empieza con limits generosos y ajusta iterativamente. Patrón común: request al p50 de uso y limit al p99 + 20% de margen. En producción, cada microservicio tiene requests y limits tuneados basados en datos reales de producción, previniendo OOM kills que antes causaban fallas en cascada.

Los Deployments de Kubernetes usan rolling updates por defecto. Cuando cambias el template del Pod (generalmente el tag de la imagen del contenedor), el controlador del Deployment crea un nuevo ReplicaSet y lo escala incrementalmente mientras reduce el viejo. Los parámetros maxSurge y maxUnavailable controlan el ritmo. Combinado con readiness probes, esto asegura que el tráfico solo llegue a Pods nuevos saludables.

Los rollbacks son instantáneos. Cada update del Deployment crea una nueva revisión almacenada como ReplicaSet. kubectl rollout undo deployment/api-server revierte a la revisión anterior. kubectl rollout undo deployment/api-server --to-revision=3 salta a una versión específica. El revisionHistoryLimit controla cuántos ReplicaSets viejos se retienen — configura al menos 3 en producción por seguridad.

Para servicios críticos, agrega un valor de minReadySeconds (ej: 30 segundos) para frenar los rollouts. Esto te da tiempo para observar tasas de error antes de que el siguiente lote de Pods sea reemplazado. Combina con alertas de Prometheus: si la tasa de error sube durante un rollout, dispara un rollback automático vía CI/CD. En producción, Helm + GitLab CI orquestan deployments estilo canary chequeando tasas de error de Prometheus entre pasos del rollout.

Prometheus es el estándar de facto para monitoreo de Kubernetes. Scrapea métricas del API server de Kubernetes, kubelet, node-exporter, y el endpoint /metrics de tu aplicación. El Helm chart kube-prometheus-stack despliega Prometheus, Grafana, Alertmanager y dashboards preconfigurados en un solo comando. En GKE, Google Cloud Managed Service for Prometheus (GMP) ofrece una alternativa totalmente gestionada.

Métricas esenciales a monitorear: container_cpu_usage_seconds_total y container_memory_working_set_bytes para consumo de recursos, kube_pod_status_phase para salud de Pods, apiserver_request_duration_seconds para latencia del control plane, y métricas custom de aplicación (tasa de requests, tasa de errores, percentiles de latencia — el método RED). Alerta sobre: loops de reinicio de Pods (CrashLoopBackOff), OOM kills, nodo NotReady, umbrales de capacidad de PVC, y expiración de certificados.

Los dashboards de Grafana visualizan datos de Prometheus. Usa los dashboards de la comunidad para overview del cluster (ID 315), métricas de nodo (ID 1860), y uso de recursos por namespace (ID 12740). Construye dashboards custom para las métricas de negocio de tu aplicación. En producción, un solo dashboard de Grafana por microservicio muestra tasa de requests, tasa de errores, latencia p99, CPU/memoria y utilización del pool de conexiones de base de datos — permitiendo a los ingenieros diagnosticar problemas en menos de 60 segundos.

El debugging en Kubernetes sigue un patrón sistemático: chequea estado del Pod, lee eventos, inspecciona logs y entra al contenedor con exec. Empieza con kubectl get pods -n production para ver estado. CrashLoopBackOff significa que el contenedor sigue crasheando — chequea logs. ImagePullBackOff significa que no se puede bajar la imagen — verifica el tag de la imagen y credenciales del registry. Pending significa que ningún nodo tiene suficientes recursos — chequea capacidad del nodo con kubectl describe node.

kubectl describe pod muestra eventos, condiciones y asignación de recursos. Mira la sección Events al final para fallas de scheduling, fallas de probes y OOM kills. kubectl logs pod-name -c container-name --previous muestra logs de la instancia anterior (crasheada) del contenedor. Para Pods multi-contenedor, siempre especifica el nombre del contenedor con -c.

Para debugging en vivo, kubectl exec -it pod-name -- /bin/sh abre un shell dentro del contenedor. Usa kubectl port-forward pod-name 3000:3000 para acceder al puerto de un Pod desde tu máquina local sin Ingress. kubectl debug crea un contenedor de debug efímero con herramientas (curl, dig, strace) conectado a un Pod en ejecución — invaluable para imágenes distroless que no tienen shell.

Las Custom Resource Definitions (CRDs) extienden la API de Kubernetes con tus propios tipos de recursos. Una vez registrada una CRD, puedes crear, leer, actualizar y eliminar instancias de ese recurso custom usando kubectl igual que los recursos built-in. Las CRDs son la base del modelo de extensión de Kubernetes — el VirtualService de Istio, el Certificate de Cert-Manager y el ServiceMonitor del Prometheus Operator son todos CRDs.

Un Operator es un controlador custom que observa CRDs y automatiza la gestión del ciclo de vida de aplicaciones complejas. En vez de correr manualmente backups de base de datos, failovers o upgrades, un Operator codifica ese conocimiento operacional en código. El patrón Operator sigue un loop de reconciliación: observar el estado deseado (el spec del recurso custom), compararlo con el estado real y tomar acción para converger. Operators populares incluyen Prometheus Operator, PostgreSQL Operator (Zalando) y Redis Operator.

En producción, las CRDs de Cert-Manager automatizan el aprovisionamiento de certificados TLS desde Let's Encrypt. El External Secrets Operator sincroniza secrets desde Google Secret Manager hacia Kubernetes. La CRD ServiceMonitor del Prometheus Operator autodescubre targets de scraping para cada microservicio — no se necesita config manual de Prometheus cuando se despliega un nuevo servicio.

Por defecto, todos los Pods en un cluster Kubernetes pueden comunicarse con cualquier otro Pod. Las Network Policies son reglas de firewall a nivel de Pod que controlan tráfico ingress y egress usando selectores de labels, selectores de namespace y bloques IP. Siguen un modelo de whitelist: una vez que una NetworkPolicy selecciona un Pod, solo el tráfico explícitamente permitido lo alcanza. Se requiere un plugin CNI que soporte NetworkPolicy (Calico, Cilium, Weave Net) — GKE usa Dataplane V2 (basado en Cilium) para soporte nativo.

Empieza con una política default-deny por namespace y después agrega reglas específicas de permitir. Este enfoque zero-trust asegura que un Pod comprometido no pueda alcanzar servicios no relacionados. Por ejemplo, el servicio de pagos solo debería aceptar ingress del API gateway y solo tener egress hacia la base de datos y la API de Stripe. Las Network Policies hacen esto aplicable a nivel de infraestructura.

En producción, cada namespace de producción tiene una política default-deny de ingress. El Helm chart de cada microservicio incluye una NetworkPolicy que permite ingress solo desde sus consumidores conocidos y egress solo hacia sus dependencias. Esta segmentación contuvo un incidente de seguridad donde un sidecar de logging comprometido no pudo alcanzar la base de datos de pagos gracias a la política aplicada.

Los contenedores pierden todos los datos cuando se reinician. Para workloads stateful, Kubernetes provee la abstracción PersistentVolume (PV) y PersistentVolumeClaim (PVC). Un PV representa una pieza de almacenamiento en el cluster (un disco en la nube, NFS share o SSD local). Un PVC es una solicitud de almacenamiento por un Pod. Cuando se crea un PVC, Kubernetes lo vincula a un PV disponible que satisfaga el tamaño y modo de acceso solicitados. El aprovisionamiento dinámico vía StorageClasses elimina la necesidad de pre-crear PVs — el proveedor de nube crea el disco on demand.

Los modos de acceso definen cómo se puede montar un volumen: ReadWriteOnce (lectura-escritura en un solo nodo, el más común), ReadOnlyMany (solo lectura en múltiples nodos), y ReadWriteMany (lectura-escritura en múltiples nodos, requiere NFS o un filesystem distribuido como GlusterFS). Las políticas de reclamo controlan qué pasa cuando se elimina un PVC: Retain mantiene los datos para recuperación manual, Delete elimina el almacenamiento subyacente. Siempre usa Retain para bases de datos de producción.

Los StatefulSets usan volumeClaimTemplates para crear automáticamente un PVC por réplica. Esto asegura que cada instancia de base de datos tenga su propio disco dedicado que persiste a través del rescheduling de Pods. En producción, MySQL corre como StatefulSet con StorageClass pd-ssd en GKE, aprovisionando PersistentDisks SSD de 100Gi por réplica. Prometheus usa un PVC de 500Gi para retención de métricas, monitoreado con alertas al 80% de capacidad para prevenir pérdida de datos.

La plataforma corre 26 microservicios en un cluster GKE con service mesh Istio, sirviendo negocios fitness en múltiples países. Este ambiente de producción demuestra cada concepto de esta guía a escala — desde tuning de recursos que eliminó cascadas de OOM hasta configuraciones de HPA que manejan picos de tráfico de 10x durante horas pico del gym.

In-Place Pod Resize (GA en 1.35): Ahora puedes cambiar recursos de CPU y memoria en Pods en ejecución sin reiniciarlos. Las disminuciones de límite de memoria ahora están permitidas, no solo los aumentos. Esta es una capacidad mayor de producción -- antes, cualquier cambio de recursos requería un reinicio del Pod, causando breve downtime. Para workloads stateful y batch jobs de larga duración, in-place resize elimina disrupciones innecesarias. Combinado con VPA en modo Auto, los clusters pueden redimensionar contenedores continuamente sin el ciclo de desalojar y recrear.

Native Sidecar Containers (GA en 1.33): Kubernetes ahora tiene soporte de primera clase para contenedores sidecar vía restartPolicy: Always en init containers. Los sidecars nativos arrancan antes que los contenedores regulares y corren durante todo el ciclo de vida del Pod, resolviendo el problema de larga data del ordenamiento y shutdown de sidecars. Istio, agentes de logging y otros workloads sidecar se benefician de una gestión apropiada del ciclo de vida -- los sidecars ahora terminan después de que el contenedor principal sale, y los Jobs con sidecars se completan correctamente en vez de colgarse indefinidamente.

Dynamic Resource Allocation (DRA) (GA en 1.34): DRA provee una API estandarizada de Kubernetes para solicitar y gestionar GPUs, FPGAs y otro hardware especializado. En vez de depender de device plugins con inteligencia de scheduling limitada, DRA habilita asignación granular de recursos con parámetros específicos del vendor. Esto es crítico para workloads AI/ML: los equipos reportan 20-35% de reducción de costos de GPU a través de mejor scheduling y sharing. DRA soporta parámetros estructurados para matching preciso de recursos y gestión de claims entre reinicios de Pod.

Pod-Level Resources (Beta en 1.35): Un nuevo campo spec.resources a nivel de Pod te permite establecer límites agregados de CPU y memoria para todos los contenedores en un Pod. En vez de especificar recursos por contenedor y esperar que la suma funcione, defines un presupuesto a nivel de Pod. El kubelet aplica el límite agregado vía un cgroup compartido. Esto simplifica la gestión de recursos para Pods multi-contenedor y sidecars, asegurando que el consumo total del Pod se mantenga dentro de los límites sin importar qué contenedor esté activo.

Kubernetes v1.36 "Haru" (lanzado 22 de abril de 2026) incluye 70 mejoras rastreadas: 18 graduando a stable, 25 a beta y 25 nuevas alpha features. Las promociones GA destacadas incluyen User Namespaces en Pods para contenedores verdaderamente rootless, OCI VolumeSource para ejecutar imágenes OCI como volúmenes, MutatingAdmissionPolicy para control de admisión sin webhooks, SELinux volume mounting (reemplazando re-etiquetado recursivo con etiquetas en tiempo de montaje) y autorización granular de API de kubelet para seguridad a nivel de nodo. HPAScaleToZero ahora está habilitado por defecto, permitiendo al Horizontal Pod Autoscaler escalar Deployments a cero réplicas cuando no hay demanda -- una feature introducida en v1.16 (2019). Las nuevas alpha features apuntan a workloads AI/ML con preemption consciente de workload para jobs de entrenamiento y streams de API fragmentados para clusters a gran escala. El plugin de volumen gitRepo y el modo IPVS en kube-proxy se eliminan en este release.

Ingress NGINX oficialmente retirado: Kubernetes SIG Network y el Comité de Respuesta de Seguridad retiraron el Ingress NGINX Controller en marzo de 2026. No habrá más releases, bugfixes ni parches de seguridad. Dado que aproximadamente el 50% de los entornos cloud-native dependían de Ingress NGINX, todos los equipos deben migrar a Gateway API u otro ingress controller soportado (Envoy Gateway, Istio, Traefik, Contour) inmediatamente. Gateway API es el estándar recomendado en adelante, soportado por todos los controllers principales.

CRI List Streaming (Alpha en 1.36): En nodos a gran escala ejecutando cientos de contenedores, las requests List monolíticas tradicionales del kubelet al runtime de contenedores causaban presión de memoria y picos de latencia. CRI list streaming reemplaza estas con RPC de streaming server-side, reduciendo significativamente la asignación de memoria durante operaciones de listado de contenedores. Esto es crítico para nodos AI/ML con muchos contenedores sidecar e init containers.