Kubernetes: CPU मर्यादा काढून तुमच्या सेवांचा वेग वाढवा

2016 मध्ये आम्ही बफरवर परतलो Kubernetes वर स्विच केले, आणि आता सुमारे 60 नोड्स (AWS वर) आणि 1500 कंटेनर आमच्या k8s क्लस्टरद्वारे व्यवस्थापित करत आहेत कोप्स. तथापि, आम्ही चाचणी आणि त्रुटीद्वारे मायक्रो सर्व्हिसेसमध्ये गेलो आणि k8 सह अनेक वर्षे काम केल्यानंतरही आम्हाला नवीन समस्यांचा सामना करावा लागत आहे. या पोस्टमध्ये आपण याबद्दल बोलू प्रोसेसर मर्यादा: आम्हाला ते चांगले सराव का वाटले आणि ते इतके चांगले का राहिले नाहीत.

प्रोसेसर मर्यादा आणि थ्रॉटलिंग

इतर अनेक Kubernetes वापरकर्त्यांप्रमाणे, Google CPU मर्यादा सेट करण्याची जोरदार शिफारस करते. अशा सेटिंगशिवाय, नोडमधील कंटेनर सर्व प्रोसेसर पॉवर घेऊ शकतात, ज्यामुळे महत्त्वपूर्ण कुबर्नेट्स प्रक्रिया होतात (उदाहरणार्थ kubelet) विनंत्यांना प्रतिसाद देणे थांबवेल. अशा प्रकारे, तुमच्या नोड्सचे संरक्षण करण्यासाठी CPU मर्यादा सेट करणे हा एक चांगला मार्ग आहे.

प्रोसेसर मर्यादा कंटेनरला एका विशिष्ट कालावधीसाठी वापरल्या जाणार्‍या कमाल CPU वेळेवर सेट करते (डीफॉल्ट 100ms आहे), आणि कंटेनर कधीही ही मर्यादा ओलांडणार नाही. साठी Kubernetes मध्ये थ्रॉटलिंग कंटेनर आणि मर्यादा ओलांडण्यापासून प्रतिबंधित करण्यासाठी, एक विशेष साधन वापरले जाते CFS कोटा, परंतु या कृत्रिम CPU मर्यादांमुळे कार्यप्रदर्शन खराब होते आणि तुमच्या कंटेनरचा प्रतिसाद वेळ वाढतो.

आम्ही प्रोसेसर मर्यादा सेट न केल्यास काय होऊ शकते?

दुर्दैवाने, आम्हाला स्वतःला या समस्येचा सामना करावा लागला. प्रत्येक नोडमध्ये कंटेनर व्यवस्थापित करण्यासाठी जबाबदार प्रक्रिया असते kubelet, आणि त्याने विनंत्यांना प्रतिसाद देणे थांबवले. जेव्हा हे घडते तेव्हा नोड राज्यात जाईल NotReady, आणि त्यातील कंटेनर इतरत्र पुनर्निर्देशित केले जातील आणि नवीन नोड्सवर समान समस्या निर्माण करतील. किमान म्हणायचे तर आदर्श परिस्थिती नाही.

थ्रॉटलिंग आणि प्रतिसादाच्या समस्येचे प्रकटीकरण

कंटेनर ट्रॅकिंगसाठी मुख्य मेट्रिक आहे trottling, ते दाखवते की तुमचा कंटेनर किती वेळा थ्रोटल झाला आहे. प्रोसेसरचा भार जास्त आहे की नाही याची पर्वा न करता, काही कंटेनरमध्ये थ्रॉटलिंगची उपस्थिती आम्हाला स्वारस्याने लक्षात आली. उदाहरण म्हणून, आमच्या मुख्य API पैकी एक पाहू:

तुम्ही खाली पाहू शकता, आम्ही मर्यादा सेट केली आहे 800m (0.8 किंवा 80% कोर), आणि सर्वोत्तम पोहोच येथे शिखर मूल्ये 200m (20% कोर). असे दिसते की सेवेचा थ्रॉटलिंग करण्यापूर्वी आमच्याकडे अद्याप भरपूर प्रोसेसर पॉवर आहे, तथापि ...

