কুবারনেটে অটোস্কেলিং এবং রিসোর্স ম্যানেজমেন্ট (পর্যালোচনা এবং ভিডিও রিপোর্ট)

সম্মেলনে ৮ এপ্রিল ড স্ট্রাইক 2019, "DevOps" বিভাগের অংশ হিসাবে, "Kubernetes-এ অটোস্কেলিং এবং সম্পদ ব্যবস্থাপনা" প্রতিবেদনটি দেওয়া হয়েছিল। এটি আপনার অ্যাপ্লিকেশনগুলির উচ্চ প্রাপ্যতা নিশ্চিত করতে এবং সর্বোচ্চ কর্মক্ষমতা নিশ্চিত করতে আপনি কীভাবে K8s ব্যবহার করতে পারেন সে সম্পর্কে কথা বলে।

ঐতিহ্য দ্বারা, আমরা উপস্থাপন করতে সন্তুষ্ট প্রতিবেদনের ভিডিও (44 মিনিট, নিবন্ধের চেয়ে অনেক বেশি তথ্যপূর্ণ) এবং পাঠ্য আকারে মূল সারাংশ। যাওয়া!

আসুন শব্দ দ্বারা রিপোর্টের বিষয় বিশ্লেষণ করা যাক এবং শেষ থেকে শুরু করি।

Kubernetes

ধরা যাক আমাদের হোস্টে ডকার কন্টেইনার আছে। কি জন্য? পুনরাবৃত্তিযোগ্যতা এবং বিচ্ছিন্নতা নিশ্চিত করতে, যার ফলে সহজ এবং ভাল স্থাপনার জন্য অনুমতি দেয়, CI/CD। আমাদের কনটেইনার সহ এরকম অনেক যানবাহন রয়েছে।

এই ক্ষেত্রে Kubernetes কি প্রদান করে?

1. আমরা এই মেশিনগুলি সম্পর্কে চিন্তা করা বন্ধ করি এবং "ক্লাউড" এর সাথে কাজ শুরু করি পাত্রের ক্লাস্টার বা শুঁটি (পাত্রের দল)।
2. তদুপরি, আমরা পৃথক পড সম্পর্কে চিন্তা করি না, তবে আরও পরিচালনা করিоবড় গ্রুপ। যেমন উচ্চ-স্তরের আদিম আমাদের বলার অনুমতি দিন যে একটি নির্দিষ্ট কাজের চাপ চালানোর জন্য একটি টেমপ্লেট রয়েছে এবং এটি চালানোর জন্য এখানে প্রয়োজনীয় সংখ্যক দৃষ্টান্ত রয়েছে। যদি আমরা পরবর্তীতে টেমপ্লেট পরিবর্তন করি, তাহলে সমস্ত দৃষ্টান্ত পরিবর্তিত হবে।
3. এর সাহায্যে ঘোষণামূলক API নির্দিষ্ট কমান্ডের একটি ক্রম কার্যকর করার পরিবর্তে, আমরা "বিশ্বের কাঠামো" (YAML-এ) বর্ণনা করি, যা Kubernetes দ্বারা তৈরি করা হয়েছে। এবং আবার: যখন বর্ণনা পরিবর্তিত হয়, তখন এর প্রকৃত প্রদর্শনও পরিবর্তিত হবে।

সম্পদ ব্যবস্থাপনা

সিপিইউ

আসুন সার্ভারে nginx, php-fpm এবং mysql চালাই। এই পরিষেবাগুলিতে আসলে আরও বেশি প্রক্রিয়া চলমান থাকবে, যার প্রতিটির জন্য কম্পিউটিং সংস্থান প্রয়োজন:

(স্লাইডের সংখ্যাগুলি হল "তোতাপাখি", কম্পিউটিং শক্তির জন্য প্রতিটি প্রক্রিয়ার বিমূর্ত প্রয়োজন)

এটির সাথে কাজ করা সহজ করার জন্য, প্রক্রিয়াগুলিকে গ্রুপে একত্রিত করা যৌক্তিক (উদাহরণস্বরূপ, সমস্ত nginx প্রসেস একটি গ্রুপ "nginx")। এটি করার একটি সহজ এবং সুস্পষ্ট উপায় হল প্রতিটি গ্রুপকে একটি পাত্রে রাখা:

