Передача Kubernetes-проекта и границы восстановления
«Площадка» теперь описывает полный локальный путь: собственные API и frontend, управляемые копии, Service, конфигурацию, probes, ресурсы и наблюдение. Последний урок превращает набор файлов в передаваемый учебный проект. Основной результат — объяснить следующему разработчику, какое состояние считается текущим, как восстановить приложение и какие данные или внешние компоненты в эту гарантию не входят.
Курс подготовлен как локальный черновик. Автор не устанавливал зависимости, не собирал образы, не запускал Kubernetes и не выполнял тесты, HTTP-проверки или нагрузку. Этот статус сохранён в метаданных уроков, README примера и плане серии. Регламент ниже описывает будущие действия читателя и ожидаемые результаты, а не отчёт о состоявшемся развёртывании.
Передаём одно определённое состояние
У серии есть последовательные файлы, и не все их нужно применять одновременно. Ранний Deployment содержит только исходные порты; поздний сохраняет конфигурацию, probes и requests. Если другой разработчик применит весь каталог без чтения, результат начнёт зависеть от порядка файлов. Поэтому в README указан набор для текущего состояния и отдельные необязательные ветки.
Базовая передача включает namespace, Services, ConfigMap и учебный Secret, два Deployment из 07-resources.yaml и роль observer. Storage-demo остаётся отдельным примером, HPA требует Metrics API. Версия образа в текущем Deployment должна совпадать с принятой стадией: после урока rollout это может быть 2, после учебного отката — 1.
Не достаточно записать «используйте последние файлы». Нужно объяснить, какие файлы полные и какие описывают только независимые объекты. В нашем наборе Deployment-манифесты являются полными состояниями соответствующей стадии; Services и RBAC добавляют собственные ресурсы. Читатель получает возможность воспроизвести намерение без реконструкции всей истории автора.
Контекст kind-ploshchadka и namespace ploshchadka входят в регламент как адреса окружения. Они не являются производственными значениями, которые нужно заменить на неизвестный рабочий кластер. Самостоятельное применение начинается с проверки выбранного context. Ошибочная адресация может быть опаснее ошибки одного параметра приложения, поэтому она должна быть видимой в командах.
Исходники, артефакты и конфигурация
Полные исходники API и web позволяют собрать собственные образы. Передающий разработчик должен назвать артефакты и их происхождение: какие файлы вошли, какой базовый образ использован, какой тег обозначает код. В этом черновике нет выполненной сборки, поэтому не указываем выдуманный digest приложений или время успешного запуска.
Базовый node:24-alpine допускает изменение содержимого внутри основной ветки. Для будущей воспроизводимой сборки читатель фиксирует проверенный digest нужной архитектуры. Образ kind-узла уже закреплён по официальному релизу. Такие записи различаются по статусу: один digest известен из опубликованного источника, другой ещё должен быть определён в реальной процедуре сборки.
ConfigMap и Secret описывают окружение процессов, а не код. Релизный набор должен сохранять связь образа и параметров. Если поменять APP_VERSION независимо от image, текст ответа перестанет точно обозначать код. Поэтому handoff прямо объясняет ограничение этого учебного поля и необходимость читать фактическую декларацию образа при расследовании.
Учебный Secret содержит заведомо несекретную строку. В реальном проекте значения выдаются отдельным процессом, а исходники не становятся хранилищем действующих полномочий. Передача должна объяснять, кто имеет доступ к данным, как меняется значение и какой экземпляр уже получил его. В нашем примере смена окружения требует создания нового процесса.
Последовательность восстановления приложения
Для основного stateless API восстановление означает создать нужное число процессов из существующего образа и подключить их к известному Service. Каталог входит в исходники и образ, поэтому отдельного восстановления записей нет. Это конкретное свойство «Площадки», а не общее обещание Kubernetes сохранять данные любого приложения.
Диагностика начинается с Deployment и Pod. Затем проверяются события, готовность и адресаты Service. После этого читается журнал HTTP-процесса и пользовательский путь через web. Такая последовательность не обязательна для всех инцидентов, но она соответствует зависимостям нашего проекта и помогает избежать замены случайных компонентов.
Например, отсутствие нового образа обнаруживается до анализа JSON-контракта. Непройденная startupProbe объясняет, почему процесс перезапускается или не становится готовым. Пустой EndpointSlice указывает на проблему выбора адресатов. Ответ 404 после успешного соединения направляет внимание к маршруту. Каждое наблюдение сужает задачу вместо неопределённого «перезапустить всё».
Откат отдельно требует прежнего образа, совместимой конфигурации и совместимых данных. История Deployment не хранит слои образа и не возвращает содержимое ConfigMap. После оперативного rollback файл на диске также должен отражать выбранное состояние. Иначе следующий apply снова внесёт отменённый выпуск.
Данные и завершение локальной работы
У storage-demo есть самостоятельный PVC storage-note. Замена Pod с сохранённым claim может оставить учебную запись доступной. Удаление namespace или кластера имеет другую границу. Перед завершением лаборатории читатель решает, нужна ли запись, изучает reclaim policy и сохраняет данные вне зависимости от удаляемого окружения.
Нельзя назвать файл на том же ноутбуке полноценным аварийным восстановлением после потери этого ноутбука. Нужны отдельное место хранения копии и проверяемая процедура возврата. В этом наборе бэкап не выполнялся, поэтому handoff не содержит слов «проверенная резервная копия». Такое честное описание помогает следующему участнику определить необходимую работу.
Port-forward тоже входит в список временных компонентов. Он прекращается вместе с командой и может потребовать переподключения после смены выбранного Pod. Это ожидаемый способ локальной диагностики, а не отказ публичного сервиса. Публичный вход, DNS, TLS и контроллер Gateway API в базовой лаборатории не создавались.
При очистке удаляют только именованную лабораторию после решения о данных. Регламент не предлагает общей команды удаления всех namespace или чужих кластеров. Адресная операция позволяет связать последствия с известными ресурсами. Если лаборатория используется несколькими людьми, сначала нужен общий выбор владельца и времени завершения.
Какие задачи остаются для производственного проекта
Для рабочего сайта потребуются внешний вход, управление реальными секретами, централизованные журналы, метрики, резервные копии и выбранная модель данных. Надёжность при потере узла требует подходящего размещения и инфраструктуры. Эти задачи нельзя объявить выполненными по наличию трёх Pod на одном компьютере.
Однако учебная модель уже помогает обсуждать их предметно. Вы можете сказать, какие экземпляры взаимозаменяемы, какая зависимость общая, кто допускается к API управления и какое поле контроллер вправе изменять. Это более полезная отправная точка, чем большой YAML без объяснения ответственности.
Сопоставьте будущую проверку с пользовательским сценарием: HTML открывается, каталог возвращается через тот же origin, экземпляр готов до допуска трафика, новая версия совместима, а операционная документация описывает откат. Пока эти действия не выполнены, они остаются пунктами проверки. README и handoff.md сохраняют этот статус рядом с исходниками.
Оглавление «Kubernetes для веб-разработчика» связывает все этапы. На следующем самостоятельном проходе используйте конкретную стадию и фиксируйте наблюдения своей лаборатории: версии инструментов, фактическое состояние объектов и результат HTTP-сценария. Тогда подготовленный учебный проект станет основанием для действительно проверенного опыта.