Kubernetes আর্কিটেকচার — কন্ট্রোল প্লেন ও নোড

Kubernetes architecture — control plane & nodes

৯ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এক নজরে · TL;DR

Kubernetes একাধিক মেশিন জুড়ে কন্টেইনার নির্ভরযোগ্যভাবে চালানোর সমস্যা সমাধান করে — ক্র্যাশ হওয়া কন্টেইনার স্বয়ংক্রিয়ভাবে পুনরায় চালু করা, ক্যাপাসিটি অনুযায়ী শিডিউল করা, স্কেল করা।
কন্ট্রোল প্লেন ("মস্তিষ্ক") চারটি মূল উপাদান নিয়ে গঠিত — API server, scheduler, controller manager ও etcd।
ওয়ার্কার নোড-এ আসল অ্যাপ্লিকেশন কন্টেইনার চলে — প্রতিটিতে একটি kubelet ও একটি container runtime থাকে।
Kubernetes-এর মূল দর্শন হলো reconciliation loop — actual অবস্থাকে ক্রমাগত desired অবস্থার সাথে মেলানো, যা L17-এর ডিক্লারেটিভ IaC ধারণারই একটি বাস্তবায়ন।

এই পাঠে যা শিখবেন

Kubernetes ঠিক কোন সমস্যা সমাধান করে এবং কেন একটি একক Docker হোস্ট যথেষ্ট নয়
কন্ট্রোল প্লেনের চারটি মূল উপাদান এবং প্রতিটির নির্দিষ্ট দায়িত্ব
ওয়ার্কার নোডে kubelet ও container runtime কীভাবে কাজ করে
reconciliation loop — Kubernetes-এর কেন্দ্রীয় দর্শন — একটি ছোট্ট Python সিমুলেশনের মাধ্যমে

১ · Kubernetes কোন সমস্যা সমাধান করে

M6-এ আমরা দেখেছি Docker একটি হোস্টে কন্টেইনার প্যাকেজ ও চালানোর সমস্যা সমাধান করে। কিন্তু বাস্তব প্রোডাকশন সিস্টেমে সাধারণত একটি মেশিন যথেষ্ট নয় — শত শত কন্টেইনার, বহু মেশিন জুড়ে চালাতে হয়। প্রশ্ন হলো — কোন কন্টেইনার কোন মেশিনে চলবে? একটি মেশিন ডাউন হলে সেই মেশিনের কন্টেইনারগুলো কে পুনরায় চালু করবে? ট্রাফিক বাড়লে কে নতুন কন্টেইনার তৈরি করবে? KubernetesKubernetes (K8s)একটি ওপেন-সোর্স কন্টেইনার অর্কেস্ট্রেশন প্ল্যাটফর্ম — মূলত Google-এ তৈরি, বহু মেশিন জুড়ে কন্টেইনার চালানো, স্কেল করা ও স্বয়ংক্রিয়ভাবে সুস্থ রাখার দায়িত্ব নেয়। (সংক্ষেপে K8s) ঠিক এই প্রশ্নগুলোর উত্তর দেয় — ক্র্যাশ হওয়া কন্টেইনার স্বয়ংক্রিয়ভাবে পুনরায় চালু করে, উপলব্ধ ক্ষমতা অনুযায়ী নতুন কন্টেইনার শিডিউল করে, চাহিদা অনুযায়ী স্কেল করে এবং নতুন ভার্সন নিরাপদে রোলআউট করে।

২ · কন্ট্রোল প্লেন — ক্লাস্টারের "মস্তিষ্ক"

একটি Kubernetes ক্লাস্টারের কন্ট্রোল প্লেনControl Planeক্লাস্টারের সিদ্ধান্ত-গ্রহণকারী অংশ — কোন পড কোথায় চলবে, বর্তমান অবস্থা কী, এবং সেই অবস্থাকে কাঙ্ক্ষিত অবস্থার সাথে কীভাবে মেলাতে হবে তা ঠিক করে। নিজে অ্যাপ্লিকেশন কন্টেইনার চালায় না — বরং সিদ্ধান্ত নেয় এবং ক্লাস্টারের স্বাস্থ্য বজায় রাখে। চারটি মূল উপাদান —

API Server
ক্লাস্টারের সব কমান্ডের "সামনের দরজা" — সব অনুরোধ (kubectl, অন্যান্য উপাদান, ইউজার) API server-এর মধ্য দিয়েই যায়।

