কুবারনেটে CPU সীমা এবং আক্রমণাত্মক থ্রটলিং

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

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

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

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

নিবন্ধের সংক্ষিপ্তসার:

• পাত্রে এবং কুবারনেটস সম্পর্কে কয়েকটি শব্দ;
• কিভাবে CPU অনুরোধ এবং সীমা বাস্তবায়ন করা হয়;
• মাল্টি-কোর পরিবেশে কিভাবে CPU সীমা কাজ করে;
• কিভাবে CPU থ্রটলিং ট্র্যাক করবেন;
• সমস্যার সমাধান এবং সূক্ষ্মতা।

পাত্রে এবং কুবারনেটস সম্পর্কে কয়েকটি শব্দ

Kubernetes মূলত অবকাঠামো বিশ্বের আধুনিক মান. এর প্রধান কাজ হল কন্টেইনার অর্কেস্ট্রেশন।

পাত্রে

অতীতে, সার্ভারে চালানোর জন্য আমাদের জাভা JARs/WARs, Python Eggs বা এক্সিকিউটেবলের মতো শিল্পকর্ম তৈরি করতে হয়েছিল। যাইহোক, এগুলিকে কার্যকর করার জন্য, অতিরিক্ত কাজ করতে হয়েছিল: রানটাইম পরিবেশ (জাভা/পাইথন) ইনস্টল করা, প্রয়োজনীয় ফাইলগুলি সঠিক জায়গায় স্থাপন করা, অপারেটিং সিস্টেমের একটি নির্দিষ্ট সংস্করণের সাথে সামঞ্জস্যতা নিশ্চিত করা ইত্যাদি। অন্য কথায়, কনফিগারেশন ম্যানেজমেন্টে (যা প্রায়শই ডেভেলপার এবং সিস্টেম অ্যাডমিনিস্ট্রেটরদের মধ্যে বিবাদের উৎস ছিল) সতর্ক মনোযোগ দিতে হয়েছিল।

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

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

Kubernetes

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

সাধারণ মানুষের দৃষ্টিকোণ থেকে কুবারনেটস

Kubernetes এ অনুরোধ এবং সীমা কি কি

ঠিক আছে, আমরা কন্টেইনার এবং কুবারনেটস কভার করেছি। আমরা আরও জানি যে একই মেশিনে একাধিক পাত্রে থাকতে পারে।

একটি সাম্প্রদায়িক অ্যাপার্টমেন্ট সঙ্গে একটি উপমা আঁকা যেতে পারে। একটি প্রশস্ত প্রাঙ্গণ (মেশিন/ইউনিট) নেওয়া হয় এবং বেশ কয়েকটি ভাড়াটেদের (পাত্রে) ভাড়া দেওয়া হয়। কুবারনেটস একটি রিয়েলটর হিসাবে কাজ করে। প্রশ্ন উঠছে, ভাড়াটিয়াদের একে অপরের সাথে দ্বন্দ্ব থেকে কীভাবে রক্ষা করবেন? যদি তাদের মধ্যে একজন বলে, অর্ধেক দিনের জন্য বাথরুম ধার করার সিদ্ধান্ত নেয়?

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

কিভাবে অনুরোধ এবং সীমা Kubernetes বাস্তবায়িত হয়

কুবারনেটস সিপিইউ সীমা বাস্তবায়নের জন্য কার্নেলের মধ্যে নির্মিত একটি থ্রোটলিং মেকানিজম (ঘড়ির চক্র এড়িয়ে যাওয়া) ব্যবহার করে। যদি একটি অ্যাপ্লিকেশন সীমা অতিক্রম করে, থ্রটলিং সক্ষম করা হয় (অর্থাৎ এটি কম CPU চক্র গ্রহণ করে)। মেমরির জন্য অনুরোধ এবং সীমা আলাদাভাবে সংগঠিত হয়, তাই সেগুলি সনাক্ত করা সহজ। এটি করার জন্য, শুধু পডের শেষ রিস্টার্ট স্ট্যাটাস চেক করুন: এটি "OOMKilled" কিনা। CPU থ্রটলিং এত সহজ নয়, যেহেতু K8s শুধুমাত্র মেট্রিক্স ব্যবহার করে উপলব্ধ করে, cgroups দ্বারা নয়।

CPU অনুরোধ

