Диаграмма Kubernetes из YAML: весь кластер одной вставкой

Деплоймент в Kubernetes это стопка YAML, которая описывает структуру, но никогда её не показывает. Чтобы получить диаграмму Kubernetes из YAML, приходится собирать связи вручную: Ingress ссылается на Service по имени, Service выбирает Pod'ы по меткам, Pod'ы создаёт Deployment, а ConfigMap и Secret где-то по пути монтируются. Каждая связь это совпадение строк, спрятанное в отдельном файле. Чтобы понять, как трафик на самом деле доходит до вашего контейнера, вы держите в голове шесть документов и надеетесь, что правильно сопоставили метки.

Вся информация уже есть; её просто никто не рисует. Так нарисуйте. Вставьте манифесты в LetDraw: он читает те же поля, что и Kubernetes (селекторы, имена, ссылки), и раскладывает диаграмму того, как связаны объекты. Папка с YAML превращается в картинку, на которую можно указать на ревью.

Манифесты Kubernetes уже описывают граф

По сути Kubernetes это граф объектов, связанных метками и именами. Бэкенд Ingress называет Service; селектор Service совпадает с метками шаблона Pod; Deployment владеет этими Pod'ами; тома ссылаются на ConfigMap или Secret по имени. Эти ссылки и есть рёбра диаграммы. Не нужно придумывать структуру или угадывать связи: они записаны в YAML как буквальные совпадения строк, и именно поэтому их безопасно отрисовывать автоматически.

Одна вставка, весь кластер

Ничего особенного экспортировать не нужно. Входные данные это манифесты, которые вы и так делаете через kubectl apply. Склейте их (или возьмите тот же многодокументный файл) и вставьте в "Создать из кода"; LetDraw разберёт объекты и нарисует найденные связи.

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

Вот этот selector: app: api и этот service.name: api и есть рёбра. LetDraw следует по ним так же, как кластер, поэтому диаграмма отражает, как трафик идёт на самом деле, а не как вы это помните. Namespace'ы становятся контейнерами, внутри которых всё находится, а иконки позволяют с первого взгляда узнать каждый тип объекта.

YAML говорит, как связан кластер. Диаграмма это те же связи, только видимые.

Теперь это обычная диаграмма

Как только черновик оказался на холсте, им можно распоряжаться как угодно. Именно здесь картинка становится тем, что стоит сохранить:

• Уберите шум. Скройте объекты, которые не относятся к сути (пятнадцатый ConfigMap, который никому не нужен на диаграмме для онбординга), и оставьте путь запроса в центре внимания.
• Подпишите тонкие места. Отметьте, где находится readiness probe, какой Service только внутренний, откуда на самом деле берётся Secret.
• Покажите несколько namespace'ов. Вставьте несколько, и границы сделают мультиарендную схему очевидной.
• Храните как код. Экспортируйте в Mermaid или D2 и положите в репозиторий рядом с манифестами, чтобы диаграмма поставлялась вместе с кластером, который она описывает.

Схема кластера Kubernetes, который вы на самом деле задеплоили

Разрыв между написанным YAML и работающим кластером это место, где прячутся инциденты: селектор, который ничего не выбирает, Service, указывающий не на тот порт, забытый маршрут Ingress. Визуализация манифестов Kubernetes превращает эти несоответствия в то, что можно увидеть, а не обнаружить в два часа ночи. Вставьте то, что вы уже применяете, получите картину связей и храните её рядом с кодом, из которого она получена.

Скопируйте манифесты, вставьте их один раз и смотрите, как кластер сам собирается в диаграмму.