Scheduler
নতুন পড তৈরি হলে কোন ওয়ার্কার নোডে সেটি চলবে তা ঠিক করে — উপলব্ধ CPU/মেমরি ক্যাপাসিটি বিবেচনায় নিয়ে।

Controller Manager
ক্রমাগত actual অবস্থাকে desired অবস্থার সাথে মেলায় — Kubernetes-এর মূল দর্শনের বাস্তবায়ন (নিচে দেখুন)।

etcd
ক্লাস্টারের সম্পূর্ণ অবস্থার ডেটাবেস — কী চলছে, কী চলা উচিত, সব কনফিগারেশন এখানে সংরক্ষিত থাকে।

৩ · ওয়ার্কার নোড — যেখানে কন্টেইনার আসলে চলে

ওয়ার্কার নোডWorker Nodeএকটি মেশিন (ভার্চুয়াল বা ফিজিক্যাল) যেখানে অ্যাপ্লিকেশনের আসল কন্টেইনার চলে — control plane-এর নির্দেশনা অনুযায়ী। হলো সেই মেশিন যেখানে আসল অ্যাপ্লিকেশন কন্টেইনার চলে। প্রতিটি ওয়ার্কার নোডে দুটি মূল উপাদান থাকে — একটি kubelet (control plane-এর সাথে যোগাযোগকারী এজেন্ট, নিশ্চিত করে যে সেই নোডে নির্ধারিত কন্টেইনারগুলো চলছে) এবং একটি container runtime (যেটি আসলে কন্টেইনার চালায়, M6-এর Docker-এর মতোই একটি রানটাইম)। একটি ক্লাস্টারে সাধারণত একাধিক ওয়ার্কার নোড থাকে, যাতে একটি নোড ডাউন হলেও বাকি নোডগুলো কাজ চালিয়ে যেতে পারে।

কন্ট্রোল প্লেন সিদ্ধান্ত নেয় ও অবস্থা মনে রাখে; ওয়ার্কার নোডগুলো সেই নির্দেশনা অনুযায়ী আসল কন্টেইনার চালায়।

৪ · রিকনসিলিয়েশন লুপ — Kubernetes-এর কেন্দ্রীয় দর্শন

L17-এ আমরা ডিক্লারেটিভ IaC-এর ধারণা দেখেছি — কাঙ্ক্ষিত চূড়ান্ত অবস্থা বর্ণনা করুন, টুল নিজে বুঝে নেবে কী পরিবর্তন দরকার। Controller Manager ঠিক এই দর্শনকেই বাস্তবায়ন করে, ক্রমাগতভাবে —

Reconciliation Loop

Controller Manager অবিরাম একটি লুপ চালায় — বর্তমানে actually কী চলছে তা পর্যবেক্ষণ করে, সেটাকে desired অবস্থার (আপনি API-তে যা ঘোষণা করেছেন) সাথে তুলনা করে, এবং পার্থক্য থাকলে ঠিক ততটুকু অ্যাকশন নেয় যতটুকু দরকার (নতুন পড তৈরি বা অতিরিক্ত পড বন্ধ) — কখনও পুরো সিস্টেম নতুন করে তৈরি করে না, শুধু ফাঁকটুকু বন্ধ করে। এই একই প্যাটার্ন পরবর্তী পাঠগুলোতে বারবার ফিরে আসবে — L28-এর self-healing Deployment, L32-এর অপারেটর, এমনকি L36-এর GitOps সিঙ্ক-এও এই একই যুক্তি প্রয়োগ হয়।

Python

# কন্ট্রোলার ম্যানেজারের reconciliation loop-এর একটি সরলীকৃত সিমুলেশন
# (fake in-memory ডেটা — বাস্তব kubectl/cluster-এর বিরুদ্ধে চলছে না)

def reconcile(desired_replicas, actual_running_pods):
    """desired ও actual-এর মধ্যে ফাঁক গণনা করে, তা বন্ধ করতে কী করতে হবে ঠিক করে।"""
    actual_count = len(actual_running_pods)
    shortfall = desired_replicas - actual_count
    actions = []

    if shortfall > 0:
        # নতুন id সবসময় সর্বোচ্চ বিদ্যমান সংখ্যার পরের থেকে শুরু হয় -- শুধু len()
        # ব্যবহার করলে মাঝখানের কোনো pod সরে গেলে (gap) নাম সংঘর্ষ হতে পারত।
        existing_numbers = [int(p.split("-")[1]) for p in actual_running_pods]
        next_number = max(existing_numbers, default=0) + 1
        for i in range(shortfall):
            new_id = f"pod-{next_number + i}"
            actions.append(("CREATE", new_id))
    elif shortfall < 0:
        to_remove = actual_running_pods[shortfall:]  # শেষের অতিরিক্ত পডগুলো
        for pod_id in to_remove:
            actions.append(("TERMINATE", pod_id))
    else:
        actions.append(("NO-OP", "already matches desired state"))

    return actions


