resume/stack/kubernetes/PROGRESS.md

Прогресс прохождения курса Kubernetes

Живой журнал, а не справочник — обновляется в конце каждой сессии по курсу. Цель: за 30 секунд понять, где остановился, и продолжить без перечитывания всего LEARNING.md. Окружение и бенчмарки — в SERVER.md, построчный разбор каждой выполненной команды (что делает каждый аргумент, что значит ответ) — в COMMANDS.md, как запустить/остановить/проверить стенд между сессиями — в USAGE.md; сюда их не дублировать.

Статус модулей

Модуль	Тема	Статус	Дата
0	Установка инструментов	✅ Пройден	18-07-2026
1	Зачем вообще Kubernetes	✅ Пройден (как смоук-тест наладки)	18-07-2026
2	Архитектура кластера	✅ Пройден	18-07-2026
3	Pod и kubectl-база	✅ Пройден	18-07-2026
4	Deployment и ReplicaSet	⬜ Не начат
5	Service и сеть	⬜ Не начат
6	Ingress	⬜ Не начат
7	ConfigMap и Secret	⬜ Не начат
8	Probes и ресурсы	⬜ Не начат
9	Диагностика поломок	⬜ Не начат
10	Хранилище: PV, PVC, StatefulSet	⬜ Не начат
11	Helm, часть 1 — пользователь чартов	⬜ Не начат
12	Helm, часть 2 — автор чарта	⬜ Не начат
13	Как это устроено в реальных проектах	⬜ Не начат
—	Выходной контроль (QUESTIONS.md + 2 схемы)	⬜ Не начат

Лог по датам

18-07-2026 — наладка окружения на сервере + модуль 0 + модуль 1

Сделано:

• Сервер totserver@192.168.31.163 обновлён (apt upgrade), перезагружен, добавлены sysctl-лимиты inotify (524288/512) для kind.
• Установлены kind v0.32.0 и helm v3.21.3 в ~/.local/bin (без sudo). kubectl уже был через snap (1.35.6), docker уже стоял (обновился до 29.6.2 при апгрейде).
• Сняты бенчмарки CPU/RAM/диска и практический замер подъёма kind-кластера — см. SERVER.md. Вердикт: сервер тянет весь курс с запасом.
• Поднят кластер kind create cluster --name lab (1-нодовый, дефолтный) — пройдена практика модуля 1: self-healing пода через Deployment продемонстрирован (под пересоздался с новым именем после kubectl delete pod).
• Deployment demo удалён после демонстрации (как требует практика модуля 1).
• Проверено: Gitea/Postgres/file-server не пострадали от ребута и от работы kind-кластера рядом (все healthy, отвечают на запросы).
• Создан SERVER.md — окружение, бенчмарки, адаптации курса под сервер по модулям.
• Создан COMMANDS.md — построчный разбор каждой выполненной команды этой сессии (задача → аргументы → ответ → значение), чтобы можно было повторить любой шаг самостоятельно.

Осталось на следующую сессию:

• Начать с модуля 2 — пересоздать кластер lab с топологией 1 control-plane + 2 worker через kind-config.yaml. Важно: сразу добавить extraPortMappings (8080→80, 8443→443) из SERVER.md, чтобы не пересоздавать кластер повторно в модуле 6.

Затыки: нет (модуль 0 и смоук-тест прошли гладко).

18-07-2026 — модуль 2: архитектура кластера

Формат сессии новый: команды на сервере выполнял сам, мне присылались логи шаг за шагом — я вёл по шагам и разбирал вывод.

Сделано:

