কুবারনেটস: CPU সীমা অপসারণ করে আপনার পরিষেবার গতি বাড়ান

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

প্রসেসরের সীমাবদ্ধতা এবং থ্রটলিং

অন্যান্য অনেক কুবারনেট ব্যবহারকারীদের মত, Google অত্যন্ত সিপিইউ সীমা সেট করার সুপারিশ করে. এই ধরনের সেটিং ব্যতীত, একটি নোডের পাত্রে সমস্ত প্রসেসরের শক্তি গ্রহণ করতে পারে, যার ফলে গুরুত্বপূর্ণ Kubernetes প্রক্রিয়াগুলি ঘটে (উদাহরণস্বরূপ kubelet) অনুরোধে সাড়া দেওয়া বন্ধ করবে। এইভাবে, CPU সীমা নির্ধারণ করা আপনার নোডগুলিকে রক্ষা করার একটি ভাল উপায়।

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

আমরা যদি প্রসেসরের সীমা নির্ধারণ না করি তবে কী ঘটতে পারে?

দুর্ভাগ্যবশত, আমরা নিজেদেরকে এই সমস্যার সম্মুখীন হতে হয়েছে. প্রতিটি নোডের একটি প্রক্রিয়া রয়েছে যা কন্টেইনার পরিচালনার জন্য দায়ী kubelet, এবং তিনি অনুরোধে সাড়া দেওয়া বন্ধ করে দেন। নোড, যখন এটি ঘটবে, রাজ্যে যাবে NotReady, এবং এটি থেকে পাত্রগুলি অন্য কোথাও পুনঃনির্দেশিত হবে এবং নতুন নোডগুলিতে একই সমস্যা তৈরি করবে। একটি আদর্শ দৃশ্যকল্প নয়, অন্তত বলতে.

থ্রটলিং এবং প্রতিক্রিয়ার সমস্যার প্রকাশ

ধারক ট্র্যাকিং জন্য মূল মেট্রিক হয় trottling, এটি দেখায় যে আপনার ধারকটি কতবার থ্রোটল করা হয়েছে। প্রসেসরের লোড চরম হোক বা না হোক আমরা আগ্রহের সাথে কিছু পাত্রে থ্রটলিং এর উপস্থিতি লক্ষ্য করেছি। একটি উদাহরণ হিসাবে, আসুন আমাদের প্রধান APIগুলির মধ্যে একটি দেখে নেওয়া যাক:

আপনি নীচে দেখতে পাচ্ছেন, আমরা সীমা সেট করেছি 800m (0.8 বা 80% কোর), এবং সর্বোচ্চ নাগালের সর্বোচ্চ মান 200m (20% কোর)। দেখে মনে হবে যে পরিষেবাটি থ্রোটল করার আগে আমাদের কাছে এখনও প্রচুর প্রসেসর পাওয়ার রয়েছে, তবে ...

আপনি হয়তো লক্ষ্য করেছেন যে প্রসেসরের লোড নির্দিষ্ট সীমার নীচে থাকলেও - উল্লেখযোগ্যভাবে নীচে - থ্রটলিং এখনও ঘটে।

এর মুখোমুখি হয়ে, আমরা শীঘ্রই বেশ কয়েকটি সংস্থান আবিষ্কার করেছি (গিথুবে সমস্যা, zadano উপর উপস্থাপনা, ওমিওতে পোস্ট করুন) থ্রটলিংয়ের কারণে পরিষেবাগুলির কার্যক্ষমতা এবং প্রতিক্রিয়ার সময় হ্রাস সম্পর্কে।

কেন আমরা কম CPU লোড এ থ্রটলিং দেখতে পাচ্ছি? সংক্ষিপ্ত সংস্করণটি হল: "লিনাক্স কার্নেলে একটি বাগ রয়েছে যা নির্দিষ্ট প্রসেসর সীমা সহ কন্টেইনারগুলির অপ্রয়োজনীয় থ্রটলিং ঘটায়।" আপনি যদি সমস্যার প্রকৃতিতে আগ্রহী হন তবে আপনি উপস্থাপনাটি পড়তে পারেন (видео и পাঠ্য বিকল্প) ডেভ চিলুক দ্বারা।

CPU বিধিনিষেধ অপসারণ (অত্যন্ত সতর্কতার সাথে)

দীর্ঘ আলোচনার পর, আমরা আমাদের ব্যবহারকারীদের জন্য প্রত্যক্ষ বা পরোক্ষভাবে গুরুত্বপূর্ণ কার্যকারিতাকে প্রভাবিত করে এমন সমস্ত পরিষেবা থেকে প্রসেসরের সীমাবদ্ধতাগুলি সরানোর সিদ্ধান্ত নিয়েছি।

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

একটি প্রেসিং ইস্যুতে ব্যবসায়িক চিঠিপত্র।

বিধিনিষেধ তুলে নেওয়া হলে কীভাবে আপনার নোডগুলি রক্ষা করবেন?

"অনিয়ন্ত্রিত" পরিষেবাগুলির বিচ্ছিন্নতা:

অতীতে, আমরা ইতিমধ্যে কিছু নোড একটি রাষ্ট্র পেতে দেখেছি notReady, প্রাথমিকভাবে পরিষেবাগুলির কারণে যেগুলি অনেক বেশি সংস্থান গ্রহণ করেছে৷

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

একটি সঠিক প্রসেসর এবং মেমরি অনুরোধ বরাদ্দ করা:

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

আপনি গ্রাফে দেখতে পাচ্ছেন, প্রসেসরের সর্বোচ্চ লোড পৌঁছেছে 242m CPU কোর (0.242 প্রসেসর কোর)। একটি প্রসেসর অনুরোধের জন্য, এই মানের থেকে সামান্য বড় একটি সংখ্যা নেওয়া যথেষ্ট। দয়া করে মনে রাখবেন যে পরিষেবাগুলি যেহেতু ব্যবহারকারী-কেন্দ্রিক, তাই পিক লোডের মানগুলি ট্র্যাফিকের সাথে মিলে যায়৷

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

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

Результаты

আমি গত কয়েক সপ্তাহের পরীক্ষা-নিরীক্ষা থেকে এই চমৎকার ফলাফল প্রকাশ করতে পেরে আনন্দিত; আমরা ইতিমধ্যে সমস্ত পরিবর্তিত পরিষেবা জুড়ে প্রতিক্রিয়ায় উল্লেখযোগ্য উন্নতি দেখেছি:

আমরা আমাদের হোম পেজে সেরা ফলাফল অর্জন করেছি (buffer.com), সেখানে পরিষেবা ত্বরান্বিত হয়েছে৷ বাইশ বার!

লিনাক্স কার্নেল বাগ সংশোধন করা হয়েছে?

হ্যাঁ, বাগটি ইতিমধ্যেই সংশোধন করা হয়েছে এবং ফিক্সটি কার্নেলে যোগ করা হয়েছে বিতরণ সংস্করণ 4.19 এবং উচ্চতর।

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

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

• ডেবিয়ান: ডিস্ট্রিবিউশনের সর্বশেষ সংস্করণে ফিক্স ইন্টিগ্রেটেড, বাস্টার, এবং বেশ তাজা দেখায় (আগস্ট 2020) আগের কিছু সংস্করণও ঠিক করা হতে পারে।
• উবুন্টু: লেটেস্ট ভার্সনে ইন্টিগ্রেটেড ফিক্স উবুন্টু ফোকাল ফোসা 20.04
• EKS এখনও একটি ঠিক আছে ডিসেম্বর 2019 সালে. যদি আপনার সংস্করণ এর চেয়ে কম হয়, তাহলে আপনার AMI আপডেট করা উচিত।
• কপস: জুন 2020 থেকে у kops 1.18+ মূল হোস্ট ইমেজ হবে উবুন্টু 20.04। আপনার কপসের সংস্করণটি যদি পুরানো হয় তবে আপনাকে একটি সমাধানের জন্য অপেক্ষা করতে হতে পারে। আমরা নিজেরাই এখন অপেক্ষা করছি।
• GKE (গুগল ক্লাউড): ফিক্স ইন্টিগ্রেটেড 2020 সালের জানুয়ারিতে, তবে থ্রটলিং এর সমস্যা আছে এখনও পর্যবেক্ষণ করা হয়.

ফিক্স যদি থ্রটলিং সমস্যাটি ঠিক করে তবে কী করবেন?

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

উপসংহার

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

আমি আশা করি এই পোস্টটি আপনাকে আপনার কন্টেইনার সিস্টেমের কর্মক্ষমতা উন্নত করতে সাহায্য করবে।

দ্রষ্টব্য এটা হল লেখক পাঠক এবং ভাষ্যকারদের (ইংরেজিতে) সাথে সঙ্গতিপূর্ণ।


উত্স: www.habr.com