Un despliegue de Kubernetes es una pila de YAML que describe una forma que nunca te muestra. Un Ingress apunta a un Service por nombre, el Service selecciona Pods por etiqueta, los Pods salen de un Deployment, y un ConfigMap y un Secret se montan en algún punto del camino. Cada vínculo es una coincidencia de cadenas enterrada en un archivo distinto. Para entender cómo llega realmente el tráfico a tu contenedor, tienes que mantener seis documentos en la cabeza y esperar haber emparejado bien las etiquetas.
Toda la información está ahí; simplemente nunca se dibuja. Así que dibújala. Pega tus manifiestos en LetDraw: lee los mismos campos que lee Kubernetes (selectores, nombres, referencias) y genera un diagrama de cómo se conectan los objetos. Lo que era una carpeta de YAML se convierte en un dibujo que puedes señalar en una revisión.
Los manifiestos ya describen el grafo
En el fondo, Kubernetes es un grafo de objetos conectados por etiquetas y nombres. El backend de un Ingress nombra un Service; el selector de un Service coincide con las etiquetas de una plantilla de Pod; un Deployment es dueño de esos Pods; los volúmenes hacen referencia a un ConfigMap o un Secret por nombre. Esas referencias son exactamente las aristas de un diagrama. No tienes que inventar la estructura ni adivinar las conexiones; están escritas en el YAML como coincidencias literales de cadenas, y eso es precisamente lo que permite dibujarlas de forma automática y segura.
Pega tus manifiestos de Kubernetes una vez y ve todo el clúster
No exportas nada especial. Los manifiestos a los que ya haces kubectl apply son la entrada. Concaténalos (o usa el mismo archivo multidocumento) y pégalos en Generar desde código; LetDraw analiza los objetos y dibuja las conexiones que encuentra.
apiVersion: apps/v1 kind: Deployment metadata: { name: api } spec: replicas: 3 selector: { matchLabels: { app: api } } --- apiVersion: v1 kind: Service metadata: { name: api } spec: selector: { app: api } # ← matches the Deployment's pods ports: [{ port: 80, targetPort: 8080 }] --- apiVersion: networking.k8s.io/v1 kind: Ingress spec: rules: [{ http: { paths: [{ backend: { service: { name: api } } }] } }] # ← names the Service
Ese selector: app: api y ese service.name: api son las aristas. LetDraw las sigue igual que lo hace el clúster, así que el diagrama refleja cómo fluye el tráfico en realidad, no cómo recuerdas que fluía. Los namespaces se convierten en los contenedores dentro de los que se sitúa todo, y los iconos hacen que cada tipo de objeto se reconozca de un vistazo.
El YAML dice cómo está cableado el clúster. El diagrama es solo ese cableado, hecho visible.
Ahora es un diagrama normal
Una vez que el borrador está en el lienzo, es tuyo para darle forma. Aquí es donde el dibujo se convierte en algo que vale la pena conservar:
- Quita el ruido. Oculta los objetos que no forman parte de la historia (el decimoquinto ConfigMap que nadie necesita ver en un diagrama de onboarding) y deja la ruta de la petición en primer plano.
- Anota las partes delicadas. Marca dónde vive la readiness probe, qué Service es solo interno y de dónde sale realmente el Secret.
- Muestra más de un namespace. Pega varios y deja que los límites hagan evidente la disposición multi-tenant.
- Guárdalo como código. Exporta a Mermaid o D2 y ponlo en el repo junto a los manifiestos, para que el diagrama viaje con el clúster que describe.
Mira el clúster que realmente desplegaste
La brecha entre el YAML que escribiste y el clúster que estás ejecutando es donde se esconden los incidentes: un selector que no coincide con nada, un Service que apunta al puerto equivocado, una ruta de Ingress que olvidaste. Dibujar los manifiestos convierte esas discrepancias en algo que puedes ver, en lugar de algo que descubres a las 2 de la madrugada. Pega lo que ya aplicas, obtén un dibujo de cómo se conecta y guárdalo junto al código que lo generó.
Copia tus manifiestos, pégalos una vez y mira cómo el clúster se ensambla solo en un diagrama.