3.3.1 · блок 3

Архитектура Kubernetes-кластера

Зачем это нужно

Docker Compose поднимает сервисы на одной машине. В продакшене десятки inference-подов, GPU-ноды, rolling update без даунтайма, самовосстановление при падении контейнера. Kubernetes (k8s) — оркестратор контейнеров: планирует, где запустить Pod, следит за здоровьем, масштабирует, подключает сеть и диски.

MLE и backend-разработчик не обязаны администрировать кластер, но обязаны понимать, куда попадает их Helm chart и почему Pod в CrashLoopBackOff.

Основные идеи

Control plane (управляющий слой). «Мозг» кластера:

kube-apiserver — единая точка входа API; все kubectl и контроллеры общаются с ним.
etcd — хранилище состояния кластера (desired state).
kube-scheduler — выбирает node для нового Pod.
kube-controller-manager — контроллеры (Deployment, ReplicaSet и др.) приводят фактическое состояние к желаемому.
cloud-controller-manager — интеграция с облаком (LB, volumes) — если есть.

Worker nodes. Машины, где крутятся ваши контейнеры:

kubelet — агент на node; получает от apiserver «запусти Pod» и дергает container runtime.
kube-proxy — сетевые правила для Service (балансировка).
Container runtime — containerd, CRI-O (Docker как runtime устарел в k8s).

Pod — минимальная единица. Не контейнер, а группа контейнеров с общим network namespace и optional shared volumes. Обычно один основной контейнер + sidecar (логи, mesh proxy).

Declarative model. Вы описыете YAML «хочу 3 реплики образа X»; контроллеры выравнивают реальность. kubectl apply -f deployment.yaml.

Namespace. Логическое разделение: dev, staging, prod, team-ml. Квоты, RBAC, изоляция имён.

kubectl — ваш интерфейс. get, describe, logs, exec, apply, delete. Контекст и namespace: kubectl config set-context ..., -n prod.

Как это выглядит на практике

Вы деплоите inference-сервис после Jenkins push образа scorer:128:


kubectl get nodes
kubectl get pods -n ml-prod
kubectl describe pod scorer-7f8b9c -n ml-prod

Если Pod Pending — scheduler не нашёл node (не хватает CPU/RAM, taints, нет GPU). Если ImagePullBackOff — неверный тег или нет доступа к registry.

На C4-диаграмме кластер — Container «Kubernetes platform»: внутри — ваш Deployment, Service, Ingress (позже Istio). Control plane обычно на отдельных VM; workers — пул для ML и системных DaemonSet (логи, мониторинг).

Путь ML-сервиса в курсе: Docker image → Jenkins push → Helm chart (values: image tag) → Pod на worker → Service → Ingress/mesh.

Что сделать после занятия

[ ] Выполните kubectl get componentstatuses или kubectl get --raw='/readyz?verbose' (зависит от версии) и выпишите, какие компоненты control plane вы видите.
[ ] Найдите Pod системного namespace (kube-system) и объясните, зачем он нужен.
[ ] Нарисуйте схему: developer → kubectl → apiserver → scheduler → kubelet → container.

Официальные материалы

Открыть интерактивную версию