kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
website/content/bn/docs/concepts/extend-kubernetes/_index.md

41 KiB
Raw Blame History

title weight description feature content_type no_list
কুবারনেটিস প্রসারিত করা 999 আপনার কুবারনেটিস ক্লাস্টারের আচরণ পরিবর্তন করার বিভিন্ন উপায়।
title description
সম্প্রসারণযোগ্যতার জন্য ডিজাইন করা হয়েছে আপস্ট্রিম সোর্স কোড পরিবর্তন না করে আপনার কুবারনেটিস ক্লাস্টারে ফিচার যোগ করুন।
concept true

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

এই নির্দেশিকাটি একটি কুবারনেটিস ক্লাস্টার কাস্টমাইজ করার উপায়গুলো বর্ণনা করে ৷ এই নির্দেশিকাটি {{< glossary_tooltip text="ক্লাস্টার অপারেটরদের" term_id="cluster-operator" >}} লক্ষ্য করে বানানো যারা তাদের কুবারনেটিস ক্লাস্টারকে তাদের কাজের পরিবেশের প্রয়োজনের সাথে কীভাবে মানিয়ে নিতে হয় তা বুঝতে চায়। ডেভেলপাররা যারা সম্ভাব্য {{< glossary_tooltip text="প্ল্যাটফর্ম ডেভেলপকারী" term_id="platform-developer" >}} বা কুবারনেটিস প্রজেক্ট {{< glossary_tooltip text="কন্ট্রিবিউটরা" term_id="contributor" >}} , এক্সটেনশন পয়েন্ট (extension points) কি এবং প্যাটার্ন বিদ্যমান এর পরিচিতি হিসাবে এবং তাদের ট্রেড-অফ আর সীমাবদ্ধতা জানার জন্য এই নির্দেশিকাটিকে দরকারী হিসেবে পাবে।

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

কনফিগারেশন

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

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

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

এক্সটেনশন

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

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

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

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

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

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

{{< note >}} কুবারনেটিসের বাইরে, “webhook” শব্দটি সাধারণত অ্যাসিঙ্ক্রোনাস(asynchronous) বিজ্ঞপ্তিগুলির জন্য একটি প্রক্রিয়াকে বোঝায়, যেখানে webhook কল অন্য সিস্টেম বা উপাদানের জন্য একমুখী বিজ্ঞপ্তি হিসাবে কাজ করে। কুবারনেটিস ইকোসিস্টেমে, এমনকি সিঙ্ক্রোনাস(synchronous) HTTP কলআউটগুলোকে প্রায়ই “webhooks” হিসাবে বর্ণনা করা হয়। {{< /note >}}

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

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

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

{{< figure src="/bn/docs/concepts/extend-kubernetes/extension-points.png" alt="কুবারনেটিসের জন্য সাতটি সংখ্যাযুক্ত এক্সটেনশন পয়েন্টের প্রতীকী উপস্থাপনা" class="diagram-large" caption="কুবারনেটিস এক্সটেনশন পয়েন্ট" >}}

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

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

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

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

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

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

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

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

    kubelet পড এবং তাদের কন্টেইনারের জন্য {{< glossary_tooltip text="ভলিউম" term_id="volume" >}} মাউন্ট এবং আনমাউন্ট করে। আপনি নতুন ধরনের স্টোরেজ এবং অন্যান্য ভলিউম টাইপের জন্য সাপোর্ট যোগ করতে স্টোরেজ প্লাগইন ব্যবহার করতে পারেন।

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

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

{{< figure src="/bn/docs/concepts/extend-kubernetes/flowchart.svg" alt="প্রয়োগকারীদের জন্য ব্যবহারের ক্ষেত্র এবং নির্দেশিকা সম্পর্কে প্রশ্ন সহ ফ্লোচার্ট। সবুজ বৃত্ত হ্যাঁ নির্দেশ করে; লাল বৃত্ত না নির্দেশ করে।" class="diagram-large" caption="একটি এক্সটেনশন পদ্ধতি নির্বাচন করতে ফ্লোচার্ট গাইড" >}}

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

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

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

API এক্সটেনশন

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

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

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

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

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

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

একটি কাস্টম রিসোর্স API এবং একটি কন্ট্রোল লুপের সংমিশ্রণকে {{< glossary_tooltip term_id="controller" text="কন্ট্রোলার" >}} প্যাটার্ন বলা হয়। যদি আপনার কন্ট্রোলার একটি কাঙ্ক্ষিত অবস্থার উপর ভিত্তি করে অবকাঠামো স্থাপনকারী মানব অপারেটরের স্থান নেয়, তাহলে কন্ট্রোলারও {{< glossary_tooltip text="অপারেটর প্যাটার্ন" term_id="operator-pattern" >}} অনুসরণ করতে পারে। অপারেটর প্যাটার্ন নির্দিষ্ট অ্যাপ্লিকেশন পরিচালনা করতে ব্যবহৃত হয়; সাধারণত, এগুলো হলো এমন অ্যাপ্লিকেশন যা অবস্থা বজায় রাখে এবং সেগুলোকে কীভাবে পরিচালনা করা হয় তার যত্নের প্রয়োজন হয়৷

আপনি আপনার নিজস্ব কাস্টম 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 এবং মেমরির মতো বিল্টইনগুলো ছাড়াও) আবিষ্কার করতে দেয় ।

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

{{< glossary_tooltip text="কন্টেইনার স্টোরেজ ইন্টারফেস(Container Storage Interface)" term_id="csi" >}} (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)

{{< feature-state for_k8s_version="v1.26" state="stable" >}} Kubelet ইমেজ ক্রেডেনশিয়াল প্রোভাইডাররা হলো Kubelet এর জন্য প্লাগইন যা ডাইনামিকভাবে ইমেজ রেজিস্ট্রি ক্রেডেনশিয়ালগুলো পুনরুদ্ধার করতে পারে। কন্টেইনার ইমেজ রেজিস্ট্রি থেকে ইমেজ তোলার সময় ক্রেডেনশিয়ালগুলো ব্যবহার করা হয় যা কনফিগারেশনের সাথে মেলে।

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

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

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

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

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

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

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

{{< note >}} আপনি শুধুমাত্র একটি শিডিউলার এক্সটেন্ডার webhook এর মাধ্যমে নোড ফিল্টারিং এবং নোড অগ্রাধিকারকে প্রভাবিত করতে পারেন; webhook ইন্টিগ্রেশনের মাধ্যমে অন্যান্য এক্সটেনশন পয়েন্ট পাওয়া যায় না। {{< /note >}}

{{% heading "whatsnext" %}}