Aprašykite Kubernetes architektūrą: control plane vs. worker node'ai ir jų komponentai.

Question

IT Interview Practice · Accepted Answer

Kubernetes klasteris turi dviejų rūšių mašinas: **control plane** („smegenys", priimančios sprendimus ir saugančios būseną) ir **worker node'us** (kur iš tikrųjų veikia jūsų Pod'ai). Kiekvienas turi nedidelį aiškiai apibrėžtų komponentų rinkinį.

## Bendras vaizdas

```text
┌──────────────── CONTROL PLANE (smegenys) ─────────────────┐
│                                                            │
│   kube-apiserver ── pagrindinės durys; VISAS ryšys eina pro│
│        │                                                   │
│   etcd ───────── key-value saugykla: klasterio TIESOS      │
│                  ŠALTINIS (visi objektai ir pageidaujama būsena)│
│   kube-scheduler ── nusprendžia, ant KURIO node veikia Pod'as│
│   controller-manager ── vykdo valdymo ciklus (reconcilers) │
└──────────────────────────┬─────────────────────────────────┘
                           │ (apiserver)
   ┌───────────────────────┼───────────────────────┐
┌──┴─── WORKER NODE ──┐ ┌──┴─── WORKER NODE ──┐  ...
│ kubelet             │ │ kubelet             │
│ kube-proxy          │ │ kube-proxy          │
│ container runtime   │ │ container runtime   │
│  └ Pod'ai (jūsų app)│ │  └ Pod'ai (jūsų app)│
└─────────────────────┘ └─────────────────────┘
```

## Control plane komponentai

```text
kube-apiserver        Vienintelis įėjimo taškas. Atveria REST API; validuoja ir
                      išsaugo objektus į etcd. kubectl, controller'iai ir kubelet'ai
                      kalbasi TIK su apiserver.
etcd                  Paskirstyta, nuosekli key-value saugykla. Laiko VISĄ
                      klasterio būseną (pageidaujamą + dabartinę). Prarasti etcd = prarasti klasterį.
kube-scheduler        Stebi Pod'us be priskirto node ir parenka geriausią node
                      (pagal resource requests, affinity, taints ir t. t.).
kube-controller-      Vykdo valdymo ciklus: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints ir t. t. Kiekvienas ciklas stumia faktinę → pageidaujamą.
cloud-controller-     (Cloud'e) integruojasi su tiekėju: load balancers, routes,
manager               node gyvavimo ciklas.
```

## Worker node komponentai

```text
kubelet          Node agentas. Kalbasi su apiserver, paleidžia/stabdo konteinerius per
                 runtime ir praneša Pod'ų bei node būseną. Jis derina node
                 tikrovę su jam priskirtais Pod'ais.
kube-proxy       Programuoja node tinklą (iptables/IPVS), kad Service virtualūs
                 IP būtų subalansuoti į tinkamus Pod'ų endpoint'us.
container runtime Programinė įranga, faktiškai paleidžianti konteinerius (containerd, CRI-O).
```

## Kaip „kubectl apply" teka per sistemą

```text
1. kubectl → kube-apiserver: "Noriu Deployment'o su 3 replikomis"
2. apiserver validuoja ir įrašo objektą į etcd
3. controller-manager (deployment→replicaset controller) tai mato, sukuria 3 Pod objektus
4. scheduler mato 3 nepriskirtus Pod'us, kiekvieną priskiria node (įrašo atgal per apiserver)
5. kiekvieno node kubelet mato savo Pod'us, liepia runtime parsisiųsti image'us ir paleisti konteinerius
6. kube-proxy sujungia Service tinklą, kad srautas pasiektų naujus Pod'us
Viskas yra WATCH + RECONCILE ciklas, tarpininkaujamas apiserver.
```

```bash
kubectl get nodes                 # išvardyti node'us (control-plane + workers)
kubectl get pods -n kube-system   # matyti control-plane / sistemos komponentus
kubectl get componentstatuses     # pagrindinių control-plane dalių būklė
```

## Kodėl tai svarbu

Supratimas apie padalijimą tarp control plane ir worker node'ų — bei kiekvieno komponento vaidmenį — būtent ir paverčia Kubernetes iš „juodosios dėžės" į sistemą, apie kurią galite samprotauti ir kurią galite eksploatuoti, tad tai yra esminė žinia bet kuriam middle-lygio ar aukštesniam inžinieriui. **Control plane** yra sprendimus priimančios smegenys: **kube-apiserver** yra vienintelės pagrindinės durys, per kurias bendrauja kiekvienas komponentas ir naudotojas; **etcd** yra nuosekli key-value saugykla, laikanti visą klasterio būseną ir esanti tiesos šaltiniu (jos praradimas reiškia klasterio praradimą); **scheduler** nusprendžia, ant kurio node atsiduria kiekvienas naujas Pod'as; o **controller-manager** vykdo derinimo ciklus, nuolat stumiančius faktinę būseną link pageidaujamos. Kiekviename **worker node** **kubelet** yra agentas, derinantis node konteinerius su jam priskirtais Pod'ais, **kube-proxy** programuoja tinklą, kad Service virtualūs IP nukreiptų į tinkamus Pod'us, o **container runtime** (containerd, CRI-O) faktiškai paleidžia konteinerius. Matymas, kaip vienas `kubectl apply` teka per šią sistemą — apiserver į etcd, controller'iai kuria objektus, scheduler talpina Pod'us, kubelet'ai paleidžia konteinerius, kube-proxy jungia tinklą, viskas kaip watch-and-reconcile ciklai — atskleidžia elegantišką, nuoseklų platformos dizainą. Būtent šis mąstymo modelis ir reikalingas, kad ištaisytumėte, kodėl Pod'as įstrigo Pending būsenoje (scheduler), kodėl klasteris nereaguoja (apiserver/etcd) ar kodėl Service nemaršrutizuoja (kube-proxy), todėl jis nepakeičiamas eksploatuojant ir šalinant realių klasterių problemas.

Bendras vaizdas

Control plane komponentai

Worker node komponentai

Kaip „kubectl apply" teka per sistemą

Kodėl tai svarbu

Susiję klausimai