জো বেডার-এর প্রাথমিক কুবেরনেটিস সিদ্ধান্তগুলো—ডিক্লারেটিভ API, কন্ট্রোল লুপ, পড, সার্ভিস, ও লেবেল—কীভাবে আধুনিক অ্যাপ প্ল্যাটফর্মগুলোকে গড়ে তুলেছে তার সরল ব্যাখ্যা।
জো বেডা কুবেরনেটিসের প্রথম নকশার মূল ব্যক্তিদের একজন ছিলেন—অন্য প্রতিষ্ঠাতাদের সঙ্গে মিলিয়ে যারা গুগলের অভ্যন্তরীণ সিস্টেম থেকে শিক্ষা নিয়ে ওপেন প্ল্যাটফর্ম গড়েছিলেন। তার প্রভাব ফ্যাশনেবল ফিচারের পিছনে ছুটাই ছিল না; বরং সহজ প্রিমিটিভ বাছাই করা যা বাস্তব প্রোডাকশন অগোছলির মধ্যে টিকে থাকতে পারে এবং দৈনন্দিন টিমগুলোর বোঝার অপারেশনাল ধারণা রাখতে পারে—এটাই ছিল লক্ষ্য।
সেই প্রাথমিক সিদ্ধান্তগুলোর কারণেই কুবেরনেটিস কেবল “একটি কনটেইনার টুল” হয়ে ওঠেনি। এটি আধুনিক অ্যাপ্লিকেশন প্ল্যাটফর্মের জন্য একটি পুন:ব্যবহারযোগ্য কর্নেল হয়ে উঠেছে।
“কনটেইনার অর্কেস্ট্রেশন” হলো নিয়ম ও স্বয়ংক্রিয়তার সেট যা আপনার অ্যাপ চালু রাখে যখন মেশিন ব্যর্থ হয়, ট্র্যাফিক বাড়ে, বা আপনি নতুন ভার্শন ডেপ্লয় করেন। একজন মানুষ সার্ভারগুলো দেখতে না বসে সিস্টেম কনটেইনারগুলোকে কম্পিউটারে শিডিউল করে, ক্র্যাশ হলে রিস্টার্ট করে, স্থায়িত্ব বাড়াতে ছড়িয়ে দেয় এবং নেটওয়ার্কিং কনফিগার করে যাতে ব্যবহারকারীরা পৌঁছতে পারে।
কুবেরনেটিস সাধারণ না হওয়ার আগে টিমগুলো প্রায়ই স্ক্রিপ্ট ও কাস্টম টুল জোড়া লাগিয়ে মৌলিক প্রশ্নগুলোর উত্তর খুঁজে নিতো:
এই DIY সিস্টেমগুলো কাজ করেছিল—যতক্ষণ না করে। প্রতিটি নতুন অ্যাপ বা টিম আরও এককালীন লজিক যোগ করতো, এবং অপারেশনাল সামঞ্জস্য অর্জন করা কঠিন হয়ে ওঠে।
কুবেরনেটিসের আগে “কনটেইনার চালানো” সাধারণত কয়েকটি কনটেইনার চালানো মানে ছিল। টিমগুলো bash স্ক্রিপ্ট, cron কাজ, গোল্ডেন ইমেজ এবং কিছু হ্যাঁ-ওয়ান-অফ টুল জোড়া লাগিয়ে ডেপ্লয়মেন্ট করতো। কিছু ভেঙে গেলে ফিক্স প্রায়ই কারো মাথায় থাকতো—অথবা এমন একটি README-তে যা কেউ বিশ্বাস করতো না। অপারেশন হলো এক ধারা এককালীন হস্তক্ষেপের: প্রসেস রিস্টার্ট, লোড ব্যালেন্সার পুনর্নির্দেশ, ডিস্ক পরিষ্কার, এবং কোন মেশিন নিরাপদে টাচ করা যাবে তা আন্দাজ করা।
কনটেইনার প্যাকেজিংকে সহজ করেছে, কিন্তু প্রোডাকশনের অগোছল অংশগুলো সরায়নি। স্কেলে সিস্টেম আরওভাবে এবং আরও প্রায়ই ফেল করে: নোড হারিয়ে যায়, নেটওয়ার্ক পার্টিশন হয়ে যায়, ইমেজ অসামঞ্জস্যভাবে রোলআউট হয়, এবং ওয়ার্কলোডগুলো ধরে থাকে না যা আপনি ভাবেন চলছে। একটি “সরল” ডেপ্লয় কাসকেডে পরিণত হতে পারে—কিছু ইনস্ট্যান্স আপডেট হয়েছে, কিছু নয়, কিছু আটকে গেছে, কিছু সুস্থ কিন্তু পৌঁছনো যায় না।
মূল সমস্যা ছিল কনটেইনার শুরু করা না—এটা ছিল সঠিক কনটেইনারগুলোকেই সঠিক আকারে চালিয়ে রাখা, স্থিতিশীলভাবে, অবিরত পরিবর্তনের মাঝেও।
টিমগুলো বিভিন্ন পরিবেশ ভারসাম্য করছিল: অন‑প্রিম হার্ডওয়্যার, VM, প্রথমবছরের ক্লাউড প্রোভাইডার, এবং বিভিন্ন নেটওয়ার্ক ও স্টোরেজ সেটআপ। প্রতিটি প্ল্যাটফর্মের নিজস্ব শব্দভাণ্ডার ও ব্যর্থতা প্যাটার্ন ছিল। একটি ভাগ করা মডেল না থাকলে প্রতিটি মাইগ্রেশন মানে ছিল অপারেশনাল টুল পুনঃলিখন ও লোকজনকে পুনরায় ট্রেইন করা।
কুবেরনেটিস একটি একক, সঙ্গত উপায় অফার করতে চেয়েছিল অ্যাপ্লিকেশন ও তাদের অপারেশনাল চাহিদা বর্ণনা করার জন্য—নোডগুলো যেখানে আছে তার উপর নির্ভর না করে।
ডেভেলপাররা আত্ম-সেবা চেয়েছিল: টিকিট ছাড়াই ডেপ্লয়, ক্যাপাসিটি ছাড়াই স্কেল, ও ড্রামা ছাড়াই রোলব্যাক। অপস দলগুলো পূর্বানুমেয়তা চেয়েছিল: স্ট্যান্ডার্ডাইজড হেলথ চেক, পুনরাবৃত্তিযোগ্য ডেপ্লয়মেন্ট, এবং কি চালানো উচিত তার একটি পরিষ্কার সোর্স অফ ট্রুথ।
কুবেরনেটিস এক ধরণের ফ্যান্সি শিডিউলার হওয়ার চেষ্টা করেনি। এটি নির্ভরযোগ্য অ্যাপ্লিকেশন প্ল্যাটফর্মের ভিত্তি হতে চেয়েছিল—একটি সিস্টেম যা অগোছল বাস্তবতাকে এমনভাবে রূপান্তর করে যে আপনি সেটির বিষয়ে যুক্তি করতে পারেন।
প্রারম্ভিক গুরুত্বপুর্ন সিদ্ধান্তগুলোর একটি ছিল কুবেরনেটিসকে ডিক্লারেটিভ করা: আপনি যা চান তা বর্ণনা করেন, এবং সিস্টেম বাস্তবতাকে সেই বর্ণনার সাথে মেলাতে কাজ করে।
একটি থার্মোস্ট্যাট এখানে ব্যবহার উপযোগী উদাহরণ। আপনি প্রতি কয়েক মিনিটে হিটার অন/অফ করে না। আপনি একটি কাঙ্ক্ষিত তাপমাত্রা—ধরা যাক ২১°C—সেট করেন এবং থার্মোস্ট্যাট ঘর চেক করে হিটার সামঞ্জস্য করে সেই লক্ষ্যের কাছে রাখে।
কুবেরনেটিসও একইভাবে কাজ করে। ক্লাস্টারকে ধাপে ধাপে বলে না “এই কনটেইনার ঐ মেশিনে শুরু করো, তারপর ক্র্যাশ হলে রিস্টার্ট করো,” বরং আপনি আউটকাম ডিক্লেয়ার করেন: “আমি চাই এই অ্যাপের ৩ কপি চালুকরণ।” কুবেরনেটিস ধারাবাহিকভাবে যা আসলে চলছে তা চেক করে এবং ড্রিফট ঠিক করে।
ডিক্লারেটিভ কনফিগারেশন সেই গোপন “ওপস চেকলিস্ট” কমায় যা প্রায়ই কারো মাথায় বা আংশিক আপডেট হওয়া রানবুকে লুকিয়ে থাকে। আপনি কনফিগ প্রয়োগ করেন, এবং কুবেরনেটিস প্লেসমেন্ট, রিস্টার্ট, এবং রিকনসিলিং মেকানিক্স নিয়ন্ত্রণ করে।
এটি পরিবর্তন রিভিউকেও সহজ করে—একটি পরিবর্তন কনফিগের ডিফ হিসেবে দৃশ্যমান হয়, একাধিক আড‑হক কমান্ডের পরিবর্তে।
কারণ ইচ্ছা লিখে রাখা আছে, আপনি একই পদ্ধতি ডেভ, স্টেজিং ও প্রোডাকশনে পুনরায় ব্যবহার করতে পারেন। পরিবেশটি বিভিন্ন হতে পারে, কিন্তু ইন্টেন্ট সঙ্গত থাকে, যা ডেপ্লয়মেন্টকে পূর্বানুমেয় ও অডিটযোগ্য করে তোলে।
ডিক্লারেটিভ সিস্টেমের একটি শিক্ষার বাঁক আছে: আপনাকে “কি সত্য হওয়া উচিত” এভাবে চিন্তা করতে হবে, না যে “পরবর্তী কী করা হবে।” এগুলোও ভালো ডিফল্ট এবং পরিষ্কার কনভেনশনগুলোর উপর নির্ভর করে—বিনা তাদের টিমগুলো এমন কনফিগ তৈরি করতে পারে যা টেকনিক্যালি কাজ করে কিন্তু বোঝা ও রক্ষণাবেক্ষণ কঠিন।
কুবেরনেটিস একবার কনটেইনার চালাতে পারায় সফল হয়নি—এটি সময়ের সাথে সেগুলোকে সঠিকভাবে চালিয়ে রাখার ক্ষমতায় সফল হয়েছিল। বড় ডিজাইন পদক্ষেপ ছিল কন্ট্রোল লুপগুলো (কন্ট্রোলার) সিস্টেমের কোর ইঞ্জিন করা।
কন্ট্রোলার একটি সাধারণ লুপ:
এটি একবারের কাজের মতো নয়—এটি অটোপাইলটের মতো। আপনি ওয়ার্কলোডগুলোকে “বেবিসিট” করেন না; আপনি ইচ্ছা ঘোষণা করেন, এবং কন্ট্রোলারগুলো ক্লাস্টারকে সেই আউটকামের দিকে চালিত রাখে।
এই প্যাটার্নটির ফলে কুবেরনেটিস বাস্তব বিশ্বের সমস্যাগুলোর প্রতিরোধে স্থিতিশীল:
ব্যর্থতাগুলোকে বিশেষ কেস হিসেবে না দেখে কন্ট্রোলারগুলো এগুলোকে “স্টেট মিসম্যাচ” হিসেবে দেখে এবং একইভাবে প্রতিবার ফিক্স করে।
পরম্পরাগত অটোমেশন স্ক্রিপ্ট প্রায়ই একটি স্থিতিশীল পরিবেশ ধরে চলে: ধাপ A চালাও, তারপর B, তারপর C। বিতরণকৃত সিস্টেমে সেই স্টেবল-অ্যাসাম্পশনগুলো নিয়মিত ভেঙে যায়। কন্ট্রোলারগুলো ভালোভাবে স্কেল করে কারণ তারা আইডেম্পোটেন্ট (বারবার চালালেও নিরাপদ) এবং অবশেষে সামঞ্জস্যপূর্ণ (লক্ষ্য পৌঁছানো পর্যন্ত বারবার চেষ্টা করে)।
আপনি যদি একটি Deployment ব্যবহার করে থাকেন, তাহলে আপনি কন্ট্রোল লুপের উপর নির্ভর করছেন। আন্ডার দ্য হুড, কুবেরনেটিস একটি ReplicaSet কন্ট্রোলার ব্যবহার করে অনুরোধকৃত পরিমাণ পড নিশ্চিত করতে—এবং একটি Deployment কন্ট্রোলার রোলিং আপডেট ও রোলব্যাকগুলি নিয়মিতভাবে পরিচালনা করে।
কুবেরনেটিস “শুধু কনটেইনার” শিডিউল করতে পারতো, কিন্তু জো বেডা’র টিম পড পরিচয় করিয়েছিল যাতে ক্লাস্টার যেটা মেশিনে রাখে তার সবচেয়ে ছোট ডেপ্লয়েবল ইউনিট হয়। মূল ধারণা: বহু বাস্তব অ্যাপ একক প্রসেস নয়; তারা একটি ছোট গ্রুপ—কয়েকটি ঘনিষ্ঠভাবে যুক্ত প্রসেস—যারা একসাথে থাকতে হবে।
পড একটি বা একাধিক কনটেইনারকে আবরণ করে যা একই ভাগ্য শেয়ার করে: তারা একসাথে শুরু হয়, একই নোডে চলে, এবং একসাথে স্কেল করে। এতে সাইডকার প্যাটার্নগুলো স্বভাবসিদ্ধ হয়—লগ শিপার, প্রক্সি, কনফিগ রিলোডার, বা সিকিউরিটি এজেন্ট যা মূল অ্যাপের সঙ্গে সর্বদা থাকা উচিত।
এই হেল্পারগুলো প্রত্যেক অ্যাপে ইন্টিগ্রেট করানোর বদলে কুবেরনেটিস আপনাকে আলাদা কনটেইনার হিসেবে প্যাকেজ করতে দেয় যা তবুও একক ইউনিট হিসেবে আচরণ করে।
পড দুটি গুরুত্বপূর্ণ অনুমান বাস্তবায়নকে ব্যবহারযোগ্য করেছে:
localhost-এ সহজেই ম্যাচ করতে পারে।এই পছন্দগুলো কাস্টম গ্লু কোডের চাহিদা কমিয়েছে, সেইসাথে কনটেইনারগুলোকে প্রসেস লেভেলে বিচ্ছিন্ন রাখে।
নতুন ব্যবহারকারীরা প্রায়ই ভাবেন “এক কনটেইনার = এক অ্যাপ,” তারপর পড-স্তরের ধারণায় আটকে পড়েন: রিস্টার্ট, IP, এবং স্কেলিং। অনেক প্ল্যাটফর্ম এই বিষয়গুলোকে সহজ করে দেয় মতামতপ্রকাশক টেমপ্লেট (উদাহরণ: “ওয়েব সার্ভিস”, “ওয়ার্কার”, বা “জব”) দিয়ে—তাহলে টিমগুলো সাইডকার ও শেয়ার করা রিসোর্সের সুবিধা পায় কিন্তু প্রতিদিন পড মেকানিক্স নিয়ে ভাবতে হয় না।
কুবেরনেটিসে শান্তভাবে শক্তিশালী একটি সিদ্ধান্ত ছিল লেবেলকে প্রথম-শ্রেণীর মেটাডেটা এবং সিলেক্টরকে আইটেমগুলো “খুঁজে পাওয়ার” প্রধান উপায় করা। নির্দিষ্ট তিন-চারটি মেশিনকে হার্ড‑কোড করার বদলে (যেমন “এই তিন মেশিন আমার অ্যাপ চালায়”), কুবেরনেটিস আপনাকে সামগ্রিক বৈশিষ্ট্য দিয়ে গ্রুপ বর্ণনা করতে উৎসাহ দেয়।
একটি লেবেল হলো আপনি রিসোর্স—পড, ডেপ্লয়মেন্ট, নোড, নেমস্পেস—এটিতে সংযুক্ত করা একটি কী/ভ্যালু জোড়া। এগুলো কনসিসটেন্ট, কুয়েরি-যোগ্য ট্যাগ হিসেবে কাজ করে:
app=checkoutenv=prodtier=frontendকারণ লেবেল হালকা ও ইউজার-ডিফাইন্ড, আপনি আপনার প্রতিষ্ঠান অনুযায়ী বাস্তবতা মডেল করতে পারেন: টিম, কস্ট সেন্টার, কমপ্লায়েন্স জোন, রিলিজ চ্যানেল, বা অপারেশনের জন্য যা গুরুত্বপূর্ণ।
সিলেক্টরগুলো লেবেলগুলোর ওপর কুয়েরি (যেমন, “সব পড যেখানে app=checkout এবং env=prod”)। এটি ফিক্সড হোস্ট লিস্টের চেয়ে ভাল কারণ সিস্টেম পড reschedule, scale up/down, বা রোলআউটের সময় সদস্যদের পরিবর্তন অনুযায়ী অভিযোজিত হতে পারে। আপনার কনফিগ স্থিতিশীল থাকে এমনকি আন্ডারলাইনিং ইনস্ট্যান্সগুলো ক্রমাগত বদলালেও।
এই ডিজাইন অপারেশনালি স্কেল করে: আপনি হাজার হাজার ইনস্ট্যান্সের পরিচয় নয়—কয়েকটি অর্থবহ লেবেল সেট পরিচালনা করেন। এটিই লুজ কাপলিং-র সারমর্ম: কম্পোনেন্টগুলো এমন গ্রুপের সাথে কানেক্ট করে যা সদস্যতা নিরাপদে পরিবর্তিত হতে পারে।
লেবেল একবার আছে, সেগুলো প্ল্যাটফর্ম জুড়ে শেয়ার্ড শব্দভাণ্ডার হয়ে উঠে। সেগুলো ট্র্যাফিক রাউটিং (Services), নীতি সীমানা (NetworkPolicy), অবজার্ভেবিলিটি ফিল্টার (মেট্রিক/লগ), এমনকি খরচ ট্র্যাকিং ও চার্জব্যাকে ব্যবহার করা হয়। একটি সাদাসর্বভৌম ধারণা—বস্তুগুলোকে ধারাবাহিকভাবে ট্যাগ করা—একটি স্বয়ংক্রিয়তার পুরো ইকোসিস্টেম খুলে দেয়।
কুবেরনেটিসকে একটি উপায় দরকার ছিল নেটওয়ার্কিংকে পূর্বানুমেয় করা, যদিও কনটেইনারগুলো তা নয়। পড প্রতিস্থাপিত হয়, রিস্কেজিউল হয়, এবং স্কেল করা হয়—তাই তাদের IP ও যে মেশিনে চলছে তা বদলে যাবে। Service-এর মূল ধারণা সহজ: একটি পরিবর্তনশীল পড সেটের কাছে একটি স্থায়ী “ফ্রন্ট ডোর” প্রদান করা।
একটি সার্ভিস আপনাকে একটি ধারাবাহিক ভার্চুয়াল IP এবং DNS নাম দেয় (যেমন payments)। সেই নামের পেছনে কুবেরনেটিস ধারাবাহিকভাবে ট্র্যাক করে কোন পডগুলো সার্ভিসের সিলেক্টরের সাথে মেলে এবং ট্র্যাফিক রাউট করে। যদি একটি পড মরছে ও নতুন একটি আসে, সার্ভিস এখনও সঠিক জায়গায় পয়েন্ট করে—আপনি অ্যাপ সেটিংস পরিবর্তন করতে বাধ্য হন না।
এই পদ্ধতি অনেক ম্যানুয়াল ওয়্যারিং সরিয়েছে। IP কনফিগ ফাইলে bake করার বদলে অ্যাপগুলো নামের উপর নির্ভর করতে পারে। আপনি অ্যাপ ডেপ্লয় করেন, সার্ভিস ডেপ্লয় করেন, এবং অন্যান্য কম্পোনেন্ট DNS-এ তা খুঁজে পায়—কোনো কাস্টম রেজিস্ট্রি দরকার নেই, কোনো হার্ড‑কোডেড এন্ডপয়েন্ট নেই।
সার্ভিস ডিফল্ট লোড‑ব্যালান্সিং আচরণও পরিচয় করায় কিউ—এটি টিমগুলোকে প্রতিটি ইন্টার্নাল মাইক্রোসার্ভিসের জন্য নিজস্ব লোড ব্যালান্সার তৈরি করতে বাধ্য করেনি। ট্র্যাফিক ছড়ানো একটি একক পড ব্যর্থতার ব্লাস্ট রেডিয়াস কমায় এবং রোলিং আপডেটগুলোকে কম ঝুঁকিপূর্ণ করে।
সার্ভিস L4 (TCP/UDP) ট্র্যাফিকের জন্য দুর্দান্ত, কিন্তু এটি HTTP রাউটিং নিয়ম, TLS টার্মিনেশন, বা এজ পলিসি মডেল করে না। এই ঘটনাগুলোর জন্য Ingress এবং, ক্রমশ, Gateway API সার্ভিসের ওপর তৈরি করে হোস্টনেম, পাথ, এবং বাইরের এন্ট্রি পয়েন্টগুলো আরও পরিষ্কারভাবে হ্যান্ডল করে।
একটি নীরবভাবে বৈপ্লবিক প্রাথমিক সিদ্ধান্ত ছিল কুবেরনেটিসকে এমন একটি API হিসেবে দেখা যা নিয়ে বিল্ড করা যায়—একটি মনোলিথিক টুল হিসেবে নয় যা আপনি “ব্যবহার” করেন। সেই API-ফার্স্ট মনোভঙ্গি কুবেরনেটিসকে এমনভাবে তৈরি করেছে যে এটিকে এক ধরনের প্ল্যাটফর্ম হিসেবে বাড়ানো যায়, স্ক্রিপ্ট করা যায়, এবং গভর্ন করা যায়।
যখন API হলো সারফেস, প্ল্যাটফর্ম টিমগুলো স্ট্যান্ডার্ডাইজ করতে পারে কিভাবে অ্যাপ্লিকেশন বর্ণনা ও পরিচালনা করা হবে, তা নির্দিষ্ট UI, পাইপলাইন বা অভ্যন্তরীণ পোর্টালের উপর নির্ভর না করে। “অ্যাপ ডেপ্লয় করা” হয়ে ওঠে “API অবজেক্ট সাবমিট ও আপডেট করা” (যেমন Deployments, Services, ConfigMaps), যা অ্যাপ টিম ও প্ল্যাটফর্মের মধ্যে একটি পরিষ্কার চুক্তি।
কারণ সবকিছু একই API-র মাধ্যমে যায়, নতুন টুলগুলোর জন্য বিশেষ ব্যাকডোর প্রয়োজন পড়ে না। ড্যাশবোর্ড, GitOps কন্ট্রোলার, পলিসি ইঞ্জিন, এবং CI/CD সিস্টেম সবই স্বাভাবিক API ক্লায়েন্ট হিসেবে কাজ করতে পারে নির্দিষ্ট অনুমতিসহ।
এই সমমিতি গুরুত্বপূর্ণ: একই নিয়ম, auth, অডিটিং, ও admission কন্ট্রোল প্রযোজ্য হবে তা হোক একটি মানুষ, একটি স্ক্রিপ্ট, বা একটি অভ্যন্তরীণ প্ল্যাটফর্ম UI থেকে আসা রিকোয়েস্ট।
API ভার্সনিং কুবেরনেটিসকে এভাবে বিকাশ করতে দিয়েছে যাতে প্রতিটি ক্লাস্টার বা টুল রাতারাতি ভেঙে পড়ে না। ডিপ্রিকেশনগুলি পর্যায়ক্রমে করা যায়; কমপ্যাটিবিলিটি টেস্ট করা যায়; আপগ্রেড পরিকল্পনা করা যায়। বছরের পর বছর ক্লাস্টার চালানোর জন্য এটি হলো “আমরা আপগ্রেড করতে পারি” এবং “আমরা আটকে আছি”—এর মধ্যে পার্থক্য।
kubectl প্রকৃতপক্ষে কী প্রতিনিধিত্ব করেkubectl কুবেরনেটিস নয়—এটি একটি ক্লায়েন্ট। এই মানসিক মডেল টিমগুলোকে API ওয়ার্কফ্লো নিয়ে ভাবতে শেখায়: আপনি kubectl-কে অটোমেশন, ওয়েব UI, বা কাস্টম পোর্টালে বদলে ফেলতে পারেন, এবং সিস্টেম স্থিতিশীল থাকে কারণ চুক্তি হলো API-ই।
etcd) ও সঙ্গতিকুবেরনেটিসকে একটি একক “ট্রুথ সোর্স” দরকার হয়—ক্লাস্টারকে বর্তমানে কেমন দেখতে হবে তা জানার জন্য: কোন পড আছে, কোন নোড সুস্থ, কোন সার্ভিস কোনকে নির্দেশ করে, এবং কোন অবজেক্ট আপডেট হচ্ছে। সেটাই হল etcd।
etcd কি করে (সরল ভাষায়)etcd হলো কন্ট্রোল প্লেনের জন্য ডাটাবেস। আপনি যখন একটি Deployment তৈরি করেন, ReplicaSet স্কেল করেন, বা একটি Service আপডেট করেন, কাঙ্ক্ষিত কনফিগারেশন etcd-তে লেখা হয়। কন্ট্রোলার ও অন্যান্য কন্ট্রোল‑প্লেন কম্পোনেন্ট সেই স্টেট ওয়াচ করে এবং বাস্তবতাকে মিলাতে কাজ করে।
কুবেরনেটিস ক্লাস্টারটিতে অনেক মোভিং পার্ট আছে: শিডিউলার, কন্ট্রোলার, kubelet, অটোস্কেলার, অ্যাডমিশন চেক—এসব একসাথে প্রতিক্রিয়া করতে পারে। যদি তারা সবাই “ট্রুথ”-এর বিভিন্ন ভার্সন পড়ে, তাহলে রেস তৈরি হয়—যেমন দুইটি কম্পোনেন্ট একই পড নিয়ে প্রতিকূল সিদ্ধান্ত নেয়।
etcd-র শক্তিশালী কনসিসটেন্সি নিশ্চিত করে যে কন্ট্রোল প্লেন যখন বলে “এটাই বর্তমান স্টেট,” সবাই একইভাবে বোঝে। সেই সমন্বয়ই কন্ট্রোল লুপগুলোকে বিশৃঙ্খলা নয়, পূর্বানুমেয় করে তোলে।
কারণ etcd ক্লাস্টারের কনফিগারেশন এবং পরিবর্তনের ইতিহাস ধরে রাখে, তাই এটি আপনি রক্ষা করবেন এমন ডেটা যখন:
etcd স্ন্যাপশট ছাড়া ক্লাস্টার অবজেক্ট নির্ভরযোগ্যভাবে রিস্টোর করা যায় না।etcd-র স্বাস্থ্য ও স্ন্যাপশটিং মনোযোগ দিয়ে আপগ্রেড ঝুঁকি কমায়।etcd রিস্টোর করা প্রায়ই কন্ট্রোল প্লেনকে একই ইন্টেন্টসহ দ্রুত ফিরিয়ে আনার দ্রুততম পথ।কন্ট্রোল-প্লেন স্টেটকে গুরুত্বপূর্ণ ডেটা হিসেবে বিবেচনা করুন। নিয়মিত etcd স্ন্যাপশট নিন, রিস্টোর টেস্ট করুন, এবং ব্যাকআপ অফ-ক্লাস্টারে সংরক্ষণ করুন। যদি আপনি ম্যানেজড কুবেরনেটিস চালান, আপনার প্রোভাইডার কি ব্যাকআপ করে তা জানুন—আর কোনটা আপনাকে নিজে ব্যাকআপ রাখতে হবে (উদাহরণ: persistent volumes ও অ্যাপ-স্তরের ডেটা) তা পরিষ্কার করুন।
কুবেরনেটিস “ওয়ার্কলোড কোথায় চালাবেন” বিষয়টাকে অবহেলা করেনি। শুরুর দিকে শিডিউলার একটি পৃথক কম্পোনেন্ট ছিল যার কাজ ছিল পডকে এমন নোডে মেলানো যা আসলেই সেগুলো চালাতে পারে—ক্লাস্টারের বর্তমান স্টেট ও পডের চাহিদা ব্যবহার করে।
উপরের স্তরে, শিডিউলিং দুটি ধাপে সিদ্ধান্ত নেয়:
এই স্ট্রাকচার কুবেরনেটিস শিডিউলিংকে পুরোপুরি পুনরায় লিখতে না করেই বিকাশের সুযোগ দিয়েছে।
একটি গুরুত্বপূর্ণ ডিজাইন চয়েস ছিল দায়িত্বগুলো পরিষ্কার রাখা:
দায়িত্বগুলো আলাদা থাকায় এক এলাকায় উন্নতি (উদাহরণ: নতুন CNI প্লাগইন) অন্য এলাকায় একটি নতুন শিডিউলার মডেল চাপায় না।
রিসোর্স সচেতনতা requests ও limits দিয়ে শুরু হয়, শিডিউলারের কাছে অনুমান যোগ্য সিগন্যাল দেয়ার জন্য। এরপর থেকে কুবেরনেটিস সমৃদ্ধ নিয়ন্ত্রণ যোগ করেছে—node affinity/anti-affinity, pod affinity, priorities & preemption, taints ও tolerations, এবং topology-aware spreading—সবই একই ভিত্তির ওপর গড়ে উঠেছে।
এই পদ্ধতি আজকের শেয়ার্ড ক্লাস্টারগুলোকে সম্ভব করেছে: টিমগুলো গুরুত্বপুর্ণ সার্ভিসগুলো আলাদা করতে priorities ও taints ব্যবহার করতে পারে, যখন সবাই উচ্চ ইউটিলাইজেশনের সুবিধা পায়। উন্নত بن-প্যাকিং ও topology কন্ট্রোল দিয়ে প্ল্যাটফর্মগুলো ব্যয়-কার্যকরভাবে ওয়ার্কলোড রাখে বিনা নির্ভরযোগ্যতা বাদ দিয়ে।
কুবেরনেটিস একটি পূর্ণাঙ্গ, মতামতপূর্ণ PaaS নিয়ে আসতেও পারতো—বিল্ডপ্যাক, অ্যাপ রাউটিং নিয়ম, ব্যাকগ্রাউন্ড জবস, কনফিগ কনভেনশন ইত্যাদি সবকিছু অন্তর্ভুক্ত করে। পরিবর্তে জো বেডা ও প্রারম্ভিক টিম কোরকে ছোট রেখে একটি পরিষ্কার প্রতিশ্রুতি রাখেছে: ওয়ার্কলোড চালাও ও হিল করো নির্ভরযোগ্যভাবে, সেগুলো এক্সপোজ করো, এবং অটোমেট করার জন্য একটি সঙ্গত API দাও।
একটি “সম্পূর্ণ PaaS” সবাইকে এক ধরণের ওয়ার্কফ্লো ও এক সেট ট্রেডঅফ চাপিয়ে দিত। কুবেরনেটিস একটি বিস্তৃত ভিত্তি লক্ষ্য করেছিল যা বিভিন্ন প্ল্যাটফর্ম শৈলীকে সমর্থন করতে পারে—Heroku‑অনুরূপ ডেভেলপার সরলতা, এন্টারপ্রাইজ গভর্ন্যান্স, ব্যাচ + ML পাইপলাইন, বা বেয়ারবোনস ইনফ্রা—কোন একক পণ্য দর্শন হস্তান্তর না করে।
কুবেরনেটিসের এক্সটেনসিবিলিটি মেকানিজমগুলো ক্ষমতাগুলো বাড়ানোর নিয়ন্ত্রিত উপায় দেয়:
Certificate বা Database)।এটার মানে অভ্যন্তরীণ প্ল্যাটফর্ম টিম ও ভেন্ডররা প্লাগইন হিসেবে ফিচার শিপ করতে পারে, তা-ও কুবেরনেটিস প্রিমিটিভ (RBAC, নেমস্পেস, অডিট লগ) ব্যবহার করে।
ভেন্ডরদের জন্য এটি আলাদা পণ্য দিতে দেয় বোনা না করে কুবেরনেটিস ফর্ক করে। অভ্যন্তরীণ টিমদের জন্য এটি একটি “কুবেরনেটিসের ওপর প্ল্যাটফর্ম” তৈরির সুযোগ দেয় যা প্রতিষ্ঠানগত প্রয়োজন অনুযায়ী কাস্টমাইজ করা যায়।
ঝুঁকি হলো ইকোসিস্টেম স্প্রল: অত্যধিক CRD, ওভারল্যাপিং টুল, এবং অসঙ্গত কনভেনশন। গভার্ন্যান্স—স্ট্যান্ডার্ড, মালিকানাধীনতা, ভার্সনিং, ও ডিপ্রিকেশন নিয়ম—প্ল্যাটফর্ম কাজের অংশ হয়ে ওঠে।
কুবেরনেটিসের প্রারম্ভিক পছন্দগুলো কেবল একটি কনটেইনার শিডিউলার তৈরি করেনি—সেগুলো একটি পুনঃব্যবহারযোগ্য প্ল্যাটফর্ম কার্নেল তৈরি করেছে। এজন্য বহু আধুনিক ইন্টারনাল ডেভেলপার প্ল্যাটফর্ম (IDP) মূলত “কুবেরনেটিস প্লাস মতামতপ্রসূত ওয়ার্কফ্লো”। ডিক্লারেটিভ মডেল, কন্ট্রোলার, এবং একটি সঙ্গত API উচ্চতর-লেভেল পণ্যগুলো গড়ে তোলার উপযোগী করে তুলেছে—প্রতি বার ডেপ্লয়মেন্ট, রিকনসিলেশন, ও সার্ভিস ডিসকভারি পুনরায় আবিষ্কার না করেই।
কারণ API হলো প্রডাক্ট সারফেস, ভেন্ডর ও প্ল্যাটফর্ম টিমগুলো একটি কন্ট্রোল প্লেনে স্ট্যান্ডার্ডাইজ করতে পারে এবং বিভিন্ন এক্সপেরিয়েন্স উর্ধ্বে নির্মাণ করতে পারে: GitOps, মাল্টি‑ক্লাস্টার ম্যানেজমেন্ট, নীতি, সার্ভিস ক্যাটালগ, ডেপ্লয়মেন্ট অটোমেশন। এটাই কুবেরনেটিসকে ক্লাউড‑নেটিভ প্ল্যাটফর্মগুলোর সাধারণ মাধ্যম করে তোলে: ইন্টিগ্রেশনগুলো API-কে লক্ষ্য করে, নির্দিষ্ট UI-কে নয়।
পরিষ্কার আবস্ট্রাকশনের সত্ত্বেও, সবচেয়ে কষ্টকর কাজ এখনও অপারেশনাল:
প্রশ্ন করুন যা অপারেশনাল পরিপক্কতা প্রকাশ করবে:
একটি ভালো প্ল্যাটফর্ম cognitive লোড কমায় তবে আন্ডারলাইনিং কন্ট্রোল প্লেন লুকোয় না বা এস্কেপ হ্যাচগুলো কষ্টকর করে না।
একটি বাস্তবিক লেন্স: প্ল্যাটফর্ম কি টিমগুলোকে “আইডিয়া → চালু সার্ভিস” এ সাহায্য করে এমনভাবে, যাতে প্রত্যেকে প্রথম দিনে কুবেরনেটিস বিশেষজ্ঞ হতে বাধ্য না হয়? “vibe‑coding” ধরনের টুল—যেমন Koder.ai—এই ধারনায় প্রবণ: চ্যাট থেকে বাস্তব অ্যাপ তৈরি, (React ওয়েব, Go ব্যাকএন্ড PostgreSQL সহ, Flutter মোবাইল) এবং planning mode, snapshots, rollback মতো ফিচার দিয়ে দ্রুত পুনরাবৃত্তি করা। আপনি এমন কিছু গ্রহণ করুন বা নিজস্ব পোর্টাল বানান—লক্ষ্য একই: কুবেরনেটিসের শক্তিশালী প্রিমিটিভ বজায় রেখে তাদের চারপাশের ওয়ার্কফ্লো ওভারহেড কমানো।
কুবেরনেটিস জটিল মনে হতে পারে, কিন্তু এর অনেক “অদ্ভুততা” ইচ্ছে করে রাখা—এগুলো ছোট প্রিমিটিভের সেট যা বিভিন্ন ধরনের প্ল্যাটফর্মে যোগ যায়।
প্রথম: “কুবেরনেটিস শুধু Docker অর্কেস্ট্রেশন।” কুবেরনেটিস প্রধানত কনটেইনার শুরু করার বিষয়ে নয়। এটি হলো ধারাবাহিকভাবে ডেজায়ার্ড স্টেট (আপনি যা চলতে চান) এবং অ্যাকচুয়াল স্টেট (বাস্তবে কি হচ্ছে) মেলানো, ব্যর্থতা, রোলআউট, এবং পরিবর্তিত চাহিদার মধ্যে।
দ্বিতীয়: “কুবেরনেটিস নিলে সবই মাইক্রোসার্ভিস হয়ে যাবে।” কুবেরনেটিস মাইক্রোসার্ভিসকে সমর্থন করে, তবে এটি মনোলিথ, ব্যাচ জব, এবং অভ্যন্তরীণ প্ল্যাটফর্মও সমর্থন করে। ইউনিটগুলো (পড, সার্ভিস, লেবেল, কন্ট্রোলার, API) নিরপেক্ষ—আপনার আর্কিটেকচার পছন্দগুলো সরঞ্জামের দ্বারা নির্ধারিত নয়।
কঠিন অংশগুলি সাধারণত YAML বা পড নয়—এগুলো হলো নেটওয়ার্কিং, সিকিউরিটি, এবং বহু‑টিম ব্যবহার: পরিচয় ও অ্যাক্সেস, সিক্রেটস ম্যানেজমেন্ট, নীতিমালা, ingress, অবজার্ভেবিলিটি, সাপ্লাই‑চেইন কন্ট্রোল, এবং এমন গার্ডরেইল তৈরি করা যাতে টিমগুলো নিরাপদে শিপ করতে পারে একে অপরকে কাঁদাতে না।
প্ল্যান করার সময় মূল নকশা বাজিগুলো মাথায় রাখুন:
আপনার প্রকৃত চাহিদাগুলো কুবেরনেটিস প্রিমিটিভ ও প্ল্যাটফর্ম লেয়ারে ম্যাপ করুন:
ওয়ার্কলোড → Pods/Deployments/Jobs
কানেক্টিভিটি → Services/Ingress
অপারেশনস → কন্ট্রোলার, নীতি, ও অবজার্ভেবিলিটি
যদি আপনি মূল্যায়ন বা স্ট্যান্ডার্ডাইজ করছেন, এই ম্যাপ লিখে স্টেকহোল্ডারদের সঙ্গে রিভিউ করুন—এবং ধাপে ধাপে প্ল্যাটফর্ম বানান গ্যাপগুলোর ওপর নয় ট্রেন্ডের ওপর।
যদি আপনি “বিল্ড” পাশটা দ্রুত করতে চান (শুধু “রান” পাশ নয়), তাহলে ভাবুন আপনার ডেলিভারি ওয়ার্কফ্লো কিভাবে ইরাড ইনটেন্টকে ডেপ্লয়েবল সার্ভিসে রূপ দেয়। কিছু টিমের জন্য এটা হল কিউরেটেড টেমপ্লেট; অন্যদের জন্য এটা AI-সহায়িত ওয়ার্কফ্লো (যেমন Koder.ai) যা দ্রুত اولیه কাজ তৈরি করে এবং পরে সোর্স‑কোড এক্সপোর্ট করে গভীর কাস্টমাইজেশনের জন্য—এবং আপনার প্ল্যাটফর্মের তলে কুবেরনেটিসের মূল নকশা সিদ্ধান্তগুলো উপকৃত হয়।
কনটেইনার অর্কেস্ট্রেশন হলো সেই স্বয়ংক্রিয়তা যা মেশিন ব্যার হওয়া, ট্র্যাফিক পরিবর্তন বা ডেপ্লয়মেন্টের সময় অ্যাপ্সগুলিকে চালু রাখে। বাস্তবে এটি করে:
Kubernetes বিভিন্ন অবকাঠামো পরিবেশ জুড়ে এই কাজগুলো করার জন্য একটি সঙ্গতিময় মডেল জনপ্রিয় করেছে।
প্রাথমিক সমস্যা ছিল কনটেইনারগুলো শুরু করা না—সমস্যা ছিল সঠিক কনটেইনারগুলোকে সঠিক রূপে, ক্রমাগত পরিবর্তন সত্ত্বেও, চালু রাখা। বড় পরিমাণে অপারেশনগুলোতে নিয়মিত ব্যর্থতা ও ড্রিফট দেখা দেয়:
Kubernetes একটি স্ট্যান্ডার্ড কন্ট্রোল প্লেন এবং শব্দভাণ্ডার দেয়ার মাধ্যমে অপারেশনগুলোকে পুনরাবৃত্তিযোগ্য এবং পূর্বানুমেয় করতে চেয়েছিল।
ডিক্লারেটিভ সিস্টেমে আপনি যে আউটকাম চান তা বর্ণনা করেন (উদাহরণ: “3 রেপ্লিকা চালাও”), এবং সিস্টেম ধারাবাহিকভাবে বাস্তবতাকে সেই আউটকামের সাথে মেলাতে কাজ করে।
প্র্যাকটিক্যাল ওয়ার্কফ্লো:
kubectl apply বা GitOps)এটি “গোপন রানবুক” কমায় এবং পরিবর্তনগুলোকে ad-hoc কমান্ডের বদলে ডিফ হিসেবে রিভিউযোগ্য করে তোলে।
কন্ট্রোলারগুলো হলো কন্ট্রোল লুপ যা বারবার:
এই ডিজাইন সাধারণ ব্যর্থতাগুলোকে বিশেষ কেস না ধরে রুটিন হিসেবে মোকাবিলা করে। উদাহরণস্বরূপ, যদি একটি পড ক্র্যাশ করে বা একটি নোড হারিয়ে যায়, সংশ্লিষ্ট কন্ট্রোলার স্রেফ দেখবে “রেপ্লিকা লক্ষ্য সংখ্যার চেয়ে কম” এবং প্রতিস্থাপন তৈরি করবে।
কুবেরনেটিস পডগুলো (নির্দিষ্ট কনটেইনার নয়) শিডিউল করে, কারণ অনেক বাস্তব ওয়ার্কলোডে ঘনিষ্ঠভাবে যুক্ত হেল্পার প্রক্রিয়া লাগে।
পড দিয়ে সম্ভব হয়:
localhost-এ যোগাযোগ)নীতিগতভাবে: পডগুলোকে ছোট ও সঙ্গতিশীল রাখুন — এমন কনটেইনারগুলোকে গ্রুপ করুন যেগুলো লাইফসাইকেল, নেটওয়ার্ক আইডেন্টিটি বা লোকাল ডেটা শেয়ার করে।
লেবেল হলো লাইটওয়েট কী/ভ্যালু ট্যাগ (উদাহরণ: app=checkout, env=prod) এবং সিলেক্টর হলো সেই লেবেলগুলোর উপর করা কুয়েরি।
এটি গুরুত্বপূর্ণ কারণ পডগুলো ক্ষণস্থায়ী: রিসোর্সগুলো পুনরায় শিডিউল, স্কেল বা প্রতিস্থাপিত হয়। লেবেল/সিলেক্টর ব্যবহার করলে সম্পর্কগুলো স্থিতিশীল থাকে (“এই লেবেলগুলোর সব পড”) এমনকি সদস্য বদলালেও।
অপারেশনাল টিপ: একটি ছোট লেবেল ট্যাক্সোনমি (app, team, env, tier) স্ট্যান্ডার্ড করুন এবং পরবর্তীতে বিশৃঙ্খলা এড়াতে নীতি দিয়ে এটি প্রয়োগ করুন।
একটি সার্ভিস পডদের পরিবর্তনশীল সেটের কাছে একটি স্থায়ী ভার্চুয়াল IP এবং DNS নাম দেয়।
সার্ভিস ব্যবহার করবেন যখন:
HTTP রাউটিং, TLS টার্মিনেশন এবং এজ নীতির জন্য সাধারণত সার্ভিসের ওপর Ingress বা Gateway API লেয়ার করা হয়।
কুবেরনেটিস API-কে প্রধান প্রডাক্ট সারফেস হিসেবে ধরে: সবকিছুই API অবজেক্ট (Deployments, Services, ConfigMaps ইত্যাদি)। টুলগুলো—kubectl, CI/CD, GitOps, ড্যাশবোর্ড—সব API ক্লায়েন্ট মাত্র।
প্র্যাকটিক্যাল সুবিধা:
যদি আপনি একটি ইন্টারনাল প্ল্যাটফর্ম বানান, ওয়ার্কফ্লো ডিজাইন করুন API চুক্তির চারপাশে, কোনো নির্দিষ্ট UI-এর উপর নয়।
etcd হলো কন্ট্রোল প্লেনের ডাটাবেজ এবং ক্লাস্টারের স্যোর্স অফ ট্রুথ: কোন পড আছে, কোন নোড সুস্থ, কোন সার্ভিস কোন পডগুলোকে নির্দেশ করে—এসব তথ্যই এখানে থাকে। কন্ট্রোলার এবং অন্যান্য কন্ট্রোল-প্লেন কম্পোনেন্ট এটাই দেখেন এবং বাস্তবতাকে মিলানোর চেষ্টা করেন।
প্র্যাকটিক্যাল নির্দেশনা:
etcd-কে গুরুত্বপূর্ণ ডেটা হিসেবে বিবেচনা করুনম্যানেজড কুবেরনেটিসে আপনার প্রোভাইডার কি ব্যাকআপ করে তা জানুন—আর কোনটা আলাদা ব্যাকআপ প্রয়োজন (উদাহরণ: persistent volumes ও অ্যাপ ডেটা) তা নির্ধারণ করুন।
কুবেরনেটিস কোরে ছোট এবং নির্দিষ্ট প্রতিশ্রুতি নিয়ে রাখা হয়েছে, এবং লক্ষ্য করা হয়েছে যে বৈশিষ্ট্যগুলো এক্সটেনশন দিয়ে যোগ করা যাবে:
Certificate, Database)।এটি প্ল্যাটফর্ম তৈরি করতে দেয়, কিন্তু টুল স্প্রল বিরূপ প্রভাব ফেলতে পারে। মূল্যায়নের সময় জিজ্ঞেস করুন: