Lo que una entrevista de trabajo me enseñó sobre Kubernetes

• Kubernetes está siendo adoptado incluso en empresas pequeñas no tanto por la escalabilidad técnica, sino como un estándar para resolver la uniformidad del despliegue y problemas de operación organizacional
• En una búsqueda laboral reciente, todas las empresas con las que hablé usaban Kubernetes, a diferencia del panorama de hace 5 años donde coexistían VM·serverless·K8s
• Las razones clave que mencionaron los CTO fueron poder desplegar todos los servicios de la misma forma, dejar el conocimiento operativo en YAML y charts de Helm, y rastrear el historial de cambios con GitOps
• Las empresas pequeñas están aceptando la complejidad de Kubernetes más por sus ventajas organizacionales que por funciones avanzadas como HPA, Pod Disruption Budget o afinidad de nodos
• Para una empresa en etapa inicial, suele ser mejor empezar sin Kubernetes para enfocarse en el producto, y la necesidad de adoptarlo crece a partir del momento en que el CTO deja de ser la única persona a cargo de ingeniería

---

Cambios observados en una búsqueda laboral reciente

• Al leer ofertas, hacer entrevistas y hablar con alrededor de doce equipos de ingeniería durante una búsqueda laboral reciente, descubrí que todas las empresas con las que hablé usaban Kubernetes
• Cuando busqué trabajo hace 5 años, coexistían grupos que usaban Kubernetes ocasionalmente, grupos que usaban systemd sobre VM/VPS/EC2, y grupos serverless con Lambda y Cloud Run
• Donde trabajo ahora tiene problemas del tamaño de Big Tech, así que Kubernetes encaja claramente, pero me sorprendió ver que incluso startups de 10 personas con solo dos servicios también lo usaban
• Las empresas con las que hablé no operaban microservicios ni estaban cerca de un entorno de gran escala, y no mostraban mucho interés en los aspectos técnicos de Kubernetes

Razones para adoptar Kubernetes y criterios para decidirlo

• Por qué usan Kubernetes

  • La primera razón fue la uniformidad: si todos los servicios se despliegan de la misma manera, desaparece la situación en la que solo un servicio queda atado a scripts de bash en una VM bare o a Docker Compose por ser algo antiguo
  • La segunda razón fue el conocimiento compartible y contratable: como Kubernetes se usa como un lenguaje común, basta con ver los charts de Helm y la configuración de Kube para entender rápidamente la arquitectura
  • Si el conocimiento queda en YAML y no en la cabeza de una persona, se reducen los casos en que alguien nuevo pasa semanas tratando de entender cómo ejecutar algo después de que otra persona se fue
  • En mi empresa actual, el SRE de guardia puede mantener incluso servicios que nunca había visto porque los patrones de Kubernetes son similares entre equipos
  • Esta ventaja solo se mantiene mientras la configuración no sea excesivamente particular
  • La tercera razón fue la trazabilidad: si en vez de ejecutar directamente kubectl apply -f en el clúster se suben los charts de Helm a git y luego se pasa por la aprobación del MR y el despliegue con FluxCD o ArgoCD, queda un historial de cambios
  • Como este flujo encaja de forma natural entre GitOps y Kubernetes, ayuda con compliance casi sin costo adicional
  • Mi empresa actual está pasando bien las certificaciones ISO con este enfoque

• Conclusiones obtenidas

  • La elección de estos CTO no era una tontería, sino una forma de resolver problemas reales
  • Kubernetes parecía una solución técnica para un problema técnico, pero muchos CTO estaban más interesados de lo esperado en sus ventajas no técnicas
  • Los problemas técnicos de las empresas pequeñas no suelen requerir realmente Kubernetes, y es probable que sus manifiestos ni siquiera tengan topologySpreadConstraints, HPA, Pod Disruption Budget o reglas de afinidad de nodos
  • Están aceptando el costo operativo de un software complejo por sus ventajas organizacionales, aun manteniendo una cantidad de nodos similar a la que tendrían con VM

• Por qué la transición ocurrió recientemente

  • Hace 5 años, VM con systemd, serverless y Kubernetes seguían siendo opciones viables, pero ahora en las ofertas de trabajo la combinación de VM y systemd casi desapareció, serverless quedó como un nicho y Kubernetes ganó
  • La razón exacta del momento de esta transición no está del todo clara
  • Una explicación posible es que Kubernetes administrado como EKS, GKE y AKS maduró, y además ya hay suficiente gente que aprendió Kubernetes como para que contratar con otro enfoque sea incluso más difícil
  • Helm hizo que reutilizar charts creados por otras personas se convirtiera en una opción realista