চালিয়ে যেতে, আপনাকে মনে রাখতে হবে একটি ধারক কী (লিনাক্সে)। তাদের উপস্থিতি সম্ভব হয়েছিল কার্নেলের তিনটি মূল বৈশিষ্ট্যের জন্য ধন্যবাদ, যা অনেক আগে বাস্তবায়িত হয়েছিল: ক্ষমতা, নামব্যবধান и cgroups. এবং আরও উন্নয়ন অন্যান্য প্রযুক্তি (ডকারের মতো সুবিধাজনক "শেল" সহ):

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

আসুন এই প্রক্রিয়াগুলির জন্য CPU প্রয়োজনীয়তাগুলিতে ফিরে আসি, এবং এখন প্রক্রিয়াগুলির গ্রুপগুলির জন্য:

(আমি আবার বলছি যে সমস্ত সংখ্যা সম্পদের প্রয়োজনের একটি বিমূর্ত অভিব্যক্তি)

একই সময়ে, CPU এর নিজেই একটি নির্দিষ্ট সীমাবদ্ধ সংস্থান রয়েছে (উদাহরণে এটি 1000), যার প্রত্যেকেরই অভাব থাকতে পারে (সমস্ত গ্রুপের প্রয়োজনের যোগফল হল 150+850+460=1460)। এ ক্ষেত্রে কী হবে?

কার্নেল সম্পদ বিতরণ শুরু করে এবং এটি "মোটামুটিভাবে" করে, প্রতিটি গ্রুপকে একই পরিমাণ সম্পদ দেয়। কিন্তু প্রথম ক্ষেত্রে, তাদের মধ্যে প্রয়োজনের চেয়ে বেশি (333>150), তাই অতিরিক্ত (333-150=183) রিজার্ভ থেকে যায়, যা অন্য দুটি পাত্রে সমানভাবে বিতরণ করা হয়:

ফলস্বরূপ: প্রথম কন্টেইনারে পর্যাপ্ত সম্পদ ছিল, দ্বিতীয়টি - এটির যথেষ্ট সম্পদ ছিল না, তৃতীয়টি - এটির যথেষ্ট সম্পদ ছিল না। এটি কর্মের ফল লিনাক্সে "সৎ" সময়সূচী - CFS. অ্যাসাইনমেন্ট ব্যবহার করে এর অপারেশন সামঞ্জস্য করা যেতে পারে ওজন প্রতিটি পাত্রে। উদাহরণস্বরূপ, এই মত:

দ্বিতীয় পাত্রে (php-fpm) সম্পদের অভাবের ক্ষেত্রে দেখা যাক। সমস্ত ধারক সংস্থান প্রক্রিয়াগুলির মধ্যে সমানভাবে বিতরণ করা হয়। ফলস্বরূপ, মাস্টার প্রক্রিয়া ভালভাবে কাজ করে, কিন্তু সমস্ত কর্মী ধীর হয়ে যায়, তাদের যা প্রয়োজন তার অর্ধেকেরও কম পায়:

এইভাবে CFS শিডিউলার কাজ করে। আমরা কন্টেইনারগুলিতে যে ওজন নির্ধারণ করি তাকে আমরা আরও কল করব অনুরোধ. কেন এটি তাই - আরও দেখুন।

পুরো পরিস্থিতি অন্যদিক থেকে দেখা যাক। আপনি জানেন, সমস্ত রাস্তা রোমের দিকে নিয়ে যায়, এবং কম্পিউটারের ক্ষেত্রে, CPU-তে। একটি CPU, অনেক কাজ - আপনার একটি ট্রাফিক লাইট প্রয়োজন। সংস্থানগুলি পরিচালনা করার সবচেয়ে সহজ উপায় হল "ট্র্যাফিক লাইট": তারা একটি প্রক্রিয়াকে সিপিইউতে একটি নির্দিষ্ট অ্যাক্সেস সময় দিয়েছে, তারপরে পরবর্তীটি ইত্যাদি।

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

আসুন লিনাক্স কার্নেল এবং CPU এর সাথে এর মিথস্ক্রিয়ায় ফিরে আসি - সামগ্রিক চিত্রটি নিম্নরূপ:

