এটি এই বিভাগটির বহু পৃষ্ঠার মুদ্রণযোগ্য দর্শন। মুদ্রণ করতে এখানে ক্লিক করুন.

পড

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)

ফিচার স্টেট: কুবারনেটিস v1.25 [stable]

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

কুবারনেটিস v1.32 -এ, এই ক্ষেত্রের জন্য আপনি যে মান সেট করেছেন তা পডগুলির জন্য শিডিউলিং কোনও প্রভাব ফেলবে না ৷ সেট করা .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 (লিনাক্স) ফ্লাগ ব্যবহার করে সুবিধাপ্রাপ্ত মোড সক্রিয় করতে পারে। এটি এমন কন্টেইনারগুলির জন্য দরকারী যেগুলি অপারেটিং সিস্টেমের প্রশাসনিক ক্ষমতাগুলি ব্যবহার করতে চায় যেমন নেটওয়ার্ক স্ট্যাক নিপূণভাবে ব্যবহার করা বা হার্ডওয়্যার ডিভাইসগুলি অ্যাক্সেস করা।

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

ফিচার স্টেট: কুবারনেটিস v1.26 [stable]

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

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

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

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

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

বিঃদ্রঃ:

একটি স্ট্যাটিক পডের spec অন্যান্য API অবজেক্টের উল্লেখ করতে পারে না (উদাহরণস্বরূপ, , , , ইত্যাদি).

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

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

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

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

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

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

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

ফিচার স্টেট: কুবারনেটিস v1.29 [beta]

ডিফল্টরূপে সক্রিয় করা হয়েছে, 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 (যেমন স্টেটফুল সেট) বা ডিপলয়মেন্ট) তে , আপনি পূর্ববর্তী আর্ট সম্পর্কে পড়তে পারেন, যার মধ্যে রয়েছে:

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

ফিচার স্টেট: কুবারনেটিস v1.29 [beta]

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

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

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

কুবারনেটিস একটি বিশেষ ক্ষেত্রে 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 সফল হওয়ার ফলে।

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

সাইডকার কন্টেইনারে জবস (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 সম্পর্কে জানুন।