Kubernetes

সমস্যাটা কী?

Container দিয়ে একটা অ্যাপ চালানো সহজ। কিন্তু production-এ যখন তোমার ৫০টা container আলাদা আলাদা মেশিনে চালাতে হয়, তখন প্রশ্ন আসে — একটা container crash করলে কে আবার চালু করবে? Traffic বাড়লে কে নতুন container যোগ করবে? কোন মেশিনে কোন container চলবে কে ঠিক করবে? নতুন version deploy করার সময় downtime কীভাবে এড়াবে?

হাতে হাতে এসব করা অসম্ভব। তোমার দরকার একটা orchestrator — যে স্বয়ংক্রিয়ভাবে container-গুলো চালায়, monitor করে, ব্যর্থ হলে ঠিক করে, আর চাহিদা অনুযায়ী scale করে। এই কাজটাই করে Kubernetes (সংক্ষেপে k8s)।

মূল ধারণা

Kubernetes হলো একটি open-source container orchestration platform যা containerized অ্যাপ্লিকেশনের deployment, scaling এবং management স্বয়ংক্রিয় করে।

Kubernetes-এর মূল দর্শন হলো declarative configuration। তুমি বলো না "এই container চালু করো, ওটা বন্ধ করো"। বরং তুমি একটা desired state ঘোষণা করো — "আমার এই অ্যাপের ৩টা copy সবসময় চলবে"। Kubernetes ক্রমাগত actual state-কে desired state-এর সাথে মিলিয়ে রাখে। কোনো copy মরে গেলে, সে নিজে থেকেই নতুন একটা চালু করে দেয়। একে বলে reconciliation loop।

কীভাবে কাজ করে

মূল components

Component	কাজ
Pod	ছোটতম unit; এক বা একাধিক container ধারণ করে
Deployment	কত replica চলবে তা ঠিক করে, update ও self-healing দেখে
ReplicaSet	নির্দিষ্ট সংখ্যক identical pod চালু রাখে
Service	pod-গুলোর জন্য একটি stable network address দেয়
Ingress	external HTTP/HTTPS traffic ভেতরের service-এ রুট করে
Node	একটি worker মেশিন (VM বা physical) যেখানে pod চলে

Pod আর Replica

Pod-এর IP address ক্ষণস্থায়ী — pod মরে নতুন pod উঠলে IP বদলে যায়। তাই pod-এর সাথে সরাসরি যোগাযোগ করা যায় না।

Deployment বলে দেয় কয়টি replica (copy) চলবে:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: myapp:1.2
          ports:
            - containerPort: 3000

এখানে replicas: 3 মানে সবসময় ৩টা pod চলবে। একটা মরে গেলে Kubernetes সাথে সাথে আরেকটা চালু করে — এটাই self-healing।

Service আর Ingress

যেহেতু pod-এর IP বদলায়, Service একটি stable virtual IP ও DNS নাম দেয়, আর behind-the-scenes traffic পেছনের pod-গুলোর মধ্যে load-balance করে।

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 3000

বাইরের জগৎ থেকে আসা traffic (যেমন api.example.com/users) সঠিক service-এ পাঠানোর কাজ করে Ingress — এটি একটি smart HTTP router, যা path বা hostname অনুযায়ী রুট করে।

Autoscaling (HPA)

Traffic বাড়লে pod বাড়ানো দরকার। HPA (Horizontal Pod Autoscaler) metric (যেমন CPU 70%-এর বেশি হলে) দেখে স্বয়ংক্রিয়ভাবে pod-এর সংখ্যা বাড়ায়, আর traffic কমলে কমিয়ে দেয়।

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          averageUtilization: 70

কৌশল

Kubernetes ব্যবহারের কিছু গুরুত্বপূর্ণ practice:

• Resource requests ও limits সেট করো, যাতে একটা pod সব resource খেয়ে না ফেলে।
• Liveness ও Readiness probe ব্যবহার করো — Kubernetes জানবে কখন pod সুস্থ আর কখন traffic নিতে প্রস্তুত।
• Namespace দিয়ে আলাদা team বা environment আলাদা রাখো।
• ConfigMap ও Secret দিয়ে configuration আর গোপন তথ্য আলাদা রাখো, image-এর ভেতরে নয়।

কখন ব্যবহার করবে / করবে না

ব্যবহার করবে যখন:

• অনেকগুলো microservice চালাতে হয় যেগুলো আলাদাভাবে scale করা দরকার।
• High availability, self-healing ও auto-scaling দরকার।
• একাধিক টিম একই infrastructure শেয়ার করে।

ব্যবহার করবে না যখন:

• একটামাত্র ছোট অ্যাপ বা startup-এর MVP। তখন managed PaaS (যেমন Render, Railway, App Runner) যথেষ্ট।
• টিমে Kubernetes চালানোর দক্ষতা নেই।

বাস্তব উদাহরণ

একটা e-commerce platform (ধরো দারাজ-জাতীয়) ভাবো। সারা বছর traffic মোটামুটি স্থির, কিন্তু "11.11" সেলের দিন traffic ১০ গুণ বেড়ে যায়।

Kubernetes-এ তাদের checkout service-এ HPA সেট করা আছে: স্বাভাবিক সময়ে ৫টা pod চলে, কিন্তু CPU বাড়লে স্বয়ংক্রিয়ভাবে ৫০টা পর্যন্ত pod উঠে যায়। সেল শেষ হলে আবার ৫টায় নেমে আসে — খরচ বাঁচে। এর মধ্যে কোনো একটা node crash করলে Kubernetes সেই node-এর pod-গুলো অন্য সুস্থ node-এ সরিয়ে চালু করে দেয়, ব্যবহারকারী টের পায় না। নতুন version deploy করার সময় rolling update-এ ধীরে ধীরে পুরোনো pod বদলে নতুন pod আসে — zero downtime।