Kubernetes: Deployment, Service, probes и rollout

Этот урок начинается с нуля. Незнакомое слово здесь не считается вашим пробелом: мы сначала создадим образ, затем дадим точное значение и только потом применим его.

Где мы находимся

Полётное повторение. В прошлом уроке была опора desired code → plan/diff → approve → apply → state; repeat → no surprise. Не подглядывая, назовите её четыре звена и только затем сравните с записью.

Результат урока

Читаем манифесты CloudLab, строим их через Kustomize и наблюдаем безопасное обновление и откат. Не переходите дальше, пока не можете объяснить, что проверяет каждая команда и какой отказ она обнаруживает.

Сначала знакомый образ

Представьте сеть пекарен. Центральный план требует три работающих точки — это Deployment. Каждая точка — Pod. Единый номер заказов — Service. Проверка «можно ли принимать заказ?» — readiness probe. Постепенная замена старых точек новыми — rollout.

Аналогия помогает начать рассуждение, но не заменяет устройство технологии. Ниже мы уточним каждое слово.

Опорный сигнал урока

Deployment wants Pods → Service finds ready Pods → probes steer traffic → rollout changes gradually

Прочитайте цепочку слева направо. Она отвечает не на вопрос «какую команду запомнить», а на вопрос «почему следующий шаг следует из предыдущего».

Новые слова простыми словами

• Kubernetes — Система, которая постоянно приводит контейнерные приложения к описанному состоянию.
• Pod — Минимальная запускаемая группа одного или нескольких тесно связанных контейнеров.
• Deployment — Контроллер желаемого числа Pod и стратегии обновления.
• Service и probe — Service даёт стабильный вход; probe сообщает, какой Pod готов или жив.

Разбираем без спешки

Deployment управляет желаемым числом Pod и обновлением, Service даёт стабильный адрес, probes управляют трафиком и перезапуском, ConfigMap отделяет открытую конфигурацию. PersistentVolumeClaim сохраняет данные, но один локальный JSON-файл не становится распределённой базой: учебный Deployment оставляет одну реплику.

Сейчас не нужно запоминать формулировку дословно. Найдите в ней причинную связь и привяжите её к опорному сигналу выше.

Сначала предскажите результат

До запуска ответьте на бумаге: что должно измениться, что должно остаться прежним и какой вывод команды подтвердит ваш прогноз? Даже неверный прогноз полезен, если после опыта вы можете объяснить расхождение.

Опыт маленькими шагами

Выполните команды из корня course/cloud-devops-lab. Команды рассчитаны на учебную среду. Перед командой, меняющей сервер или данные, прочитайте её целиком и проверьте текущий каталог. Запускайте блок по одной смысловой группе. После каждой остановитесь и сопоставьте результат со своим прогнозом.

kubectl kustomize deploy/k8s >/tmp/cloudlab-k8s.yaml
grep -n 'kind: Deployment[|]readinessProbe[|]runAsNonRoot[|]resources:' /tmp/cloudlab-k8s.yaml
printf 'With a local cluster: kubectl apply -k deploy/k8s\n'
printf 'Then: kubectl -n cloudlab rollout status deployment/cloudlab\n'

Эталонные файлы проекта.

Что именно делает этот опыт

kubectl kustomize сначала собирает итоговый YAML локально. Поиск проверяет ключевые части, а client-side dry-run просит Kubernetes разобрать объект без создания. Только после понимания манифеста можно применять его к учебному кластеру.

Что должно получиться

• Собранный YAML содержит probes и securityContext.
• Команда завершается предсказуемым кодом.
• Результат можно повторить на чистой среде.

Соберите целое по опорной схеме

Проведите пальцем или карандашом по четырём блокам и расскажите весь урок одним связным объяснением.

Воспроизведите без подсказки

1. Закройте схему и нарисуйте четыре блока по памяти.
2. Объясните каждый переход словами «потому что».
3. Дайте определение одному новому термину, не повторяя текст дословно.
4. Назовите один сигнал, который доказывает результат.

Найдите и исправьте ошибку

Ошибка: «Kubernetes автоматически делает любое приложение отказоустойчивым». Исправление: он выполняет описанные правила, но плохие probes, единый диск или ошибка приложения сохраняются.

Задание

Теперь соберите тот же смысл самостоятельно. Можно смотреть на опорную схему; цель — не экзамен на память, а воспроизводимый результат.

Обязательное. Напишите POSIX sh-проверку, которая строит Kustomize YAML, требует наличие Deployment, Service, readinessProbe и runAsNonRoot: true, затем запускает client-side dry-run. Отправьте только команды или скрипт POSIX sh без реальных ключей и токенов.

Критерии готовности

• Вы понимаете каждую запускаемую строку.
• Повторный запуск даёт ожидаемый результат или безопасно объяснённое отличие.
• В выводе нет настоящих ключей, токенов и паролей.
• Вы можете показать факт, который подтверждает успех.

Если проверка не прошла, зафиксируйте ожидаемое и фактическое, вернитесь к одному разорванному звену опоры и повторите. Ошибка не отнимает у вас право продолжать обучение.

По желанию. Запишите один возможный отказ и сигнал, по которому вы его заметите.

Открытая перспектива

Следующий урок добавит новую опору: Наблюдаемость, резервная копия и учебный инцидент.

Оглавление курса