Архитектура Kubernetes и устройство кластера

После модуля вы сможете объяснить путь запроса от kubectl до контейнера, разделить ответственность Control Plane и Worker Node и наблюдать reconciliation на локальном кластере kind.

• Control Plane хранит и согласует желаемое состояние
• Worker Nodes выполняют workloads
• Kubernetes API — контракт между пользователем и компонентами
• Pod — минимальная планируемая единица

Kubernetes — система управления desired state. Пользователь записывает spec через API Server, контроллеры сравнивают его с actual state и создают изменения, пока состояние не совпадёт.

Декларативная модель описывает результат, а не последовательность ручных действий. Reconciliation выполняется непрерывно и поэтому компенсирует удаление или отказ отдельных экземпляров.

kube-apiserver выполняет authentication, authorization и admission, проверяет объект и работает с etcd. etcd хранит состояние API. kube-scheduler выбирает Node для неназначенного Pod, а kube-controller-manager запускает control loops.

Компоненты координируются через Kubernetes API. Недоступность API Server блокирует новые изменения, но уже запущенные процессы на Nodes не обязаны немедленно остановиться.

kubelet наблюдает назначенные своему Node PodSpecs и через CRI управляет container runtime. Runtime загружает images и запускает containers; сетевой плагин реализует связность, а kube-proxy или его замена — сервисную маршрутизацию.

Docker не является обязательным runtime Kubernetes. Современный kubelet использует CRI-совместимые runtime, обычно containerd или CRI-O.

kubectl отправляет HTTPS-запрос в API Server. После проверки объект сохраняется, контроллер создаёт зависимые объекты, scheduler назначает Pod, kubelet запускает sandbox и контейнеры. Status и Events возвращают наблюдаемое состояние в API.

spec — намерение пользователя, status — наблюдение системы. Смешивать их при диагностике нельзя.

• Перед практикой проверьте docker, kind и kubectl; текущий context должен быть kind-course
• Выполняйте команды группами и после каждой формулируйте ожидаемое изменение
• Не разбирайте табличный вывод в автоматизации: используйте JSON, jsonpath или Go template
• Сначала собирайте evidence через get, describe и events, затем меняйте ресурс
• Локальный kind-кластер учебный и не моделирует HA Control Plane или production storage

Сохраните конфигурацию как kind.yaml. Она создаёт один control-plane и один worker Node.

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: course
nodes:
  - role: control-plane
  - role: worker

kind create cluster --config kind.yaml
kubectl cluster-info --context kind-course
kubectl get nodes -o wide
kubectl get pods -n kube-system -o wide
kubectl get --raw /readyz?verbose
kubectl api-resources

Проверьте Ready у обоих Nodes, системные Pods и успешный ответ /readyz. Не продолжайте, пока базовое состояние не объяснимо.

Создайте Deployment, удалите управляемый Pod и наблюдайте его замену. Затем измените desired replicas с одной на три.

kubectl create namespace lab-architecture
kubectl create deployment web --image=nginx:1.28-alpine -n lab-architecture
kubectl rollout status deployment/web -n lab-architecture --timeout=120s
kubectl get deployment,replicaset,pod -n lab-architecture -o wide
kubectl delete pod -n lab-architecture -l app=web
kubectl get pods -n lab-architecture -w
kubectl scale deployment/web -n lab-architecture --replicas=3
kubectl wait -n lab-architecture --for=condition=Available deployment/web --timeout=120s

Готово, когда Deployment Available, существуют три Ready Pod, а удалённый UID заменён новым.

Намеренно задайте отсутствующий image tag. Timeout rollout здесь ожидаем: он доказывает, что новая ReplicaSet не стала Available.

kubectl set image deployment/web nginx=nginx:does-not-exist -n lab-architecture
kubectl rollout status deployment/web -n lab-architecture --timeout=30s
kubectl get pods -n lab-architecture
kubectl describe deployment web -n lab-architecture
kubectl events -n lab-architecture --types=Warning
kubectl rollout undo deployment/web -n lab-architecture
kubectl rollout status deployment/web -n lab-architecture --timeout=120s
kubectl delete namespace lab-architecture
kind delete cluster --name course

Диагностическая цепочка: scope и context → объект контроллера → Pod Conditions → container state → Warning Events → минимальное обратимое исправление.

• Почему scheduler не запускает контейнеры сам?
• Чем spec отличается от status?
• Что сохранится при недоступном API Server?
• Почему удалённый Pod Deployment появляется снова?
• Чем containerd отличается от Docker в контексте kubelet?

Минимум команд: kubectl cluster-info, get nodes, get pods -A, describe, events, logs. Модуль освоен, если вы без подсказки прослеживаете путь kubectl → API Server → controller → scheduler → kubelet → runtime и подтверждаете каждый этап данными.