Git как источник желаемого состояния
В курсе «Kubernetes для веб-разработчика» мы описали «Площадку» манифестами и научились читать Deployment, Service и readiness. Теперь проект «Релиз» добавит постоянный источник желаемого состояния в Git и Argo CD, который сравнивает его с локальным кластером. Результат первой главы — понятное распределение ответственности: кто хранит намерение, кто создаёт контейнеры и кто разрешает применение нового выпуска.
Нужны основы Git, контейнеров и результат предыдущей серии. Архив нового курса автономен: API, web, обе версии кода и все декларации включены повторно, поэтому не требуется неизвестный registry или недостающая папка прошлой лаборатории. Автор не создавал кластер, не собирал образы, не выполнял Git операции, установку или тесты; описанные результаты ожидаемые.
Декларация на диске ещё не управляет кластером
В прежнем маршруте разработчик менял YAML и выполнял kubectl apply. Файл сообщал, какое состояние требуется, но сам не проверял, совпадает ли с ним кластер через час. Другой человек мог изменить replicas командой scale и забыть обновить файл. Тогда очередное apply возвращало прежнее число копий, хотя временное действие уже выглядело привычной частью работы.
Git добавляет историю намерений. Commit фиксирует согласованный набор деклараций и объяснение изменения. Для выпуска полезно видеть не только новое число replicas, но и образ, конфигурацию и выбранное окружение. Однако Git не выполняет Deployment и не знает, что Pod стал готовым. Это хранилище исходного состояния, а не замена Kubernetes контроллерам.
Argo CD получает определённую revision Git, строит манифесты и сравнивает их с живыми объектами. В нашей лаборатории применение остаётся ручным: новый commit не означает автоматическую замену работающей версии. Такое начало позволяет сначала увидеть difference, затем осознанно sync и только после этого наблюдать состояние Kubernetes.
Код, образ и Git revision обозначают разные вещи
API source находится в app/api, web — в app/web. Читатель самостоятельно создаст ploshchadka-api:1 и ploshchadka-web:1, загрузив их в отдельный kind-кластер. В app/api-v2 есть полный второй вариант API с дополнительной записью каталога. Архив не содержит слои этих образов и не утверждает, что они уже построены.
GitOps декларация ссылается на image. В нашем локальном маршруте imagePullPolicy Never означает использование заранее загруженного образа. Argo CD не выполняет Dockerfile при sync и не умеет получить отсутствующий собственный образ из неизвестного registry. Если reader забыл загрузить api:2, корректная декларация версии два всё равно даст ошибку запуска контейнера.
Commit Git и image tag не совпадают автоматически. Один commit может менять только replicas, а тот же код приложения оставаться в image один. Другой commit может связывать новый image и совместимые параметры. Для производственного выпуска обычно нужен проверенный неизменяемый digest и источник образов; локальная лаборатория использует явные теги один и два, запрещая перезаписывать их разным содержимым.
Следующая таблица задаёт термины серии. Значения описывают будущую самостоятельную работу, а не уже созданное окружение.
| Объект | Что обозначает |
|---|---|
| app/api | Исходники первого API |
| ploshchadka-api:1 | Локальный артефакт первой сборки читателя |
| Git commit | Набор желаемых деклараций |
| Application | Связь источника, пути и назначения |
| Deployment | Контроллер экземпляров приложения |
Выбираем границы локального проекта
Новый кластер называется release, context — kind-release. Namespaces ploshchadka-dev и ploshchadka-stage разделяют два учебных окружения. Имена API, web и Service api сохраняют преемственность с «Площадкой». Внутри каждого namespace web обращается к http://api:3000, поэтому overlay меняет место размещения, не требуя другого прикладного API.
Argo CD устанавливается в argocd. Источник Git находится в отдельном namespace release-lab и отдаёт только несекретные учебные файлы. Это самостоятельный источник, доступный repo-server внутри кластера; локальный путь на диске ноутбука не подставляется в repoURL. Как подготовить этот источник без внешнего аккаунта, разберём в следующей главе.
Bootstrap и GitOps имеют разные обязанности. Bootstrap создаёт namespaces, Git Service/PVC, Argo CD и учебные Secret. Application управляет Deployment, Service и ConfigMap выбранного overlay. Если поместить всё в один каталог и применить рекурсивно, будет трудно объяснить, кто имеет право удалить инфраструктуру и откуда восстанавливается сам источник.
Начинаем с ручного решения о выпуске
В Application отсутствует automated. После того как repo-server сможет прочитать Git, ожидается построение желаемых манифестов и состояние OutOfSync для ещё не созданного приложения. Reader просмотрит diff, выполнит sync и прочитает health. Эти три действия отвечают на разные вопросы: что изменится, было ли применено намерение, как чувствуют себя полученные ресурсы.
Synced не означает успешный пользовательский сценарий. Deployment может соответствовать YAML, но API возвращать неподходящее содержимое, web неправильно проксировать путь или внешний клиент не иметь доступа. В курсе проверка маршрута через локальный port-forward остаётся самостоятельным действием читателя после наблюдения Kubernetes. Автор не выдаёт наличие YAML за состоявшийся HTTP результат.
Manual sync также не отменяет контроля drift. Если replicas изменены напрямую, Argo CD может показать расхождение, не исправляя его автоматически. Человек решает, вернуть декларацию или сохранить намеренное изменение через Git. Этот выбор важен при обучении: наблюдение становится основанием действия, а не незаметной борьбой двух инструментов за одно поле.
Версия инструмента и передаваемый результат
На дату подготовки, 12 октября 2026 года, официальный stable/VERSION Argo CD содержит 3.5.4. В README закреплён соответствующий install.yaml v3.5.4 и рекомендован CLI той же версии. Использование stable ссылки без тега дало бы меняющееся содержимое при следующем самостоятельном проходе. Здесь фиксируется источник декларации установки, а совместимость целого локального стека ещё требует запуска читателем.
Kind и образ узла продолжают параметры предыдущей «Площадки». Собственные образы собираются из включённых исходников; внешних действий с аккаунтами не требуется. Базовый node:24-alpine пока не закреплён digest, поэтому перед реальным проходом читатель должен выбрать доступный образ своей архитектуры. Такой предел воспроизводимости записан рядом с файлами, а не скрыт за словом «готово».
После первой главы проект разделён на исходники приложения, артефакты, желаемые декларации и живые объекты. Git хранит историю намерения, Argo CD сравнивает и применяет выбранную revision, Kubernetes управляет экземплярами. В следующем уроке создадим понятный локальный bootstrap и источник Git, который repo-server действительно сможет читать по сетевому адресу.