Kubernetes для Python-бэкенд-разработчика

Незнакомый термин? Откройте словарь Kubernetes и терминов курса.

Практический курс от первой модели Kubernetes API до рабочей нагрузки FastAPI, ориентированной на промышленную эксплуатацию. Текст рассчитан на пользователя Linux: необходимые технические термины, команды, ключи YAML и буквальный вывод оставлены на английском, объяснения даны по-русски.

Срез исследования: 2026-07-29. Последняя стабильная версия Kubernetes: v1.36.2. Учебный кластер: kind v0.32.0 с закреплённым образом kindest/node:v1.36.1@sha256:3489c7674813ba5d8b1a9977baea8a6e553784dab7b84759d1014dbd78f7ebd5. Разница в исправляющих версиях не нарушает правила совместимости; точный образ опубликован самим kind. Проверенная среда создания: Ubuntu 24.04.3 LTS, Linux 6.8.0-88-generic, x86_64. Изначально на машине не было kubectl, kind, Docker/Podman и Helm; для автономной проверки во /tmp был загружен и проверен по SHA-256 только kubectl v1.36.2. Среда исполнения контейнеров и работающий кластер по-прежнему отсутствуют; точная граница проверенного описана в конце.

Что здесь построено

Один сервис python-api развивается от отдельного Pod до безопасного, масштабируемого Deployment. Исходник находится в app/, манифесты — в manifests/, конфигурация kind — в cluster/kind-config.yaml. Единые имена:

Предварительные знания

Нужны уверенное владение командной оболочкой Linux, процессы, TCP/HTTP/DNS, основы веб-сервиса Python, YAML и образ контейнера на уровне build, run, реестра и тегов. Отдельного курса по Docker здесь нет. Желательно 4 CPU, 8 GiB RAM и 20 GiB свободного места. 00-diagnostic-and-local-cluster.md содержит предварительную проверку установки без изменения чужого kubeconfig.

Измеримые результаты

После курса вы сможете:

1. Нарисовать путь запроса через сервер API и объяснить согласование.
2. Выбрать Pod, Deployment, Job, StatefulSet или DaemonSet по эксплуатационному контракту.
3. Развернуть python-api, проверить Service, EndpointSlice, DNS и локальный путь HTTP.
4. Предсказать последствия проверок, запросов/лимитов ресурсов, параметров rollout, PDB и ограничений планирования.
5. Выдать рабочей нагрузке только минимальные разрешения RBAC и выполнить Pod Security restricted.
6. Диагностировать минимум восемь отказов на основе status, Events, журналов и сетевых доказательств и доказательств хранилища.
7. Собрать наложения Kustomize, описать компромиссы Helm/GitOps и провести rollback.
8. Защитить эксплуатационный проект и ответить на вопросы собеседования без «магических» формулировок.

Карта курса

Полный путь занимает примерно 66–83 часа, включая итоговый проект. Время — активная практика; загрузка образов и чтение дополнительных источников не включены.

Зависимости глав

flowchart LR
    C00[00 локальный кластер] --> C01[01 модель API]
    C01 --> C02[02 нагрузки]
    C02 --> C03[03 конфигурация]
    C02 --> C04[04 сеть]
    C02 --> C05[05 хранилище]
    C03 --> C06[06 исправность/ресурсы]
    C04 --> C06
    C05 --> C06
    C06 --> C07[07 доступность]
    C06 --> C08[08 безопасность]
    C07 --> C09[09 диагностика]
    C08 --> C09
    C09 --> C10[10 управление конфигурацией]
    C10 --> C11[11 эксплуатация]
    C07 --> L90[90 лабораторные]
    C08 --> L90
    C09 --> L90
    C11 --> L91[91 итоговый проект]
    L90 --> L91
    L91 --> I92[92 собеседование/резюме]
    I92 --> S93[93 контрольный список]

Можно проходить 03–05 параллельно после 02. Не начинайте 07–09 до 06: иначе rollout и доказательства отказов будут выглядеть как набор флагов без причинной модели.

Диагностический тест

Ответьте без запуска команд. За каждую полностью объяснённую позицию — 1 балл.

1. Чем контейнер отличается от Pod?
2. Кто создаёт новый Pod после удаления Pod, принадлежащего Deployment?
3. Что является источником истины: YAML-файл, объект в API или текущий процесс?
4. Почему Service продолжает работать после замены всех Pod?
5. Что произойдёт с трафиком при провале проверки readiness? А при liveness?
6. Чем запрос CPU отличается от лимита CPU?
7. Почему echo c2VjcmV0 | base64 -d доказывает, что base64 не шифрование?
8. Где искать причину Pending: в журналах приложения или Events? Почему?
9. Что защищает PDB, а что он не защищает?
10. Разрешает ли Role читать ресурсы во всех namespaces?
11. Почему принятый Ingress может не маршрутизировать трафик?
12. Как доказать несовпадение селектора?
13. Можно ли считать kubectl apply --dry-run=client полной проверкой API?
14. В каком порядке обновляют kube-apiserver и kubelet?
15. Чем доступность Kubernetes отличается от корректности приложения?

