Людям тяжело с Kubernetes не потому, что YAML сложно набирать. Им тяжело, потому что между "пришёл запрос" и "контейнер его обработал" есть невидимая цепочка объектов, и ни одна её часть не лежит в одном месте; без схемы сети Kubernetes её приходится собирать в голове. Pod выполняет код, но трафик никогда не направляют на Pod. Service даёт ему стабильное имя, но Service не терминирует TLS. Ingress или Gateway работает с внешним миром, но пересылает запросы в Service, который выбирает Pod'ы, а те могут переехать в любой момент. Пропустите одно звено, и ничего не работает, причём сообщение об ошибке редко говорит, какое именно.
Диаграмма этой цепочки ценнее любого количества перечитываний манифестов. Давайте построим мысленную модель объект за объектом, а затем нарисуем её.
Pod'ы: где на самом деле выполняется код
Pod это один или несколько контейнеров, запланированных вместе и разделяющих сетевую идентичность. Это единица, в которой работает ваш процесс. Ключевой факт для диаграммы: Pod'ы это скот, а не питомцы. Их постоянно создают и уничтожают, их IP меняются, и никогда не стоит зависеть от конкретного Pod'а. Именно поэтому существует всё, что над ними: чтобы было на что-то стабильное указывать.
Service: стабильное имя перед меняющимися Pod'ами
Service это стабильный виртуальный адрес и правило балансировки нагрузки. Он использует селектор меток, чтобы найти Pod'ы за собой, и распределяет трафик между теми, что существуют сейчас. Когда Pod умирает и запускается новый, Service тихо обновляется; вызывающие стороны ничего не замечают. На вашей диаграмме Service это блок, к которому подключается всё остальное, с подразумеваемым разветвлением на меняющийся набор Pod'ов за ним.
Ingress vs Gateway API: дверь во внешний мир
Один Service не открывает вас миру полезным образом. Это работа Ingress или, в более новой модели, Gateway. Этот слой отвечает за маршрутизацию по хосту и пути, терминацию TLS и правила вида "запросы для этого хоста и пути идут в тот Service". Gateway API обобщает старый Ingress с более чистым разделением ответственности (кто владеет шлюзом, а кто маршрутами), но на диаграмме форма та же: это пограничный блок, в который всё внешнее попадает первым и который по правилам пересылает запросы в Service.
Нарисуйте цепочку один раз, и ошибки начнут объяснять себя сами: сломанный селектор, отсутствующий маршрут, Service, который ни на что не указывает.
Почему нарисовать лучше, чем перечитать
Когда что-то недоступно, диаграмма становится чеклистом. Указывает ли правило Ingress на нужный Service? Совпадает ли селектор Service с метками Pod'ов? Есть ли Pod'ы вообще? Каждое звено на картинке это то, что может оказаться неправильным, и когда они разложены перед глазами, расплывчатое "не работает" превращается в конкретное "селектор не совпадает". В этом разница между отладкой и гаданием.
Пусть манифесты нарисуют архитектуру Kubernetes сами
Расставлять эти блоки вручную не нужно. Ваши манифесты уже кодируют всю цепочку: Ingress называет свой Service, Service несёт свой селектор, Deployment проставляет метки на свои Pod'ы. Вставьте YAML, и связи будут нарисованы за вас, сгруппированные по namespace, так что картинка соответствует кластеру, а не вашим предположениям о нём.
Затем подпишите для людей
Когда объекты на холсте, сделайте так, чтобы картинка обучала. Выделите цветом внешнюю границу, сгруппируйте по namespace, отметьте, где терминируется TLS, и пометьте, какой Service под нагрузкой. Новый инженер должен суметь проследить пальцем запрос от интернета до контейнера, не открывая ни одного YAML-файла. Вот диаграмма, которую стоит хранить.
Вставьте манифесты, посмотрите, как связываются Pod'ы, Service, Ingress и шлюзы, и наконец удержите весь путь запроса в голове целиком.