Kubernetes (K8s) es una plataforma de orquestación de contenedores de código abierto que automatiza el despliegue, el escalado y la gestión de aplicaciones en contenedores en un clúster de máquinas. Google la liberó como código abierto en 2014, y la Cloud Native Computing Foundation (CNCF) se encarga de su mantenimiento en la actualidad.
Kubernetes es una plataforma de orquestación de contenedores de código abierto que automatiza el despliegue, el escalado y la gestión de aplicaciones en contenedores. Google liberó el código fuente de Kubernetes en junio de 2014, y la Cloud Native Computing Foundation (CNCF) lo mantiene desde 2015. Kubernetes agrupa los contenedores en Pods, los programa en un clúster de máquinas y reinicia automáticamente las cargas de trabajo que fallan.
Puntos Clave
- Kubernetes programa contenedores en un clúster, reinicia las cargas de trabajo fallidas y escala las aplicaciones automáticamente. Google lo publicó como código abierto en junio de 2014, y la versión 1.0 se lanzó el 21 de julio de 2015, cuando el proyecto fue donado a la recién formada CNCF.
- Un clúster de Kubernetes consta de dos partes: un plano de control (kube-apiserver, etcd, kube-scheduler y gestores de controladores) que toma decisiones, y nodos de trabajo (kubelet, entorno de ejecución de contenedores, kube-proxy) que ejecutan las cargas de trabajo.
- El proyecto publica tres versiones menores al año, cada una con un soporte de aproximadamente 14 meses. Kubernetes v1.36, publicada el 22 de abril de 2026, es la versión actual.
- Los secretos de Kubernetes se codifican en base64, no se cifran, de forma predeterminada. Los clústeres de producción deben habilitar el cifrado en reposo; el proveedor KMS v2 ha sido estable desde la versión 1.29.
- El controlador Ingress NGINX se retiró en marzo de 2026 y ya no recibe actualizaciones de seguridad. La API Gateway es su sucesora recomendada.
Cómo funciona Kubernetes
Kubernetes funciona con un modelo declarativo: se describe el estado deseado en YAML o JSON, y los controladores ajustan continuamente el clúster para alcanzar ese estado. Si se especifica que un despliegue debe ejecutar cinco réplicas de un servicio y una de ellas falla, Kubernetes detecta la incidencia e inicia un reemplazo sin intervención humana.
Imaginemos una empresa que utiliza un sistema ERP con módulos independientes para inventario, recursos humanos y finanzas. A medida que aumenta la demanda, Kubernetes escala los contenedores de cada módulo, equilibra el tráfico entre los servidores y reinicia los servicios que fallan. Además, realiza comprobaciones de actividad (¿sigue funcionando la aplicación?) y de disponibilidad (¿puede aceptar tráfico?) para reiniciar o retirar de la rotación los contenedores con problemas antes de que los usuarios lo noten. Dado que la CNCF mantiene Kubernetes como software de código abierto independiente del proveedor, la misma definición de clúster se ejecuta en las instalaciones de la empresa, en cualquier nube importante o en entornos híbridos.
Kubernetes frente a Docker Swarm
Docker Swarm es el modo de agrupación en clústeres integrado de Docker; es más sencillo de configurar que Kubernetes, pero cubre un conjunto mucho más limitado de necesidades de orquestación.
| Atributo | Enjambre Docker | Kubernetes |
| Configuración | Integrado en Docker; minutos para empezar. | Curva de aprendizaje más pronunciada; los servicios gestionados (EKS, AKS, GKE) reducen la carga. |
| Descamación | Escalado de servicio manual | Escalado horizontal automático con el escalador automático de pods horizontal (HPA). |
| La auto-sanación | Reinicia los contenedores que fallaron | Reinicia, reprograma y reemplaza Pods utilizando sondas de disponibilidad y preparación. |
| Rollouts | Actualizaciones continuas, controles limitados | Actualizaciones continuas más reversión automática en caso de fallos en las comprobaciones de estado. |
| Ecosistema | Cadena de herramientas de Docker | Ecosistema CNCF: Helm, Prometheus, cert-manager, implementaciones de la API de Gateway |
| Ideal para | Equipos pequeños, cargas de trabajo sencillas. | Sistemas de producción a gran escala, microservicios, nube híbrida y multinube. |
Características principales de Kubernetes
Kubernetes agrupa las tareas operativas que antes los equipos programaban manualmente mediante scripts, convirtiéndolas en funciones declarativas integradas.
- Escala horizontalEl escalador automático de pods horizontal agrega o elimina pods según métricas como el uso de CPU y memoria. Las solicitudes y límites de recursos permiten que el planificador agrupe los contenedores en los nodos sin sobrecargar ninguna máquina.
- Autosanación: El kubelet reinicia los contenedores que fallan en las pruebas de estado y retiene el tráfico de los Pods que fallan en las pruebas de disponibilidad.
- Descubrimiento de servicios y equilibrio de carga: Cada servicio obtiene un nombre DNS y una IP virtual estable. ClusterIP expone un servicio dentro del clúster, NodePort abre un puerto en cada nodo y LoadBalancer aprovisiona un balanceador de carga en la nube para el tráfico externo.
- Orquestación de almacenamiento: PersistentVolumes y PersistentVolumeClaims desacoplan el almacenamiento de los Pods, y la Container Storage Interface (CSI) integra sistemas de almacenamiento como AWS EBS, Google Persistent Disk o NFS con aprovisionamiento dinámico a través de StorageClasses.
- Secretos y configuración: Los ConfigMaps almacenan la configuración y los Secrets contienen valores confidenciales, como las claves de API. Los Secrets están codificados en base64, pero no cifrados, de forma predeterminada; habilite el cifrado en reposo y utilice el proveedor KMS v2 (estable desde la versión 1.29) para protegerlos con claves almacenadas en un servicio externo de administración de claves.
- Despliegues y reversiones automatizados: Las implementaciones actualizan los Pods gradualmente mientras supervisan las sondas de estado y revierten a la última versión estable cuando falla una actualización.
- Cargas de trabajo por lotes: Los trabajos ejecutan las tareas hasta su finalización, y los trabajos programados (CronJobs) las ejecutan según un cronograma, como por ejemplo las copias de seguridad nocturnas o las ejecuciones de análisis.
- Redes de doble pila y extensibilidad: Los pods y los servicios pueden tener direcciones IPv4 e IPv6, y las definiciones de recursos personalizados extienden la API de Kubernetes para herramientas como los operadores de Prometheus o cert-manager.
Arquitectura de Kubernetes
Un clúster de Kubernetes divide las responsabilidades entre un plano de control que toma decisiones globales y nodos de trabajo que ejecutan las cargas de trabajo de las aplicaciones.
Componentes del plano de control
- kube-apiserver: La puerta de entrada del clúster. Cada comando kubectl, controlador e interacción con los nodos pasa por el servidor API.
- etcd: Un almacén de clave-valor consistente que contiene todo el estado y la configuración del clúster. Es la fuente de información fidedigna: si un componente del plano de control se reinicia, recupera el estado actual desde etcd.
- kube-scheduler: Asigna los Pods recién creados a los nodos en función de las solicitudes de recursos, las reglas de afinidad y las restricciones.
- kube-controller-manager: Ejecuta los bucles de reconciliación que mantienen el estado actual coincidiendo con el estado deseado, como por ejemplo, reemplazar los Pods cuando falla un nodo.
- administrador-controlador-nube: Integra el clúster con las API de un proveedor de nube para balanceadores de carga, rutas y ciclo de vida de los nodos.
Componentes del nodo de trabajo
- kubelet: El agente en cada nodo que garantiza que los contenedores descritos en las especificaciones del Pod estén en funcionamiento y en buen estado.
- Tiempo de ejecución del contenedor: El software que ejecuta los contenedores a través de la Interfaz de Ejecución de Contenedores (CRI), normalmente containerd o CRI-O. Kubernetes eliminó el dockershim específico de Docker en la versión 1.24 (mayo de 2022); las imágenes creadas con Docker siguen funcionando sin cambios.
- kube-proxy: Mantiene las reglas de red en cada nodo para que el tráfico del servicio llegue a los Pods correctos.
Objetos de Kubernetes
| Objeto | ¿Qué hace? | Caso de uso de ejemplo |
| Vaina | Unidad desplegable más pequeña; uno o más contenedores que comparten red y almacenamiento. | Ejecutando una instancia de un servidor web Nginx |
| Servicio | Punto final de red estable para un conjunto de Pods | Conectar un frontend con una API de backend |
| Despliegue | Gestiona ReplicaSets, actualizaciones progresivas y reversiones. | Lanzamiento de una nueva versión de microservicio sin tiempo de inactividad. |
| conjunto de réplicas | Mantiene en funcionamiento un número específico de Pods idénticos. | Mantener cinco réplicas del servidor web para garantizar la disponibilidad. |
| Mapa de configuración / Secreto | Mantener la configuración y los valores confidenciales. | Cadenas de conexión a la base de datos; credenciales de la API |
| Conjunto con estado | Identidad y almacenamiento estables para aplicaciones con estado | Ejecutar MongoDB o MySQL con volúmenes por instancia. |
| Conjunto de demonios | Ejecuta un Pod en cada nodo. | Implementación de un agente de registro o monitorización en todo el clúster |
| Trabajo / Trabajo programado | Ejecuta las tareas una sola vez o según un cronograma. | Copias de seguridad nocturnas de la base de datos |
Redes: De la API de entrada a la API de puerta de enlace
La forma en que el tráfico externo ingresa a un clúster de Kubernetes cambió sustancialmente en 2026, y cualquier equipo que aún esté estandarizando el controlador Ingress NGINX debe tomar medidas.
La API Ingress enruta el tráfico HTTP y HTTPS externo a los servicios dentro del clúster y puede finalizar TLS. La API en sí sigue formando parte de Kubernetes, pero su funcionalidad está congelada. Su implementación más popular, el controlador Ingress NGINX, fue retirada por el proyecto Kubernetes el 24 de marzo de 2026, tras un anuncio del 12 de noviembre de 2025; el repositorio es de solo lectura y no recibe más correcciones de errores ni parches CVE.
En un comunicado del 29 de enero de 2026, los Comités Directivo y de Respuesta de Seguridad de Kubernetes señalaron que aproximadamente la mitad de los entornos nativos de la nube utilizan Ingress NGINX e instaron a la migración inmediata.
La API Gateway, disponible de forma general desde la versión 1.0 en octubre de 2023, es la sucesora recomendada. Separa las cuestiones de infraestructura (Gateways) del enrutamiento de aplicaciones (HTTPRoutes), admite controles de tráfico más completos y se comporta de forma coherente en implementaciones como Envoy Gateway, Cilium y las pasarelas de los proveedores de la nube.
La herramienta ingress2gateway, que alcanzó la versión 1.0 en marzo de 2026, convierte los recursos Ingress existentes a sus equivalentes en la API Gateway. Los equipos que prefieran seguir utilizando la API Ingress pueden migrar a un controlador de terceros con soporte activo, como Traefik, HAProxy o el controlador comercial F5 NGINX Ingress Controller.
Kubernetes en DevOps y CI/CD
Kubernetes proporciona a los equipos de DevOps un único objetivo de despliegue y un único modelo operativo en todos los entornos, razón por la cual constituye la base de la mayoría de las canalizaciones de CI/CD modernas.
Las canalizaciones creadas con Jenkins, GitLab CI o herramientas similares crean una imagen de contenedor, la suben a un registro y aplican un manifiesto actualizado al clúster; Kubernetes realiza entonces la actualización progresiva y revierte automáticamente si fallan las comprobaciones de estado.
En los flujos de trabajo de GitOps, herramientas como Argo CD y Flux supervisan un repositorio Git y mantienen el clúster sincronizado con él, de modo que cada cambio esté controlado por versiones y sea auditable. Dado que los manifiestos son declarativos, las mismas definiciones se ejecutan de forma idéntica en desarrollo, preproducción y producción. Para comprender mejor la práctica en la que se enmarca esto, consulte qué es DevOps y cómo funciona.
PKI y TLS en Kubernetes
Cada clúster de Kubernetes es una infraestructura de clave pública en funcionamiento: los certificados X.509 autentican y cifran prácticamente todas las conexiones entre componentes, independientemente de que el equipo que gestiona el clúster piense o no en los certificados.
La infraestructura de clave pública (PKI) es el marco de autoridades de certificación (CA), certificados y claves que establece la confianza entre máquinas. En Kubernetes, los certificados de seguridad de la capa de transporte (TLS) protegen el punto final del servidor API, la conexión del kubelet con el plano de control, el tráfico entre pares y clientes de etcd, y cualquier servicio expuesto a través de HTTPS.
Los certificados de cliente también autentican a los usuarios y componentes ante el servidor API. Los clústeres inicializados con kubeadm generan esta infraestructura de clave pública (PKI) automáticamente, y sus certificados de cliente caducan al cabo de un año por defecto, por lo que es necesario controlar o automatizar su renovación antes de que provoque una interrupción del servicio.
Para los certificados de carga de trabajo, cert-manager automatiza la emisión y renovación dentro del clúster y se graduó como proyecto CNCF el 12 de noviembre de 2024, lo que lo sitúa en el mismo nivel de madurez que Kubernetes. Los certificados suelen ingresar al clúster como secretos de Kubernetes a los que hacen referencia los recursos Gateways o Ingress; generar correctamente la solicitud de firma de certificado (CSR) subyacente es el primer paso de esa cadena.
A escala empresarial, los certificados de clúster y de carga de trabajo deberían seguir el mismo proceso de gestión del ciclo de vida que el resto de los activos, especialmente teniendo en cuenta que la validez máxima de los certificados TLS públicos se reducirá a 47 días en marzo de 2029, según el calendario del CA/Browser Forum.
Riesgos de seguridad y mejores prácticas de Kubernetes
La mayoría de las brechas de seguridad en Kubernetes se remontan a un pequeño conjunto de vulnerabilidades recurrentes, cada una con un control bien conocido.
| Supervisión | Por qué importa | Buenas prácticas |
| Control de acceso mal configurado | Un control de acceso basado en roles (RBAC) débil o predeterminado permite que usuarios no autorizados manipulen el clúster. | Implementar el control de acceso basado en roles (RBAC) de mínimo privilegio, auditar el acceso periódicamente y aplicar políticas de red. |
| Imágenes de contenedores vulnerables | Las imágenes obsoletas o no verificadas introducen vulnerabilidades CVE conocidas en la producción. | Extraiga imágenes de registros de confianza y analícelas con herramientas como Trivy. |
| Secretos sin cifrar | Los secretos codificados en Base64 son legibles por cualquier persona con acceso a etcd o API. | Habilite el cifrado en reposo con KMS v2; restrinja el acceso a Secret mediante RBAC. |
| Capa de entrada sin parchear | Los controladores retirados, como Ingress NGINX, no recibirán correcciones de CVE después de marzo de 2026. | Migre a Gateway API o a un controlador mantenido. |
| Cadena de suministro no firmada | Las imágenes y dependencias manipuladas ingresan al clúster sin ser detectadas. | Firma y verifica las imágenes con Sigstore Cosign; aplica las políticas de admisión. |
| Certificados caducados | Los certificados de cliente de kubeadm caducan después de un año y provocan fallos en la autenticación del clúster. | Supervise y automatice la renovación de certificados en todos los clústeres. |
Para un análisis más detallado, consulte las guías de EC sobre las mejores prácticas de seguridad de Kubernetes , la protección de contenedores y las identidades de máquinas en Kubernetes en un modelo de confianza cero.
Cómo ayuda la consultoría de cifrado
CertSecure Manager es la plataforma de gestión del ciclo de vida de certificados de Encryption Consulting. Descubre los certificados que se ejecutan en sus clústeres de Kubernetes y el resto de su infraestructura, automatiza la emisión y renovación mediante integraciones como cert-manager, y alerta sobre la expiración antes de que se produzca una interrupción del servicio. Los servicios PKI de Encryption Consulting diseñan y gestionan la jerarquía de CA que garantiza la confianza en sus clústeres. Cuenta con el respaldo de las prácticas certificadas ISO/IEC 27001:2022 y SOC 2.
Preguntas frecuentes
¿Qué es Kubernetes en términos sencillos?
Kubernetes es un software que ejecuta y administra aplicaciones en contenedores en un grupo de máquinas llamado clúster. Usted declara el estado deseado, como tres copias de un servidor web, y Kubernetes inicia los contenedores, los distribuye entre las máquinas, reemplaza los que fallan y agrega más cuando aumenta el tráfico.
¿Cuál es la diferencia entre Kubernetes y Docker?
Docker crea y ejecuta contenedores individuales en una sola máquina. Kubernetes orquesta múltiples contenedores en varias máquinas, gestionando la planificación, el escalado, la red y la recuperación. Ambos sistemas trabajan conjuntamente: las imágenes de contenedor creadas con Docker se ejecutan dentro de pods de Kubernetes. Desde que Kubernetes v1.24 eliminó dockershim en mayo de 2022, los clústeres ejecutan esas imágenes mediante entornos de ejecución CRI como containerd o CRI-O.
¿Con qué frecuencia se publican nuevas versiones de Kubernetes y cuál es la versión actual?
El proyecto Kubernetes publica tres versiones menores al año, y cada versión recibe aproximadamente 14 meses de soporte mediante parches. El proyecto ofrece soporte para las tres versiones menores más recientes en todo momento. Kubernetes v1.36, publicada el 22 de abril de 2026, es la versión menor actual, y la v1.37 está programada para el 26 de agosto de 2026.
¿Los secretos de Kubernetes están cifrados de forma predeterminada?
No. Los secretos de Kubernetes están codificados en base64, que es una codificación reversible, no un cifrado. Cualquiera con acceso a etcd o permisos de API suficientes puede leerlos. Los clústeres de producción deben habilitar el cifrado en reposo mediante una EncryptionConfiguration, idealmente con el proveedor KMS v2, que se estabilizó en Kubernetes v1.29 y cifra los secretos con claves almacenadas en un servicio externo de gestión de claves.
¿Qué reemplazó a Ingress NGINX en Kubernetes?
El proyecto Kubernetes retiró el controlador Ingress NGINX en marzo de 2026, y el repositorio ya no recibe correcciones de errores ni parches de seguridad. La API de Ingress aún existe, pero su desarrollo de funcionalidades está congelado. La API Gateway es la alternativa recomendada para nuevas implementaciones, y la herramienta ingress2gateway convierte los recursos Ingress existentes durante la migración.
¿Por qué Kubernetes necesita PKI y certificados TLS?
Cada conexión entre los componentes de Kubernetes, incluyendo el servidor API, etcd, kubelets y controladores, se autentica y cifra con certificados X.509 emitidos por las Autoridades de Certificación del clúster. Sin esta infraestructura de clave pública, cualquier proceso podría suplantar la identidad de un componente del clúster. Los certificados emitidos por kubeadm caducan automáticamente al cabo de un año, por lo que su renovación debe controlarse o automatizarse.
Automatice el ciclo de vida de los certificados en sus clústeres.
Los fallos en los certificados pueden provocar la caída silenciosa de los clústeres de Kubernetes. Automatice el ciclo de vida de los certificados con CertSecure Manager o genere su próxima CSR en segundos con el generador de CSR gratuito de EC.