• Cuándo usar Kubernetes

  • Mi criterio personal es el momento en que el CTO deja de ser la única persona de ingeniería
  • Cuando entra la segunda persona de ingeniería, alguien que no configuró directamente los servidores tiene que poder desplegar, y hace falta un control de acceso adecuado en lugar de simplemente dar llaves SSH para todo
  • Tarde o temprano alguien se va de la empresa, y el conocimiento operativo que tenía también puede irse con esa persona
  • A partir de ese punto, el conocimiento debe quedar dentro del sistema y no en las personas
  • Antes de esa etapa, depurar un clúster realmente puede ser difícil, y uno puede terminar gastando en infraestructura la energía que debería ir al producto
  • Justo antes de una llamada con un cliente grande, en una emergencia puede ser más rápido y comprensible arreglar algo a las carreras con git pull en un VPS que pasar dos horas buscando la causa de un pod en CrashLoopBackOff

[GN⁺]

Opiniones en Lobste.rs

• En Europa la razón es bastante clara. Los CTO creen que si lo montan sobre K8s pueden cambiar de proveedor de K8s administrado en cuestión de semanas
  No significa que sea cierto, pero de verdad lo creen. También piensan que los entornos de PR se vuelven más fáciles
  Pero el punto clave es poder cambiar de proveedor. Esperan que en los próximos años aparezcan prohibiciones de uso de proveedores vinculados con EE. UU., especialmente en GDPR, sistemas financieros, etc. Así que se están preparando para ese riesgo

• Parece una prueba de que la industria tecnológica perdió totalmente el rumbo, sin importar el tamaño de la empresa. El stack se ha vuelto cada vez más uniforme y complejo, y como resultado cada vez es más difícil encontrar productos y servicios que puedas usar sin rechinar los dientes

  • Las capas de bajo nivel tienen tantos bugs y tanta complejidad que, para sobrevivir, al final no queda otra que construir algo como Kubernetes. Si queremos evitar que el stack siga creciendo hacia arriba, hay que mejorar las capas de abajo
    Hacen falta primitivos del sistema operativo mucho mejores. Por ejemplo, los contenedores mezclaban varias funciones de aislamiento del kernel sin un diseño consistente, así que tenían muchos huecos
    Ahora el aislamiento de contenedores ha mejorado bastante, pero no fue diseñado desde el principio con seguridad y solidez, sino que se fue parchando a lo que salía. Hasta que el kernel resuelva esa enorme deuda técnica, o alguien haga un kernel al que valga la pena migrar, vamos a seguir apilando cosas encima

• Una herramienta de despliegue lo bastante compleja termina incluyendo una implementación a medias de Kubernetes hecha como parche temporal, definida de manera informal, llena de bugs y lenta

  • Lo de “a medias” sí es correcto. Solo que da la casualidad de que esa mitad es justo la mitad que hace falta
    Podría hablar largo y tendido de cómo estaba montada en 2009 una empresa SaaS de comercio electrónico valuada en mil millones de dólares, o de cómo funcionaba el backend en línea de un juego multijugador AAA gigantesco, y esas cosas definitivamente se parecían más a Kubernetes que a despliegues en una sola máquina
    Pero eran más rápidas y tenían opiniones fuertes exactamente en la forma que la organización necesitaba, no de maneras que chocaban con los requisitos del producto
    Lo de que Kubernetes es “buggy” muchas veces no viene tanto del sistema central, sino de las innumerables capas de interfaz que le montamos encima para forzarlo a comportarse como queremos
  • Eso aplica a Erlang, no a Kubernetes. En Kubernetes no tiene ningún sentido

• El problema es que la mayoría de las organizaciones adopta K8s a medias, hasta arma un equipo de DevOps para administrarlo, y aun así termina aventándole a los ingenieros de software todo lo relacionado con K8s: escribir, desplegar, depurar y operar
  Un buen equipo de DevOps debería ofrecer internamente una experiencia tipo Heroku. Deberías definir los recursos necesarios y desplegar al hacer merge a main, no andar perdido en un dashboard chafa de GitOps/DevOps tratando de averiguar qué salió mal
  Heroku fue el punto más alto de la experiencia de desarrollador, y siento que eso se perdió después de K8s

  • Más allá de ver que un Pod se ejecuta en un nodo, no tengo claro cuál sería la gran diferencia entre la experiencia de uso de Heroku y la de Kubernetes
    Claro, Heroku ofrece una experiencia más integrada para conectar bases de datos o desplegar con git push, pero hacer una capa personalizada encima de Kubernetes no suele salir bien. Al final terminas exponiendo todos los parámetros tal cual

