აღწერეთ Kubernetes-ის არქიტექტურა: control plane vs worker node-ები და მათი კომპონენტები.

Question

IT Interview Practice · Accepted Answer

Kubernetes-ის კლასტერს ორი სახის მანქანა აქვს: **control plane** ("ტვინი", რომელიც გადაწყვეტილებებს იღებს და მდგომარეობას ინახავს) და **worker node-ები** (სადაც თქვენი Pod-ები რეალურად მუშაობენ). თითოეულს კარგად განსაზღვრული კომპონენტების მცირე ნაკრები აქვს.

## საერთო სურათი

```text
┌──────────────── CONTROL PLANE (the brain) ────────────────┐
│                                                            │
│   kube-apiserver ── the front door; ALL comms go through it│
│        │                                                   │
│   etcd ───────── key-value store: the cluster's SOURCE OF  │
│                  TRUTH (all objects & desired state)       │
│   kube-scheduler ── decides WHICH node a new Pod runs on   │
│   controller-manager ── runs control loops (reconcilers)   │
└──────────────────────────┬─────────────────────────────────┘
                           │ (apiserver)
   ┌───────────────────────┼───────────────────────┐
┌──┴─── WORKER NODE ──┐ ┌──┴─── WORKER NODE ──┐  ...
│ kubelet             │ │ kubelet             │
│ kube-proxy          │ │ kube-proxy          │
│ container runtime   │ │ container runtime   │
│  └ Pods (your apps) │ │  └ Pods (your apps) │
└─────────────────────┘ └─────────────────────┘
```

## Control plane-ის კომპონენტები

```text
kube-apiserver        The single entry point. Exposes the REST API; validates &
                      persists objects to etcd. kubectl, controllers, and kubelets
                      all talk ONLY to the apiserver.
etcd                  Distributed, consistent key-value store. Holds the ENTIRE
                      cluster state (desired + current). Lose etcd = lose the cluster.
kube-scheduler        Watches for Pods with no node assigned and picks the best node
                      (based on resource requests, affinity, taints, etc.).
kube-controller-      Runs the control loops: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints, etc. Each loop drives actual → desired.
cloud-controller-     (On cloud) integrates with the provider: load balancers, routes,
manager               node lifecycle.
```

## Worker node-ის კომპონენტები

```text
kubelet          The node agent. Talks to the apiserver, starts/stops containers via
                 the runtime, and reports Pod & node status. It makes the node's
                 reality match the Pods assigned to it.
kube-proxy       Programs the node's networking (iptables/IPVS) so that Service virtual
                 IPs are load-balanced to the right Pod endpoints.
container runtime The software that actually runs containers (containerd, CRI-O).
```

## როგორ მიედინება "kubectl apply" სისტემაში

```text
1. kubectl → kube-apiserver: "I want a Deployment with 3 replicas"
2. apiserver validates & writes the object to etcd
3. controller-manager (deployment→replicaset controller) sees it, creates 3 Pod objects
4. scheduler sees 3 unassigned Pods, assigns each to a node (writes back via apiserver)
5. each node's kubelet sees its Pods, tells the runtime to pull images & start containers
6. kube-proxy wires up Service networking so traffic reaches the new Pods
Everything is a WATCH + RECONCILE loop mediated by the apiserver.
```

```bash
kubectl get nodes                 # node-ების სია (control-plane + worker-ები)
kubectl get pods -n kube-system   # control-plane / system კომპონენტების ნახვა
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** აპროგრამებს ქსელს ისე, რომ Service-ის ვირტუალური IP-ები სწორ Pod-ებზე მარშრუტდებოდეს, ხოლო **container runtime** (containerd, CRI-O) რეალურად უშვებს კონტეინერებს. იმის დანახვა, თუ როგორ მიედინება ერთი `kubectl apply` ამ სისტემაში — apiserver-იდან etcd-მდე, კონტროლერები ქმნიან ობიექტებს, scheduler ათავსებს Pod-ებს, kubelet-ები უშვებენ კონტეინერებს, kube-proxy აწყობს ქსელს, ყველაფერი watch-and-reconcile მარყუჟებად — ცხადყოფს პლატფორმის უკან მდგარ ელეგანტურ, თანმიმდევრულ დიზაინს. ეს აზრობრივი მოდელი სწორედ ის არის, რაც გჭირდებათ იმის debug-ისთვის, თუ რატომ არის Pod გაჭედილი Pending-ში (scheduler), რატომ არ პასუხობს კლასტერი (apiserver/etcd) ან რატომ არ მარშრუტდება Service (kube-proxy), რაც მას შეუცვლელს ხდის რეალური კლასტერების ოპერირებისა და პრობლემების აღმოფხვრისთვის.

საერთო სურათი

Control plane-ის კომპონენტები

Worker node-ის კომპონენტები

როგორ მიედინება "kubectl apply" სისტემაში

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები