Опишите архитектуру Kubernetes: control plane против worker node и их компоненты.

Question

IT Interview Practice · Accepted Answer

Кластер Kubernetes состоит из двух видов машин: **control plane** ("мозг", который принимает решения и хранит состояние) и **worker node** (где фактически работают ваши Pod). У каждого есть небольшой набор чётко определённых компонентов.

## Общая картина

```text
┌──────────────── CONTROL PLANE (мозг) ─────────────────────┐
│                                                            │
│   kube-apiserver ── парадная дверь; ВСЯ связь идёт через неё│
│        │                                                   │
│   etcd ───────── key-value хранилище: ИСТОЧНИК ИСТИНЫ       │
│                  кластера (все объекты и желаемое состояние)│
│   kube-scheduler ── решает, на КАКОМ node запустить новый Pod│
│   controller-manager ── выполняет циклы управления (reconcilers)│
└──────────────────────────┬─────────────────────────────────┘
                           │ (apiserver)
   ┌───────────────────────┼───────────────────────┐
┌──┴─── WORKER NODE ──┐ ┌──┴─── WORKER NODE ──┐  ...
│ kubelet             │ │ kubelet             │
│ kube-proxy          │ │ kube-proxy          │
│ container runtime   │ │ container runtime   │
│  └ Pods (ваши apps) │ │  └ Pods (ваши apps) │
└─────────────────────┘ └─────────────────────┘
```

## Компоненты control plane

```text
kube-apiserver        Единственная точка входа. Предоставляет REST API; валидирует и
                      сохраняет объекты в etcd. kubectl, контроллеры и kubelet
                      общаются ТОЛЬКО с apiserver.
etcd                  Распределённое, консистентное key-value хранилище. Хранит ВСЁ
                      состояние кластера (желаемое + текущее). Потеря etcd = потеря кластера.
kube-scheduler        Следит за Pod без назначенного node и выбирает лучший node
                      (по resource requests, affinity, taints и т.д.).
kube-controller-      Выполняет циклы управления: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints и т.д. Каждый цикл ведёт фактическое → желаемое.
cloud-controller-     (В облаке) интегрируется с провайдером: load balancers, маршруты,
manager               жизненный цикл node.
```

## Компоненты worker node

```text
kubelet          Агент node. Общается с apiserver, запускает/останавливает контейнеры
                 через runtime и сообщает статус Pod и node. Он приводит реальность
                 node в соответствие с назначенными ему Pod.
kube-proxy       Программирует сеть node (iptables/IPVS), чтобы виртуальные IP Service
                 балансировались на нужные endpoints Pod.
container runtime ПО, которое фактически запускает контейнеры (containerd, CRI-O).
```

## Как "kubectl apply" проходит через систему

```text
1. kubectl → kube-apiserver: "Хочу Deployment с 3 репликами"
2. apiserver валидирует и записывает объект в etcd
3. controller-manager (deployment→replicaset controller) видит его, создаёт 3 объекта Pod
4. scheduler видит 3 неназначенных Pod, назначает каждый на node (записывает обратно через apiserver)
5. kubelet каждого node видит свои Pod, велит runtime скачать образы и запустить контейнеры
6. kube-proxy настраивает сеть Service, чтобы трафик достигал новых Pod
Всё — это цикл WATCH + RECONCILE, опосредованный apiserver.
```

```bash
kubectl get nodes                 # список node (control-plane + workers)
kubectl get pods -n kube-system   # посмотреть компоненты control-plane / системы
kubectl get componentstatuses     # здоровье ключевых частей control-plane
```

## Почему это важно

Понимание разделения между control plane и worker node — и роли каждого компонента — это то, что превращает Kubernetes из чёрного ящика в систему, о которой можно рассуждать и которой можно управлять, поэтому это ключевое знание для любого инженера уровня middle и выше. **Control plane** — это принимающий решения мозг: **kube-apiserver** — единственная парадная дверь, через которую общаются все компоненты и пользователи; **etcd** — консистентное key-value хранилище, содержащее всё состояние кластера и являющееся источником истины (его потеря означает потерю кластера); **scheduler** решает, на какой node попадёт каждый новый Pod; а **controller-manager** выполняет циклы согласования, непрерывно ведущие фактическое состояние к желаемому. На каждом **worker node** **kubelet** — это агент, который приводит контейнеры node в соответствие с назначенными ему Pod, **kube-proxy** программирует сеть, благодаря которой виртуальные IP Service маршрутизируются на нужные Pod, а **container runtime** (containerd, CRI-O) фактически запускает контейнеры. Наблюдение за тем, как единственный `kubectl apply` проходит через эту систему — apiserver к etcd, контроллеры создают объекты, scheduler размещает Pod, kubelet запускают контейнеры, kube-proxy настраивает сеть, всё в виде циклов watch-and-reconcile, — раскрывает элегантный, консистентный дизайн платформы. Именно эта ментальная модель нужна, чтобы отладить, почему Pod застрял в Pending (scheduler), почему кластер не отвечает (apiserver/etcd) или почему Service не маршрутизирует (kube-proxy), что делает её незаменимой для эксплуатации и устранения неполадок в реальных кластерах.

Общая картина

Компоненты control plane

Компоненты worker node

Как "kubectl apply" проходит через систему

Почему это важно

Похожие вопросы