M. ISLAM

Day 27 — Kubernetes — ভয় পাবেন না, ২০% জানলেই ৮০% কাজ হয় ☸️

July 20, 20266 min read30 Days Of Backend Engineering

এখন আপনার team-এর productivity অনেক বেড়ে গেছে। এখন আপনার application-এর সবকিছুই বলতে গেলে docker এবং docker compose দিয়ে চলে। কিন্তু আপনার application-এর পরিমাণ অনেক বেশি, আলাদা instance রয়েছে, load balancer আছে, database instances আছে। problem হচ্ছে, এখানে আপনি চাইলেই multiple instance run করা যায় তবে এই instance fixed করা থাকে কমানোও যায় না, বাড়ানোও যায় না। শুধুমাত্র আপনাকে manually add করতে হবে। আবার কোনো instance down হয়ে গেলে তাকে restart করার প্রয়োজন হয়। এই সবকিছুই manually করতে হয়। suppose একটা application-এ ৩টা fixed instance আছে। এই ৩টা instance maximum 2k request per second handle করতে পারে। এখন হঠাৎ করে peak time-এ এটা 3k rps-এ চলে গেল। এখন আপনার instance ২টা বাড়াতে হবে। এই আপনি করলেন কিন্তু ১ঘণ্টা পরে load কমে গেল 1k rps-এ। তখন কিন্তু আপনার ২টা instance হলেই enough, বাকি ৩টা instance-এর কিন্তু দরকার নেই। এটা করার জন্য আপনাকে আবার manually code update করে run করা লাগবে।

এখন এটা যদি প্রতিদিন করা লাগে বিষয়টা কেমন হবে just imagine। এটা তো এখন এর থেকেও বড় কথা হচ্ছে, আপনি বুঝবেন কীভাবে load বেড়ে গেছে? load 100% হয়ে গেলে তো সব instance crash করে যাবে। আরও অনেক problem।

এখন এটাই যদি automatically করা যেত তাহলে বিষয়টা কেমন হতো?

আপনার এত tension করা লাগত না। load যখন বেড়ে যাবে তখন automatically instance বেড়ে যাবে (scale up)। load কমে গেলে automatically instance কমতে থাকবে (scale down)। ইচ্ছা মতো container up, down করা যাবে। আরও অনেক problem solve হয়ে যাবে।

বিষয়টা খুবই interesting, তাই না। এই same কাজটাই করে Kubernetes (K8s)।

What is kubernetes?

kubernetes হলো docker compose-এর মতো একটা orchestrator, যার মূল কাজ হচ্ছে container-গুলোকে maintain করা। একে short-এ K8s বলে থাকে। docker compose-এ যেখানে limitation চলে আসে, সেখান থেকেই k8s-এর শুরু। k8s-এর history বলে লাভ নেই। একটু research করলেই পেয়ে যাবেন।

একটু আগে scale up and scale down-এর কথা বললাম, সেই কাজটা k8s easily করতে পারে, automatic-ভাবে। একে autoscaling বলে। automatically scale হবে। তবে এই autoscalling এর জন্য logic এবং পলিসি আগে থেকে code এ লিখে দিতে হয়। K8s-এর নিজস্ব Service object আছে যা internal load balancing করে, এবং cloud provider-এর সাথে মিলে external traffic handle করা একদম সহজ করে দেয়। এছাড়াও auto healing-এর feature-ও k8s-এ আছে।

k8s একটা huge জিনিস। এটা মোটামোটি complex, learning curve অনেক long। আর k8s small to medium application-এর জন্য use করা overkill হয়ে যায়।

K8s কেন দরকার?

কেন দরকার সেটা কিছুটা আন্দাজ করতে পারছেন। সেই বিষয়ে যাওয়ার আগে নিচের question-গুলো নিয়ে একটু ভাবুন:

  • Container crash করলে কে restart করবে?
  • Traffic বাড়লে container বা instance কে বাড়াবে?
  • আবার traffic কমে গেলে instance কে কমাবে?
  • ১০টা server-এ load কীভাবে distribute হবে?
উপরে প্রত্যেক problem-এর solution k8s-এ রয়েছে। এছাড়াও k8s zero down time deployment-এর benefit দেয়। এখানে আপনার application down না করেই নতুন version-এ roll করা যায়। server কোনো ভাবেই down হবে না। gracefully old application-গুলো new version-এর application দিয়ে replace করে দেবে with zero down time।

মূল Concepts — শুধু এগুলো

  • Pod — K8s সরাসরি container রান করে না, Pod রান করে। এটি ক্লাস্টারের সবচেয়ে ছোট unit, যার ভেতরে এক বা একাধিক container থাকতে পারে (যেমন আপনার main app এবং একটি logging agent)।
  • Deployment — আপনার অ্যাপের কতগুলো copy (Pod) চলবে এবং কোন image থেকে চলবে তা define করে। কোনো Pod ক্র্যাশ করলে নতুন Pod তৈরি করা বা Zero-downtime আপডেট দেওয়ার দায়িত্ব মূলত এর।
  • Service — Pods নশ্বর (mortal), এরা dead হয়ে গেলে নতুন IP দিয়ে আবার নতুন করে রান হয়। Service এদের সামনে একটা Fixed IP ও DNS নাম বসিয়ে দেয়, যেন ডাটাবেস বা অন্যান্য অ্যাপ সহজে এদের খুঁজে পায়।
  • Ingress — বাইরের traffic (ইন্টারনেট) ক্লাস্টারের ভেতরে আসার মেইন দরজা বা Router। কোন ডোমেইন বা URL-এ হিট করলে কোন Service-এ ট্রাফিক যাবে, তা Ingress ঠিক করে দেয়।
  • ConfigMap / Secret — অ্যাপ্লিকেশনের Environment Variables এবং Configuration কোড থেকে আলাদা রাখার জায়গা। সাধারণ ডাটার জন্য ConfigMap আর পাসওয়ার্ড বা API Key এর মতো সেনসিটিভ ডাটার জন্য Secret ব্যবহৃত হয়।

