# Как выбрать упражнение

Начинай каждый модуль с блока «Где выполнять задания». Готовые Deployment, сеть и диагностика открываются в /labs; их готовит и проверяет портал. Диски, права и GitOps используют отдельные учебные namespaces. Портал допускает один активный терминал.

Python-модель работает локально в домашнем каталоге и не создаёт облачных ресурсов. Опасные опыты с нодами, etcd, сетевым плагином и Cluster API выполняются только на отдельной машине. Ниже её подготовка.

# Отдельный стенд из терминала портала

Этот файл нужен для экспериментов с нодами, сетью, etcd и общими типами ресурсов.
Обычные задания Deployment, сети и диагностики открываются прямо в /labs.

## 1. Где выполнять команды

Терминал портала подключён к 192.168.0.12. Это действующий кластер.
Для опасных опытов нужна **отдельная одноразовая VM (Virtual Machine — виртуальная машина)**:
например, Ubuntu 24.04 x86_64, от 4 ядер, 12 GiB (гибибайт) памяти и 40 GiB диска.
Это ориентир для небольшого опыта, не обещание достаточности для OpenStack-кластера.
Машина должна иметь выход к официальным реестрам и быть доступна с 192.168.0.12.
Не используй адреса существующих управляющих нод.

Запиши её адрес и пользователя. В портальном терминале выполни, заменив оба значения:

```bash
ssh <ПОЛЬЗОВАТЕЛЬ>@<АДРЕС_НОВОЙ_VM>
hostname
ip -br address
```

SSH (Secure Shell — протокол защищённого удалённого доступа) попросит подтвердить ключ
новой машины. Сверь отпечаток с её консолью, не отключай проверку.
После подключения ты всё ещё работаешь в браузере, но команды выполняются уже на новой машине.
`exit` возвращает к терминалу 192.168.0.12.

**Дальнейшие команды этого файла выполняются только внутри новой VM.**
Если отдельной машины ещё нет, остановись здесь. Теорию, расчёты и локальную Python-модель
можно изучать раньше; практический критерий опасного опыта пока не отмечается.

## 2. Инструменты и отдельная конфигурация

Установи Docker Engine по официальной инструкции Ubuntu:
https://docs.docker.com/engine/install/ubuntu/
Используй именно команды для выбранной версии системы. Не запускай случайные установочные скрипты.
Проверь `docker info`; команда должна успешно выполняться твоим учебным пользователем.
Членство в группе docker даёт широкие права на эту одноразовую VM.

Установи kubectl по официальной инструкции с проверкой SHA-256:
https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/
Для воспроизводимого исторического учебного примера ниже используется Kubernetes 1.33.4.
Выбирай kubectl с поддерживаемой разницей версий. Это не рекомендация версии для новой услуги.

Установи Helm по официальному руководству:
https://helm.sh/docs/intro/install/

Kind (Kubernetes in Docker — Kubernetes в контейнерах Docker) создаёт учебные ноды-контейнеры.
Ниже зафиксирован выпуск v0.30.0 и его официальный образ, а не «самый новый» выпуск.
Перед новым реальным проектом выбери поддерживаемую пару из актуальных release notes:
https://github.com/kubernetes-sigs/kind/releases/tag/v0.30.0

На x86_64:

```bash
umask 077
mkdir -p ~/kaas-sandbox/bin
cd ~/kaas-sandbox
curl -fSLo bin/kind https://kind.sigs.k8s.io/dl/v0.30.0/kind-linux-amd64
curl -fSLo kind.sha256sum https://github.com/kubernetes-sigs/kind/releases/download/v0.30.0/kind-linux-amd64.sha256sum
EXPECTED=$(awk '{print $1}' kind.sha256sum)
printf '%s  bin/kind\n' "$EXPECTED" | sha256sum -c -
chmod 700 bin/kind
export PATH="$HOME/kaas-sandbox/bin:$PATH"
export KUBECONFIG="$HOME/kaas-sandbox/kubeconfig"
kind version
kubectl config get-contexts
```