cgroup এর দুটি সেটিংস রয়েছে - মূলত এগুলি দুটি সাধারণ "টুইস্ট" যা আপনাকে নির্ধারণ করতে দেয়:

1. ধারক জন্য ওজন (অনুরোধ) হয় শেয়ার;
2. কন্টেইনার টাস্কে কাজ করার জন্য মোট CPU সময়ের শতাংশ (সীমা) ভাগ.

সিপিইউ কিভাবে পরিমাপ করবেন?

বিভিন্ন উপায় আছে:

1. কি তোতা, কেউ জানে না - আপনাকে প্রতিবার আলোচনা করতে হবে।
2. সুদ পরিষ্কার, কিন্তু আপেক্ষিক: 50 কোর এবং 4 কোর সহ একটি সার্ভারের 20% সম্পূর্ণ ভিন্ন জিনিস।
3. আপনি ইতিমধ্যে উল্লিখিত বেশী ব্যবহার করতে পারেন ওজন, যা লিনাক্স জানে, কিন্তু সেগুলোও আপেক্ষিক।
4. সবচেয়ে পর্যাপ্ত বিকল্প হল কম্পিউটিং সংস্থান পরিমাপ করা সেকেন্ড. সেগুলো. রিয়েল টাইমের সেকেন্ডের তুলনায় প্রসেসর সময়ের সেকেন্ডে: প্রতি 1 রিয়েল সেকেন্ডে 1 সেকেন্ড প্রসেসর সময় দেওয়া হয়েছিল - এটি একটি সম্পূর্ণ CPU কোর।

কথা বলা আরও সহজ করার জন্য, তারা সরাসরি পরিমাপ করতে শুরু করে কার্নেল, তাদের দ্বারা অর্থ বাস্তবের তুলনায় একই CPU সময়। যেহেতু লিনাক্স ওজন বোঝে, কিন্তু এত বেশি সিপিইউ সময়/কোর নয়, তাই একটি থেকে অন্যটিতে অনুবাদ করার জন্য একটি প্রক্রিয়া প্রয়োজন ছিল।

3টি সিপিইউ কোর সহ একটি সার্ভারের একটি সাধারণ উদাহরণ বিবেচনা করা যাক, যেখানে তিনটি পডকে ওজন দেওয়া হবে (500, 1000 এবং 1500) যা সহজেই তাদের জন্য বরাদ্দ করা কোরের সংশ্লিষ্ট অংশগুলিতে রূপান্তরিত হয় (0,5, 1 এবং 1,5)।

আপনি যদি একটি দ্বিতীয় সার্ভার নেন, যেখানে দ্বিগুণ কোর (6) থাকবে এবং সেখানে একই পড রাখুন, কোরগুলির বন্টন সহজে 2 (যথাক্রমে 1, 2 এবং 3) দ্বারা গুণ করে গণনা করা যেতে পারে। কিন্তু একটি গুরুত্বপূর্ণ মুহূর্ত ঘটে যখন এই সার্ভারে একটি চতুর্থ পড উপস্থিত হয়, যার ওজন, সুবিধার জন্য, 3000 হবে৷ এটি CPU সংস্থানগুলির (অর্ধেক কোর) অংশ নিয়ে যায় এবং অবশিষ্ট পডগুলির জন্য সেগুলি পুনরায় গণনা করা হয় (অর্ধেক):

Kubernetes এবং CPU সম্পদ

কুবারনেটসে, সিপিইউ সংস্থানগুলি সাধারণত পরিমাপ করা হয় মিলিড্রাক্স, অর্থাৎ 0,001 কোরকে ভিত্তি ওজন হিসাবে নেওয়া হয়। (লিনাক্স/সিগ্রুপের পরিভাষায় একই জিনিসকে সিপিইউ শেয়ার বলা হয়, যদিও আরও স্পষ্ট করে বললে, 1000 মিলিকোর = 1024 সিপিইউ শেয়ার।) K8s নিশ্চিত করে যে এটি সার্ভারে সমস্ত পডের ওজনের যোগফলের জন্য CPU সংস্থানগুলির চেয়ে বেশি পড স্থাপন করে না।

