Архітектура 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 і підтверджуєте кожен етап даними.