Если проверка суммы неуспешна — не запускай файл.
Новый KUBECONFIG отделяет доступы учебной машины от существующей лабы.
В новом терминале повтори два export: переменные не переносятся между вкладками.
Не копируй сюда административный kubeconfig общего кластера.

## 3. Обычный учебный кластер и образ

Сравни диапазоны адресов в файле с `ip route` и сетями облака.
CIDR (Classless Inter-Domain Routing — запись диапазона с длиной префикса)
не должен пересекаться с доступными через VM сетями.

```bash
cd ~/kaas-sandbox
curl -fSLo kind-lab.yaml https://test.igorhome.ru/static/learning/kind-lab.yaml
cat kind-lab.yaml
ip route
kind create cluster --name kaas-lab --config kind-lab.yaml --image kindest/node:v1.33.4@sha256:25a6018e48dfcaee478f4a59af81157a437f15e6e140bf103f85a2e7cd0cbbf2 --wait 180s
kubectl --context kind-kaas-lab create namespace kaas-lab
curl -fSLo Dockerfile https://test.igorhome.ru/static/learning/Dockerfile
docker build -t kaas-demo:v1 .
kind load docker-image kaas-demo:v1 --name kaas-lab
kubectl --context kind-kaas-lab -n kaas-lab apply -f https://test.igorhome.ru/static/learning/demo.yaml
kubectl --context kind-kaas-lab -n kaas-lab rollout status deployment/demo --timeout=120s
```

Ожидается две готовые копии demo. Если загрузка образа не удалась, исправь доступ к реестру.
Для воспроизводимого проекта дополнительно закрепи базовый образ Dockerfile по digest.

Портал допускает один активный терминал. Запусти перенаправление порта в фоне,
проверь ответ и останови только созданный процесс в этом же сеансе:

```bash
kubectl --context kind-kaas-lab -n kaas-lab port-forward service/demo 18081:80 --address 127.0.0.1 </dev/null >forward.log 2>&1 &
FORWARD_PID=$!
sleep 2
curl -fsS http://127.0.0.1:18081
kill "$FORWARD_PID"
wait "$FORWARD_PID" 2>/dev/null || true
```

Ожидается kaas-demo v1. Если соединение не установлено, прочитай forward.log.

### Обновление приложения v1 → v2

Сначала проверь ответ v1 как выше и останови перенаправление порта.
Измени только учебную строку, собери второй образ и загрузи его в ноды:

```bash
sed 's/kaas-demo v1/kaas-demo v2/' Dockerfile > Dockerfile.v2
docker build -f Dockerfile.v2 -t kaas-demo:v2 .
kind load docker-image kaas-demo:v2 --name kaas-lab
kubectl --context kind-kaas-lab -n kaas-lab set image deployment/demo web=kaas-demo:v2
kubectl --context kind-kaas-lab -n kaas-lab rollout status deployment/demo --timeout=120s
kubectl --context kind-kaas-lab -n kaas-lab get pods -o wide
```

Снова запусти блок перенаправления порта, запрос и остановку процесса.
Теперь ожидается kaas-demo v2. Сохрани оба ответа.
Это проверка до и после обновления, а не непрерывное измерение отсутствия простоя.
Для возврата конфигурации используй set image с kaas-demo:v1 и повтори проверку.

## 4. Отдельная сеть с политиками

Не устанавливай второй сетевой плагин в kaas-lab или общий кластер.
Для сетевого опыта сначала удали только свой обычный стенд:
`kind delete cluster --name kaas-lab`.
Так ты не держишь несколько тяжёлых кластеров одновременно.

```bash
curl -fSLo kind-network-lab.yaml https://test.igorhome.ru/static/learning/kind-network-lab.yaml
kind create cluster --name kaas-net --config kind-network-lab.yaml --image kindest/node:v1.33.4@sha256:25a6018e48dfcaee478f4a59af81157a437f15e6e140bf103f85a2e7cd0cbbf2
```

