Historias de administradores de Kubernetes en producción

Hay una belleza singular en un clúster de Kubernetes que funciona como un reloj. Las aplicaciones conviven en armonía, las canalizaciones de CI/CD fluyen sin tropiezos y cada pod sabe cuál es su sitio. Pero por cada instante de tranquilidad, siempre acecha una tormenta a punto de estallar. Pregunta a cualquier administrador de Kubernetes y te confirmará que gestionar k8s se parece menos a un trabajo habitual y más a un deporte de supervivencia.

Desde fuera, Kubernetes puede parecer una utopía de automatización y escalabilidad. Sin embargo, entras en la cabina de mando y te topas con un laberinto de YAML, registros de error crípticos y parches improvisados que harían sonrojar a cualquiera. Detrás de todo eso, quienes mantienen los sistemas en pie (administradores, ingenieros y especialistas de SRE) sostienen la estructura con café, cinta adhesiva y una buena dosis de tensión contenida. Esta recopilación va por ellos.

"Fácil" hasta que te toca gestionarlo

Kubernetes resulta complicado porque te permite hacer casi cualquier cosa, aunque sea una buena herramienta. Esa es su bendición y su condena. ¿Quieres ejecutar un clúster de un solo nodo en una Raspberry Pi guardada en un armario? Adelante. ¿Prefieres escalar y orquestar cientos de microservicios en varias nubes? Sin problema. ¿Te piden poner en producción SELinux obligatorio porque el director general se entusiasmó con un término de moda en LinkedIn? Bueno, ahí es donde empiezan los problemas serios.

Un administrador relató un descenso al caos digno de Kafka: la historia arrancó con un clúster de MicroK8s sobre Ubuntu y terminó con Kubernetes upstream en Rocky Linux, todo por culpa de un director general que decidió que "entorno corporativo" significaba complicarlo todo sin motivo. Ese mismo directivo exigió SELinux estricto sin entender cómo funcionaba y asumió que los paquetes Snap operarían por arte de magia en Rocky. Lo que vino después fueron sesiones a las 2 AM depurando registros de denegación para funciones que nadie usaba, un auténtico espectáculo repleto de siglas.

Y aun así, pese a los dolores de cabeza, el clúster resistió. GitLab, la telefonía, el SSO y toda la infraestructura funcionaron sin una sola pausa durante más de un año. Aunque la disponibilidad no siempre te gana el reconocimiento de nadie. A veces basta con que un programador decida saltarse Git y subir código mediante un recurso compartido SMB, usando una carpeta de red como control de versiones, para echarlo todo a perder.

En ese punto, nuestro protagonista pulsó el botón de eyección. El clúster siguió encendido, pero él no se quedó.

Homelabs y exceso de confianza

Podrías pensar que este desorden solo ocurre en grandes corporaciones, pero Kubernetes puede sembrar el caos incluso en un sótano particular. Un usuario lo sintetizó muy bien: "K8s es una bendición incluso para un homelab modesto". Hay mucha verdad en eso. Tanto si despliegas proyectos personales como si montas entornos casi empresariales, Kubernetes te permite recrear infraestructuras reales como nunca antes.

Eso no significa que el camino sea tranquilo. Hasta profesionales experimentados acaban atrapados en bucles de reinicio (CrashLoopBackOff), caídas de controladores personalizados o la desagradable sorpresa de que la última versión de su controlador de ingress no se lleva bien con su operador preferido.

En ocasiones el problema radica en la acumulación de aplicaciones de terceros añadidas encima. Siempre surge un operador reluciente, una herramienta milagrosa de observabilidad o una solución de GitOps prometiendo el paraíso. La mayoría de las veces, estas piezas se solapan, entran en conflicto o fallan directamente, y el problema te toca resolverlo a ti.

Cuando el problema es el proveedor

Otro hilo conductor de estas anécdotas es la complejidad que genera la dependencia de proveedores. La API de Kubernetes puede ser estable, pero los proveedores ciertamente no lo son. Ya hablemos de EKS, AKS o de alguna distribución con capas de abstracción añadidas, dar soporte a estos clústeres híbridos implica lidiar con decisiones que no tomaste y que no puedes corregir.

Un administrador apuntaba que k8s resulta sencillo... hasta que tu proveedor empieza a "aportar valor añadido". De pronto, tu clúster limpio se vuelve una maraña de sidecars propietarios, CRD misteriosos y rutas de actualización que parecen un campo de minas a oscuras. Y cuando algo revienta, buena suerte para encontrar documentación. Estás por tu cuenta, o pagando por el privilegio de preguntar al soporte por qué su controlador de DNS personalizado devora la memoria RAM a puñados.

"Si es una chapuza pero funciona..."

A veces la única salida es seguir adelante. Un administrador que intentaba conectar External Secrets Operator con Vault entre clústeres distintos lo resumió con precisión: "No hay guías ni documentación. Los manuales de Vault son puro folleto de ventas. La documentación de ESO es indescifrable. Y lo de AWS lo dejan como ejercicio para el lector".

Hicieron falta reescrituras en CoreDNS, malabares con OIDC y bastante ensayo y error, pero funcionó. Y en el terreno de Kubernetes, si funciona, no es ninguna tontería. Esa es la regla no escrita.

La mayor parte de las dificultades en Kubernetes no tienen tanto que ver con la plataforma como con el factor humano: las suposiciones precipitadas, los egos y ese eterno "esto debería ser fácil" que degenera en una semana entera de depuración sin tregua.

Lo odiarás, lo amarás y mañana lo seguirás usando

Kubernetes no se va a marchar. Para bien o para mal, representa la columna vertebral de la infraestructura moderna, y las personas que lo operan son quienes consiguen que tus aplicaciones, tus servicios y tus proyectos nativos de la nube no se vengan abajo de repente.

Tampoco conviene idealizarlo en exceso. Como reflejó un comentario muy acertado: "K8s es a la vez un regalo y una pesadilla". Te apoyas en él y al mismo tiempo reniegas de él. Ganas soltura con kubectl pero sigues buscando comandos elementales en Google. Dominas Helm y aun así te sorprendes discutiendo con un archivo de values que se niega a combinar bien los datos.

Y tal vez, tras superar los bucles de reinicio, los certificados caducados, los enigmas de red y a los directivos que creen que por mirar un panel de AWS ya son expertos en DevOps, encuentres un orgullo especial en mantenerlo todo en pie. Si Kubernetes enseña algo, es a ser resiliente cuando a tu alrededor todo parece a punto de colapsar.