কিভাবে CPU অনুরোধ বাস্তবায়ন করা হয়

সরলতার জন্য, আসুন উদাহরণ হিসাবে 4-কোর CPU সহ একটি মেশিন ব্যবহার করে প্রক্রিয়াটি দেখি।

সম্পদের বরাদ্দ (মেমরি এবং প্রসেসর) নিয়ন্ত্রণ করতে K8s একটি কন্ট্রোল গ্রুপ মেকানিজম (cgroups) ব্যবহার করে। এটির জন্য একটি অনুক্রমিক মডেল উপলব্ধ: শিশুটি পিতামাতার গোষ্ঠীর সীমার উত্তরাধিকারী হয়। বিতরণের বিবরণ একটি ভার্চুয়াল ফাইল সিস্টেমে সংরক্ষণ করা হয় (/sys/fs/cgroup) একটি প্রসেসরের ক্ষেত্রে এটি হয় /sys/fs/cgroup/cpu,cpuacct/*.

K8s ফাইল ব্যবহার করে cpu.share প্রসেসর সম্পদ বরাদ্দ করতে. আমাদের ক্ষেত্রে, রুট cgroup CPU সম্পদের 4096 শেয়ার পায় - উপলব্ধ প্রসেসর পাওয়ারের 100% (1 কোর = 1024; এটি একটি নির্দিষ্ট মান)। মূল গোষ্ঠী নিবন্ধিত বংশধরদের শেয়ারের উপর নির্ভর করে আনুপাতিকভাবে সম্পদ বিতরণ করে cpu.share, এবং তারা, ঘুরে, তাদের বংশধরদের সাথে একই কাজ করে, ইত্যাদি। একটি সাধারণ কুবারনেটস নোডে, রুট সিগ্রুপের তিনটি সন্তান রয়েছে: system.slice, user.slice и kubepods. প্রথম দুটি সাবগ্রুপগুলি K8 এর বাইরে ক্রিটিক্যাল সিস্টেম লোড এবং ব্যবহারকারী প্রোগ্রামগুলির মধ্যে সংস্থান বিতরণ করতে ব্যবহৃত হয়। সর্বশেষ - kubepods — কুবারনেটস দ্বারা পডের মধ্যে সংস্থান বিতরণ করার জন্য তৈরি করা হয়েছে।

উপরের চিত্রটি দেখায় যে প্রথম এবং দ্বিতীয় উপগোষ্ঠী প্রতিটি পেয়েছে 1024 শেয়ার, kuberpod উপগোষ্ঠীর সাথে বরাদ্দ করা হয়েছে 4096 শেয়ার এটি কীভাবে সম্ভব: সর্বোপরি, রুট গ্রুপের কেবল অ্যাক্সেস রয়েছে 4096 শেয়ার, এবং তার বংশধরদের শেয়ারের যোগফল উল্লেখযোগ্যভাবে এই সংখ্যা ছাড়িয়ে গেছে (6144)? বিন্দু হল যে মানটি যৌক্তিক অর্থে তৈরি করে, তাই লিনাক্স শিডিউলার (CFS) এটিকে আনুপাতিকভাবে CPU সম্পদ বরাদ্দ করতে ব্যবহার করে। আমাদের ক্ষেত্রে, প্রথম দুটি গ্রুপ গ্রহণ 680 প্রকৃত শেয়ার (16,6-এর 4096%), এবং কুবেপড অবশিষ্টাংশ পায় 2736 শেয়ার ডাউনটাইমের ক্ষেত্রে, প্রথম দুটি গ্রুপ বরাদ্দকৃত সম্পদ ব্যবহার করবে না।

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

এই প্রক্রিয়াটি প্রসেসরের শক্তির একটি ন্যায্য বন্টন নিশ্চিত করে এবং নিশ্চিত করে যে কেউ অন্যের কাছ থেকে সম্পদ "চুরি" করে না।

CPU সীমা

K8 এ সীমা এবং অনুরোধের কনফিগারেশন একই রকম হওয়া সত্ত্বেও, তাদের বাস্তবায়ন আমূল ভিন্ন: এটি সবচেয়ে বিভ্রান্তিকর এবং সর্বনিম্ন নথিভুক্ত অংশ।

K8s জড়িত সিএফএস কোটা প্রক্রিয়া সীমা বাস্তবায়ন করতে। তাদের সেটিংস ফাইলগুলিতে নির্দিষ্ট করা আছে cfs_period_us и cfs_quota_us cgroup ডিরেক্টরিতে (ফাইলটিও সেখানে অবস্থিত cpu.share).

অসদৃশ cpu.share, কোটার উপর ভিত্তি করে সময় কাল, এবং উপলব্ধ প্রসেসর শক্তিতে নয়। cfs_period_us সময়কালের সময়কাল (যুগ) নির্দিষ্ট করে - এটি সর্বদা 100000 μs (100 ms)। K8s-এ এই মান পরিবর্তন করার একটি বিকল্প আছে, কিন্তু এটি আপাতত শুধুমাত্র আলফাতে উপলব্ধ। ব্যবহৃত কোটা পুনরায় আরম্ভ করতে সময়সূচী epoch ব্যবহার করে। দ্বিতীয় ফাইল cfs_quota_us, প্রতিটি যুগে উপলব্ধ সময় (কোটা) নির্দিষ্ট করে। নোট করুন যে এটি মাইক্রোসেকেন্ডে নির্দিষ্ট করা হয়েছে। কোটা যুগের দৈর্ঘ্য অতিক্রম করতে পারে; অন্য কথায়, এটি 100 ms এর বেশি হতে পারে।

আসুন 16-কোর মেশিনে দুটি পরিস্থিতি দেখি (ওমিওতে আমাদের কাছে সবচেয়ে সাধারণ ধরনের কম্পিউটার):

দৃশ্যকল্প 1: 2 থ্রেড এবং একটি 200 ms সীমা। কোন থ্রটলিং

দৃশ্যকল্প 2: 10 থ্রেড এবং 200 ms সীমা। থ্রটলিং 20 ms পরে শুরু হয়, প্রসেসর সংস্থানগুলিতে অ্যাক্সেস আরও 80 ms পরে পুনরায় শুরু হয়

ধরা যাক আপনি CPU সীমা সেট করেছেন 2 কার্নেল; Kubernetes এই মানটিকে 200 ms এ অনুবাদ করবে। এর মানে হল যে ধারকটি থ্রটলিং ছাড়াই সর্বাধিক 200ms CPU সময় ব্যবহার করতে পারে৷

আর এখান থেকেই মজা শুরু হয়। উপরে উল্লিখিত হিসাবে, উপলব্ধ কোটা হল 200 ms। আপনি যদি সমান্তরালভাবে কাজ করছেন দশ একটি 12-কোর মেশিনে থ্রেড (দৃশ্য 2 এর চিত্র দেখুন), অন্যান্য সমস্ত পড নিষ্ক্রিয় থাকাকালীন, কোটা মাত্র 20 মিসে শেষ হয়ে যাবে (যেহেতু 10 * 20 ms = 200 ms), এবং এই পডের সমস্ত থ্রেড ঝুলবে » (থ্রোটল) পরবর্তী 80 ms এর জন্য ইতিমধ্যে উল্লেখ করা হয়েছে সময়সূচী বাগ, যার কারণে অতিরিক্ত থ্রটলিং ঘটে এবং কন্টেইনারটি বিদ্যমান কোটাও পূরণ করতে পারে না।

কিভাবে পড মধ্যে থ্রটলিং মূল্যায়ন?

শুধু পডে লগইন করুন এবং চালান cat /sys/fs/cgroup/cpu/cpu.stat.

• nr_periods - নির্ধারিত সময়ের মোট সংখ্যা;
• nr_throttled — রচনায় থ্রটলড পিরিয়ডের সংখ্যা nr_periods;
• throttled_time — ন্যানোসেকেন্ডে ক্রমবর্ধমান থ্রটলড সময়।

আসলে কি হচ্ছে?

ফলস্বরূপ, আমরা সমস্ত অ্যাপ্লিকেশনে উচ্চ থ্রটলিং পাই। মাঝে মাঝে সে ভিতরে থাকে দেড় বার হিসাবের চেয়ে শক্তিশালী!

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

সিদ্ধান্ত এবং ফলাফল

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

HTTP 5xx ত্রুটি

একটি গুরুত্বপূর্ণ পরিষেবার জন্য HTTP 5xx ত্রুটি৷

প্রতিক্রিয়া সময় p95

ক্রিটিক্যাল সার্ভিস রিকোয়েস্ট লেটেন্সি, 95ম পার্সেন্টাইল

অপারেটিং খরচ

সময় ব্যয় করা উদাহরণের সংখ্যা

ধরাটা কী?

নিবন্ধের শুরুতে যেমন বলা হয়েছে:

একটি সাম্প্রদায়িক অ্যাপার্টমেন্টের সাথে একটি সাদৃশ্য আঁকা যেতে পারে... কুবারনেটস একজন রিয়েলটর হিসাবে কাজ করে। তবে কীভাবে ভাড়াটেদের একে অপরের সাথে দ্বন্দ্ব থেকে রক্ষা করবেন? যদি তাদের মধ্যে একজন বলে, অর্ধেক দিনের জন্য বাথরুম ধার করার সিদ্ধান্ত নেয়?

এখানে ধরা আছে. একটি অসতর্ক ধারক একটি মেশিনে উপলব্ধ সমস্ত CPU সম্পদ খেয়ে ফেলতে পারে। আপনার যদি একটি স্মার্ট অ্যাপ্লিকেশন স্ট্যাক থাকে (উদাহরণস্বরূপ, JVM, Go, Node VM সঠিকভাবে কনফিগার করা আছে), তাহলে এটি কোনও সমস্যা নয়: আপনি এই ধরনের পরিস্থিতিতে দীর্ঘ সময়ের জন্য কাজ করতে পারেন। কিন্তু যদি অ্যাপ্লিকেশনগুলি খারাপভাবে অপ্টিমাইজ করা হয় বা একেবারেই অপ্টিমাইজ করা না হয় (FROM java:latest), পরিস্থিতি নিয়ন্ত্রণের বাইরে চলে যেতে পারে। Omio-তে আমাদের প্রধান ভাষা স্ট্যাকের জন্য পর্যাপ্ত ডিফল্ট সেটিংস সহ স্বয়ংক্রিয় বেস ডকারফাইল রয়েছে, তাই এই সমস্যাটি বিদ্যমান ছিল না।

আমরা মেট্রিক্স নিরীক্ষণ সুপারিশ ব্যবহারের (ব্যবহার, স্যাচুরেশন এবং ত্রুটি), API বিলম্ব এবং ত্রুটির হার। ফলাফল প্রত্যাশা পূরণ নিশ্চিত করুন.

রেফারেন্স

এই আমাদের গল্প. নিম্নলিখিত উপকরণগুলি কী ঘটছে তা বোঝার জন্য ব্যাপকভাবে সাহায্য করেছে:

• kernel.org → CFS শিডিউলার;
• kernel.org → CFS ব্যান্ডউইথ কন্ট্রোল;
• লিনাক্স কন্টেইনার সময়সূচী বোঝা;
• লিনাক্স কন্টেইনার সম্পর্কে আপনার যা কিছু জানা দরকার, প্রথম অংশ: লিনাক্স কন্ট্রোল গ্রুপ এবং প্রসেস আইসোলেশন;
• কুবারনেটস ব্যর্থতার গল্প - "cpu থ্রটলিং" সন্ধান করুন।

Kubernetes বাগ রিপোর্ট:

• #51135: গ্যারান্টিযুক্ত পডের জন্য CPU সীমা নির্ধারণ করা এড়িয়ে চলুন;
• #67577: CFS কোটা অপ্রয়োজনীয় থ্রটলিং হতে পারে;
• অত্যধিক আক্রমণাত্মক CFS.

আপনি কি আপনার অনুশীলনে অনুরূপ সমস্যার সম্মুখীন হয়েছেন বা কনটেইনারাইজড উত্পাদন পরিবেশে থ্রটলিং সম্পর্কিত অভিজ্ঞতা আছে? মন্তব্যে আপনার গল্প শেয়ার করুন!

অনুবাদক থেকে PS

আমাদের ব্লগেও পড়ুন:

• «কুবারনেটে অটোস্কেলিং এবং রিসোর্স ম্যানেজমেন্ট (পর্যালোচনা এবং ভিডিও রিপোর্ট)";
• «কিভাবে CPU ম্যানেজার কুবারনেটসে কাজ করে";
• «আপনি যখন kubectl রান চালান তখন কুবারনেটসে কী ঘটে? অংশ ২».

উত্স: www.habr.com