ধারণা

• 1: ওভারভিউ
• 1.1: কুবারনেটিস কম্পোনেন্ট
• 1.2: কুবারনেটিসে অবজেক্ট
• 2: ক্লাস্টার আর্কিটেকচার
• 2.1: Nodes
• 3: কন্টেইনার
• 4: ওয়ার্কলোড
• 4.1: পড
• 4.1.1: সাইডকার কন্টেইনার
• 4.2: ওয়ার্কলোড ম্যানেজমেন্ট
• 4.3: অটোস্কেলিং ওয়ার্কলোড
• 5: সার্ভিস, লোড ব্যালেন্সিং এবং নেটওয়ার্কিং
• 5.1: ইনগ্রেস
• 6: স্টোরেজ
• 7: কনফিগারেশন
• 8: নিরাপত্তা
• 9: নীতিমালা
• 10: শিডিউলিং, প্রিএম্পশন এবং ইভিকশন (Scheduling, Preemption and Eviction)
• 10.1: কুবারনেটিস শিডিউলার
• 11: ক্লাস্টার অ্যাডমিনিস্ট্রেশন
• 11.1: সার্টিফিকেট
• 11.2: ক্লাস্টার নেটওয়ার্কিং
• 12: কুবারনেটিসে উইন্ডোজ
• 13: কুবারনেটিস প্রসারিত করা
• 13.1: অপারেটর প্যাটার্ন
• 13.2: কম্পিউট, স্টোরেজ, এবং নেটওয়ার্কিং এক্সটেনশন
• 13.3: কুবারনেটিস API প্রসারিত করা

1 - ওভারভিউ

এই পৃষ্ঠাটি কুবারনেটিসের একটি পরিপূর্ণ ধারণা প্রদান করে ।

কুবারনেটিস হল একটি পোর্টেবল, বর্ধনশীল, ওপেন সোর্স প্ল্যাটফর্ম যা কনটেইনারাইজড ওয়ার্কলোড এবং পরিষেবাগুলি পরিচালনা করার জন্য, ঘোষণামূলক কনফিগারেশন এবং অটোমেশন উভয়কেই সহজতর করে। এটির একটি বড়, দ্রুত বর্ধনশীল ইকোসিস্টেম রয়েছে। কুবারনেটিস পরিষেবাগুলি, সমর্থন, এবং সরঞ্জাম ব্যাপকভাবে সহজলভ্য।

কুবারনেটিস নামটি গ্রীক থেকে এসেছে, যার অর্থ হেলমসম্যান বা পাইলট। "K" এবং "s" এর মধ্যে আটটি অক্ষর গণনা করার ফলে একটি সংক্ষিপ্ত রূপ K8s। গুগল ২০১৪ সালে কুবারনেটিস প্রজেক্টটি ওপেন সোর্স করেছে। কুবারনেটিস 15 বছরেরও বেশি সময় ধরে Google-এর অভিজ্ঞতাকে একত্রিত করেছে যা কমিউনিটির সেরা আইডিয়া এবং অনুশীলনের সাথে স্কেলে উৎপাদন কাজের চাপ চালানোর।

অতিতে যাই

চলুন অতিতে যেয়ে এক নজরে দেখে নেওয়া যাক কেন কুবারনেটিস এতটা কাজে লাগে।

ঐতিহ্যবাহী ডিপ্লয়মেন্টের যুগ: প্রথম দিকে, সংস্থাগুলি ফিজিক্যাল সার্ভারগুলিতে অ্যাপ্লিকেশন চালাত। একটি ফিজিক্যাল সার্ভারে অ্যাপ্লিকেশনের জন্য রিসোর্স সীমানা নির্ধারণ করার কোন উপায় ছিল না, এবং এর ফলে রিসোর্স বরাদ্দ সমস্যা হয়েছে। উদাহরণস্বরূপ, যদি একটি ফিজিক্যাল সার্ভারে একাধিক অ্যাপ্লিকেশান চালিত হয়, এমন উদাহরণ হতে পারে যেখানে একটি অ্যাপ্লিকেশন বেশিরভাগ সংস্থান গ্রহণ করবে, এবং ফলস্বরূপ, অন্যান্য অ্যাপ্লিকেশনগুলি কম পারফর্ম করবে। এই জন্য একটি সমাধান একটি ভিন্ন ফিজিক্যাল সার্ভারে প্রতিটি অ্যাপ্লিকেশন চালানো হবে। কিন্তু সম্পদের অব্যবহৃত হওয়ার কারণে এটির মাপকাঠিি ঠিক করা যায়নি এবং অনেকগুলি ফিজিক্যাল সার্ভার বজায় রাখা সংস্থাগুলির জন্য ব্যয়বহুল ছিল।

ভার্চুয়ালাইজড ডিপ্লয়মেন্টর যুগ: একটি সমাধান হিসাবে, ভার্চুয়ালাইজেশন চালু করা হয়েছিল। এটি আপনাকে একটি একক ফিজিক্যাল সার্ভারের CPU-তে একাধিক ভার্চুয়াল মেশিন (VMs) চালানো যায়। ভার্চুয়ালাইজেশন অ্যাপ্লিকেশনগুলিকে VM-এর মধ্যে বিচ্ছিন্ন করার অনুমতি দেয় এবং একটি স্তরের নিরাপত্তা প্রদান করে কারণ একটি অ্যাপ্লিকেশনের তথ্য অন্য অ্যাপ্লিকেশন দ্বারা অবাধে অ্যাক্সেস করা যায় না।

ভার্চুয়ালাইজেশন একটি ফিজিক্যাল সার্ভারে রিসোর্সগুলির আরও ভালো ব্যবহারের অনুমতি দেয় এবং আরও ভাল স্কেলেবিলিটির অনুমতি দেয় কারণ একটি অ্যাপ্লিকেশন সহজে যোগ বা আপডেট করা যায়, হার্ডওয়্যার খরচ কমায় এবং আরও অনেক কিছু। ভার্চুয়ালাইজেশনের মাধ্যমে আপনি ডিসপোজেবল ভার্চুয়াল মেশিনের একটি ক্লাস্টার হিসাবে ফিজিক্যাল সম্পদের একটি সেট উপস্থাপন করতে পারেন।

প্রতিটি VM হল একটি সম্পূর্ণ মেশিন যা ভার্চুয়ালাইজড হার্ডওয়্যারের উপরে নিজস্ব অপারেটিং সিস্টেম সহ সমস্ত উপাদান চালায়।

কন্টেইনার স্থাপনের যুগ: কনটেইনারগুলি VM-এর মতোই, তবে অ্যাপ্লিকেশনগুলির মধ্যে অপারেটিং সিস্টেম (OS) ভাগ করার জন্য তাদের শিথিল বিচ্ছিন্নতা বৈশিষ্ট্য রয়েছে৷ অতএব, কন্টেইনারগুলোকে হালকা বলে মনে করা হয়। একটি VM-এর মতো, একটি কনটেইনারের নিজস্ব ফাইল সিস্টেম, CPU ভাগ, মেমরি, প্রক্রিয়া স্থান এবং আরও অনেক কিছু রয়েছে। যেহেতু এগুলি অন্তর্নিহিত অবকাঠামো থেকে আলাদা করা হয়েছে, তারা ক্লাউড এবং OS ডিস্ট্রিবিউশন জুড়ে বহনযোগ্য।

কন্টেইনারগুলো জনপ্রিয় হয়ে উঠেছে কারণ তারা অতিরিক্ত সুবিধা প্রদান করে, যেমন:

• এজাইল (Agile) অ্যাপ্লিকেশন তৈরি এবং ডিপ্লয়মেন্টয়: ভিএম ইমেজ (VM Image) ব্যবহারের তুলনায় কন্টেইনার ইমেজ (Container Image) তৈরির সহজতা এবং দক্ষতা বেশি।
• ক্রমাগত বিকাশ, একীকরণ এবং ডিপ্লয়মেন্ট: নির্ভরযোগ্য এবং ঘন ঘন কন্টেইনার ইমেজ তৈরি এবং ডিপ্লয়মেন্টের জন্য প্রদান করে দ্রুত এবং দক্ষ রোলব্যাকের (ইমেজ অপরিবর্তনীয়তার কারণে) সাথে ।
• ডেভ (Dev) এবং অপস (Ops) উদ্বেগের বিচ্ছেদ: বিল্ড/রিলিজের সময়ে অ্যাপ্লিকেশন কন্টেইনার ইমেজ তৈরি করে ডিপ্লয়মেন্টের সময়ের তুলনায়, ফলস্বরূপ অ্যাপ্লিকেশনগুলি অবকাঠামো থেকে বিচ্ছিন্ন হয়।
• পর্যবেক্ষণযোগ্যতা: শুধুমাত্র OS-স্তরের তথ্য এবং মেট্রিক্সই নয়, প্রয়োগের স্বাস্থ্য এবং অন্যান্য সংকেতও।
• ডেভেলপমেন্ট, টেস্টিং এবং প্রোডাকশন জুড়ে পরিবেশগত সামঞ্জস্য: একটি ল্যাপটপে ক্লাউডের মতোই চলে।
• ক্লাউড এবং ওএস ডিস্ট্রিবিউশন পোর্টেবিলিটি: উবুন্টু (Ubuntu), রেল (RHEL), কোরওস (CoreOS), অন-প্রিমিসেস (on-premises), প্রধান পাবলিক ক্লাউডসর উপর, এবং অন্য কোথাও চলে।
• অ্যাপ্লিকেশন-কেন্দ্রিক ব্যবস্থাপনা: ভার্চুয়াল হার্ডওয়্যারে একটি OS চালানো থেকে লজিক্যাল রিসোর্স ব্যবহার করে একটি OS-এ একটি অ্যাপ্লিকেশন চালানো পর্যন্ত বিমূর্ততার স্তর বাড়ায়।
• ঢিলেঢালাভাবে সংযুক্ত, বিতরণ করা, স্থিতিস্থাপক, মুক্ত মাইক্রো-পরিষেবা: অ্যাপ্লিকেশনগুলিকে ছোট, স্বাধীন টুকরোগুলিতে বিভক্ত করা হয় এবং গতিশীলভাবে স্থাপন ও পরিচালনা করা যায় – একটি বড় একক-উদ্দেশ্য মেশিনে চলমান একটি মনোলিথিক স্ট্যাক নয়।.
• রিসোর্স আইসোলেশন: অনুমানযোগ্য অ্যাপ্লিকেশন কর্মক্ষমতা।
• রিসোর্স ব্যবহার: উচ্চ দক্ষতা এবং ঘনত্ব।

আপনার কেন কুবারনেটিস দরকার এবং এটি কী করতে পারে

কন্টেইনারসমূহ অ্যাপ্লিকেশন একত্রকরণ এবং চালানোর একটি ভালো উপায়৷ একটি উৎপাদন পরিবেশে, কন্টেইনারসমূহ এমন ভাবে পরিচালনা করতে হবে যা অ্যাপ্লিকেশনগুলি চালানোর সময় যেন কোনো ডাউনটাইম না থাকে তা নিশ্চিত করবে। উদাহরণস্বরূপ, যদি একটি কন্টেইনার ডাউন হয়, তাহলে অন্য কন্টেইনার কে সেই মুহূর্তে চালু হতে হবে। আর এই অবস্থাটি একটি সিস্টেম দ্বারা পরিচালিত হলে এটি কি সহজ হবে না?

এভাবেই কুবারনেটস উদ্ধারে আসে!। কুবারনেটিস একটি কাঠামো প্রদান করে আপনাকে সিস্টেমগুলিকে স্থিতিস্থাপকভাবে চালানোর জন্য । এটি আপনার অ্যাপ্লিকেশনের জন্য স্কেলিং এবং ফেইলওভারের যত্ন নেয়, ডিপ্লয়মেন্টের নিদর্শন প্রদান করে এবং আরও অনেক কিছু করে। উদাহরণস্বরূপ, কুবারনেটিস সহজেই আপনার সিস্টেমের জন্য একটি ক্যানারি ডিপ্লয়মেন্ট পরিচালনা করতে পারে।

কুবারনেটিস আপনাকে সরবরাহ করে:

• পরিষেবা আবিষ্কার এবং লোড ব্যালেন্সিং কুবারনেটিস ডিএনএস নাম ব্যবহার করে বা তাদের নিজস্ব আইপি ঠিকানা ব্যবহার করে একটি ধারক প্রকাশ করতে পারে। একটি কন্টেইনারে ট্রাফিক বেশি হলে, কুবারনেটিস লোড ব্যালেন্স এবং নেটওয়ার্ক ট্র্যাফিক বিতরণ করতে সক্ষম হয় যাতে ডিপ্লয়মেন্ট স্থিতিশীল থাকে।
• স্টোরেজ অর্কেস্ট্রেশন কুবারনেটিস আপনাকে স্বয়ংক্রিয়ভাবে আপনার পছন্দের একটি স্টোরেজ সিস্টেম মাউন্ট করার অনুমতি দেয়, যেমন স্থানীয় স্টোরেজ, পাবলিক ক্লাউড প্রদানকারী এবং আরও অনেক কিছু।
• স্বয়ংক্রিয় রোলআউট এবং রোলব্যাক আপনি কুবারনেটিস ব্যবহার করে আপনার স্থাপন করা কন্টেইনার জন্য পছন্দসই অবস্থা বর্ণনা করতে পারেন এবং এটি একটি নিয়ন্ত্রিত হারে প্রকৃত অবস্থাকে পছন্দসই অবস্থায় পরিবর্তন করতে পারে। উদাহরণস্বরূপ, আপনি কুবারনেটিস দিয়ে স্বয়ংক্রিয়ভাবে আপনার ডিপ্লয়মেন্টের জন্য নতুন কন্টেইনার তৈরি, বিদ্যমান কন্টেইনারগুলি সরাতে এবং নতুন কন্টেইনারে তাদের সমস্ত রিসোর্স গ্রহণ করতে পারেন।
• স্বয়ংক্রিয় বিন প্যাকিং আপনি কুবারনেটিসকে নোডের একটি ক্লাস্টার প্রদান করেন যা এটি কন্টেইনারাইজড কাজ চালাতে ব্যবহার করতে পারে। আপনি কুবারনেটিসকেে বলুন প্রতিটি কন্টেইনারের কত CPU এবং মেমরি (RAM) প্রয়োজন। কুবারনেটিস আপনার সম্পদের সর্বোত্তম ব্যবহার করতে আপনার নোডগুলিতে কন্টেইনারে মানানসই করতে পারে।
• স্ব-নিরাময় কুবারনেটিস ব্যর্থ কন্টেইনারগুলি পুনরায় চালু করে, কন্টেইনারগুলিকে প্রতিস্থাপন করে, এমন কন্টেইনারগুলিকে বন্ধ করে যেটি আপনার ব্যবহারকারী-সংজ্ঞায়িত স্বাস্থ্য পরীক্ষায় সাড়া দেয় না এবং ক্লায়েন্টদের কাছে তাদের বিজ্ঞাপন দেবেন না যতক্ষণ না এটি পরিবেশন করার জন্য প্রস্তুত।
• গোপন এবং কনফিগারেশন ব্যবস্থাপনা কুবারনেটিস আপনাকে সংবেদনশীল তথ্য সংরক্ষণ এবং পরিচালনা করতে দেয়, যেমন পাসওয়ার্ড, ওঅথ (OAuth) টোকেন এবং এসএসএইচ (SSH) কী। আপনি গোপনীয়তা এবং অ্যাপ্লিকেশনের কনফিগারেশন স্থাপন এবং আপডেট করতে পারবেন আপনার কন্টেইনার চিত্রগুলি পুনর্নির্মাণ করা ছাড়াই, এবং আপনার স্ট্যাক কনফিগারেশনের গোপনীয়তা প্রকাশ না করে।
• ব্যাচ এক্সেকিউশন পরিষেবাগুলি ছাড়াও, কুবারনেটস আপনার ব্যাচ এবং সিআই ওয়ার্কলোডগুলি পরিচালনা করতে পারে, যদি ইচ্ছা হয় তবে ব্যর্থ কন্টেইনারগুলি প্রতিস্থাপন করতে পারে।
• অনুভূমিক স্কেলিং একটি সাধারণ কমান্ডের সাহায্যে, একটি UI সহ, বা স্বয়ংক্রিয়ভাবে CPU ব্যবহারের উপর ভিত্তি করে আপনার অ্যাপ্লিকেশনকে উপরে এবং নীচে স্কেল করুন।
• IPv4/IPv6 ডুয়াল-স্ট্যাক পড এবং পরিষেবাগুলিতে IPv4 এবং IPv6 ঠিকানাগুলির বরাদ্দ৷
• এক্সটেনসিবিলিটির জন্য ডিজাইন আপস্ট্রিম (upstream) সোর্স কোড পরিবর্তন না করে আপনার কুবারনেটিস ক্লাস্টারে বৈশিষ্ট্য যোগ করুন।

কুবারনেটিস কি নয়

কুবারনেটিস একটি ঐতিহ্যগত, সর্ব-অন্তর্ভুক্ত PaaS (পরিষেবা হিসাবে প্ল্যাটফর্ম) সিস্টেম নয়। যেহেতু Kubernetes হার্ডওয়্যার স্তরের পরিবর্তে কন্টেইনার স্তরে কাজ করে, তাই এটি PaaS অফারগুলির জন্য সাধারণভাবে কিছু প্রযোজ্য বৈশিষ্ট্য প্রদান করে, যেমন ডিপ্লয়মেন্ট, স্কেলিং, লোড ব্যালেন্সিং, এবং ব্যবহারকারীদের তাদের লগিং, পর্যবেক্ষণ এবং সতর্কতা সমাধানগুলিকে একীভূত করতে দেয়৷ যাইহোক, কুবারনেটিস একচেটিয়া নয়, এবং এই ডিফল্ট সমাধান ঐচ্ছিক এবং প্লাগযোগ্য। কুবারনেটিস বিকাশকারী প্ল্যাটফর্ম তৈরির জন্য বিল্ডিং ব্লক সরবরাহ করে, কিন্তু যেখানে এটি গুরুত্বপূর্ণ সেখানে ব্যবহারকারীর পছন্দ এবং নমনীয়তা সংরক্ষণ করে।

কুবারনেটিস:

• সমর্থিত অ্যাপ্লিকেশনের ধরন সীমাবদ্ধ করে না। কুবারনেটিস একটি লক্ষ্য হল স্টেটলেস, স্টেটফুল এবং ডেটা-প্রসেসিং সহ অত্যন্ত বৈচিত্র্যময় কাজের চাপ কাজের ভার সমর্থন করা। যদি একটি অ্যাপ্লিকেশন একটি কন্টেইনারে চলতে পারে তবে কুবারনেটিসেও দুর্দান্ত চলা উচিত।
• সোর্স কোড স্থাপন করে না এবং আপনার অ্যাপ্লিকেশন তৈরি করে না। একটানা ইন্টিগ্রেশন, ডেলিভারি, এবং ডিপ্লোয়মেন্ট (CI/CD) ওয়ার্কফ্লোগুলি প্রতিষ্ঠানের সংস্কৃতি এবং পছন্দের পাশাপাশি প্রযুক্তিগত প্রয়োজনীয়তা দ্বারা নির্ধারিত হয়।
• অ্যাপ্লিকেশন-স্তরের পরিষেবা প্রদান করে না, যেমন মিডলওয়্যার (উদাহরণস্বরূপ, বার্তা বাস), ডেটা-প্রসেসিং ফ্রেমওয়ার্ক (উদাহরণস্বরূপ, স্পার্ক), ডাটাবেস (উদাহরণস্বরূপ, মাইএসকিউএল), ক্যাশে, বা বিল্ট-ইন পরিষেবা হিসাবে ক্লাস্টার স্টোরেজ সিস্টেম (উদাহরণস্বরূপ, Ceph)। এই ধরনের উপাদান চলতে পারে কুবারনেটিসে, এবং/অথবা পোর্টেবল মেকানিজমের মাধ্যমে কুবারনেটিস এ চলমান অ্যাপ্লিকেশন দ্বারা অ্যাক্সেস করা যেতে পারে, যেমন ওপেন সার্ভিস ব্রোকার।
• লগিং, মনিটরিং বা সতর্কতা সমাধান নির্দেশ করে না। এটি ধারণার প্রমাণ হিসাবে কিছু ইন্টিগ্রেশন প্রদান করে, এবং মেট্রিক্স সংগ্রহ এবং রপ্তানি করার প্রক্রিয়া।
• এটি কনফিগারেশন ভাষা/সিস্টেম প্রদান বা আদেশ দেয় না (উদাহরণস্বরূপ, Jsonnet)। এটি একটি ঘোষণামূলক এপিআই প্রদান করে যা ঘোষণামূলক স্পেসিফিকেশনের নির্বিচারে ফর্ম দ্বারা লক্ষ্য করা যেতে পারে।
• কোন ব্যাপক মেশিন কনফিগারেশন, রক্ষণাবেক্ষণ, ব্যবস্থাপনা প্রদান বা গ্রহণ করে না, বা স্ব-নিরাময় সিস্টেম।
• উপরন্তু, কুবারনেটিস একটি নিছক অর্কেস্ট্রেশন সিস্টেম নয়। আসলে, এটি অর্কেস্ট্রেশনের জন্য প্রয়োজনীয়তা দূর করে। অর্কেস্ট্রেশনের প্রযুক্তিগত সংজ্ঞা হল একটি সংজ্ঞায়িত ওয়ার্কফ্লো কার্যকর করা: প্রথমে A, তারপর B, তারপর C করুন। বিপরীতে, কুবারনেটিস স্বাধীন, কম্পোজযোগ্য একটি সেট নিয়ে গঠিত নিয়ন্ত্রণ প্রক্রিয়া যা ক্রমাগত বর্তমান অবস্থাকে প্রদত্ত পছন্দসই অবস্থার দিকে চালিত করে। আপনি A থেকে C পর্যন্ত কিভাবে যাবেন তা বিবেচ্য নয়। কেন্দ্রীভূত নিয়ন্ত্রণেরও প্রয়োজন নেই। এই সিস্টেমের ফলাফল যা ব্যবহার করা সহজ এবং আরও শক্তিশালী, মজবুত, স্থিতিস্থাপক এবং এক্সটেনসিবল।

এর পরের কি

• কুবারনেটিস উপাদান একবার দেখুন
• কুবারনেটিস এপিআই একবার দেখুন
• ক্লাস্টার আর্কিটেকচার একবার দেখুন
• শুরু করতে প্রস্তুত আপনি?

1.1 - কুবারনেটিস কম্পোনেন্ট

এই পেইজটি প্রয়োজনীয় কম্পোনেন্ট গুলোর একটি হাই-লেভেলের ওভারভিউ প্রদান করে যা একটি কুবারনেটিস ক্লাস্টার তৈরি করে।

মূল কম্পোনেন্ট গুলো

একটি কুবারনেটিস ক্লাস্টার একটি কন্ট্রোল প্লেন এবং এক বা একাধিক ওয়ার্কার নোড নিয়ে গঠিত। এখানে প্রধান কম্পোনেন্ট গুলোর একটি সংক্ষিপ্ত বিবরণ রয়েছে:

কন্ট্রোল প্লেন কম্পোনেন্ট গুলো

ক্লাস্টারের সামগ্রিক অবস্থা পরিচালনা করে:

kube-apiserver

মূল কম্পোনেন্ট সার্ভার যা কুবারনেটিস HTTP API প্রকাশ করে

etcd

সকল API সার্ভার ডেটার জন্য সামঞ্জস্যপূর্ণ এবং হাইলি-এভেইলেভেল কী ভ্যালু স্টোর

kube-scheduler

একটি নোডের সাথে এখনও আবদ্ধ নয় এমন পডগুলির সন্ধান করে এবং প্রতিটি পডকে একটি উপযুক্ত নোডে বরাদ্দ করে৷

kube-controller-manager

কুবারনেটিস API আচরণ বাস্তবায়ন করতে কন্ট্রোলার চালায়।

cloud-controller-manager (অপশনাল)

অন্তর্নিহিত ক্লাউড প্রদানকারী(গুলি) এর সাথে সমন্বিত করে।

নোড কম্পোনেন্ট গুলো

চলমান পড বজায় রাখে এবং কুবারনেটিস রানটাইম এনভায়রনমেন্ট প্রদান করে প্রতিটি নোডে চালায়:

kubelet

নিশ্চিত করে যে পডগুলো চলছে, তাদের কন্টেইনার সহ।

kube-proxy (optional)

সার্ভিসগুলো বাস্তবায়নের জন্য নোডগুলিতে নেটওয়ার্ক রুলস বজায় রাখে।

কন্টেইনার রানটাইম

কন্টেইনার চালানোর জন্য দায়ী সফ্টওয়্যার। আরো জানতে কন্টেইনার রানটাইম পড়ুন।

আপনার ক্লাস্টার প্রতিটি নোডে অতিরিক্ত সফ্টওয়্যার প্রয়োজন হতে পারে; উদাহরণস্বরূপ, আপনি লোকাল কম্পোনেন্টগুলো তত্ত্বাবধান করতে একটি লিনাক্স নোডে systemd চালাতে পারেন।

অ্যাডঅন

অ্যাডঅন কুবারনেটিসের কার্যকারিতা প্রসারিত করে। কয়েকটি গুরুত্বপূর্ণ উদাহরণের মধ্যে রয়েছে:

DNS

ক্লাস্টার-ওয়াইড DNS রেজোলিউশনের জন্য

Web UI (Dashboard)

একটি ওয়েব ইন্টারফেসের মাধ্যমে ক্লাস্টার পরিচালনার জন্য

Container Resource Monitoring

কন্টেইনার মেট্রিক্স সংগ্রহ এবং সংরক্ষণের জন্য

Cluster-level Logging

একটি কেন্দ্রীয় লগ স্টোরে কন্টেইনার লগ সংরক্ষণের জন্য

আর্কিটেকচারে ফ্লেক্সিবিলিটি

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

প্রতিটি কম্পোনেন্টের ব্যাপারে এবং আপনার ক্লাস্টার আর্কিটেকচার কনফিগার করার বিভিন্ন উপায় সম্পর্কে আরও বিস্তারিত তথ্যের জন্য, ক্লাস্টার আর্কিটেকচার পেইজটি দেখুন।

1.2 - কুবারনেটিসে অবজেক্ট

এই পৃষ্ঠাটি ব্যাখ্যা করে কুবারনেটিস API-তে কুবারনেটিস অবজেক্টগুলি কীভাবে প্রতিনিধিত্ব করা হয় এবং আপনি কিভাবে তা .yaml ফরম্যাটে প্রকাশ করতে পারেন।

কুবারনেটিস অবজেক্ট বোঝা

কুবারনেটিস অবজেক্ট হল কুবারনেটিস সিস্টেমের সত্তা সংরক্ষিত এন্টিটিগুলি। কুবারনেটিস এই এন্টিটিগুলি ব্যবহার করে আপনার ক্লাস্টারের অবস্থা প্রকাশ করতে। বিশেষভাবে, তারা বর্ণনা করতে পারে:

• কোন কন্টেনার অ্যাপ্লিকেশন কি রান করছে (এবং কোন নোডগুলিতে)
• ঐ অ্যাপ্লিকেশনগুলির জন্য রিসোর্স
• ঐ অ্যাপ্লিকেশনগুলির কিভাবে ব্যবহার করতে হবে, উদাহরণস্বরূপ রিস্টার্ট নীতি, আপগ্রেড, এবং ফল্ট-টলারেন্স

একটি কুবারনেটিস অবজেক্ট হল একটি "উদ্দেশ্যের রেকর্ড" - একবার আপনি অবজেক্ট তৈরি করে দিলে, কুবারনেটিস সিস্টেম সরাসরি এই অবজেক্টটি থাকার নিশ্চয়তার জন্য কাজ করবে। অবজেক্ট তৈরি করে আপনি সাধারণত কুবারনেটিস সিস্টেমকে বলে দিচ্ছেন যে আপনার ক্লাস্টারের ওয়ার্কলোড কি হবে; এটা হল আপনার ক্লাস্টারের কাঙ্ক্ষিত অবস্থা।

কুবারনেটিস অবজেক্টগুলির সাথে কাজ করতে - তা তৈরি, পরিবর্তন করতে বা মুছতে - আপনার কুবারনেটিস API ব্যবহার করতে হবে। উদাহরণস্বরূপ, যখন আপনি kubectl কমান্ড-লাইন ইন্টারফেস ব্যবহার করেন, তখন CLI আপনার জন্য প্রয়োজনীয় কুবারনেটিস API কল করে। আপনি একটি Client Libraries ব্যবহার করে নিজের প্রোগ্রামে কুবারনেটিস API সরাসরি ব্যবহার করতে পারেন।

অবজেক্ট স্পেক এবং স্ট্যাটাস

প্রায় সব কুবারনেটিস অবজেক্টের একটি spec এবং একটি status নেস্টেড অবজেক্ট ফিল্ড রয়েছে যা অবজেক্টের কনফিগারেশন নিয়ন্ত্রণ করে: অবজেক্টের spec এবং status। যে অবজেক্টগুলির spec থাকে, আপনার অবজেক্ট তৈরি করতে এটা নির্ধারণ করতে হবে যখন অবজেক্ট তৈরি করবেন, যে রিসোর্সের বৈশিষ্ট্য বর্ণনা প্রদান করবেন: এর কাঙ্ক্ষিত অবস্থা।

status অবজেক্টের বর্তমান অবস্থা বর্ণনা করে, যা কুবারনেটিস সিস্টেম এবং এর উপাদানগুলি প্রদান এবং আপডেট করে। কুবারনেটিস control plane সরাসরি এবং সক্রিয়ভাবে প্রতিটি অবজেক্টের বর্তমান অবস্থা পরিচালনা করে যাতে আপনার প্রদত্ত অবস্থা মিলে।

উদাহরণস্বরূপ: কুবারনেটিসে, একটি ডিপ্লয়মেন্ট একটি অবজেক্ট যা আপনার ক্লাস্টারে চলমান একটি অ্যাপ্লিকেশন প্রতিনিধিত্ব করতে পারে। ডিপ্লয়মেন্ট তৈরি করতে যখন আপনি ডিপ্লয়মেন্ট তৈরি করেন, আপনি ডিপ্লয়মেন্ট spec সেট করতে পারেন যে আপনি চাইছেন অ্যাপ্লিকেশনের তিনটি রিপ্লিকা চলমান থাকুক। কুবারনেটিস সিস্টেম ডিপ্লয়মেন্ট স্পেক পড়ে এবং আপনার প্রদত্ত ডিপ্লয়মেন্ট এর তিনটি ইনস্ট্যান্স চালু করে, এই স্ট্যাটাস আপনার স্পেক অনুসারে আপডেট করে। যদি সেই ইনস্ট্যান্সগুলোর মধ্যে কোনওটি ব্যর্থ হয় (একটি স্ট্যাটাস পরিবর্তন), কুবারনেটিস সিস্টেম স্পেক এবং স্ট্যাটাস মধ্যে পার্থক্যের প্রতিক্রিয়া দিয়ে একটি সংশোধন করে এই ক্ষেত্রে, একটি প্রতিস্থাপন ইনস্ট্যান্স চালু করে।

বিস্তারিত তথ্যের জন্য অবজেক্ট স্পেক, স্ট্যাটাস এবং মেটাডেটা দেখুন, Kubernetes API Conventions.

একটি কুবারনেটিস অবজেক্ট বর্ণনা

যখন আপনি কুবারনেটিসে একটি অবজেক্ট তৈরি করবেন, আপনাকে অবজেক্ট spec প্রদান করতে হবে যা দরকার তার কাঙ্ক্ষিত অবস্থা বর্ণনা করে এবং অবজেক্ট সম্পর্কে কিছু মৌলিক তথ্য (যেমন নাম) প্রদান করতে হবে। যখন আপনি অবজেক্ট তৈরি করতে কুবারনেটিস API ব্যবহার করেন (এটা সরাসরি বা kubectl এর মাধ্যমে), তখন ঐ API অনুরোধটি এই তথ্যকে একটি JSON রিকোয়েস্ট বডি হিসেবে অন্তর্ভুক্ত করতে হবে। সাধারণত, আপনি একটি manifest নামে পরিচিত ফাইলে kubectl কে তথ্য প্রদান করেন। নিয়ম অনুসারে, ম্যানিফেস্ট হল YAML (আপনি JSON ফরম্যাটও ব্যবহার করতে পারেন)। HTTP-এর মাধ্যমে API অনুরোধ করার সময় টুল যেমন kubectl একটি ম্যানিফেস্ট থেকে তথ্যকে JSON বা অন্য সমর্থিত সিরিয়ালাইজেশন ফরম্যাটে রূপান্তর করে।

এখানে একটি উদাহরণ ম্যানিফেস্ট দেওয়া হল একটি কুবারনেটিস ডিপ্লয়মেন্টের জন্য প্রয়োজনীয় ক্ষেত্রগুলি এবং অবজেক্ট স্পেকের জন্যের একটি নমুনা:

application/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # ডিপ্লয়মেন্টকে টেমপ্লেটের সাথে মিলে যাওয়া 2টি পড চালাতে বলে
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

একটি উপরের মতো ম্যানিফেস্ট ফাইল ব্যবহার করে একটি ডিপ্লয়মেন্ট তৈরি করার একটি উপায় হল kubectl apply কমান্ড ব্যবহার করা, kubectl এর কমান্ড-লাইন ইন্টারফেসে yaml ফাইলটি আর্গুমেন্ট হিসেবে পাঠানো। একটি উদাহরণ:

kubectl apply -f https://k8s.io/examples/application/deployment.yaml

আউটপুট এর অনুরূপ:

deployment.apps/nginx-deployment created

প্রয়োজনীয় ক্ষেত্র

আপনার কুবারনেটিস অবজেক্ট এর জন্য ম্যানিফেস্ট (YAML বা JSON ফাইল) এ নিম্নলিখিত ক্ষেত্রগুলির জন্য মান নির্ধারণ করতে হবে:

• apiVersion - আপনি কোন ভার্সনের কুবারনেটিস API ব্যবহার করছেন তা উল্লেখ করতে হবে
• kind - আপনি কোন ধরনের অবজেক্ট তৈরি করতে চান তা উল্লেখ করতে হবে
• metadata - অবজেক্ট যে সাহায্য করে অনন্যভাবে সনাক্ত করা যায়, যেমন name স্ট্রিং, UID, এবং ঐচ্ছিক namespace
• spec - অবজেক্টের জন্য আপনি কি অবস্থা চান

অবজেক্ট spec সুনির্দিষ্ট ফরম্যাট প্রতিটি কুবারনেটিস অবজেক্টের জন্য আলাদা, এবং সেই বস্তুর জন্য নির্দিষ্ট নেস্টেড ক্ষেত্র রয়েছে। Kubernetes API রেফারেন্স ব্যবহার করে আপনি যে সমস্ত অবজেক্ট তৈরি করতে পারেন তার জন্য নির্দিষ্ট ফরম্যাট খুঁজে পেতে সাহায্য করতে পারে।

উদাহরণস্বরূপ, দেখুন spec ফিল্ড Pod API রেফারেন্স এর জন্য। প্রতিটি Pod এর জন্য, .spec ক্ষেত্রটি পড এবং তার কাঙ্ক্ষিত অবস্থা (যেমন সেই পডের মধ্যে প্রতিটি কন্টেইনারের জন্য কন্টেইনার ইমেজের নাম) নির্দিষ্ট করে৷ আরও একটি অবজেক্ট স্পেসিফিকেশনের উদাহরণ হল spec ফিল্ড StatefulSet API এর জন্য। StatefulSet এর জন্য, .spec ফিল্ড নির্দিষ্ট করে এবং সেট করে এর অবস্থা। StatefulSet এর .spec এর মধ্যে একটি টেমপ্লেট পড অবজেক্টের জন্য । সেই টেমপ্লেটটি Pods বর্ণনা করে যা StatefulSet কন্ট্রোলার স্টেটফুলসেট স্পেসিফিকেশন সন্তুষ্ট করার জন্য তৈরি করবে। অন্যান্য প্রকারের অবজেক্ট গুলির জন্য বিভিন্ন .status থাকতে পারে; আবার, API রেফারেন্স পৃষ্ঠাগুলি এই .status ফিল্ডের গঠন এবং এর প্রত্যেক বিভিন্ন প্রকারের অবজেক্টের জন্য তার বিষয়বস্তু বিবরণ করে।

সার্ভার সাইড ফিল্ড ভেরিফিকেশন

কুবারনেটিস v1.25 থেকে শুরু করে, API সার্ভার সার্ভার সাইড field validation যা অব্যক্ত বা পুনরায় ফিল্ড অনুমান করে একটি অবজেক্টে। এটি সমস্ত কার্যকারিতা প্রদান করে kubectl --validate এর সার্ভার সাইড এ কর্মক্ষমতা।

kubectl টুলটি ব্যবহার করে --validate ফ্ল্যাগ ব্যবহার করে ফিল্ড ভেরিফিকেশনের স্তর সেট করে। এটি গ্রহণ করে মান ignore, warn, এবং strict এবং এটি true (strict এর সমান) এবং false ( ignore এর সমান) মান গ্রহণ করে। kubectl এর ডিফল্ট ভেরিফিকেশন সেটিং হল --validate=true।

Strict

Strict ফিল্ড ভেরিফিকেশন, ভেরিফিকেশন ব্যর্থ হওয়ায় errors দেখায়

Warn

ফিল্ড ভেরিফিকেশন করা হয়, কিন্তু errors গুলি অনুরোধ ব্যর্থ হওয়ার পরিবর্তে সতর্কতা হিসাবে প্রকাশ করা হয়

Ignore

কোনো সার্ভার সাইড ফিল্ড ভেরিফিকেশন করা হয় না

যখন kubectl এর একটি API সার্ভারে সংযোগ করতে পারে না যে কোন ফিল্ড ভেরিফিকেশন সাপোর্ট করে তখন এটি ফেলে যায় ক্লায়েন্ট-সাইড ভেরিফিকেশন ব্যবহার করা হয়। কুবারনেটিস 1.27 এবং তারপরের সংস্করণ সবসময় ফিল্ড ভেরিফিকেশন প্রদান করে; পুরাতন কুবারনেটিস রিলিসেগুলিতে এটি হতে পারে না। যদি আপনার ক্লাস্টার v1.27 এর চেয়ে পুরানো হয় তবে এপনার কুবারনেটিস সংস্করণের জন্য ডকুমেন্টেশন চেক করুন।

এর পরের কি

যদি আপনি নতুন কুবারনেটিসে এসেছেন, তাহলে নিম্নলিখিত বিষয়গুলি সম্পর্কে আরো পড়ুন:

• Pods যা হলে সবচেয়ে গুরুত্বপূর্ণ মৌলিক কুবারনেটিস অবজেক্ট।
• Deployment অবজেক্টগুলি।
• Controllers কুবারনেটিসে।
• kubectl এবং kubectl কমান্ড।

কুবারনেটিস অবজেক্ট ম্যানেজমেন্ট kubectl ব্যবহার করে অবজেক্ট পরিচালনা করার উপায়গুলি বিস্তারিত ভাবে বর্ণনা করে। আপনার কাছে যদি আগে থেকে না থাকে তাহলে kubectl ইনস্টল করুন।

কুবারনেটিস API সাধারণভাবে সম্পর্কে জানতে, পড়ুন:

• Kubernetes API overview

কুবারনেটিসে অবজেক্টগুলির বিস্তারিত জানতে, এই বিভাগে অন্যান্য পৃষ্ঠাগুলি পড়ুন:

2 - ক্লাস্টার আর্কিটেকচার

2.1 - Nodes

Kubernetes runs your workload by placing containers into Pods to run on Nodes. A node may be a virtual or physical machine, depending on the cluster. Each node is managed by the control plane and contains the services necessary to run Pods.

Typically you have several nodes in a cluster; in a learning or resource-limited environment, you might have only one node.

The components on a node include the kubelet, a container runtime, and the kube-proxy.

Management

There are two main ways to have Nodes added to the API server:

1. The kubelet on a node self-registers to the control plane
2. You (or another human user) manually add a Node object

After you create a Node object, or the kubelet on a node self-registers, the control plane checks whether the new Node object is valid. For example, if you try to create a Node from the following JSON manifest:

{
  "kind": "Node",
  "apiVersion": "v1",
  "metadata": {
    "name": "10.240.79.157",
    "labels": {
      "name": "my-first-k8s-node"
    }
  }
}

Kubernetes creates a Node object internally (the representation). Kubernetes checks that a kubelet has registered to the API server that matches the metadata.name field of the Node. If the node is healthy (i.e. all necessary services are running), then it is eligible to run a Pod. Otherwise, that node is ignored for any cluster activity until it becomes healthy.

The name of a Node object must be a valid DNS subdomain name.

Node name uniqueness

The name identifies a Node. Two Nodes cannot have the same name at the same time. Kubernetes also assumes that a resource with the same name is the same object. In case of a Node, it is implicitly assumed that an instance using the same name will have the same state (e.g. network settings, root disk contents) and attributes like node labels. This may lead to inconsistencies if an instance was modified without changing its name. If the Node needs to be replaced or updated significantly, the existing Node object needs to be removed from API server first and re-added after the update.

Self-registration of Nodes

When the kubelet flag --register-node is true (the default), the kubelet will attempt to register itself with the API server. This is the preferred pattern, used by most distros.

For self-registration, the kubelet is started with the following options:

• --kubeconfig - Path to credentials to authenticate itself to the API server.

• --cloud-provider - How to talk to a cloud provider to read metadata about itself.

• --register-node - Automatically register with the API server.

• --register-with-taints - Register the node with the given list of taints (comma separated <key>=<value>:<effect>).

  No-op if register-node is false.

• --node-ip - Optional comma-separated list of the IP addresses for the node. You can only specify a single address for each address family. For example, in a single-stack IPv4 cluster, you set this value to be the IPv4 address that the kubelet should use for the node. See configure IPv4/IPv6 dual stack for details of running a dual-stack cluster.

  If you don't provide this argument, the kubelet uses the node's default IPv4 address, if any; if the node has no IPv4 addresses then the kubelet uses the node's default IPv6 address.

• --node-labels - Labels to add when registering the node in the cluster (see label restrictions enforced by the NodeRestriction admission plugin).

• --node-status-update-frequency - Specifies how often kubelet posts its node status to the API server.

When the Node authorization mode and NodeRestriction admission plugin are enabled, kubelets are only authorized to create/modify their own Node resource.

Manual Node administration

You can create and modify Node objects using kubectl.

When you want to create Node objects manually, set the kubelet flag --register-node=false.

You can modify Node objects regardless of the setting of --register-node. For example, you can set labels on an existing Node or mark it unschedulable.

You can use labels on Nodes in conjunction with node selectors on Pods to control scheduling. For example, you can constrain a Pod to only be eligible to run on a subset of the available nodes.

Marking a node as unschedulable prevents the scheduler from placing new pods onto that Node but does not affect existing Pods on the Node. This is useful as a preparatory step before a node reboot or other maintenance.

To mark a Node unschedulable, run:

kubectl cordon $NODENAME

See Safely Drain a Node for more details.

Node status

A Node's status contains the following information:

• Addresses
• Conditions
• Capacity and Allocatable
• Info

You can use kubectl to view a Node's status and other details:

kubectl describe node <insert-node-name-here>

See Node Status for more details.

Node heartbeats

Heartbeats, sent by Kubernetes nodes, help your cluster determine the availability of each node, and to take action when failures are detected.

For nodes there are two forms of heartbeats:

• Updates to the .status of a Node.
• Lease objects within the kube-node-lease namespace. Each Node has an associated Lease object.

Node controller

The node controller is a Kubernetes control plane component that manages various aspects of nodes.

The node controller has multiple roles in a node's life. The first is assigning a CIDR block to the node when it is registered (if CIDR assignment is turned on).

The second is keeping the node controller's internal list of nodes up to date with the cloud provider's list of available machines. When running in a cloud environment and whenever a node is unhealthy, the node controller asks the cloud provider if the VM for that node is still available. If not, the node controller deletes the node from its list of nodes.

The third is monitoring the nodes' health. The node controller is responsible for:

• In the case that a node becomes unreachable, updating the Ready condition in the Node's .status field. In this case the node controller sets the Ready condition to Unknown.
• If a node remains unreachable: triggering API-initiated eviction for all of the Pods on the unreachable node. By default, the node controller waits 5 minutes between marking the node as Unknown and submitting the first eviction request.

By default, the node controller checks the state of each node every 5 seconds. This period can be configured using the --node-monitor-period flag on the kube-controller-manager component.

Rate limits on eviction

In most cases, the node controller limits the eviction rate to --node-eviction-rate (default 0.1) per second, meaning it won't evict pods from more than 1 node per 10 seconds.

The node eviction behavior changes when a node in a given availability zone becomes unhealthy. The node controller checks what percentage of nodes in the zone are unhealthy (the Ready condition is Unknown or False) at the same time:

• If the fraction of unhealthy nodes is at least --unhealthy-zone-threshold (default 0.55), then the eviction rate is reduced.
• If the cluster is small (i.e. has less than or equal to --large-cluster-size-threshold nodes - default 50), then evictions are stopped.
• Otherwise, the eviction rate is reduced to --secondary-node-eviction-rate (default 0.01) per second.

The reason these policies are implemented per availability zone is because one availability zone might become partitioned from the control plane while the others remain connected. If your cluster does not span multiple cloud provider availability zones, then the eviction mechanism does not take per-zone unavailability into account.

A key reason for spreading your nodes across availability zones is so that the workload can be shifted to healthy zones when one entire zone goes down. Therefore, if all nodes in a zone are unhealthy, then the node controller evicts at the normal rate of --node-eviction-rate. The corner case is when all zones are completely unhealthy (none of the nodes in the cluster are healthy). In such a case, the node controller assumes that there is some problem with connectivity between the control plane and the nodes, and doesn't perform any evictions. (If there has been an outage and some nodes reappear, the node controller does evict pods from the remaining nodes that are unhealthy or unreachable).

The node controller is also responsible for evicting pods running on nodes with NoExecute taints, unless those pods tolerate that taint. The node controller also adds taints corresponding to node problems like node unreachable or not ready. This means that the scheduler won't place Pods onto unhealthy nodes.

Resource capacity tracking

Node objects track information about the Node's resource capacity: for example, the amount of memory available and the number of CPUs. Nodes that self register report their capacity during registration. If you manually add a Node, then you need to set the node's capacity information when you add it.

The Kubernetes scheduler ensures that there are enough resources for all the Pods on a Node. The scheduler checks that the sum of the requests of containers on the node is no greater than the node's capacity. That sum of requests includes all containers managed by the kubelet, but excludes any containers started directly by the container runtime, and also excludes any processes running outside of the kubelet's control.

Node topology

If you have enabled the TopologyManager feature gate, then the kubelet can use topology hints when making resource assignment decisions. See Control Topology Management Policies on a Node for more information.

Swap memory management

To enable swap on a node, the NodeSwap feature gate must be enabled on the kubelet (default is true), and the --fail-swap-on command line flag or failSwapOn configuration setting must be set to false. To allow Pods to utilize swap, swapBehavior should not be set to NoSwap (which is the default behavior) in the kubelet config.

A user can also optionally configure memorySwap.swapBehavior in order to specify how a node will use swap memory. For example,

memorySwap:
  swapBehavior: LimitedSwap

• NoSwap (default): Kubernetes workloads will not use swap.
• LimitedSwap: The utilization of swap memory by Kubernetes workloads is subject to limitations. Only Pods of Burstable QoS are permitted to employ swap.

If configuration for memorySwap is not specified and the feature gate is enabled, by default the kubelet will apply the same behaviour as the NoSwap setting.

With LimitedSwap, Pods that do not fall under the Burstable QoS classification (i.e. BestEffort/Guaranteed Qos Pods) are prohibited from utilizing swap memory. To maintain the aforementioned security and node health guarantees, these Pods are not permitted to use swap memory when LimitedSwap is in effect.

Prior to detailing the calculation of the swap limit, it is necessary to define the following terms:

• nodeTotalMemory: The total amount of physical memory available on the node.
• totalPodsSwapAvailable: The total amount of swap memory on the node that is available for use by Pods (some swap memory may be reserved for system use).
• containerMemoryRequest: The container's memory request.

Swap limitation is configured as: (containerMemoryRequest / nodeTotalMemory) * totalPodsSwapAvailable.

It is important to note that, for containers within Burstable QoS Pods, it is possible to opt-out of swap usage by specifying memory requests that are equal to memory limits. Containers configured in this manner will not have access to swap memory.

Swap is supported only with cgroup v2, cgroup v1 is not supported.

For more information, and to assist with testing and provide feedback, please see the blog-post about Kubernetes 1.28: NodeSwap graduates to Beta1, KEP-2400 and its design proposal.

এর পরের কি

Learn more about the following:

• Components that make up a node.
• API definition for Node.
• Node section of the architecture design document.
• Graceful/non-graceful node shutdown.
• Cluster autoscaling to manage the number and size of nodes in your cluster.
• Taints and Tolerations.
• Node Resource Managers.
• Resource Management for Windows nodes.

3 - কন্টেইনার

আপনার চালানো প্রতিটি কন্টেইনার পুনরাবৃত্তিযোগ্য; নির্ভরতা অন্তর্ভুক্ত করা থেকে প্রমিতকরণের (standardization) অর্থ হলো আপনি যেখানেই এটি চালান সেখানই আপনি একই আচরণ পাবেন।

কন্টেইনার অন্তর্নিহিত হোস্ট পরিকাঠামো থেকে অ্যাপ্লিকেশনগুলোকে দ্বিগুণ করে৷ এটি বিভিন্ন ক্লাউড বা ওএস পরিবেশে ডিপ্লয়মেন্টকে সহজ করে তোলে।

একটি কুবারনেটিস ক্লাস্টারের প্রতিটি নোড , সেই নোডের জন্য নির্ধারিত পড গঠনকারী কন্টেইনারগুলো চালায়। একটি পডের কন্টেইনারগুলো একই নোডে চালানোর জন্য সহ-অবস্থিত (co-located) এবং সহ-নির্ধারিত (co-scheduled)।

কন্টেইনার ছবি

একটি কন্টেইনার ছবি হলো একটি রেডি-টু-রান সফ্টওয়্যার প্যাকেজ যাতে একটি অ্যাপ্লিকেশন চালানোর জন্য প্রয়োজনীয় সমস্ত কিছু থাকে: কোড এবং যেকোন রানটাইম, অ্যাপ্লিকেশন এবং সিস্টেম লাইব্রেরি এবং যেকোনো প্রয়োজনীয় সেটিংসের জন্য ডিফল্ট মান।

কন্টেইনারগুলো স্টেটলেস এবং অপরিবর্তনীয় হওয়ার উদ্দেশ্যে করা হয়েছে: আপনার এমন একটি কন্টেইনারের কোড পরিবর্তন করা উচিত নয় যা ইতিমধ্যেই চলছে ৷ আপনার যদি একটি কন্টেইনারাইজড অ্যাপ্লিকেশন থাকে এবং পরিবর্তন করতে চান, সঠিক প্রক্রিয়াটি হলো একটি নতুন ছবি তৈরি করা যাতে পরিবর্তনটি অন্তর্ভুক্ত থাকে, তারপর আপডেট করা ছবি থেকে শুরু করতে কন্টেইনারটি পুনরায় তৈরি করুন ।

কন্টেইনার রানটাইম

একটি মৌলিক উপাদান যা কুবারনেটিসকে কার্যকরভাবে কন্টেইনার চালানোর ক্ষমতা দেয়। এটি কুবারনেটিস পরিবেশের মধ্যে কন্টেইনারগুলির সম্পাদন এবং জীবনচক্র পরিচালনার জন্য দায়ী।

কুবারনেটস কনটেইনার রানটাইম সমর্থন করে যেমন containerd, CRI-O, এবং কুবারনেটিস CRI (কন্টেইনার রানটাইম ইন্টারফেস)।

সাধারণত, আপনি আপনার ক্লাস্টারকে একটি পডের জন্য ডিফল্ট কন্টেইনার রানটাইম বাছাই করার অনুমতি দিতে পারেন। আপনি যদি আপনার ক্লাস্টারে একাধিক কন্টেইনার রানটাইম ব্যবহার করতে চান, আপনি একটি পডের জন্য রানটাইম ক্লাস নির্দিষ্ট করতে পারেন যাতে কুবারনেটিস একটি নির্দিষ্ট কন্টেইনার রানটাইম ব্যবহার করে সেই কন্টেইনারগুলো চালায়।

আপনি একই কন্টেইনার রানটাইম সহ বিভিন্ন পড চালানোর জন্য রানটাইম ক্লাস ব্যবহার করতে পারেন কিন্তু ভিন্ন সেটিংসের সাথে।

4 - ওয়ার্কলোড

ওয়ার্কলোড হলো কুবারনেটিস-এ চলমান একটি অ্যাপ্লিকেশন। আপনার ওয়ার্কলোড একটি একক উপাদান বা একাধিক যা একসাথে কাজ করে, কুবারনেটিসে আপনি এটিকে pods এর একটি সেটের মধ্যে চালান। কুবারনেটিসে, একটি পড আপনার ক্লাস্টারে কন্টেইনারগুলোর চলমান একটি সেট উপস্থাপন করে৷

কুবারনেটিস পডের একটি সংজ্ঞায়িত জীবনচক্র. উদাহরণস্বরূপ, একবার আপনার ক্লাস্টারে একটি পড চলমান হলে নোড যেখানে সেই পডটি চলছে সেখানে একটি গুরুতর ত্রুটির অর্থ হলো সেই নোডের সমস্ত পড ব্যর্থ হয়েছে ৷ কুবারনেটিস ব্যর্থতার সেই লেভেলটিকে চূড়ান্ত হিসাবে বিবেচনা করে: আপনাকে পুনরুদ্ধার করার জন্য একটি নতুন পড তৈরি করতে হবে, এমনকি যদি নোডটি পরে সুস্থ হয়ে ওঠে।

যাইহোক, জীবনকে যথেষ্ট সহজ করতে, আপনাকে প্রতিটি পড সরাসরি পরিচালনা করতে হবে না। পরিবর্তে, আপনি ওয়ার্কলোড রিসোর্স ব্যবহার করতে পারেন যা আপনার পক্ষ থেকে পডের একটি সেট পরিচালনা করে। এই রিসোর্সগুলো কন্ট্রোলার কনফিগার করে যা নিশ্চিত করে যে সঠিক সংখ্যক পড চলছে, আপনার নির্দিষ্ট স্টেটের সাথে মেলে৷

কুবারনেটিস বেশ কয়েকটি বিল্ট ইন ওয়ার্কলোড রিসোর্স সরবরাহ করে:

• ডিপ্লয়মেন্ট এবং রেপ্লিকাসেট, (ডিপ্লয়মেন্ট হলো একটি প্রতিস্থাপন ব্যবস্থা লিগেসি ReplicationController API এর) ক্লাস্টারে একটি স্টেটলেস অ্যাপ্লিকেশান ওয়ার্কলোড পরিচালনা করার জন্য ডিপ্লয়মেন্ট একটি উপযুক্ত ব্যবস্থা , যেখানে ডিপ্লয়মেন্টের যেকোনো পড বিনিময়যোগ্য এবং প্রয়োজনে প্রতিস্থাপন করা যেতে পারে।
• স্টেটফুলসেট আপনাকে এক বা একাধিক সম্পর্কিত পড চালাতে দেয় যা কোনোভাবে ট্র্যাক স্টেট করে। উদাহরণস্বরূপ, যদি আপনার ওয়ার্কলোড ক্রমাগতভাবে ডেটা রেকর্ড করে, আপনি একটি স্টেটফুলসেট চালাতে পারেন যা প্রতিটি পডের সাথে একটি PersistentVolume এর সাথে মেলে। আপনার কোড, সেই স্টেটফুলসেটের জন্য পডগুলিতে চলমান, সামগ্রিক স্থিতিস্থাপকতা উন্নত করতে একই স্টেটফুলসেটের অন্যান্য পডগুলিতে ডেটা প্রতিলিপি করতে পারে।
• একটি ডেমনসেট পডগুলোকে সংজ্ঞায়িত করে যা একটি নির্দিষ্ট নোড লোকাল সুবিধা প্রদান করে; প্রতিবার আপনি আপনার ক্লাস্টারে একটি নোড যুক্ত করেন যা একটি ডেমনসেটের স্পেসিফিকেশনের সাথে মেলে, কন্ট্রোল প্লেন সেই ডেমনসেটের জন্য একটি পডকে নতুন নোডে নির্ধারণ করে। ডেমনসেটের প্রতিটি পড একটি ক্লাসিক Unix / POSIX সার্ভারে সিস্টেম ডেমনের মতো একই ভূমিকা পালন করে। একটি ডেমনসেট আপনার ক্লাস্টার পরিচালনার জন্য গুরুত্বপূর্ণ হতে পারে, যেমন একটি প্লাগইন নোড অ্যাক্সেস করতে দেয় ক্লাস্টার নেটওয়ার্কিং, এটি আপনাকে নোড পরিচালনা করতে সাহায্য করতে পারে, অথবা এটি ঐচ্ছিক আচরণ প্রদান করতে পারে যা আপনি যে কন্টেইনার প্ল্যাটফর্মটি চালাচ্ছেন তা উন্নত করে।
• আপনি একটি Job এবং / বা একটি CronJob ব্যবহার করতে পারেন যা কাজগুলোকে চিহ্নিত করবে যা সমাপ্তির জন্য চলবে পরে থামবে। একটি Job একটি একক টাস্কের প্রতিনিধিত্ব করে, যেখানে প্রতিটি CronJob একটি শিডিউল অনুযায়ী পুনরাবৃত্তি করে।

বৃহত্তর কুবারনেটস ইকোসিস্টেমে, আপনি তৃতীয় পক্ষের ওয়ার্কলোডের রিসোর্সগুলো খুঁজে পেতে পারেন যা অতিরিক্ত আচরণ প্রদান করে। একটি কাস্টম রিসোর্স ডেফিনিশন ব্যবহার করে, আপনি যদি কুবারনেটসের মূল অংশ নয় এমন একটি নির্দিষ্ট আচরণ চান তাহলে আপনি একটি তৃতীয় পক্ষের ওয়ার্কলোডের রিসোর্স যোগ করতে পারেন । উদাহরণস্বরূপ, আপনি যদি আপনার অ্যাপ্লিকেশনের জন্য পডগুলির একটি গ্রুপ চালাতে চান কিন্তু কাজ বন্ধ করতে চান যদি না সব পডগুলো উপলব্ধ হয় (সম্ভবত কিছু উচ্চ-থ্রুপুট ডিস্ট্রিবিউট করা কাজের জন্য), তাহলে আপনি সেই ফিচারটি প্রদান করে এমন একটি এক্সটেনশন বাস্তবায়ন বা ইনস্টল করতে পারেন।

এর পরের কি

ওয়ার্কলোড ম্যানেজমেন্টের জন্য প্রতিটি API ধরণের সম্পর্কে পড়ার পাশাপাশি, আপনি কীভাবে নির্দিষ্ট কাজগুলো করতে হবে তা পড়তে পারেন:

• একটি ডিপ্লয়মেন্ট ব্যবহার করে একটি স্টেটলেস অ্যাপ্লিকেশন চালান
• একটি একক উদাহরণ হিসাবে একটি স্টেটফুল অ্যাপ্লিকেশন চালান অথবা একটি রেপ্লিকেটেড সেট হিসাবে
• CronJob দিয়ে স্বয়ংক্রিয় কাজ চালান

কনফিগারেশন থেকে কোড আলাদা করার জন্য কুবারনেটিসের প্রক্রিয়া সম্পর্কে জানতে, কনফিগারেশন দেখুন।

কুবারনেটিস কীভাবে অ্যাপ্লিকেশনগুলির জন্য পডগুলো পরিচালনা করে সে সম্পর্কে পটভূমি প্রদান করে এমন দুটি সাপোর্টকারী ধারণা রয়েছে:

• গার্বেজ কালেকশন আপনার ক্লাস্টার থেকে বস্তুগুলিকে তাদের মালিকানাধীন রিসোর্স সরিয়ে ফেলার পরে পরিষ্কার করে।
• time-to-live after finished কন্ট্রোলার কাজগুলো সম্পূর্ণ করার পর একটি নির্দিষ্ট সময় পেরিয়ে গেলে তা সরিয়ে দেয়।

একবার আপনার অ্যাপ্লিকেশানটি চালু হয়ে গেলে, আপনি এটিকে একটি সার্ভিস হিসাবে ইন্টারনেটে উপলব্ধ করতে চাইতে পারেন বা, শুধুমাত্র ওয়েব অ্যাপ্লিকেশনের জন্য, একটি ইনগ্রেস ব্যবহার করে ।

4.1 - পড

পড হলো কম্পিউটিংয়ের ক্ষুদ্রতম স্থাপনযোগ্য একক যা আপনি কুবারনেটিসে তৈরি এবং পরিচালনা করতে পারেন।

একটি পড (তিমি বা মটর শুঁটির একটি পডের মতো) এক বা একাধিক কন্টেইনার এর একটি গ্রুপ , শেয়ার্ড স্টোরেজ এবং নেটওয়ার্ক রিসোর্স গুলির সাথে, এবং কন্টেইনার কীভাবে চালানো যায় তার জন্য একটি স্পেসিফিকেশন। একটি পডের সামগ্রী সর্বদা সহ-অবস্থিত এবং সহ-নির্ধারিত, এবং একটি শেয়ার্ড প্রসঙ্গে চালে। একটি পড মডেল একটি অ্যাপ্লিকেশন-নির্দিষ্ট "লজিক্যাল হোস্ট": এটিতে এক বা একাধিক অ্যাপ্লিকেশন রয়েছে কন্টেইনার যা তুলনামূলকভাবে শক্তভাবে মিলিত হয়। নন-ক্লাউড প্রেক্ষাপটে, একই ভৌত (ফিজিক্যাল) বা ভার্চুয়াল মেশিনে সঞ্চালিত অ্যাপ্লিকেশনগুলি একই লজিক্যাল হোস্টে নির্বাহিত ক্লাউড অ্যাপ্লিকেশনগুলির সাথে সাদৃশ্যপূর্ণ।

পাশাপাশি অ্যাপ্লিকেশন কন্টেইনারে, একটি পড থাকতে পারে init কন্টেইনার যেটি চলে পড স্টার্টআপের সময়। আপনি ইনজেকশনও করতে পারেন ephemeral কন্টেইনার একটি চলমান পড ডিবাগ করার জন্য।

পড কি ?

একটি পডের শেয়ার্ড প্রসঙ্গ হল লিনাক্স নেমস্পেস(namespaces), cgroups এবং বিচ্ছিন্নতার সম্ভাব্য অন্যান্য দিক - একই জিনিস যা একটি কন্টেইনার বিচ্ছিন্ন করে। একটি পডের প্রেক্ষাপটের মধ্যে, পৃথক অ্যাপ্লিকেশন থাকতে পারে আরও উপ-বিচ্ছিন্নতা প্রয়োগ করা হয়েছে।

একটি পড শেয়ার্ড নেমস্পেস এবং শেয়ার্ড ফাইল সিস্টেম ভলিউম সহ কন্টেইনারগুলির সেটের অনুরূপ।

কুবারনেটিস ক্লাস্টারের পড প্রধানত দুটি উপায়ে ব্যবহৃত হয়:

• পড যা একটি একক কন্টেইনার চালায়" এক-কন্টেইনার-প্রতি-পড" মডেলটি কুবারনেটিসের সবচেয়ে সাধারণ ব্যবহার; এই ক্ষেত্রে, আপনি একটি একক কন্টেইনারর চারপাশে একটি মোড়ক হিসাবে একটি পডকে ভাবতে পারেন; কুবারনেটিস সরাসরি কন্টেইনারগুলি পরিচালনা করার পরিবর্তে পডগুলি পরিচালনা করে।

• পডগুলি যা একাধিক কন্টেইনার চালায় যা একসাথে কাজ করা দরকার একটি পড একাধিক সহ-অবস্থিত কন্টেইনার দ্বারা গঠিত একটি অ্যাপ্লিকেশনকে এনক্যাপসুলেট(encapsulate) করতে পারে যেগুলি শক্তভাবে সংযুক্ত এবং রিসোর্স ভাগ করতে হবে৷ এই সহ-অবস্থিত কন্টেইনারগুলি একটি একক সমন্বিত ইউনিট গঠন করে।

  একটি একক পডে একাধিক সহ-অবস্থিত এবং সহ-পরিচালিত কন্টেইনারে গোষ্ঠীবদ্ধ করা একটি অপেক্ষাকৃত উন্নত ব্যবহারের ক্ষেত্রে। আপনার এই প্যাটার্নটি কেবলমাত্র নির্দিষ্ট ক্ষেত্রে ব্যবহার করা উচিত যেখানে আপনার কন্টেইনারে শক্তভাবে সংযুক্ত করা হয়েছে।

  প্রতিলিপি প্রদানের জন্য আপনাকে একাধিক কন্টেইনার চালানোর দরকার নেই (স্থিতিস্থাপকতার জন্য বা ক্ষমতা); আপনার একাধিক প্রতিলিপি প্রয়োজন হলে, দেখুন ওয়ার্কলোড ম্যানেজমেন্ট।

পডের ব্যবহার

নিচে একটি পডের উদাহরণ দেওয়া হল যেটিতে একটি কন্টেইনার রয়েছে যা nginx:1.14.2 ইমেজটি চালাচ্ছে।

pods/simple-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

উপরে দেখানো পড তৈরি করতে, নিম্নলিখিত কমান্ডটি চালান:

kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml

পড সাধারণত সরাসরি তৈরি করা হয় না এবং ওয়ার্কলোড রিসোর্স ব্যবহার করে তৈরি করা হয়। কিভাবে পডগুলিব্যবহার করা হয় ওয়ার্কলোড রিসোর্স সহ সে সম্পর্কে আরও তথ্যের জন্য পডগুলির সাথে কাজ দেখুন।

পড পরিচালনার জন্য ওয়ার্কলোডের রিসোর্স

সাধারণত আপনাকে সরাসরি পড তৈরি করতে হবে না, এমনকি সিঙ্গেলটন পডও। পরিবর্তে, ওয়ার্কলোড রিসোর্সগুলি ব্যবহার করে সেগুলি তৈরি করুন যেমন ডিপলয়ম্যান্ট বা জব। আপনার পডের অবস্থা ট্র্যাক করার প্রয়োজন হলে, বিবেচনা করুন স্টেটফুলসেট রিসোর্স।

প্রতিটি পড একটি প্রদত্ত অ্যাপ্লিকেশনের একটি একক উদাহরণ চালানোর জন্য বোঝানো হয়। যদি আপনি চান আপনার অ্যাপ্লিকেশনকে অনুভূমিকভাবে স্কেল করতে (আরো উদাহরণ চালানোর মাধ্যমে আরো সামগ্রিক রিসোর্স প্রদান করতে), আপনার একাধিক পড ব্যবহার করা উচিত, প্রতিটি উদাহরণের জন্য একটি। কুবারনেটিসে-এ, এটিকে সাধারণত প্রতিলিপি হিসাবে উল্লেখ করা হয়। প্রতিলিপিকৃত পডগুলি সাধারণত একটি ওয়ার্কলোড রিসোর্স কন্ট্রোলার দ্বারা একটি গ্রুপ হিসাবে তৈরি এবং পরিচালিত হয়।

দেখুন পড এবং কন্ট্রোলার আরও তথ্যের জন্য কিভাবে কুবারনেটিস অ্যাপ্লিকেশন স্কেলিং এবং অটো-হিলিং বাস্তবায়নের জন্য ওয়ার্কলোড রিসোর্স এবং তাদের কন্ট্রোলার ব্যবহার করে।

পডগুলি স্থানীয়ভাবে তাদের উপাদান কন্টেইনারের জন্য দুই ধরণের ভাগ করা রিসোর্স সরবরাহ করে: নেটওয়ার্কিং এবং স্টোরেজ।

পডগুলি নিয়ে কাজ করা

আপনি খুবই কম সময় সরাসরি কুবারনেটিস-এ এমনকি সিঙ্গেলটন পডগুলি-তে পৃথক পড তৈরি করবেন। এই কারণে পডগুলি তুলনামূলকভাবে অল্পক্ষণস্থায়ী, নিষ্পত্তিযোগ্য(disposable) হিসাবে ডিজাইন করা হয়েছে। যখন একটি পড তৈরি করা হয় (প্রত্যক্ষভাবে আপনার দ্বারা বা পরোক্ষভাবে একটি কন্ট্রোলার) দ্বারা, নতুন পডটি আপনার ক্লাস্টারে একটি নোড চালানোর জন্য নির্ধারিত হয়। পডটি সেই নোডে থাকে যতক্ষণ না পড এক্সিকিউশন শেষ করে, পড অবজেক্টটি মুছে ফেলা হয়, পডটিকে রিসোর্সের অভাবের জন্য উচ্ছেদ করা হয়, বা নোড ব্যর্থ হয়।

একটি পডের নাম অবশ্যই একটি বৈধ DNS সাবডোমেন মান হতে হবে, তবে এটি পড হোস্টনামের জন্য অপ্রত্যাশিত ফলাফল তৈরি করতে পারে। সর্বোত্তম সামঞ্জস্যের জন্য, নামের আরো সীমাবদ্ধ নিয়ম অনুসরণ করা উচিত DNS লেবেলএর জন্য।

পড অপারেটিং সিস্টেম(OS)

আপনি যে OS-এ পড চালাতে চান তা নির্দেশ করার জন্য আপনাকে .spec.os.name যে কোনো একটি ক্ষেত্রে windows বা linux-তে সেট করতে হবে। এই দুটিই একমাত্র অপারেটিং সিস্টেম যা এখন কুবারনেটিস দ্বারা সমর্থিত। ভবিষ্যতে, এই তালিকা প্রসারিত করা হতে পারে।

কুবারনেটিস v1.31 -এ, এই ক্ষেত্রের জন্য আপনি যে মান সেট করেছেন তা পডগুলির জন্য শিডিউলিং কোনও প্রভাব ফেলবে না ৷ সেট করা .spec.os.name পড অপারেটিং সিস্টেমকে প্রামাণিকভাবে সনাক্ত করতে সহায়তা করে এবং বৈধতার জন্য ব্যবহৃত হয়। Kubelet একটি পড চালাতে প্রত্যাখ্যান করে যেখানে আপনি একটি পড এর অপারেটিং সিস্টেম নির্দিষ্ট করেছেন, যদি এটি সেই নোডের অপারেটিং সিস্টেমের মতো না হয় যেখানে সেই Kubelet চলছে। পডের নিরাপত্তা মান সেই অপারেটিং সিস্টেমের সাথে প্রাসঙ্গিক নয় এমন নীতি প্রয়োগ করা এড়াতে এই ক্ষেত্রটিও ব্যবহার করা হয়৷

পড এবং কন্ট্রোলার

আপনি আপনার জন্য একাধিক পড তৈরি এবং পরিচালনা করতে ওয়ার্কলোড রিসোর্স ব্যবহার করতে পারেন। পড ব্যর্থতার ক্ষেত্রে রিসোর্স জন্য একটি কন্ট্রোলার প্রতিলিপি এবং রোলআউট এবং স্বয়ংক্রিয় নিরাময় পরিচালনা করে। উদাহরণস্বরূপ, যদি একটি নোড ব্যর্থ হয়, একটি কন্ট্রোলার লক্ষ্য করে যে সেই নোডের পডগুলি কাজ করা বন্ধ করে দিয়েছে এবং একটি প্রতিস্থাপন পড তৈরি করে। শিডিউলার একটি সুস্থ নোডে প্রতিস্থাপন পড স্থাপন করে।

এখানে ওয়ার্কলোড রিসোর্সগুলির কিছু উদাহরণ রয়েছে যা এক বা একাধিক পডগুলি পরিচালনা করে:

• ডিপলয়ম্যান্টস
• স্টেটফুল সেট
• ডেমোনসেট

পড টেমপ্লেট

রিসোর্সগুলির জন্য ওয়ার্কলোড কন্ট্রোলাররা একটি পড টেমপ্লেট থেকে পড তৈরি করে এবং আপনার পক্ষে সেই পডগুলি পরিচালনা করে৷

পড টেমপ্লেটগুলি হল পড তৈরির জন্য স্পেসিফিকেশন, এবং ওয়ার্কলোড রিসোর্সগুলির অন্তর্ভুক্ত যেমন ডিপলয়ম্যান্টস, জব, এবং ডেমোনসেট।

ওয়ার্কলোড রিসোর্সের প্রতিটি কন্ট্রোলার প্রকৃত পড তৈরি করতে ওয়ার্কলোড অবজেক্টের ভিতরে পড টেম্পলেট ব্যবহার করে। পড টেম্পলেট হল আপনার অ্যাপ চালানোর জন্য যে কোনো ওয়ার্কলোড রিসোর্স ব্যবহার করা সেই কাঙ্ক্ষিত অবস্থার অংশ।

নিচের নমুনাটি একটি সাধারণ কাজের জন্য একটি টেমপ্লেট সহ একটি ম্যানিফেস্ট যা একটি কন্টেইনার শুরু করে। সেই পডের কন্টেইনারটি একটি বার্তা প্রিন্ট করে তারপর বিরতি দেয়।

apiVersion: batch/v1
kind: Job
metadata:
  name: hello
spec:
  template:
    # This is the pod template
    spec:
      containers:
      - name: hello
        image: busybox:1.28
        command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
      restartPolicy: OnFailure
    # The pod template ends here

পড টেমপ্লেট পরিবর্তন করা বা একটি নতুন পড টেমপ্লেটে স্যুইচ করা আগে থেকেই বিদ্যমান পডগুলিতে সরাসরি প্রভাব ফেলে না। আপনি যদি কোনও ওয়ার্কলোড রিসোর্সের জন্য পড টেমপ্লেট পরিবর্তন করেন তবে সেই রিসোর্সটি এর প্রতিস্থাপন পড তৈরি করতে হবে যা আপডেট করা টেমপ্লেট ব্যবহার করে।

উদাহরণস্বরূপ, স্টেটফুলসেট কন্ট্রোলার নিশ্চিত করে যে চলমান পডগুলি প্রতিটি স্টেটফুলসেট অবজেক্টের বর্তমান পড টেমপ্লেটের একই । আপনি যদি স্টেটফুলসেট ইডিট করেন তার পড টেমপ্লেট পরিবর্তন করতে, স্টেটফুলসেট আপডেট করা টেমপ্লেটের উপর ভিত্তি করে নতুন পড তৈরি করা শুরু করে। অবশেষে, সমস্ত পুরানো পড নতুন পড দিয়ে প্রতিস্থাপিত হয় এবং আপডেট সম্পূর্ণ হয়।

প্রতিটি ওয়ার্কলোড রিসোর্স পড টেমপ্লেটের পরিবর্তনগুলি পরিচালনা করার জন্য নিজস্ব নিয়মগুলি প্রয়োগ করে৷ আপনি যদি বিশেষভাবে স্টেটফুলসেট সম্পর্কে আরও পড়তে চান, স্টেটফুলসেট বেসিক টিউটোরিয়ালটিতে
আপডেট কৌশল পড়ুন।

নোডগুলিতে, kubelet পড টেমপ্লেট এবং আপডেটগুলির আশেপাশে কোনও বিবরণ সরাসরি পর্যবেক্ষণ বা পরিচালনা করে না; এই বিবরণগুলি দূরে এব্যস্ট্রাক হয় ৷ উদ্বেগের এব্যস্ট্রাকশন এবং বিচ্ছেদ সিস্টেমের শব্দার্থিকে সরল করে, এবং বিদ্যমান কোড পরিবর্তন না করে ক্লাস্টারের আচরণকে প্রসারিত করা সম্ভবপর করে তোলে।

পড আপডেট এবং প্রতিস্থাপন

পূর্ববর্তী সেকশনে উল্লিখিত হিসাবে, যখন একটি ওয়ার্কলোড রিসোর্সের জন্য পড টেমপ্লেট পরিবর্তন করা হয়, তখন কন্ট্রোলার বিদ্যমান পডগুলিকে আপডেট বা প্যাচ করার পরিবর্তে আপডেট করা টেমপ্লেটের উপর ভিত্তি করে নতুন পড তৈরি করে।

কুবারনেটিস আপনাকে সরাসরি পড পরিচালনা করতে বাধা দেয় না। এটি একটি চলমান পডের কিছু ক্ষেত্র আপডেট করা সম্ভব। যাইহোক, পড আপডেটের ক্রিয়াকলাপ যেমন প্যাচ, এবং প্রতিস্থাপন কিছু সীমাবদ্ধতা রয়েছে :

• একটি পড সম্পর্কে বেশিরভাগ মেটাডেটা অপরিবর্তনীয়। উদাহরণস্বরূপ আপনি namespace, name, uid, বা creationTimestamp ক্ষেত্র পরিবর্তন করতে পারবেন না; generation ক্ষেত্রটি অনন্য। এটি কেবলমাত্র সেই আপডেটগুলি গ্রহণ করে যা ক্ষেত্রের বর্তমান মান বৃদ্ধি করে।

• যদি metadata.deletionTimestamp সেট করা থাকে, তবে metadata.finalizers তালিকায় কোনো নতুন এন্ট্রি যোগ করা যাবে না।

• পড আপডেটগুলি spec.containers[*].image, spec.initContainers[*].image, spec.activeDeadlineSeconds বা spec.tolerations ব্যতীত অন্য কোনো ক্ষেত্র পরিবর্তন করতে পারে না। spec.tolerations এর জন্য, আপনি শুধুমাত্র নতুন এন্ট্রি যোগ করতে পারেন।

• spec.activeDeadlineSeconds ক্ষেত্র আপডেট করার সময়, দুই ধরনের আপডেটের অনুমতি দেওয়া হয়:

  1. একটি ধনাত্মক সংখ্যায় আনঅ্যাসাইন করা ক্ষেত্র সেট করা;
  2. ক্ষেত্রটিকে একটি ধনাত্মক সংখ্যা থেকে একটি ছোট, অ-ঋণাত্মক সংখ্যায় আপডেট করা।

রিসোর্স ভাগাভাগি এবং যোগাযোগ

পডগুলি তাদের উপাদান কন্টেইনারর মধ্যে ডেটা ভাগ করে নেওয়া এবং যোগাযোগ করতে সক্ষম করে।

পডগুলিতে স্টোরেজ

একটি পড শেয়ার্ড স্টোরেজ ভলিউম এর একটি সেট নির্দিষ্ট করতে পারে। পডের সমস্ত কন্টেইনারে ভাগ করা ভলিউমগুলি অ্যাক্সেস করতে পারে, সেই কন্টেইনারগুলিকে ডেটা ভাগ করতে দেয় ৷ ভলিউমগুলি একটি পডের মধ্যে স্থায়ী ডেটাকে টিকে থাকার অনুমতি দেয় যদি এর মধ্যে থাকা একটি কন্টেইনারকে পুনরায় চালু করতে হয় । দেখুন স্টোরেজ কুবারনেটিস কীভাবে শেয়ার্ড স্টোরেজ প্রয়োগ করে এবং এটি পডের কাছে উপলব্ধ করে সে বিষয়ে আরও তথ্যের জন্য।

পড নেটওয়ার্কিং

প্রতিটি পড প্রতিটি এড্রেস পরিবারের জন্য একটি একক আইপি এড্রেস বরাদ্দ করা হয় । একটি পডের প্রতিটি কন্টেইনার আইপি এড্রেস এবং নেটওয়ার্ক পোর্ট সহ নেটওয়ার্ক নেমস্পেস শেয়ার করে । একটি পডের ভিতরে (এবং শুধুমাত্র তখন), পডের অন্তর্গত কন্টেইনারগুলি লোকালহোস্ট ব্যবহার করে একে অপরের সাথে যোগাযোগ করতে পারে। যখন একটি পডের কন্টেইনারগুলি পডের বাইরে এনটিটির সাথে যোগাযোগ করে, তখন তাদের অবশ্যই সমন্বয় করতে হবে যে তারা কীভাবে ভাগ করা নেটওয়ার্ক রিসোর্সগুলি (যেমন পোর্ট) ব্যবহার করে। একটি পডের মধ্যে, কন্টেইনারগুলি একটি আইপি ঠিকানা এবং পোর্ট স্পেস ভাগ করে এবং একে অপরকে লোকালহোস্ট এর মাধ্যমে খুঁজে পেতে পারে। একটি পডের কন্টেইনারগুলি যেমন SystemV semaphores বা POSIX শেয়ার্ড মেমরির সাথে স্ট্যান্ডার্ড ইন্টার-প্রসেস ব্যবহার করে একে অপরের সাথে যোগাযোগ করতে পারে। বিভিন্ন পডের কন্টেইনারগুলির ইউনিক IP এড্রেস থাকে এবং বিশেষ কনফিগারেশন ছাড়া OS-লেভেলের IPC দ্বারা যোগাযোগ করতে পারে না। যে কন্টেইনারগুলি একটি ভিন্ন পডে চলমান একটি কন্টেইনারের সাথে ইন্টারঅ্যাক্ট করতে চায় তারা যোগাযোগের জন্য আইপি নেটওয়ার্কিং ব্যবহার করতে পারে।

পডের মধ্যে থাকা কন্টেইনারগুলি সিস্টেমের হোস্টনামটিকে পডের জন্য কনফিগার করা নাম-এর মতই দেখতে পায়। এই সেকশনে networking এই বিষয়ে আরো আছে।

কন্টেইনারগুলির জন্য বিশেষাধিকার মোড

অপারেটিং সিস্টেমের প্রশাসনিক ক্ষমতা ব্যবহার করার জন্য একটি পডের যেকোনো কন্টেইনার বিশেষ সুবিধাপ্রাপ্ত মোডে চলতে পারে যা অন্যথায় অ্যাক্সেসযোগ্য হবে না। এটি উইন্ডোজ এবং লিনাক্স উভয়ের জন্যই সহজলভ্য।

লিনাক্স বিশেষাধিকার কন্টেইনার

লিনাক্সে, পডের যেকোনো কনটেইনার স্পেকের নিরাপত্তা প্রসঙ্গ তে privileged (লিনাক্স) ফ্লাগ ব্যবহার করে সুবিধাপ্রাপ্ত মোড সক্রিয় করতে পারে। এটি এমন কন্টেইনারগুলির জন্য দরকারী যেগুলি অপারেটিং সিস্টেমের প্রশাসনিক ক্ষমতাগুলি ব্যবহার করতে চায় যেমন নেটওয়ার্ক স্ট্যাক নিপূণভাবে ব্যবহার করা বা হার্ডওয়্যার ডিভাইসগুলি অ্যাক্সেস করা।

উইন্ডোজ বিশেষাধিকার কন্টেইনার

উইন্ডোজে, আপনি পড স্পেকের নিরাপত্তা প্রসঙ্গে windowsOptions.hostProcess ফ্লাগ সেট করে একটি উইন্ডোজে HostProcess পড তৈরি করতে পারেন। এই পডের সমস্ত কন্টেইনার অবশ্যই উইন্ডোজ HostProcess কন্টেইনার হিসাবে চালাতে হবে। HostProcess পডগুলি সরাসরি হোস্টে চলে এবং লিনাক্স সুবিধাপ্রাপ্ত কন্টেইনারগুলির মতো প্রশাসনিক কাজ সম্পাদন করতেও ব্যবহার করা যেতে পারে।

স্ট্যাটিক পডগুলি

স্ট্যাটিক পডগুলি একটি নির্দিষ্ট নোডে kubelet daemon দ্বারা সরাসরি পরিচালিত হয়, API সার্ভার তাদের পর্যবেক্ষণ করে না। যেখানে বেশিরভাগ পড নিয়ন্ত্রণ কন্ট্রোল প্লেন দ্বারা পরিচালিত হয় (উদাহরণস্বরূপ, একটি ডিপ্লয়মেন্ট), স্ট্যাটিক পডগুলির জন্য, kubelet সরাসরি প্রতিটি স্ট্যাটিক পডের তত্ত্বাবধান করে (এবং এটি ব্যর্থ হলে পুনরায় চালু করে)।

একটি নির্দিষ্ট নোডে স্ট্যাটিক পডগুলি সবসময় একটি Kubelet এর সাথে আবদ্ধ থাকে। স্ট্যাটিক পডের প্রধান ব্যবহার হল একটি স্ব-হোস্টেড কন্ট্রোল প্লেনে চালানো: অন্য কথায়, ব্যক্তিগত কন্ট্রোল প্লেন উপাদান তত্ত্বাবধানে kubelet ব্যবহার করা।

kubelet স্বয়ংক্রিয়ভাবে প্রতিটি স্ট্যাটিক পডের জন্য কুবারনেটিস API সার্ভারে একটি মিরর পড তৈরির চেষ্টা করে। এর মানে হল যে একটি নোডে চলমান পডগুলি API সার্ভারে দৃশ্যমান, তবে সেখান থেকে নিয়ন্ত্রণ করা যায় না। আরও তথ্যের জন্য স্থির পড তৈরি করুন গাইডটি দেখুন।

একাধিক কন্টেইনার সহ পড

পডগুলি একাধিক সহযোগিতা প্রক্রিয়া (কন্টেইনার হিসাবে) সমর্থন করার জন্য ডিজাইন করা হয়েছে যা পরিষেবার একটি সমন্বিত একক গঠন করে। একটি পডের কন্টেইনারগুলি ক্লাস্টারের একই ফিজিক্যাল বা ভার্চুয়াল মেশিনে স্বয়ংক্রিয়ভাবে সহ-অবস্থিত এবং সহ-নির্ধারিত। কন্টেইনারগুলি রিসোর্স এবং নির্ভরতা ভাগ করে নিতে পারে, একে অপরের সাথে যোগাযোগ করতে পারে এবং কখন এবং কীভাবে সেগুলি বন্ধ করা হয় তা সমন্বয় করতে পারে।

কুবারনেটিস ক্লাস্টারের পড দুটি প্রধান উপায়ে ব্যবহৃত হয়:

• পড যা একটি একক কন্টেইনার চালায়। "এক-কন্টেইনার-প্রতি-পড" মডেলটি কুবারনেটিসের সবচেয়ে সাধারণ ব্যবহারের ক্ষেত্রে; এই ক্ষেত্রে, আপনি একটি একক কন্টেইনারের চারপাশে একটি মোড়ক হিসাবে একটি পডকে ভাবতে পারেন; কুবারনেটস সরাসরি কন্টেইনারগুলি পরিচালনা করার পরিবর্তে পডগুলি পরিচালনা করে।
• পড যা একাধিক কন্টেইনার চালায় যেগুলি একসাথে কাজ করতে হবে। একটি পড একাধিক সহ-অবস্থিত কন্টেইনারে গঠিত একটি অ্যাপ্লিকেশনকে এনক্যাপসুলেট করতে পারে যা শক্তভাবে সংযুক্ত থাকে এবং রিসোর্স ভাগ করে নেওয়ার প্রয়োজন হয়। এই সহ-অবস্থিত কন্টেইনারগুলি পরিষেবার একটি একক সমন্বিত ইউনিট গঠন করে—উদাহরণস্বরূপ, একটি কন্টেইনার জনসাধারণের কাছে ভাগ করা ভলিউমে ডেটা সংরক্ষণ করে, যখন একটি পৃথক সাইডকার কন্টেইনার সেই ফাইলগুলিকে রিফ্রেশ বা আপডেট করে৷ পড এই কন্টেইনার, স্টোরেজ রিসোর্স এবং একটি ক্ষণস্থায়ী নেটওয়ার্ক পরিচয়কে একক ইউনিট হিসাবে একত্রে মোড়ক করে।

উদাহরণস্বরূপ, আপনার কাছে একটি কন্টেইনার থাকতে পারে যেটি একটি শেয়ার্ড ভলিউমের ফাইলগুলির জন্য একটি ওয়েব সার্ভার হিসাবে কাজ করে এবং একটি পৃথক সাইডকার কন্টেইনার যা একটি দূরবর্তী উৎস থেকে সেই ফাইলগুলিকে আপডেট করে, যেমনটি নিম্নলিখিত চিত্রে রয়েছে:

কিছু পডের আছে init কন্টেইনার পাশাপাশি অ্যাপ কন্টেইনার। ডিফল্টরূপে, init কন্টেইনারগুলি অ্যাপ কন্টেইনারগুলি শুরু হওয়ার আগে চলে এবং সম্পূর্ণ হয়।

আপনার কাছে সাইডকার কন্টেইনার থাকতে পারে যেগুলি প্রধান অ্যাপ্লিকেশন পডকে সহায়ক পরিষেবা প্রদান করে (উদাহরণস্বরূপ: একটি পরিষেবা মেশ)।

ডিফল্টরূপে সক্রিয় করা হয়েছে, SidecarContainers ফিচার গেট init কন্টেইনারগুলির জন্য আপনাকে restartPolicy: Always নির্দিষ্ট করতে দেয়। Always পুনঃসূচনা নীতি সেট করা নিশ্চিত করে যে কন্টেইনারগুলি যেখানে আপনি এটি সেট করেছেন সেগুলিকে sidecars হিসাবে গণ্য করা হয় যেগুলি পডের পুরো জীবনকাল চলা অবস্থায় থাকে। যে কন্টেইনারগুলিকে আপনি স্পষ্টভাবে সাইডকার কন্টেনার হিসাবে সংজ্ঞায়িত করেছেন সেগুলি মূল অ্যাপ্লিকেশন পডের আগে শুরু হয় এবং পড বন্ধ না হওয়া পর্যন্ত চলমান থাকে।

কন্টেইনার probes

একটি probe একটি ডায়াগনস্টিক যা একটি কন্টেইনার kubelet দ্বারা পর্যায়ক্রমে সম্পাদিত হয়। একটি ডায়গনিস্টিক সঞ্চালনের জন্য, kubelet বিভিন্ন ক্রিয়াকলাপ করতে পারে:

• ExecAction (কন্টেইনারের রানটাইমের সাহায্যে সম্পাদিত হয়েছে)
• TCPSocketAction (kubelet দ্বারা সরাসরি চেক করা হয়েছে)
• HTTPGetAction (kubelet দ্বারা সরাসরি চেক করা হয়েছে)

আপনি পডের জীবনচক্র ডকুমেন্টেশনে probes সম্পর্কে আরও পড়তে পারেন।

এর পরের কি

• একটি পডের জীবনচক্র সম্পর্কে জানুন।
• RuntimeClass সম্পর্কে জানুন এবং আপনি কীভাবে এটি ব্যবহার করতে পারেন বিভিন্ন কন্টেইনারের রানটাইম কনফিগারেশন সহ বিভিন্ন পড কনফিগার করুন।
• PodDisruptionBudget সম্পর্কে পড়ুন এবং প্রতিবন্ধকতার সময় অ্যাপ্লিকেশনের প্রাপ্যতা পরিচালনা করার জন্য আপনি কীভাবে এটি ব্যবহার করতে পারেন।
• Pod হল Kubernetes REST API-এর একটি শীর্ষ-স্তরের রিসোর্স। Pod অবজেক্টের সংজ্ঞা বস্তুর বিস্তারিত বর্ণনা করে।
• ডিস্ট্রিবিউটেড সিস্টেম টুলকিট: কম্পোজিট কন্টেইনারগুলির জন্য প্যাটার্ন একাধিক কন্টেইনার সহ পডগুলির জন্য সাধারণ লেআউটগুলি ব্যাখ্যা করে।
• [পড টপোলজি স্প্রেড সীমাবদ্ধতা] (/docs/concepts/scheduling-eviction/topology-spread-constraints/) সম্পর্কে পড়ুন।

কুবারনেটিস কেন অন্যান্য রিসোর্সগুলিতে মোড়ানোর প্রসঙ্গটি বোঝার জন্য একটি সাধারণ পড API (যেমন স্টেটফুল সেট) বা ডিপলয়মেন্ট) তে , আপনি পূর্ববর্তী আর্ট সম্পর্কে পড়তে পারেন, যার মধ্যে রয়েছে:

• Aurora
• Borg
• Marathon
• Omega
• Tupperware।

4.1.1 - সাইডকার কন্টেইনার

সাইডকার কন্টেইনার হল সেকেন্ডারি কন্টেইনার যা একই পড এর মধ্যে প্রধান অ্যাপ্লিকেশন কন্টেইনারের সাথে চলে। এই কন্টেইনারগুলি প্রাথমিক অ্যাপ্লিকেশন কোডটি সরাসরি পরিবর্তন না করেই অতিরিক্ত পরিষেবা, বা লগিং, মনিটরিং, নিরাপত্তা বা ডেটা সিঙ্ক্রোনাইজেশনের মতো কার্যকারিতা প্রদান করে প্রধান অ্যাপ্লিকেশন কন্টেইনারের কার্যকারিতা বাড়াতে বা প্রসারিত করতে ব্যবহৃত হয়।

সাধারণত, আপনার একটি পডে শুধুমাত্র একটি অ্যাপ কন্টেইনার থাকে। উদাহরণস্বরূপ, যদি আপনার কাছে একটি ওয়েব অ্যাপ্লিকেশন থাকে যার জন্য একটি লোকাল ওয়েবসার্ভার প্রয়োজন, লোকাল ওয়েব সার্ভারটি একটি সাইডকার এবং ওয়েব অ্যাপ্লিকেশনটি নিজেই অ্যাপ কন্টেইনার৷

কুবারনেটিসের মধ্যে সাইডকার কন্টেইনার

কুবারনেটিস একটি বিশেষ ক্ষেত্রে init কন্টেইনারে; পড স্টার্টআপের পরে সাইডকারের কন্টেইনারগুলি চলমান থাকে। এই নথিটি regular init containers শব্দটি ব্যবহার করে স্পষ্টভাবে সেই কন্টেইনারগুলিকে বোঝাতে যা শুধুমাত্র পড স্টার্টআপের সময় চলে।

আপনার ক্লাস্টারে SidecarContainers ফিচার গেট এনেবলড করা থাকলে (কুবারনেটস v1.29 থেকে ফিচারটি ডিফল্টরূপে সক্রিয় থাকে), আপনি একটি restartPolicy নির্দিষ্ট করতে পারেন পডের initContainers ক্ষেত্রে তালিকাভুক্ত কন্টেইনারগুলির জন্য। এই রিস্টার্টেবল sidecar কন্টেইনারগুলি অন্যান্য init কন্টেইনার থেকে এবং একই পডের মধ্যে প্রধান অ্যাপ্লিকেশন কন্টেইনার(গুলি) থেকে স্বাধীন। এগুলি মূল অ্যাপ্লিকেশন কন্টেইনার এবং অন্যান্য init কন্টেইনারগুলিকে প্রভাবিত না করেই শুরু, বন্ধ এবং পুনরায় চালু করা যেতে পারে।

আপনি একাধিক কন্টেইনারে একটি পড চালাতে পারেন যেগুলি init বা সাইডকার কন্টেইনার হিসাবে চিহ্নিত নয়৷ এটি উপযুক্ত যদি পডের মধ্যে থাকা কন্টেইনারগুলি পডের সামগ্রিকভাবে কাজ করার জন্য প্রয়োজন হয়, তবে আপনার কোন কন্টেইনারগুলি প্রথমে শুরু হবে বা থামবে তা নিয়ন্ত্রণ করার দরকার নেই৷ আপনি যদি কুবারনেটিসের পুরানো ভার্শনসগুলিকে সমর্থন করতে চান যা একটি কন্টেইনার-স্তরের restartPolicy ষেত্র সমর্থন করে না তবে আপনি এটিও করতে পারেন।

উদাহরণ অ্যাপ্লিকেশন

এখানে দুটি কন্টেইনার সহ একটি ডেপ্লয়মেন্টের একটি উদাহরণ রয়েছে, যার মধ্যে একটি সাইডকার:

application/deployment-sidecar.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: alpine:latest
          command: ['sh', '-c', 'while true; do echo "logging" >> /opt/logs.txt; sleep 1; done']
          volumeMounts:
            - name: data
              mountPath: /opt
      initContainers:
        - name: logshipper
          image: alpine:latest
          restartPolicy: Always
          command: ['sh', '-c', 'tail -F /opt/logs.txt']
          volumeMounts:
            - name: data
              mountPath: /opt
      volumes:
        - name: data
          emptyDir: {}

সাইডকার কন্টেইনার এবং পড জীবনচক্র (Pod lifecycle)

যদি একটি init কন্টেইনার তৈরি করা হয় তার restartPolicy Always সেট করে, তাহলে এটি শুরু হবে এবং পডের পুরো জীবনকালে চলতে থাকবে। এটি প্রধান অ্যাপ্লিকেশন কন্টেইনারগুলি থেকে আলাদা করে সহায়ক সেবা চালানোর জন্য সহায়ক হতে পারে৷

যদি এই init কন্টেইনারের জন্য একটি readinessProbe নির্দিষ্ট করা হয়, তাহলে এর ফলাফল পডের রেডি অবস্থা নির্ধারণ করতে ব্যবহার করা হবে।

যেহেতু এই কন্টেইনারগুলিকে init কন্টেইনার হিসাবে সংজ্ঞায়িত করা হয়, তাই তারা অন্যান্য init কন্টেইনারগুলির মতো একই ক্রম এবং অনুক্রমিক গ্যারান্টি থেকে উপকৃত হয়, যাতে সেগুলিকে জটিল পড ইনিশিয়ালাইজেশন প্রবাহে অন্যান্য init কন্টেইনার মিশ্রিত করা যায়।

রেগুলার init কন্টেইনারগুলির তুলনায়, initContainers-এর মধ্যে সংজ্ঞায়িত সাইডকারগুলি শুরু হওয়ার পরে চলতে থাকে। এটি গুরুত্বপূর্ণ যখন একটি পডের জন্য .spec.initContainers এর ভিতরে একাধিক এন্ট্রি থাকে। একটি সাইডকার-স্টাইলের init কন্টেইনার চালু হওয়ার পরে (কুবেলেট (kubelet) সেই init কন্টেইনারের জন্য start স্ট্যাটাসটিকে সত্যে সেট করেছে), কুবেলেট (kubelet) তারপর অর্ডারকৃত .spec.initContainers তালিকা থেকে পরবর্তী init কন্টেইনার শুরু করে। সেই স্ট্যাটাসটি হয় সত্য হয়ে যায় কারণ কন্টেইনারে একটি প্রক্রিয়া চলছে এবং কোনো স্টার্টআপ প্রোব (probe) সংজ্ঞায়িত করা হয়নি, অথবা এর startupProbe সফল হওয়ার ফলে।

সাইডকার কন্টেইনারে জবস (Jobs with sidecar containers)

আপনি যদি কুবারনেটস-স্টাইলের init কন্টেইনার ব্যবহার করে সাইডকার ব্যবহার করে এমন একটি জব (job) ডিফাইন করেন, তবে প্রতিটি পডের সাইডকার কন্টেইনার মূল কন্টেইনার শেষ হওয়ার পরে কাজটি সম্পূর্ণ হতে বাধা দেয় না।

এখানে দুটি কন্টেইনার সহ একটি কাজের উদাহরণ রয়েছে, যার মধ্যে একটি সাইডকার:

application/job/job-sidecar.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: myjob
spec:
  template:
    spec:
      containers:
        - name: myjob
          image: alpine:latest
          command: ['sh', '-c', 'echo "logging" > /opt/logs.txt']
          volumeMounts:
            - name: data
              mountPath: /opt
      initContainers:
        - name: logshipper
          image: alpine:latest
          restartPolicy: Always
          command: ['sh', '-c', 'tail -F /opt/logs.txt']
          volumeMounts:
            - name: data
              mountPath: /opt
      restartPolicy: Never
      volumes:
        - name: data
          emptyDir: {}

অ্যাপ্লিকেশন কন্টেইনার থেকে পার্থক্য

সাইডকার কন্টেইনারগুলি একই পডে app containers পাশাপাশি চলে৷ যাইহোক, তারা প্রাইমারি প্রয়োগ যুক্তি এক্সিকিউট না করে; পরিবর্তে, তারা প্রধান অ্যাপ্লিকেশনে সহায়ক কার্যকারিতা প্রদান করে।

সাইডকার কন্টেইনারদের নিজস্ব স্বাধীন জীবনচক্র আছে। এগুলি রেগুলার কন্টেইনারে স্বাধীনভাবে শুরু, বন্ধ এবং পুনরায় চালু করা যেতে পারে। এর মানে আপনি প্রাইমারি অ্যাপ্লিকেশনকে প্রভাবিত না করেই আপডেট, স্কেল বা মেইনটেইন করতে পারবেন।

সাইডকার কন্টেইনার প্রাইমারি কন্টেইনারের সাথে একই নেটওয়ার্ক এবং স্টোরেজ নেমস্পেস শেয়ার করে। এই সহ-অবস্থান তাদের ঘনিষ্ঠভাবে ইন্টারঅ্যাক্ট করতে এবং সম্পদ শেয়ার করতে দেয়।

init কন্টেইনার থেকে পার্থক্য

সাইডকার কন্টেইনার প্রধান কন্টেইনারের পাশাপাশি কাজ করে, এর কার্যকারিতা প্রসারিত করে এবং অতিরিক্ত পরিষেবা প্রদান করে।

সাইডকার কন্টেইনার প্রধান অ্যাপ্লিকেশন কন্টেইনারের সাথে একযোগে চালান। তারা পডের জীবনচক্র জুড়ে সক্রিয় থাকে এবং মূল কন্টেইনার থেকে স্বাধীনভাবে শুরু এবং বন্ধ করা যেতে পারে। init কন্টেইনার থেকে ভিন্ন, সাইডকার কন্টেইনার সমর্থন probe নিয়ন্ত্রণ করতে তাদের জীবনচক্র।

সাইডকার কন্টেইনারগুলি প্রধান অ্যাপ্লিকেশন কন্টেইনারগুলির সাথে সরাসরি ইন্টারঅ্যাক্ট করতে পারে, কারণ init কন্টেইনারগুলির মতো তারা সবসময় একই নেটওয়ার্ক ভাগ করে এবং ঐচ্ছিকভাবে ভলিউম (ফাইলসিস্টেম) ভাগ করতে পারে।

Init কন্টেইনারগুলি মূল পাত্রে শুরু হওয়ার আগে বন্ধ হয়ে যায়, তাই init কন্টেইনারগুলি একটি Pod-এ অ্যাপ কন্টেইনারের সাথে মেসেজেস বিনিময় করতে পারে না। যে কোনো ডেটা পাসিং একমুখী হয় (উদাহরণস্বরূপ, একটি init কন্টেইনার একটি emptyDir ভলিউমের মধ্যে তথ্য রাখতে পারে)।

কন্টেইনারে সম্পদ ভাগাভাগি

init, sidecar এবং অ্যাপ কন্টেইনারগুলির জন্য কার্যকর করার আদেশ দেওয়া হলে, সম্পদ ব্যবহারের জন্য নিম্নলিখিত নিয়মগুলি প্রযোজ্য:

• সমস্ত init কন্টেইনার সংজ্ঞায়িত কোনো নির্দিষ্ট রিসোর্স অনুরোধ বা সীমার মধ্যে সর্বোচ্চ হল এফেক্টিভ রিকোয়েস্ট/লিমিট। যদি কোন সম্পদের কোন সম্পদ সীমা নির্দিষ্ট না থাকে তবে এটি সর্বোচ্চ সীমা হিসাবে বিবেচিত হয়।
• একটি সম্পদের জন্য Pod এর এফেক্টিভ রিকোয়েস্ট/লিমিট হল pod overhead এর সমষ্টি এবং এর উচ্চতর:
  • সমস্ত non-init কন্টেইনারের সমষ্টি (অ্যাপ এবং সাইডকার কন্টেইনার) রিসোর্সের জন্য অনুরোধ/সীমা
  • একটি সম্পদের জন্য এফেক্টিভ রিকোয়েস্ট/লিমিট
• সময়সূচী কার্যকরী অনুরোধ/সীমার উপর ভিত্তি করে করা হয়, যার অর্থ init কন্টেইনারগুলি প্রারম্ভিকতার জন্য সংস্থান সংরক্ষণ করতে পারে যা পডের জীবদ্দশায় ব্যবহৃত হয় না।
• পডের কার্যকর QoS টিয়ার এর QoS (পরিষেবার গুণমান) স্তর হল সমস্ত init, সাইডকার এবং অ্যাপ কন্টেইনারগুলির জন্য QoS স্তর।

কার্যকর পড অনুরোধ এবং সীমার উপর ভিত্তি করে কোটা এবং সীমা প্রয়োগ করা হয়।

সাইডকার কন্টেইনার এবং লিনাক্স cgroups

লিনাক্সে, পড লেভেল কন্ট্রোল গ্রুপের (cgroups) জন্য রিসোর্স বরাদ্দ করা হয় কার্যকর পড রিকোয়েস্ট এবং লিমিট উপর ভিত্তি করে, যেমন শিডিউলারের মতো।

এর পরের কি

• নেটিভ সাইডকার কন্টেইনারে এ একটি ব্লগ পোস্ট পড়ুন।
• একটি পড তৈরি করা যাতে একটি init কন্টেইনার রয়েছে সম্পর্কে পড়ুন।
• প্রোবের প্রকার সম্পর্কে জানুন: সজীবতা, প্রস্তুতি, স্টার্টআপ প্রোব।
• pod overhead সম্পর্কে জানুন।

4.2 - ওয়ার্কলোড ম্যানেজমেন্ট

কুবারনেটিস বিভিন্ন বিল্ট ইন API দেয় ঘোষণামূলক ম্যানেজমেন্ট ওয়ার্কলোড এবং ওয়ার্কলোডের উপাদানের জন্য।

অবশেষে, আপনার অ্যাপ্লিকেশন পডের মধ্যে রান হয় কন্টেইনার হিসেবে; যাইহোক, একক পড ম্যানেজ করা কষ্টসাধ্য। উদাহরণস্বরূপ, যদি একটি পড ব্যর্থ হয়, আপনি তাহলে নতুন পড চালিয়ে এটিকে রিপ্লেস করতে চাইবেন। কুবারনেটিস আপনার জন্য এটি করে দিবে।

আপনি ওয়ার্ক লোড তৈরি করার জন্য কুবারনেটিস API ব্যবহার করতে পারেন অবজেক্ট যা পড থেকে বেশি অবস্ট্রাক্শন লেভেল প্রদর্শন করে, তারপর কুবারনেটিস কন্ট্রোল প্লেন স্বয়ংক্রিয়ভাবে আপনার পক্ষ থেকে পড অবজেক্ট পরিচালনা করে, আপনার সংজ্ঞায়িত ওয়ার্কলোড অবজেক্টের স্পেসিফিকেশনের উপর ভিত্তি করে।

ওয়ার্কলোড পরিচালনার জন্য বিল্ট ইন API গুলো হলো:

ডিপ্লয়মেন্ট (এবং, পরোক্ষভাবে, রেপ্লিকাসেট), আপনার ক্লাস্টারে একটি অ্যাপ্লিকেশন চালানোর সবচেয়ে সাধারণ উপায়। ক্লাস্টারে একটি স্টেটলেস অ্যাপ্লিকেশান ওয়ার্কলোড পরিচালনা করার জন্য ডিপ্লয়মেন্ট একটি উপযুক্ত ব্যবস্থা , যেখানে ডিপ্লয়মেন্টের যেকোনো পড বিনিময়যোগ্য এবং প্রয়োজনে প্রতিস্থাপন করা যেতে পারে। (ডিপ্লয়মেন্ট হলো একটি প্রতিস্থাপন ব্যবস্থা লিগেসি ReplicationController API এর).

একটি স্টেটফুলসেট আপনাকে অনুমতি দেয় এক বা একাধিক পড পরিচালনা করার – সব একই অ্যাপ্লিকেশন কোড চালায় – যেখানে পড একটি স্বতন্ত্র পরিচয় রাখতে চায়। এটি ডিপ্লয়মেন্ট থেকে ভিন্ন যেখানে পড বিনিময়যোগ্য হয়ে থাকে । স্টেটফুলসেটের সাধারণ কাজ হলো পড এবং পারসিসটেন্ট স্টোরেজ এর মধ্যে একটি লিঙ্ক তৈরি করা। উদাহরণস্বরূপ, আপনি একটি স্টেটফুল সেট চালাতে পারেন যা প্রতিটি পডকে সংযুক্ত করে একটি PersistentVolume এর সাহায্যে।যদি স্টেটফুলসেটের একটি পডও ব্যর্থ হয়, তাহলে কুবারনেটিস একটি প্রতিস্থাপন পড তৈরি করে যা একই PersistentVolume এর সাথে সংযুক্ত থাকে।

একটি ডেমনসেট পডগুলোকে সংজ্ঞায়িত করে যা একটি নির্দিষ্ট নোড লোকাল সুবিধা প্রদান করে; উদাহরণস্বরূপ, ড্রাইভার নোডের কন্টেইনারগুলোকে স্টোরেজ সিস্টেম অ্যাক্সেস করতে দেয়। আপনি তখন ডেমনসেট ব্যবহার করতে পারেন যখন ড্রাইভার, বা অন্যান্য নোড-লেভেলের সার্ভিস,নোডে চালাতে হবে যেখানে এটি দরকারী। ডেমনসেটের প্রতিটি পড একটি ক্লাসিক Unix / POSIX সার্ভারে সিস্টেম ডেমনের মতো একই ভূমিকা পালন করে। একটি ডেমনসেট আপনার ক্লাস্টার পরিচালনার জন্য গুরুত্বপূর্ণ হতে পারে, যেমন একটি প্লাগইন নোড অ্যাক্সেস করতে দেয় ক্লাস্টার নেটওয়ার্কিং, এটি আপনাকে নোড পরিচালনা করতে সাহায্য করতে পারে, বা এটি কম সুবিধা প্রদান করতে পারে যা আপনি যে কন্টেইনার প্ল্যাটফর্মটি চালাচ্ছেন তা উন্নত করে। আপনি আপনার ক্লাস্টারের প্রতিটি নোড জুড়ে বা শুধুমাত্র একটি উপসেট জুড়ে ডেমনসেট (এবং তাদের পড) চালাতে পারেন (উদাহরণস্বরূপ, শুধুমাত্র GPU ইনস্টল করা নোডগুলিতে GPU এক্সিলারেটর ড্রাইভার ইনস্টল করুন)।

আপনি একটি Job এবং / বা একটি CronJob ব্যবহার করতে পারেন যা কাজগুলোকে চিহ্নিত করবে যা সমাপ্তির জন্য চলবে পরে থামবে। একটি Job একটি একক টাস্কের প্রতিনিধিত্ব করে, যেখানে প্রতিটি CronJob একটি শিডিউল অনুযায়ী পুনরাবৃত্তি করে।

এই বিভাগে অন্যান্য বিষয়:

4.3 - অটোস্কেলিং ওয়ার্কলোড

কুবারনেটিসে, আপনি বর্তমান রিসোর্স চাহিদার উপর নির্ভর করে একটি ওয়ার্কলোড স্কেল করতে পারেন। এটি আপনার ক্লাস্টারকে রিসোর্স চাহিদার পরিবর্তনে আরও নমনীয় এবং দক্ষতার সাথে প্রতিক্রিয়া জানাতে সাহায্য করে।

যখন আপনি একটি ওয়ার্কলোড স্কেল করেন, তখন আপনি ওয়ার্কলোড দ্বারা পরিচালিত রেপ্লিকাগুলির সংখ্যা বাড়াতে বা কমাতে পারেন, অথবা রেপ্লিকাগুলিতে উপলব্ধ রিসোর্সগুলি সরাসরি সামঞ্জস্য করতে পারেন।

প্রথম পদ্ধতিটিকে হরিজন্টাল স্কেলিং বলা হয়, যেখানে দ্বিতীয়টিকে ভার্টিকাল স্কেলিং বলা হয়।

আপনার ব্যবহার কেসের উপর নির্ভর করে, আপনার ওয়ার্কলোডগুলি স্কেল করার ম্যানুয়াল এবং স্বয়ংক্রিয় উপায় রয়েছে।

ম্যানুয়ালি ওয়ার্কলোড স্কেলিং

কুবারনেটিস ওয়ার্কলোডের ম্যানুয়াল স্কেলিং সমর্থন করে। হরিজন্টাল স্কেলিং kubectl CLI ব্যবহার করে করা যায়। ভার্টিকাল স্কেলিং এর জন্য, আপনাকে আপনার ওয়ার্কলোডের রিসোর্স সংজ্ঞা patch করতে হবে।

উভয় কৌশলের উদাহরণ নীচে দেওয়া হল।

• হরিজন্টাল স্কেলিং (Horizontal scaling): আপনার অ্যাপের একাধিক ইনস্ট্যান্স চালানো
• ভার্টিকাল স্কেলিং (Vertical scaling): কন্টেইনারগুলিতে বরাদ্দকৃত CPU এবং মেমরি রিসোর্স পুনরায় আকার দেওয়া

স্বয়ংক্রিয়ভাবে ওয়ার্কলোড স্কেলিং

কুবারনেটিস ওয়ার্কলোডের _স্বয়ংক্রিয় স্কেলিং_ও সমর্থন করে, যা এই পেজ এর মূল ফোকাস।

কুবারনেটিসে অটোস্কেলিং ধারণাটি নির্দেশ করে স্বয়ংক্রিয়ভাবে একটি এমন অবজেক্ট আপডেট করার ক্ষমতা যা পডের একটি সেট পরিচালনা করে (উদাহরণস্বরূপ একটি ডিপ্লয়মেন্ট)।

হরিজন্টালি ওয়ার্কলোড স্কেলিং

কুবারনেটিসে, আপনি হরিজন্টালপডঅটোস্কেলার (HPA) ব্যবহার করে স্বয়ংক্রিয়ভাবে একটি ওয়ার্কলোড হরিজন্টালি স্কেল করতে পারেন।

এটি কুবারনেটিস API রিসোর্স এবং একটি কন্ট্রোলার হিসাবে বাস্তবায়িত এবং নিয়মিতভাবে ওয়ার্কলোডে রেপ্লিকা সংখ্যা সামঞ্জস্য করে যাতে পর্যবেক্ষিত রিসোর্স ব্যবহার যেমন CPU বা মেমরি ব্যবহারের সাথে মিল থাকে।

একটি ডিপ্লয়মেন্টের জন্য HorizontalPodAutoscaler কনফিগার করার একটি ওয়াকথ্রু টিউটোরিয়াল রয়েছে।

ভার্টিকালি ওয়ার্কলোড স্কেলিং

আপনি ভার্টিকালপডঅটোস্কেলার (VPA) ব্যবহার করে স্বয়ংক্রিয়ভাবে একটি ওয়ার্কলোড ভার্টিকালি স্কেল করতে পারেন। HPA-এর বিপরীতে, VPA ডিফল্টভাবে কুবারনেটিসের সাথে আসে না, কিন্তু একটি পৃথক প্রকল্প যা GitHub-এ পাওয়া যাবে।

ইনস্টল করার পরে, এটি আপনাকে আপনার ওয়ার্কলোডগুলির জন্য কাস্টমরিসোর্সডেফিনিশন (CRDs) তৈরি করতে দেয় যা পরিচালিত রেপ্লিকার রিসোর্সগুলি কীভাবে এবং কখন স্কেল করা হবে তা সংজ্ঞায়িত করে।

বর্তমানে, VPA চারটি ভিন্ন মোডে কাজ করতে পারে:

in-place রিসাইজিং এর জন্য প্রয়োজনীয়তা

in-place একটি ওয়ার্কলোড রিসাইজিং ছাড়া পড বা এর কন্টেইনার রিস্টার্ট করার জন্য কুবারনেটিস ভার্সন 1.27 বা পরবর্তী প্রয়োজন। এছাড়াও, InPlaceVerticalScaling ফিচার গেট এনাবল্ করা প্রয়োজন।

InPlacePodVerticalScaling: ইন-প্লেস পড ভার্টিক্যাল স্কেলিং সক্ষম করে।

ক্লাস্টারের আকারের উপর ভিত্তি করে অটোস্কেলিং

যেসব ওয়ার্কলোড ক্লাস্টারের আকারের উপর ভিত্তি করে স্কেল করতে হয় (উদাহরণস্বরূপ cluster-dns বা অন্যান্য সিস্টেম কম্পোনেন্ট), আপনি ক্লাস্টার প্রপোরশনাল অটোস্কেলার ব্যবহার করতে পারেন। VPA-এর মতোই, এটি কুবারনেটিস কোরের অংশ নয়, বরং GitHub-এ নিজস্ব প্রকল্প হিসাবে হোস্ট করা হয়েছে।

ক্লাস্টার প্রপোরশনাল অটোস্কেলার শিডিউলযোগ্য নোডগুলো এবং কোরের সংখ্যা পর্যবেক্ষণ করে এবং সেই অনুযায়ী টার্গেট ওয়ার্কলোডের রেপ্লিকার সংখ্যা স্কেল করে।

যদি রেপ্লিকার সংখ্যা একই থাকা উচিত হয়, আপনি ক্লাস্টার প্রপোরশনাল ভার্টিকাল অটোস্কেলার ব্যবহার করে ক্লাস্টারের আকার অনুযায়ী আপনার ওয়ার্কলোডগুলিকে ভার্টিকালি স্কেল করতে পারেন। প্রকল্পটি বর্তমানে বিটা অবস্থায় আছে এবং GitHub-এ পাওয়া যাবে।

যেখানে ক্লাস্টার প্রপোরশনাল অটোস্কেলার একটি ওয়ার্কলোডের রেপ্লিকার সংখ্যা স্কেল করে, সেখানে ক্লাস্টার প্রপোরশনাল ভার্টিকাল অটোস্কেলার ক্লাস্টারের নোড এবং/অথবা কোরের সংখ্যার উপর ভিত্তি করে একটি ওয়ার্কলোডের (যেমন একটি ডিপ্লয়মেন্ট বা ডেমনসেট) রিসোর্স রিকোয়েস্টগুলি এডজাস্ট করে।

ইভেন্ট চালিত অটোস্কেলিং

ইভেন্টের উপর ভিত্তি করে ওয়ার্কলোড স্কেল করাও সম্ভব, উদাহরণস্বরূপ কুবারনেটিস ইভেন্ট ড্রিভেন অটোস্কেলার (KEDA) ব্যবহার করে।

KEDA হল একটি CNCF গ্র্যাজুয়েটেড প্রকল্প যা আপনাকে প্রক্রিয়াকরণের জন্য ইভেন্টের সংখ্যার উপর ভিত্তি করে আপনার ওয়ার্কলোড স্কেল করতে সক্ষম করে, উদাহরণস্বরূপ একটি কিউতে বার্তার পরিমাণ। বিভিন্ন ইভেন্ট সোর্সের জন্য বিস্তৃত পরিসরের অ্যাডাপ্টার বিদ্যমান।

সময়সূচী ভিত্তিক অটোস্কেলিং

আপনার ওয়ার্কলোড স্কেল করার আরেকটি কৌশল হল স্কেলিং অপারেশনগুলি সময়সূচীবদ্ধ করা, উদাহরণস্বরূপ অফ-পিক সময়ে রিসোর্স ব্যবহার কমানোর জন্য।

ইভেন্ট চালিত অটোস্কেলিংয়ের অনুরূপ, এই ধরনের আচরণ KEDA এবং এর Cron স্কেলার একসাথে ব্যবহার করে অর্জন করা যেতে পারে। Cron স্কেলার আপনাকে আপনার ওয়ার্কলোডগুলিকে স্কেল ইন বা আউট করার জন্য সময়সূচী (এবং টাইম জোন) নির্ধারণ করতে দেয়।

ক্লাস্টার ইনফ্রাস্ট্রাকচার স্কেলিং

যদি ওয়ার্কলোড স্কেলিং আপনার চাহিদা পূরণের জন্য যথেষ্ট না হয়, আপনি আপনার ক্লাস্টার ইনফ্রাস্ট্রাকচারকেও স্কেল করতে পারেন।

ক্লাস্টার ইনফ্রাস্ট্রাকচার স্কেলিং সাধারণত nodes। যোগ বা অপসারণ করা বোঝায়। আরও তথ্যের জন্য ক্লাস্টার অটোস্কেলিং পড়ুন।

এর পরের কি

• হরিজন্টাল স্কেলিং সম্পর্কে আরও জানুন
  • স্টেটফুলসেট স্কেল করুন
  • হরিজন্টালপডঅটোস্কেলার ওয়াকথ্রু
• কন্টেইনার রিসোর্স In-Place রিসাইজ করুন
• ক্লাস্টারে DNS সার্ভিস অটোস্কেল করুন
• ক্লাস্টার অটোস্কেলিং সম্পর্কে জানুন

5 - সার্ভিস, লোড ব্যালেন্সিং এবং নেটওয়ার্কিং

কুবারনেটিস নেটওয়ার্ক মডেল

একটি ক্লাস্টারের প্রতিটি পড তার নিজস্ব ক্লাস্টার-ওয়াইড আইপি ঠিকানা পায়। এর অর্থ হলো আপনাকে পডের মধ্যে স্পষ্টভাবে লিঙ্ক তৈরি করার দরকার নেই এবং পোর্টগুলো হোস্ট করার জন্য আপনাকে ম্যাপিং কন্টেইনার পোর্টগুলোর সাথে মোকাবিলা করতে হবে না। এটি একটি পরিষ্কার, পিছনের-সামঞ্জস্যপূর্ণ মডেল (backwards-compatible model) তৈরি করে যেখানে পোর্ট বরাদ্দকরণ, নামকরণ, সার্ভিস আবিষ্কার (service discovery), লোড ব্যালেন্সিং, অ্যাপ্লিকেশন কনফিগারেশন এবং মাইগ্রেশনের দৃষ্টিকোণ থেকে পডগুলোকে অনেকটা ভিএম (Virtual Machine) বা ফিজিক্যাল হোস্টের মতোই বিবেচনা করা যেতে পারে।

কুবারনেটিস যেকোন নেটওয়ার্কিং বাস্তবায়নে নিম্নলিখিত মৌলিক প্রয়োজনীয়তাগুলো আরোপ করে (যেকোনো ইচ্ছাকৃত নেটওয়ার্ক বিভাজন নীতি ব্যতীত):

• পড NAT ছাড়া অন্য কোনো নোডে অন্য সব পডের সঙ্গে যোগাযোগ করতে পারে
• একটি নোডের এজেন্ট (যেমন system daemons, kubelet) সেই নোডের সমস্ত পডের সাথে যোগাযোগ করতে পারে

দ্রষ্টব্য: হোস্ট নেটওয়ার্কে (যেমন লিনাক্স) চলমান পডগুলোকে সমর্থন করে এমন প্ল্যাটফর্মগুলোর জন্য, যখন পডগুলো একটি নোডের হোস্ট নেটওয়ার্কের সাথে সংযুক্ত থাকে তখনও তারা সমস্ত নোডের সমস্ত পডের সাথে যোগাযোগ করতে পারে NAT ছাড়া ৷

এই মডেলটি শুধুমাত্র সামগ্রিকভাবে কম জটিল নয়, এটি প্রধানত কুবারনেটিসের ইচ্ছার সাথে সামঞ্জস্যপূর্ণ যাতে ভিএম থেকে কন্টেইনারে অ্যাপের লো-ফ্রিকশন পোর্টিং সক্ষম করা যায়। যদি আপনার কাজ আগে কোনো ভিএম-এ চলত, তাহলে আপনার ভিএম-এর IP ছিল এবং আপনার প্রোজেক্টের অন্যান্য ভিএম-এর সাথে কথা বলতে পারে। এটি একই মৌলিক মডেল।

কুবারনেটিস আইপি ঠিকানাগুলো পড স্কোপে বিদ্যমান - একটি পডের মধ্যে থাকা কন্টেনারগুলো তাদের নেটওয়ার্ক নেমস্পেসগুলো ভাগ করে - তাদের IP ঠিকানা এবং MAC ঠিকানা সহ। এর মানে হলো যে একটি পডের মধ্যে থাকা কন্টেইনারগুলো একে অপরের পোর্টে লোকালহোস্টে পৌঁছাতে পারে। এটি আরো বোঝায় যে একটি পডের মধ্যে থাকা কন্টেইনারগুলোকে পোর্ট ব্যবহারের সমন্বয় করতে হবে, তবে এটি একটি ভিএম-এর প্রক্রিয়াগুলোর থেকে আলাদা নয়। এটিকে "IP-per-pod" মডেল বলা হয়।

এটি কীভাবে প্রয়োগ করা হয় তা ব্যবহার করা নির্দিষ্ট কন্টেইনার রানটাইমের একটি ডিটেইল।

নোডেই পোর্টের জন্য অনুরোধ করা সম্ভব যা আপনার পডে ফরোয়ার্ড করা হয় (যাকে হোস্ট পোর্ট বলা হয়), কিন্তু এটি একটি খুব বিশিষ্ট অপারেশন। সেই ফরোয়ার্ডিং কীভাবে বাস্তবায়িত হয় তাও কন্টেইনার রানটাইমের ডিটেইল। পড নিজেই হোস্ট পোর্টের অস্তিত্ব বা অ-অস্তিত্ব সম্পর্কে অন্ধ।

কুবারনেটিস নেটওয়ার্কিং চারটি উদ্বেগের সমাধান করে:

• লুপব্যাকের মাধ্যমে একটি পডের মধ্যে কন্টেইনার যোগাযোগের জন্য নেটওয়ার্কিং ব্যবহার করে ।
• ক্লাস্টার নেটওয়ার্কিং বিভিন্ন পডের মধ্যে যোগাযোগ প্রদান করে।
• সার্ভিস API আপনাকে আপনার ক্লাস্টারের বাইরে থেকে পৌঁছানোর জন্য পডসে চলমান একটি অ্যাপ্লিকেশন প্রকাশ করতে দেয় ।
  • ইনগ্রেস বিশেষত HTTP অ্যাপ্লিকেশন, ওয়েবসাইট এবং এপিআই প্রকাশ করার জন্য অতিরিক্ত কার্যকারিতা প্রদান করে।
  • গেটওয়ে API হলো একটি অ্যাড-অন যেটি মডেলিং সার্ভিস নেটওয়ার্কিংয়ের জন্য API ধরণের একটি অভিব্যক্তিপূর্ণ (expressive), এক্সটেনসিবল, এবং ভূমিকা-ভিত্তিক পরিবার প্রদান করে।
• এছাড়া আপনি শুধুমাত্র আপনার ক্লাস্টারের মধ্যে ব্যবহারের জন্য সার্ভিসগুলো প্রকাশ করতে সার্ভিসগুলো ব্যবহার করতে পারেন ।

কানেক্টিং অ্যাপ্লিকেশানস উইথ সার্ভিস টিউটোরিয়াল আপনাকে একটি হ্যান্ডস-অন উদাহরণ সহ পরিষেবা এবং কুবারনেটিস নেটওয়ার্কিং সম্পর্কে শিখতে দেয়।

ক্লাস্টার নেটওয়ার্কিং ব্যাখ্যা করে কিভাবে আপনার ক্লাস্টারের জন্য নেটওয়ার্কিং সেট আপ করতে হয় এবং এর সাথে জড়িত প্রযুক্তিগুলোর একটি ওভারভিউ প্রদান করে।

5.1 - ইনগ্রেস

একটি API অবজেক্ট যা একটি ক্লাস্টারে সার্ভিসগুলিতে এক্সটার্নাল অ্যাক্সেস পরিচালনা করে, সাধারণত HTTP৷

Ingress লোড ব্যালেন্সিং, SSL টারমিনেশন এবং নাম-ভিত্তিক ভার্চুয়াল হোস্টিং প্রদান করতে পারে।

টার্মিনোলোজি

স্পষ্টতার জন্য, এই গাইড নিম্নলিখিত টার্মগুলি সংজ্ঞায়িত করে:

• নোড: কুবারনেটিস-এ একটি ওয়ার্কার মেশিন, যা একটি ক্লাস্টারের অংশ।
• ক্লাস্টার: একটি সেট নোড যা কুবারনেটিস দ্বারা পরিচালিত কন্টেইনারাইজড অ্যাপ্লিকেশন চালায়। এই উদাহরণের জন্য, এবং বেশিরভাগ সাধারণ কুবারনেটিস ডিপ্লয়মেন্টে, ক্লাস্টারের নোডগুলি পাবলিক ইন্টারনেটের অংশ নয়।
• এজ রাউটার: একটি রাউটার যা আপনার ক্লাস্টারের জন্য ফায়ারওয়াল নীতি প্রয়োগ করে। এটি একটি ক্লাউড প্রদানকারী দ্বারা পরিচালিত একটি গেটওয়ে বা হার্ডওয়্যারের একটি শারীরিক অংশ হতে পারে।
• ক্লাস্টার নেটওয়ার্ক: একটি সেট লিঙ্ক, লজিক্যাল বা ফিজিক্যাল, যা কুবারনেটিস নেটওয়ার্কিং মডেল অনুযায়ী একটি ক্লাস্টারের মধ্যে যোগাযোগ সহজতর করে।
• সার্ভিস: একটি কুবারনেটিস Service যা লেবেল সিলেক্টর ব্যবহার করে একটি পড সেট সনাক্ত করে। অন্যথায় উল্লেখ না করা হলে, সার্ভিসগুলি শুধুমাত্র ক্লাস্টার নেটওয়ার্কের মধ্যে রাউটেবল ভার্চুয়াল আইপি ধারণ করে বলে ধরে নেওয়া হয়।

ইনগ্রেস কী?

ইনগ্রেস ক্লাস্টারের বাইরে থেকে HTTP এবং HTTPS রুটগুলি সার্ভিস-এ উন্মুক্ত করে। ট্রাফিক রাউটিং ইনগ্রেস রিসোর্সে সংজ্ঞায়িত নিয়ম দ্বারা নিয়ন্ত্রিত হয়।

এখানে একটি সহজ উদাহরণ দেওয়া হল যেখানে একটি ইনগ্রেস তার সমস্ত ট্রাফিক একটি সার্ভিসে পাঠায়:

একটি ইনগ্রেস সার্ভিসগুলিকে বাহ্যিকভাবে-অ্যাক্সেসযোগ্য URL প্রদান করতে, ট্রাফিক লোড ব্যালেন্স করতে, SSL / TLS শেষ করতে এবং নাম-ভিত্তিক ভার্চুয়াল হোস্টিং অফার করতে কনফিগার করা যেতে পারে। একটি ইনগ্রেস কন্ট্রোলার ইনগ্রেস পূরণ করার জন্য দায়ী, সাধারণত একটি লোড ব্যালেন্সার সহ, যদিও এটি আপনার এজ রাউটার বা অতিরিক্ত ফ্রন্টএন্ডগুলি ট্রাফিক পরিচালনা করতে সহায়তা করার জন্যও কনফিগার করতে পারে।

ইনগ্রেস এলোমেলো পোর্ট বা প্রোটোকল উন্মুক্ত করে না। HTTP এবং HTTPS ছাড়া অন্য সার্ভিসগুলিকে ইন্টারনেটে উন্মুক্ত করা সাধারণত Service.Type=NodePort বা Service.Type=LoadBalancer ব্যবহার করে।

পূর্বশর্ত

আপনার একটি ইনগ্রেস কন্ট্রোলার থাকতে হবে একটি ইনগ্রেস পূরণ করতে। শুধুমাত্র একটি ইনগ্রেস রিসোর্স তৈরি করা কোন প্রভাব ফেলে না।

আপনাকে ingress-nginx এর মতো একটি ইনগ্রেস কন্ট্রোলার স্থাপন করতে হতে পারে। আপনি বেশ কয়েকটি ইনগ্রেস কন্ট্রোলার থেকে বেছে নিতে পারেন।

আদর্শভাবে, সমস্ত ইনগ্রেস কন্ট্রোলারগুলি রেফারেন্স স্পেসিফিকেশন অনুসারে ফিট করা উচিত। বাস্তবে, বিভিন্ন ইনগ্রেস কন্ট্রোলারগুলি সামান্য ভিন্নভাবে কাজ করে।

ইনগ্রেস রিসোর্স

একটি ন্যূনতম ইনগ্রেস রিসোর্স উদাহরণ:

service/networking/minimal-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx-example
  rules:
  - http:
      paths:
      - path: /testpath
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              number: 80

একটি ইনগ্রেস এর apiVersion, kind, metadata এবং spec ক্ষেত্র প্রয়োজন। একটি ইনগ্রেস অবজেক্টের নাম একটি বৈধ DNS সাবডোমেন নাম হতে হবে। কনফিগ ফাইলগুলির সাথে কাজ করার বিষয়ে সাধারণ তথ্যের জন্য, অ্যাপ্লিকেশন স্থাপন, কনফিগারিং কন্টেইনার, রিসোর্স পরিচালনা দেখুন। ইনগ্রেস প্রায়ই ইনগ্রেস কন্ট্রোলারের উপর নির্ভর করে কিছু বিকল্প কনফিগার করতে অ্যানোটেশন ব্যবহার করে, যার একটি উদাহরণ হল rewrite-target অ্যানোটেশন। বিভিন্ন ইনগ্রেস কন্ট্রোলার বিভিন্ন অ্যানোটেশন সমর্থন করে। সমর্থিত কোন অ্যানোটেশনগুলি শিখতে আপনার পছন্দের ইনগ্রেস কন্ট্রোলারের ডকুমেন্টেশন পর্যালোচনা করুন।

ইনগ্রেস স্পেস এ লোড ব্যালেন্সার বা প্রক্সি সার্ভার কনফিগার করার জন্য প্রয়োজনীয় সমস্ত তথ্য রয়েছে। সবচেয়ে গুরুত্বপূর্ণভাবে, এটি সমস্ত আসন্ন অনুরোধের বিরুদ্ধে মেলানো নিয়মগুলির একটি তালিকা ধারণ করে। ইনগ্রেস রিসোর্স শুধুমাত্র HTTP(S) ট্রাফিক পরিচালনার জন্য নিয়ম সমর্থন করে।

যদি ingressClassName বাদ দেওয়া হয়, একটি ডিফল্ট ইনগ্রেস ক্লাস সংজ্ঞায়িত করা উচিত।

কিছু ইনগ্রেস কন্ট্রোলার আছে, যা একটি ডিফল্ট IngressClass সংজ্ঞা ছাড়াই কাজ করে। উদাহরণস্বরূপ, ইনগ্রেস-NGINX কন্ট্রোলারটি একটি ফ্ল্যাগ --watch-ingress-without-class দিয়ে কনফিগার করা যেতে পারে। এটি প্রস্তাবিত যদিও, ডিফল্ট IngressClass নির্দিষ্ট করতে যেমন নীচে দেখানো হয়েছে।

ইনগ্রেস নিয়ম

প্রতিটি HTTP নিয়মে নিম্নলিখিত তথ্য রয়েছে:

• একটি অপশনাল হোস্ট। এই উদাহরণে, কোন হোস্ট নির্দিষ্ট করা হয়নি, তাই নিয়মটি নির্দিষ্ট করা IP ঠিকানার মাধ্যমে সমস্ত ইনবাউন্ড HTTP ট্রাফিকের জন্য প্রযোজ্য। যদি একটি হোস্ট প্রদান করা হয় (উদাহরণস্বরূপ, foo.bar.com), নিয়মগুলি সেই হোস্টের জন্য প্রযোজ্য।
• একটি পাথের তালিকা (উদাহরণস্বরূপ, /testpath), যার প্রতিটিতে একটি service.name এবং একটি service.port.name বা service.port.number সহ একটি সম্পর্কিত ব্যাকএন্ড সংজ্ঞায়িত করা হয়েছে। হোস্ট এবং পাথ উভয়ই একটি আসন্ন অনুরোধের বিষয়বস্তু মেলাতে হবে এর আগে লোড ব্যালেন্সার ট্রাফিককে উল্লেখিত সার্ভিসে নির্দেশ করে।
• একটি ব্যাকএন্ড হল সার্ভিস ডক বা একটি কাস্টম রিসোর্স ব্যাকএন্ড দ্বারা বর্ণিত সার্ভিস এবং পোর্ট নামগুলির একটি সংমিশ্রণ CRD এর মাধ্যমে। ইনগ্রেস-এ হোস্ট এবং পাথের নিয়ম মেলে এমন HTTP (এবং HTTPS) অনুরোধগুলি তালিকাভুক্ত ব্যাকএন্ডে পাঠানো হয়।

একটি defaultBackend প্রায়শই একটি ইনগ্রেস কন্ট্রোলারে কনফিগার করা হয় যাতে কোনও অনুরোধের জন্য সার্ভিস দেওয়া হয় যা স্পেসে কোনও পাথের সাথে মেলে না।

DefaultBackend

কোন নিয়ম ছাড়াই একটি ইনগ্রেস সমস্ত ট্রাফিককে একটি একক ডিফল্ট ব্যাকএন্ডে পাঠায় এবং .spec.defaultBackend হল ব্যাকএন্ড যা সেই ক্ষেত্রে অনুরোধগুলি পরিচালনা করা উচিত। defaultBackend প্রচলিতভাবে একটি ইনগ্রেস কন্ট্রোলার এর একটি কনফিগারেশন বিকল্প এবং আপনার ইনগ্রেস রিসোর্সগুলিতে নির্দিষ্ট করা হয় না। যদি কোনও .spec.rules নির্দিষ্ট না করা হয়, তবে .spec.defaultBackend নির্দিষ্ট করা আবশ্যক। যদি defaultBackend সেট না করা হয়, তাহলে কোনও নিয়মের সাথে মেলে না এমন অনুরোধগুলির পরিচালনা ইনগ্রেস কন্ট্রোলারের উপর নির্ভর করবে (এই ক্ষেত্রে এটি কীভাবে পরিচালনা করে তা জানতে আপনার ইনগ্রেস কন্ট্রোলারের ডকুমেন্টেশন পরামর্শ করুন)।

যদি কোনও হোস্ট বা পাথ ইনগ্রেস অবজেক্টগুলিতে HTTP অনুরোধের সাথে মেলে না, তাহলে ট্রাফিক আপনার ডিফল্ট ব্যাকএন্ডে রাউট করা হয়।

রিসোর্স ব্যাকএন্ড

একটি Resource ব্যাকএন্ড হল ইনগ্রেস অবজেক্টের মতো একই নেমস্পেসের অন্য কুবারনেটিস রিসোর্সের একটি ObjectRef। একটি Resource সার্ভিসের সাথে পারস্পরিক একচেটিয়া সেটিং এবং উভয় নির্দিষ্ট করা থাকলে বৈধতা ব্যর্থ হবে। একটি Resource ব্যাকএন্ডের একটি সাধারণ ব্যবহার হল স্ট্যাটিক অ্যাসেট সহ একটি অবজেক্ট স্টোরেজ ব্যাকএন্ডে ডেটা ইনগ্রেস করা।

service/networking/ingress-resource-backend.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-resource-backend
spec:
  defaultBackend:
    resource:
      apiGroup: k8s.example.com
      kind: StorageBucket
      name: static-assets
  rules:
    - http:
        paths:
          - path: /icons
            pathType: ImplementationSpecific
            backend:
              resource:
                apiGroup: k8s.example.com
                kind: StorageBucket
                name: icon-assets

উপরে ইনগ্রেস তৈরি করার পরে, আপনি নিম্নলিখিত কমান্ড দিয়ে এটি দেখতে পারেন:

kubectl describe ingress ingress-resource-backend

Name:             ingress-resource-backend
Namespace:        default
Address:
Default backend:  APIGroup: k8s.example.com, Kind: StorageBucket, Name: static-assets
Rules:
  Host        Path  Backends
  ----        ----  --------
  *
              /icons   APIGroup: k8s.example.com, Kind: StorageBucket, Name: icon-assets
Annotations:  <none>
Events:       <none>

পাথ টাইপ

ইনগ্রেস-এ প্রতিটি পাথের একটি সংশ্লিষ্ট পাথ টাইপ থাকা প্রয়োজন। যেসব পাথে একটি স্পষ্ট pathType অন্তর্ভুক্ত নেই তারা বৈধতা ব্যর্থ করবে। তিনটি সমর্থিত পাথ টাইপ রয়েছে:

• ImplementationSpecific: এই পাথ টাইপের সাথে, মেলানো IngressClass এর উপর নির্ভর করে। বাস্তবায়নগুলি এটিকে একটি পৃথক pathType হিসাবে বা Prefix বা Exact পাথ টাইপগুলির সাথে অভিন্ন হিসাবে বিবেচনা করতে পারে।

• Exact: URL পাথটি ঠিক এবং কেস সংবেদনশীলতার সাথে মেলে।

• Prefix: / দ্বারা বিভক্ত একটি URL পাথ প্রিফিক্সের উপর ভিত্তি করে মেলে। মেলানো কেস সংবেদনশীল এবং একটি পাথ উপাদান দ্বারা উপাদান ভিত্তিতে করা হয়। একটি পাথ উপাদানটি / বিভাজক দ্বারা বিভক্ত পাথের লেবেলের তালিকাকে বোঝায়। একটি অনুরোধ পাথ p এর উপাদান-ওয়াইজ প্রিফিক্স হলে পাথ p এর জন্য একটি ম্যাচ।

  বিঃদ্রঃ:

  যদি পাথের শেষ উপাদানটি অনুরোধ পাথের শেষ উপাদানের একটি সাবস্ট্রিং হয়, তবে এটি একটি ম্যাচ নয় (উদাহরণস্বরূপ: /foo/bar /foo/bar/baz এর সাথে মেলে, কিন্তু /foo/barbaz এর সাথে মেলে না)।

উদাহরণ

একাধিক ম্যাচ

কিছু ক্ষেত্রে, একটি অনুরোধের সাথে ইনগ্রেস-এর একাধিক পাথ মেলে। সেই ক্ষেত্রে অগ্রাধিকার প্রথমে দীর্ঘতম মেলানো পাথকে দেওয়া হবে। যদি দুটি পাথ এখনও সমানভাবে মেলে, অগ্রাধিকারটি প্রিফিক্স পাথ টাইপের উপর সঠিক পাথ টাইপের পাথগুলিকে দেওয়া হবে।

হোস্টনাম ওয়াইল্ডকার্ড

হোস্টগুলি সুনির্দিষ্ট ম্যাচ (উদাহরণস্বরূপ “foo.bar.com”) বা একটি ওয়াইল্ডকার্ড (উদাহরণস্বরূপ “*.foo.com”) হতে পারে। সুনির্দিষ্ট ম্যাচগুলির জন্য প্রয়োজন যে HTTP host হেডারটি host ক্ষেত্রের সাথে মেলে। ওয়াইল্ডকার্ড ম্যাচগুলির জন্য প্রয়োজন যে HTTP host হেডারটি ওয়াইল্ডকার্ড নিয়মের উপসর্গের সমান।

service/networking/ingress-wildcard-host.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-wildcard-host
spec:
  rules:
  - host: "foo.bar.com"
    http:
      paths:
      - pathType: Prefix
        path: "/bar"
        backend:
          service:
            name: service1
            port:
              number: 80
  - host: "*.foo.com"
    http:
      paths:
      - pathType: Prefix
        path: "/foo"
        backend:
          service:
            name: service2
            port:
              number: 80

ইনগ্রেস ক্লাস

ইনগ্রেস বিভিন্ন কন্ট্রোলার দ্বারা বাস্তবায়িত হতে পারে, প্রায়শই বিভিন্ন কনফিগারেশন সহ। প্রতিটি ইনগ্রেস একটি ক্লাস নির্দিষ্ট করা উচিত, একটি রেফারেন্স IngressClass রিসোর্স যা অতিরিক্ত কনফিগারেশন ধারণ করে যার মধ্যে রয়েছে কন্ট্রোলারের নাম যা ক্লাসটি বাস্তবায়িত করা উচিত।

service/networking/external-lb.yaml

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: external-lb
spec:
  controller: example.com/ingress-controller
  parameters:
    apiGroup: k8s.example.com
    kind: IngressParameters
    name: external-lb

IngressClass এর .spec.parameters ক্ষেত্রটি আপনাকে একটি রিসোর্স উল্লেখ করতে দেয় যা সেই IngressClass এর সাথে সম্পর্কিত কনফিগারেশন প্রদান করে।

ব্যবহার করার জন্য নির্দিষ্ট ধরণের প্যারামিটারগুলি আপনি IngressClass এর .spec.controller ক্ষেত্রে যে ইনগ্রেস কন্ট্রোলারটি নির্দিষ্ট করেছেন তার উপর নির্ভর করে।

IngressClass স্কোপ

আপনার ইনগ্রেস কন্ট্রোলারের উপর নির্ভর করে, আপনি প্যারামিটারগুলি ব্যবহার করতে সক্ষম হতে পারেন যা আপনি ক্লাস্টার-ওয়াইড বা শুধুমাত্র একটি নেমস্পেসের জন্য সেট করেন।

• Cluster
• Namespaced

---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: external-lb-1
spec:
  controller: example.com/ingress-controller
  parameters:
    # এই IngressClass এর প্যারামিটারগুলি একটি
    # ClusterIngressParameter (API group k8s.example.net) এ নির্দিষ্ট করা হয়েছে
    # "external-config-1" নামক। এই সংজ্ঞাটি কুবারনেটিস কে বলে
    # একটি ক্লাস্টার-স্কোপড প্যারামিটার রিসোর্সের জন্য সন্ধান করুন।
    scope: Cluster
    apiGroup: k8s.example.net
    kind: ClusterIngressParameter
    name: external-config-1

---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: external-lb-2
spec:
  controller: example.com/ingress-controller
  parameters:
    # এই IngressClass এর প্যারামিটারগুলি একটি
    # IngressParameter (API group k8s.example.com) এ নির্দিষ্ট করা হয়েছে, "external-config" নামক,
    # যা "external-configuration" নেমস্পেসে।
    scope: Namespace
    apiGroup: k8s.example.com
    kind: IngressParameter
    namespace: external-configuration
    name: external-config

অপ্রচলিত অ্যানোটেশন

IngressClass রিসোর্স এবং ingressClassName ক্ষেত্রটি কুবারনেটিস 1.18 এ যোগ করার আগে, ইনগ্রেস ক্লাসগুলি একটি ইনগ্রেস-এ kubernetes.io/ingress.class অ্যানোটেশন। এই অ্যানোটেশনটি কখনই আনুষ্ঠানিকভাবে সংজ্ঞায়িত করা হয়নি, তবে এটি ব্যাপকভাবে সমর্থিত ছিল ইনগ্রেস কন্ট্রোলার দ্বারা।

ইনগ্রেস-এ নতুন ingressClassName ক্ষেত্রটি সেই অ্যানোটেশনের জন্য একটি প্রতিস্থাপন, তবে এটি একটি সরাসরি সমতুল্য নয়। যদিও অ্যানোটেশনটি সাধারণত ইনগ্রেস কন্ট্রোলারের নাম উল্লেখ করতে ব্যবহৃত হত যা ইনগ্রেস বাস্তবায়ন করা উচিত, ক্ষেত্রটি একটি IngressClass রিসোর্সের একটি রেফারেন্স যা অতিরিক্ত ইনগ্রেস কনফিগারেশন ধারণ করে, যার মধ্যে রয়েছে ইনগ্রেস কন্ট্রোলারের নাম।

ডিফল্ট IngressClass

আপনি আপনার ক্লাস্টারের জন্য একটি নির্দিষ্ট IngressClass ডিফল্ট হিসাবে চিহ্নিত করতে পারেন। একটি IngressClass রিসোর্সে ingressclass.kubernetes.io/is-default-class অ্যানোটেশন true এ সেট করা নিশ্চিত করবে যে নতুন ইনগ্রেস-গুলি যেগুলিতে একটি ingressClassName ক্ষেত্র নির্দিষ্ট করা নেই সেগুলি এই ডিফল্ট IngressClass বরাদ্দ করা হবে।

কিছু ইনগ্রেস কন্ট্রোলার আছে, যা একটি ডিফল্ট IngressClass সংজ্ঞা ছাড়াই কাজ করে। উদাহরণস্বরূপ, ইনগ্রেস-NGINX কন্ট্রোলারটি একটি ফ্ল্যাগ --watch-ingress-without-class দিয়ে কনফিগার করা যেতে পারে। এটি প্রস্তাবিত যদিও, ডিফল্ট IngressClass নির্দিষ্ট করতে:

service/networking/default-ingressclass.yaml

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  labels:
    app.kubernetes.io/component: controller
  name: nginx-example
  annotations:
    ingressclass.kubernetes.io/is-default-class: "true"
spec:
  controller: k8s.io/ingress-nginx

ইনগ্রেস এর ধরন

একটি একক সার্ভিস দ্বারা সমর্থিত ইনগ্রেস

একটি একক সার্ভিস উন্মুক্ত করার জন্য বিদ্যমান কুবারনেটিস ধারণা রয়েছে (দেখুন বিকল্প)। আপনি একটি ইনগ্রেস সহ একটি ডিফল্ট ব্যাকএন্ড নির্দিষ্ট করে এটি করতে পারেন কোন নিয়ম ছাড়াই।

service/networking/test-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
spec:
  defaultBackend:
    service:
      name: test
      port:
        number: 80

যদি আপনি এটি kubectl apply -f ব্যবহার করে তৈরি করেন তবে আপনি যুক্ত করা ইনগ্রেস এর অবস্থা দেখতে সক্ষম হবেন:

kubectl get ingress test-ingress

NAME           CLASS         HOSTS   ADDRESS         PORTS   AGE
test-ingress   external-lb   *       203.0.113.123   80      59s

যেখানে 203.0.113.123 হল ইনগ্রেস কন্ট্রোলার দ্বারা বরাদ্দ করা IP এই ইনগ্রেস পূরণ করতে।

সহজ ফ্যানআউট

একটি ফ্যানআউট কনফিগারেশন একটি একক IP ঠিকানা থেকে একাধিক সার্ভিসে ট্রাফিক রুট করে, অনুরোধ করা HTTP URI এর উপর ভিত্তি করে। একটি ইনগ্রেস আপনাকে লোড ব্যালেন্সারের সংখ্যা কমিয়ে রাখতে দেয় একটি ন্যূনতম। উদাহরণস্বরূপ, একটি সেটআপের মতো:

এটি একটি ইনগ্রেস প্রয়োজন যেমন:

service/networking/simple-fanout-example.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: simple-fanout-example
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        pathType: Prefix
        backend:
          service:
            name: service1
            port:
              number: 4200
      - path: /bar
        pathType: Prefix
        backend:
          service:
            name: service2
            port:
              number: 8080

যখন আপনি kubectl apply -f দিয়ে ইনগ্রেস তৈরি করেন:

kubectl describe ingress simple-fanout-example

Name:             simple-fanout-example
Namespace:        default
Address:          178.91.123.132
Default backend:  default-http-backend:80 (10.8.2.3:8080)
Rules:
  Host         Path  Backends
  ----         ----  --------
  foo.bar.com
               /foo   service1:4200 (10.8.0.90:4200)
               /bar   service2:8080 (10.8.0.91:8080)
Events:
  Type     Reason  Age                From                     Message
  ----     ------  ----               ----                     -------
  Normal   ADD     22s                loadbalancer-controller  default/test

ইনগ্রেস কন্ট্রোলার একটি বাস্তবায়ন-নির্দিষ্ট লোড ব্যালেন্সার সরবরাহ করে যা ইনগ্রেস পূরণ করে, যতক্ষণ না সার্ভিসগুলি (service1, service2) বিদ্যমান থাকে। যখন এটি করেছে, আপনি লোড ব্যালেন্সারের ঠিকানা দেখতে পারেন ঠিকানা ক্ষেত্র।

নেম বেসড ভার্চুয়াল হোস্টিং

নাম-ভিত্তিক ভার্চুয়াল হোস্টগুলি একই IP ঠিকানায় একাধিক হোস্ট নামের জন্য HTTP ট্রাফিক রাউটিং সমর্থন করে।

নিম্নলিখিত ইনগ্রেস ব্যাকিং লোড ব্যালেন্সারকে Host হেডার এর উপর ভিত্তি করে অনুরোধগুলি রাউট করতে বলে।

service/networking/name-virtual-host-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: name-virtual-host-ingress
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service1
            port:
              number: 80
  - host: bar.foo.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service2
            port:
              number: 80

যদি আপনি কোনও হোস্ট সংজ্ঞায়িত না করে একটি ইনগ্রেস রিসোর্স তৈরি করেন তবে নিয়মগুলি, তাহলে আপনার ইনগ্রেস কন্ট্রোলারের IP ঠিকানায় যেকোনো ওয়েব ট্রাফিক একটি নাম ভিত্তিক ভার্চুয়াল হোস্ট প্রয়োজন ছাড়াই মেলানো যেতে পারে।

উদাহরণস্বরূপ, নিম্নলিখিত ইনগ্রেস রুট ট্রাফিক first.bar.com এর জন্য অনুরোধ করা service1 এ, second.bar.com এ service2 এ, এবং যেকোনো ট্রাফিক যার অনুরোধ হোস্ট হেডার first.bar.com এর সাথে মেলে না এবং second.bar.com service3 এ।

service/networking/name-virtual-host-ingress-no-third-host.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: name-virtual-host-ingress-no-third-host
spec:
  rules:
  - host: first.bar.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service1
            port:
              number: 80
  - host: second.bar.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service2
            port:
              number: 80
  - http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service3
            port:
              number: 80

TLS

আপনি একটি সিক্রেট নির্দিষ্ট করে একটি ইনগ্রেস সুরক্ষিত করতে পারেন যা একটি TLS ব্যক্তিগত কী এবং শংসাপত্র ধারণ করে। ইনগ্রেস রিসোর্স শুধুমাত্র একটি একক TLS পোর্ট, 443 সমর্থন করে এবং ইনগ্রেস পয়েন্টে TLS সমাপ্তি ধরে নেয় (সার্ভিস এবং এর পডগুলিতে ট্র্যাফিক প্লেইনটেক্সটে থাকে)। যদি একটি ইনগ্রেস-এ TLS কনফিগারেশন বিভাগে বিভিন্ন হোস্ট নির্দিষ্ট করা থাকে, তবে সেগুলি SNI TLS এক্সটেনশনের মাধ্যমে নির্দিষ্ট হোস্টনাম অনুসারে একই পোর্টে মাল্টিপ্লেক্স করা হয় (ইনগ্রেস কন্ট্রোলার SNI সমর্থন করে)। TLS সিক্রেটে tls.crt এবং tls.key নামে কী থাকতে হবে যা TLS এর জন্য ব্যবহার করার শংসাপত্র এবং ব্যক্তিগত কী ধারণ করে। উদাহরণস্বরূপ:

apiVersion: v1
kind: Secret
metadata:
  name: testsecret-tls
  namespace: default
data:
  tls.crt: base64 encoded cert  
  tls.key: base64 encoded key
type: kubernetes.io/tls

একটি ইনগ্রেস-এ এই সিক্রেটটি উল্লেখ করা ইনগ্রেস কন্ট্রোলারকে TLS ব্যবহার করে ক্লায়েন্ট থেকে লোড ব্যালেন্সারে চ্যানেলটি সুরক্ষিত করতে বলে। আপনাকে নিশ্চিত করতে হবে আপনি যে TLS সিক্রেটটি তৈরি করেছেন তা একটি শংসাপত্র থেকে এসেছে যাতে একটি সাধারণ নাম (CN), এছাড়াও https-example.foo.com এর জন্য একটি সম্পূর্ণ যোগ্য ডোমেন নাম (FQDN) হিসাবে পরিচিত।

service/networking/tls-example-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tls-example-ingress
spec:
  tls:
  - hosts:
      - https-example.foo.com
    secretName: testsecret-tls
  rules:
  - host: https-example.foo.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: service1
            port:
              number: 80

লোড ব্যালেন্সিং

একটি ইনগ্রেস কন্ট্রোলার কিছু লোড ব্যালেন্সিং নীতি সেটিংস সহ বুটস্ট্র্যাপ করা হয় যা এটি সমস্ত ইনগ্রেস-এ প্রয়োগ করে, যেমন লোড ব্যালেন্সিং অ্যালগরিদম, ব্যাকএন্ড ওজন স্কিম, এবং অন্যান্য। আরো উন্নত লোড ব্যালেন্সিং ধারণা (যেমন স্থায়ী সেশন, গতিশীল ওজন) এখনও ইনগ্রেস এর মাধ্যমে প্রকাশ করা হয়নি। আপনি পরিবর্তে সার্ভিসের জন্য ব্যবহৃত লোড ব্যালেন্সারের মাধ্যমে এই ফিচারগুলি পেতে পারেন।

এটি উল্লেখ করার মতো যে স্বাস্থ্য পরীক্ষা সরাসরি প্রকাশ করা হয় না ইনগ্রেস এর মাধ্যমে, কুবারনেটিস-এ সমান্তরাল ধারণা যেমন readiness probes যা আপনাকে একই শেষ ফলাফল অর্জন করতে দেয়। অনুগ্রহ করে কন্ট্রোলার পর্যালোচনা করুন নির্দিষ্ট ডকুমেন্টেশন দেখতে তারা স্বাস্থ্য পরীক্ষা কিভাবে পরিচালনা করে (উদাহরণস্বরূপ: nginx, বা GCE)।

একটি ইনগ্রেস আপডেট করা

একটি নতুন হোস্ট যোগ করতে একটি বিদ্যমান ইনগ্রেস আপডেট করতে, আপনি এটি সম্পাদনা করে আপডেট করতে পারেন:

kubectl describe ingress test

Name:             test
Namespace:        default
Address:          178.91.123.132
Default backend:  default-http-backend:80 (10.8.2.3:8080)
Rules:
  Host         Path  Backends
  ----         ----  --------
  foo.bar.com
               /foo   service1:80 (10.8.0.90:80)
Annotations:
  nginx.ingress.kubernetes.io/rewrite-target:  /
Events:
  Type     Reason  Age                From                     Message
  ----     ------  ----               ----                     -------
  Normal   ADD     35s                loadbalancer-controller  default/test

kubectl edit ingress test

এটি YAML ফরম্যাটে বিদ্যমান কনফিগারেশন সহ একটি সম্পাদক পপ আপ করে। নতুন হোস্ট অন্তর্ভুক্ত করতে এটি পরিবর্তন করুন:

spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - backend:
          service:
            name: service1
            port:
              number: 80
        path: /foo
        pathType: Prefix
  - host: bar.baz.com
    http:
      paths:
      - backend:
          service:
            name: service2
            port:
              number: 80
        path: /foo
        pathType: Prefix
..

আপনার পরিবর্তনগুলি সংরক্ষণ করার পরে, kubectl API সার্ভারে রিসোর্সটি আপডেট করে, যা বলে ইনগ্রেস কন্ট্রোলার লোড ব্যালেন্সার পুনরায় কনফিগার করতে।

এটি যাচাই করুন:

kubectl describe ingress test

Name:             test
Namespace:        default
Address:          178.91.123.132
Default backend:  default-http-backend:80 (10.8.2.3:8080)
Rules:
  Host         Path  Backends
  ----         ----  --------
  foo.bar.com
               /foo   service1:80 (10.8.0.90:80)
  bar.baz.com
               /foo   service2:80 (10.8.0.91:80)
Annotations:
  nginx.ingress.kubernetes.io/rewrite-target:  /
Events:
  Type     Reason  Age                From                     Message
  ----     ------  ----               ----                     -------
  Normal   ADD     45s                loadbalancer-controller  default/test

আপনি একটি পরিবর্তিত ইনগ্রেস YAML ফাইলে kubectl replace -f আহ্বান করে একই ফলাফল অর্জন করতে পারেন।

প্রাপ্যতা জোন জুড়ে ব্যর্থ হচ্ছে

ব্যর্থতার ডোমেনগুলির মধ্যে ট্র্যাফিক ছড়িয়ে দেওয়ার কৌশলগুলি ক্লাউড প্রদানকারীদের মধ্যে আলাদা। বিস্তারিত জানার জন্য প্রাসঙ্গিক ইনগ্রেস কন্ট্রোলার এর ডকুমেন্টেশন চেক করুন।

বিকল্প

আপনি একটি সার্ভিসকে একাধিক উপায়ে উন্মুক্ত করতে পারেন যা সরাসরি ইনগ্রেস রিসোর্সের সাথে জড়িত নয়:

• Service.Type=LoadBalancer ব্যবহার করুন
• Service.Type=NodePort ব্যবহার করুন

এর পরের কি

• ইনগ্রেস API সম্পর্কে জানুন
• ইনগ্রেস কন্ট্রোলার সম্পর্কে জানুন
• NGINX কন্ট্রোলার সহ Minikube-এ ইনগ্রেস সেট আপ করুন

6 - স্টোরেজ

7 - কনফিগারেশন

8 - নিরাপত্তা

এই কুবারনেটিস ডকুমেন্টেশনের এই অংশের উদ্দেশ্য আপনাকে ক্লাউড-নেটিভ প্রযুক্তিতে নিরাপত্তামুলকভাবে ওয়ার্কলোডগুলি পরিচালনা শেখানোর সাহায্য করা এবং একটি কুবারনেটিসের ক্লাস্টার নিরাপত্তামুলকভাবে রাখার গুরুত্বপূর্ণ দিক সম্পর্কে জানানো।

কুবারনেটিস ক্লাউড-নেটিভ স্থাপত্যের উপর ভিত্তি করে এবং ক্লাউড-নেটিভ তথ্য নিরাপত্তা সম্পর্কে ভাল অনুশীলনের জন্য CNCF থেকে পরামর্শ প্রদান করে।

আপনার ক্লাস্টার এবং অ্যাপ্লিকেশনগুলিকে কীভাবে সুরক্ষিত করবেন সে সম্পর্কে বিস্তৃত প্রেক্ষাপটের জন্য ক্লাউড নেটিভ নিরাপত্তা এবং কুবারনেটিস পড়ুন।

কুবারনেটিসের নিরাপত্তা ব্যবস্থা

কুবারনেটিসের মধ্যে বেশ কয়েকটি API এবং নিরাপত্তা কন্ট্রোল রয়েছে, সেইসাথে পলিসিগুলি সংজ্ঞায়িত করার উপায় যা আপনি কীভাবে তথ্য সুরক্ষা পরিচালনা করেন তার অংশ গঠন করতে পারে।

কন্ট্রোল প্লেন সুরক্ষা

কোন কুবারনেটিসের ক্লাস্টারের জন্য একটি প্রধান নিরাপত্তা ব্যবস্থা হলো কুবারনেটিস API-এ অ্যাক্সেস কন্ট্রোল করা।

কুবারনেটিস আশা করে যে আপনি কন্ট্রোল প্লেনের মধ্যে এবং কন্ট্রোল প্লেন এবং এর ক্লায়েন্টদের মধ্যে ট্রানজিটে ডেটা এনক্রিপশন প্রদান করতে TLS কনফিগার করবেন এবং ব্যবহার করবেন। আপনি কুবারনেটিস কন্ট্রোল প্লেনের মধ্যে সংরক্ষিত ডেটার জন্য এনক্রিপশন এট রেস্ট(encryption at rest) সক্ষম করতে পারেন; এটি আপনার নিজের ওয়ার্কলোডের ডেটার জন্য এনক্রিপশন এট রেস্ট ব্যবহার করা থেকে আলাদা, যা একটি ভাল আইডিয়াও হতে পারে

সিক্রেট

সিক্রেট API কনফিগারেশন ভ্যালুগুলির জন্য মৌলিক সুরক্ষা প্রদান করে যার জন্য গোপনীয়তা প্রয়োজন ।

ওয়ার্কলোড সুরক্ষা

পড এবং তাদের কন্টেনারগুলি যথাযথভাবে আইসোলেট নিশ্চিত করতে পড নিরাপত্তা স্ট্যান্ডার্ডস আপনার প্রয়োজন হলে কাস্টম আইসোলেশন নির্ধারণ করার জন্য আপনি RuntimeClasses ব্যবহার করতে পারেন।

নেটওয়ার্ক পলিসি আপনাকে পডগুলির মধ্যে, অথবা আপনার ক্লাস্টারের বাইরের নেটওয়ার্ক মধ্যে নেটওয়ার্ক ট্রাফিক নিয়ন্ত্রণ করতে দেয়।

আপনি পড, তাদের কন্টেনারগুলি এবং তাদের মধ্যে চলা ইমেজগুলির চারপাশে প্রতিরোধমূলক বা ডিটেক্টিভ কন্ট্রোলগুলি প্রয়োগ করতে বিস্তৃত ইকোসিস্টেম থেকে সিকিউরিটি কন্ট্রোল স্থাপন করতে পারেন ।

অডিটিং

কুবারনেটিস অডিটিং লগিং একটি নিরাপত্তা-সংশ্লিষ্ট, সময়ানুক্রমিক সেট অফ রেকর্ড সরবরাহ করে যা ক্লাস্টারের ক্রিয়াকলাপের অনুক্রমিক ডকুমেন্ট করে। ক্লাস্টার ব্যবহারকারীদের দ্বারা উত্পন্ন ক্রিয়াকলাপ, কুবার্নিটিস API ব্যবহার করা অ্যাপ্লিকেশন এবং নিয়ন্ত্রণ প্লেন নিজস্ব ক্রিয়াকলাপগুলি অডিট করে।

ক্লাউড প্রোভাইডার নিরাপত্তা

আপনি যদি আপনার নিজের হার্ডওয়্যার বা অন্য কোনো ক্লাউড প্রোভাইডার এ একটি কুবারনেটিস ক্লাস্টার চালান, তাহলে নিরাপত্তার সর্বোত্তম অনুশীলনের জন্য আপনার ডকুমেন্টেশনের সাথে পরামর্শ করুন। এখানে কিছু জনপ্রিয় ক্লাউড প্রোভাইডার এর নিরাপত্তা ডকুমেন্টেশনের লিঙ্ক রয়েছে :

পলিসি

আপনি কুবারনেটিস-নেটিভ মেকানিজম ব্যবহার করে নিরাপত্তা পলিসি নির্ধারণ করতে পারেন, যেমন NetworkPolicy (নেটওয়ার্ক প্যাকেট ফিল্টারিং উপর ঘোষণামূলক কন্ট্রোল) বা ValidatingAdmissionPolicy (কুবারনেটিস API ব্যবহার করে কেউ কী পরিবর্তন করতে পারে তার ঘোষণামূলক সীমাবদ্ধতা)।

তবে, আপনি কুবারনেটিস পরিবেশের চারপাশে পলিসি কার্যান্বয়নে নির্ভর করতে পারেন। কুবারনেটিস এক্সটেনশন মেকানিজম সরবরাহ করে এই পরিবেশ প্রকল্পগুলির উপর তাদের নিজস্ব পলিসি নিয়ন্ত্রণ সাধারণের জন্য উন্মোচনের সুযোগ প্রদান করতে। এগুলি উদাহরণ হিসেবে উল্লেখ করা যেতে পারে: সোর্স কোড পর্যালোচনা, কন্টেনার ইমেজ অনুমোদন, এপিআই অ্যাক্সেস নিয়ন্ত্রণ, নেটওয়ার্কিং, এবং অন্যান্য।

পলিসি মেকানিজম এবং কুবারনেটিসের সম্পর্কে আরও তথ্য জানতে, পলিসি পড়ুন।

এর পরের কি

সম্পর্কিত কুবারনেটিস নিরাপত্তা বিষয়গুলি জানুন:

• আপনার ক্লাস্টার নিরাপত্তা সুরক্ষা করা
• পরিচিত দুর্বলতা কুবারনেটিসে (এবং আরও তথ্যের লিঙ্ক)
• ট্রানজিটে ডেটা এনক্রিপশন কন্ট্রোল প্লেনের জন্য
• ডেটা এনক্রিপশন এট রেস্ট
• কুবারনেটিস API অ্যাক্সেস নিয়ন্ত্রণ
• নেটওয়ার্ক পলিসি পড এর জন্য
• কুবারনেটিসে সিক্রেট
• পডগুলির নিরাপত্তা স্ট্যান্ডার্ডস
• RuntimeClasses

প্রসঙ্গ জানুন:

• ক্লাউড নেটিভ নিরাপত্তা এবং কুবারনেটিস পড়ুন।

সার্টিফাইড:

• সার্টিফাইড কুবারনেটিস নিরাপত্তা বিশেষজ্ঞ সার্টিফিকেশন এবং অফিসিয়াল প্রশিক্ষণ কোর্স।

এই অধ্যায়ে আরো পড়ুন:

9 - নীতিমালা

কুবারনেটিস নীতিগুলি এমন কনফিগারেশন যা অন্যান্য কনফিগারেশন বা রানটাইম আচরণগুলি পরিচালনা করে। কুবারনেটিস বিভিন্ন ধরণের নীতি সরবরাহ করে নীচে তা বর্ণিত হলো:

এপিআই (API) অবজেক্ট ব্যবহার করে পলিসি প্রয়োগ করুন

কিছু API অবজেক্ট নীতি হিসাবে কাজ করে। এখানে কিছু উদাহরণ দেওয়া হল:

• নেটওয়ার্ক নীতি একটি কাজের চাপের জন্য প্রবেশ এবং প্রস্থানে ট্র্যাফিক সীমাবদ্ধ করতে ব্যবহার করা যেতে পারে।
• লিমিট রেঞ্জ বিভিন্ন বস্তুর ধরণের জুড়ে রিসোর্স বরাদ্দের সীমাবদ্ধতা পরিচালনা করে।
• রিসোর্স কোটা একটি জন্য সম্পদ খরচ সীমাবদ্ধ করুন নেমস্পেস

ভর্তি নিয়ন্ত্রক ব্যবহার করে নীতিমালা প্রয়োগ করুন

একটি ভর্তি নিয়ন্ত্রক API সার্ভারে চলে এবং API অনুরোধগুলিকে যাচাই বা পরিবর্তন করতে পারে। কিছু ভর্তি নিয়ন্ত্রক নীতি প্রয়োগ করার জন্য কাজ করে। উদাহরণস্বরূপ, অলওয়েজইমেজপুল অ্যাডমিশন কন্ট্রোলার ইমেজ পুল পলিসি অলওয়েজ এ সেট করতে একটি নতুন পড সংশোধন করে।

কুবারনেটিস বেশ কয়েকটি অন্তর্নির্মিত ভর্তি নিয়ামক রয়েছে যা API সার্ভারের মাধ্যমে কনফিগারযোগ্য --enable-admission-plugin ফ্লাগ।

ভর্তি নিয়ন্ত্রকদের বিবরণ, উপলব্ধ ভর্তি নিয়ন্ত্রকদের সম্পূর্ণ তালিকা সহ, একটি ডেডিকেটেড অংশে নথিভুক্ত ( ডকুমেন্ট) করা হয়েছে।

• ভর্তি নিয়ন্ত্রকরা

ভ্যালিডেটিংএডমিশনপলিসি ব্যবহার করে নীতিগুলি প্রয়োগ করুন

ভর্তি নীতিগুলি যাচাই করা কমন এক্সপ্রেশন ল্যাঙ্গুয়েজ (সিইএল) ব্যবহার করে API সার্ভারে কনফিগারযোগ্য বৈধতা চেকগুলি কার্যকর করার অনুমতি দেয়। উদাহরণস্বরূপ, সর্বশেষ চিত্র ট্যাগের ব্যবহার নিষিদ্ধ করতে একটি ভ্যালিডেটিংঅ্যাডমিশনপলিসি ব্যবহার করা যেতে পারে।

একটি ভ্যালিডেটিঅ্যাডমিশনপলিসি একটি API অনুরোধের ভিত্তিতে কাজ করে এবং ব্যবহারকারীদের অ-সম্মতিযুক্ত কনফিগারেশন সম্পর্কে ব্লক, নিরীক্ষণ (হিসাবনিকাশ) এবং সতর্ক করতে ব্যবহার করা যেতে পারে।

উদাহরণ সহ ভ্যালিডেটিংএডমিশনপলিসি API সম্পর্কে বিশদ বিবরণ একটি ডেডিকেটেড অংশে নথিভুক্ত (ডকুমেন্ট) করা হয়েছে:

• ভ্যালিডেটিং এডমিশন পলিসি

ডাইনামিক ভর্তি নিয়ন্ত্রণ ব্যবহার করে নীতিমালা প্রয়োগ করুন

ডায়নামিক অ্যাডমিশন কন্ট্রোলার (বা অ্যাডমিশন ওয়েবহুক) এপিআই সার্ভারের বাইরে পৃথক অ্যাপ্লিকেশন হিসাবে চালিত হয় যা এপিআই অনুরোধগুলির বৈধতা বা মিউটেশন সম্পাদনের জন্য ওয়েবহুক অনুরোধগুলি গ্রহণ করতে নিবন্ধন করে।

ডায়নামিক অ্যাডমিশন কন্ট্রোলারগুলি এপিআই অনুরোধগুলিতে নীতি প্রয়োগ করতে এবং অন্যান্য নীতি-ভিত্তিক কর্মপ্রবাহকে ট্রিগার করতে ব্যবহার করা যেতে পারে। একটি ডায়নামিক ভর্তি কন্ট্রোলার অন্যান্য ক্লাস্টার সংস্থান এবং বহিরাগত ডেটা পুনরুদ্ধারের প্রয়োজন সহ জটিল চেকগুলি সম্পাদন করতে পারে। উদাহরণস্বরূপ, একটি ইমেজ যাচাইকরণ কন্টেইনার চিত্রের স্বাক্ষর এবং প্রত্যয়নগুলি যাচাই করতে ওসিআই (OCI) রেজিস্ট্রি থেকে ডেটা খুঁজতে পারে।

ডায়নামিক ভর্তি নিয়ন্ত্রণের বিশদ বিবরণ একটি নিয়োজিত (ডেডিকেটেড) অংশে নথিভুক্ত ( ডকুমেন্ট) করা হয়েছে:

• ডাইনামিক ভর্তি নিয়ন্ত্রণ

বাস্তবায়ন

নমনীয় নীতি ইঞ্জিন হিসাবে কাজ করে এমন ডায়নামিক অ্যাডমিশন কন্ট্রোলারগুলি কুবারনেটিস ইকোসিস্টেমে উন্নত(ডেভলাপ) করা হচ্ছে, যেমন:

• Kubewarden
• Kyverno
• OPA Gatekeeper
• Polaris

Kubelet কনফিগারেশন ব্যবহার করে নীতি প্রয়োগ করুন

কুবারনেটিস প্রতিটি ওর্য়াকার নোডে Kubelet কনফিগার করার অনুমতি দেয়। কিছু Kubelet কনফিগারেশন নীতি হিসাবে কাজ করে:

• প্রক্রিয়া আইডি সীমা এবং সংরক্ষণ বরাদ্দযোগ্য পিআইডি সীমাবদ্ধ এবং সংরক্ষণ করতে ব্যবহৃত হয়।
• নোড রিসোর্স ম্যানেজার বিলম্ব-সমালোচনামূলক এবং উচ্চ-থ্রুপুট ওয়ার্কলোডের জন্য গণনা, মেমরি এবং ডিভাইস সংস্থানগুলি পরিচালনা করতে পারে।

10 - শিডিউলিং, প্রিএম্পশন এবং ইভিকশন (Scheduling, Preemption and Eviction)

কুবারনেটিসে, শিডিউলিং মানে হল নিশ্চিত করা যে পডগুলি নোডগুলির সাথে মিলিত হয়েছে কিনা যাতে kubelet তাদের রান করতে পারে। প্রিএম্পশন হল স্বল্প অগ্রাধিকার পডগুলি বাতিল করার প্রক্রিয়া যাতে উচ্চ অগ্রাধিকার পডগুলি নোডগুলিতে শিডিউল করতে পারে। ইভিকশন হল রিসোর্স-ক্ষুধার্ত নোডগুলিতে এক বা একাধিক পডগুলি প্রত্যাহার করার প্রক্রিয়া।

শিডিউলিং

• কুবারনেটস এর শিডিউলিং
• নোডগুলিতে পডস বরাদ্দ করা
• পডসের অতিরিক্ত ব্যয়
• পডস এর টপোলজি ছড়িয়ে যাওয়ার সীমাবদ্ধতা
• টেইন্টস এবং টলারেশনস
• শিডিউলিং ফ্রেমওয়ার্ক
• ডাইনামিক রিসোর্স বরাদ্দ করা
• শিডিউলার পারফরমেন্স টিউনিং
• সম্প্রসারিত রিসোর্স এর জন্য রিসোর্স বিন প্যাকিং
• পড শিডিউলিং এর সাধনযোগ্যতা
• ডিশেডিউলার

পডস এর ভাঙ্গন

পড-ব্যঘাত হলো সেই প্রক্রিয়া যার
মাধ্যমে নোডের পডগুলো স্বেচ্ছায় বা অনিচ্ছাকৃতভাবে বন্ধ করা হয়।

অ্যাপ্লিকেশন মালিক বা ক্লাস্টার অ্যাডমিনিস্ট্রেটররা ইচ্ছাকৃতভাবে স্বেচ্ছায় ব্যাঘাত শুরু করে। অনিচ্ছাকৃত ব্যাঘাতগুলি অনিচ্ছাকৃত এবং নোডের রিসোর্স ফুরিয়ে যাওয়ার মতো অনিবার্য সমস্যার কারণে বা দুর্ঘটনাবশত মুছে ফেলার কারণে ট্রিগার হতে পারে।

• পড অগ্রাধিকার এবং প্রিম্পশন
• নোড-প্রেসার ইভিকশন
• API-প্রবর্তিত ইভিকশন

10.1 - কুবারনেটিস শিডিউলার

কুবারনেটিসে, শিডিউলিং বলতে পড গুলিকে নোড এর সাথে মিলিয়ে দেওয়া বোঝায়, যেন Kubelet সেগুলি চালাতে পারে।

শিডিউলিং এর সংক্ষিপ্ত বিবরণ

একটি শিডিউলার নতুন তৈরি হওয়া এমন পড গুলিকে নজরে রাখে যাদের কোন নোড বরাদ্দ করা হয়নি। প্রতিটি পডের জন্য যা শিডিউলার আবিষ্কার করে, শিডিউলার সেই পডের জন্য সেরা নোড খুঁজে বের করার দায়িত্ব নেয়। শিডিউলার নিম্নলিখিত শিডিউলিং নীতিগুলি বিবেচনা করে এই স্থান নির্ধারণের সিদ্ধান্তে পৌঁছায়।

আপনি যদি বুঝতে চান কেন পডগুলি একটি নির্দিষ্ট নোডে রাখা হয়েছে, অথবা আপনি যদি নিজে একটি কাস্টম শিডিউলার তৈরি করতে চান, এই পৃষ্ঠাটি আপনাকে শিডিউলিং সম্পর্কে জানতে সাহায্য করবে।

kube-scheduler

kube-scheduler কুবারনেটিসের ডিফল্ট শিডিউলার এবং এটি কন্ট্রোল প্লেন এর অংশ হিসেবে চলে। kube-scheduler এমনভাবে ডিজাইন করা হয়েছে যে, আপনি যদি চান এবং প্রয়োজন হয়, আপনি আপনার নিজস্ব শিডিউলিং কম্পোনেন্ট লিখতে পারেন এবং তার পরিবর্তে সেটি ব্যবহার করতে পারেন।

Kube-scheduler নতুন তৈরি বা এখনও পর্যন্ত শিডিউল না করা (unscheduled) পডগুলি চালানোর জন্য একটি সর্বোত্তম নোড নির্বাচন করে। যেহেতু পডে থাকা কন্টেইনারগুলি - এবং পডগুলি নিজেরাই - বিভিন্ন প্রয়োজনীয়তা থাকতে পারে, শিডিউলার এমন যেকোনো নোড ফিল্টার করে বাদ দেয় যা একটি পডের নির্দিষ্ট শিডিউলিং প্রয়োজনীয়তা পূরণ করে না। বিকল্পভাবে, API আপনাকে পড তৈরি করার সময় একটি নোড নির্দিষ্ট করে দেওয়ার অনুমতি দেয়, তবে এটি অস্বাভাবিক এবং শুধুমাত্র বিশেষ ক্ষেত্রে করা হয়।

একটি ক্লাস্টারে, যে নোডগুলি একটি পডের শিডিউলিং প্রয়োজনীয়তা পূরণ করে তাদেরকে সম্ভাব্য নোড বলা হয়। যদি কোন নোড উপযুক্ত না হয়, পডটি অশিডিউলড থাকে যতক্ষণ না শিডিউলার এটিকে রাখতে সক্ষম হয়।

শিডিউলার একটি পডের জন্য সম্ভাব্য নোডগুলি খুঁজে বের করে এবং তারপর একগুচ্ছ ফাংশন চালায় যা সম্ভাব্য নোডগুলিকে স্কোর করে এবং সম্ভাব্য নোডগুলির মধ্যে সর্বোচ্চ স্কোর সহ একটি নোড বেছে নেয় পডটি চালানোর জন্য। শিডিউলার তারপর এই সিদ্ধান্ত সম্পর্কে API সার্ভারকে অবহিত করে, একটি প্রক্রিয়ায় যাকে বাইন্ডিং বলা হয়।

শিডিউলিং সিদ্ধান্তগুলির জন্য যে বিষয়গুলি বিবেচনায় নিতে হবে তার মধ্যে রয়েছে ব্যক্তিগত এবং সামষ্টিক সম্পদ প্রয়োজনীয়তা, হার্ডওয়্যার / সফটওয়্যার / নীতি সীমাবদ্ধতা, আকর্ষণ এবং বিকর্ষণ স্পেসিফিকেশন, ডাটা লোকালিটি, আন্তঃ-ওয়ার্কলোড হস্তক্ষেপ, ইত্যাদি।

kube-scheduler এ নোড নির্বাচন

kube-scheduler পডের জন্য একটি নোড নির্বাচন করে ২-ধাপের অপারেশনে:

1. ফিল্টারিং
2. স্কোরিং

