কনভেয়ার থেকে কনটেইনার: CRI-O এখন OpenShift কন্টেইনার প্ল্যাটফর্ম 4-এ ডিফল্ট।

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

সুস্পষ্ট সমাধান ছিল Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linux-এর একটি রূপ) এবং CRI-O কে স্ট্যান্ডার্ড হিসাবে ব্যবহার করা, এবং এখানে কেন...

যেহেতু কুবারনেটস এবং কন্টেইনারগুলির কাজ ব্যাখ্যা করার সময় সাদৃশ্যগুলি খুঁজে বের করার জন্য পালতোলা বিষয়টি খুব ভাল, তাই একটি উদাহরণ ব্যবহার করে CoreOS এবং CRI-O যে ব্যবসায়িক সমস্যাগুলি সমাধান করে সেগুলি সম্পর্কে কথা বলার চেষ্টা করা যাক কারচুপির ব্লক তৈরির জন্য ব্রুনেলের উদ্ভাবন. 1803 সালে, মার্ক ব্রুনেলকে ক্রমবর্ধমান ব্রিটিশ নৌবাহিনীর প্রয়োজনের জন্য 100 কারচুপির ব্লক তৈরি করার দায়িত্ব দেওয়া হয়েছিল। একটি কারচুপি ব্লক হল এক ধরণের কারচুপি যা পালগুলিতে দড়ি সংযুক্ত করতে ব্যবহৃত হয়। 19 শতকের একেবারে শুরু পর্যন্ত, এই ব্লকগুলি হাতে তৈরি করা হয়েছিল, কিন্তু ব্রুনেল উত্পাদন স্বয়ংক্রিয় করতে পরিচালিত হয়েছিল এবং মেশিন টুল ব্যবহার করে প্রমিত ব্লক তৈরি করতে শুরু করেছিল। এই প্রক্রিয়ার স্বয়ংক্রিয়তার অর্থ হল যে ফলস্বরূপ ব্লকগুলি কার্যত অভিন্ন, ভাঙা হলে সহজেই প্রতিস্থাপন করা যেতে পারে এবং প্রচুর পরিমাণে উত্পাদিত হতে পারে।

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

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

OpenShift 4 এমনভাবে তৈরি করা হয়েছে যাতে সমস্ত প্রধান ক্লাউড কম্পিউটিং প্রদানকারী, ভার্চুয়ালাইজেশন প্ল্যাটফর্ম এবং এমনকি বেয়ার মেটাল সিস্টেমের জন্য প্ল্যাটফর্মের সমগ্র জীবনচক্রে (সংস্করণ 4.X এর জন্য) সিস্টেমটিকে সুবিধাজনকভাবে আপডেট করার ক্ষমতা প্রদান করা হয়। এটি করার জন্য, বিনিময়যোগ্য উপাদানগুলির ভিত্তিতে নোডগুলি তৈরি করতে হবে। যখন একটি ক্লাস্টারের জন্য Kubernetes-এর একটি নতুন সংস্করণের প্রয়োজন হয়, তখন এটি CoreOS-এ CRI-O-এর সংশ্লিষ্ট সংস্করণও পায়। যেহেতু CRI-O সংস্করণটি সরাসরি Kubernetes-এর সাথে আবদ্ধ, তাই এটি পরীক্ষা, সমস্যা সমাধান বা সহায়তার উদ্দেশ্যে যেকোন পারমুটেশনকে ব্যাপকভাবে সহজ করে। উপরন্তু, এই পদ্ধতিটি শেষ ব্যবহারকারী এবং Red Hat-এর জন্য খরচ কমিয়ে দেয়।

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

খোলা পাত্রের জগত

পৃথিবী বহুকাল ধরে খোলা পাত্রের দিকে এগিয়ে চলেছে। কুবারনেটসে হোক বা নিম্ন স্তরে, ধারক মান উন্নয়ন প্রতিটি স্তরে উদ্ভাবনের একটি বাস্তুতন্ত্রের ফলাফল।

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

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

