Deployment আপডেট করলে সাইট ডাউন হয় না কেন — Rolling Update ভেতরে ভেতরে কী করে

kubectl set image deployment/api api=myapp:v2 — একটা কমান্ড, আর কয়েক সেকেন্ড পর kubectl get pods চালালে দেখা যায় পুরনো Pod-গুলো একে একে হারিয়ে যাচ্ছে, নতুনগুলো জায়গা নিচ্ছে। এই পুরো সময়টায় সাইটে একটাও রিকোয়েস্ট ফেইল হয় না — অথচ কোনো মেইনটেন্যান্স পেজ দেখানো হয়নি, কাউকে জানানোও হয়নি।

এটা কীভাবে হয়, সেটা বুঝলে দুটো জিনিস পরিষ্কার হয়ে যায়: ডিপ্লয়মেন্ট স্লো কেন হচ্ছে সেটা ডিবাগ করা, আর কিছু ভুল হলে কীভাবে এক কমান্ডে ফিরিয়ে আনা যায়।

ডিফল্ট স্ট্র্যাটেজি: RollingUpdate

একটা Kubernetes Deployment-এর .spec.strategy.type ডিফল্টভাবে RollingUpdate — মানে নতুন ভার্সন এক ধাক্কায় পুরনোটাকে replace করে না। বরং ধাপে ধাপে: কিছু নতুন Pod তৈরি হয়, তারা readiness probe পাস করে ট্রাফিক নেওয়ার জন্য প্রস্তুত হয়, তারপরই সমপরিমাণ পুরনো Pod সরিয়ে দেওয়া হয়। পুরো ট্রানজিশন জুড়ে সবসময় যথেষ্ট সংখ্যক Pod ট্রাফিক পাওয়ার জন্য রেডি থাকে।

দুটো সংখ্যা যা পুরো আচরণ নিয়ন্ত্রণ করে

RollingUpdate স্ট্র্যাটেজির ভেতরে দুটো প্যারামিটার থাকে, দুটোই পার্সেন্টেজ বা সংখ্যা হিসেবে দেওয়া যায়:

maxSurge — কাঙ্ক্ষিত রেপ্লিকা সংখ্যার চেয়ে বেশি কতগুলো Pod সাময়িকভাবে তৈরি করা যাবে। এটা বেশি রাখলে ডিপ্লয়মেন্ট দ্রুত হয় (একসাথে বেশি নতুন Pod ওঠে), কিন্তু ওই মুহূর্তে ক্লাস্টারে বাড়তি CPU/মেমরি লাগে।

maxUnavailable — কাঙ্ক্ষিত সংখ্যার চেয়ে কতগুলো Pod সাময়িকভাবে কম থাকতে পারবে (অর্থাৎ, ট্রাফিক নেওয়ার জন্য অনুপলব্ধ থাকতে পারবে)। এটা 0 রাখলে ডিপ্লয়মেন্টের সময় ক্যাপাসিটি কখনো কমবে না — কিন্তু তার মানে maxSurge অন্তত ১ না রাখলে নতুন Pod ওঠারই জায়গা থাকবে না।

spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%

spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

৪টা রেপ্লিকা আর ডিফল্ট 25%/25% কনফিগারেশন দিয়ে হিসাব করলে: maxUnavailable: 25% মানে একসাথে ১টা Pod সাময়িকভাবে কমে যেতে পারে (৪ থেকে ৩-এ), অর্থাৎ ক্যাপাসিটি সাময়িকভাবে কমে। ডান পাশের কনফিগারেশনে maxUnavailable: 0 দেওয়ায় সেটা কখনো হয় না — সবসময় কমপক্ষে ৪টা Pod রেডি থাকে, মাঝেমধ্যে ৫টা পর্যন্ত (৪ + maxSurge: 1)।

rollout স্টাক থাকলে কী দেখবেন

kubectl rollout status deployment/api কমান্ড আটকে থাকলে, প্রথম সন্দেহ করার জায়গা: নতুন Pod-গুলো readiness probe পাস করছে কি না। kubectl get pods চালিয়ে READY কলামে 0/1 দেখলে বোঝা যায় Pod উঠেছে কিন্তু readiness ফেইল করছে — এটাই আগের লেখার বিষয় (liveness বনাম readiness)।

আরেকটা সাধারণ কারণ: রিসোর্স কোটা বা নোডে জায়গা না থাকা। maxSurge বাড়তি Pod তৈরির অনুমতি দেয়, কিন্তু ক্লাস্টারে সেই Pod বসানোর মতো CPU/মেমরি না থাকলে সেটা Pending অবস্থাতেই আটকে থাকবে, আর rollout এগোবে না।

কিছু ভুল হলে — Rollback

নতুন ভার্সন ডিপ্লয় করার পর যদি বোঝা যায় কিছু ভুল আছে, kubectl rollout undo deployment/api চালালে Kubernetes ঠিক এই একই rolling update মেকানিজম ব্যবহার করে — শুধু উল্টো দিকে। আগের ভার্সনের Pod ধীরে ধীরে ফিরিয়ে আনা হয়, নতুনটা সরানো হয়, একই maxSurge/maxUnavailable নিয়ম মেনেই।

এটা কাজ করে কারণ Deployment প্রতিটা আপডেটের একটা রিভিশন হিস্টোরি রাখে (kubectl rollout history deployment/api)। নির্দিষ্ট কোনো রিভিশনে ফিরতে চাইলে: kubectl rollout undo deployment/api --to-revision=3।

ডিপ্লয়মেন্টের আগে-পরে যা চেক করবেন

Rolling update জাদু না — এটা দুটো সংখ্যার হিসাব, আর সেই হিসাবটা কাজ করার জন্য readiness probe-এর ওপর সম্পূর্ণ নির্ভরশীল। এই তিনটা জিনিস একসাথে বুঝলে — probe, maxSurge/maxUnavailable, আর rollback — একটা প্রোডাকশন Deployment দেখলে আর অন্ধকারে ঢিল ছোড়ার মতো লাগবে না।