scenarios = {
    "আন্ডার-প্রভিশনড (৩টি চলছে, ৫টি দরকার)": (5, ["pod-1", "pod-2", "pod-3"]),
    "ওভার-প্রভিশনড (৪টি চলছে, ২টি দরকার)": (2, ["pod-1", "pod-2", "pod-3", "pod-4"]),
    "ইতিমধ্যে মিলে গেছে": (3, ["pod-1", "pod-2", "pod-3"]),
}

for label, (desired, actual) in scenarios.items():
    print(f"--- {label} ---")
    for action, target in reconcile(desired, actual):
        print(f"  {action}: {target}")

লক্ষ্য করুন — reconcile() ফাংশনটি প্রতিবার শুধু ফাঁকটুকু বন্ধ করে, পুরো সিস্টেম নতুন করে তৈরি করে না। এটিই আসল Controller Manager প্রতি কয়েক সেকেন্ডে অবিরাম করে থাকে — এই একই লজিক আমরা L28-এ একটি Deployment অবজেক্টের ভেতরে বসিয়ে দেখব, যাতে ক্র্যাশ হওয়া পড স্বয়ংক্রিয়ভাবে প্রতিস্থাপিত হয়।

৫ · কন্ট্রোল প্লেন কি নিজে অ্যাপ চালায়?

সাধারণত না — বেশিরভাগ ক্লাস্টার কনফিগারেশনে কন্ট্রোল প্লেন শুধু "সিদ্ধান্ত গ্রহণ ও রেকর্ড রাখা"-র দায়িত্বে থাকে, আসল অ্যাপ্লিকেশন কন্টেইনার সবসময় ওয়ার্কার নোডে চলে। এই বিভাজন গুরুত্বপূর্ণ কারণ কন্ট্রোল প্লেনের কাজ সমালোচনামূলক (পুরো ক্লাস্টারের সিদ্ধান্ত) — সেটিকে আলাদা রাখলে একটি ব্যস্ত অ্যাপ্লিকেশনের লোড কন্ট্রোল প্লেনের সিদ্ধান্ত-গ্রহণ ক্ষমতাকে প্রভাবিত করতে পারে না। বড় প্রোডাকশন ক্লাস্টারে প্রায়ই একাধিক কন্ট্রোল-প্লেন নোড থাকে (high availability-এর জন্য) — একটি ডাউন হলেও ক্লাস্টার চালু থাকে।

মূল কথা · Key takeaway

Kubernetes-এর আর্কিটেকচার দুটি স্পষ্ট স্তরে ভাগ — কন্ট্রোল প্লেন সিদ্ধান্ত নেয় ও অবস্থা মনে রাখে, ওয়ার্কার নোড সেই নির্দেশনা কার্যকর করে। আর পুরো সিস্টেম একটি একক দর্শনের উপর দাঁড়িয়ে — ক্রমাগত actual-কে desired-এর সাথে মেলানো। L28 থেকে শুরু করে আমরা এই দর্শনের উপর একের পর এক স্তর তৈরি হতে দেখব — Pod, ReplicaSet, Deployment, Service, এবং আরও অনেক কিছু।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ কেন Kubernetes-কে একটি "ডিক্লারেটিভ" সিস্টেম বলা হয়, এবং এটি কীভাবে L17-এর IaC দর্শনের সাথে সম্পর্কিত?

Kubernetes-এ আপনি ধাপে ধাপে নির্দেশ দেন না ("প্রথমে এই পড তৈরি করো, তারপর ওইটা মুছে দাও") — বরং আপনি শুধু কাঙ্ক্ষিত চূড়ান্ত অবস্থা ঘোষণা করেন (যেমন "৩টি রেপ্লিকা চলুক") এবং Controller Manager নিজে বুঝে নেয় সেই অবস্থায় পৌঁছাতে ঠিক কী করতে হবে। এটি হুবহু L17-এর ডিক্লারেটিভ IaC (Terraform) একই দর্শন — শুধু এখানে "রিসোর্স" মানে ভার্চুয়াল মেশিন নয়, পড/কন্টেইনার।