• Кластер lab пересоздан с топологией 1 control-plane + 2 worker через ~/k8s/kind-config.yaml, сразу с extraPortMappings 8080→80/8443→443 (адаптация из SERVER.md) — все 3 ноды Ready за 46-57с. Разбор команд — COMMANDS.md #24-26.
• Вживую найдены и разобраны все 4 компонента control-plane (kube-apiserver, etcd, kube-controller-manager, kube-scheduler — все на lab-control-plane) и оба DaemonSet'а (kindnet, kube-proxy — по одному поду на каждую из 3 нод); coredns опознан как обычный Deployment (2 реплики), а не DaemonSet. Разбор — COMMANDS.md #27.
• Устная самопроверка модуля 2 (компоненты control-plane/worker, кворум etcd) пройдена развёрнуто и верно. Дополнительно самостоятельно разобрана разница iptables/nftables применительно к режимам kube-proxy (сверх программы модуля 2, пригодится в модуле 5).
• CI-стек Gitea проверен перед началом — все 4 контейнера Up/healthy, не задет.

Осталось на следующую сессию:

• Модуль 3 — Pod и kubectl-база: создать pod.yaml (Namespace demo + Pod demo-pod), пройти базовый набор команд (get, describe, logs, exec, -o yaml, delete).

Затыки: нет, модуль 2 прошёл гладко.

18-07-2026 — модуль 3: Pod и kubectl-база

Формат сессии тот же: команды на сервере выполнял сам, логи присылались шаг за шагом.

Сделано:

• Создан ~/k8s/pod.yaml (Namespace demo + Pod demo-pod, образ nginxdemos/hello:latest), применён — под ушёл в Running на lab-worker за ~7с (время скачивания образа). Разбор — COMMANDS.md #28.
• Пройден базовый набор команд: get pods [-o wide], describe pod (разобрана секция Events как таймлайн действий control-plane/kubelet), logs (вывод самого nginx), exec -it ... -- sh (интерактивный вход внутрь контейнера). Разбор — COMMANDS.md #29.
• Разобран kubectl get pod -o yaml построчно: чем ~120 строк реального объекта отличаются от 12 строк исходного манифеста (служебные поля metadata, дефолты в spec, целиком раздел status как runtime-состояние от kubelet) — основа declarative-модели K8s (spec = желаемое, status = фактическое). Разбор — COMMANDS.md #30.
• Под удалён (kubectl delete pod) — наглядно показано отсутствие self-healing у голого Pod без контроллера сверху (в отличие от Deployment в модуле 1). Разбор — COMMANDS.md #31.
• Устная самопроверка модуля 3 (4 ключа манифеста, logs vs describe, что добавляет -o yaml, плюс доп. вопрос про поведение при падении ноды) пройдена развёрнуто и верно.

Осталось на следующую сессию:

• Модуль 4 — Deployment и ReplicaSet: deployment.yaml (3 реплики), посмотреть, как Deployment управляет ReplicaSet, а ReplicaSet — подами.

Затыки: нет, модуль 3 прошёл гладко.

Состояние кластера прямо сейчас

• Кластер lab существует, топология модуля 2: 1 control-plane (lab-control-plane) + 2 worker (lab-worker, lab-worker2), создан через kind-config.yaml с extraPortMappings 8080→80/8443→443.
• Namespace demo существует (создан в модуле 3), но пуст — demo-pod был удалён по завершении практики модуля 3. Namespace monitoring — не создан.
• В кластере, кроме namespace demo, ничего не развёрнуто.

Открытые вопросы / затыки

Пока пусто — появятся, если самопроверка какого-то модуля не пройдёт с первого раза.

Вне периметра курса (не забыть)

• gitea_runner был в restart-loop (unregistered runner, обнаружено 18-07-2026 при проверке после ребута) — починено в тот же день (чистая перерегистрация). Дополнительно поднят второй CI-раннер gitea_runner_armhf (cross-builder для ARM) под реальный проект maxim/Pluto-SDR; все 4 CI-workflow зелёные. Разбор — ../docker/CASE.md → раздел 9.
• Перед каждой сессией курса сверяться с чек-листом «CI-инфраструктура на сервере — что нельзя ломать» в SERVER.md — там же актуальный список занятых портов (3000/3030/222/4400/9090).