Red Hat এবং Google-এর প্রকৌশলীরা একটি কন্টেইনার ইঞ্জিনের বাজারের প্রয়োজন দেখেছেন যা CRI প্রোটোকলের মাধ্যমে কুবেলেটের অনুরোধগুলি গ্রহণ করতে পারে এবং উপরে উল্লিখিত OCI স্পেসিফিকেশনগুলির সাথে সামঞ্জস্যপূর্ণ কন্টেইনারগুলি প্রবর্তন করেছে৷ তাই OCID হাজির. কিন্তু মাফ করবেন, আমরা কি বলিনি যে এই উপাদানটি CRI-O কে উৎসর্গ করা হবে? আসলে এটা, শুধু মুক্তি সঙ্গে সংস্করণ 1.0 প্রকল্পটির নাম পরিবর্তন করে CRI-O রাখা হয়েছিল।

ডুমুর। 1।

CRI-O এবং CoreOS এর সাথে উদ্ভাবন

OpenShift 4 প্ল্যাটফর্ম চালু হওয়ার সাথে সাথে এটি পরিবর্তন করা হয়েছিল ধারক ইঞ্জিন, প্ল্যাটফর্মে ডিফল্টরূপে ব্যবহৃত হয়, এবং Docker CRI-O দ্বারা প্রতিস্থাপিত হয়, কুবারনেটসের সাথে সমান্তরালভাবে বিকশিত একটি কন্টেইনার চালানোর জন্য একটি ব্যয়-কার্যকর, স্থিতিশীল, সহজ এবং বিরক্তিকর পরিবেশ প্রদান করে। এটি ক্লাস্টার সমর্থন এবং কনফিগারেশনকে ব্যাপকভাবে সরল করে। কনটেইনার ইঞ্জিন এবং হোস্টের কনফিগারেশন, সেইসাথে তাদের ব্যবস্থাপনা, OpenShift 4-এর মধ্যে স্বয়ংক্রিয় হয়ে যায়।

দাঁড়াও, এটা কেমন?

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

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

প্ল্যাটফর্মে অপারেটর ব্যবহার করে, OpenShift 4 RHEL CoreOS এবং CRI-O-এর ব্যবস্থাপনায় এই নতুন দৃষ্টান্ত (সেট এবং প্রকৃত অবস্থার ধারণা ব্যবহার করে) নিয়ে এসেছে। অপারেটিং সিস্টেম এবং কন্টেইনার ইঞ্জিনের সংস্করণগুলি কনফিগার এবং পরিচালনার কাজগুলি তথাকথিত ব্যবহার করে স্বয়ংক্রিয় হয় মেশিন কনফিগার অপারেটর (MCO). MCO ক্লাস্টার অ্যাডমিনিস্ট্রেটরের কাজকে ব্যাপকভাবে সরল করে, মূলত ইনস্টলেশনের শেষ পর্যায়গুলিকে স্বয়ংক্রিয় করে, সেইসাথে পরবর্তী ইনস্টলেশন-পরবর্তী ক্রিয়াকলাপগুলি (দুই দিন অপারেশন)। এই সবই OpenShift 4 কে একটি সত্যিকারের ক্লাউড প্ল্যাটফর্ম করে তোলে। আমরা একটু পরে এটি পেতে হবে.

চলমান পাত্রে

ব্যবহারকারীরা ওপেনশিফট প্ল্যাটফর্মে CRI-O ইঞ্জিন ব্যবহার করার সুযোগ পেয়েছে টেক প্রিভিউ স্ট্যাটাসে সংস্করণ 3.7 থেকে এবং সাধারণভাবে উপলব্ধ স্থিতিতে (বর্তমানে সমর্থিত) সংস্করণ 3.9 থেকে। উপরন্তু, Red Hat ব্যাপকভাবে ব্যবহার করে উৎপাদন কাজের চাপ চালানোর জন্য CRI-O সংস্করণ 3.10 থেকে OpenShift অনলাইনে। এই সবই CRI-O-তে কাজ করা দলটিকে বৃহৎ কুবারনেটস ক্লাস্টারে গণ লঞ্চ কন্টেইনারে ব্যাপক অভিজ্ঞতা অর্জনের অনুমতি দেয়। কুবারনেটস কীভাবে CRI-O ব্যবহার করে তার একটি প্রাথমিক বোঝার জন্য, আসুন নিম্নলিখিত চিত্রটি দেখি, যা দেখায় কিভাবে স্থাপত্য কাজ করে।

