Περίγραψε την αρχιτεκτονική του Kubernetes: control plane έναντι worker nodes και τα components τους.

Question

IT Interview Practice · Accepted Answer

Ένα cluster Kubernetes έχει δύο είδη μηχανημάτων: το **control plane** (το «μυαλό» που παίρνει αποφάσεις και αποθηκεύει την κατάσταση) και τους **worker nodes** (όπου πραγματικά τρέχουν τα Pods σου). Καθένα έχει ένα μικρό σύνολο σαφώς καθορισμένων components.

## Η μεγάλη εικόνα

```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) │
└─────────────────────┘ └─────────────────────┘
```

## Components του 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.
```

## Components του 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                 # λίστα των nodes (control-plane + workers)
kubectl get pods -n kube-system   # δες τα components του control-plane / συστήματος
kubectl get componentstatuses     # υγεία των βασικών κομματιών του control-plane
```

## Γιατί έχει σημασία

Η κατανόηση του διαχωρισμού μεταξύ control plane και worker nodes — και του ρόλου κάθε component — είναι αυτό που μετατρέπει το Kubernetes από ένα μαύρο κουτί σε ένα σύστημα που μπορείς να συλλογιστείς και να χειριστείς, οπότε είναι βασική γνώση για κάθε μηχανικό επιπέδου middle και πάνω. Το **control plane** είναι το μυαλό που παίρνει τις αποφάσεις: το **kube-apiserver** είναι η μοναδική είσοδος μέσα από την οποία επικοινωνεί κάθε component και χρήστης· το **etcd** είναι το συνεπές key-value store που κρατά ολόκληρη την κατάσταση του cluster και είναι η πηγή αλήθειας (χάνοντάς το σημαίνει να χάσεις το cluster)· ο **scheduler** αποφασίζει σε ποιον node προσγειώνεται κάθε νέο Pod· και ο **controller-manager** τρέχει τα loops εναρμόνισης που οδηγούν συνεχώς την πραγματική κατάσταση προς την επιθυμητή. Σε κάθε **worker node**, το **kubelet** είναι ο agent που κάνει τα containers του node να ταιριάζουν με τα Pods που του έχουν ανατεθεί, το **kube-proxy** προγραμματίζει το networking που κάνει τα virtual IPs των Services να δρομολογούνται στα σωστά Pods, και ένα **container runtime** (containerd, CRI-O) τρέχει πραγματικά τα containers. Το να βλέπεις πώς ένα μόνο `kubectl apply` ρέει μέσα από αυτό το σύστημα — apiserver προς etcd, controllers που δημιουργούν objects, scheduler που τοποθετεί Pods, kubelets που ξεκινούν containers, kube-proxy που καλωδιώνει το networking, όλα ως loops παρακολούθησης-και-εναρμόνισης — αποκαλύπτει τον κομψό, συνεπή σχεδιασμό πίσω από την πλατφόρμα. Αυτό το νοητικό μοντέλο είναι ακριβώς αυτό που χρειάζεσαι για να κάνεις debug γιατί ένα Pod κόλλησε σε Pending (scheduler), γιατί το cluster δεν αποκρίνεται (apiserver/etcd), ή γιατί ένα Service δεν δρομολογεί (kube-proxy), κάνοντάς το απαραίτητο για τη λειτουργία και την αντιμετώπιση προβλημάτων πραγματικών clusters.

Η μεγάλη εικόνα

Components του control plane

Components του worker node

Πώς ένα "kubectl apply" ρέει μέσα από το σύστημα

Γιατί έχει σημασία

Σχετικές ερωτήσεις