পড বুঝুন, কুবারনেটিসের সবচেয়ে ছোট ডেপ্লয়বল কম্পিউট অবজেক্ট এবং উচ্চ-লেভেল অবস্ট্রাক্শন যা আপনাকে সেগুলো চালাতে সাহায্য করে ।
ওয়ার্কলোড হলো কুবারনেটিস-এ চলমান একটি অ্যাপ্লিকেশন। আপনার ওয়ার্কলোড একটি একক উপাদান বা একাধিক যা একসাথে কাজ করে, কুবারনেটিসে আপনি এটিকে pods এর একটি সেটের মধ্যে চালান। কুবারনেটিসে, একটি পড আপনার ক্লাস্টারে কন্টেইনারগুলোর চলমান একটি সেট উপস্থাপন করে৷
কুবারনেটিস পডের একটি সংজ্ঞায়িত জীবনচক্র. উদাহরণস্বরূপ, একবার আপনার ক্লাস্টারে একটি পড চলমান হলে নোড যেখানে সেই পডটি চলছে সেখানে একটি গুরুতর ত্রুটির অর্থ হলো সেই নোডের সমস্ত পড ব্যর্থ হয়েছে ৷ কুবারনেটিস ব্যর্থতার সেই লেভেলটিকে চূড়ান্ত হিসাবে বিবেচনা করে: আপনাকে পুনরুদ্ধার করার জন্য একটি নতুন পড তৈরি করতে হবে, এমনকি যদি নোডটি পরে সুস্থ হয়ে ওঠে।
যাইহোক, জীবনকে যথেষ্ট সহজ করতে, আপনাকে প্রতিটি পড সরাসরি পরিচালনা করতে হবে না। পরিবর্তে, আপনি ওয়ার্কলোড রিসোর্স ব্যবহার করতে পারেন যা আপনার পক্ষ থেকে পডের একটি সেট পরিচালনা করে। এই রিসোর্সগুলো কন্ট্রোলার কনফিগার করে যা নিশ্চিত করে যে সঠিক সংখ্যক পড চলছে, আপনার নির্দিষ্ট স্টেটের সাথে মেলে৷
কুবারনেটিস বেশ কয়েকটি বিল্ট ইন ওয়ার্কলোড রিসোর্স সরবরাহ করে:
বৃহত্তর কুবারনেটস ইকোসিস্টেমে, আপনি তৃতীয় পক্ষের ওয়ার্কলোডের রিসোর্সগুলো খুঁজে পেতে পারেন যা অতিরিক্ত আচরণ প্রদান করে। একটি কাস্টম রিসোর্স ডেফিনিশন ব্যবহার করে, আপনি যদি কুবারনেটসের মূল অংশ নয় এমন একটি নির্দিষ্ট আচরণ চান তাহলে আপনি একটি তৃতীয় পক্ষের ওয়ার্কলোডের রিসোর্স যোগ করতে পারেন । উদাহরণস্বরূপ, আপনি যদি আপনার অ্যাপ্লিকেশনের জন্য পডগুলির একটি গ্রুপ চালাতে চান কিন্তু কাজ বন্ধ করতে চান যদি না সব পডগুলো উপলব্ধ হয় (সম্ভবত কিছু উচ্চ-থ্রুপুট ডিস্ট্রিবিউট করা কাজের জন্য), তাহলে আপনি সেই ফিচারটি প্রদান করে এমন একটি এক্সটেনশন বাস্তবায়ন বা ইনস্টল করতে পারেন।
ওয়ার্কলোড ম্যানেজমেন্টের জন্য প্রতিটি API ধরণের সম্পর্কে পড়ার পাশাপাশি, আপনি কীভাবে নির্দিষ্ট কাজগুলো করতে হবে তা পড়তে পারেন:
কনফিগারেশন থেকে কোড আলাদা করার জন্য কুবারনেটিসের প্রক্রিয়া সম্পর্কে জানতে, কনফিগারেশন দেখুন।
কুবারনেটিস কীভাবে অ্যাপ্লিকেশনগুলির জন্য পডগুলো পরিচালনা করে সে সম্পর্কে পটভূমি প্রদান করে এমন দুটি সাপোর্টকারী ধারণা রয়েছে:
একবার আপনার অ্যাপ্লিকেশানটি চালু হয়ে গেলে, আপনি এটিকে একটি সার্ভিস হিসাবে ইন্টারনেটে উপলব্ধ করতে চাইতে পারেন বা, শুধুমাত্র ওয়েব অ্যাপ্লিকেশনের জন্য, একটি ইনগ্রেস ব্যবহার করে ।
পড হলো কম্পিউটিংয়ের ক্ষুদ্রতম স্থাপনযোগ্য একক যা আপনি কুবারনেটিসে তৈরি এবং পরিচালনা করতে পারেন।
একটি পড (তিমি বা মটর শুঁটির একটি পডের মতো) এক বা একাধিক কন্টেইনার এর একটি গ্রুপ , শেয়ার্ড স্টোরেজ এবং নেটওয়ার্ক রিসোর্স গুলির সাথে, এবং কন্টেইনার কীভাবে চালানো যায় তার জন্য একটি স্পেসিফিকেশন। একটি পডের সামগ্রী সর্বদা সহ-অবস্থিত এবং সহ-নির্ধারিত, এবং একটি শেয়ার্ড প্রসঙ্গে চালে। একটি পড মডেল একটি অ্যাপ্লিকেশন-নির্দিষ্ট "লজিক্যাল হোস্ট": এটিতে এক বা একাধিক অ্যাপ্লিকেশন রয়েছে কন্টেইনার যা তুলনামূলকভাবে শক্তভাবে মিলিত হয়। নন-ক্লাউড প্রেক্ষাপটে, একই ভৌত (ফিজিক্যাল) বা ভার্চুয়াল মেশিনে সঞ্চালিত অ্যাপ্লিকেশনগুলি একই লজিক্যাল হোস্টে নির্বাহিত ক্লাউড অ্যাপ্লিকেশনগুলির সাথে সাদৃশ্যপূর্ণ।
পাশাপাশি অ্যাপ্লিকেশন কন্টেইনারে, একটি পড থাকতে পারে init কন্টেইনার যেটি চলে পড স্টার্টআপের সময়। আপনি ইনজেকশনও করতে পারেন ephemeral কন্টেইনার একটি চলমান পড ডিবাগ করার জন্য।
একটি পডের শেয়ার্ড প্রসঙ্গ হল লিনাক্স নেমস্পেস(namespaces), cgroups এবং বিচ্ছিন্নতার সম্ভাব্য অন্যান্য দিক - একই জিনিস যা একটি কন্টেইনার বিচ্ছিন্ন করে। একটি পডের প্রেক্ষাপটের মধ্যে, পৃথক অ্যাপ্লিকেশন থাকতে পারে আরও উপ-বিচ্ছিন্নতা প্রয়োগ করা হয়েছে।
একটি পড শেয়ার্ড নেমস্পেস এবং শেয়ার্ড ফাইল সিস্টেম ভলিউম সহ কন্টেইনারগুলির সেটের অনুরূপ।
কুবারনেটিস ক্লাস্টারের পড প্রধানত দুটি উপায়ে ব্যবহৃত হয়:
পড যা একটি একক কন্টেইনার চালায়" এক-কন্টেইনার-প্রতি-পড" মডেলটি কুবারনেটিসের সবচেয়ে সাধারণ ব্যবহার; এই ক্ষেত্রে, আপনি একটি একক কন্টেইনারর চারপাশে একটি মোড়ক হিসাবে একটি পডকে ভাবতে পারেন; কুবারনেটিস সরাসরি কন্টেইনারগুলি পরিচালনা করার পরিবর্তে পডগুলি পরিচালনা করে।
পডগুলি যা একাধিক কন্টেইনার চালায় যা একসাথে কাজ করা দরকার একটি পড একাধিক সহ-অবস্থিত কন্টেইনার দ্বারা গঠিত একটি অ্যাপ্লিকেশনকে এনক্যাপসুলেট(encapsulate) করতে পারে যেগুলি শক্তভাবে সংযুক্ত এবং রিসোর্স ভাগ করতে হবে৷ এই সহ-অবস্থিত কন্টেইনারগুলি একটি একক সমন্বিত ইউনিট গঠন করে।
একটি একক পডে একাধিক সহ-অবস্থিত এবং সহ-পরিচালিত কন্টেইনারে গোষ্ঠীবদ্ধ করা একটি অপেক্ষাকৃত উন্নত ব্যবহারের ক্ষেত্রে। আপনার এই প্যাটার্নটি কেবলমাত্র নির্দিষ্ট ক্ষেত্রে ব্যবহার করা উচিত যেখানে আপনার কন্টেইনারে শক্তভাবে সংযুক্ত করা হয়েছে।
প্রতিলিপি প্রদানের জন্য আপনাকে একাধিক কন্টেইনার চালানোর দরকার নেই (স্থিতিস্থাপকতার জন্য বা ক্ষমতা); আপনার একাধিক প্রতিলিপি প্রয়োজন হলে, দেখুন ওয়ার্কলোড ম্যানেজমেন্ট।
নিচে একটি পডের উদাহরণ দেওয়া হল যেটিতে একটি কন্টেইনার রয়েছে যা nginx:1.14.2 ইমেজটি চালাচ্ছে।
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 লেবেলএর জন্য।
কুবারনেটিস v1.25 [stable]
আপনি যে OS-এ পড চালাতে চান তা নির্দেশ করার জন্য আপনাকে .spec.os.name যে কোনো একটি ক্ষেত্রে windows
বা linux-তে সেট করতে হবে। এই দুটিই একমাত্র অপারেটিং সিস্টেম যা এখন
কুবারনেটিস দ্বারা সমর্থিত। ভবিষ্যতে, এই তালিকা প্রসারিত করা হতে পারে।
কুবারনেটিস v1.35 -এ, এই ক্ষেত্রের জন্য আপনি যে
মান সেট করেছেন তা পডগুলির জন্য শিডিউলিং কোনও প্রভাব ফেলবে না ৷
সেট করা .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 ক্ষেত্র আপডেট করার সময়, দুই ধরনের আপডেটের
অনুমতি দেওয়া হয়:
পডগুলি তাদের উপাদান কন্টেইনারর মধ্যে ডেটা ভাগ করে নেওয়া এবং যোগাযোগ করতে সক্ষম করে।
একটি পড শেয়ার্ড স্টোরেজ ভলিউম এর একটি সেট নির্দিষ্ট করতে পারে। পডের সমস্ত কন্টেইনারে ভাগ করা ভলিউমগুলি অ্যাক্সেস করতে পারে, সেই কন্টেইনারগুলিকে ডেটা ভাগ করতে দেয় ৷ ভলিউমগুলি একটি পডের মধ্যে স্থায়ী ডেটাকে টিকে থাকার অনুমতি দেয় যদি এর মধ্যে থাকা একটি কন্টেইনারকে পুনরায় চালু করতে হয় । দেখুন স্টোরেজ কুবারনেটিস কীভাবে শেয়ার্ড স্টোরেজ প্রয়োগ করে এবং এটি পডের কাছে উপলব্ধ করে সে বিষয়ে আরও তথ্যের জন্য।
প্রতিটি পড প্রতিটি এড্রেস পরিবারের জন্য একটি একক আইপি এড্রেস বরাদ্দ করা হয় । একটি পডের
প্রতিটি কন্টেইনার আইপি এড্রেস এবং নেটওয়ার্ক পোর্ট সহ নেটওয়ার্ক
নেমস্পেস শেয়ার করে । একটি পডের ভিতরে (এবং শুধুমাত্র তখন), পডের অন্তর্গত কন্টেইনারগুলি
লোকালহোস্ট ব্যবহার করে একে অপরের সাথে যোগাযোগ করতে পারে। যখন একটি পডের কন্টেইনারগুলি পডের বাইরে এনটিটির সাথে যোগাযোগ করে,
তখন তাদের অবশ্যই সমন্বয় করতে হবে যে
তারা কীভাবে ভাগ করা নেটওয়ার্ক রিসোর্সগুলি (যেমন পোর্ট) ব্যবহার করে।
একটি পডের মধ্যে, কন্টেইনারগুলি একটি আইপি ঠিকানা এবং পোর্ট স্পেস ভাগ করে এবং
একে অপরকে লোকালহোস্ট এর মাধ্যমে খুঁজে পেতে পারে। একটি পডের কন্টেইনারগুলি যেমন 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 অবজেক্টের উল্লেখ করতে পারে না
(উদাহরণস্বরূপ, ServiceAccount,
ConfigMap,
Secret, ইত্যাদি).পডগুলি একাধিক সহযোগিতা প্রক্রিয়া (কন্টেইনার হিসাবে) সমর্থন করার জন্য ডিজাইন করা হয়েছে যা পরিষেবার একটি সমন্বিত একক গঠন করে। একটি পডের কন্টেইনারগুলি ক্লাস্টারের একই ফিজিক্যাল বা ভার্চুয়াল মেশিনে স্বয়ংক্রিয়ভাবে সহ-অবস্থিত এবং সহ-নির্ধারিত। কন্টেইনারগুলি রিসোর্স এবং নির্ভরতা ভাগ করে নিতে পারে, একে অপরের সাথে যোগাযোগ করতে পারে এবং কখন এবং কীভাবে সেগুলি বন্ধ করা হয় তা সমন্বয় করতে পারে।
কুবারনেটিস ক্লাস্টারের পড দুটি প্রধান উপায়ে ব্যবহৃত হয়:
উদাহরণস্বরূপ, আপনার কাছে একটি কন্টেইনার থাকতে পারে যেটি একটি শেয়ার্ড ভলিউমের ফাইলগুলির জন্য একটি ওয়েব সার্ভার হিসাবে কাজ করে এবং একটি পৃথক সাইডকার কন্টেইনার যা একটি দূরবর্তী উৎস থেকে সেই ফাইলগুলিকে আপডেট করে, যেমনটি নিম্নলিখিত চিত্রে রয়েছে:
কিছু পডের আছে init কন্টেইনার পাশাপাশি অ্যাপ কন্টেইনার। ডিফল্টরূপে, init কন্টেইনারগুলি অ্যাপ কন্টেইনারগুলি শুরু হওয়ার আগে চলে এবং সম্পূর্ণ হয়।
আপনার কাছে সাইডকার কন্টেইনার থাকতে পারে যেগুলি প্রধান অ্যাপ্লিকেশন পডকে সহায়ক পরিষেবা প্রদান করে (উদাহরণস্বরূপ: একটি পরিষেবা মেশ)।
কুবারনেটিস v1.33 [stable](enabled by default)ডিফল্টরূপে সক্রিয় করা হয়েছে, SidecarContainers ফিচার গেট
init কন্টেইনারগুলির জন্য আপনাকে restartPolicy: Always নির্দিষ্ট করতে দেয়।
Always পুনঃসূচনা নীতি সেট করা নিশ্চিত করে যে কন্টেইনারগুলি যেখানে আপনি এটি সেট করেছেন
সেগুলিকে sidecars হিসাবে গণ্য করা হয় যেগুলি পডের পুরো জীবনকাল চলা অবস্থায় থাকে।
যে কন্টেইনারগুলিকে আপনি স্পষ্টভাবে সাইডকার কন্টেনার
হিসাবে সংজ্ঞায়িত করেছেন সেগুলি মূল অ্যাপ্লিকেশন পডের আগে শুরু হয় এবং পড বন্ধ না
হওয়া পর্যন্ত চলমান থাকে।
একটি probe একটি ডায়াগনস্টিক যা একটি কন্টেইনার kubelet দ্বারা পর্যায়ক্রমে সম্পাদিত হয়। একটি ডায়গনিস্টিক সঞ্চালনের জন্য, kubelet বিভিন্ন ক্রিয়াকলাপ করতে পারে:
ExecAction (কন্টেইনারের রানটাইমের সাহায্যে সম্পাদিত হয়েছে)TCPSocketAction (kubelet দ্বারা সরাসরি চেক করা হয়েছে)HTTPGetAction (kubelet দ্বারা সরাসরি চেক করা হয়েছে)আপনি পডের জীবনচক্র ডকুমেন্টেশনে probes সম্পর্কে আরও পড়তে পারেন।
কুবারনেটিস কেন অন্যান্য রিসোর্সগুলিতে মোড়ানোর প্রসঙ্গটি বোঝার জন্য একটি সাধারণ পড API (যেমন স্টেটফুল সেট) বা ডিপলয়মেন্ট) তে , আপনি পূর্ববর্তী আর্ট সম্পর্কে পড়তে পারেন, যার মধ্যে রয়েছে:
কুবারনেটিস v1.29 [beta]
সাইডকার কন্টেইনার হল সেকেন্ডারি কন্টেইনার যা একই পড এর মধ্যে প্রধান অ্যাপ্লিকেশন কন্টেইনারের সাথে চলে। এই কন্টেইনারগুলি প্রাথমিক অ্যাপ্লিকেশন কোডটি সরাসরি পরিবর্তন না করেই অতিরিক্ত পরিষেবা, বা লগিং, মনিটরিং, নিরাপত্তা বা ডেটা সিঙ্ক্রোনাইজেশনের মতো কার্যকারিতা প্রদান করে প্রধান অ্যাপ্লিকেশন কন্টেইনারের কার্যকারিতা বাড়াতে বা প্রসারিত করতে ব্যবহৃত হয়।
সাধারণত, আপনার একটি পডে শুধুমাত্র একটি অ্যাপ কন্টেইনার থাকে। উদাহরণস্বরূপ, যদি আপনার কাছে একটি ওয়েব অ্যাপ্লিকেশন থাকে যার জন্য একটি লোকাল ওয়েবসার্ভার প্রয়োজন, লোকাল ওয়েব সার্ভারটি একটি সাইডকার এবং ওয়েব অ্যাপ্লিকেশনটি নিজেই অ্যাপ কন্টেইনার৷
কুবারনেটিস একটি বিশেষ ক্ষেত্রে init কন্টেইনারে; পড স্টার্টআপের পরে সাইডকারের কন্টেইনারগুলি চলমান থাকে। এই নথিটি regular init containers শব্দটি ব্যবহার করে স্পষ্টভাবে সেই কন্টেইনারগুলিকে বোঝাতে যা শুধুমাত্র পড স্টার্টআপের সময় চলে।
আপনার ক্লাস্টারে SidecarContainers
ফিচার গেট এনেবলড করা
থাকলে (কুবারনেটস v1.29 থেকে ফিচারটি ডিফল্টরূপে সক্রিয় থাকে), আপনি একটি restartPolicy নির্দিষ্ট করতে পারেন
পডের initContainers ক্ষেত্রে তালিকাভুক্ত কন্টেইনারগুলির জন্য।
এই রিস্টার্টেবল sidecar কন্টেইনারগুলি অন্যান্য init কন্টেইনার থেকে এবং
একই পডের মধ্যে প্রধান অ্যাপ্লিকেশন কন্টেইনার(গুলি) থেকে স্বাধীন।
এগুলি মূল অ্যাপ্লিকেশন কন্টেইনার এবং অন্যান্য init কন্টেইনারগুলিকে প্রভাবিত না করেই শুরু, বন্ধ
এবং পুনরায় চালু করা যেতে পারে।
আপনি একাধিক কন্টেইনারে একটি পড চালাতে পারেন যেগুলি init বা সাইডকার কন্টেইনার হিসাবে
চিহ্নিত নয়৷ এটি উপযুক্ত যদি পডের মধ্যে থাকা কন্টেইনারগুলি পডের সামগ্রিকভাবে
কাজ করার জন্য প্রয়োজন হয়, তবে আপনার কোন কন্টেইনারগুলি প্রথমে শুরু হবে বা থামবে তা নিয়ন্ত্রণ করার দরকার নেই৷
আপনি যদি কুবারনেটিসের পুরানো ভার্শনসগুলিকে সমর্থন করতে চান যা একটি কন্টেইনার-স্তরের restartPolicy
ষেত্র সমর্থন করে না তবে আপনি এটিও করতে পারেন।
এখানে দুটি কন্টেইনার সহ একটি ডেপ্লয়মেন্টের একটি উদাহরণ রয়েছে, যার মধ্যে একটি সাইডকার:
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: {}
যদি একটি init কন্টেইনার তৈরি করা হয় তার restartPolicy Always সেট করে,
তাহলে এটি শুরু হবে এবং পডের পুরো জীবনকালে চলতে থাকবে। এটি প্রধান অ্যাপ্লিকেশন
কন্টেইনারগুলি থেকে আলাদা করে সহায়ক সেবা চালানোর জন্য সহায়ক হতে পারে৷
যদি এই init কন্টেইনারের জন্য একটি readinessProbe নির্দিষ্ট করা হয়, তাহলে এর ফলাফল
পডের রেডি অবস্থা নির্ধারণ করতে ব্যবহার করা হবে।
যেহেতু এই কন্টেইনারগুলিকে init কন্টেইনার হিসাবে সংজ্ঞায়িত করা হয়, তাই তারা অন্যান্য init কন্টেইনারগুলির মতো একই ক্রম এবং অনুক্রমিক গ্যারান্টি থেকে উপকৃত হয়, যাতে সেগুলিকে জটিল পড ইনিশিয়ালাইজেশন প্রবাহে অন্যান্য init কন্টেইনার মিশ্রিত করা যায়।
রেগুলার init কন্টেইনারগুলির তুলনায়, initContainers-এর মধ্যে সংজ্ঞায়িত সাইডকারগুলি
শুরু হওয়ার পরে চলতে থাকে। এটি গুরুত্বপূর্ণ যখন একটি পডের জন্য .spec.initContainers
এর ভিতরে একাধিক এন্ট্রি থাকে। একটি সাইডকার-স্টাইলের init কন্টেইনার চালু হওয়ার পরে (কুবেলেট (kubelet)
সেই init কন্টেইনারের জন্য start স্ট্যাটাসটিকে সত্যে সেট করেছে), কুবেলেট (kubelet) তারপর অর্ডারকৃত
.spec.initContainers তালিকা থেকে পরবর্তী init কন্টেইনার শুরু করে।
সেই স্ট্যাটাসটি হয় সত্য হয়ে যায় কারণ কন্টেইনারে একটি প্রক্রিয়া চলছে এবং কোনো স্টার্টআপ
প্রোব (probe) সংজ্ঞায়িত করা হয়নি, অথবা এর startupProbe সফল হওয়ার ফলে।
Pod টার্মিনেশন হওয়ার পরে, kubelet প্রধান অ্যাপ্লিকেশন কন্টেইনার সম্পূর্ণরূপে বন্ধ না হওয়া পর্যন্ত সাইডকার কন্টেইনার বন্ধ করা স্থগিত করে। সাইডকার কন্টেইনারগুলি তখন পড স্পেসিফিকেশনে তাদের উপস্থিতির বিপরীত ক্রমে বন্ধ করা হয়। এই পদ্ধতিটি নিশ্চিত করে যে সাইডকারগুলি সচল থাকে, পডের মধ্যে অন্যান্য কন্টেইনার সাপোর্ট করে, যতক্ষণ না তাদের সার্ভিসের আর প্রয়োজন হয় না।
আপনি যদি কুবারনেটস-স্টাইলের init কন্টেইনার ব্যবহার করে সাইডকার ব্যবহার করে এমন একটি জব (job) ডিফাইন করেন, তবে প্রতিটি পডের সাইডকার কন্টেইনার মূল কন্টেইনার শেষ হওয়ার পরে কাজটি সম্পূর্ণ হতে বাধা দেয় না।
এখানে দুটি কন্টেইনার সহ একটি কাজের উদাহরণ রয়েছে, যার মধ্যে একটি সাইডকার:
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 কন্টেইনার থেকে ভিন্ন, সাইডকার কন্টেইনার সমর্থন probe নিয়ন্ত্রণ করতে তাদের জীবনচক্র।
সাইডকার কন্টেইনারগুলি প্রধান অ্যাপ্লিকেশন কন্টেইনারগুলির সাথে সরাসরি ইন্টারঅ্যাক্ট করতে পারে, কারণ init কন্টেইনারগুলির মতো তারা সবসময় একই নেটওয়ার্ক ভাগ করে এবং ঐচ্ছিকভাবে ভলিউম (ফাইলসিস্টেম) ভাগ করতে পারে।
Init কন্টেইনারগুলি মূল পাত্রে শুরু হওয়ার আগে বন্ধ হয়ে যায়, তাই init কন্টেইনারগুলি একটি Pod-এ
অ্যাপ কন্টেইনারের সাথে মেসেজেস বিনিময় করতে পারে না। যে কোনো ডেটা পাসিং একমুখী হয়
(উদাহরণস্বরূপ, একটি init কন্টেইনার একটি emptyDir ভলিউমের মধ্যে তথ্য রাখতে পারে)।
init, sidecar এবং অ্যাপ কন্টেইনারগুলির জন্য কার্যকর করার আদেশ দেওয়া হলে, সম্পদ ব্যবহারের জন্য নিম্নলিখিত নিয়মগুলি প্রযোজ্য:
কার্যকর পড অনুরোধ এবং সীমার উপর ভিত্তি করে কোটা এবং সীমা প্রয়োগ করা হয়।
লিনাক্সে, পড লেভেল কন্ট্রোল গ্রুপের (cgroups) জন্য রিসোর্স বরাদ্দ করা হয় কার্যকর পড রিকোয়েস্ট এবং লিমিট উপর ভিত্তি করে, যেমন শিডিউলারের মতো।
কুবারনেটিস বিভিন্ন বিল্ট ইন API দেয় ঘোষণামূলক ম্যানেজমেন্ট ওয়ার্কলোড এবং ওয়ার্কলোডের উপাদানের জন্য।
অবশেষে, আপনার অ্যাপ্লিকেশন পডের মধ্যে রান হয় কন্টেইনার হিসেবে; যাইহোক, একক পড ম্যানেজ করা কষ্টসাধ্য। উদাহরণস্বরূপ, যদি একটি পড ব্যর্থ হয়, আপনি তাহলে নতুন পড চালিয়ে এটিকে রিপ্লেস করতে চাইবেন। কুবারনেটিস আপনার জন্য এটি করে দিবে।
আপনি ওয়ার্ক লোড তৈরি করার জন্য কুবারনেটিস API ব্যবহার করতে পারেন অবজেক্ট যা পড থেকে বেশি অবস্ট্রাক্শন লেভেল প্রদর্শন করে, তারপর কুবারনেটিস কন্ট্রোল প্লেন স্বয়ংক্রিয়ভাবে আপনার পক্ষ থেকে পড অবজেক্ট পরিচালনা করে, আপনার সংজ্ঞায়িত ওয়ার্কলোড অবজেক্টের স্পেসিফিকেশনের উপর ভিত্তি করে।
ওয়ার্কলোড পরিচালনার জন্য বিল্ট ইন API গুলো হলো:
ডিপ্লয়মেন্ট (এবং, পরোক্ষভাবে, রেপ্লিকাসেট), আপনার ক্লাস্টারে একটি অ্যাপ্লিকেশন চালানোর সবচেয়ে সাধারণ উপায়। ক্লাস্টারে একটি স্টেটলেস অ্যাপ্লিকেশান ওয়ার্কলোড পরিচালনা করার জন্য ডিপ্লয়মেন্ট একটি উপযুক্ত ব্যবস্থা , যেখানে ডিপ্লয়মেন্টের যেকোনো পড বিনিময়যোগ্য এবং প্রয়োজনে প্রতিস্থাপন করা যেতে পারে। (ডিপ্লয়মেন্ট হলো একটি প্রতিস্থাপন ব্যবস্থা লিগেসি ReplicationController API এর).
একটি স্টেটফুলসেট আপনাকে অনুমতি দেয় এক বা একাধিক পড পরিচালনা করার – সব একই অ্যাপ্লিকেশন কোড চালায় – যেখানে পড একটি স্বতন্ত্র পরিচয় রাখতে চায়। এটি ডিপ্লয়মেন্ট থেকে ভিন্ন যেখানে পড বিনিময়যোগ্য হয়ে থাকে । স্টেটফুলসেটের সাধারণ কাজ হলো পড এবং পারসিসটেন্ট স্টোরেজ এর মধ্যে একটি লিঙ্ক তৈরি করা। উদাহরণস্বরূপ, আপনি একটি স্টেটফুল সেট চালাতে পারেন যা প্রতিটি পডকে সংযুক্ত করে একটি PersistentVolume এর সাহায্যে।যদি স্টেটফুলসেটের একটি পডও ব্যর্থ হয়, তাহলে কুবারনেটিস একটি প্রতিস্থাপন পড তৈরি করে যা একই PersistentVolume এর সাথে সংযুক্ত থাকে।
একটি ডেমনসেট পডগুলোকে সংজ্ঞায়িত করে যা একটি নির্দিষ্ট নোড লোকাল সুবিধা প্রদান করে; উদাহরণস্বরূপ, ড্রাইভার নোডের কন্টেইনারগুলোকে স্টোরেজ সিস্টেম অ্যাক্সেস করতে দেয়। আপনি তখন ডেমনসেট ব্যবহার করতে পারেন যখন ড্রাইভার, বা অন্যান্য নোড-লেভেলের সার্ভিস,নোডে চালাতে হবে যেখানে এটি দরকারী। ডেমনসেটের প্রতিটি পড একটি ক্লাসিক Unix / POSIX সার্ভারে সিস্টেম ডেমনের মতো একই ভূমিকা পালন করে। একটি ডেমনসেট আপনার ক্লাস্টার পরিচালনার জন্য গুরুত্বপূর্ণ হতে পারে, যেমন একটি প্লাগইন নোড অ্যাক্সেস করতে দেয় ক্লাস্টার নেটওয়ার্কিং, এটি আপনাকে নোড পরিচালনা করতে সাহায্য করতে পারে, বা এটি কম সুবিধা প্রদান করতে পারে যা আপনি যে কন্টেইনার প্ল্যাটফর্মটি চালাচ্ছেন তা উন্নত করে। আপনি আপনার ক্লাস্টারের প্রতিটি নোড জুড়ে বা শুধুমাত্র একটি উপসেট জুড়ে ডেমনসেট (এবং তাদের পড) চালাতে পারেন (উদাহরণস্বরূপ, শুধুমাত্র GPU ইনস্টল করা নোডগুলিতে GPU এক্সিলারেটর ড্রাইভার ইনস্টল করুন)।
আপনি একটি Job এবং / বা একটি CronJob ব্যবহার করতে পারেন যা কাজগুলোকে চিহ্নিত করবে যা সমাপ্তির জন্য চলবে পরে থামবে। একটি Job একটি একক টাস্কের প্রতিনিধিত্ব করে, যেখানে প্রতিটি CronJob একটি শিডিউল অনুযায়ী পুনরাবৃত্তি করে।
এই বিভাগে অন্যান্য বিষয়: