Si estás iniciando tu trayectoria y te preguntas qué es Kubernetes, este artículo es para ti. Aquí encontrarás una base para comenzar, analizando las tareas que resuelve, sus objetos principales y cómo gestionar un clúster sin recurrir a comandos complejos en la terminal.
Es un hecho conocido que Kubernetes tiene una presencia omnipresente en la industria. Su conocimiento y manejo son requisitos para desarrolladores, testers, ingenieros DevOps y analistas de sistemas. Incluso los gerentes de producto muestran interés en su funcionamiento.
Cómo funcionaba todo antes de Kubernetes
¿Cuál es la necesidad real de Kubernetes? Analicemos el contexto. Una aplicación se estructura comúnmente de la siguiente manera: un frontend (interfaz de usuario) y un backend.
El backend incluye servicios como el principal, de autorización, de notificaciones y de pagos. Sin embargo, existe una variable crítica: la carga no es uniforme. La autenticación de usuarios es infrecuente, los pedidos son más habituales y las notificaciones se generan con mayor frecuencia. Para gestionar esta alta demanda, cada servicio se despliega en múltiples instancias.
Si los servicios se alojan en un único servidor, se elimina la tolerancia a fallos. La caída de un servidor resulta en la caída de toda la aplicación. Es imperativo distribuir los servicios en diferentes servidores. Por ejemplo, alquilar tres máquinas virtuales o tres servidores físicos para distribuir los servicios. De este modo, la caída de un servidor no compromete la operatividad del sistema.
La siguiente tarea es la distribución de la carga. Para ello, se utiliza un balanceador. Pero, ¿cómo determina a dónde redirigir el tráfico?
Es necesario especificar manualmente todas las direcciones IP y puertos de los servidores donde se encuentran las aplicaciones. Con el tiempo, la carga aumenta y el servicio crece, atrayendo a más usuarios. Se requiere añadir otra instancia del servicio principal, lo que implica actualizar nuevamente toda la configuración de forma manual, un proceso ineficiente.
En un escenario donde todos los servicios del tercer servidor fallan, el balanceador de carga continúa enviando peticiones hacia él, ya que no detecta la anomalía. Los servicios no se reiniciarán automáticamente, requiriendo intervención manual. Esto afecta tanto al sistema como a los usuarios, quienes experimentan latencia elevada o, en el peor de los casos, una interrupción completa del servicio durante un tiempo prolongado.
La situación con las actualizaciones de la aplicación es aún más compleja. Es posible detener los cinco servicios simultáneamente y luego reiniciarlos, pero esto generaría un tiempo de inactividad (downtime) para los usuarios. Por lo tanto, los servicios deben desactivarse secuencialmente. Se apaga el primer servicio y se activa su nueva versión. Si el resultado es satisfactorio, la versión se despliega en los demás servidores, nuevamente de forma manual y poco práctica.
Luego, en una nueva actualización se detecta una fuga de memoria (memory leak). Es necesario revertir a la versión anterior. Y, por supuesto, habría que detener secuencialmente cada servicio y reiniciarlo con la versión antigua.
Esto era solo una pequeña parte del sistema. En empresas pequeñas, la arquitectura se ve así:
Y en grandes corporaciones, se asemeja a esto:
Para gestionar toda esta complejidad, surgió Kubernetes.
Qué es Kubernetes: La Solución a la Complejidad
Kubernetes es un sistema de orquestación de código abierto que automatiza el despliegue, escalado y gestión de aplicaciones en contenedores. Su función principal es simplificar la operación de sistemas complejos, distribuyendo la carga de trabajo entre múltiples servidores (nodos) y garantizando que las aplicaciones se mantengan siempre en ejecución y disponibles.
Para entender mejor qué es Kubernetes y para qué sirve, podemos verlo como un sistema que facilita el lanzamiento, escalado y mantenimiento de aplicaciones, simplificando su operación y distribuyendo la carga entre los servicios.
Resuelve las siguientes tareas:
- Despliegue (Deployment): Levanta nuevas instancias de la aplicación.
- Autorreparación (Self-healing): Monitoriza la aplicación y la reinicia automáticamente en caso de fallo.
- Gestión (Management): Controla el ciclo de vida de la aplicación.
- Escalado (Scaling): Añade o reduce el número de instancias de la aplicación según la carga.
- Balanceo de tráfico (Load Balancing): Distribuye la carga entre las instancias de la aplicación.
Sin embargo, Kubernetes no almacena datos ni imágenes de aplicaciones, ni tampoco construye imágenes de Docker.
Estructura de Kubernetes
Analicemos su arquitectura a alto nivel. Un nodo (node) es un servidor o una máquina virtual. Se puede concebir como un ordenador en un centro de datos. Existe el nodo maestro (master node), que es el centro de control o el cerebro de Kubernetes, gestionando todos los demás componentes. Y también están los nodos trabajadores (worker nodes), que son los servidores o máquinas virtuales donde se ejecutan las aplicaciones: API, frontend, bases de datos, etc.
Para garantizar la alta disponibilidad, Kubernetes utiliza tres nodos maestros.
¿Qué componentes contienen?
El primero y más simple es etcd. Es una base de datos clave-valor que almacena la configuración y el estado actual del clúster de Kubernetes. Por ejemplo, contiene información sobre las aplicaciones desplegadas, sus configuraciones y recursos. El scheduler determina en qué nodo trabajador se desplegará una aplicación.
A continuación, el servidor API (API-server). Todos los componentes, desde el desarrollador hasta los nodos, interactúan con él. Nadie accede ni gestiona directamente la base de datos etcd. La API es el único punto de entrada a Kubernetes.
Finalmente, el gestor de controladores (Controller manager), un programa que se asegura de que todas las solicitudes se ejecuten correctamente.
La gestión y operación de Kubernetes se realiza a través de kubectl. Es una interfaz de línea de comandos (CLI) con la que obtenemos información de Kubernetes.
Qué es Minikube
Minikube permite crear un clúster de Kubernetes en una máquina local. Requiere únicamente un ordenador, como un portátil. En este caso, yo utilizo macOS.
Se instala con dos comandos y se inicia con minikube start. Por ejemplo, desde la línea de comandos podemos ejecutar kubectl get nodes. Dado que K8s está desplegado en una sola máquina, los nodos trabajador y maestro están unificados.
No todos los operadores se sienten cómodos trabajando con Kubernetes a través de la línea de comandos. Para ello, se desarrolló una herramienta de visualización: el Dashboard de Kubernetes. Al seleccionar todos los namespaces, se puede visualizar la composición del clúster, incluyendo Deployments, Pods y ReplicaSets.
Adicionalmente, permite monitorizar el uso de CPU, el número de núcleos y la memoria utilizada, e incluso consultar registros (logs).
Deployment
Comencemos con la unidad más pequeña que se puede concebir. El Pod es el concepto mínimo en Kubernetes. K8s no opera con el término “contenedor”; más comúnmente se habla de Pods. Y generalmente, en un Pod hay un solo contenedor de Docker (la aplicación), aunque su diseño permite alojar múltiples contenedores que necesitan operar de forma conjunta y compartir recursos.
Un Deployment es un manifiesto, típicamente un archivo YAML, donde describimos el estado deseado. El Deployment no crea Pods directamente; primero crea un ReplicaSet. Este último es el encargado de levantar los Pods y de monitorizar que se mantengan en ejecución.
¿Cómo se gestiona el tráfico en Kubernetes? ¿Cómo se comunica un Pod con otro? Y, fundamentalmente, ¿cómo puede un usuario externo enviar una solicitud que atraviese todas las capas de Kubernetes hasta llegar a nuestra aplicación?
Frecuentemente, se instala un Ingress Controller. Un Ingress contiene las reglas para distribuir el tráfico entrante desde internet. A menudo se utiliza Nginx para esta función. Una vez que la solicitud es aceptada, se envía a un Service. El Service, a su vez, determina a qué Pod debe dirigir la solicitud. Podrías preguntarte: “¿Para qué se necesita un Service? ¿Por qué no enviar el tráfico directamente al Pod y evitar una entidad adicional?”.
La razón es que los Pods, que contienen nuestra aplicación, son efímeros. Se despliegan en diferentes nodos, sus direcciones IP cambian y su ubicación puede variar.
Dentro de un clúster de Kubernetes puede haber 15 Pods: cinco en cada servidor. Para determinar a dónde enviar una solicitud, se necesita el Service.
En cada servidor (nodo) se ejecuta un programa llamado kube-proxy. Este proceso recibe la solicitud del Ingress (por ejemplo, Nginx) y se encarga de balancear la carga, decidiendo a qué Pod específico debe enviarla.
Otro aspecto importante es que en cada nodo existe otro proceso: kubelet. Este es responsable de asegurar que se esté ejecutando el número exacto de Pods solicitado (el número de réplicas de la aplicación).
Kubelet se encarga de verificar periódicamente si un Pod está activo. Los ingenieros DevOps o desarrolladores pueden configurar la frecuencia y las condiciones de estas comprobaciones de estado (health checks).
¿Qué sucede con las bases de datos (PostgreSQL, Redis, Kafka) que requieren un estado persistente? No pueden simplemente desplegarse en otro nodo. Cada instancia de la aplicación tiene su propio almacenamiento y un Pod específico debe estar vinculado a él. Para estos casos, en lugar de un Deployment, se utiliza una entidad llamada StatefulSet.
Esta permite asignar a cada instancia de la aplicación direcciones IP estables, identificadores únicos, replicar la carga y añadir comprobaciones de estado. En la práctica, los StatefulSets rara vez se utilizan en su forma cruda. Generalmente, se emplean imágenes preconfiguradas que los gestionan.
Ahora, pasemos a la parte más interesante: trabajar con Kubernetes y lanzar nuestra propia aplicación. Si deseas observar el proceso completo de configuración y despliegue en acción, te recomendamos ver un ejemplo real en el video.
Kubernetes: ¿Vale la pena la inversión?
Kubernetes es una de las herramientas más demandadas en la industria de TI, y su popularidad continúa en aumento. Según datos recientes de la industria, en 2024, el +60% de las empresas ya utilizaban o estaban probando Kubernetes. Además, las proyecciones indican que esta cifra superará el 90 % en 2027.
A nivel global, Kubernetes también ocupa una posición de liderazgo: diversos estudios indican que la mayoría de los profesionales del sector lo utiliza para la orquestación. ¿Cuál es la razón? Kubernetes resuelve tareas complejas de automatización del despliegue, escalado y gestión de aplicaciones.
A pesar del amplio espectro de aplicaciones de Kubernetes, el mantenimiento autónomo de un clúster a menudo resulta ser una tarea compleja. Frecuentemente, los equipos carecen de los recursos o las competencias necesarias, y mantener un equipo completo de especialistas en DevOps puede ser económicamente inviable.
En tales casos, es recomendable delegar parte de las funciones a un proveedor de Managed Kubernetes. Este enfoque simplifica la operación con los clústeres, incluyendo su despliegue, escalado y el mantenimiento general de la infraestructura. El servicio garantiza un funcionamiento estable mediante la tolerancia a fallos y el autoescalado. Permite crear un clúster de cualquier configuración en pocos clics.
La disponibilidad de los clústeres en Managed Kubernetes se define y se fija en un Acuerdo de Nivel de Servicio (SLA), por lo que, al utilizar el servicio, la empresa puede mitigar parte de los riesgos y delegarlos al proveedor. Esto permite al equipo centrarse en el desarrollo del producto en lugar de en la configuración de la infraestructura.
El conocimiento de Kubernetes es fundamental para la creación de infraestructuras de TI modernas, flexibles y estables, que sustentan el negocio en condiciones de rápido crecimiento y cambio. Esto se traduce en una preparación para los nuevos desafíos digitales.
