Kubernetes para principiantes: pods, deployments y services

Kubernetes es un orquestador de contenedores, es decir, un sistema que se encarga de correr, coordinar y mantener en funcionamiento muchos contenedores repartidos a través de un grupo de máquinas llamado clúster. Mientras que Docker resuelve el problema de empaquetar y ejecutar un contenedor individual, Kubernetes resuelve el problema que aparece cuando hay que ejecutar muchos y a escala: que no se caigan, que se reinicien automáticamente si fallan, que se distribuyan entre las máquinas disponibles, que se muevan a otra máquina si la suya se apaga, que se actualicen a versiones nuevas sin cortar el servicio y que aumenten o reduzcan su cantidad según el tráfico. Funciona de manera declarativa: uno describe el estado que desea que exista y Kubernetes trabaja de forma continua para alcanzarlo y mantenerlo, reparando por su cuenta cualquier desvío. Es una herramienta muy potente, adoptada ampliamente en la industria para operar aplicaciones grandes y críticas.

Son las tres piezas básicas de Kubernetes. El pod es la unidad mínima que Kubernetes ejecuta: envuelve uno o más contenedores muy relacionados que comparten red y almacenamiento, y es efímero, lo que significa que puede morir y ser reemplazado por otro nuevo con una identidad y una dirección distintas en cualquier momento. El deployment es un objeto al que se le indica cuántas copias idénticas del pod deben existir y con qué imagen, y que vigila continuamente el estado real frente al deseado, creando pods nuevos cuando alguno se cae y encargándose además de actualizar la aplicación reemplazando los pods viejos por los nuevos de forma gradual y sin cortes. El service resuelve que, como los pods van y vienen y cambian de dirección, se necesita un punto de entrada estable: ofrece una dirección y un nombre fijos para todo el grupo de pods y reparte el tráfico entre las copias disponibles, actuando como balanceador de carga. Con estas tres piezas se entiende la mayor parte de lo que ocurre en un clúster.

No son competidores sino piezas de niveles distintos que suelen usarse juntas. Docker se ocupa de empaquetar una aplicación con su entorno en una imagen y de correr contenedores individuales; resuelve el «en mi máquina funciona» y es la base sobre la que se apoya todo lo demás. Kubernetes se ocupa de un problema de nivel superior: orquestar muchos contenedores a través de varias máquinas, manteniéndolos vivos, distribuyéndolos, escalándolos y actualizándolos de forma coordinada y automática. Dicho de otro modo, Docker te da un contenedor que corre, y Kubernetes gobierna una flota entera de contenedores en producción. Por eso el orden de aprendizaje natural es primero Docker y después Kubernetes, y por eso adoptar Kubernetes sin entender antes los contenedores lleva a la frustración: casi todo lo que Kubernetes coordina son, en el fondo, contenedores como los que crea Docker.

Significa que uno no le da a Kubernetes una lista de órdenes paso a paso sobre qué hacer, sino que le describe en archivos de configuración el estado final que desea que exista: cuántas copias de la aplicación deben correr, qué imagen deben usar, cómo deben exponerse. A partir de esa descripción, Kubernetes se encarga por su cuenta de llevar el sistema a ese estado y, lo más importante, de mantenerlo así en el tiempo. Si en algún momento el estado real se desvía del deseado —porque un pod se cayó, una máquina murió o algo cambió— Kubernetes detecta la diferencia y actúa para corregirla, sin que nadie tenga que intervenir. Este enfoque declarativo contrasta con el imperativo, en el que uno ejecutaría comandos concretos y tendría que vigilar y reaccionar manualmente ante cada problema. La ventaja es enorme en robustez y en reproducibilidad, y es la base de prácticas avanzadas como GitOps, donde ese estado deseado vive versionado en un repositorio.

No, y creer que sí es uno de los errores más costosos. Kubernetes brilla cuando se corren muchos servicios, se necesita alta disponibilidad real, se escala según la demanda y se cuenta con un equipo capaz de operarlo, porque en ese contexto resuelve problemas genuinamente difíciles y caros. Pero para una aplicación pequeña, un sitio con poco tráfico o un proyecto de una sola persona, suele ser una solución claramente sobredimensionada que introduce una enorme complejidad operativa —muchas piezas, mucha configuración, mucho que puede fallar— a cambio de beneficios que ese proyecto no necesita. En esos casos, un par de contenedores corriendo con Docker en un servidor, o una plataforma gestionada que se ocupe de la infraestructura, resuelven lo mismo con una fracción del esfuerzo. La regla sana es elegir la herramienta más simple que resuelva el problema que realmente se tiene, no la más impresionante ni la que está de moda, porque la complejidad innecesaria también es un costo.

Kubernetes ofrece un tipo de objeto específico para credenciales y datos sensibles, pensado para mantenerlos separados de la configuración común de la aplicación, y en entornos serios se combina con un gestor de secretos externo dedicado y con el cifrado de esos datos en reposo. Lo que nunca hay que hacer es escribir contraseñas, claves o tokens directamente en los archivos de manifiesto que describen los deployments y services, porque esos archivos suelen versionarse en un repositorio y compartirse con el equipo, de modo que cualquier secreto escrito ahí queda expuesto. La regla es la misma que rige en el código fuente, en las imágenes de contenedor y en los pipelines: los secretos viven en un mecanismo aparte diseñado para protegerlos y se inyectan en el momento de la ejecución, no quedan grabados en lo que se versiona o se distribuye. Además, conviene limitar quién puede leer esos secretos dentro del clúster mediante los controles de acceso que Kubernetes provee.