ফিল্টারিং ধাপে নোডের সেট খুঁজে বের করা হয় যেখানে পডটি শিডিউল করা সম্ভব। উদাহরণস্বরূপ, PodFitsResources ফিল্টার যাচাই করে যে একটি ক্যান্ডিডেট নোডের পডের নির্দিষ্ট সম্পদ অনুরোধ পূরণ করার জন্য যথেষ্ট পরিমাণ উপলব্ধ সম্পদ আছে কিনা। এই ধাপের পরে, নোড তালিকায় যেকোনো উপযুক্ত নোড থাকে; প্রায়শই, একাধিক থাকবে। যদি তালিকাটি খালি হয়, সেই পডটি (এখনও) শিডিউল করা যায় না।

স্কোরিং ধাপে, শিডিউলার বাকি নোডগুলিকে র্যাঙ্ক করে সবচেয়ে উপযুক্ত পড প্লেসমেন্ট বেছে নেয়। শিডিউলার প্রতিটি নোডকে একটি স্কোর দেয় যা ফিল্টারিং পার করেছে, সক্রিয় স্কোরিং নিয়মগুলির উপর ভিত্তি করে এই স্কোর নির্ধারণ করে।

অবশেষে, kube-scheduler পডটিকে সর্বোচ্চ র্যাঙ্কিং সহ নোডে বরাদ্দ করে। যদি একাধিক নোড সমান স্কোরের সাথে থাকে, kube-scheduler এদের মধ্যে একটিকে এলোমেলোভাবে নির্বাচন করে।

শিডিউলারের ফিল্টারিং এবং স্কোরিং আচরণ কনফিগার করার দুটি সমর্থিত উপায় রয়েছে:

1. শিডিউলিং পলিসি আপনাকে ফিল্টারিংয়ের জন্য প্রেডিকেট এবং স্কোরিংয়ের জন্য প্রায়োরিটি কনফিগার করতে দেয়।
2. শিডিউলিং প্রোফাইল আপনাকে বিভিন্ন শিডিউলিং স্টেজ, যেমন: QueueSort, Filter, Score, Bind, Reserve, Permit, এবং অন্যান্য বাস্তবায়ন করে এমন প্লাগইন কনফিগার করতে দেয়। আপনি বিভিন্ন প্রোফাইল চালানোর জন্য kube-scheduler কেও কনফিগার করতে পারেন।

এর পরের কি

• শিডিউলার পারফরম্যান্স টিউনিং সম্পর্কে পড়ুন
• পড টপোলজি স্প্রেড কনস্ট্রেইন্টস সম্পর্কে পড়ুন
• kube-scheduler এর রেফারেন্স ডকুমেন্টেশন পড়ুন
• kube-scheduler কনফিগ (v1) রেফারেন্স পড়ুন
• একাধিক শিডিউলার কনফিগার করা সম্পর্কে জানুন
• টপোলজি ম্যানেজমেন্ট পলিসি সম্পর্কে জানুন
• পড ওভারহেড সম্পর্কে জানুন
• ভলিউম ব্যবহারকারী পডের শিডিউলিং সম্পর্কে জানুন:
  • ভলিউম টপোলজি সাপোর্ট
  • স্টোরেজ ক্যাপাসিটি ট্র্যাকিং
  • নোড-নির্দিষ্ট ভলিউম লিমিট

11 - ক্লাস্টার অ্যাডমিনিস্ট্রেশন

ক্লাস্টার অ্যাডমিনিস্ট্রেশন ওভারভিউ(overview) যে কেউ একটি কুবারনেটিস ক্লাস্টার তৈরি বা পরিচালনা করছেন তাঁর জন্য। এটি মূল কুবারনেটিসের ধারণাগুলোর সাথে কিছু পরিচিতি আশা করে ।।

একটি ক্লাস্টার পরিকল্পনা

সেট আপ এ নির্দেশিকাগুলি দেখুন কুবারনেটিস ক্লাস্টারগুলি কীভাবে পরিকল্পনা, সেট আপ এবং কনফিগার করতে হয় তার উদাহরণগুলির জন্য৷ এই নিবন্ধে তালিকাভুক্ত সমাধানগুলিকে বলা হয় distros।

একটি গাইড নির্বাচন করার আগে, এখানে কিছু বিবেচনা আছে:

• আপনি কি আপনার কম্পিউটারে কুবারনেটিস ব্যবহার করে দেখতে চান, বা আপনি একটি উচ্চ-উপলব্ধতা(availability) তৈরি করতে চান, মাল্টি-নোড ক্লাস্টার ? আপনার প্রয়োজনের জন্য সবচেয়ে উপযুক্ত ডিস্ট্রো বেছে নিন।
• আপনি কি ব্যবহার করবেন হোস্ট করা কুবারনেটিস ক্লাস্টার , যেমন গুগল কুবারনেটিস ইঞ্জিন, অথবা আপনার নিজস্ব ক্লাস্টার হোস্ট করছেন?
• আপনার ক্লাস্টার কি অন-প্রিমিসেস, বা ক্লাউডে (IaaS) হবে ? কুবারনেটিস হাইব্রিড ক্লাস্টারগুলিকে সরাসরি সমর্থন করে না। এর পরিবর্তে, আপনি একাধিক ক্লাস্টার সেট আপ করতে পারেন।
• যদি আপনি কুবারনেটিস অন-প্রিমিসেস কনফিগার করছেন, তাহলে বিবেচনা করুন নেটওয়ার্কিং মডেল সবচেয়ে উপযুক্ত।
• আপনি কি "বেয়ার মেটাল(bare metal)" হার্ডওয়্যার অথবা ভার্চুয়াল মেশিনে (VMs) চালাবেন?
• আপনি কি একটি ক্লাস্টার চালাতে চান, অথবা আপনি কি কুবারনেটিস প্রজেক্ট কোডের সক্রিয় বিকাশ করার আশা করছেন? যদি পরেরটি হয়, একটি সক্রিয়ভাবে-বিকশিত ডিস্ট্রো নির্বাচন করুন। কিছু ডিস্ট্রো শুধুমাত্র বাইনারি রিলিজ ব্যবহার করে,কিন্তু, পছন্দের একটি বৃহত্তর বৈচিত্র অফার করে।
• একটি ক্লাস্টার চালানোর জন্য প্রয়োজনীয় উপাদান এর সাথে নিজেকে পরিচিত করুন৷

একটি ক্লাস্টার পরিচালনা করা

• শিখুন কিভাবে নোড পরিচালনা করবেন।

  • এ সম্পর্কে পড়ুন cluster autoscaling.

• কিভাবে সেট আপ এবং পরিচালনা করতে হয় রিসোর্স কোটা শেয়ার্ড ক্লাস্টারগুলির জন্য তা শিখুন।

একটি ক্লাস্টার সুরক্ষিত করা

• জেনারেট সার্টিফিকেট বিভিন্ন টুল চেইন ব্যবহার করে সার্টিফিকেট তৈরি করার ধাপগুলি বর্ণনা করে।

• কুবারনেটিস কন্টেইনার এনভায়রনমেন্ট একটি কুবারনেটিস নোডে Kubelet পরিচালিত কন্টেইনারগুলির পরিবেশ বর্ণনা করে।

• Kubernetes API-তে অ্যাক্সেস কন্ট্রোল বর্ণনা করে কিভাবে কুবারনেটিস তার নিজস্ব API এর জন্য অ্যাক্সেস কন্ট্রোল প্রয়োগ করে।

• অথেন্টিকেশন বিভিন্ন অথেন্টিকেশন বিকল্প সহ, কুবারনেটিসে অথেন্টিকেশনের ব্যাখ্যা দেয়।

• অথোরাইজেশন অথেন্টিকেশন থেকে আলাদা, এবং HTTP কলগুলি কীভাবে পরিচালনা করা হয় তা নিয়ন্ত্রণ করে।

• অ্যাডমিশন কন্ট্রোলের ব্যবহার ব্যাখ্যা করে প্লাগ-ইনগুলি অথেন্টিকেশন এবং অথোরাইজেশনের পরে কুবারনেটস API সার্ভারে অনুরোধগুলিকে বাধা দেয়।

• কুবারনেটিস ক্লাস্টারে Sysctls ব্যবহার একজন অ্যাডমিনিস্ট্রেটর কাছে বর্ণনা করে যে কীভাবে কার্নেল প্যারামিটার সেট করতে sysctl কমান্ড-লাইন টুল ব্যবহার করতে হয় ।

• অডিটিং বর্ণনা করে কিভাবে কুবারনেটিসের অডিট লগের সাথে যোগাযোগ করতে হয়।

Kubelet সুরক্ষিত করা

• কন্ট্রোল প্লেন-নোড কমিউনিকেশন
• TLS বুটস্ট্র্যাপিং
• Kubelet অথেন্টিকেশন /অথোরাইজেশন

অপশনাল ক্লাস্টার সার্ভিস

• DNS ইন্টিগ্রেশন বর্ণনা করে কিভাবে সরাসরি কুবারনেটিস পরিষেবাতে একটি DNS নাম সমাধান করা যায়।

• লগিং এবং মনিটরিং ক্লাস্টার অ্যাক্টিভিটি ব্যাখ্যা করে কিভাবে কুবারনেটিসে লগিং কাজ করে এবং কিভাবে এটি বাস্তবায়ন করা যায়।

11.1 - সার্টিফিকেট

আপনার ক্লাস্টারের জন্য সার্টিফিকেট তৈরি করার পদ্ধতি জানতে সার্টিফিকেট ডকুমেন্টেশন দেখুন।

11.2 - ক্লাস্টার নেটওয়ার্কিং

নেটওয়ার্কিং কুবারনেটিসের একটি কেন্দ্রীয় অংশ, কিন্তু এটি কীভাবে কাজ করে তা বোঝা চ্যালেঞ্জিং হতে পারে। মোট ৪টি আলাদা নেটওয়ার্কিং সমস্যা রয়েছে যা সমাধান করতে হয়:

1. অত্যন্ত ঘনিষ্ঠভাবে সংযুক্ত কন্টেইনার-টু-কন্টেইনার যোগাযোগ: এটি পড এবং localhost যোগাযোগের মাধ্যমে সমাধান করা হয়।
2. পড-টু-পড যোগাযোগ: এটি এই ডকুমেন্টের প্রধান আলোচ্য বিষয়।
3. পড-টু-সার্ভিস যোগাযোগ: এটি সার্ভিস দ্বারা আলোচিত হয়েছে।
4. বাহ্যিক-টু-সার্ভিস যোগাযোগ: এটিও সার্ভিস দ্বারা আলোচিত হয়েছে।

কুবারনেটিস মূলত অ্যাপ্লিকেশনগুলির মধ্যে মেশিন ভাগ করে নেওয়ার বিষয়ে। সাধারণত, মেশিন ভাগ করে নেওয়ার জন্য নিশ্চিত করতে হয় যে দুটি অ্যাপ্লিকেশন একই পোর্ট ব্যবহার করার চেষ্টা না করে। বড় আকারের সিস্টেমে বিভিন্ন ডেভেলপারদের মধ্যে পোর্ট সমন্বয় করা খুব কঠিন এবং ব্যবহারকারীদের নিয়ন্ত্রণের বাইরে ক্লাস্টার-লেভেলের সমস্যাগুলি প্রকাশ করে।

ডাইনামিক পোর্ট বরাদ্দ সিস্টেমে অনেক জটিলতা আনে - প্রতিটি অ্যাপ্লিকেশনকে পোর্টগুলি ফ্ল্যাগ হিসাবে নিতে হয়, API সার্ভারগুলিকে কনফিগারেশন ব্লকগুলিতে ডাইনামিক পোর্ট নম্বর কীভাবে ঢোকাতে হয় তা জানতে হয়, সার্ভিসগুলিকে একে অপরকে কীভাবে খুঁজে পেতে হয় তা জানতে হয়, ইত্যাদি। এই সমস্যাগুলি সমাধান করার পরিবর্তে, কুবারনেটিস একটি ভিন্ন পদ্ধতি গ্রহণ করে।

কুবারনেটিস নেটওয়ার্কিং মডেল সম্পর্কে জানতে, এখানে দেখুন।

কুবারনেটিস IP অ্যাড্রেস রেঞ্জ

কুবারনেটিস ক্লাস্টারগুলির জন্য পড, সার্ভিস এবং নোডের জন্য নন-ওভারল্যাপিং IP অ্যাড্রেস বরাদ্দ করতে হয়, নিম্নলিখিত উপাদানগুলিতে কনফিগার করা উপলব্ধ অ্যাড্রেস রেঞ্জ থেকে:

• নেটওয়ার্ক প্লাগইনটি পডগুলিকে IP অ্যাড্রেস বরাদ্দ করার জন্য কনফিগার করা হয়।
• kube-apiserver সার্ভিসগুলিকে IP অ্যাড্রেস বরাদ্দ করার জন্য কনফিগার করা হয়।
• kubelet বা cloud-controller-manager নোডগুলিকে IP অ্যাড্রেস বরাদ্দ করার জন্য কনফিগার করা হয়।

ক্লাস্টার নেটওয়ার্কিং প্রকার

কুবারনেটিস ক্লাস্টারগুলি, কনফিগার করা IP ফ্যামিলিগুলির উপর ভিত্তি করে, এই প্রকারগুলিতে বিভক্ত করা যেতে পারে:

• শুধুমাত্র IPv4: নেটওয়ার্ক প্লাগইন, kube-apiserver এবং kubelet/cloud-controller-manager শুধুমাত্র IPv4 অ্যাড্রেস বরাদ্দ করার জন্য কনফিগার করা আছে।
• শুধুমাত্র IPv6: নেটওয়ার্ক প্লাগইন, kube-apiserver এবং kubelet/cloud-controller-manager শুধুমাত্র IPv6 অ্যাড্রেস বরাদ্দ করার জন্য কনফিগার করা আছে।
• IPv4/IPv6 বা IPv6/IPv4 ডুয়াল-স্ট্যাক:
  • নেটওয়ার্ক প্লাগইন IPv4 এবং IPv6 অ্যাড্রেস বরাদ্দ করার জন্য কনফিগার করা আছে।
  • kube-apiserver IPv4 এবং IPv6 অ্যাড্রেস বরাদ্দ করার জন্য কনফিগার করা আছে।
  • kubelet বা cloud-controller-manager IPv4 এবং IPv6 অ্যাড্রেস বরাদ্দ করার জন্য কনফিগার করা আছে।
  • সমস্ত উপাদানগুলি কনফিগার করা প্রাথমিক IP ফ্যামিলির সাথে সম্মত হতে হবে।

কুবারনেটিস ক্লাস্টারগুলি শুধুমাত্র পড, সার্ভিস এবং নোড অবজেক্টগুলিতে উপস্থিত IP ফ্যামিলিগুলি বিবেচনা করে, প্রতিনিধিত্ব করা অবজেক্টগুলির বিদ্যমান IP গুলি থেকে স্বাধীনভাবে। উদাহরণস্বরূপ, একটি সার্ভার বা একটি পডের ইন্টারফেসগুলিতে একাধিক IP অ্যাড্রেস থাকতে পারে, কিন্তু শুধুমাত্র node.status.addresses বা pod.status.ips এ থাকা IP অ্যাড্রেসগুলিই কুবারনেটিস নেটওয়ার্ক মডেল বাস্তবায়ন এবং ক্লাস্টারের প্রকার নির্ধারণের জন্য বিবেচনা করা হয়।

কীভাবে কুবারনেটিস নেটওয়ার্ক মডেল বাস্তবায়ন করা যায়

নেটওয়ার্ক মডেলটি প্রতিটি নোডে কন্টেইনার রানটাইম দ্বারা বাস্তবায়িত হয়। সবচেয়ে সাধারণ কন্টেইনার রানটাইমগুলি তাদের নেটওয়ার্ক এবং সুরক্ষা ক্ষমতা পরিচালনা করার জন্য কন্টেইনার নেটওয়ার্ক ইন্টারফেস (CNI) প্লাগইন ব্যবহার করে। বিভিন্ন বিক্রেতাদের থেকে অনেক ভিন্ন CNI প্লাগইন রয়েছে। এদের মধ্যে কিছু শুধুমাত্র নেটওয়ার্ক ইন্টারফেস যোগ করা এবং সরানোর মৌলিক বৈশিষ্ট্য প্রদান করে, অন্যদিকে অন্যান্যরা আরও জটিল সমাধান প্রদান করে, যেমন অন্যান্য কন্টেইনার অর্কেস্ট্রেশন সিস্টেমের সাথে ইন্টিগ্রেশন, একাধিক CNI প্লাগইন চালানো, উন্নত IPAM বৈশিষ্ট্য ইত্যাদি।

কুবারনেটিস দ্বারা সমর্থিত নেটওয়ার্কিং অ্যাডঅন এর একটি অসম্পূর্ণ তালিকার জন্য এই পৃষ্ঠা দেখুন।

এর পরের কি

নেটওয়ার্কিং মডেলের প্রাথমিক ডিজাইন এবং এর যৌক্তিকতা নেটওয়ার্কিং ডিজাইন ডকুমেন্ট এ আরও বিস্তারিতভাবে বর্ণনা করা হয়েছে। কুবারনেটিস নেটওয়ার্কিং উন্নত করার লক্ষ্যে ভবিষ্যত পরিকল্পনা এবং কিছু চলমান প্রচেষ্টার জন্য, অনুগ্রহ করে SIG-Network KEPs দেখুন।

12 - কুবারনেটিসে উইন্ডোজ

কুবার্নেটিস লিনাক্স বা মাইক্রোসফট উইন্ডোজ চালানো ওয়ার্কার নোড নোড সমর্থন করে।

CNCF এবং এর মূল প্রতিষ্ঠান লিনাক্স ফাউন্ডেশন (Linux Foundation) নিরপেক্ষভাবে সামঞ্জস্যতা নিশ্চিত করে। আপনি চাইলে আপনার উইন্ডোজ সার্ভার কে কুবার্নেটিস ক্লাস্টারের ওয়ার্কার নোড হিসেবে যুক্ত করতে পারেন।

আপনার ক্লাস্টারে যে অপারেটিং সিস্টেমই থাকুক না কেন, আপনি সহজেই [Windows-এ kubectl ইনস্টল এবং সেটআপ করতে পারেন।] (/bn/docs/tasks/tools/install-kubectl-windows/)

যদি আপনি Windows নোড ব্যবহার করেন, তাহলে আপনি এটি পড়তে পারেন:

• Windows-এ নেটওয়ার্কিং
• কুবার্নেটিসে Windows স্টোরেজ
• Windows নোডের জন্য রিসোর্স ব্যবস্থাপনা
• উইন্ডোজ পড এবং কন্টেইনারগুলির জন্য RunAsUserName কনফিগার করুন
• Windows হোস্টপ্রসেস পড তৈরি করুন
• Windows পড এবং কন্টেইনারের জন্য গ্রুপ ম্যানেজড সার্ভিস অ্যাকাউন্ট কনফিগার করুন
• Windows নোডের জন্য নিরাপত্তা
• Windows ডিবাগিং টিপস
• কুবার্নেটিসে Windows কন্টেইনার নির্ধারণের জন্য গাইড

অথবা, একটি সারাংশের জন্য, পড়ুন:

13 - কুবারনেটিস প্রসারিত করা

কুবারনেটিস খুবই কনফিগারযোগ্য এবং সম্প্রসারণযোগ্য। ফলস্বরূপ, কুবারনেটিস প্রজেক্ট কোডে ফর্ক(fork) বা প্যাচ জমা দেওয়ার খুব কমই প্রয়োজন হয়।

এই নির্দেশিকাটি একটি কুবারনেটিস ক্লাস্টার কাস্টমাইজ করার উপায়গুলো বর্ণনা করে ৷ এই নির্দেশিকাটি ক্লাস্টার অপারেটরদের লক্ষ্য করে বানানো যারা তাদের কুবারনেটিস ক্লাস্টারকে তাদের কাজের পরিবেশের প্রয়োজনের সাথে কীভাবে মানিয়ে নিতে হয় তা বুঝতে চায়। ডেভেলপাররা যারা সম্ভাব্য প্ল্যাটফর্ম ডেভেলপকারী বা কুবারনেটিস প্রজেক্ট কন্ট্রিবিউটরা , এক্সটেনশন পয়েন্ট (extension points) কি এবং প্যাটার্ন বিদ্যমান এর পরিচিতি হিসাবে এবং তাদের ট্রেড-অফ আর সীমাবদ্ধতা জানার জন্য এই নির্দেশিকাটিকে দরকারী হিসেবে পাবে।

কাস্টমাইজেশন পন্থাগুলিকে বিস্তৃতভাবে কনফিগারেশনে বিভক্ত করা যেতে পারে, যার মধ্যে শুধুমাত্র কমান্ড লাইন আর্গুমেন্ট, লোকাল কনফিগারেশন ফাইল বা API রিসোর্স পরিবর্তন করা জড়িত; এবং এক্সটেনশন, যার মধ্যে অতিরিক্ত প্রোগ্রাম চালানো, অতিরিক্ত নেটওয়ার্ক সার্ভিস বা উভয়ই জড়িত। এই ডকুমেন্টটি মূলত এক্সটেনশন সম্পর্কে।

কনফিগারেশন

কনফিগারেশন ফাইল এবং কমান্ড আর্গুমেন্ট অনলাইন ডকুমেন্টেশনের রেফারেন্স বিভাগে ডকুমেন্টেড করা হয়েছে, প্রতিটি বাইনারির জন্য একটি পৃষ্ঠা রয়েছে :

• kube-apiserver
• kube-controller-manager
• kube-scheduler
• kubelet
• kube-proxy

কমান্ড আর্গুমেন্ট এবং কনফিগারেশন ফাইল সবসময় একটি হোস্ট করা কুবারনেটিস সার্ভিস বা পরিচালিত ইনস্টলেশনের সাথে একটি ডিস্ট্রিবিউশন এ পরিবর্তনযোগ্য নাও হতে পারে। যখন তারা পরিবর্তনযোগ্য হয়, তারা সাধারণত ক্লাস্টার অপারেটর দ্বারা পরিবর্তনযোগ্য হয়। এছাড়াও, এগুলো ভবিষ্যতের কুবারনেটিস সংস্করণে পরিবর্তন হতে পারে, এবং সেগুলো সেট করার জন্য রিস্টারটিং প্রক্রিয়া প্রয়োজন হতে পারে। এই কারণে, সেগুলি শুধুমাত্র তখনই ব্যবহার করা উচিত যখন অন্য কোন বিকল্প থাকে না।

বিল্ট-ইন পলিসি API গুলো, যেমন ResourceQuota, NetworkPolicy এবং Role-based Access Control (RBAC), হলো বিল্ট-ইন কুবারনেটিস API যা ঘোষণামূলকভাবে কনফিগার করা পলিসি সেটিংস প্রদান করে। API গুলো সাধারণত হোস্ট করা কুবারনেটিস সার্ভিস এবং পরিচালিত কুবারনেটিস ইনস্টলেশনগুলোর সাথে ব্যবহারযোগ্য। বিল্ট-ইন পলিসি API গুলো অন্যান্য কুবারনেটিস রিসোর্স যেমন পডের মতো একই নিয়ম অনুসরণ করে। আপনি যখন স্থিতিশীল একটি পলিসি API ব্যবহার করেন, তখন আপনি অন্যান্য কুবারনেটিস API-এর মতো একটি সংজ্ঞায়িত সাপোর্ট পলিসি থেকে উপকৃত হন। এই কারণে, পলিসি API গুলো কনফিগারেশন ফাইল এবং কমান্ড আর্গুমেন্ট এর বদলে যেখানে উপযুক্ত সেখানে সুপারিশ করা হয় ।

এক্সটেনশন

এক্সটেনশন হলো সফ্টওয়্যার উপাদান যা কুবারনেটিসের সাথে প্রসারিত এবং গভীরভাবে একত্রিত হয়। তারা এটিকে নতুন টাইপের এবং নতুন ধরণের হার্ডওয়্যার সাপোর্ট করার জন্য মানিয়ে নেয়।

অনেক ক্লাস্টার অ্যাডমিনিস্ট্রেটর কুবারনেটিসের হোস্টেড বা ডিস্ট্রিবিউশন উদাহরণ ব্যবহার করে। এই ক্লাস্টারগুলো পূর্বে ইনস্টল করা এক্সটেনশনগুলোর সাথে আসে। ফলস্বরূপ, বেশিরভাগ কুবারনেটিস ব্যবহারকারীদের এক্সটেনশন ইনস্টল করার প্রয়োজন হবে না এবং এমনকি কম ব্যবহারকারীদের নতুন বানাতে হবে।

এক্সটেনশন প্যাটার্ন

কুবারনেটিস ডিজাইন করা হয়েছে ক্লায়েন্ট প্রোগ্রাম লিখার মাধ্যমে স্বয়ংক্রিয় হতে । কুবারনেটিস API-তে পড়া এবং/অথবা লেখা যে কোনো প্রোগ্রাম দরকারী অটোমেশন প্রদান করতে পারে। অটোমেশন ক্লাস্টারে চলতে পারে বা এটি বন্ধ করতে পারে। এই ডকুমেন্টের নির্দেশিকা অনুসরণ করে আপনি অত্যন্ত উপলব্ধ এবং শক্তিশালী অটোমেশন লিখতে পারেন। অটোমেশন সাধারণত হোস্ট করা ক্লাস্টার এবং পরিচালিত ইনস্টলেশন সহ যেকোন কুবারনেটিস ক্লাস্টারের সাথে কাজ করে।

ক্লায়েন্ট প্রোগ্রাম লেখার জন্য একটি নির্দিষ্ট প্যাটার্ন রয়েছে যা কুবারনেটিসের সাথে ভালভাবে কাজ করে যাকে কন্ট্রোলার প্যাটার্ন বলা হয়। কন্ট্রোলাররা সাধারণত একটি অবজেক্টের .spec পড়ে, সম্ভবত জিনিসগুলি করে এবং তারপর অবজেক্টের .status আপডেট করে ৷

একটি কন্ট্রোলার হল কুবারনেটিস API-এর ক্লায়েন্ট। যখন কুবারনেটিস ক্লায়েন্ট হয় এবং একটি রিমোট সার্ভিসে কল করে, কুবারনেটিস এটিকে একটি webhook বলে। রিমোট সার্ভিসকে webhook backend বলা হয়। কাস্টম কন্ট্রোলারের মতো, webhook গুলো ব্যর্থতার একটি পয়েন্ট যোগ করে।

webhook মডেলে, কুবারনেটিস একটি রিমোট সার্ভিসে একটি নেটওয়ার্ক অনুরোধ করে। বিকল্প binary Plugin মডেলের সাথে, কুবারনেটস একটি বাইনারি (প্রোগ্রাম) চালায়। বাইনারি প্লাগইনগুলো kubelet দ্বারা ব্যবহৃত হয় (উদাহরণস্বরূপ, CSI storage plugins এবং CNI network plugins), এবং kubectl দ্বারা (প্লাগইনগুলোর সাথে প্রসারিত kubectl দেখুন)।

এক্সটেনশন পয়েন্ট

এই ডায়াগ্রামটি একটি কুবারনেটিস ক্লাস্টারের এক্সটেনশন পয়েন্ট এবং এটি অ্যাক্সেসকারী ক্লায়েন্টদের দেখায়।

চিত্রের চাবিকাঠি

1. ব্যবহারকারীরা প্রায়ই kubectl ব্যবহার করে কুবারনেটিস API এর সাথে যোগাযোগ করে। প্লাগইন ক্লায়েন্টদের আচরণ কাস্টমাইজ করে। জেনেরিক এক্সটেনশন রয়েছে যা বিভিন্ন ক্লায়েন্টের জন্য প্রযোজ্য হতে পারে, সেইসাথেkubectl প্রসারিত করার নির্দিষ্ট উপায়ও ।

2. API সার্ভার সমস্ত অনুরোধ পরিচালনা করে। API সার্ভারে বিভিন্ন ধরণের এক্সটেনশন পয়েন্টগুলো তাদের কনটেন্টের উপর ভিত্তি করে অনুরোধগুলো অথেন্টিকেটিং(authenticating), বা তাদের ব্লক করার অনুমতি দেয়, বিষয়বস্তু পরিবর্তন করে এবং মুছে ফেলার ব্যবস্থা করে। এগুলো API অ্যাক্সেস এক্সটেনশন বিভাগে বর্ণিত হয়েছে।

3. এপিআই সার্ভার বিভিন্ন ধরণের রিসোর্স সরবরাহ করে। বিল্ট-ইন রিসোর্স ধরনের, যেমন pods, কুবারনেটিস প্রজেক্ট দ্বারা সংজ্ঞায়িত করা হয় এবং পরিবর্তন করা যায় না। কুবারনেটিস API প্রসারিত করার বিষয়ে জানতে API এক্সটেনশন পড়ুন।

4. কুবারনেটিস শিডিউলার কোন নোডগুলোতে পড স্থাপন করবে তা নির্ধারণ করে। শিডিউলিং প্রসারিত করার বিভিন্ন উপায় রয়েছে, যা শিডিউলিং এক্সটেনশন বিভাগে বর্ণিত করা হয়েছে।

5. কুবারনেটিসের বেশিরভাগ আচরণ কন্ট্রোলার নামক প্রোগ্রাম দ্বারা বাস্তবায়িত হয়, যেগুলো API সার্ভারের ক্লায়েন্ট। কন্ট্রোলারগুলো প্রায়ই কাস্টম রিসোর্সগুলোর সাথে একত্রে ব্যবহৃত হয়। আরও জানতে অটোমেশনের সাথে নতুন API-এর সমন্বয় এবং বিল্ট-ইন রিসোর্স পরিবর্তন পড়ুন।

6. kubelet সার্ভারে (নোড) চলে এবং ক্লাস্টার নেটওয়ার্কে তাদের নিজস্ব আইপি সহ ভার্চুয়াল সার্ভারের মতো পডগুলোকে দেখাতে সহায়তা করে। নেটওয়ার্ক প্লাগইনগুলো পড নেটওয়ার্কিং এর বিভিন্ন বাস্তবায়নের অনুমতি দেয়।

7. আপনি কাস্টম হার্ডওয়্যার বা অন্যান্য বিশেষ নোড-লোকাল সুবিধাগুলো একীভূত করতে ডিভাইস প্লাগইনগুলো ব্যবহার করতে পারেন এবং আপনার ক্লাস্টারে চলমান পডগুলোতে এগুলো উপলব্ধ করতে পারেন৷ kubelet ডিভাইস প্লাগইনগুলোর সাথে কাজ করার জন্য সাপোর্ট অন্তর্ভুক্ত করে।

   kubelet পড এবং তাদের কন্টেইনারের জন্য ভলিউম মাউন্ট এবং আনমাউন্ট করে। আপনি নতুন ধরনের স্টোরেজ এবং অন্যান্য ভলিউম টাইপের জন্য সাপোর্ট যোগ করতে স্টোরেজ প্লাগইন ব্যবহার করতে পারেন।

এক্সটেনশন পয়েন্ট চয়েস ফ্লোচার্ট

আপনি কোথা থেকে শুরু করবেন তা নিশ্চিত না হলে, এই ফ্লোচার্টটি সাহায্য করতে পারবে৷ মনে রাখবেন কিছু সমাধানে বিভিন্ন ধরনের এক্সটেনশন জড়িত থাকতে পারে।

ক্লায়েন্ট এক্সটেনশন

kubectl-এর জন্য প্লাগইন হলো পৃথক বাইনারি যা নির্দিষ্ট সাবকমান্ডের আচরণ যোগ বা প্রতিস্থাপন করে। kubectl টুলটি ক্রেডেনশিয়াল(credential) প্লাগইনগুলোর সাথেও একীভূত করতে পারে। এই এক্সটেনশনগুলো শুধুমাত্র একটি একক ব্যবহারকারীর লোকাল পরিবেশকে প্রভাবিত করে, এবং তাই সাইট-ব্যাপী পলিসিগুলো প্রয়োগ করতে পারে না।

আপনি যদি kubectl টুল প্রসারিত করতে চান, তাহলে প্লাগইন সহ kubectl প্রসারিত করা পড়ুন।

API এক্সটেনশন

কাস্টম রিসোর্স সংজ্ঞা

আপনি যদি নতুন কন্ট্রোলার, অ্যাপ্লিকেশন কনফিগারেশন অবজেক্ট বা অন্যান্য ডিক্লারেটিভ API সংজ্ঞায়িত করতে চান এবং কুবারনেটিস টুলস যেমন kubectl ব্যবহার করে সেগুলো পরিচালনা করতে চান তাহলে কুবারনেটিসে একটি কাস্টম রিসোর্স যোগ করার কথা বিবেচনা করুন।

কাস্টম রিসোর্স সম্পর্কে আরও জানতে, কাস্টম রিসোর্স কনসেপ্ট গাইড দেখুন।

API এগ্রিগেশন লেয়ার(aggregation layer)

আপনি কুবারনেটিস API এগ্রিগেশন লেয়ার ব্যবহার করতে পারেন কুবারনেটিস API-কে মেট্রিক্সের মতো অতিরিক্ত সার্ভিসের সাথে একীভূত করতে।

অটোমেশনের সাথে নতুন API-এর সমন্বয়

একটি কাস্টম রিসোর্স API এবং একটি কন্ট্রোল লুপের সংমিশ্রণকে কন্ট্রোলার প্যাটার্ন বলা হয়। যদি আপনার কন্ট্রোলার একটি কাঙ্ক্ষিত অবস্থার উপর ভিত্তি করে অবকাঠামো স্থাপনকারী মানব অপারেটরের স্থান নেয়, তাহলে কন্ট্রোলারও অপারেটর প্যাটার্ন অনুসরণ করতে পারে। অপারেটর প্যাটার্ন নির্দিষ্ট অ্যাপ্লিকেশন পরিচালনা করতে ব্যবহৃত হয়; সাধারণত, এগুলো হলো এমন অ্যাপ্লিকেশন যা অবস্থা বজায় রাখে এবং সেগুলোকে কীভাবে পরিচালনা করা হয় তার যত্নের প্রয়োজন হয়৷

আপনি আপনার নিজস্ব কাস্টম API এবং কন্ট্রোল লুপগুলোও তৈরি করতে পারেন যা অন্যান্য রিসোর্সগুলো পরিচালনা করতে পারে, যেমন স্টোরেজ, বা পলিসিগুলো সংজ্ঞায়িত করতে (যেমন একটি অ্যাক্সেস কন্ট্রোল রেস্ট্রিকশন)।

বিল্ট-ইন রিসোর্স পরিবর্তন

আপনি যখন কাস্টম রিসোর্স যোগ করে কুবারনেটিস API প্রসারিত করেন, তখন যোগ করা রিসোর্স সবসময় একটি নতুন API গ্রুপে পড়ে। আপনি বিদ্যমান API গ্রুপগুলোকে প্রতিস্থাপন বা পরিবর্তন করতে পারবেন না ৷ একটি API যোগ করলে আপনাকে বিদ্যমান API-এর আচরণকে সরাসরি প্রভাবিত করতে দেওয়া না (যেমন পড), যেখানে API অ্যাক্সেস এক্সটেনশানগুলো করে।

API অ্যাক্সেস এক্সটেনশন

যখন একটি অনুরোধ কুবারনেটিস API সার্ভারে পৌঁছায়, এটি প্রথমে অথেন্টিকেটেড(authenticated) করা হয়, তারপর অনুমোদিত(authorized) হয় এবং তারপরে আসে বিভিন্ন ধরণের অ্যাডমিশন কন্ট্রোলের(admission control) বিষয় (কিছু অনুরোধ প্রকৃতপক্ষে অথেন্টিকেটেড(authenticated) নয়, এবং স্পেশাল ট্রিটমেন্ট পান)। এই প্রবাহ সম্পর্কে আরও জানতে কুবারনেটিস API-এ অ্যাক্সেস কন্ট্রোল করা দেখুন।

কুবারনেটিস অথেন্টিকেশন/অথোরাইজেশন প্রবাহের প্রতিটি ধাপ এক্সটেনশন পয়েন্ট অফার করে।

অথেন্টিকেশন(Authentication)

ক্লায়েন্ট অনুরোধ করার জন্য একটি ব্যবহারকারীর নামের সমস্ত অনুরোধে অথেন্টিকেশন শিরোনাম বা সার্টিফিকেট যুক্ত করে।

কুবারনেটিস এর বেশ কয়েকটি বিল্ট-ইন অথেন্টিকেশন পদ্ধতি রয়েছে যা এটি সাপোর্ট করে। এটি একটি অথেন্টিকেটিং প্রক্সির পিছনেও বসতে পারে এবং এটি একটি অথোরাইজেশন(Authorization) টোকেন পাঠাতে পারে যাচাইয়ের জন্য: শিরোনাম থেকে একটি রিমোট সার্ভিসে (একটি অথেন্টিকেশন webhook) যদি সেগুলো আপনার প্রয়োজনগুলো পূরণ না করে৷

অথোরাইজেশন(Authorization)

অথোরাইজেশন নির্ধারণ করে যে নির্দিষ্ট ব্যবহারকারীরা API রিসোর্সগুলোতে পড়তে, লিখতে এবং অন্যান্য ক্রিয়াকলাপ করতে পারে কিনা। এটি সম্পূর্ণ রিসোর্সের লেভেলে কাজ করে -- এটি ইচ্ছামত অবজেক্টের ফিল্ডের উপর ভিত্তি করে বৈষম্য করে না।

যদি বিল্ট-ইন অথোরাইজেশনের উপায়গুলো আপনার চাহিদা পূরণ না করে, তাহলে একটি অথোরাইজেশন webhook কাস্টম কোডে কল করার অনুমতি দেয় যা একটি অথোরাইজেশনের সিদ্ধান্ত নেয়।

ডাইনামিক অ্যাডমিশন কন্ট্রোল

একটি অনুরোধ অনুমোদিত হওয়ার পরে, যদি এটি একটি লিখিত অপারেশন হয়, তবে এটি অ্যাডমিশন কন্ট্রোলের পদক্ষেপগুলোর মধ্য দিয়ে যায়। বিল্ট-ইন পদক্ষেপগুলো ছাড়াও, বেশ কয়েকটি এক্সটেনশন রয়েছে:

• ইমেজ পলিসি webhook কন্টেইনারে কোন ইমেজ চালানো যাবে তা সীমাবদ্ধ করে।
• ইচ্ছামত অ্যাডমিশন কন্ট্রোলের সিদ্ধান্ত নিতে, একটি সাধারণ অ্যাডমিশন webhook ব্যবহার করা যেতে পারে। অ্যাডমিশন webhook সৃষ্টি বা আপডেট প্রত্যাখ্যান করতে পারে। কিছু অ্যাডমিশন webhook ইনকামিং রিকোয়েস্ট ডেটা পরিবর্তন করে কুবারনেটিস দ্বারা আরও পরিচালনা করার আগে।

অবকাঠামো এক্সটেনশন

ডিভাইস প্লাগইন

ডিভাইস প্লাগইনগুলো একটি ডিভাইস প্লাগইনের মাধ্যমে একটি নোডকে নতুন নোড রিসোর্সগুলো (CPU এবং মেমরির মতো বিল্টইনগুলো ছাড়াও) আবিষ্কার করতে দেয় ।

স্টোরেজ প্লাগইন

কন্টেইনার স্টোরেজ ইন্টারফেস(Container Storage Interface) (CSI) প্লাগইনগুলো নতুন ধরনের ভলিউমের জন্য সাপোর্ট সহ কুবারনেটিস প্রসারিত করার একটি উপায় প্রদান করে। ভলিউমগুলো টেকসই এক্সটার্নাল স্টোরেজ দ্বারা সাহায্যপ্রাপ্ত করা যেতে পারে, বা ক্ষণস্থায়ী স্টোরেজ(ephemeral storage) প্রদান করতে পারে, অথবা তারা একটি ফাইল সিস্টেম প্যারাডাইম ব্যবহার করে তথ্যের জন্য একটি রিড-অনলি ইন্টারফেস দিতে পারে ।

কুবারনেটিস এছাড়াও FlexVolume প্লাগইনগুলোর জন্য সাপোর্ট অন্তর্ভুক্ত করে, যা কুবারনেটিস v1.23 (CSI-এর পক্ষে) থেকে অবমূল্যায়িত(deprecated) করা হয়েছে ।

FlexVolume প্লাগইনগুলো ব্যবহারকারীদের ভলিউম প্রকারগুলো মাউন্ট করার অনুমতি দেয় যা সাধারণত কুবারনেটিস দ্বারা সাপোর্টেড নয়। আপনি যখন FlexVolume স্টোরেজের উপর নির্ভর করে এমন একটি পড চালান, তখন kubelet ভলিউম মাউন্ট করার জন্য একটি বাইনারি প্লাগইন কল করে। আর্কাইভ করা FlexVolume ডিজাইন প্রস্তাবে এই পদ্ধতির আরও বিশদ বিবরণ রয়েছে।

The Kubernetes Volume Plugin FAQ for Storage Vendors তে স্টোরেজ প্লাগইনগুলোর সাধারণ তথ্য অন্তর্ভুক্ত রয়েছে ।

নেটওয়ার্ক প্লাগইন

আপনার কুবারনেটিস ক্লাস্টারের একটি নেটওয়ার্ক প্লাগইন প্রয়োজন যাতে একটি কার্যকরী পড নেটওয়ার্ক থাকে এবং কুবারনেটিস নেটওয়ার্ক মডেলের অন্যান্য দিকগুলোকে সাপোর্ট করতে পারে৷

নেটওয়ার্ক প্লাগইনগুলো কুবারনেটিসকে বিভিন্ন নেটওয়ার্কিং টপোলজি এবং প্রযুক্তির সাথে কাজ করার অনুমতি দেয়।

Kubelet ইমেজ ক্রেডেনশিয়াল প্রোভাইডার প্লাগইন (Kubelet image credential provider plugins)

প্লাগইনগুলো বহিরাগত সার্ভিসগুলোর সাথে যোগাযোগ করতে পারে বা ক্রেডেনশিয়ালগুলো পেতে লোকাল ফাইলগুলো ব্যবহার করতে পারে ৷ এইভাবে, kubelet এর প্রতিটি রেজিস্ট্রির জন্য স্ট্যাটিক ক্রেডেনশিয়ালের প্রয়োজন নেই এবং বিভিন্ন অথেন্টিকেশন পদ্ধতি এবং প্রোটোকল সাপোর্ট করতে পারে ।

প্লাগইন কনফিগারেশনের বিশদ বিবরণের জন্য, একটি Kubelet ইমেজ ক্রেডেনশিয়াল প্রোভাইডার কনফিগার দেখুন।

শিডিউলিং এক্সটেনশন

শিডিউলার হলো একটি বিশেষ ধরনের কন্ট্রোলার যা পডগুলো দেখে এবং নোডগুলোতে পড বরাদ্দ করে। অন্যান্য কুবারনেটিস উপাদানগুলো ব্যবহার করা চালিয়ে যাওয়ার সময় ডিফল্ট শিডিউলার সম্পূর্ণরূপে প্রতিস্থাপন করা যেতে পারে, অথবা একাধিক শিডিউলার একই সময়ে চলতে পারে।

এটি একটি উল্লেখযোগ্য উদ্যোগ, এবং প্রায় সমস্ত কুবারনেটিস ব্যবহারকারীরা দেখতে পান যে তাদের শিডিউলার পরিবর্তন করার প্রয়োজন নেই।

আপনি কোন শিডিউলার প্লাগইনগুলো সক্রিয় তা নিয়ন্ত্রণ করতে পারেন বা বিভিন্ন নামযুক্ত শিডিউলার প্রোফাইলের সাথে প্লাগইনগুলোর সেটগুলোকে সংযুক্ত করতে পারেন ৷ আপনি আপনার নিজস্ব প্লাগইনও লিখতে পারেন যা এক বা একাধিক kube-scheduler এর এক্সটেনশন পয়েন্টের সাথে একত্রিত হয় ।

অবশেষে, বিল্ট-ইন kube-scheduler উপাদানটি একটি webhookকে সাপোর্ট করে যা একটি রিমোট HTTP ব্যাকএন্ড (শিডিউলার এক্সটেনশন) ফিল্টার এবং/অথবা নোডগুলোকে অগ্রাধিকার দেওয়ার অনুমতি দেয় যা kube-scheduler একটি পডের জন্য বেছে নেয়।

এর পরের কি

• অবকাঠামো এক্সটেনশন সম্পর্কে আরও জানুন
  • ডিভাইস প্লাগইন
  • নেটওয়ার্ক প্লাগইন
  • CSI স্টোরেজ প্লাগইন
• kubectl প্লাগইন সম্পর্কে জানুন
• কাস্টম রিসোর্স সম্পর্কে আরও জানুন
• এক্সটেনশন API সার্ভার সম্পর্কে আরও জানুন
• ডাইনামিক অ্যাডমিশন কন্ট্রোল সম্পর্কে জানুন
• অপারেটর প্যাটার্ন সম্পর্কে জানুন

13.1 - অপারেটর প্যাটার্ন

অপারেটর হল কুবারনেটিসের সফ্টওয়্যার এক্সটেনশন, যা
কাস্টম রিসোর্স
ব্যবহার করে অ্যাপ্লিকেশন এবং তাদের কম্পোনেন্টগুলি পরিচালনা করে। অপারেটরগুলি কুবারনেটিসের নীতিগুলো অনুসরণ করে, বিশেষত কন্ট্রোল লুপ (control loop)।

অনুপ্রেরণা

অপারেটর প্যাটার্ন এমন একটি ধারণা যা একজন মানুষ
কোনো সার্ভিস বা সার্ভিসের সেট পরিচালনার সময় অনুসরণ করেন। যারা নির্দিষ্ট অ্যাপ্লিকেশন ও সার্ভিস পরিচালনা করেন, তারা সিস্টেম কীভাবে কাজ করা উচিত, কীভাবে এটি ডিপ্লয় করতে হয়,
এবং কোনো সমস্যা হলে কীভাবে প্রতিক্রিয়া জানাতে হয়—এসব বিষয়ে গভীর জ্ঞান রাখেন।

কুবারনেটিস ওয়ার্কলোড পরিচালনাকারীরা প্রায়ই অটোমেশন ব্যবহার করতে চান,
যা পুনরাবৃত্তিমূলক কাজগুলো করে দেয়। অপারেটর প্যাটার্ন দেখায় কীভাবে আপনি কোড লিখে
এমন একটি কাজ অটোমেট করতে পারেন, যা কুবারনেটিস নিজেই সরাসরি প্রদান করে না।

কুবারনেটিস অপারেটর

কুবারনেটিস অটোমেশন কাজের জন্য ডিজাইন করা হয়েছে। শুরুতেই, আপনি কুবারনেটিসের মূল অংশ থেকে অনেক বিল্ট-ইন অটোমেশন পাবেন। আপনি কুবারনেটিস ব্যবহার করে ওয়ার্কলোড ডিপ্লয় এবং চালানোর কাজ অটোমেট করতে পারেন, এবং কুবারনেটিস যেভাবে এই কাজগুলো করে, তাও অটোমেট করতে পারেন।

কুবারনেটিসের অপারেটর প্যাটার্ন ধারণাটি আপনাকে ক্লাস্টারের আচরণ বাড়ানোর সুযোগ দেয়, কুবারনেটিসের মূল কোড পরিবর্তন না করেই
এটি কন্ট্রোলার এক বা একাধিক কাস্টম রিসোর্সের সঙ্গে সংযুক্ত করে এই কাজটি সম্পন্ন করে। অপারেটর হলো কুবারনেটিস API-এর ক্লায়েন্ট, যা
কাস্টম রিসোর্স
এর জন্য কন্ট্রোলারের ভূমিকা পালন করে।

অপারেটরের একটি উদাহরণ

অপারেটর ব্যবহার করে আপনি যেসব কাজ অটোমেট করতে পারেন, তার মধ্যে রয়েছে:

• চাহিদা অনুযায়ী কোনো অ্যাপ্লিকেশন ডিপ্লয় করা
• অ্যাপ্লিকেশনের অবস্থা সংরক্ষণ (ব্যাকআপ) এবং পুনরুদ্ধার করা
• অ্যাপ্লিকেশন কোড আপগ্রেড করা, সাথে সংশ্লিষ্ট পরিবর্তন যেমন
  ডাটাবেস স্কিমা বা অতিরিক্ত কনফিগারেশন সেটিংস পরিচালনা করা
• কুবারনেটিসের API সাপোর্ট করে সার্ভিস খুঁজে পায় না, এমন অ্যাপ্লিকেশনগুলির জন্য একটি সার্ভিস প্রকাশ করা
• ক্লাস্টারের সম্পূর্ণ বা আংশিক ব্যর্থতা অনুকরণ করে তার স্থিতিশীলতা পরীক্ষা করা
• অভ্যন্তরীণ সদস্য নির্বাচন প্রক্রিয়া ছাড়াই একটি ডিসট্রিবিউটেড অ্যাপ্লিকেশনের জন্য লিডার নির্বাচন করা

অপারেটর কেমন দেখতে হতে পারে? একটি অপারেটরের বিস্তারিত উদাহরণ এখানে দেওয়া হলো:

1. SampleDB নামের একটি কাস্টম রিসোর্স আপনি ক্লাস্টারে কনফিগার করতে পারেন।
2. একটি ডিপ্লয়মেন্ট নিশ্চিত করে যে অপারেটরের কন্ট্রোলার অংশ চালানোর জন্য একটি পড সবসময় সক্রিয় রয়েছে।
3. অপারেটর কোডের একটি কন্টেইনার ইমেজ।
4. কন্ট্রোলার কোডই কন্ট্রোল প্লেনকে জিজ্ঞাসা করে, যে কোন SampleDB রিসোর্স কনফিগার করা হয়েছে কিনা ।
5. অপারেটরের মূল কাজ হলো এপিআই সার্ভারকে নির্দেশ দেওয়া, যাতে কনফিগার করা রিসোর্স অনুযায়ী বাস্তবতা তৈরি হয়।
   • যদি আপনি নতুন SampleDB যোগ করেন, তাহলে অপারেটর PersistentVolumeClaims তৈরি করে ডাটাবেস স্টোরেজ নিশ্চিত করে, StatefulSet তৈরি করে SampleDB চালানোর জন্য এবং প্রাথমিক কনফিগারেশনের জন্য একটি Job সেটআপ করে।
   • যদি আপনি এটি ডিলিট করে ফেলেন, তাহলে অপারেটর প্রথমে একটি স্ন্যাপশট নেয়, তারপর StatefulSet এবং ভলিউম ডিলিট করা নিশ্চিত করে ।
6. অপারেটর নিয়মিত ডাটাবেস ব্যাকআপও পরিচালনা করে।
   প্রতিটি SampleDB রিসোর্সের জন্য অপারেটর নির্ধারণ করে কখন একটি পড তৈরি করতে হবে,
   যা ডাটাবেসের সাথে সংযুক্ত হয়ে ব্যাকআপ নিতে পারে।
   এই পডগুলো ConfigMap এবং / অথবা Secret ব্যবহার করে, যেখানে ডাটাবেসের সংযোগের বিবরণ ও
   অন্যান্য তথ্য সংরক্ষিত থাকে।
7. অপারেটর ব্যবস্থাপিত রিসোর্সের জন্য আরও উন্নত অটোমেশন সরবরাহ করতে পারে।
   যেমন, যদি এটি দেখে যে ডাটাবেসটি পুরোনো সংস্করণ চালাচ্ছে,
   তাহলে এটি Job অবজেক্ট তৈরি করে স্বয়ংক্রিয়ভাবে আপগ্রেড করে দিতে পারে।

অপারেটর ডিপ্লয় করা

অপারেটর ডিপ্লয় করার সবচেয়ে সাধারণ উপায় হলো
Custom Resource Definition (CRD) এবং এর সাথে সম্পর্কিত কন্ট্রোলার ক্লাস্টারে যোগ করা। কন্ট্রোলার সাধারণত কন্ট্রোল প্লেন এর বাইরে চলে, ঠিক যেমন আপনি অন্য কোনো কন্টেইনারাইজড অ্যাপ চালান।
উদাহরণস্বরূপ, আপনি ক্লাস্টারের ভেতর একটি ডিপ্লয়মেন্ট হিসেবে কন্ট্রোলার চালাতে পারেন।

অপারেটর ব্যবহার করা

একবার আপনার একটি অপারেটর ডিপ্লয় হয়ে গেলে, আপনি অপারেটর যে ধরণের রিসোর্স ব্যবহার করে তা যোগ, সংশোধন বা মুছে দিয়ে এটি ব্যবহার করবেন। উপরের উদাহরণটি অনুসরণ করে, আপনি নিজেই অপারেটরের জন্য একটি ডিপ্লয়মেন্ট সেট আপ করবেন এবং তারপর:

kubectl get SampleDB                   # find configured databases  

kubectl edit SampleDB/example-database  # manually change some settings

...এবং এটাই! অপারেটর স্বয়ংক্রিয়ভাবে পরিবর্তনগুলো প্রয়োগ করবে এবং বিদ্যমান সার্ভিস ঠিকঠাক চালিয়ে যাবে।

নিজের অপারেটর লেখা

আপনার কাঙ্ক্ষিত আচরণ বাস্তবায়নের জন্য যদি বিদ্যমান অপারেটর না থাকে, তাহলে আপনি নিজেই একটি অপারেটর তৈরি করতে পারেন।

আপনি যে কোনো প্রোগ্রামিং ভাষা বা রানটাইম ব্যবহার করে একটি অপারেটর (অর্থাৎ, কন্ট্রোলার) লিখতে পারেন,
যা কুবারনেটিস API-এর ক্লায়েন্ট হিসেবে কাজ করতে সক্ষম।

নিম্নে কিছু লাইব্রেরি ও টুলের তালিকা দেওয়া হলো,
যা ব্যবহার করে আপনি নিজস্ব ক্লাউড নেটিভ অপারেটর তৈরি করতে পারেন।

• Charmed Operator Framework
• Java Operator SDK
• Kopf (Kubernetes Operator Pythonic Framework)
• kube-rs (Rust)
• kubebuilder
• KubeOps (.NET operator SDK)
• Mast
• Metacontroller
  পাশাপাশি আপনার নিজের তৈরি WebHooks ব্যবহার করতে পারেন
• Operator Framework
• shell-operator

এর পরের কি

• CNCF
  কর্তৃক প্রকাশিত অপারেটর হোয়াইট পেপার পড়ুন।
• কাস্টম রিসোর্স সম্পর্কে আরও জানুন।
• আপনার ব্যবহারের উপযোগী রেডিমেড অপারেটর খুঁজতে ভিজিট করুন
  OperatorHub.io।
• আপনার অপারেটর তৈরি করে OperatorHub.io -তে
  পাবলিশ করুন, যাতে অন্যরাও এটি ব্যবহার করতে পারে।
• অপারেটর প্যাটার্নের ধারণা প্রথম যে নিবন্ধে প্রকাশিত হয়েছিল,
  সেই CoreOS-এর আসল ব্লগ
  (সংরক্ষিত সংস্করণ) পড়ুন।
• Google Cloud-এর এই নিবন্ধটি
  পড়ুন, যেখানে অপারেটর এবং স্টেটফুল অ্যাপ তৈরির জন্য সেরা অনুশীলনগুলি তুলে ধরা হয়েছে।

13.2 - কম্পিউট, স্টোরেজ, এবং নেটওয়ার্কিং এক্সটেনশন

এই বিভাগটি আপনার ক্লাস্টারের এক্সটেনশনগুলোকে কভার করে যা কুবারনেটিসের অংশ হিসাবে আসে না। আপনি এই এক্সটেনশনগুলো আপনার ক্লাস্টারে নোডগুলোকে উন্নত করতে বা পডকে একসাথে লিঙ্ক করে এমন নেটওয়ার্ক ফ্যাব্রিক প্রদান করতে ব্যবহার করতে পারেন।

• CSI এবং FlexVolume স্টোরেজ প্লাগইন

  কন্টেইনার স্টোরেজ ইন্টারফেস (CSI) প্লাগইনগুলো নতুন ধরনের ভলিউমের জন্য সাপোর্ট সহ কুবারনেটিসকে প্রসারিত করার একটি উপায় প্রদান করে।ভলিউমগুলি টেকসই এক্সটার্নাল স্টোরেজ দ্বারা ব্যাক করা যেতে পারে, বা ক্ষণস্থায়ী স্টোরেজ প্রদান করতে পারে, অথবা তারা একটি ফাইল সিস্টেম প্যারাডাইম ব্যবহার করে তথ্যের জন্য একটি পঠনযোগ্য ইন্টারফেস অফার করতে পারে।

  কুবারনেটিস এছাড়াও FlexVolume প্লাগইনগুলোর জন্য সাপোর্ট অন্তর্ভুক্ত করে, যা কুবারনেটিস v1.23 (CSI-এর পক্ষে) থেকে অবমূল্যায়িত(deprecated) করা হয়েছে ।

  FlexVolume প্লাগইনগুলো ব্যবহারকারীদের ভলিউম প্রকারগুলো মাউন্ট করার অনুমতি দেয় যা সাধারণত কুবারনেটিস দ্বারা সাপোর্টেড নয়। আপনি যখন FlexVolume স্টোরেজের উপর নির্ভর করে এমন একটি পড চালান, তখন kubelet ভলিউম মাউন্ট করার জন্য একটি বাইনারি প্লাগইন কল করে। আর্কাইভ করা FlexVolume ডিজাইন প্রস্তাবে এই পদ্ধতির আরও বিশদ বিবরণ রয়েছে।

  The Kubernetes Volume Plugin FAQ for Storage Vendors তে স্টোরেজ প্লাগইনগুলোর সাধারণ তথ্য অন্তর্ভুক্ত রয়েছে ।

• ডিভাইস প্লাগইন

  ডিভাইস প্লাগইনগুলো একটি নোডকে নতুন নোড সুবিধাগুলি আবিষ্কার করার অনুমতি দেয় (বিল্ট-ইন নোড রিসোর্স যেমন cpu এবং মেমরি ছাড়াও), এবং তাদের অনুরোধকারী পডগুলোতে এই কাস্টম নোড-লোকাল সুবিধাগুলো সরবরাহ করে।

• নেটওয়ার্ক প্লাগইন

  একটি নেটওয়ার্ক প্লাগইন কুবারনেটিসকে বিভিন্ন নেটওয়ার্কিং টপোলজি এবং প্রযুক্তির সাথে কাজ করার অনুমতি দেয়। আপনার কুবারনেটিস ক্লাস্টারের একটি নেটওয়ার্ক প্লাগইন প্রয়োজন যাতে একটি কার্যকরী পড নেটওয়ার্ক থাকে এবং কুবারনেটিস নেটওয়ার্ক মডেলের অন্যান্য দিকগুলোকে সাপোর্ট করতে পারে ৷

  কুবারনেটিস 1.31 CNI নেটওয়ার্ক প্লাগইনগুলোর সাথে সামঞ্জস্যপূর্ণ ৷

13.3 - কুবারনেটিস API প্রসারিত করা

কাস্টম রিসোর্স হলো কুবারনেটিস API এর এক্সটেনশন। কুবারনেটিস আপনার ক্লাস্টারে কাস্টম রিসোর্স যোগ করার দুটি উপায় প্রদান করে:

• CustomResourceDefinition (CRD) মেকানিজম আপনাকে একটি API গ্রুপ, ধরনের, এবং স্কিমা দিয়ে ঘোষণামূলকভাবে একটি নতুন কাস্টম API সংজ্ঞায়িত করতে দেয় যা আপনি নির্দিষ্ট করেছেন। কুবারনেটিস কন্ট্রোল প্লেন আপনার কাস্টম রিসোর্সের স্টোরেজ পরিবেশন এবং পরিচালনা করে। CRD গুলো আপনাকে আপনার ক্লাস্টারের জন্য একটি কাস্টম API সার্ভার না লিখে এবং চালানো ছাড়াই নতুন ধরণের রিসোর্স তৈরি করতে দেয় ।
• এগ্রিগেশন লেয়ারটি প্রাইমারি API সার্ভারের পিছনে থাকে, যা একটি প্রক্সি হিসেবে কাজ করে। এই ব্যবস্থাটিকে API এগ্রিগেশন (API Aggregation)(AA) বলা হয়, যা আপনাকে আপনার নিজস্ব API সার্ভার লিখে এবং স্থাপন করার মাধ্যমে আপনার কাস্টম রিসোর্সগুলোর জন্য বিশেষায়িত বাস্তবায়ন প্রদান করতে দেয়। প্রধান API সার্ভার আপনার API সার্ভারে আপনার নির্দিষ্ট করা কাস্টম API গুলোর জন্য অনুরোধগুলো অর্পণ করে, সেগুলোকে এর সমস্ত ক্লায়েন্টদের জন্য উপলব্ধ করে৷