কাস্টম স্টেজ ব্যবহার করে GKE রোলআউট সিকোয়েন্সিং
Google Cloud-এর GKE এখন আপনাকে ক্লাস্টারগুলো কোন ক্রমে আপগ্রেড করা হবে তা নির্ধারণ করার সুযোগ দিচ্ছে। ডিফল্ট রিজিওনাল শিডিউলের পরিবর্তে এটি কাস্টম-স্টেজ রোলআউট সিকোয়েন্সিং ব্যবহার করে, যা আপনার নিজস্ব বিজনেস লজিক অনুসরণ করে।
ডজন ডজন বা শত শত এনভায়রনমেন্ট জুড়ে Kubernetes ক্লাস্টার আপগ্রেড করা একটি অত্যন্ত জটিল কাজ। নিয়মিত সিকিউরিটি প্যাচ আসে, কিন্তু আপনাকে প্রোডাকশন সার্ভিসগুলোও সচল রাখতে হয়। পুরনো রিজিওনাল আপগ্রেড মডেলে একটি স্টেজিং এনভায়রনমেন্টের ভ্যালিডেশন শেষ হওয়ার আগেই প্রোডাকশন ক্লাস্টারে নতুন কন্ট্রোল-প্লেন ভার্সন চলে আসতে পারত, যা পুরো ফ্লিটকে (fleet) পরীক্ষা না করা পরিবর্তনের ঝুঁকির মুখে ফেলে দিত।
কেন পুরনো মডেলটি যথেষ্ট ছিল না
একটি রিজিওনাল রোলআউট ওই রিজিওনের প্রতিটি ক্লাস্টারকে একটি একক গ্রুপ বা বাকেট হিসেবে বিবেচনা করে। যখন আপগ্রেড উইন্ডো খোলে, রিলিজ পাইপলাইনে ক্লাস্টারটি কোথায় আছে তা বিবেচনা না করেই কন্ট্রোল প্লেন এবং নোডগুলো সমান্তরালভাবে (in parallel) আপগ্রেড হয়। যে টিমগুলো কঠোরভাবে 'ক্যানারি-এরপর-প্রোডাকশন' (canary-then-production) ফ্লো অনুসরণ করে, তাদের ক্ষেত্রে "আউট-অফ-অর্ডার" আপগ্রেড ঘটে। এর ফলে এমন রিগ্রেশন (regression) দেখা দিতে পারে যা নির্দিষ্ট কোনো পরিবর্তনের সাথে শনাক্ত করা কঠিন হয়ে পড়ে। এর ফলে শুধু ডাউনটাইমই নয়, বরং যে সমস্যাটি আগেভাগেই ধরা যেত, সেটি ডিবাগ করতে ইঞ্জিনিয়ারিংয়ের মূল্যবান সময়ও নষ্ট হয়।
GKE রোলআউট সিকোয়েন্সিং যা যোগ করছে
এই নতুন ফিচারটি একটি RolloutSequence অবজেক্ট প্রবর্তন করেছে যা কতগুলো স্টেজ বা ধাপ নির্ধারণ করে। প্রতিটি স্টেজ হলো আপনার ফ্লিটের একটি লজিক্যাল অংশ, যা লেবেল সিলেক্টর (label selectors) দ্বারা চিহ্নিত করা হয়। সিস্টেমটি একটি ডিটারমিনিস্টিক (deterministic) পথ অনুসরণ করে:
- প্রথমে কন্ট্রোল-প্লেন আপগ্রেড। কোনো নোড স্পর্শ করার আগেই GKE কেন্দ্রীয় ম্যানেজমেন্ট কম্পোনেন্টটিকে টার্গেট ভার্সনে নিয়ে যায়।
- সোয়াক টাইমার (Soak timer) শুরু হয়। কন্ট্রোল প্লেন টার্গেট ভার্সনে পৌঁছানোর পর, একটি কনফিগারযোগ্য বিলম্ব (delay) চলে, যা আপনাকে হেলথ চেক করার জন্য সময় দেয়।
- নোড আপগ্রেড সমান্তরালভাবে চলে। সোয়াক টাইমার চলাকালীন, GKE নোডগুলো আপগ্রেড করে, ফলে ক্লাস্টারটি দ্রুত নতুন ভার্সনে পৌঁছাতে পারে।
- পরবর্তী স্টেজ কেবল সম্পন্ন হওয়ার পরেই শুরু হয়। বর্তমান স্টেজের প্রতিটি নোড এবং কন্ট্রোল প্লেন সম্পন্ন হলে এবং সোয়াক টাইমার শেষ হলে, GKE পরবর্তী স্টেজে অগ্রসর হয়।
একটি ফ্লিটকে ছোট ছোট লেবেলযুক্ত গ্রুপে ভাগ করার মাধ্যমে, আপনি প্রথমে কয়েকটি ক্যানারি ক্লাস্টার আপগ্রেড করতে পারেন, মনিটরিং এবং ট্রাফিক-রাউটিং রুলগুলো প্রত্যাশা অনুযায়ী কাজ করছে কিনা তা যাচাই করতে পারেন এবং তারপর বাকি প্রোডাকশনে একই ভার্সন রোলআউট করতে পারেন।
সিকোয়েন্সটি সুশৃঙ্খল রাখার নিয়মাবলী
- ক্যাচ-অল (Catch-all) স্টেজ: শেষ স্টেজে কোনো লেবেল সিলেক্টর থাকে না, যা নিশ্চিত করে যে আগে কোনো স্টেজের সাথে মেলেনি এমন ক্লাস্টারগুলোও আপগ্রেড পাবে।
- কনফ্লিক্ট রেজোলিউশন (Conflict resolution): যদি কোনো ক্লাস্টারের লেবেল একাধিক স্টেজের শর্ত পূরণ করে, তবে GKE সেটিকে প্রথম ম্যাচিং স্টেজে রাখে, যা দুবার আপগ্রেড হওয়ার ঝুঁকি রোধ করে।
রিয়েল-টাইম কন্ট্রোল নবস (Control knobs)
একটি সক্রিয় রোলআউটের সময় আপনি নিয়ন্ত্রণ বজায় রাখতে পারেন:
- Pause: এটি পরবর্তী সব আপগ্রেড থামিয়ে দেয়, ফলে কোনো ক্যানারি স্টেজে সমস্যা দেখা দিলে তা পুরো সিস্টেমে ছড়িয়ে পড়ার আগেই আপনি তদন্ত করতে পারেন।
- Force-complete: আপনার ভ্যালিডেশন স্ক্রিপ্ট যদি দ্রুত সফলতার রিপোর্ট দেয়, তবে এটি বাকি থাকা সোয়াক টাইম কমিয়ে দেয়, ফলে রোলআউট দ্রুত সম্পন্ন হয়।
- Cancel: যদি নতুন রিলিজ করা ভার্সনে কোনো গুরুতর বাগ (bug) দেখা দেয়, তবে এটি পুরো সিকোয়েন্স বাতিল করে দেয়, যা আপনাকে আগের অবস্থায় ফিরে যেতে বা হটফিক্সের জন্য অপেক্ষা করতে সাহায্য করে।
কারা উপকৃত হবেন এবং এর সীমাবদ্ধতাগুলো কী কী
পরবর্তীতে যা খেয়াল রাখতে হবে
সারসংক্ষেপ
কাস্টম-স্টেজ রোলআউট সিকোয়েন্সিং GKE অপারেটরদের ক্লাস্টারগুলো তাদের ব্যবসার প্রয়োজন অনুযায়ী আপগ্রেড করার ক্ষমতা দেয়, প্ল্যাটফর্মের নির্ধারিত ক্রমে নয়। কন্ট্রোল-প্লেন এবং নোড আপগ্রেড আলাদা করা, একটি কনফিগারযোগ্য সোয়াক পিরিয়ড যোগ করা এবং pause/force-complete/cancel অ্যাকশন প্রদানের মাধ্যমে, এই ফিচারটি আপগ্রেড করার ঝুঁকি কমায় এবং ক্লাউড-নেটিভ টিমগুলোর প্রয়োজনীয় গতি বজায় রাখে। যারা ফ্লিট-ওয়াইড Kubernetes আপগ্রেডের বিশৃঙ্খলার সাথে লড়াই করছেন, তাদের জন্য এই নতুন সিকোয়েন্সিং মডেলটি নিরাপদ এবং বিজনেস-অ্যালাইনড অটোমেশনের দিকে একটি সুনির্দিষ্ট পদক্ষেপ।