প্র ০২ etcd যদি ডেটা হারায় বা ক্র্যাশ করে, ক্লাস্টারে কী ঘটতে পারে এবং এটি এত সমালোচনামূলক কেন?

etcd পুরো ক্লাস্টারের অবস্থার একমাত্র উৎস — কী চলছে এবং কী চলা উচিত, সব তথ্য সেখানেই। etcd হারালে API server, scheduler ও Controller Manager-এর কাছে তুলনা করার মতো কোনো "সত্য" অবস্থাই থাকে না — তারা সঠিক সিদ্ধান্ত নিতে পারে না। এই কারণেই etcd-এর নিয়মিত ব্যাকআপ (L12-এর ধারণারই একটি প্রয়োগ) ও প্রায়ই একাধিক etcd ইনস্ট্যান্স (high availability) প্রোডাকশন ক্লাস্টারে অপরিহার্য বিবেচিত হয়।

প্র ০৩ কন্ট্রোল প্লেন ও ওয়ার্কার নোডের মধ্যে দায়িত্ব বিভাজন কেন গুরুত্বপূর্ণ — কন্ট্রোল প্লেন কি নিজে অ্যাপ চালায়?

সাধারণত না — কন্ট্রোল প্লেন শুধু সিদ্ধান্ত নেয় ও অবস্থা মনে রাখে, আসল অ্যাপ্লিকেশন কন্টেইনার সবসময় ওয়ার্কার নোডে চলে। এই বিভাজন গুরুত্বপূর্ণ কারণ একটি ব্যস্ত/ভারী অ্যাপ্লিকেশনের লোড যেন পুরো ক্লাস্টারের সিদ্ধান্ত-গ্রহণ ক্ষমতাকে প্রভাবিত না করে — কন্ট্রোল প্লেন আলাদা থাকায় এটি স্বাধীনভাবে, নির্ভরযোগ্যভাবে কাজ করতে পারে এমনকি ওয়ার্কার নোডে ভারী লোড থাকলেও।

অনুশীলন

চিন্তা করুন: একটি সাধারণ ওয়েব অ্যাপ্লিকেশন চালানোর জন্য ন্যূনতম ক্লাস্টার কনফিগারেশন কেমন হতে পারে (কতটি কন্ট্রোল-প্লেন নোড, কতটি ওয়ার্কার নোড), এবং কেন high-availability-এর জন্য একাধিক কন্ট্রোল-প্লেন নোড প্রয়োজন হতে পারে?

একটি ছোট টেস্ট/ডেভ পরিবেশে একটি একক কন্ট্রোল-প্লেন নোড ও এক বা দুটি ওয়ার্কার নোড যথেষ্ট হতে পারে। কিন্তু প্রোডাকশনে সাধারণত অন্তত তিনটি কন্ট্রোল-প্লেন নোড রাখা হয় (একটি বিজোড় সংখ্যা, etcd-এর consensus প্রক্রিয়ার জন্য প্রয়োজনীয়) — যাতে একটি কন্ট্রোল-প্লেন নোড ডাউন হলেও বাকিরা মিলে ক্লাস্টার পরিচালনা চালিয়ে যেতে পারে, একক-পয়েন্ট-অফ-ফেইলিওর এড়াতে।
পরীক্ষা করুন: উপরের কোড সেলে একটি চতুর্থ সিনারিও যোগ করুন যেখানে desired_replicas=0 (সম্পূর্ণ স্কেল-ডাউন) এবং actual_running_pods-এ ৩টি পড আছে — ফলাফল কী হবে প্রথমে অনুমান করুন, তারপর চালিয়ে দেখুন।

shortfall = 0 - 3 = -3, তাই ফাংশনটি তিনটি TERMINATE অ্যাকশন ফেরত দেবে — actual_running_pods[-3:] অর্থাৎ তিনটি পডই বন্ধ করার নির্দেশ আসবে। এটি দেখায় একই reconcile() লজিক scale-to-zero (সম্পূর্ণ বন্ধ করা) পরিস্থিতিতেও স্বাভাবিকভাবে কাজ করে, বিশেষ কোনো আলাদা কোড ছাড়াই।