Qué es Kubernetes y cómo funciona en producción
Kubernetes existe desde 2014. La mayoría de los equipos ya saben que es “ el orquestador de contenedores de Google ”. Lo que pocos tienen claro es qué implica operarlo de verdad, por qué tantos proyectos fracasan en la fase de adopción y cuándo tiene sentido usarlo frente a alternativas más simples.
Aquí vamos al grano: arquitectura real, decisiones que importan en producción y los errores más comunes.
RECURSOS
Qué es Kubernetes, sin rodeos
Kubernetes es un sistema para orquestar cargas de trabajo en contenedores sobre un clúster de máquinas. Su función principal es tomar decisiones de scheduling (qué ejecutar, dónde y cuándo) y mantener el estado deseado de la plataforma de forma continua.
No es un PaaS. No gestiona tu código. No elimina la complejidad operativa, la traslada a una capa que necesita ser gestionada.
Si ya tienes claro que Kubernetes es la base de tu arquitectura, puedes ver cómo lo implementamos en nuestros servicios de Kubernetes gestionado.
Esquema de un servicio de Kubernetes gestionado.
Arquitectura real: lo que hay detrás
Un clúster Kubernetes tiene dos capas diferenciadas:
Es el cerebro. Gestiona el estado del clúster, expone la API y toma decisiones operativas:
- API Server: punto de entrada único para todas las operaciones. Valida y persiste los recursos en etcd.
- etcd: base de datos distribuida clave-valor que almacena el estado del clúster. Si etcd falla, el clúster pierde coherencia.
- Scheduler: asigna pods a nodos en función de recursos disponibles, afinidades y restricciones definidas.
Controller Manager: bucle de control continuo que reconcilia el estado actual con el estado deseado. Si un pod muere, el controller lo detecta y crea uno nuevo.
Ejecutan las cargas de trabajo. Cada nodo incluye:
- kubelet: agente que recibe instrucciones del control plane y gestiona los pods localmente.
- kube-proxy: gestiona las reglas de red para exponer servicios.
- Container runtime : típicamente container o CRI-O, quien ejecuta realmente los contenedores.
Los recursos que necesitas dominar en producción
La unidad mínima de ejecución. Un pod puede contener uno o varios contenedores que comparten red y almacenamiento local. En producción rara vez se despliegan pods directamente, se usan abstracciones de nivel superior.
Describen el estado deseado de una aplicación: imagen, número de réplicas y estrategia de actualización. Permiten rollouts progresivos y rollbacks controlados sin interrupción de servicio.
Abstracción estable sobre un conjunto de pods. Dado que los pods son efímeros y cambian de IP, un Service proporciona un endpoint fijo y distribuye el tráfico mediante kube-proxy.
Gestiona la exposición HTTP/HTTPS al exterior: terminación TLS, routing por host/path y anotaciones específicas del controlador. Requiere un Ingress Controller desplegado en el clúster (nginx, Traefik, Envoy…).
Los namespaces son separación lógica dentro del clúster. El RBAC define qué puede hacer cada usuario o servicio sobre qué recursos. En producción, el principio de mínimo privilegio no es opcional.
Separan la configuración del código. Los Secrets se almacenan codificados en base64 en etcd, no cifrados por defecto, lo que implica que etcd debe estar protegido o integrarse con sistemas como Vault o AWS Secrets Manager.
¿Tiene alguna duda de los conceptos anteriores?
Cuándo usar Kubernetes
Tienes múltiples servicios con ciclos de vida independientes y equipos que necesitan desplegar de forma autónoma.
El tiempo de despliegue importa: CI/CD con rollouts automatizados y rollbacks en segundos.
Necesitas escalar de forma predecible: tanto a nivel de aplicación (HPA) como de infraestructura (Cluster Autoscaler).
La consistencia operativa es prioritaria: mismos patrones de observabilidad, seguridad y exposición para todos los servicios.
Operas en múltiples entornos: staging, producción, regiones distintas con configuración reproducible.
Cuándo NO usar Kubernetes
Aquí está el error más común: adoptar Kubernetes porque “escala” cuando el problema real no es la escala.
No lo uses si:
Tu aplicación es un monolito que se despliega una vez al mes. El overhead operativo no se justifica.
Tu equipo no tiene experiencia operando la plataforma y no tienes soporte externo. Un clúster mal configurado es más frágil que un servidor bien configurado.
Tu prioridad es salir al mercado rápido con un MVP. El time-to-market se resiente cuando hay que montar la plataforma desde cero.
Tienes una aplicación simple, stateful y de bajo tráfico. Una VPS profesional bien dimensionada es más barata y más simple de operar.
La complejidad de Kubernetes tiene un coste. Ese coste solo se amortiza cuando el problema que resuelve es real.
Relación con otras tecnologías
Kubernetes orquesta contenedores, pero no los construye. El runtime subyacente (containerd, CRI-O) es quien los ejecuta. Docker como runtime fue deprecado en Kubernetes 1.20.
Gestor de paquetes para Kubernetes. Permite parametrizar y versionar manifiestos complejos. Es el estándar de facto para distribuir aplicaciones en Kubernetes.
Para provisionar el clúster y la infraestructura cloud subyacente. Kubernetes gestiona lo que hay dentro del clúster; Terraform gestiona el clúster en sí.
Añaden una capa de gestión de tráfico, observabilidad y seguridad entre servicios mediante proxies sidecar. Útil en entornos con muchos microservicios y requisitos avanzados de seguridad o tráfico.
El estado del clúster se define en Git y se sincroniza de forma continua. Es el patrón recomendado para gestionar Kubernetes en producción a escala de equipo.
Operar Kubernetes en producción: donde realmente está el problema
Montar un clúster Kubernetes no es el problema. El problema real es operarlo: mantenerlo actualizado, monitorizarlo, gestionar incidencias y asegurar que la plataforma sigue funcionando bajo carga.
Es en esta capa donde la mayoría de equipos encuentran las dificultades reales: complejidad operativa, falta de visibilidad y dependencia de configuraciones difíciles de mantener en el tiempo.
Si tu equipo necesita centrarse en la aplicación y no en la operación de la plataforma, puedes apoyarte en un servicio de Kubernetes gestionado.
Infraestructura distribuida en CPDs españoles
Para que Kubernetes funcione correctamente en producción, la infraestructura subyacente es crítica. En CCIT operamos clústeres sobre infraestructura basada en colocation en Madrid, distribuida en dos centros de procesamiento de datos españoles de referencia: ESPANIX e IPCORE.
Esta distribución no es solo geográfica: los nodos workers y los nodos etcd están repartidos entre ambos CPDs. Esto permite mantener el quórum del clúster incluso ante la caída de uno de los centros, garantizando continuidad operativa sin intervención manual.
El almacenamiento persistente también está distribuido en red entre ambos CPDs. Actualmente operamos con Longhorn como solución de almacenamiento distribuido nativo para Kubernetes, y estamos en la fase final de implantación de Ceph, lo que permitirá mayor rendimiento, escalabilidad y opciones de almacenamiento.
El resultado es una plataforma con resiliencia real ante fallos de infraestructura, no solo ante fallos de pod.
Además de nuestra presencia directa en estos CPDs, trabajamos con distintos proveedores de infraestructura y conectividad que puedes consultar en nuestra página de partners.
Por qué elegir CCIT para Kubernetes en producción
Montar un clúster Kubernetes no es el problema. El problema real es operarlo: mantenerlo actualizado, monitorizarlo, gestionar incidencias a las dos de la madrugada y asegurarte de que el equipo de desarrollo no tiene que pensar en nada de eso.
Con KPaaS de CCIT, el clúster es nuestro problema.
Tu equipo solo despliega y opera sus servicios.
- Prometheus + Grafana con dashboards configurados
- Sistema de alertas en tiempo real
- ELK Stack para agregación y análisis de logs
- Cilium como CNI
- Gateway API
-
IPs públicas bajo demanda
- Rancher como interfaz visual
- Gestión multiusuario vía kubectl con RBAC
Equipo técnico accesible en todo momento, con conocimiento real de la plataforma
| FAQ |
No. Kubernetes no sustituye a Docker ni a otras herramientas de contenedores. Kubernetes se encarga de orquestar contenedores en múltiples nodos, pero necesita un runtime (como containerd o CRI-O) para ejecutarlos.
En producción, Kubernetes y los contenedores forman parte del mismo stack, pero cumplen funciones diferentes.
No. Kubernetes solo tiene sentido cuando la complejidad de la aplicación lo justifica.
Para aplicaciones simples, monolitos o proyectos con poco tráfico, una VPS profesional bien configurada suele ser más eficiente, más barata y más fácil de operar.
Depende de la carga y los requisitos de disponibilidad, pero en producción nunca debería existir un único punto de fallo.
Como base:
- mínimo 3 nodos en el control plane para mantener quórum
- múltiples worker nodes para distribuir carga
La arquitectura debe diseñarse en función de la criticidad del servicio.
El coste de Kubernetes no es solo infraestructura.
Incluye:
- recursos (CPU, RAM, almacenamiento)
- operación (monitorización, mantenimiento, soporte)
- equipo técnico especializado
En muchos casos, el coste operativo es superior al de la infraestructura.
No por defecto.
Kubernetes permite construir sistemas altamente disponibles, pero la alta disponibilidad depende de:
- arquitectura del clúster
- diseño de la aplicación
- configuración de red y almacenamiento
Un clúster mal diseñado puede ser menos resiliente que una infraestructura más simple bien planteada.
Sí. La complejidad no está en desplegar Kubernetes, sino en operarlo.
Los principales retos son:
- observabilidad
- gestión de incidencias
- actualizaciones
- seguridad
Por eso muchas empresas optan por un enfoque de Kubernetes gestionado.
Kubernetes es mejor opción cuando:
- hay múltiples servicios o microservicios
- se necesita escalado dinámico
- hay despliegues frecuentes
Un VPS es más adecuado cuando:
- la aplicación es simple
- el tráfico es estable
- se busca simplicidad operativa
Sí. Es habitual trabajar con arquitecturas híbridas:
- Kubernetes para servicios distribuidos
- VPS para cargas simples
- colocation para control de infraestructura
Elegir la combinación adecuada depende del caso de uso.
¿Kubernetes encaja con tu proyecto ?
El siguiente paso es implementarlo correctamente desde el inicio. Descubre cómo abordamos