Ноды пока NotReady: стандартный CNI (Container Network Interface — интерфейс подключения
контейнеров к сети) выключен. Это ожидаемо.
Выбери выпуск Cilium, поддерживающий эту версию Kubernetes, по официальной инструкции:
https://docs.cilium.io/en/stable/installation/kind/
Если текущий Cilium уже не поддерживает 1.33, сначала выбери новую совместимую пару
kind/Kubernetes из официальных выпусков. Не устанавливай заведомо несовместимый плагин.

Замени значение версии, затем установи только в kind-kaas-net:

```bash
helm repo add cilium https://helm.cilium.io/
helm repo update
CILIUM_VERSION=<ПРОВЕРЕННАЯ_ВЕРСИЯ>
helm --kube-context kind-kaas-net install cilium cilium/cilium --version "$CILIUM_VERSION" --namespace kube-system --set ipam.mode=kubernetes
kubectl --context kind-kaas-net -n kube-system rollout status daemonset/cilium --timeout=180s
kubectl --context kind-kaas-net wait --for=condition=Ready nodes --all --timeout=180s
kubectl --context kind-kaas-net create namespace kaas-lab
kind load docker-image kaas-demo:v1 --name kaas-net
kubectl --context kind-kaas-net -n kaas-lab apply -f https://test.igorhome.ru/static/learning/demo.yaml
kubectl --context kind-kaas-net -n kaas-lab rollout status deployment/demo --timeout=120s
```

Создай два клиента, используя тот же подготовленный образ:

```bash
kubectl --context kind-kaas-net -n kaas-lab run allowed --image=kaas-demo:v1 --labels=role=client --command -- python -c 'import time; time.sleep(3600)'
kubectl --context kind-kaas-net -n kaas-lab run blocked --image=kaas-demo:v1 --labels=role=other --command -- python -c 'import time; time.sleep(3600)'
kubectl --context kind-kaas-net -n kaas-lab wait --for=condition=Ready pod/allowed pod/blocked --timeout=120s
```

До политики обе команды должны успешно получить страницу:

```bash
kubectl --context kind-kaas-net -n kaas-lab exec allowed -- python -c 'import urllib.request; print(urllib.request.urlopen("http://demo",timeout=3).read().decode())'
kubectl --context kind-kaas-net -n kaas-lab exec blocked -- python -c 'import urllib.request; print(urllib.request.urlopen("http://demo",timeout=3).read().decode())'
```

Примени network-policy.yaml из урока и повтори обе команды:
allowed получает страницу, blocked завершается ошибкой или таймаутом.
Если оба проходят — изоляция не доказана. Если оба не проходят — разрешение тоже не доказано.
Запиши исходный и конечный результаты.

## 5. Стенд для большинства etcd

После очистки предыдущего одноразового кластера:

```bash
curl -fSLo kind-ha-lab.yaml https://test.igorhome.ru/static/learning/kind-ha-lab.yaml
kind create cluster --name kaas-ha --config kind-ha-lab.yaml --image kindest/node:v1.33.4@sha256:25a6018e48dfcaee478f4a59af81157a437f15e6e140bf103f85a2e7cd0cbbf2 --wait 180s
kubectl --context kind-kaas-ha get nodes
```

Пять контейнеров на одной VM — модель голосования, не физическая HA (High Availability — высокая доступность).
Остановка участников и копии описаны в ha-restore.md.

## 6. Очистка и возвращение

Удаляй только созданный тобой именованный кластер, например:

```bash
kind delete cluster --name kaas-net
kind get clusters
exit
hostname
```

После exit ты снова на портальной ноде. Прежде чем выполнять следующие команды,
проверь место работы и контекст. Копии и журналы сохраняются отдельно от удаляемого кластера.