এটা কিভাবে হয়? যখন আপনি একটি Kubernetes ক্লাস্টারে একটি সার্ভার যোগ করেন, তখন এটিতে কতগুলি CPU কোর রয়েছে তা রিপোর্ট করা হয়। এবং একটি নতুন পড তৈরি করার সময়, Kubernetes শিডিয়ুলার জানেন যে এই পডের কতগুলি কোরের প্রয়োজন হবে। এইভাবে, পডটি এমন একটি সার্ভারে বরাদ্দ করা হবে যেখানে পর্যাপ্ত কোর রয়েছে।

হলে কি হবে না অনুরোধ নির্দিষ্ট করা হয়েছে (অর্থাৎ পডের প্রয়োজনীয় কোরগুলির একটি সংজ্ঞায়িত সংখ্যা নেই)? আসুন জেনে নেওয়া যাক কিভাবে কুবারনেটস সাধারণত সম্পদ গণনা করে।

একটি পডের জন্য আপনি উভয় অনুরোধ (CFS শিডিউলার) এবং সীমা (ট্র্যাফিক লাইট মনে রাখবেন?) উল্লেখ করতে পারেন:

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

স্মৃতি

মেমরির সাথে, পরিস্থিতি অনুরূপ, কিন্তু সামান্য ভিন্ন - সর্বোপরি, এই সম্পদগুলির প্রকৃতি ভিন্ন। সাধারণভাবে, সাদৃশ্যটি নিম্নরূপ:

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

এটি সর্বদা আমাদের জন্য উপযুক্ত নয়, তাই কোন প্রক্রিয়াগুলি আমাদের জন্য গুরুত্বপূর্ণ এবং হত্যা করা উচিত নয় তা নিয়ন্ত্রণ করা সম্ভব। এটি করার জন্য, প্যারামিটার ব্যবহার করুন oom_score_adj.

আসুন CPU-এর QoS ক্লাসে ফিরে আসি এবং oom_score_adj মানগুলির সাথে একটি সাদৃশ্য আঁকি যা পডের জন্য মেমরি খরচের অগ্রাধিকার নির্ধারণ করে:

• একটি পডের জন্য সর্বনিম্ন oom_score_adj মান - -998 - এর অর্থ হল এই ধরনের একটি পড শেষ পর্যন্ত মেরে ফেলা উচিত, এটি নিশ্চিত.
• সর্বোচ্চ - 1000 - হয় সেরা প্রচেষ্টা, এই ধরনের শুঁটি প্রথমে মেরে ফেলা হয়।
• অবশিষ্ট মান গণনা করতে (burstable) একটি সূত্র আছে, যার সারমর্ম এই সত্যে ফুটে উঠেছে যে একটি পড যত বেশি সম্পদের অনুরোধ করেছে, এটিকে হত্যা করার সম্ভাবনা কম।

দ্বিতীয় "টুইস্ট" - limit_in_bytes - সীমাবদ্ধতার জন্য। এটির সাথে, সবকিছুই সহজ: আমরা কেবল সর্বাধিক পরিমাণ জারি করা মেমরি বরাদ্দ করি এবং এখানে (সিপিইউ থেকে ভিন্ন) কীভাবে এটি (মেমরি) পরিমাপ করা যায় সে সম্পর্কে কোনও প্রশ্ন নেই।

মোটে

Kubernetes প্রতিটি শুঁটি দেওয়া হয় requests и limits - CPU এবং মেমরির জন্য উভয় পরামিতি:

1. অনুরোধের উপর ভিত্তি করে, Kubernetes শিডিউলার কাজ করে, যা সার্ভারের মধ্যে পড বিতরণ করে;
2. সমস্ত পরামিতির উপর ভিত্তি করে, পডের QoS শ্রেণী নির্ধারণ করা হয়;
3. আপেক্ষিক ওজন CPU অনুরোধের উপর ভিত্তি করে গণনা করা হয়;
4. CFS সময়সূচী CPU অনুরোধের উপর ভিত্তি করে কনফিগার করা হয়;
5. OOM কিলার মেমরি অনুরোধের উপর ভিত্তি করে কনফিগার করা হয়;
6. একটি "ট্রাফিক লাইট" সিপিইউ সীমার উপর ভিত্তি করে কনফিগার করা হয়েছে;
7. মেমরি সীমার উপর ভিত্তি করে, cgroup-এর জন্য একটি সীমা কনফিগার করা হয়।

