Обновления и управление через Git
Научись отличать обновление приложения от обновления кластера. Используй установленный Argo CD (Continuous Delivery — непрерывная доставка) для безопасного опыта с одной учебной конфигурацией.
Ещё не начатГде выполнять задания
Используем уже установленный Argo CD (Continuous Delivery — непрерывная доставка). Учебное приложение управляет только одним ConfigMap. Обновление Kubernetes выполняется на отдельном стенде.
Открыть практикум и терминал ↗Читай урок в этой вкладке, команды выполняй в соседней. Подстановки в угловых скобках сначала замени своими значениями. Ctrl+C останавливает наблюдение или учебный сервер.
Сокращения этого модуля: расшифровки и смысл
- API
- Application Programming Interface — программный интерфейс
- CD
- Continuous Delivery — непрерывная доставка
- KaaS
- Kubernetes as a Service — Kubernetes как услуга
В командах сохраняется точное написание параметров и имён. В тексте сокращения раскрываются в скобках.
Результат модуля
- Составить матрицу версий и план со стоп-условиями.
- На установленном Argo CD (Continuous Delivery — непрерывная доставка) наблюдать возврат учебной конфигурации из Git.
- Проверить изменение на отдельном canary и отличить откат файла от восстановления данных.
Перед началом: Наблюдаемость: понять и исправить сбой.
1. Какие версии должны подходить друг другу
Версия Kubernetes — только одна строка в списке компонентов. Есть kubelet на нодах, управляющие компоненты, runtime контейнеров, сетевой плагин, драйвер хранилища и облачный провайдер. У каждого есть поддерживаемые сочетания и порядок обновления.
API (Application Programming Interface — программный интерфейс) меняется между версиями: некоторые поля и версии объектов удаляются. Читай release notes и политику version skew — допустимого различия версий компонентов. Не начинай обновление с команды, пока не проверены данные, копии и путь восстановления.
Составь таблицу: компонент, текущая версия, целевая версия, официальный источник совместимости, способ проверки. Не переноси номера из чужой статьи как готовое решение. Дата проверки важна: через несколько месяцев набор поддерживаемых версий изменится.
- Canary
- Отдельный малый стенд для проверки изменения.
- Drift
- Расхождение фактической конфигурации с записанной в Git.
- Self-heal
- Автоматический возврат управляемого объекта к намерению.
- Version skew
- Допустимое различие версий связанных компонентов.
По шагам
- В Git записано message=from-git.
- Ручная правка ставит manual-change.
- Контроллер замечает разницу и возвращает from-git; постоянное изменение делается в источнике.
2. Как спланировать обновление
Canary — небольшой отдельный стенд для проверки того же изменения. На нём повторяют создание приложения, сетевой запрос, подключение тома и удаление. Успех запуска управляющего процесса недостаточен: проверяют пользовательские функции.
Сначала обновляют компоненты в порядке, разрешённом их документацией. Узлы выводят на обслуживание с учётом готовых реплик, бюджетов и свободного места. Нужны стоп-условия: например, неготовая нода дольше согласованного времени или потеря доступа к данным.
На общей лаборатории мы не обновляем Kubernetes ради урока. В ней можно прочитать версии и составить план. Реальный прогон выполняется на отдельном стенде; пока он не пройден, галочка canary остаётся пустой.
3. Как Git становится источником настроек
Git хранит версии файлов. GitOps — практика, при которой желаемое состояние записано в Git, а контроллер регулярно сравнивает его с кластером и применяет разницу. Argo CD (Continuous Delivery — непрерывная доставка) уже установлен в нашей лабе.
У каждого объекта должен быть понятный владелец. Если Argo CD (Continuous Delivery — непрерывная доставка) следит за ConfigMap, ручное редактирование создаёт drift — расхождение с Git. При включённом selfHeal контроллер вернёт значение. Поэтому править управляемый объект вручную и ждать постоянного результата бессмысленно.
В упражнении новый AppProject разрешает только ConfigMap в kaas-gitops из одного репозитория. Application указывает на отдельный каталог. Объекты лабораторного baseline и другие приложения не затрагиваются. Секреты в Git не добавляются.
4. Что можно вернуть назад
Возврат коммита восстанавливает конфигурацию, но не обязательно содержимое базы или старый формат данных. Downgrade Kubernetes может не поддерживаться. Поэтому «откатить всё» — недостаточная инструкция.
Раздели три сценария: вернуть манифест приложения; восстановить прикладные данные; восстановить управляющие компоненты. Для каждого нужны собственные условия и проверки. Перед изменением с необратимым преобразованием данных подготовь проверенную копию и решение о совместимости.
В KaaS (Kubernetes as a Service — Kubernetes как услуга) клиент должен видеть согласованное состояние операции обновления: запланирована, выполняется, приостановлена или требует вмешательства. Возобновление не должно повторно создавать уже обновлённые ресурсы.
Практика через терминал портала
Прочитай реальные версии
Открой терминал. Эта часть только читает состояние.
kubectl version kubectl get nodes -o wide helm list -A kubectl -n argocd get deploymentsЧто должно получиться. В журнале есть датированный перечень версий и установленного Argo CD (Continuous Delivery — непрерывная доставка).
Если результат отличается
Не считай тег образа единственным доказательством поддерживаемости. Проверь официальную матрицу.
Подготовь план и стоп-условия
Выбери одну цель обновления на отдельном стенде. Запиши порядок, три проверки пользователя и измеримое условие остановки.
kubectl get --raw /readyzЧто должно получиться. Есть ответ о готовности текущего управляющего интерфейса и отдельный план. Обновление ещё не выполнялось.
Если результат отличается
Отсутствие разрешения на readyz не повод выдавать широкие права учебному приложению.
Прочитай ограниченный проект
Сначала скачай файл. Убедись, что destination — только kaas-gitops, source — каталог labs/course-gitops, а разрешённый тип — ConfigMap.
curl -fSLo /tmp/kaas-gitops.yaml https://test.igorhome.ru/static/learning/gitops-lab.yaml cat /tmp/kaas-gitops.yamlЧто должно получиться. Нет разрешения на произвольные namespaces или общие ресурсы. Репозиторий использует уже настроенный в Argo CD (Continuous Delivery — непрерывная доставка) доступ.
Если результат отличается
Если зарегистрированный адрес репозитория изменился, сверяй существующие Application, не копируй секрет из Secret.
Запусти учебную синхронизацию
Примени только скачанный проверенный файл. Он создаёт собственный namespace и отдельные AppProject/Application.
kubectl apply -f /tmp/kaas-gitops.yaml kubectl -n argocd get application kaas-course -o wide kubectl -n kaas-gitops get configmap course-message -o yamlЧто должно получиться. Application приходит в Synced, в ConfigMap message=from-git. Первая синхронизация может занять несколько минут.
Если результат отличается
При Unknown или Error прочитай status.conditions Application. Не меняй общий проект default или доступ baseline.
Создай расхождение
Измени только учебное значение. Сразу прочитай его, затем наблюдай возврат.
kubectl -n kaas-gitops patch configmap course-message --type=merge -p '{"data":{"message":"manual-change"}}' kubectl -n kaas-gitops get configmap course-message -wЧто должно получиться. Значение вернулось из Git после сверки. Заверши наблюдение Ctrl+C. Запиши время и состояние Application.
Если результат отличается
Нет возврата: проверь automated.selfHeal, conditions и revision. Не считай наличие Application доказательством успешной синхронизации.
Найди точный источник
Сопоставь применённый коммит и путь с файлом. Для настоящего выпуска фиксируют проверенный коммит, а не неопределённое «последнее».
kubectl -n argocd get application kaas-course -o jsonpath='{.status.sync.revision}{"\n"}{.spec.source.path}{"\n"}'Что должно получиться. Есть конкретный идентификатор версии и имя владельца конфигурации.
Если результат отличается
Если revision пустой, синхронизация ещё не подтверждена.
Повтори на canary
На отдельном стенде прогони своё изменение версий и манифестов, затем проверки приложения, сети и тома. Запиши фактический результат, включая неуспех.
kubectl --context kind-kaas-lab get nodesЧто должно получиться. Есть отдельный протокол проверки; ручной drift на общей лабе не выдан за обновление Kubernetes.
Если результат отличается
Если canary отсутствует, сначала выполни подготовку отдельного стенда.
Останови управление и очисти
Сначала удали только учебную Application, затем её AppProject и namespace. У Application намеренно нет каскадного finalizer; удаление namespace уберёт оставшуюся учебную конфигурацию.
kubectl -n argocd delete application kaas-course kubectl -n argocd delete appproject kaas-course kubectl delete namespace kaas-gitopsЧто должно получиться. Учебный контроллер больше не восстанавливает ConfigMap; baseline и остальные приложения на месте.
Если результат отличается
Не удаляй namespace argocd и общий репозиторный Secret.
Открыть терминал ↗ · Скачать файлы лаборатории →
Файлы и подготовка к этой работе
Критерии готовности
Отмечай только то, что проверил на указанном стенде. Эти галочки сохраняются в браузере. Для готовых упражнений зачёт выдаёт отдельная серверная проверка практикума; остальные задания подтверждай журналом и доказательствами. Учебная модель не заменяет реальный облачный опыт.
Что сохранить в портфолио
- Журнал: исходное состояние → команда или действие → ожидаемый результат → фактическое наблюдение.
- Доказательства по критериям ниже: очищенный от секретов вывод, схема или ссылка на проверенный коммит.
- Отдельный список: что пока не запускалось, почему и какой стенд нужен для продолжения.
Проверь понимание
8 вопросов по этому модулю. Проходной результат — 7 из 8. После ответа — объяснения и ссылки на разделы, к которым стоит вернуться.
Пройти тест модуляОфициальные источники
Чек-листы уроков, заметки к ним и результаты тестов хранятся в этом браузере; для переноса используй экспорт. Автоматические проверки и журнал практикума сохраняются отдельно на сервере.