ভাত। 2. কুবারনেটস ক্লাস্টারে পাত্রে কীভাবে কাজ করে

CRI-O নতুন নোড শুরু করার সময় এবং ওপেনশিফ্ট প্ল্যাটফর্মের নতুন সংস্করণ প্রকাশ করার সময় সম্পূর্ণ শীর্ষ স্তরকে সিঙ্ক্রোনাইজ করে নতুন কন্টেইনার হোস্ট তৈরিকে সহজ করে। সমগ্র প্ল্যাটফর্মের পুনর্বিবেচনা লেনদেন সংক্রান্ত আপডেট/রোলব্যাকগুলির জন্য অনুমতি দেয়, এবং কন্টেইনার টেইল কোর, কন্টেইনার ইঞ্জিন, নোড (কুবেলেট) এবং কুবারনেটস মাস্টার নোডের মধ্যে নির্ভরতার মধ্যে অচলাবস্থা প্রতিরোধ করে। নিয়ন্ত্রণ এবং সংস্করণ সহ সমস্ত প্ল্যাটফর্ম উপাদানগুলি কেন্দ্রীয়ভাবে পরিচালনা করার মাধ্যমে, রাজ্য A থেকে রাজ্য B পর্যন্ত সর্বদা একটি পরিষ্কার পথ থাকে। এটি আপডেট প্রক্রিয়াকে সহজ করে, নিরাপত্তা উন্নত করে, কর্মক্ষমতা প্রতিবেদনের উন্নতি করে এবং নতুন সংস্করণগুলির আপডেট এবং ইনস্টলেশনের খরচ কমাতে সাহায্য করে। .

প্রতিস্থাপন উপাদান শক্তি প্রদর্শন

আগেই উল্লেখ করা হয়েছে, OpenShift 4 এ কন্টেইনার হোস্ট এবং কন্টেইনার ইঞ্জিন পরিচালনা করতে মেশিন কনফিগ অপারেটর ব্যবহার করা একটি নতুন স্তরের অটোমেশন প্রদান করে যা পূর্বে Kubernetes প্ল্যাটফর্মে সম্ভব ছিল না। নতুন বৈশিষ্ট্যগুলি প্রদর্শন করতে, আমরা দেখাব কিভাবে আপনি crio.conf ফাইলে পরিবর্তন করতে পারেন৷ পরিভাষা দ্বারা বিভ্রান্ত হওয়া এড়াতে, ফলাফলের উপর ফোকাস করার চেষ্টা করুন।

প্রথমে, আসুন তৈরি করি যাকে কন্টেইনার রানটাইম কনফিগারেশন বলা হয় - কন্টেইনার রানটাইম কনফিগারেশন। এটিকে একটি Kubernetes রিসোর্স হিসেবে ভাবুন যা CRI-O-এর কনফিগারেশনের প্রতিনিধিত্ব করে। বাস্তবে, এটি MachineConfig নামক কিছুর একটি বিশেষ সংস্করণ, যা একটি ওপেনশিফট ক্লাস্টারের অংশ হিসাবে একটি RHEL CoreOS মেশিনে স্থাপন করা যেকোনো কনফিগারেশন।

ContainerRuntimeConfig নামক এই কাস্টম রিসোর্সটি ক্লাস্টার অ্যাডমিনিস্ট্রেটরদের CRI-O কনফিগার করা সহজ করার জন্য তৈরি করা হয়েছিল। এই টুলটি যথেষ্ট শক্তিশালী যে এটি শুধুমাত্র MachineConfigPool সেটিংসের উপর নির্ভর করে নির্দিষ্ট নোডগুলিতে প্রয়োগ করা যেতে পারে। এটিকে মেশিনের একটি গ্রুপ হিসাবে মনে করুন যা একই উদ্দেশ্য পরিবেশন করে।

শেষ দুটি লাইন লক্ষ্য করুন যা আমরা /etc/crio/crio.conf ফাইলে পরিবর্তন করতে যাচ্ছি। এই দুটি লাইন crio.conf ফাইলের লাইনের সাথে খুব মিল, তারা হল:

vi ContainerRuntimeConfig.yaml

