La guía del hater sobre Kubernetes

Artículo original ↗ Discusión en Hacker News ↗

Kubernetes polariza a los ingenieros como un estándar potente para desplegar y escalar contenedores que también introduce una complejidad considerable, especialmente para equipos que no necesitan de verdad todo su conjunto de funciones. Los comentaristas sopesan sus ventajas —APIs agnósticas a la nube, herramientas ricas, autoscaling y una “única interfaz” entre entornos— frente a la fragilidad operativa, las curvas de aprendizaje pronunciadas, el dolor de la templating con YAML/Helm y la tendencia cultural a sobrediseñar. Muchos sostienen que opciones más simples (VMs, ECS, Docker Compose, Nomad, k3s, Dokku) suelen ser suficientes, y que el verdadero reto es elegir una infraestructura proporcional a la escala, las habilidades y las necesidades de negocio de una empresa, en lugar de seguir el hype.

Postura general sobre Kubernetes

  • Muchos ven Kubernetes como potente pero excesivamente complejo; otros sostienen que su complejidad se corresponde con problemas del mundo real a gran escala.
  • La opinión común: solo una pequeña minoría “necesita” k8s para sobrevivir, pero un grupo mucho más grande lo encuentra beneficioso operativamente.
  • Varios lo comparan con git o systemd: un diseño central sólido, una UX dolorosa.

Complejidad operativa y fragilidad

  • Los clústeres autogestionados se describen como frágiles: actualizaciones de etcd, planos de control insuficientemente dimensionados y fallos opacos.
  • A menudo se recomienda k8s gestionado (GKE/EKS/AKS) para evitar el dolor del plano de control, aunque algunos siguen reportando frecuentes “problemas extraños”.
  • Depurar despliegues fallidos de Helm, bucles de crash y el comportamiento de operators/CRD es una queja recurrente.

Herramientas: YAML, Helm, operators, alternativas

  • Hay un fuerte rechazo hacia YAML y, especialmente, el YAML templated con Go de Helm; la gente reporta errores sutiles de espacios/templating.
  • Alternativas mencionadas: kustomize, envsubst, Jsonnet, Pulumi, Terraform, CDK, cdk8s; algunos prefieren “solo código” en lugar de YAML templated.
  • Los operators y las CRD se ven tanto como la principal fortaleza de k8s (infraestructura programable, Ceph/Rook, operators de GitHub) como una gran fuente de complejidad y acoplamiento a nivel de clúster.

Autoscaling, despliegues y latencia

  • Se alaba a los HPA, VPA y KEDA cuando se adoptan ampliamente; ajustar HPA en vivo se considera mejor que escalar manualmente a las 4 a. m.
  • Los despliegues sin tiempo de inactividad son un motivador importante; muchos señalan que también se puede lograr esto con configuraciones blue/green más sencillas y reverse proxies.
  • Los arranques en frío de k8s para cargas efímeras y sensibles a la latencia son difíciles de bajar de ~0.5–2 s sin trabajar a fondo en el interior; algunos cambian a Nomad o a schedulers personalizados.

Cloud, lock-in y portabilidad

  • Las voces pro-k8s destacan: modelo declarativo, balanceo de carga y reinicios integrados, herramientas de observabilidad y, especialmente, APIs agnósticas a la nube entre local, on-prem (k3s) y cloud.
  • Los críticos responden que las configuraciones reales siguen dependiendo mucho de las particularidades de cada nube y que la “migración a la nube” se sobreenfatiza en relación con la frecuencia con la que ocurre.

Cuándo no usar Kubernetes y alternativas

  • Para sistemas simples o a pequeña escala, muchos prefieren: ASGs, ECS/Fargate, Cloud Run, Docker Compose, Swarm, Nomad, Dokku, Kamal, VMs sin más con scripts.
  • Los usuarios de homelab a menudo encuentran suficiente k3s o simplemente Docker Compose.

Dinámicas culturales y organizacionales

  • K8s puede convertirse en una “trampa de la astucia” y un símbolo de estatus, generando culturas de héroes de plataforma y capas interminables de herramientas.
  • Varios argumentan que el verdadero problema es la adopción impulsada por el hype y el mal uso, no la tecnología en sí.