- Kubernetes ha liderado la innovación en orquestación de contenedores durante los últimos 10 años
- Se observan varias limitaciones y necesidades de mejora en la configuración con YAML, la dependencia de etcd y la gestión de paquetes con Helm
- Se discuten como elementos de cambio para Kubernetes 2.0 la adopción de HCL, almacenamiento conectable, un nuevo gestor de paquetes (KubePkg) e IPv6 por defecto, entre otros
- La estructura abierta actual sigue siendo importante, pero los valores predeterminados y una dirección oficial tienen un impacto decisivo en la innovación del ecosistema
- Se confirma la necesidad de que Kubernetes sea más adecuado para un conjunto más amplio de usuarios y organizaciones mediante mejoras disruptivas continuas
Diez años de Kubernetes: éxitos y límites
Inicio y crecimiento
- Entre 2012 y 2013 comenzaron a circular en la comunidad de sysadmins rumores sobre Borg, el sistema interno de contenedores Linux de Google
- En 2014 se hizo público Kubernetes, y al principio incluso su nombre era difícil de pronunciar
- Grandes empresas como Microsoft, RedHat, IBM y Docker se sumaron rápidamente, y Kubernetes empezó a consolidarse como el estándar del ecosistema
- En 2015, con el lanzamiento de la v1.0 y la creación de la CNCF, comenzó de lleno la construcción de un ecosistema abierto
Puntos clave de innovación
Gestión de contenedores a gran escala
- Kubernetes ofrece escalabilidad para el desarrollo y despliegue de software basado en contenedores
- Hace posible el despliegue masivo del mismo entorno, desde entornos simples de desarrollo hasta miles de servidores
- Las organizaciones pudieron encontrar una vía para pasar de una arquitectura monolítica a microservicios distribuidos
Mantenimiento de bajo costo y autorrecuperación
- La gestión de servidores cambió drásticamente de la era "Simpsons" (cada servidor con apodo y operación manual) a la era "UUID" (reemplazo total, automatización y ausencia de estado)
- Los conceptos de vida útil de la máquina y periodo de soporte del sistema operativo casi desaparecieron, y ante fallas se recompone todo automáticamente mediante la "recreación del nodo"
- Muchas habilidades de Linux dejaron de ser un requisito indispensable para convertirse en algo "deseable"
Procesamiento por lotes y gestión de Jobs
- El procesamiento por lotes, que antes dependía de "cajas dedicadas a cron", fue reemplazado por tareas automatizadas basadas en colas y mecanismos de reintento
- El reinicio automático ante fallas y el manejo flexible elevaron mucho la eficiencia operativa y la satisfacción de los desarrolladores
Descubrimiento de servicios y balanceo de carga
- En lugar de direcciones IP codificadas de forma fija, se introdujo un esquema de nombres de servicios basado en DNS interno
- Mediante API, IP fija y nombres de host se simplificó la conexión entre servicios, y también se pudo tratar a los servicios externos como si fueran internos
Kubernetes 2.0: propuestas clave de mejora
De YAML a HCL: reemplazo del lenguaje de configuración
Límites de YAML
- YAML es fácil de leer y parece mejor que JSON o XML, pero tiene problemas serios como errores frecuentes, falta de soporte de tipos y dificultad para depurar
- Ejemplos: el problema noruego (cuando 'NO' se interpreta como false), errores de indentación y confusión entre números y cadenas, entre muchos otros factores de falla
Alternativa: adoptar HCL
- HCL (HashiCorp Configuration Language), el formato estándar de Terraform, ofrece funciones sólidas como tipado fuerte, validación, funciones y bifurcación condicional
- Una parte considerable de los clústeres de Kubernetes ya usa HCL junto con Terraform
- HCL cuenta con capacidades más potentes que YAML, como estabilidad de tipos, reducción de duplicación, configuración dinámica, iteración, lógica condicional, excelente soporte para comentarios, modularidad y validación
- Aunque persiste el problema de licencias open source (MPL 2.0 → compatibilidad con Apache 2.0), su valor para mejorar la calidad es suficiente
Ejemplo: HCL vs YAML
- Gracias a ventajas de HCL como tipos, variables, funciones, condicionales y bucles, se pueden prevenir errores de configuración, mejorar el mantenimiento y asegurar consistencia incluso en entornos complejos
Soporte para opciones que reemplacen etcd
- etcd es potente, pero en clústeres pequeños o entornos de bajos recursos implica un consumo excesivo
- Surge la necesidad de ampliar la flexibilidad del almacenamiento predeterminado mediante soporte oficial para backends conectables, como Kine
- Ejemplo: k8s-dqlite, que ofrece una capa de datos liviana y flexible con SQLite distribuido + Raft
Más allá de Helm: un gestor de paquetes nativo
Límites de Helm
- Helm es un caso en el que una solución provisional terminó convirtiéndose en estándar, y presenta problemas como complejidad de plantillas, dificultad para depurar, conflictos de dependencias/versiones y validación insuficiente
- En el uso real aparecen muchas dificultades: duplicación entre charts, versiones inconsistentes, instalaciones complicadas entre namespaces, ausencia de búsqueda de charts/metadatos, incumplimiento de versionado semántico y manejo inseguro de CRD
Propuesta de un nuevo sistema de paquetes: KubePkg
- Permitiría gestionar de forma integral, como recursos de Kubernetes, paquetes, dependencias, versionado semántico, seguridad, ciclo de vida y metadatos
- Incluiría hooks de ciclo de vida sofisticados, estrategias de estado y de respaldo/recuperación, configuración declarativa, proceso de firma verificable, registros de auditoría y control de políticas organizacionales
- Su objetivo es heredar las ventajas de los gestores de paquetes de Linux para ofrecer una confiabilidad y consistencia sólidas en la gestión real de infraestructura
Requisitos principales
- Estructura de recursos completamente nativa de Kubernetes
- Soporte integrado para aplicaciones con estado
- Fortalecimiento de procesos de firma/verificación/escaneo de seguridad
- Configuración declarativa estructurada + validación por esquema
- Control de todo el ciclo de vida y soporte sencillo para upgrades/hooks
- Resolución de dependencias/versiones al estilo Linux
- Historial de cambios y trazabilidad de auditoría
- Posibilidad de aplicar políticas por organización
- Una UX familiar de gestión de paquetes al estilo Linux
Cambio a IPv6 por defecto
- Actualmente IPv6 y dualstack están soportados, pero el valor predeterminado sigue siendo IPv4
- Esto ofrece ventajas para resolver comunicación entre clústeres, problemas de NAT y escasez de IP, además de una estructura de red más simple e IPSec integrado
- En entornos que requieren gran cantidad de IP (ejemplo: un bloque /20, 40 nodos y 30 pods por nodo), se llega rápidamente al límite de IPv4
- Quedan claros los beneficios prácticos, como simplificar la operación en entornos públicos IPv6, captar usuarios de cloud y reducir la carga de administrar espacios privados
Conclusión: la necesidad del cambio y el poder de los valores predeterminados
- Existe la opinión de que, "al ser una plataforma abierta, la comunidad se encargará", pero los valores predeterminados guían el comportamiento de la industria
- Kubernetes 2.0 necesita convicciones oficiales, un diseño sobresaliente y valores predeterminados sólidos
- Es un momento importante para dar un salto innovador acorde con su posición como estándar de la industria y tendencia dominante en la operación de centros de datos a nivel global
- En áreas tecnológicas diversas, como móvil y web, ya se ha repetido la experiencia de transformar todo el ecosistema mediante cambios audaces
- También Kubernetes ha llegado al punto de pensar en la siguiente etapa a través de un histórico 2.0
2 comentarios
Creo que los ingenieros capaces de configurar y operar Kubernetes vanilla, hecho ensamblando componentes de código abierto, seguirán siendo pocos en el futuro.
Tal como fueron poquísimos los ingenieros que podían operar el ecosistema Hadoop vanilla, en vez de comprar un clúster de Hadoop empaquetado dentro de la plataforma de Cloudera.
Opinión de Hacker News
Diría que el mayor problema de Kubernetes es que no es un sistema que “simplemente funciona”. En la práctica, son pocos los ingenieros capaces de operar servicios en producción sin fricciones, y construir y mantener directamente un clúster de Kubernetes sobre VMs es todavía más difícil. Por eso están surgiendo startups de serverless: porque se ha extendido la percepción de que (1) consume mucho tiempo, (2) tiene muchísimos errores y (3) es muy probable que falle en producción. Creo que Kubernetes 2.0 debería ir en la dirección de permitir que cualquiera pueda self-hostear fácilmente una plataforma de despliegue y usarla con confianza, manteniendo un núcleo de orquestación pequeño pero potente. Estoy desarrollando personalmente un orquestador y plataforma de despliegue llamado Rivet, y lo presento como la plataforma serverless open source Rivet, pero a menudo me pregunto: “¿qué sería Kubernetes 2.0?”. También están aumentando los casos en que la gente adopta Rivet para escenarios más amplios de lo que esperábamos. La mayor fortaleza de Rivet es que permite desarrollar fácilmente capacidades al nivel de un controller de Kubernetes, lo que lo hace útil para muchos escenarios: servidores de juego, despliegues por tenant, orquestación avanzada de workloads, multitenencia, cobro por tenant y diseño de operadores potentes.
Esta perspectiva me genera bastante rechazo. Tal vez porque ya tengo mis años y soy un poco cínico, pero es un patrón que veo seguido. La tecnología X es demasiado pesada, entonces alguien dice “yo solo quiero correr esto sencillo en mi laptop” y crea la tecnología Y. Luego Y también se vuelve popular y, cuando hace falta escalarla fuera de la laptop, se le agregan muchas funciones y también se vuelve pesada. Entonces aparece alguien a decir “ahora Y también es demasiado pesada” y repite exactamente lo mismo. Es como una 'rueda del tiempo': una historia que se repite sin principio ni fin.
La realidad es que k3s (k8s liviano) es realmente muy fácil de mantener. Con autoactualización de k3s y reglas de eviction adecuadas, casi no hace falta tocar nada; si el almacenamiento como Ceph te parece difícil, también puedes usar alternativas “casi sin mantenimiento” como Lemon o Longhorn. Hay miles de charts de Helm, así que incluso bases de datos complejas se pueden desplegar en un minuto. Desplegar servicios también es muy fácil si usas plantillas de Helm comunes. Helm no es perfecto, pero si lo configuras como quieres, puedes incluso aprovechar autocompletado de valores y cosas así. La barrera de entrada es un poco más alta que serverless, pero aprender una semana y ahorrarte una buena suma en producción vale totalmente la pena.
El problema que Kubernetes resuelve es “¿cómo despliego esto?”. Viendo la documentación de Rivet, solo hay contenedor único, Docker Compose y despliegue manual (comandos de Docker). Me cuesta creer que una infraestructura serverless real se pueda desplegar así a escala. Mi primera duda es: “a estas alturas, ¿no se podría correr Rivet sobre Kubernetes (contenedores, kube-virt, etc.)?”. No veo cómo Docker Compose podría ser más robusto o más escalable que Kubernetes. Y si no es así y lo que venden es un servicio en la nube, entonces eso tampoco encaja con la idea de Kubernetes 2.0. Si yo estuviera self-hosteando Rivet, probablemente cambiaría la documentación para poder correrlo en Kubernetes.
Si usas “k8s como servicio”, donde el mantenimiento del clúster se subcontrata al proveedor cloud, me pregunto qué parte se siente tan compleja. El rango de configuración es amplio, pero para llevar un servicio real a producción basta con conocer unas pocas configuraciones. Con algo apenas un poco más complejo que Docker Compose ya puedes desplegar perfectamente en k8s. Aun así, para la mayoría de las apps incluso ese “un poco más” puede ser innecesario. De hecho, Docker Compose respondía a una necesidad muy popular, y es una pena que no haya recibido más atención sostenida.
Mi experiencia en operación de infraestructura es que nunca va a existir algo que “simplemente funcione”. Incluso Heroku tiene problemas al escalar. Si quieres una plataforma de despliegue que cualquiera pueda adoptar con facilidad, es más realista entender Kubernetes como el primitive base de cierto PaaS. Rivet se ve interesante porque es peculiar y toma algunas ideas del ecosistema BEAM. Personalmente, me interesa más la solidez y el enfoque local-first que el despliegue a gran escala.
“Low maintenance”... uso bastante EKS (k8s administrado), y no necesito preocuparme directamente por el estado del clúster (dejando aparte las formas creativas en que yo mismo podría romper los nodos). Kubernetes realmente pretende ser “lo más libre de mantenimiento posible”, pero en la práctica es mantenimiento puro. Es increíble que puedas poner un yaml y desplegar software al mundo de inmediato. Pero el precio es justamente un mantenimiento complejo. Configurar el clúster, inicializar ArgoCD, registrar otros clústeres en un modelo hub-and-spoke... eso es apenas un acto del circo. Súmale instalar operadores útiles del tooling del CNCF Landscape y herramientas auxiliares (no son de primera línea en lo físico, pero sí esenciales), y terminas corriendo al menos unas 30 cosas. Configurar
values.yamltampoco toma una o dos horas; gran parte del tiempo se va en ArgoCD y en plantillas. Secrets Manager -> External Secrets -> ArgoCD ApplicationSet -> otrovalues.yaml... a veces se va muchísimo tiempo solo para pasar un boolean. Además, el ciclo de actualización de clústeres y operadores es rápido, así que el mantenimiento es un problema permanente. Si haces autoscaling con Karpenter, el reemplazo de nodos y el cero downtime se convierte en otro número de circo más (las apps stateful en k8s son el doble de divertidas). Resumen: “Low maintenance” es, en realidad, una expresión irónica.“Low maintenance” al final siempre es un concepto relativo a la alternativa. En mi experiencia, con k8s la carga de mantenimiento para obtener un servicio de la misma calidad era mucho menor en todo: escalado, failover, rollback, disaster recovery, DevOps, levantar clústeres independientes, etc. Puede variar según el caso, pero esa ha sido mi experiencia.
Llevo dos años usando k3s en hetzner y he tenido 100% de uptime. La carga de mantenimiento es tan baja que una vez incluso perdí la llave SSH del nodo master, y volver a aprovisionar todo el clúster me tomó solo 90 minutos, incluyendo actualizar la documentación. Si hubiera sido urgente, lo habría hecho en 15 minutos. Estoy operando un clúster k8s por 20 euros al mes con 3 nodos ARM y 1 master, algo de storage y DNS automático integrado con Cloudflare.
Pero en realidad lo que estás administrando no es Kubernetes en sí, sino sistemas complementarios como CI/CD, gestión de secretos y automatización de operación de bases de datos. Antes eso se habría hecho con cronjobs, ansible, systemd, scripts de bash, etc., en lugar de yaml.
Se siente como si hubieras construido tu propio circo con tus manos. No deberías instalar tantas cosas. Cada cosa que agregas viene con deuda técnica y costo de mantenimiento, incluso si la herramienta es gratis. Si el autoscaling te genera más deuda y mantenimiento que ahorro, mejor simplemente apágalo.
Si hubieras armado y operado individualmente un conjunto de servicios similar, la carga de mantenimiento sería muchísimo mayor. Pero Kubernetes es tan fácil de administrar que puedes dejarlo ardiendo y desentenderte. Eso sí, solo si sabes lo que estás haciendo y no caes en la tentación de instalar “herramientas que se ven cool”.
K8S tampoco obliga a usar yaml. Puede ser la forma idiomática, pero no es obligatorio.
kubectl applysoporta json desde el inicio, y el endpoint también es json y grpc. Puedes generar config desde varios lenguajes, como jsonnet. Segundo, me pregunto por qué dependency y dependency ordering son un problema en charts de Helm. El modismo principal de Kubernetes está en el loop: si no hay una dependencia, la app lo trata como un recoverable error y reintenta hasta que pueda. O si no, crashea y el controller de ReplicaSet la reinicia automáticamente. Si no hay dependencias en el chart, tampoco hay conflictos de dependencias. Si una app realmente depende de otra, lo correcto es incluir también esa app/servicio dependiente dentro del chart de Helm.(Citando una opinión principal) > que el controller de ReplicaSet reinicie la app cuando crashea no es suficiente. Por ejemplo, si keycloak tarda 1 minuto en levantar, el servicio que depende de él crashea de inmediato por no tener keycloak, y entre reintentos puede caer en throttling, así que incluso después de que keycloak ya esté listo, sigue esperando inútilmente otros 5 a 10 minutos. Si la dependencia es clara, sería más apropiado validar el servicio dependiente con un init container antes de pasar al contenedor principal. Me gustaría que Kubernetes tuviera una función explícita para declarar dependencias de arranque. Que crashee, reintente unas veces y luego entre en throttling no es la respuesta. Las dependencias simplemente existen en la realidad.
Creo que los fallos de dependencias deberían ser necesariamente recoverable. Antes tuve una caída por comportamiento fail-closed causado por una dependencia que ni siquiera se usaba de verdad. Casi todas las dependencias entre servidores son soft dependencies. Si una dependencia downstream falla, simplemente devuelves un 500 y que el load balancer evite los servidores unhealthy.
Se dice “se supone que debe ser así”, pero eso encaja bien solo cuando construyes un stack de software in-house. También hay mucho software legado ya hecho que primero solo soportaba Docker y luego fue adaptado para poder correr en Kubernetes. Cuando los desarrolladores crean herramientas según su propia filosofía, igual la gente termina usándolas como quiere y el resultado se vuelve un desastre. Al final hay que darles múltiples funciones y opciones a las personas, y el mercado las usa como quiere.
Criticar todo esto porque “puedes usar json en vez de yaml” no va al punto. No es lo que realmente le importa a nadie. Me parece una objeción inútil.
Estoy fuertemente en contra de la idea de reemplazar yaml por HCL. HCL es difícil de ver y de leer para los desarrolladores. Hay muchas quejas de usabilidad: si soporta imports o no, lo difícil que es debuggear, etc. No entiendo por qué no se puso en el centro algo como un lenguaje de definición de interfaces tipo protobuf, para luego transformar la forma según la preferencia del usuario.
HCL es de lo peor. Nunca me ha faltado nada usando solo yaml en k8s. Si la configuración se vuelve demasiado compleja, probablemente el problema esté más en el diseño de la app que en usar config maps.
En realidad, ya sea HCL, JSON o YAML, todo eso lo puede serializar/deserializar el cliente. O sea, no es un problema de Kubernetes en sí, sino simplemente una capa externa de conversión.
La definición de interfaces de Kubernetes ya está basada en protobuf (dejando fuera los CRD).
Mi principal queja con HCL es la sintaxis del
for loop. Es realmente terrible.Cuando dicen “HCL es difícil para desarrolladores y es difícil de lint y debuggear”, suena más a que no quieren aprender algo nuevo. Me parece una confusión entre aprender HCL y enfrentarse a un dominio complejo.
Estoy desarrollando el proyecto nebulous con un estilo “Kubernetes 2.0” (todavía en fase pre-alpha). La meta es que sea distribuido y ligero a nivel global, que pueda ejecutarse como binario único en una laptop y escalar hasta miles de nodos en la nube, con red Tailnet, storage por BitTorrent, multitenencia, live migration, etc. La mayoría de estos requisitos surgieron de operar ML, sobre todo por la escasez de GPU, y quizá si el ML se vuelve algo completamente cotidiano, esto termine siendo la base por defecto.
La live migration suena interesante. Nosotros ahora usamos una estrategia de precios basada en autoscaling entre múltiples clústeres y clouds, pero live migration ya es un desafío de otro nivel.
Esto no es Kubernetes, sino un sistema aparte especializado en operación de GPU.
“Distribución global” podría ser, de hecho, un non-requirement. Si Tailnet es la red por defecto, yo sería de los primeros en querer quitar esa parte. Que Kubernetes asuma una sola NIC es una herencia frustrante pensada para la nube (por eso da gusto ver varios CNI y proyectos recientes como Multus; referencia: blog de redhat). Me pregunto en qué se diferencia realmente el diseño multi-tenant respecto a k8s. Y si el storage usa BitTorrent, si también compartes imágenes públicas de contenedores, las tarifas de tráfico egress se van a disparar.
Viendo GitHub, aparece
Chart.yaml, e incluso plantillas comoprovider_aws.yaml, que de verdad son un patrón de código que ojalá no hubieran usado.Sigo sintiendo que Kubernetes es realmente muy complejo. Solo se percibe menos así porque ya se masificó. En Kubernetes 2.0 me gustaría que la experiencia de usuario, especialmente para operaciones frecuentes (desplegar apps, exponer servicios, cambiar service accounts o imágenes, etc.), fuera mucho más simple. Pero como ahora todo gira alrededor de los LLM, parece difícil que haya un desarrollo posterior fuerte en esa dirección.
Kubernetes tiene demasiadas capas de abstracción. Los pods son un concepto central genial, pero cuando se suman deployment, rep set, namespace, etc., dan ganas de que fuera tan simple como Docker Swarm. Terraform también tenía una sola capa y era fácil de aprender. Estoy sintiendo en carne propia lo empinada que es la curva de aprendizaje de k8s.
Esto me hace pensar que “la distinción de tipos en los programas de computadora es resultado de la percepción humana”. Los operadores/controllers están demasiado abstraídos, casi como COM/CORBA en el pasado (eso es tanto ventaja como desventaja). Para implementaciones simples, siento que un k8s-lite más limitado sería más adecuado. En cambio, para entornos complejos, muchas veces ni siquiera las abstracciones actuales de k8s alcanzan. Me pregunto si un solo sistema, ya sea Kubernetes 2.0 o lo que sea, realmente podrá encapsular todos los problemas del mundo real de forma que desarrolladores y diseñadores humanos puedan manejarlo.
Quiero un sistema con “sane defaults”, o sea, que sin elegir nada en particular ya venga con valores base suficientemente razonables (red, storage, load balancer, etc.). Ni yaml ni HCL me convencen. Hace falta una mejor forma de configurar, y no es algo que se resuelva solo cambiando de lenguaje. Creo que IPv6 es indispensable. Docker, los contenedores y Kubernetes debieron haber sido IPv6-only por dentro, dejando IPv4 como una excepción en el ingress controller.
Hay un conflicto esencial entre “sane defaults” y “convertir clientes a servicios administrados”. Cuanto más observo k8s, más crece esa filosofía de “batteries not included” en storage, networking, etc., y AWS/GCP y otros terminan vendiendo integraciones caras encima de eso. En la práctica, k8s no parece tanto open source, sino también una herramienta para empujar ventas como relleno de brechas cloud.
(Experiencia personal) Algo en lo que Terraform/HCL sí supera a YAML es que no depende de caracteres invisibles, y por eso resulta más fácil de leer.
Justamente por esos “sane defaults”, k3s me gusta mucho más.
Me parece una wishlist algo modesta para un release 2.0. En mi entorno todos se quejan mucho de la complejidad de k8s en producción. El verdadero punto clave es cómo lograr backward compatibility y simplicidad al mismo tiempo. Normalmente la backward compatibility dispara la complejidad (porque el sistema nuevo termina cargando con funciones viejas y nuevas a la vez).
Siento que ya vivo en un “mundo Kubernetes 2.0” administrando clústeres y apps con Terraform.
tf applyconfiguro de una vez clúster, nodos, integración cloud (S3, etc.) y hasta servicios dentro del clústercloudflareden el clúster + configuración del túnel vía API de Cloudflare)Como alguien que viene del frontend, Kubernetes me pareció bastante intuitivo. Antes recibía datos de entrada para construir una UI reactiva; ahora siento que escribo código para hacer que los recursos y la configuración coincidan con lo que hay en el panel de control.