উপসংহার:

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: set-log-and-pid
spec:
 machineConfigPoolSelector:
   matchLabels:
     debug-crio: config-log-and-pid
 containerRuntimeConfig:
   pidsLimit: 2048
   logLevel: debug

এখন এই ফাইলটিকে কুবারনেটস ক্লাস্টারে পুশ করা যাক এবং এটি আসলে তৈরি হয়েছে কিনা তা পরীক্ষা করা যাক। অনুগ্রহ করে মনে রাখবেন যে অপারেশনটি অন্য যেকোন কুবারনেটস রিসোর্সের মতোই একই:

oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig

উপসংহার:

NAME              AGE
set-log-and-pid   22h

একবার আমরা ContainerRuntimeConfig তৈরি করে ফেললে, কুবারনেটসকে সংকেত দেওয়ার জন্য আমাদের একটি MachineConfigPools সংশোধন করতে হবে যে আমরা ক্লাস্টারের একটি নির্দিষ্ট গ্রুপের মেশিনে এই কনফিগারেশনটি প্রয়োগ করতে চাই। এই ক্ষেত্রে আমরা মাস্টার নোডের জন্য MachineConfigPool পরিবর্তন করব:

oc edit MachineConfigPool/master

উপসংহার (স্বচ্ছতার জন্য, মূল সারাংশ বাকি আছে):

...
metadata:
 creationTimestamp: 2019-04-10T23:42:28Z
 generation: 1
 labels:
   debug-crio: config-log-and-pid
   operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...

এই মুহুর্তে, MCO ক্লাস্টারের জন্য একটি নতুন crio.conf ফাইল তৈরি করতে শুরু করে। এই ক্ষেত্রে, সম্পূর্ণ সমাপ্ত কনফিগারেশন ফাইলটি Kubernetes API ব্যবহার করে দেখা যেতে পারে। মনে রাখবেন, ContainerRuntimeConfig হল MachineConfig-এর একটি বিশেষ সংস্করণ, তাই আমরা MachineConfigs-এ প্রাসঙ্গিক লাইনগুলি দেখে ফলাফল দেখতে পারি:

oc get MachineConfigs | grep rendered

উপসংহার:

rendered-master-c923f24f01a0e38c77a05acfd631910b                  4.0.22-201904011459-dirty 2.2.0 16h
rendered-master-f722b027a98ac5b8e0b41d71e992f626                  4.0.22-201904011459-dirty 2.2.0 4m
rendered-worker-9777325797fe7e74c3f2dd11d359bc62                  4.0.22-201904011459-dirty 2.2.0 16h

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

python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid

উপসংহার:

pids_limit = 2048

এখন নিশ্চিত করা যাক যে কনফিগারেশনটি সমস্ত মাস্টার নোডে প্রয়োগ করা হয়েছে। প্রথমে আমরা ক্লাস্টারে নোডগুলির একটি তালিকা পাই:

oc get node | grep master

Output:

ip-10-0-135-153.us-east-2.compute.internal   Ready master 23h v1.12.4+509916ce1

ip-10-0-154-0.us-east-2.compute.internal     Ready master 23h v1.12.4+509916ce1

ip-10-0-166-79.us-east-2.compute.internal    Ready master 23h v1.12.4+509916ce1

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

oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’

উপসংহার:

...
pids_limit = 2048
...
log_level = "debug"
...

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

উপরের উদাহরণটি তিনটি প্রোডাকশন নোড সহ একটি ছোট ওপেনশিফট কন্টেইনার প্ল্যাটফর্ম 4 ক্লাস্টারে বা 3000 নোড সহ একটি বিশাল উত্পাদন ক্লাস্টারে পরিবর্তন করার ক্ষমতা দেখায়। যাই হোক না কেন, কাজের পরিমাণ একই হবে - এবং খুব ছোট - শুধু ContainerRuntimeConfig ফাইলটি কনফিগার করুন এবং MachineConfigPool-এ একটি লেবেল পরিবর্তন করুন৷ এবং আপনি ওপেনশিফট কন্টেইনার প্ল্যাটফর্ম 4.X এর যেকোন সংস্করণের সাথে এটি করতে পারেন যেটি কুবারনেটস তার জীবনচক্র জুড়ে চলছে।

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

উত্স: www.habr.com