तुमच्या लक्षात आले असेल की जेव्हा प्रोसेसर लोड निर्दिष्ट मर्यादेपेक्षा कमी असतो - लक्षणीय खाली - थ्रॉटलिंग अजूनही होते.

याचा सामना करत, आम्ही लवकरच अनेक संसाधने शोधली (github वर समस्या, zadano वर सादरीकरण, omio वर पोस्ट करा) थ्रॉटलिंगमुळे सेवांच्या कामगिरीतील घट आणि प्रतिसाद वेळेबद्दल.

आम्ही कमी CPU लोडवर थ्रॉटलिंग का पाहतो? लहान आवृत्ती अशी आहे: "लिनक्स कर्नलमध्ये एक बग आहे ज्यामुळे निर्दिष्ट प्रोसेसर मर्यादा असलेल्या कंटेनरचे अनावश्यक थ्रॉटलिंग होते." आपल्याला समस्येच्या स्वरूपामध्ये स्वारस्य असल्यास, आपण सादरीकरण वाचू शकता (видео и मजकूर पर्याय) डेव्ह चिलुक द्वारे.

CPU निर्बंध काढून टाकणे (अत्यंत सावधगिरीने)

प्रदीर्घ चर्चेनंतर, आम्ही आमच्या वापरकर्त्यांच्या गंभीर कार्यक्षमतेवर प्रत्यक्ष किंवा अप्रत्यक्षपणे परिणाम करणाऱ्या सर्व सेवांवरील प्रोसेसर निर्बंध काढून टाकण्याचा निर्णय घेतला.

निर्णय घेणे सोपे नव्हते कारण आम्ही आमच्या क्लस्टरच्या स्थिरतेला खूप महत्त्व देतो. भूतकाळात, आम्ही आमच्या क्लस्टरच्या अस्थिरतेचा प्रयोग आधीच केला आहे आणि नंतर सेवांनी खूप संसाधने वापरली आणि त्यांच्या संपूर्ण नोडचे काम मंद केले. आता सर्वकाही काहीसे वेगळे होते: आम्हाला आमच्या क्लस्टर्सकडून काय अपेक्षित आहे याची आम्हाला स्पष्ट समज होती, तसेच नियोजित बदलांची अंमलबजावणी करण्यासाठी एक चांगली रणनीती होती.

एका गंभीर समस्येवर व्यवसाय पत्रव्यवहार.

निर्बंध उठवल्यावर तुमच्या नोड्सचे संरक्षण कसे करावे?

"अप्रतिबंधित" सेवांचे पृथक्करण:

भूतकाळात, आम्ही आधीच काही नोड्स स्थितीत आल्याचे पाहिले आहे notReady, प्रामुख्याने सेवांमुळे ज्यांनी खूप संसाधने वापरली आहेत.

आम्ही अशा सेवा वेगळ्या (“लेबल केलेले”) नोड्समध्ये ठेवण्याचे ठरविले जेणेकरून ते “संबंधित” सेवांमध्ये व्यत्यय आणू नयेत. परिणामी, काही नोड्स चिन्हांकित करून आणि "असंबंधित" सेवांमध्ये सहिष्णुता पॅरामीटर जोडून, ​​आम्ही क्लस्टरवर अधिक नियंत्रण मिळवले आणि आमच्यासाठी नोड्समधील समस्या ओळखणे सोपे झाले. तत्सम प्रक्रिया स्वतः पार पाडण्यासाठी, आपण स्वत: ला परिचित करू शकता दस्तऐवजीकरण.

योग्य प्रोसेसर आणि मेमरी विनंती नियुक्त करणे:

आमची सर्वात मोठी भीती अशी होती की प्रक्रिया खूप संसाधने वापरेल आणि नोड विनंत्यांना प्रतिसाद देणे थांबवेल. आत्तापासून (डेटाडॉगचे आभार) आम्ही आमच्या क्लस्टरवरील सर्व सेवांचे स्पष्टपणे निरीक्षण करू शकलो, मी "असंबंधित" म्हणून नियुक्त करण्याची योजना आखत असलेल्या अनेक महिन्यांच्या ऑपरेशनचे विश्लेषण केले. मी फक्त 20% च्या फरकाने जास्तीत जास्त CPU वापर सेट करतो आणि अशा प्रकारे k8s ने नोडला इतर सेवा नियुक्त करण्याचा प्रयत्न केल्यास नोडमध्ये जागा वाटप केली.

जसे आपण ग्राफमध्ये पाहू शकता, प्रोसेसरवरील कमाल भार पोहोचला आहे 242m CPU कोर (0.242 प्रोसेसर कोर). प्रोसेसर विनंतीसाठी, या मूल्यापेक्षा किंचित मोठी संख्या घेणे पुरेसे आहे. कृपया लक्षात घ्या की सेवा वापरकर्ता-केंद्रित असल्याने, पीक लोड मूल्ये रहदारीशी जुळतात.

मेमरी वापर आणि क्वेरी, आणि व्हॉइलासह तेच करा - तुम्ही सर्व तयार आहात! अधिक सुरक्षिततेसाठी, तुम्ही क्षैतिज पॉड ऑटोस्केलिंग जोडू शकता. अशा प्रकारे, प्रत्येक वेळी संसाधनाचा भार जास्त असताना, ऑटोस्केलिंग नवीन पॉड्स तयार करेल आणि कुबर्नेट्स त्यांना मोकळ्या जागेसह नोड्समध्ये वितरित करेल. क्लस्टरमध्येच जागा शिल्लक नसल्यास, तुम्ही स्वत:ला अलर्ट सेट करू शकता किंवा त्यांच्या ऑटोस्केलिंगद्वारे नवीन नोड्स जोडणे कॉन्फिगर करू शकता.

उणेंपैकी, हे लक्षात घेण्यासारखे आहे की आम्ही "मध्ये हरलोकंटेनर घनता", म्हणजे एका नोडवर चालणाऱ्या कंटेनरची संख्या. कमी रहदारीच्या घनतेवर आमच्याकडे भरपूर "विश्रांती" देखील असू शकते आणि आपण उच्च प्रोसेसर लोडवर पोहोचण्याची शक्यता देखील आहे, परंतु ऑटोस्केलिंग नोड्स नंतरच्या बाबतीत मदत करतात.

निकाल

गेल्या काही आठवड्यांतील प्रयोगांचे हे उत्कृष्ट परिणाम प्रकाशित करताना मला आनंद होत आहे; आम्ही सर्व सुधारित सेवांमध्ये प्रतिसादात लक्षणीय सुधारणा पाहिल्या आहेत:

आम्ही आमच्या मुख्यपृष्ठावर सर्वोत्तम परिणाम प्राप्त केले (buffer.com), तेथे सेवेचा वेग वाढला बावीस वेळा!

लिनक्स कर्नल बग निश्चित केला आहे का?

होय, बग आधीच निश्चित केले गेले आहे आणि निराकरण कर्नलमध्ये जोडले गेले आहे वितरण आवृत्ती 4.19 आणि उच्च.

तथापि, वाचल्यावर github वर kubernetes समस्या दुसऱ्या सप्टेंबर 2020 साठी आम्हाला अजूनही काही लिनक्स प्रोजेक्ट्सचे उल्लेख आढळतात ज्यामध्ये एक समान बग आहे. मला विश्वास आहे की काही लिनक्स वितरणांमध्ये अजूनही हा बग आहे आणि ते फक्त त्याचे निराकरण करण्याचे काम करत आहेत.

तुमची वितरण आवृत्ती 4.19 पेक्षा कमी असल्यास, मी नवीनतम अद्यतनित करण्याची शिफारस करतो, परंतु कोणत्याही परिस्थितीत तुम्ही प्रोसेसर निर्बंध काढून टाकण्याचा प्रयत्न केला पाहिजे आणि थ्रॉटलिंग कायम राहते का ते पहा. खाली तुम्ही Kubernetes व्यवस्थापन सेवा आणि Linux वितरणांची आंशिक सूची पाहू शकता:

• डेबियन: वितरणाच्या नवीनतम आवृत्तीमध्ये समाकलित केलेले निराकरण, बुस्टर, आणि अगदी ताजे दिसते (ऑगस्ट 2020). काही मागील आवृत्त्या देखील निश्चित केल्या जाऊ शकतात.
• उबंटू: नवीनतम आवृत्तीमध्ये समाकलित केलेले निराकरण उबंटू फोकल फोसा 20.04
• ईकेएसला अद्याप निराकरण झाले आहे डिसेंबर 2019 मध्ये. तुमची आवृत्ती यापेक्षा कमी असल्यास, तुम्ही AMI अपडेट करा.
• कोप्स: जून 2020 पासून у kops 1.18+ मुख्य होस्ट प्रतिमा उबंटू 20.04 असेल. तुमची कॉप्सची आवृत्ती जुनी असल्यास, तुम्हाला निराकरणासाठी प्रतीक्षा करावी लागेल. आम्ही स्वतः आता वाट पाहत आहोत.
• GKE (Google Cloud): फिक्स इंटिग्रेटेड जानेवारी 2020 मध्ये, तथापि थ्रॉटलिंगमध्ये समस्या आहेत अजूनही पाळले जातात.

फिक्सने थ्रॉटलिंग समस्येचे निराकरण केल्यास काय करावे?

मला खात्री नाही की समस्येचे पूर्णपणे निराकरण झाले आहे. जेव्हा आम्ही फिक्ससह कर्नल आवृत्तीवर पोहोचतो, तेव्हा मी क्लस्टरची चाचणी घेईन आणि पोस्ट अद्यतनित करेन. जर कोणी आधीच अपडेट केले असेल, तर मला तुमचे परिणाम वाचण्यात रस असेल.

निष्कर्ष

• जर तुम्ही लिनक्स अंतर्गत डॉकर कंटेनरसह काम करत असाल (कुबर्नेट्स, मेसोस, स्वॉर्म किंवा इतर काही फरक पडत नाही), तुमचे कंटेनर थ्रॉटलिंगमुळे कार्यप्रदर्शन गमावू शकतात;
• दोष आधीच निश्चित केला गेला आहे या आशेने आपल्या वितरणाच्या नवीनतम आवृत्तीवर अद्यतनित करण्याचा प्रयत्न करा;
• प्रोसेसर मर्यादा काढून टाकणे समस्या सोडवेल, परंतु हे एक धोकादायक तंत्र आहे जे अत्यंत सावधगिरीने वापरले पाहिजे (प्रथम कर्नल अद्यतनित करणे आणि परिणामांची तुलना करणे चांगले आहे);
• जर तुम्ही CPU मर्यादा काढून टाकल्या असतील, तर तुमचे CPU आणि मेमरी वापराचे काळजीपूर्वक निरीक्षण करा आणि तुमची CPU संसाधने तुमच्या वापरापेक्षा जास्त आहेत याची खात्री करा;
• उच्च हार्डवेअर लोडच्या बाबतीत नवीन पॉड्स तयार करण्यासाठी पॉड्स ऑटोस्केल करणे हा एक सुरक्षित पर्याय आहे, जेणेकरून कुबर्नेट्स त्यांना फ्री नोड्सवर नियुक्त करतात.

मला आशा आहे की हे पोस्ट तुम्हाला तुमच्या कंटेनर सिस्टमचे कार्यप्रदर्शन सुधारण्यात मदत करेल.

PS तो आहे लेखक वाचक आणि भाष्यकारांशी (इंग्रजीमध्ये) पत्रव्यवहार करतो.


स्त्रोत: www.habr.com