etcd, o por qué el software moderno da pena [ENG]

Érase una vez en 2013, había una herramienta llamada etcd que era una base de datos realmente ligera escrita alrededor de Raft. Esta herramienta se escribió originalmente en 2013 para un proyecto fallido llamado CoreOS Container Linux ... En 2015, Google lanzó una herramienta no relacionada llamada Kubernetes. Llegaría a decir que Kubernetes es lo peor que le ha pasado a la administración de sistemas desde systemd...

[#1 freelancer]

Érase una vez en 2013, había una herramienta llamada etcd que era una base de datos realmente ligera escrita alrededor de Raft. Esta herramienta se escribió originalmente en 2013 para un proyecto fallido llamado CoreOS Container Linux que murió hace varios años, pero eso realmente no importa, etcd sobrevivió a CoreOS. Etcd proporcionó un conjunto conveniente y simple de primitivas (set a key, get a key, set-only-if-unchanged, watch-for-changes) con una API HTTP simple y sencilla encima de ellas. He creado una serie de herramientas usando etcd y es absolutamente un placer trabajar con ellas.

En 2015, Google lanzó una herramienta no relacionada llamada Kubernetes. Llegaría a decir que Kubernetes es lo peor que le ha pasado a la administración del sistema desde systemd. Es un conjunto integral que promete simplificar el funcionamiento de los clústeres de software y ofrecer algo así como la experiencia del administrador de clústeres borg de Google. Lo que realmente hace es:

Agregar cientos de nuevos modos de error a su software
Pasar de escribir configuración de software portátil a escribir miles de líneas de YAML específicas de k8s
Sumérjase en una malla de patrones cuestionablemente buenos como la containerización y la red definida por software

Si está ejecutando un sistema realmente enorme y desea tener una orquestación lista para usar, Kubernetes puede ser la herramienta para usted. Para el 99.9% restante, es solo una capa adicional de complejidad que no agrega casi nada de valor.

[#2 Mustela]

Resulta curioso que se hable tanto de ese producto y no de lo que compite, docker (con su swarm), que a su vez no dejaba de ser un producto posterior de LXC, que tirando del hilo no deja de ser una especie de jaula chroot pero más avanzada.

[#3 ElMaki]

Las notas al pie no tienen desperdicio. Tan jugosas como el artículo principal, si no más

[#5 freelancer]

#2 Cuando el Open Source tiene un sector que mueve mucho dinero detrás aparece docker, podman, kubernetes, openshift... Todos quieren su trozo del pastel. El CI-CD y demás cancamusas del 2020. Tener la solución predominante mueve empresas a tu nube, que es lo que paga todos estos proyectos. Entonces se salta por encima de todas las buenas prácticas y el objetivo es tener algo de lo que los comerciales puedan vender la versión enterprise con certificado, sello y garantía lo antes posible.

[#6 aironman]

Este enlace es un ejemplo de porqué Mnm puede ser útil.

[#7 hay_meneo]

"and it's absolutely a pleasure to work with."

A ver, al final es lo de siempre, el problema de trabajar con kubernetes es que muchos se meten a toquetear kubernetes sin tener ni idea o usar ninguna herramienta que te ayude como rancher o openshift.

Kubernetes bien configurado y bien usado es muy fácil de usar y de mantener.

Llevo casi dos años con kubernetes y eso de "writing thousands of lines of k8s-specific YAML" sólo lo ha podido escribir alguien que no ha usado kubernetes en la vida.

Los ficheros yaml de configuración son muy simples e intuitivos y reusables entre ellos, peor me parece por ejemplo el cloud formation de AWS.

Y el que use "miles de lineas en un yaml" no tiene ni idea o no está usando bien kubernetes, puedes aplicar configuraciones separadas con solo ficheros de 5 lineas o one liners por CLI o replicar configuraciones e instancias desde rancher o openshift sin tener que tocar un fichero yaml.