সাধারণভাবে, এই ছবিটি কুবারনেটসে সম্পদ ব্যবস্থাপনার মূল অংশটি কীভাবে ঘটে সে সম্পর্কে সমস্ত প্রশ্নের উত্তর দেয়।

অটোস্কেলিং

K8s ক্লাস্টার-অটোস্কেলার

আসুন কল্পনা করি যে পুরো ক্লাস্টারটি ইতিমধ্যেই দখল করা হয়েছে এবং একটি নতুন পড তৈরি করতে হবে। যদিও পড প্রদর্শিত হতে পারে না, এটি স্ট্যাটাসে ঝুলে থাকে বিচারাধীন. এটি প্রদর্শিত হওয়ার জন্য, আমরা ক্লাস্টারে একটি নতুন সার্ভার সংযোগ করতে পারি বা... ক্লাস্টার-অটোস্কেলার ইনস্টল করতে পারি, যা আমাদের জন্য এটি করবে: ক্লাউড প্রদানকারী থেকে একটি ভার্চুয়াল মেশিন অর্ডার করুন (একটি API অনুরোধ ব্যবহার করে) এবং এটি ক্লাস্টারের সাথে সংযুক্ত করুন , তারপর পড যোগ করা হবে.

এটি কুবারনেটস ক্লাস্টারের অটোস্কেলিং, যা দুর্দান্ত কাজ করে (আমাদের অভিজ্ঞতায়)। যাইহোক, অন্য জায়গার মতো এখানেও কিছু সূক্ষ্মতা রয়েছে...

যতক্ষণ আমরা ক্লাস্টারের আকার বাড়িয়েছি, সবকিছু ঠিক ছিল, কিন্তু ক্লাস্টার হলে কী হবে নিজেকে মুক্ত করতে লাগলো? সমস্যা হল পড মাইগ্রেট করা (হোস্ট মুক্ত করার জন্য) খুব প্রযুক্তিগতভাবে কঠিন এবং সম্পদের পরিপ্রেক্ষিতে ব্যয়বহুল। Kubernetes একটি সম্পূর্ণ ভিন্ন পদ্ধতি ব্যবহার করে।

3টি সার্ভারের একটি ক্লাস্টার বিবেচনা করুন যাতে স্থাপনা রয়েছে। এটির 6টি পড রয়েছে: এখন প্রতিটি সার্ভারের জন্য 2টি রয়েছে৷ কিছু কারণে আমরা সার্ভারগুলির একটি বন্ধ করতে চেয়েছিলাম। এটি করার জন্য আমরা কমান্ডটি ব্যবহার করব kubectl drain, যা:

• এই সার্ভারে নতুন পড পাঠানো নিষিদ্ধ করবে;
• সার্ভারে বিদ্যমান পড মুছে ফেলবে।

যেহেতু কুবারনেটস পডের সংখ্যা (6) বজায় রাখার জন্য দায়ী, এটি সহজভাবে পুনরায় তৈরি করবে সেগুলি অন্যান্য নোডগুলিতে, কিন্তু যেটি অক্ষম করা হয়েছে তার উপর নয়, যেহেতু এটি ইতিমধ্যেই নতুন পড হোস্ট করার জন্য অনুপলব্ধ হিসাবে চিহ্নিত করা হয়েছে৷ এটি কুবারনেটসের জন্য একটি মৌলিক মেকানিক।

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

MongoDB পারে die কারণ এটির একটি কোরাম প্রয়োজন: তিনটি ইনস্টলেশনের একটি ক্লাস্টারের জন্য, কমপক্ষে দুটি অবশ্যই কাজ করবে। যাইহোক, এই ঘটছে না - ধন্যবাদ PodDisruptionBudget. এই প্যারামিটারটি ন্যূনতম প্রয়োজনীয় সংখ্যক কাজের পড নির্ধারণ করে। মঙ্গোডিবি পডগুলির মধ্যে একটি আর কাজ করছে না তা জেনে এবং মঙ্গোডিবি-র জন্য PodDisruptionBudget সেট করা আছে তা জেনে minAvailable: 2, Kubernetes আপনাকে একটি পড মুছে ফেলার অনুমতি দেবে না.