• En la industria, la adopción tecnológica siempre se mueve con la lógica de “contratar algo listo para usar y despedirlo si ya no sirve”. Este es solo el ejemplo más reciente

• La frase “el conocimiento debe vivir en el sistema, no en las personas” expresa muy bien algo que yo había pensado de forma vaga
  Este tipo de formalización solo es posible cuando baja la variabilidad del proceso. Primero lo hace una persona, luego se documenta el proceso, después se convierte en script y finalmente se automatiza
  En los flujos de trabajo comunes de herramientas o ecosistemas populares, gran parte de esas etapas te llega casi gratis

• No hago mucho DevOps, y ahora mismo el sistema funciona bien solo con systemd y contenedores podman de vez en cuando. Trabajo en IoT/AgTech
  Este texto tiene ese tipo de “afirmaciones” que uno suele escuchar de ejecutivos no técnicos. Algo como “¿ellos también usan LoRa? ¿Entonces ya está? ¿Podemos lanzar mañana?”
  Existe la creencia de que la no uniformidad es el único obstáculo para el éxito. Si dos sistemas usan Fiber, Modbus o “tienen una API”, entonces supuestamente ya se pueden conectar de inmediato y crear esa gran experiencia donde “1 + 1 es más que la suma de las partes”
  Pero que dos programas acuerden un estándar de interoperabilidad de bajo nivel no elimina el trabajo real de decidir cómo interpretar y usar de forma útil datos fáciles de parsear
  Que dos personas hablen el mismo idioma no hace que desaparezca el trabajo. Usar un lenguaje común tampoco borra las decisiones que parte del equipo tomó con esa herramienta bajo las condiciones que conocía en ese momento
  Al principio, en ciencia e ingeniería, Fortran era el idioma común, pero eso no evitaba que uno quedara totalmente desconcertado con el trabajo de sus colegas o que terminara reescribiéndolo
  No tengo problema con el valor de K8s ni con que hoy se haya convertido en el “estándar”. Pero me cuesta aceptar la idea de que eso haga desaparecer cierto tipo de problemas de programación. La ley de conservación de lo feo sigue ahí

• Kubernetes es una plataforma de despliegue decente

• La forma de distribución también es otra razón. Trabajo con nodos Canton, y el software Canton upstream junto con las apps relacionadas se entrega como charts de Helm
  Independientemente de si Kubernetes es adecuado para nuestro trabajo, yo diría que no, el software se distribuye y se soporta así. Si te sales de ese camino, el trabajo extra termina siendo mayor que lidiar con Kubernetes

• No sé si solo me pasa a mí, pero este texto suena demasiado como si lo hubiera escrito una IA
  Aun así, estoy de acuerdo con la idea general. Estoy migrando configuraciones de homelab/self-hosting desde un estado de ajustes personalizados de systemd, comandos de shell que ya no recuerdo, y “carajo, ¿en qué archivo Markdown había anotado ese procedimiento de configuración?”, y de verdad se siente refrescante
  Todavía no uso un sistema real de despliegue continuo, pero me gusta la sensación de que con un pequeño script de shell apply y un conjunto de archivos YAML podría recuperar el 90% incluso después de un desastre
  systemd es conceptualmente simple, pero la reproducibilidad es compleja; Kubernetes es lo contrario. Pagas un costo conceptual mayor, pero la reproducibilidad y la comprensión que viene con ella son mucho más fuertes. Al menos así lo veo por ahora
  Sigo en una etapa intermedia de aprendizaje de Kubernetes, pero últimamente lo he estado disfrutando bastante

  • Hace 10 años habría estado de acuerdo, pero ahora systemd también se siente como “otro monstruo” por la variedad de opciones de namespaces y la integración dinámica de usuarios
    Este tipo de integración vertical con definiciones de primera clase parece una mala dirección
  • Si lo escribió una IA o no, realmente no importa mucho. Lo importante es si está bien escrito o no