সাইডকার কন্টেইনার
কুবারনেটিস 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: {}
সাইডকার কন্টেইনার এবং পড জীবনচক্র (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) ডিফাইন করেন, তবে প্রতিটি পডের সাইডকার কন্টেইনার মূল কন্টেইনার শেষ হওয়ার পরে কাজটি সম্পূর্ণ হতে বাধা দেয় না।
এখানে দুটি কন্টেইনার সহ একটি কাজের উদাহরণ রয়েছে, যার মধ্যে একটি সাইডকার:
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 সম্পর্কে জানুন।