নীচের লাইন: যখন ক্লাস্টার প্রকাশ করা হয় তখন পডগুলির চলাচলের (এবং প্রকৃতপক্ষে, পুনঃসৃষ্টি) সঠিকভাবে কাজ করার জন্য, PodDisruptionBudget কনফিগার করা প্রয়োজন।

অনুভূমিক স্কেলিং

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

আজ কুবারনেটসে এটি ম্যানুয়ালি করার দরকার নেই: মাপা লোড সূচকের মানগুলির উপর নির্ভর করে পডের সংখ্যায় একটি স্বয়ংক্রিয় বৃদ্ধি/কমানো কনফিগার করা হয়েছে।

এখানে প্রধান প্রশ্ন হল: ঠিক কি পরিমাপ করতে হবে и কিভাবে ব্যাখ্যা করতে হয় প্রাপ্ত মান (পড সংখ্যা পরিবর্তন করার সিদ্ধান্ত নেওয়ার জন্য)। আপনি অনেক পরিমাপ করতে পারেন:

প্রযুক্তিগতভাবে এটি কীভাবে করবেন - মেট্রিক্স ইত্যাদি সংগ্রহ করুন। — রিপোর্টে বিস্তারিত বলেছি মনিটরিং এবং কুবারনেটস. এবং সর্বোত্তম পরামিতি নির্বাচন করার জন্য প্রধান পরামর্শ হয় পরীক্ষা!

আছে পদ্ধতি ব্যবহার করুন (ব্যবহার স্যাচুরেশন এবং ত্রুটি), যার অর্থ নিম্নরূপ। কিসের ভিত্তিতে এটি স্কেল করা অর্থপূর্ণ, উদাহরণস্বরূপ, php-fpm? এর ভিত্তিতে শ্রমিকরা ফুরিয়ে যাচ্ছে ব্যবহারের. এবং যদি শ্রমিকরা শেষ হয়ে যায় এবং নতুন সংযোগ গ্রহণ না করা হয়, এটি ইতিমধ্যেই পরিপৃক্তি. এই উভয় পরামিতি পরিমাপ করা আবশ্যক, এবং মান উপর নির্ভর করে, স্কেলিং বাহিত করা আবশ্যক.

পরিবর্তে একটি উপসংহারের

প্রতিবেদনটির একটি ধারাবাহিকতা রয়েছে: উল্লম্ব স্কেলিং সম্পর্কে এবং কীভাবে সঠিক সংস্থান নির্বাচন করা যায়। আমি ভবিষ্যতে ভিডিওতে এই সম্পর্কে কথা বলতে হবে আমাদের ইউটিউব - সাবস্ক্রাইব করুন যাতে আপনি মিস করবেন না!

ভিডিও এবং স্লাইড

পারফরম্যান্স থেকে ভিডিও (44 মিনিট):

প্রতিবেদনের উপস্থাপনা:

দ্রষ্টব্য

আমাদের ব্লগে কুবারনেটস সম্পর্কে অন্যান্য প্রতিবেদন:

• «Kubernetes প্রসারিত এবং পরিপূরক» (Andrey Polovov; সেন্ট হাইলোড++ এ 8 এপ্রিল, 2019);
• «ডাটাবেস এবং কুবারনেটস» (দিমিত্রি স্টোলিয়ারভ; 8 নভেম্বর, 2018 হাইলোড++ এ);
• «মনিটরিং এবং কুবারনেটস» (দিমিত্রি স্টোলিয়ারভ; রুটকনফে 28 মে, 2018);
• «কুবারনেটস এবং গিটল্যাবের সাথে সিআই/সিডি সেরা অনুশীলন» (দিমিত্রি স্টোলিয়ারভ; 7 নভেম্বর, 2017 হাইলোড++ এ);
• «ছোট প্রকল্পে Kubernetes সঙ্গে আমাদের অভিজ্ঞতা» (দিমিত্রি স্টোলিয়ারভ; জুন 6, 2017 রুটকনফে).

উত্স: www.habr.com