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

Живой журнал, а не справочник — обновляется в конце каждой сессии по курсу. Цель: за 30 секунд понять, где остановился, и продолжить без перечитывания всего [LEARNING.md](LEARNING.md). Окружение и бенчмарки — в [SERVER.md](SERVER.md), построчный разбор каждой выполненной команды (что делает каждый аргумент, что значит ответ) — в [COMMANDS.md](COMMANDS.md), как запустить/остановить/проверить стенд между сессиями — в [USAGE.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](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](SERVER.md) — окружение, бенчмарки, адаптации курса под сервер по модулям.
- Создан [COMMANDS.md](COMMANDS.md) — построчный разбор каждой выполненной команды этой сессии (задача → аргументы → ответ → значение), чтобы можно было повторить любой шаг самостоятельно.

Осталось на следующую сессию:
- Начать с **модуля 2** — пересоздать кластер `lab` с топологией 1 control-plane + 2 worker через `kind-config.yaml`. **Важно**: сразу добавить `extraPortMappings` (8080→80, 8443→443) из [SERVER.md](SERVER.md#модуль-2--топология-кластера), чтобы не пересоздавать кластер повторно в модуле 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](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](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](COMMANDS.md) #28.
- Пройден базовый набор команд: `get pods [-o wide]`, `describe pod` (разобрана секция `Events` как таймлайн действий control-plane/kubelet), `logs` (вывод самого nginx), `exec -it ... -- sh` (интерактивный вход внутрь контейнера). Разбор — [COMMANDS.md](COMMANDS.md) #29.
- Разобран `kubectl get pod -o yaml` построчно: чем ~120 строк реального объекта отличаются от 12 строк исходного манифеста (служебные поля metadata, дефолты в spec, целиком раздел status как runtime-состояние от kubelet) — основа declarative-модели K8s (`spec` = желаемое, `status` = фактическое). Разбор — [COMMANDS.md](COMMANDS.md) #30.
- Под удалён (`kubectl delete pod`) — наглядно показано отсутствие self-healing у голого Pod без контроллера сверху (в отличие от Deployment в модуле 1). Разбор — [COMMANDS.md](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](../docker/CASE.md) → раздел 9.
- **Перед каждой сессией курса** сверяться с чек-листом [«CI-инфраструктура на сервере — что нельзя ломать»](SERVER.md#ci-инфраструктура-на-сервере--что-нельзя-ломать) в SERVER.md — там же актуальный список занятых портов (3000/3030/222/4400/9090).