Kubernetes আর্কিটেকচার বর্ণনা করুন: control plane বনাম worker node ও তাদের উপাদানসমূহ।

Question

IT Interview Practice · Accepted Answer

একটি Kubernetes cluster-এ দুই ধরনের মেশিন থাকে: **control plane** (যে "মস্তিষ্ক" সিদ্ধান্ত নেয় ও state সংরক্ষণ করে) এবং **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 component দেখুন
kubectl get componentstatuses     # মূল control-plane অংশগুলোর স্বাস্থ্য
```

## এটি কেন গুরুত্বপূর্ণ

control plane ও worker node-এর মধ্যকার বিভাজন — এবং প্রতিটি উপাদানের ভূমিকা — বোঝাই Kubernetes-কে একটি ব্ল্যাক বক্স থেকে এমন একটি সিস্টেমে পরিণত করে যা নিয়ে আপনি যুক্তি করতে ও চালাতে পারেন, তাই এটি যেকোনো middle-বা-উপরের ইঞ্জিনিয়ারের জন্য মূল জ্ঞান। **control plane** হলো সিদ্ধান্ত-গ্রহণকারী মস্তিষ্ক: **kube-apiserver** হলো একমাত্র সামনের দরজা যার মাধ্যমে প্রতিটি উপাদান ও ব্যবহারকারী যোগাযোগ করে; **etcd** হলো সেই consistent key-value store যা সম্পূর্ণ cluster state ধরে রাখে এবং যা সত্যের উৎস (এটি হারানো মানে cluster হারানো); **scheduler** সিদ্ধান্ত নেয় প্রতিটি নতুন Pod কোন node-এ নামবে; এবং **controller-manager** সেই reconciliation loop চালায় যা অবিরত প্রকৃত state-কে desired state-এর দিকে চালিত করে। প্রতিটি **worker node**-এ, **kubelet** হলো সেই agent যা node-এর container-গুলোকে তার কাছে assign করা Pod-এর সাথে মেলায়, **kube-proxy** সেই networking প্রোগ্রাম করে যা Service virtual IP-কে সঠিক Pod-এ route করায়, এবং একটি **container runtime** (containerd, CRI-O) প্রকৃতপক্ষে container চালায়। একটি একক `kubectl apply` কীভাবে এই সিস্টেমের মধ্য দিয়ে প্রবাহিত হয় তা দেখা — apiserver থেকে etcd, controller object তৈরি করছে, scheduler Pod বসাচ্ছে, kubelet container শুরু করছে, kube-proxy networking জুড়ছে, সবই watch-and-reconcile loop হিসেবে — প্ল্যাটফর্মের পেছনের মার্জিত, সামঞ্জস্যপূর্ণ design প্রকাশ করে। এই মানসিক মডেলই ঠিক যা আপনার দরকার debug করতে কেন একটি Pod Pending-এ আটকে আছে (scheduler), কেন cluster অসাড় (apiserver/etcd), বা কেন একটি Service route করছে না (kube-proxy), যা বাস্তব cluster পরিচালনা ও সমস্যা-সমাধানের জন্য অপরিহার্য করে তোলে।

বড় ছবি

Control plane উপাদানসমূহ

Worker node উপাদানসমূহ

একটি "kubectl apply" কীভাবে সিস্টেমের মধ্য দিয়ে প্রবাহিত হয়

এটি কেন গুরুত্বপূর্ণ

সম্পর্কিত প্রশ্ন