Интерпретация: 0–4 — идти последовательно; 5–9 — главы 00–02 прочитать быстро, лабораторные выполнять полностью; 10–12 — начать с самостоятельной задачи в конце каждой главы; 13–15 — использовать курс как аудит пробелов промышленной эксплуатации. Проверочные тезисы: контроллер выполняет согласование; объект API — источник истины кластера; readiness убирает endpoint, liveness перезапускает контейнер; запрос ресурсов участвует в планировании, лимит задаёт верхнюю границу среды исполнения; PDB действует на добровольный eviction, но не на отказ узла; Role ограничена namespace; Ingress требует контроллер; клиентский dry-run не выполняет admission и серверную схему; плоскость управления обновляется раньше kubelet.

Два маршрута

Job-ready — 35–45 часов

Пройти 00–09, затем лабораторные 1–10 из главы 90, итоговый проект до уровня job-ready, главы 92 и 93. Допустимо обзорно прочитать Helm/GitOps и эксплуатацию управляемого кластера. Критерий: самостоятельно развернуть сервис, провести rollout/rollback и расследовать шесть сценариев за 90 минут, объясняя доказательства.

Production-ready — 66–83 часа

Все главы и лабораторные, включая drain нескольких узлов, NetworkPolicy с поддерживающим её CNI, конвейер метрик и HPA, наложения Kustomize, модель угроз, SLO и регламент, упражнение по обновлению и устареванию и все упражнения с отказами. Критерий — уровень production-ready по итоговому проекту и воспроизводимый пакет доказательств.

Последовательные лабораторные работы

Команды, ожидаемые результаты, восстановление и очистка находятся в 90-kubectl-labs.md. Ожидаемый вывод задаёт форму и инвариант, а не обещание побайтового совпадения отметок времени, UID и IP.

Почему kind

kind (Kubernetes IN Docker) создаёт узлы как контейнеры, быстро пересоздаётся, поддерживает многоузловую топологию и хорошо подходит для CI. Это позволяет изучить scheduler, drain и загрузку образов без отдельной виртуальной машины на каждый узел. В v0.32.0 доступен проверенный образ узла v1.36.1. Цена выбора: среда исполнения контейнеров обязательна; сеть, хранилище и маршрутизация хоста по умолчанию не равны промышленному облаку; NetworkPolicy требует совместимого CNI; Ingress и LoadBalancer требуют контроллера или дополнения, например cloud-provider-kind.

Альтернатива — minikube: удобнее, если нужны готовые дополнения ingress и metrics-server или несколько драйверов. Работа с дополнениями там проще для одиночной рабочей станции разработчика, но часть платформенных зависимостей становится менее заметной. Команды курса оптимизированы для kind, не смешивайте контексты.

Правило безопасной работы

Перед каждым изменением:

kubectl config current-context
test "$(kubectl config current-context)" = "kind-kube-course"
kubectl diff -k manifests/overlays/dev

Если test возвращает не 0, остановитесь. Все команды namespace явно используют -n kube-course. Не применяйте сломанные манифесты в чужом кластере. Очистка сначала удаляет namespace и объекты курса, затем только кластер с точным именем: kind delete cluster --name kube-course.

Критерии завершения

Курс завершён, когда есть не отметки «прочитал», а артефакты:

• сохранены kubectl version, сведения об узлах, StorageClass, CNI и предварительная проверка метрик;
• сервис отвечает, а Service имеет готовые EndpointSlices;
• проведены и объяснены обновление конфигурации, rollout, rollback и корректное завершение;
• для Pending, CrashLoopBackOff, ImagePullBackOff, проверки, селектора, DNS/политики, OOM и PVC есть доказательство → гипотеза → проверка → исправление → повторная проверка;
• положительная и отрицательная проверки RBAC дают ожидаемые разрешение и запрет;
• kubectl kustomize детерминирован, клиентский и серверный dry-run успешны;
• итоговый проект содержит диаграмму, решения по безопасности и хранилищу, PDB/HPA, точки наблюдаемости, rollback и регламент;
• проверочный список 93 заполнен командами и выводом, а не самооценкой;
• вы можете за 10 минут объяснить путь запроса и две главные области отказа.

Что проверено при создании курса

Фактически выполнены:

• компиляция Python и контрольная HTTP-проверка приложения: конфигурация, endpoints /health/live и /health/ready, состояние, нагрузка, метрики Prometheus и переход readiness в 503 после drain;
• разбор всех 33 YAML-файлов и 38 YAML-блоков в Markdown;
• детерминированный рендеринг обоих наложений через проверенный kubectl v1.36.2 (Kustomize v5.8.1);
• строгая проверка схемы через kubeconform v0.7.0 и официальные схемы Kubernetes v1.36.2: наложения — 22/22 корректны; базовый набор, лабораторные и сломанные сценарии — 25 корректны, 0 некорректных, 1 пропущен (Kustomization);
• внутренние ссылки Markdown, ссылки на манифесты и patches, обязательные файлы, отсутствие :latest, cluster-admin и привилегированного режима в развёртываемых ресурсах;
• HTTP-доступность всех 103 внешних URL источников и выпусков на дату исследования.

kubectl apply --dry-run=client без обнаружения API и серверного dry-run здесь невозможны: даже клиентское применение пытается получить сведения от сервера API. Сборка контейнера, admission и лабораторные в работающем кластере также не выполнялись из-за отсутствия среды исполнения и кластера. Поэтому ожидаемый вывод в главах — явно помеченное поведение, а не запись фактического запуска кластера. Повторяемый протокол проверки дан в 00, 90 и 91.

Начните с диагностики и локального кластера.