Esta vez y después de unas merecidas vacaciones venimos con experiencias personales y con algo de humor.
Todos hemos abierto esa nevera.
La nevera de la oficina, la compartida, la que usa todo el mundo. Abres la puerta buscando un sitio para tu comida y ahí está: al fondo, tapado por una botella de leche que caducó en marzo, un tupper que no es de nadie. Y desde hace unos días, cuando abres la puerta, la nevera entera huele a algo que preferirías no saber qué es.
Ese tupper es nuestro cluster de SBX. Y esta es la historia de cómo apestó toda la nevera y de cómo, al final, dejamos de necesitar la nevera compartida.
Martes 11:00am: mensaje de Slack "¿De quién son los 10 deployments que llevan semanas ahí?".
Acto 1: el tupper entra con las mejores intenciones
Al principio, meter el tupper en la nevera tiene toda la lógica del mundo. "Lo dejo aquí y me lo como luego". Nadie mete un tupper pensando "lo dejaré 3 semanas y apestaré la nevera del equipo".
Con SBX pasó igual: buenísima idea, un entorno de sbx, un sitio donde probar. ¡Lógica impecable!
Que la gente pruebe sus cosas aquí, rompa lo que tenga que romper y, cuando funcione, que lo suba a STG.
Durante un tiempo funcionó. Un developer desplegaba sus cosas, las probaba, las rompía y las arreglaba. Comida entrando y saliendo sin problema.
El pequeño detalle: solo una nevera usada por todos.
Acto 2: el tupper se pudre
Nadie recuerda el día exacto en que el tupper empezó a oler. Es gradual. Primero es solo "un tupper más". Luego lleva ahí más de lo normal. Y para cuando alguien se da cuenta de que huele, ya nadie sabe de quién es ni cuánto lleva.
Cronologia de degradación de SBX:
Primero, "SBX está roto". Alguien despliega algo, un helm chart a medio hacer, una config agresiva, un CRD que colisiona, y tira un servicio que otros tres estaban usando. Pero como hay quince personas usando la misma nevera, nadie sabe quién dejó el tupper ni qué hay dentro. Un kubectl get events es como arrepentirse al abrir el tupper: sales con menos ganas aún.
Después, "SBX ya no se usa". Como la nevera huele mal, y como cuando parece que está bien no te fías de que tu comida no acabe contaminada por el experimento de otro, la gente deja de usarla. Poco a poco SBX se convierte en tierra de nadie: un fondo de nevera lleno de tuppers zombie (cuál más pocho) que nadie se atreve a tirar por "si son de alguien".
Y entonces, "¿para qué queremos SBX si tenemos ya STG?"
Suena bien, no? (a mi me ponen nervioso estas frases). Si la nevera de SBX apesta, ¿para qué usarla? Me llevo la comida a la otra nevera, la de STG, que estará mejor. Y aquí es donde la cosa se pone de verdad fea.
Acto 3: el olor se muda a STG
Cuando la gente deja de usar la nevera de SBX y empieza a meter tuppers en STG, no has resuelto el problema: ahora tenemos dos problemas, y cada vez más cerca de producción.
STG, que debía ser la nevera buena, la limpia, la que se parece a la de casa (prod), ahora hace de SBX. Ahora es la que se llena de experimentos. Y cuando STG deje de oler bien, ¿cuál es la siguiente nevera?... (Spoiler: Producción).
Ese es el verdadero problema de un tupper podrido en una nevera compartida: no se queda quieto.
El diagnóstico: el problema nunca fue el tupper
Aquí es donde por fin te sientas y entiendes contra qué estás luchando. (uno de ellos).
El error que cometimos durante meses fue intentar arreglar SBX. Más limpieza, más quotas, más "por favor", más normas en post-it, pero estábamos tratando el síntoma.
El problema no era el tupper. El problema era una contradicción de diseño.
Experimentar significa romper. Y si rompes algo que es compartido, apestas a todos. No hay cartel de "limpia la nevera los viernes" que arregle eso, porque ¿y si limpias el viernes y es del compi del sábado?
La solución no era una nevera mejor gestionada. Era eliminar la necesidad de una nevera compartida.
Como no, soluciones fáciles
Un cluster EKS por developer: no. Cada cluster EKS son minutos de aprovisionamiento, un control plane que pagas, addons y una factura que se multiplica por persona (se planteó, aportando renders, argo...), pero podría ser comprar una nevera industrial para guardar un sándwich.
Un namespace por developer: tentador, pero un namespace no es un aislamiento de verdad. Es darle a cada uno su estantería en la misma nevera: siguen compartiendo motor, la puerta, aire... Comparten el mismo API server, CRDs, el mismo RBAC a nivel de cluster. Uno instala un operator y afecta a todos. Uno mete un CRD que colisiona y hola de nuevo, nevera compartida.
Lo que hacía falta era el punto medio que no existía: el aislamiento de un cluster real, con el coste de un namespace.
Ahí es donde entra vCluster.
vCluster: tu propia nevera dentro de la nevera
Un vCluster es un cluster de Kubernetes completo: su propio API server, su propio control plane, su propia versión de k8s; que corre dentro de un namespace de un cluster host. Desde dentro parece un cluster real, aunque en realidad son pods.
La clave para nosotros: cada developer apesta SOLO su vCluster. Puede dejar el tupper podrirse a gusto, tirar su API server, meter un CRD roto, desplegar un chart infernal, y al de al lado le da exactamente igual. Su nevera ni se entera, y cuando el vCluster está hecho un desastre... lo tira y coge otro limpio en segundos.
Es la fiambrera personal que la nevera compartida nunca pudo ser, porque aquella era de todos y esta es tuya.
Y lo mejor: como todos los vClusters viven dentro de un solo EKS host, el coste es el de los pods que consumen, no el de N clusters.
Self-service de verdad: Git como interfaz
Tener vClusters está bien. Pero si para conseguir uno el developer tiene que abrirme un ticket, escribirme 7 veces por Slack, llamarme por Zoom y seguirme hasta mi casa por la noche, ahora soy yo el que reparte fiambreras a mano.
Self-service de verdad significa que el developer no le pide nada a nadie.
Lo hemos montado sobre EKS Capabilities de ArgoCD (tenemos otro post que habla de esto). https://dev.to/aws-espanol/aws-me-esta-quitando-el-trabajo-591f
El modelo es tan simple como esto: en un repo, una carpeta con un fichero por developer.
Cada fichero es la "solicitud" de un entorno:
Y un ApplicationSet va mirando qué pasa ahí; por cada fichero, lanza un vCluster:
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: dev-vclusters
namespace: argocd
spec:
goTemplate: true
goTemplateOptions: [ "missingkey=error" ]
generators:
- git:
repoURL: https://github.com/ragerdevops/vcluster
revision: main
files:
- path: "developers/*.yaml"
template:
metadata:
name: 'vcluster-{{.developer}}'
spec:
project: default
destination:
name: in-cluster
namespace: 'vcluster-{{.developer}}'
sources:
- repoURL: https://charts.loft.sh
chart: vcluster
targetRevision: 0.36.0
helm:
releaseName: 'vcluster-{{.developer}}'
# Los valores del fichero del dev entran aquí
valuesObject:
controlPlane:
distro:
k8s:
resources:
limits:
cpu: '{{.resources.cpu}}'
memory: '{{.resources.memory}}'
syncPolicy:
automated:
selfHeal: true
prune: true
syncOptions:
- CreateNamespace=true
Lo mejor de toda la "plataforma":
Abrir un PR creando un fichero = tener tu entorno.
Un developer nuevo entra al equipo. Abre un PR con developers/sunombre.yaml. Se mergea. ArgoCD detecta el fichero y en segundos tiene su vCluster corriendo. No me ha pedido nada. No ha esperado a plataforma.
¿Se va del equipo? ¿No lo necesita? Borra su fichero: prune: true destruye su vCluster entero. Auditado en el historial de Git, revisión por PR, sin que yo toque nada.
Eso es self-service. El equipo de plataforma provee la capacidad; los developers la consumen solos.
La nevera, por fin, ordenada
Si volvemos al principio: SBX podrido, nadie lo usa, se experimenta en STG, STG se contamina, PROD en peligro.
Con un vCluster desechable por developer, la nevera se ordena sola.
El vCluster es la fiambrera personal donde el developer prueba, rompe y arregla antes de tocar cualquier nevera compartida. Cuando su app funciona en su vCluster, entra en STG.
Y aquí el final feliz: STG vuelve a ser lo que debía ser. Ya nadie experimenta ahí, porque cada uno experimenta en su propio vCluster. STG deja de oler a SBX y recupera su papel: el primer entorno de integración real, estable, donde validas que tu app funciona con la plataforma, no si funciona en absoluto.
SBX nunca se limpió: dejó de ser necesario.
Kubectl get pods
vcluster connect vcluster-alex --namespace vcluster-alex
vcluster disconnect
Como podemos ver una vez lanzamos el vcluster connect tenemos un entorno aislado y nuevo que nada tiene que ver con el del host.
Como toda historia, tiene sus cosas malas
Sería muy chungo vender vCluster como solución a todo, así que veamos qué no cubre. Un vCluster aísla el control plane, pero comparte el plano de datos (nodos, kernel y red) con el host. De ahí salen sus límites:
No valida tu mesh: si tu app depende de Istio con sidecars, en el vCluster no está tu Istio del host. La integración nativa existe, pero solo en modo Ambient.
No valida tu ingress real. Gateway API, ALB, tus hostnames y certs son infra del host. En el vCluster no los pruebas tal cual.
DaemonSets y cosas de nodo no se comportan como en un cluster real. El vCluster no controla los nodos físicos.
No valida tu integración con la plataforma.
En otras palabras: el vCluster valida que tu comida esté buena. STG valida que cabe en nuestra nevera. Cada uno tiene su papel, y por eso STG sigue existiendo.
Para muchas de las cosas que un developer hace iterar sobre su chart, su config, su lógica, desplegar su Prometheus, probar operators, romper y rehacer el vCluster le cubre todo el ciclo de "experimentar" sin tocar nada compartido.
Hacia dónde va todo esto
Lo que tenemos soluciona uno de nuestros problemas, pero una plataforma de verdad no se para aquí. Los siguientes pasos:
Kubeconfig automático por developer. Que al provisionarse el vCluster, el dev reciba el contexto listo, sin comandos manuales.
Quotas por developer. ResourceQuota + LimitRange parametrizados.
Sleep mode. vCluster puede dormir los entornos inactivos (escala a cero) y despertarlos al reconectar. Ahorro de coste brutal cuando tienes N developers que no trabajan a la vez.
Aislamiento por identidad. Hoy los devs comparten rol de acceso; el siguiente nivel es que cada uno solo pueda tocar su vCluster, con grupos de IAM Identity Center.
Moraleja del tupper
Durante meses intentamos arreglar SBX. Le pusimos normas, quotas, avisos en Slack, carteles de "limpia la nevera los viernes". Nada funcionó.
El monstruo no era el tupper. El monstruo no era el tupper. En cuanto le dimos a cada developer su propia fiambrera desechable aprovisionada por ellos mismos vía Git, sobre vClusters en nuestro EKS, orquestada por ArgoCD gestionado, el problema desapareció.
A veces la mejor forma de arreglar una nevera que apesta no es limpiarla: es dejar de necesitarla.
Top comments (0)