Kubernetes সেরা অভ্যাস. সম্পদের অনুরোধ এবং সীমা নির্ধারণ করা

Kubernetes সেরা অভ্যাস. ছোট পাত্র তৈরি করা
Kubernetes সেরা অভ্যাস. নামস্থান সহ Kubernetes সংস্থা
Kubernetes সেরা অভ্যাস. প্রস্তুতি এবং সজীবতা পরীক্ষার সাথে কুবারনেটসের স্বাস্থ্য পরীক্ষা করা হচ্ছে

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

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

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

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

একটি পডের প্রতিটি ধারক তার নিজস্ব অনুরোধ এবং সীমা সেট করতে পারে, এটি সবই সংযোজন। প্রসেসর সম্পদ মিলিকোরে সংজ্ঞায়িত করা হয়. যদি আপনার ধারকটি চালানোর জন্য দুটি পূর্ণ কোরের প্রয়োজন হয়, তাহলে আপনি মান 2000m সেট করুন। যদি ধারকটির শুধুমাত্র 1/4 কোর শক্তির প্রয়োজন হয়, তাহলে মানটি 250m হবে। সচেতন থাকুন যে আপনি যদি সবচেয়ে বড় নোডের কোরের সংখ্যার চেয়ে বেশি একটি CPU রিসোর্স মান বরাদ্দ করেন, তাহলে আপনার পড একেবারেই শুরু হওয়ার জন্য নির্ধারিত হবে না। আপনার যদি এমন একটি পড থাকে যার জন্য চারটি কোরের প্রয়োজন হয় এবং কুবারনেটস ক্লাস্টারে শুধুমাত্র দুটি প্রধান ভার্চুয়াল মেশিন থাকে তাহলে একই পরিস্থিতি ঘটবে।

যদি না আপনার অ্যাপ্লিকেশনটি একাধিক কোরের সুবিধা নেওয়ার জন্য বিশেষভাবে ডিজাইন করা হয় (এইভাবে জটিল বৈজ্ঞানিক গণনা এবং ডাটাবেস অপারেশনের মতো প্রোগ্রামগুলি মনে আসে), তাহলে সেরা অনুশীলন হল CPU অনুরোধগুলিকে 1 বা তার নীচে সেট করা এবং তারপরে স্কেলেবিলিটির জন্য আরও প্রতিলিপি চালানো। এই সমাধানটি সিস্টেমটিকে আরও নমনীয়তা এবং নির্ভরযোগ্যতা দেবে।

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

মেমরি সম্পদ বাইট সংজ্ঞায়িত করা হয়. সাধারণত সেটিংসের মানটি Mib মেবিবাইটে পরিমাপ করা হয়, তবে আপনি এটিকে বাইট থেকে পেটাবাইটে যেকোনো মান সেট করতে পারেন। এখানে পরিস্থিতি CPU-এর মতোই - আপনি যদি আপনার নোডের মেমরির পরিমাণকে ছাড়িয়ে যায় এমন মেমরির জন্য অনুরোধ করেন, তাহলে এই পডের সম্পাদনের সময়সূচী হবে না। কিন্তু CPU সম্পদের বিপরীতে, মেমরি সংকুচিত হয় না কারণ এর ব্যবহার সীমিত করার কোনো উপায় নেই। অতএব, কন্টেইনারটি বরাদ্দকৃত মেমরি শেষ হওয়ার সাথে সাথে এটির সম্পাদন বন্ধ করা হবে।

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

একটি আদর্শ বিশ্বে, ডিফল্ট কন্টেইনার সেটিংস কর্মপ্রবাহকে মসৃণভাবে চালানোর জন্য যথেষ্ট হবে। কিন্তু বাস্তব জগৎ এমন নয়, মানুষ সহজে সম্পদের ব্যবহার সামঞ্জস্য করতে ভুলে যেতে পারে, অথবা হ্যাকাররা অবকাঠামোর প্রকৃত ক্ষমতার চেয়ে বেশি অনুরোধ এবং সীমা সেট করবে। এই ধরনের পরিস্থিতি প্রতিরোধ করতে, আপনি ResourceQuota রিসোর্স কোটা এবং LimitRange রেঞ্জ কনফিগার করতে পারেন।

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