Deployment & Service: A Real Example

Kubernetes-এ সবকিছু ডিক্লেয়ার করা হয় YAML ম্যানিফেস্টের মাধ্যমে:

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-backend-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate # Zero-downtime rolling update
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: my-backend
  template:
    metadata:
      labels:
        app: my-backend
    spec:
      containers:
        - name: app
          image: my-backend:v1.0.0
          ports:
            - containerPort: 3000
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
---
# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-backend-service
spec:
  type: ClusterIP
  selector:
    app: my-backend
  ports:
    - port: 80
      targetPort: 3000

HPA (Horizontal Pod Autoscaler): অটো-স্কেলিং 📈

ম্যানুয়ালি ৩টি বা ৫টি Pod নির্দিষ্ট না রেখে, ট্রাফিকের ওপর ভিত্তি করে স্বয়ংক্রিয়ভাবে Pod সংখ্যা বাড়ানো বা কমানোর কাজ করে HPA. For example:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-backend-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-backend-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70 # CPU ব্যবহার ৭০% পার হলে নতুন Pod তৈরি হবে

K8s in small application

শুনতে এত জোস লাগলেও, একটা ছোট বা মিডিয়াম সাইজের প্রোজেক্টে, যেখানে ইউজার বেস কম এবং ট্রাফিক প্রেডিক্টেবল, সেখানে K8s সেটআপ করা মানে নিজের পায়ে নিজে কুড়াল মারা। কেন? চলুন একটু ভেঙে বলি:

  1. Overkill Architecture & Complexity: Kubernetes এর নিজস্ব একটা বিশাল লার্নিং কার্ভ (Learning curve) আছে। Pods, Deployments, Services, Ingress, ConfigMaps—এসব মেইনটেইন করতেই আপনার জান বের হয়ে যাবে। যে সময়টা আপনি কোড ইমপ্রুভমেন্ট বা বিজনেজ লজিকে দিতে পারতেন, সেটা চলে যাবে ক্লাস্টার কনফিগার করতেই।
  2. Infrastructure Cost (পকেটের টান): K8s চালাতে গেলে মিনিমাম একটা Control Plane (Master Node) আর কয়েকটা Worker Node লাগে। ছোট একটা অ্যাপের যে রিসোর্স লাগবে, তার চেয়ে বেশি রিসোর্স খরচ হয়ে যাবে শুধু Kubernetes ক্লাস্টারটাকে টিকিয়ে রাখতে। ক্লাউড বিল দেখে তখন কপালে হাত পড়বে!
  3. Operational Overhead: এটাকে ম্যানেজ করার জন্য ডেডিকেটেড DevOps ইঞ্জিনিয়ার বা এক্সপার্টাইজ লাগে। ছোট টিমে ডেভলপাররাই যখন DevOps-এর কাজ করে, তখন এই ওভারহেড প্রোডাক্টিভিটি কমিয়ে দেয়।
তাহলে উপায় কি?

আপনার অ্যাপ্লিকেশন যদি ছোট হয়, তাহলে অযথা Kubernetes ব্যবহার করার দরকার নেই। সিম্পল এবং ইফেক্টিভ কিছু অল্টারনেটিভ অলরেডি মার্কেটে আছে:

  • Docker Compose: সিঙ্গেল ভার্চুয়াল মেশিনে (VM) মাল্টিপল কন্টেইনার চালানোর জন্য বেস্ট এবং একদম সিম্পল।
  • Docker Swarm: Docker এর নিজের Orchestration tool. K8s এর থেকে অনেক simple আর easy to learn।
  • Managed Platforms: Render, Railway, বা DigitalOcean App Platform-এর মতো সার্ভিসগুলো ইউজ করতে পারেন। কোনো ইনফ্রাস্ট্রাকচারের চিন্তা ছাড়াই জাস্ট কোড পুশ করলেই লাইভ!
  • VPS (Virtual Private Server): একটা সিম্পল Hetzner বা DigitalOcean Droplet-এ Docker দিয়ে সেটআপ করে নিলেই বছরের পর বছর শান্তিতে চালানো যায়।

বটম লাইন

কুবারনেটিস টেকনোলজি হিসেবে অসাধারণ এবং বড় স্কেলের মাইক্রোসার্ভিস আর্কিটেকচারের জন্য এটার কোনো বিকল্প নেই। কিন্তু হাইপ বা ট্রেন্ডের পেছনে ছুটে ছোট অ্যাপে K8s ঢুকিয়ে কমপ্লেক্সিটি বাড়ানোর কোনো মানে হয় না। তবে k8s ব্যবহার করতে হয় তাহলে একেবারে বেসিক দিয়ে শুরু করুন। Deployment, Service, HPA, Ingress — এই চারটা দিয়েই ৮০% production workload handle করা যায়, এই গুলা শিখে শুরু করুন পরে প্রয়োজন হলে শিখে নিবেন।

আপনি কি K8s ব্যবহার করছেন? সবচেয়ে কঠিন কোন concept মনে হয়েছে? কমেন্টে শেয়ার করুন! 👇

Back to publications