From 8f431e47980c963a0f601adb586c5f0b898c871c Mon Sep 17 00:00:00 2001 From: Tot Maxim Date: Sat, 18 Jul 2026 00:45:48 +0300 Subject: [PATCH] =?UTF-8?q?=D0=94=D0=BE=D1=80=D0=B0=D0=B1=D0=BE=D1=82?= =?UTF-8?q?=D0=BA=D0=B0=20=D1=83=D1=80=D0=BE=D0=BA=D0=B0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- stack/kubernetes/LEARNING.md | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/stack/kubernetes/LEARNING.md b/stack/kubernetes/LEARNING.md index 0c294a2..4ed01b4 100644 --- a/stack/kubernetes/LEARNING.md +++ b/stack/kubernetes/LEARNING.md @@ -6,7 +6,7 @@ **Формат каждого модуля:** зачем это → теория-минимум → практика руками → самопроверка → как это в реальных проектах. -**Окружение курса** (одно на все модули, то же, что в CASE.md): Windows + Docker Desktop, кластер `kind` с именем `lab`, 1 control-plane + 2 worker. Не пересоздавай кластер между модулями без необходимости — большинство модулей продолжают работать в одном и том же кластере и в одних и тех же namespace (`demo`, `monitoring`), это ближе к тому, как выглядит реальная работа с уже существующим кластером. +**Окружение курса** (одно на все модули, то же, что в CASE.md): Windows + Docker Desktop, кластер `kind` с именем `lab`, 1 control-plane + 2 worker. Все команды курса — в bash-синтаксисе (heredoc, `base64 -d`, настоящий `curl`), поэтому выполнять их нужно в **Git Bash** (ставится вместе с Git for Windows), а не в PowerShell/cmd — там половина команд не сработает или сработает иначе (`curl` в PowerShell — алиас на `Invoke-WebRequest`). Docker Desktop стоит выделить не меньше 8 ГБ RAM — иначе стек мониторинга из модуля 12 повиснет в Pending. Не пересоздавай кластер между модулями без необходимости — большинство модулей продолжают работать в одном и том же кластере и в одних и тех же namespace (`demo`, `monitoring`), это ближе к тому, как выглядит реальная работа с уже существующим кластером. --- @@ -60,20 +60,25 @@ helm version ```bash kind create cluster --name lab -kubectl run demo --image=nginxdemos/hello --restart=Always +# создаём под через Deployment — контроллер, который будет поддерживать desired state +# (голый `kubectl run demo --image=...` создал бы под без контроллера — его никто бы не пересоздал) +kubectl create deployment demo --image=nginxdemos/hello kubectl get pods -# демо self-healing: убиваем под руками -kubectl delete pod demo +# демо self-healing: убиваем под руками (имя вида demo-<хэш> — взять из вывода выше) +kubectl delete pod <имя-пода> kubectl get pods -# NAME ... — под пересоздан автоматически (другой RESTARTS/AGE), потому что desired state требует, чтобы под существовал +# под пересоздан автоматически с новым именем, потому что desired state требует, чтобы существовала 1 реплика + +# уборка — дальше в курсе работаем в отдельном namespace +kubectl delete deployment demo ``` ### Самопроверка - Своими словами: что такое desired state и чем декларативный подход отличается от «выполнить команду»? -- Почему после `kubectl delete pod demo` под появился снова? +- Почему после `kubectl delete pod <имя>` под появился снова — и почему с другим именем? -*(Забегая вперёд: на самом деле голый `kubectl run` пересоздаётся не всегда — это будет явно разобрано в модуле 4 про Deployment. Здесь цель — просто увидеть идею self-healing на практике.)* +*(Забегая вперёд: пересоздал под не «Kubernetes вообще», а конкретный контроллер — Deployment. Голый под, созданный через `kubectl run`, не пересоздаст никто — за него никто не отвечает. Иерархия Deployment → ReplicaSet → Pod подробно разобрана в модуле 4; здесь цель — просто увидеть идею self-healing на практике.)* ### Как это в реальных проектах @@ -195,7 +200,7 @@ kubectl -n demo delete pod demo-pod # удалить ### Как это в реальных проектах -Голые Pod'ы в проде почти никогда не создают напрямую (кроме короткоживущих задач) — если под упадёт, его никто не пересоздаст, потому что за него никто не отвечает (в отличие от модуля 1, где `kubectl run` создавал под через неявный контроллер). Правильный способ — через Deployment, это модуль 4. +Голые Pod'ы в проде почти никогда не создают напрямую (кроме короткоживущих задач) — если под упадёт, его никто не пересоздаст, потому что за него никто не отвечает (в отличие от модуля 1, где под был создан через Deployment и контроллер его пересоздал). Правильный способ — через Deployment, это модуль 4. ---