একটি সম্পদ কোটা এই মত দেখতে হতে পারে. এই উদাহরণে, 4টি বিভাগ রয়েছে - এগুলি কোডের 4টি নীচের লাইন।

আসুন তাদের প্রতিটি তাকান. Requests.cpu হল CPU পাওয়ারের জন্য সর্বাধিক সংখ্যক সম্মিলিত অনুরোধ যা সমস্ত নেমস্পেস কন্টেইনার থেকে আসতে পারে। এই উদাহরণে, আপনার কাছে 50m অনুরোধ সহ 10টি কন্টেইনার, 100m অনুরোধ সহ পাঁচটি কন্টেনার বা 500m অনুরোধ সহ একটি কন্টেইনার থাকতে পারে। যতক্ষণ পর্যন্ত একটি প্রদত্ত নেমস্পেসের মোট requests.cpu সংখ্যা 500m এর কম হয়, সবকিছু ঠিক হয়ে যাবে।

অনুরোধ করা মেমরি requests.memory হল সর্বাধিক পরিমাণ সম্মিলিত মেমরি অনুরোধ যা নেমস্পেসের সমস্ত কন্টেইনারে থাকতে পারে। পূর্ববর্তী ক্ষেত্রের মতো, আপনার কাছে 50 2 mib কন্টেনার, পাঁচটি 20 mib কন্টেনার, অথবা একটি একক 100 mib কন্টেইনার থাকতে পারে যতক্ষণ না নেমস্পেসে অনুরোধ করা মেমরির মোট পরিমাণ 100 মেবিবাইটের কম হয়।

Limits.cpu হল প্রসেসর পাওয়ারের সর্বাধিক সম্মিলিত পরিমাণ যা সমস্ত নেমস্পেস কন্টেইনার ব্যবহার করতে পারে। আমরা অনুমান করতে পারি যে এটি প্রসেসর পাওয়ার অনুরোধের সীমা।

অবশেষে, limits.memory হল সর্বাধিক পরিমাণ শেয়ার করা মেমরি যা নেমস্পেসের সমস্ত কন্টেইনার ব্যবহার করতে পারে। এটি মোট মেমরি অনুরোধের সীমা।
সুতরাং, ডিফল্টরূপে, কুবারনেটস ক্লাস্টারের কন্টেইনারগুলি সীমাহীন কম্পিউটিং সংস্থানগুলির সাথে চালিত হয়। রিসোর্স কোটা সহ, ক্লাস্টার অ্যাডমিনিস্ট্রেটররা নেমস্পেসের উপর ভিত্তি করে রিসোর্স খরচ এবং রিসোর্স তৈরি সীমিত করতে পারে। একটি নেমস্পেসে, একটি পড বা কন্টেইনার নেমস্পেস রিসোর্স কোটা দ্বারা সংজ্ঞায়িত যতটা CPU এবং মেমরি শক্তি ব্যবহার করতে পারে। যাইহোক, একটি উদ্বেগ রয়েছে যে একটি পড বা ধারক সমস্ত উপলব্ধ সংস্থানকে একচেটিয়া করতে পারে। এই পরিস্থিতি প্রতিরোধ করার জন্য, সীমা পরিসর ব্যবহার করা হয় - নামস্থানে সম্পদের বরাদ্দ (পড বা পাত্রের জন্য) সীমিত করার নীতি।

সীমা পরিসীমা সীমা প্রদান করে যা করতে পারে:

