Kubernetes: El coste operativo de dar en cada clavo con un martillo

mayor mentira del mundo de la tecnología de los últimos 5 a 6 años es: «Pon tu aplicación en Kubernetes y ella se encargará del resto». Los que suban al escenario en las conferencias le dirán lo «autocurativo» que es Kubernetes (K8) y una increíble herramienta de orquestación. Pero nadie le habla del coste del ejército de ingenieros que se necesita para dirigir esa orquesta.

La triste verdad es que usted no es Google. Probablemente tampoco tenga los problemas de escalado de Google. Pero por el «FOMO» (miedo a quedarse atrás) en la industria, intenta gestionar incluso un sitio web simple con un sistema de paneles de control de submarinos nucleares complejo. Echemos un vistazo a este proyecto de ley invisible sobre el «infierno de YAML».

1. Operaciones del «segundo día»: El sueño se acabó, la realidad comienza

Crear el clúster de Kubernetes es la parte más fácil («Día 1»). La principal pesadilla comienza con las operaciones del «Día 2». Mantener el clúster actualizado, gestionar la rotación de certificados, las incompatibilidades de versiones y los nodos bloqueados

• Coste de recursos humanos: gestionar los K8 es un trabajo a tiempo completo en sí mismo. ¿El trabajo de sus desarrolladores es escribir código o depurar por qué Ingress Controller
no dirige el tráfico?
• Abstraction Leak: Dicen que el hardware del K8 es abstracto, pero es mentira. En el momento en que establezca los límites de CPU («solicitudes» y «límites») de forma incorrecta, su aplicación muere silenciosamente con el error «OomKilled» (memoria agotada
).
• Redes: comunicación entre POD, Service Mesh, complementos del CNI... Una simple solicitud HTTP puede convertirse de repente en un problema de ingeniería de redes intratable

2. Reanudar el desarrollo impulsado

Cuando entro en una empresa como experto escéptico, lo primero que veo es: ¿Esta arquitectura se impuso por los requisitos del puesto o es el deseo de los ingenieros de escribir «experto en Kubernetes» en sus currículums?

Si su aplicación cabe en un único servidor virtual (VM) y la divide en un clúster K8 de 3 nodos, lo único que resuelve es

3. Vulnerabilidades causadas por la complejidad

complejidad es el enemigo número uno de la seguridad. La configuración por defecto de Kubernetes suele ser «orientada al trabajo», no «segura».

un contenedor Docker con autoridad raíz, eludir la gestión de secretos (cifrado etcd) o las reglas de RBAC (control de acceso basado en roles) configuradas incorrectamente... Para los hackers, el K8s es un parque de atracciones si se configura incorrectamente. Para garantizar la seguridad de los K8, necesita herramientas adicionales (trivy, falco, etc.) y más tiempo para gestionarlos.

4. ¿Cuándo es el K8s, cuándo es

Entonces, ¿debemos tirar Kubernetes a la basura? No. Busquemos el clavo correcto.

• El infierno de los microservicios: Si realmente tiene más de 50 microservicios que gestionar y se comunican intensamente entre sí, el K8 es un salvador.
• Aplicaciones monolíticas: si tiene una aplicación monolítica, dockerizarla y ejecutarla en una PaaS simple (Heroku, DigitalOcean App Platform, etc.) o en un servicio de contenedores gestionado (AWS ECS) le costará un 80% menos de carga operativa.