• নামস্থানে প্রতিটি মডিউল বা কন্টেইনারের জন্য কম্পিউটিং সংস্থানগুলির সর্বনিম্ন এবং সর্বাধিক ব্যবহার নিশ্চিত করুন;
• নেমস্পেসে প্রতিটি Persistent VolumeClaim-এর জন্য একটি সর্বনিম্ন এবং সর্বোচ্চ Starage অনুরোধ প্রয়োগ করুন;
• একটি নামস্থানে একটি সম্পদের জন্য একটি অনুরোধ এবং একটি সীমার মধ্যে সম্পর্ক জোর করে;
• নামস্থানে কম্পিউট রিসোর্সের জন্য ডিফল্ট অনুরোধ/সীমা সেট করুন এবং রানটাইমে স্বয়ংক্রিয়ভাবে কন্টেইনারে ইনজেক্ট করুন।

তাই আপনি আপনার নামস্থানে একটি সীমা পরিসীমা তৈরি করতে পারেন। কোটার বিপরীতে, যা পুরো নামস্থানে প্রযোজ্য, সীমা পরিসরটি পৃথক পাত্রের জন্য ব্যবহৃত হয়। এটি ব্যবহারকারীদের একটি নামস্থানের মধ্যে ক্ষুদ্র বা দৈত্যাকার পাত্র তৈরি করতে বাধা দিতে পারে। সীমা পরিসীমা এই মত দেখতে পারে.

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

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

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

ন্যূনতম বিভাগটি ন্যূনতম অনুরোধগুলি নির্দিষ্ট করে যা একটি পডের একটি পাত্রের জন্য সেট করা যেতে পারে। যাইহোক, ডিফল্ট বিভাগে মান এবং একটি কন্টেইনারের জন্য অনুরোধ এই সীমার নিচে সেট করা যাবে না।

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

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

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

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

যেমনটি আমি বলেছি, যখন এটি CPU-তে আসে, কুবারনেটস পড সীমিত করা শুরু করবে। প্রতিটি পড যতটুকু চেয়েছে ততটুকু পাবে, কিন্তু যদি তা সীমায় না পৌঁছায়, তাহলে থ্রটলিং প্রয়োগ করা শুরু হবে।

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

আসুন এমন একটি দৃশ্যকল্প কল্পনা করি যেখানে আপনার মেমরি ফুরিয়ে যাচ্ছে - কুবারনেটস কীভাবে এটি পরিচালনা করবে?

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

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

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

Kubernetes সেরা অভ্যাস. সঠিক শাটডাউন বন্ধ

কিছু বিজ্ঞাপন 🙂

আমাদের সাথে থাকার জন্য আপনাকে ধন্যবাদ. আপনি আমাদের নিবন্ধ পছন্দ করেন? আরো আকর্ষণীয় বিষয়বস্তু দেখতে চান? অর্ডার দিয়ে বা বন্ধুদের সুপারিশ করে আমাদের সমর্থন করুন, $4.99 থেকে বিকাশকারীদের জন্য ক্লাউড ভিপিএস, এন্ট্রি-লেভেল সার্ভারগুলির একটি অনন্য অ্যানালগ, যা আমাদের দ্বারা আপনার জন্য উদ্ভাবিত হয়েছে: VPS (KVM) E5-2697 v3 (6 কোর) 10GB DDR4 480GB SSD 1Gbps থেকে $19 বা কিভাবে একটি সার্ভার শেয়ার করবেন সম্পর্কে সম্পূর্ণ সত্য? (RAID1 এবং RAID10 এর সাথে উপলব্ধ, 24 কোর পর্যন্ত এবং 40GB DDR4 পর্যন্ত)।

আমস্টারডামের ইকুইনিক্স টায়ার IV ডেটা সেন্টারে ডেল R730xd 2x সস্তা? শুধু এখানে 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 টিভি $199 থেকে নেদারল্যান্ডে! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 থেকে! সম্পর্কে পড়ুন কিভাবে ইনফ্রাস্ট্রাকচার কর্পোরেশন তৈরি করা যায়। এক পয়সার জন্য 730 ইউরো মূল্যের Dell R5xd E2650-4 v9000 সার্ভার ব্যবহার করে ক্লাস?

উত্স: www.habr.com