Kubernetes: Kubelet/Kubernetes को स्वैप सक्षम के साथ काम करना चाहिए

स्वैप के लिए समर्थन गैर-तुच्छ है। गारंटीकृत पॉड्स को कभी भी स्वैप की आवश्यकता नहीं होनी चाहिए। बर्स्टेबल पॉड्स को स्वैप की आवश्यकता के बिना उनके अनुरोधों को पूरा करना चाहिए। BestEffort पॉड्स की कोई गारंटी नहीं होती है। क्यूबलेट में अभी पॉड्स में सही मात्रा में अनुमानित व्यवहार प्रदान करने के लिए स्मार्ट की कमी है।

हमने इस विषय पर इस वर्ष की शुरुआत में आमने-सामने संसाधन एमजीएमटी पर चर्चा की। हम इसे प्राप्त होने वाले लाभों के सापेक्ष निकट अवधि में इससे निपटने में सुपर रुचि नहीं रखते हैं। हम दबाव का पता लगाने के आसपास विश्वसनीयता में सुधार करना पसंद करेंगे, और स्वैप के लिए अनुकूलित करने का प्रयास करने से पहले विलंबता के आसपास के मुद्दों को अनुकूलित करेंगे, लेकिन अगर यह आपके लिए एक उच्च प्राथमिकता है, तो हम आपकी मदद से प्यार करेंगे।

/ तरह की सुविधा

@derekwaynecarr स्पष्टीकरण के लिए धन्यवाद! कुबेरनेट्स के लिए स्वैप को अक्षम क्यों किया जाना चाहिए, कोई भी जानकारी/दस्तावेज प्राप्त करना कठिन था। यही मुख्य कारण था कि मैंने इस विषय को खोला। इस समय मैं इस मुद्दे पर उच्च प्राथमिकता नहीं रखता, बस यह सुनिश्चित करना चाहता था कि हमारे पास एक ऐसा स्थान हो जहां इस पर चर्चा की जा सके।

यहां चर्चा में और संदर्भ हैं: https://github.com/kubernetes/kubernetes/issues/7294 - स्वैप उपलब्ध होने से स्मृति सीमा के साथ बहुत ही अजीब और खराब बातचीत होती है। उदाहरण के लिए, एक कंटेनर जो अपनी मेमोरी सीमा को हिट करता है, वह _then_ स्वैप में फैलना शुरू कर देगा (यह f4edaf2b8c32463d6485e2c12b7fd776aef948bc के बाद से तय किया गया प्रतीत होता है - उन्हें किसी भी स्वैप का उपयोग करने की अनुमति नहीं दी जाएगी चाहे वह वहां हो या नहीं)।

यह हमारे लिए भी महत्वपूर्ण उपयोग का मामला है। हमारे पास एक क्रॉन जॉब है जो कभी-कभी उच्च मेमोरी उपयोग (> 30GB) में चलती है और हम स्थायी रूप से 40+GB नोड्स आवंटित नहीं करना चाहते हैं। इसके अलावा, यह देखते हुए कि हम तीन क्षेत्रों (जीकेई) में चलते हैं, यह 3 ऐसी मशीनों को आवंटित करेगा (प्रत्येक क्षेत्र में 1)। और इस कॉन्फ़िगरेशन को 3+ प्रोडक्शन इंस्टेंस और 10+ टेस्ट इंस्टेंस में दोहराया जाना है, जिससे K8s का उपयोग करना बहुत महंगा हो गया है। हमें 25+ 48GB नोड्स रखने के लिए मजबूर किया जाता है, जिसमें भारी लागत आती है!
कृपया स्वैप सक्षम करें!.

उन लोगों के लिए एक समाधान जो वास्तव में स्वैप चाहते हैं। अगर तुम

• क्यूबलेट को --fail-swap-on=false
• अपने नोड्स में स्वैप जोड़ें
• कंटेनर जो स्मृति आवश्यकता को निर्दिष्ट नहीं करते हैं, तब डिफ़ॉल्ट रूप से स्वैप सहित सभी मशीन मेमोरी का उपयोग करने में सक्षम होंगे।

हम यही तो कर रहे हैं। या कम से कम, मुझे पूरा यकीन है कि यह है, मैंने वास्तव में इसे व्यक्तिगत रूप से लागू नहीं किया था, लेकिन मैं यही इकट्ठा करता हूं।

यह वास्तव में केवल एक व्यवहार्य रणनीति हो सकती है यदि आपका कोई भी कंटेनर कभी भी स्पष्ट स्मृति आवश्यकता निर्दिष्ट नहीं करता है ...

हम GKE में चलते हैं, और मुझे उन विकल्पों को सेट करने का कोई तरीका नहीं पता है।

यदि कोई क्यूबलेट में स्मृति निष्कासन के प्रभावों का मूल्यांकन कर सकता है तो मैं zswap को अपनाने पर विचार करने के लिए तैयार हूं।

मैं अपने स्थानीय उबंटू लैपटॉप में कुबेरनेट्स चला रहा हूं और प्रत्येक पुनरारंभ के साथ मुझे स्वैप को बंद करना होगा। इसके अलावा मुझे इस बात की चिंता करनी होगी कि स्वैप बंद होने के कारण स्मृति सीमा के पास न जाएं।

क्या प्रत्येक पुनरारंभ के साथ कोई तरीका है कि मुझे मौजूदा स्थापना में कुछ कॉन्फ़िगरेशन फ़ाइल परिवर्तन की तरह स्वैप बंद करने की आवश्यकता नहीं है?

मुझे क्लस्टर में चल रहे नोड्स पर स्वैप की आवश्यकता नहीं है।

कुबेरनेट्स लोकल देव क्लस्टर के अलावा मेरे लैपटॉप पर इसके अन्य एप्लिकेशन हैं जिन्हें चालू करने के लिए स्वैप की आवश्यकता होती है।

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.2", GitCommit:"5fa2db2bd46ac79e5e00a4e6ed24191080aa463b", GitTreeState:"clean", BuildDate:"2018-01-18T10:09:24Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.2", GitCommit:"5fa2db2bd46ac79e5e00a4e6ed24191080aa463b", GitTreeState:"clean", BuildDate:"2018-01-18T09:42:01Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}

अभी झंडा काम नहीं कर रहा है।

# systemctl restart kubelet --fail-swap-on=false
systemctl: unrecognized option '--fail-swap-on=false'

निम्नलिखित क्यूबलेट ध्वज सेट करें: --fail-swap-on=false

मंगल, 30 जनवरी, 2018 में 1:59 बजे पर, icewheel [email protected] लिखा है:

मैं अपने स्थानीय उबंटू लैपटॉप में कुबेरनेट्स चला रहा हूं और प्रत्येक पुनरारंभ के साथ I
स्वैप टर्नऑफ करना होगा। इसके अलावा मुझे इस बात की चिंता करनी होगी कि मैं स्मृति के पास न जाऊं
अगर स्वैप बंद है तो सीमा।

क्या प्रत्येक पुनरारंभ के साथ कोई रास्ता है मुझे कुछ की तरह स्वैप बंद करने की ज़रूरत नहीं है
मौजूदा स्थापना में कॉन्फ़िगरेशन फ़ाइल परिवर्तन?

मुझे क्लस्टर में चल रहे नोड्स पर स्वैप की आवश्यकता नहीं है।

कुबेरनेट्स लोकल देव के अलावा मेरे लैपटॉप पर इसके अन्य अनुप्रयोग हैं
क्लस्टर जिन्हें चालू करने के लिए स्वैप की आवश्यकता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/53533#issuecomment-361748518 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AA3JwQdj2skL2dSqEVyV46iCllzT-sOVks5tP5DSgaJpZM4PwnD5
.

--
माइकल टौफेन
गूगल स्वे

धन्यवाद @mtaufen

आपके लिए क्लस्टर बूटस्ट्रैप करने वाले सिस्टम के लिए (जैसे टेराफॉर्म), आपको सेवा फ़ाइल को संशोधित करने की आवश्यकता हो सकती है

यह मेरे लिए काम किया

sudo sed -i '/kubelet-wrapper/a \ --fail-swap-on=false \\\' /etc/systemd/system/kubelet.service

डिफ़ॉल्ट के रूप में स्वैप का समर्थन नहीं कर रहा है? मुझे यह सुनकर आश्चर्य हुआ -- मुझे लगा कि कुबेरनेट्स प्राइम टाइम के लिए तैयार हैं? स्वैप उन विशेषताओं में से एक है।

अधिकांश खुले उपयोग के मामलों में यह वास्तव में वैकल्पिक नहीं है - इसी तरह से यूनिक्स पारिस्थितिकी तंत्र को चलाने के लिए डिज़ाइन किया गया है, जिसमें वीएमएम निष्क्रिय पृष्ठों को स्विच कर रहा है।

यदि विकल्प कोई स्वैप या कोई स्मृति सीमा नहीं है, तो मैं किसी भी दिन स्वैप रखना चुनूंगा, और जब मैं पेजिंग शुरू करूंगा तो बस और अधिक मेजबानों को स्पिन करूंगा, और मैं अभी भी पैसे बचाने के लिए बाहर आऊंगा।

क्या कोई स्पष्ट कर सकता है - क्या स्मृति निष्कासन में समस्या केवल एक समस्या है यदि आप पॉड परिभाषा में स्मृति सीमा का उपयोग कर रहे हैं, लेकिन अन्यथा, यह ठीक है?

ऐसी दुनिया में काम करना अच्छा होगा जहां एप्लिकेशन मेमोरी के काम करने के तरीके पर मेरा नियंत्रण है, इसलिए मुझे खराब मेमोरी उपयोग के बारे में चिंता करने की ज़रूरत नहीं है, लेकिन अधिकांश एप्लिकेशन में बहुत अधिक निष्क्रिय मेमोरी स्पेस है।

मुझे ईमानदारी से लगता है कि स्वैप के बिना सर्वर चलाने का यह हालिया कदम Paa प्रदाताओं द्वारा संचालित है, जो लोगों को बड़े मेमोरी इंस्टेंस में ज़बरदस्ती करने की कोशिश कर रहे हैं - जबकि ~ 40 साल के मेमोरी मैनेजमेंट डिज़ाइन की अवहेलना करते हुए। वास्तविकता यह है कि कर्नेल वास्तव में यह जानने के लिए अच्छा है कि कौन से मेमोरी पेज सक्रिय हैं या नहीं - इसे अपना काम करने दें।

इसका एक प्रभाव यह भी है कि यदि नोड पर मेमोरी समाप्त हो जाती है, तो यह संभावित रूप से पूरी तरह से लॉक हो जाएगा - नोड को फिर से शुरू करने की आवश्यकता है, बजाय इसके कि कुछ समय बाद धीमा हो जाए और ठीक हो जाए।

90d निष्क्रियता के बाद मुद्दे पुराने हो जाते हैं।
/remove-lifecycle stale साथ समस्या को ताज़ा के रूप में चिह्नित करें।
अतिरिक्त 30d निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

अगर इस मुद्दे को अभी बंद करना सुरक्षित है तो कृपया /close साथ ऐसा करें।

sig-testing, Kubernetes/test-infra और/या fejta को फ़ीडबैक भेजें।
/जीवनचक्र बासी

मेरे क्लस्टर नोड्स ( K8s Version - v1.11.2 ) में डिस्क की संख्या अधिक है। स्वैप मेमोरी को अक्षम करने के कारण हो सकता है?

https://stackoverflow.com/questions/51988566/high-number-of-disk-reads-in-kubernetes-nodes

@srevenant क्लस्टर की दुनिया में, दूसरे नोड का RAM नया स्वैप है। उस ने कहा, मैं दो एक-नोड K8s उदाहरण चलाता हूं जहां स्वैप समझ में आता है। लेकिन यह K8s का विशिष्ट उपयोग मामला नहीं है।

@srevenant मैं SWAP का उपयोग यूनिक्स और लिनक्स पर डिफ़ॉल्ट रूप से किया जाता है क्योंकि वे पैदा हुए थे, मुझे लगता है कि मैंने लिनक्स पर काम करने के 15 वर्षों के दौरान एक ऐप नहीं देखा जो SWAP को बंद करने के लिए कहता है।
जब हम किसी भी लिनक्स डिस्ट्रो को स्थापित करते हैं तो SWAP हमेशा डिफ़ॉल्ट रूप से चालू रहता है, इसलिए मुझे K8s स्थापित करने से पहले इसे बंद कर देना चाहिए और यह एक आश्चर्य की बात थी।
लिनक्स कर्नेल अच्छी तरह से जानता है कि सर्वर के प्रदर्शन को बढ़ाने के लिए SWAP को कैसे प्रबंधित किया जाए, विशेष रूप से अस्थायी रूप से जब सर्वर RAM की सीमा तक पहुंचने वाला हो।
क्या इसका मतलब यह है कि K8s को अच्छी तरह से काम करने के लिए मुझे SWAP को बंद करना होगा?

मुझे यह काम करने में दिलचस्पी है, और मेरे पास परीक्षण करने के लिए कौशल और कई मशीनें हैं। अगर मैं योगदान देना चाहता हूं, तो शुरू करने के लिए सबसे अच्छी जगह कहां है?

@superdave कृपया कुबेरनेट्स/समुदाय में एक केईपी को एक साथ रखें, जिसमें बताया गया है कि आप कैसे स्वैप का समर्थन करना चाहते हैं, और इसे सिग-नोड में प्रस्तुत करें। हमें आपकी मदद करना अच्छा लगेगा।

मैं कुबेरनेट के पॉड्स में स्वैप को ठीक से सक्षम करने के लिए खड़ा हूं। स्वैप न होने का वास्तव में कोई मतलब नहीं है, क्योंकि लगभग सभी कंटेनर कस्टम लिनक्स इंस्टेंस हैं, और इसलिए डिफ़ॉल्ट रूप से स्वैप का समर्थन करते हैं।
यह समझ में आता है कि इस सुविधा को लागू करना जटिल है, लेकिन कब से इसने हमें आगे बढ़ने से रोक दिया?

मुझे इस बात से सहमत होना चाहिए कि कुबेरनेट्स में स्वैप मुद्दों को हल किया जाना चाहिए क्योंकि स्वैप को अक्षम करने से नोड पर स्मृति समाप्त होने पर नोड विफलता का कारण बनता है। उदाहरण के लिए यदि आपके पास 3 वर्कर नोड्स (प्रत्येक में 20GB RAM) हैं और एक नोड नीचे चला जाता है क्योंकि RAM की सीमा 2 अन्य वर्कर नोड्स तक पहुंच जाती है, तो उस समय में सभी पॉड्स को स्थानांतरित करने के बाद भी नीचे चला जाएगा।

आप मेमोरी अनुरोधों को वास्तविक के अनुसार सेट करके इसे रोक सकते हैं
आवेदन की आवश्यकता।

यदि आपके एप्लिकेशन की मेमोरी का एक तिहाई परिमाण के 2 क्रमों पर है
धीमी भंडारण, क्या यह कोई उपयोगी कार्य करने में सक्षम होगा?

बुध Sep 26, 2018 में 6:51 AM पर vasicvuk [email protected] लिखा है:

मुझे इस बात से सहमत होना चाहिए कि कुबेरनेट्स में स्वैप मुद्दों को हल किया जाना चाहिए
स्वैप को अक्षम करने से नोड पर स्मृति समाप्त होने पर नोड विफलता का कारण बनता है। के लिये
उदाहरण यदि आपके पास 3 कार्यकर्ता नोड्स (प्रत्येक में 20GB RAM) और एक नोड जाता है
नीचे क्योंकि राम की सीमा 2 अन्य कार्यकर्ता नोड्स तक पहुंच गई है
उस समय में सभी पॉड्स को उनके पास स्थानांतरित करने के बाद नीचे।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/53533#issuecomment-424604731 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAICBqZApBscFl5aNA4IcYvlxcvPA88Tks5ueyPlgaJpZM4PwnD5
.

@matthiasr आप ऐसा तब कर सकते हैं जब आपके पास 10-50 सेवाएं हों। लेकिन जब आपके पास 200 से अधिक सेवाएं चल रही हों और उनमें से आधे को आधिकारिक हेल्म चार्ट का उपयोग करके बिना किसी स्मृति अनुरोध के तैनात किया गया हो तो आपके हाथ ज्वार हैं।

लेकिन फिर, गायब स्मृति समस्या को संबोधित करने का अनुरोध नहीं कर रही है?

@matthiasr कई मामलों में स्मृति एक बार प्रक्रिया में मैप की गई केवल एक बार उपयोग की जाती है या वास्तव में कभी भी उपयोग नहीं की जाती है। वे वैध मामले हैं और मेमोरी लीक नहीं हैं। जब आप स्वैप करते हैं तो उन पृष्ठों को अंततः बदल दिया जाता है और फिर कभी भी स्वैप नहीं किया जा सकता है, फिर भी आप बेहतर उपयोग के लिए तेज़ रैम जारी करते हैं।

न ही जवाबदेही सुनिश्चित करने के लिए स्वैप को बंद करना एक अच्छा तरीका है। जब तक आप मेमोरी में फाइलों को पिन नहीं करते (एक क्षमता K8s में निष्पादन योग्य के लिए होना चाहिए, कम से कम), कर्नेल अभी भी मेमोरी दबाव, या यहां तक ​​​​कि केवल उपयोग की कमी के जवाब में किसी भी और सभी फ़ाइल-समर्थित पृष्ठों को स्वैप कर देगा।

स्वैप सक्षम होने से कर्नेल व्यवहार स्पष्ट रूप से नहीं बदलता है। यह केवल गुमनाम पृष्ठों, या गाय-मैप की गई फाइलों से लोड किए गए संशोधित पृष्ठों को स्वैप करने के लिए एक स्थान प्रदान करता है।

आप पूरी तरह से स्वैपिंग को बंद नहीं कर सकते हैं, इसलिए K8s को अपने अस्तित्व को बनाए रखने की आवश्यकता है, चाहे अनाम मेमोरी स्वैपिंग का विशेष मामला सक्षम हो

यह इसे एक बग बनाता है: आप एक कर्नेल सुविधा का समर्थन करने में विफल हो रहे हैं जिसे वास्तव में बंद नहीं किया जा सकता है।

@ बॉघनी

स्मृति दबाव, या यहां तक ​​कि उपयोग की कमी के जवाब में कर्नेल अभी भी किसी भी और सभी फ़ाइल-समर्थित पृष्ठों को स्वैप कर देगा। स्वैप सक्षम होने से कर्नेल व्यवहार स्पष्ट रूप से नहीं बदलता है।

आप अदला-बदली को पूरी तरह बंद नहीं कर सकते,

क्या आप इसके लिए कुछ संदर्भ प्रदान कर सकते हैं ताकि मैं खुद को शिक्षित कर सकूं?

जब तक आप मेमोरी में फाइलों को पिन नहीं करते (एक क्षमता K8s में निष्पादन योग्य के लिए होनी चाहिए, कम से कम),

आप k8s को किस क्षमता का उपयोग करना चाहते हैं? यदि कोई बाइनरी स्थिर है तो इसे पॉड पर एक tmpfs पर कॉपी करने से पेजिंग विलंबता में मदद मिलनी चाहिए।

@adityakali स्वैप बंद होने पर कर्नेल में स्वैप के प्रभाव पर कोई विचार?

क्या आप इसके लिए कुछ संदर्भ प्रदान कर सकते हैं ताकि मैं खुद को शिक्षित कर सकूं?

सभी आधुनिक वर्चुअल मेमोरी OSes की तरह, Linux डिस्क से मेमोरी में पेज एक्जिक्यूटिव की मांग करता है। स्मृति दबाव के तहत, कर्नेल आपके प्रोग्राम के वास्तविक निष्पादन योग्य कोड को किसी भी अन्य मेमोरी पेजों की तरह "स्वैप अक्षम करना" द्वारा आपके द्वारा अक्षम की गई _only_ अदला-बदली "अनाम स्मृति" है - स्मृति जो _not_ किसी फ़ाइल से संबद्ध है (सर्वोत्तम उदाहरण "स्टैक" और "हीप" डेटा संरचनाएं हैं)।

पाठ्यक्रम के उपरोक्त विवरण में बहुत सारे विवरण हैं जिन्हें मैं छोड़ रहा हूं। विशेष रूप से, निष्पादन योग्य अपने मेमोरी स्पेस के हिस्से को mlock syscalls के परिवार का उपयोग करके रैम में "लॉक" कर सकते हैं, madvise() माध्यम से चालाक चीजें करते हैं, यह जटिल हो जाता है जब एक ही पृष्ठ कई प्रक्रियाओं द्वारा साझा किए जाते हैं (उदाहरण के लिए libc.so), आदि। मुझे डर है कि मेरे पास उन मैनपेजों, या पाठ्यपुस्तकों या लिनक्स कर्नेल स्रोत/दस्तावेज़/मेलिंग-सूची जैसी सामान्य चीज़ों के अलावा और अधिक पढ़ने के लिए अधिक उपयोगी सूचक नहीं है।

तो, उपरोक्त का एक व्यावहारिक प्रभाव यह है कि जैसे-जैसे आपकी प्रक्रिया अपनी स्मृति सीमा के करीब आती है, कर्नेल को _code_ भाग और स्थिरांक को ram से बेदखल करने के लिए मजबूर किया जाएगा। अगली बार जब उस बिट कोड या स्थिर मान की आवश्यकता होती है, तो प्रोग्राम रुक जाएगा, इसे डिस्क से वापस लाने की प्रतीक्षा में (और कुछ और बेदखल)। तो "स्वैप अक्षम" के साथ भी, जब भी आपका कार्य सेट उपलब्ध स्मृति से अधिक हो जाता है, तब भी आपको वही गिरावट मिलती है।

इससे पहले कि लोग ऊपर पढ़ें और सब कुछ मेमोरी में लॉक करने के लिए कॉल करना शुरू करें या एंटी-स्वैप विच हंट के हिस्से के रूप में सब कुछ एक रैमड्राइव में कॉपी करें, मैं दोहराना चाहूंगा कि यहां रुचि का वास्तविक संसाधन सेट आकार काम कर रहा है - कुल आकार नहीं . एक प्रोग्राम जो रैम में गीगाबाइट डेटा के माध्यम से रैखिक रूप से काम करता है, वह एक समय में केवल उस डेटा की एक संकीर्ण विंडो पर काम कर सकता है। यह काल्पनिक कार्यक्रम बड़ी मात्रा में स्वैप और एक छोटी रैम सीमा के साथ ठीक काम करेगा - और यह सभी को वास्तविक राम में बंद करने के लिए बहुत अक्षम होगा। जैसा कि आपने उपरोक्त स्पष्टीकरण से सीखा है, यह बिल्कुल एक प्रोग्राम के समान है जिसमें बड़ी मात्रा में _code_ है लेकिन किसी विशेष क्षण में केवल इसकी थोड़ी मात्रा को निष्पादित करता है।

कुछ इस तरह का मेरा नवीनतम व्यक्तिगत वास्तविक दुनिया का उदाहरण कुबेरनेट्स एक्जिक्यूटिव को जोड़ रहा है। मैं वर्तमान में (विडंबना) अपने कुबेरनेट्स क्लस्टर पर कुबेरनेट्स को संकलित करने में असमर्थ हूं क्योंकि गो लिंक चरण के लिए कई गीगाबाइट (अनाम) वर्चुअल मेमोरी की आवश्यकता होती है, भले ही वर्किंग सेट बहुत छोटा हो।

वास्तव में "काम करने वाले सेट के बारे में, वर्चुअल मेमोरी नहीं" बिंदु पर वास्तव में विश्वास करने के लिए, एक ऐसे प्रोग्राम पर विचार करें जो बहुत सारी नियमित फ़ाइल I/O करता है और mmap से कोई लेना-देना नहीं है। यदि आपके पास पर्याप्त रैम है, तो कर्नेल बार-बार उपयोग की जाने वाली निर्देशिका संरचनाओं को कैश करेगा और रैम में डेटा फ़ाइल करेगा और डिस्क पर जाने से बच जाएगा, और यह डिस्क राइट-आउट को अनुकूलित करने के लिए अस्थायी रूप से रैम में लिखने की अनुमति देगा। यहां तक ​​​​कि इस तरह का एक "बेवकूफ" प्रोग्राम काम करने वाले सेट आकार बनाम उपलब्ध रैम के आधार पर रैम-स्पीड से डिस्क-स्पीड तक कम हो जाएगा। जब आप अनावश्यक रूप से रैम में कुछ पिन करते हैं (उदाहरण: एमलॉक या स्वैप को अक्षम करना), तो आप कर्नेल को भौतिक रैम के उस पृष्ठ का उपयोग करने से रोकते हैं जो वास्तव में उपयोगी होता है और (यदि आपके पास काम करने के लिए पर्याप्त रैम नहीं है) डिस्क I/O को कहीं अधिक महंगी जगह पर ले जाया गया।

@superdave : मुझे भी यहां यथास्थिति में सुधार करने में दिलचस्पी है। कृपया मुझे शामिल करें यदि आप किसी दस्तावेज़ की समीक्षा करने के लिए आँखों की एक और जोड़ी चाहते हैं, या कीबोर्ड पर हाथ रखना चाहते हैं।

कुछ इस तरह का मेरा नवीनतम व्यक्तिगत वास्तविक दुनिया का उदाहरण कुबेरनेट्स एक्जिक्यूटिव को जोड़ रहा है। मैं वर्तमान में (विडंबना) अपने कुबेरनेट्स क्लस्टर पर कुबेरनेट्स को संकलित करने में असमर्थ हूं क्योंकि गो लिंक चरण के लिए कई गीगाबाइट (अनाम) वर्चुअल मेमोरी की आवश्यकता होती है, भले ही वर्किंग सेट बहुत छोटा हो।

@superdave : मुझे भी यहां यथास्थिति में सुधार करने में दिलचस्पी है। कृपया मुझे शामिल करें यदि आप किसी दस्तावेज़ की समीक्षा करने के लिए आँखों की एक और जोड़ी चाहते हैं, या कीबोर्ड पर हाथ रखना चाहते हैं।

इस मुद्दे का अच्छा सारांश हाथ में है! स्वैप थ्रैशिंग यहाँ की मुख्य समस्या है, वास्तव में; यह कुछ ऐसा है जिसे मैं तर्कसंगत रूप से संबोधित करने की उम्मीद कर रहा हूं। यह मुझे लगता है, हालांकि मेरे पास वास्तव में इसके माध्यम से पर्याप्त सोचने का समय नहीं है, कि कुछ प्रकार की मैट्रिक स्वैपिंग गतिविधि (किसी निश्चित समय सीमा में पेजिन/आउट, शायद एक प्रतिशत नियम के साथ अति-उत्सुक उछाल से बचने के लिए यदि कोई प्रक्रिया अचानक अस्थायी रूप से बढ़ जाती है) स्वैप सक्षम होने पर बेदखली के लिए चीजों का मूल्यांकन करने का एक अच्छा तरीका हो सकता है। कई मेट्रिक्स हैं, और मुझे संदेह है कि हम बहुत सारे नॉब्स की पेशकश करना चाहते हैं और साथ ही संभावित उपयोग के मामलों का सावधानीपूर्वक मूल्यांकन करना चाहते हैं। मुझे यह भी संदेह है कि वर्चुअल मेमोरी इंटरैक्शन के लिए पॉड्स को साधन करने में सक्षम होने से लोगों को बेहतर ट्यून करने में मदद मिलनी चाहिए; मैं पहले से ही यह बताने के लिए पर्याप्त रूप से परिचित नहीं हूं कि अब क्या है, लेकिन मुझे संदेह है कि मैं इसका पता लगाने जा रहा हूं।

मैं उन नियंत्रणों से भी पर्याप्त परिचित नहीं हूँ जिन्हें हमें जानना है कि हम अलग-अलग पॉड्स/कंटेनरों में स्वैपिंग व्यवहार को कितनी अच्छी तरह नियंत्रित कर सकते हैं; प्रतिधारण या अदला-बदली के लिए चीजों को "त्याग" करने में सक्षम होना मददगार होगा, लेकिन डेवलपर्स स्पष्ट रूप से हमेशा mlock() करने की कोशिश करने के लिए स्वतंत्र होते हैं, जब उन्हें पूरी तरह से गारंटी देने की आवश्यकता होती है कि वे वैसे भी निवासी होंगे।

जो भी हो, हाँ, मैं बिल्कुल इस पर आगे बढ़ना चाहता हूँ। मुझे हाल ही में काम पर लाया गया है (k8s के तहत अपने स्वयं के माइक्रोसर्विसेज के साथ कुछ OOM मुद्दों को संभालना जो लोड के तहत स्वैप करने में सक्षम होने से लाभान्वित होंगे क्योंकि 99% समय उन्हें RAM की आवश्यकता नहीं होती है जब तक कि कोई अनजाने में बड़ा नहीं करता है अनुरोध), लेकिन कृपया इसके बारे में मुझ पर बने रहने के लिए स्वतंत्र महसूस करें। मैंने पहले कभी केईपी प्रक्रिया में भाग नहीं लिया है, इसलिए मैं इसमें काफी हरा-भरा होने जा रहा हूं, लेकिन इन दिनों मैं मतदान की तुलना में एक रुकावट के आधार पर बहुत बेहतर काम करता हूं। :-)

मैं यह बताना चाहूंगा कि ज़राम स्वैप पर गुल्लक करके काम करता है। यदि k8 पर कोई स्वैप नहीं है, तो कोई मेमोरी कंप्रेशन नहीं है, जो कि कुछ गैर-लिनक्स ओएस डिफ़ॉल्ट रूप से सक्षम है (क्यू विंडोज, मैकओएस)।

हमारे पास k8 पर एक उबंटू उदाहरण है जो हर रात एक बड़े बैच का काम करता है जो बहुत अधिक मेमोरी की खपत करता है। चूंकि कार्यभार पूर्व निर्धारित नहीं है, हमें OOM से बचने के लिए इसकी वास्तविक मेमोरी खपत की परवाह किए बिना (महंगे) नोड को 16GB आवंटित करने के लिए मजबूर किया जाता है। हमारे स्थानीय देव सर्वर पर स्मृति संपीड़न के साथ, कार्य केवल 3GB पर चरम पर होता है। अन्यथा दिन में यह केवल 1GB मेमोरी लेता है। स्वैप पर प्रतिबंध लगाना और इस प्रकार मेमोरी कंप्रेशन काफी मूर्खतापूर्ण कदम है।

मुझे लगता है कि यहां मुख्य चिंता शायद अलगाव है। एक विशिष्ट मशीन एक टन पॉड्स को होस्ट कर सकती है, और अगर मेमोरी टाइट हो जाती है, तो वे स्वैप करना शुरू कर सकते हैं और एक दूसरे के प्रदर्शन को पूरी तरह से नष्ट कर सकते हैं। यदि कोई अदला-बदली नहीं है, तो अलगाव बहुत आसान है।

मुझे लगता है कि यहां मुख्य चिंता शायद अलगाव है। एक विशिष्ट मशीन एक टन पॉड्स को होस्ट कर सकती है, और अगर मेमोरी टाइट हो जाती है, तो वे स्वैप करना शुरू कर सकते हैं और एक दूसरे के प्रदर्शन को पूरी तरह से नष्ट कर सकते हैं। यदि कोई अदला-बदली नहीं है, तो अलगाव बहुत आसान है।

लेकिन जैसा कि पहले बताया गया है, स्वैप को अक्षम करने से हमें यहां कुछ भी नहीं मिलता है। वास्तव में, चूंकि यह समग्र रूप से स्मृति दबाव को बढ़ाता है, यह कर्नेल को काम करने वाले सेट के कुछ हिस्सों को छोड़ने के लिए मजबूर कर सकता है जब यह अन्यथा अप्रयुक्त डेटा को स्वैप कर सकता था - इसलिए यह स्थिति को और खराब कर देता है ।

स्वैप को सक्षम करने से, वास्तव में अलगाव में सुधार होना चाहिए।

लेकिन यह आपको बहुत कुछ खरीदता है, अगर आप चीजों को उस तरह से चलाते हैं जैसे आप चाहते हैं (और जिस तरह से Google बोर्ग पर चीजें चलाता है): सभी कंटेनरों को ऊपरी मेमोरी सीमा निर्दिष्ट करनी चाहिए। बोर्ग Google इन्फ्रा का लाभ उठाता है और यदि आप इसे चाहते हैं तो सीमाएं सीखता है (पिछले संसाधन उपयोग और ओओएम व्यवहार से), लेकिन फिर भी सीमाएं हैं।

मैं वास्तव में इस बात से चकित हूं कि K8S लोगों ने मेमोरी सीमा को वैकल्पिक होने दिया। सीपीयू के विपरीत, मेमोरी प्रेशर का सिस्टम के प्रदर्शन पर बहुत गैर-रैखिक प्रभाव पड़ता है, क्योंकि जिसने भी सिस्टम को स्वैपिंग के कारण पूरी तरह से लॉक होते देखा है, वह प्रमाणित करेगा। इसे वास्तव में डिफ़ॉल्ट रूप से इसकी आवश्यकता होनी चाहिए, और यदि आप इसे अक्षम करना चुनते हैं तो आपको एक चेतावनी देनी चाहिए।

लेकिन यह आपको बहुत कुछ खरीदता है, अगर आप चीजों को उस तरह से चलाते हैं जैसे आप चाहते हैं (और जिस तरह से Google बोर्ग पर चीजें चलाता है): सभी कंटेनरों को ऊपरी मेमोरी सीमा निर्दिष्ट करनी चाहिए। बोर्ग Google इन्फ्रा का लाभ उठाता है और यदि आप इसे चाहते हैं तो सीमाएं सीखता है (पिछले संसाधन उपयोग और ओओएम व्यवहार से), लेकिन फिर भी सीमाएं हैं।

मैं वास्तव में इस बात से चकित हूं कि K8S लोगों ने मेमोरी सीमा को वैकल्पिक होने दिया। सीपीयू के विपरीत, मेमोरी प्रेशर का सिस्टम के प्रदर्शन पर बहुत गैर-रैखिक प्रभाव पड़ता है, क्योंकि जिसने भी सिस्टम को स्वैपिंग के कारण पूरी तरह से लॉक होते देखा है, वह प्रमाणित करेगा। इसे वास्तव में डिफ़ॉल्ट रूप से इसकी आवश्यकता होनी चाहिए, और यदि आप इसे अक्षम करना चुनते हैं तो आपको एक चेतावनी देनी चाहिए।

मुझे लगता है कि यह जिस मुद्दे को संबोधित करने में विफल रहता है वह यह है कि ऊपरी सीमा परिवर्तनशील है और हमेशा कुछ प्रक्रियाओं के लिए ज्ञात नहीं होती है। जिस मुद्दे से मैं निपट रहा हूं वह विशेष रूप से 3D मॉडल रेंडरर नोड्स को प्रबंधित करने के लिए k8s का उपयोग करने पर केंद्रित है। मॉडल और दृश्य के लिए संपत्तियों के आधार पर, आवश्यक रैम की मात्रा काफी भिन्न हो सकती है, और जबकि अधिकांश रेंडर छोटे होंगे, तथ्य यह है कि _some_ विशाल हो सकता है इसका मतलब है कि हमारे अनुरोधों और सीमाओं को अधिक मेमोरी आरक्षित करना है ओओएम से बचने के लिए हमें वास्तव में 90% समय की आवश्यकता होती है, बजाय इसके कि पॉड कभी-कभी कॉन्फ़िगर की गई सीमा से अधिक हो और स्वैप स्पेस में फैलने में सक्षम हो।

हां, और उस स्थिति में आप अपनी ऊपरी सीमा "कोई नहीं" या उस प्रभाव के लिए कुछ सेट करेंगे। मेरा कहना है, यह डिफ़ॉल्ट नहीं होना चाहिए। इसे कुछ भी नहीं पर सेट करना किसी भी प्रकार के बुद्धिमान वर्कलोड शेड्यूलिंग को पूरी तरह से हरा देता है, क्योंकि मास्टर बस "आइटम" (नौकरी) के आकार को नहीं जानता है, जिसे "नैप्सैक" (क्यूबलेट) में रखा जाता है।

यहां समस्या यह नहीं है कि आपकी नौकरी को स्वैप करने के लिए छोड़ दिया जाएगा, यह है कि उस नोड पर चलने वाली अन्य सभी नौकरियां भी होंगी। और उनमें से कुछ (अधिकांश?) इसे बिल्कुल भी पसंद नहीं करेंगे।

डेटा अखंडता पर कोई प्रभाव नहीं होने के कारण बोर्ग पर प्रोग्राम किसी भी समय पूर्व-खाली (मारने योग्य, शब्दजाल से परिचित नहीं होने के लिए) लिखे जाते हैं। यह वास्तव में कुछ ऐसा है जो मुझे Google के बाहर बहुत अधिक दिखाई नहीं देता है, और आपके कार्यक्रम की संभावित अचानक मृत्यु दर को स्वीकार करने से अधिक विश्वसनीय सॉफ़्टवेयर लिखने में मदद मिलती है। लेकिन मैं पीछे हटा।

इस तरह के कार्यक्रमों के साथ निर्मित सिस्टम उन कार्यक्रमों को मरने के लिए और सेल (बोर्ग क्लस्टर) में कहीं और फिर से अवतरित होना पसंद करेंगे, बजाय इसके कि एक ओवरसब्सक्राइब नोड पर पीड़ित रहें। पूंछ विलंबता वास्तव में समस्याग्रस्त हो सकती है अन्यथा, खासकर जब नौकरी में कार्यों की संख्या बड़ी हो।

मुझे गलत मत समझो, मैं यह नहीं कह रहा हूं कि चीजों को चलाने का यही एकमात्र "सही" तरीका है। मैं सिर्फ उस संभावित तर्क को स्पष्ट करने की कोशिश कर रहा हूं जो डिजाइन में चला गया।

अस्वीकरण: मैं एक पूर्व Googler हूं जिसने कई बहुत बड़ी सेवाओं को चलाने के लिए बोर्ग का उपयोग किया है, इसलिए मैं इसे अच्छी तरह से जानता हूं, और यह ज्ञान काफी हद तक कुबेरनेट्स में अनुवाद करता है। मैं वर्तमान में Google के साथ नहीं हूं, और मैं यहां जो कुछ भी लिखता हूं वह मेरे अपने विचार हैं।

@ 1e100 : आप "कुल वीएम" आकार को "वर्किंग सेट" आकार के साथ

(मैं एक पूर्व-Google-SRE भी हूं, और मैं मानता हूं कि ये सामान्य Google मिथक लगभग निश्चित रूप से निर्णय में गए हैं कि k8s पर भी स्वैप को अक्षम करना ठीक था (या वांछनीय भी)। मैंने कई Google टीमों को जाते देखा सीखने के माध्यम से कि स्वैप को अक्षम करना स्वैपिंग को अक्षम नहीं करता है, और कुल मेमोरी अपशिष्ट जो केवल स्मृति के लिए "कठिन" (ओम-किल) सीमा का वर्णन करता है - ये ठीक कुछ चीजें हैं जिन्हें मैं k8s के साथ सुधारना चाहता हूं। वहां अब उपलब्ध कई cgroup/स्वैप ट्यून करने योग्य नॉब हैं जो हमारे पास नहीं थे जब बोर्ग संसाधन मॉडल को शुरू में डिज़ाइन किया गया था, और मुझे विश्वास है कि हम इस तरह के थ्रो-बेबी-आउट-विद-बाथवाटर दृष्टिकोण के बिना वांछित परिणाम प्राप्त कर सकते हैं मैं यह भी नोट करूंगा कि बेहतर/ज्ञात सबसे खराब स्थिति (यानी: रीयल-टाइम व्यवहार) प्राप्त करने के लिए औसतन कम कुशल होने के लिए Google ट्रेडऑफ _अक्सर_ है और यह अक्सर Google के बाहर वांछित विकल्प _not_ होता है - छोटा/ कम मेजबान, अधिक आराम से एसएलओ, कम बजट, अधिक खराब-परिभाषित एड बैच की नौकरियां, गैर-संकलित ढेर-अक्षम भाषाओं का अधिक उपयोग, आदि)

अनाम स्मृति की अदला-बदली नहीं होगी। कुछ भी मेमोरी मैप की गई (प्रोग्राम कोड और डेटा सहित) मेमोरी प्रेशर होने पर भी स्वैप कर सकती है, इसलिए मैंने सुझाव दिया कि डिफ़ॉल्ट रूप से रैम की सीमा की आवश्यकता होनी चाहिए: इसे कम करने की संभावना को कम करने के लिए पहली जगह में मेमोरी प्रेशर है। ऐसे कार्यभार के लिए जिन्हें और भी सख्त गारंटी की आवश्यकता होती है, mlockall() और कम swappiness मूल्य भी होता है।

एक पूर्व Google SRE के रूप में आप यह तर्क नहीं दे सकते कि ऊपरी RAM सीमा को निर्दिष्ट नहीं करना, या जो कुछ भी वे चाहते हैं उसे स्वैप करने के लिए कार्यों को सक्षम करना एक अच्छी बात है, जब तक कि आप केवल एक विरोधाभासी नहीं बनना चाहते। मेमोरी मैप की गई फाइलों की अदला-बदली काफी खराब है, मिश्रण में और भी संभावित प्रदर्शन चट्टानों को पेश करना अच्छी बात नहीं है।

ये डिज़ाइन द्वारा साझा किए गए परिवेश हैं, और आप प्रोग्रामों के लिए एक-दूसरे के प्रदर्शन को अप्रत्याशित बनाने के तरीकों को समाप्त करना चाहते हैं, नए नहीं जोड़ना चाहते हैं। जैसा कि Google SRE कहते हैं, "आशा कोई रणनीति नहीं है"। स्वैप थ्रैशिंग सबसे आसान तरीका है जिससे मैं लिनक्स मशीन को पूरी तरह से और अपरिवर्तनीय रूप से लॉक करने के लिए जानता हूं, भले ही आप एसएसडी को स्वैप कर रहे हों। यह अच्छा नहीं हो सकता, भले ही आप मशीन पर सिर्फ एक कार्यभार चला रहे हों, एक दो दर्जन को तो छोड़ दें। कुछ कार्यों/पॉड्स के साथ छोटे समूहों में सहसंबद्ध विफलताएं विशेष रूप से दर्दनाक हो सकती हैं।

यदि कोई चाहे तो आज भी स्वैप चेक को अनदेखा कर सकता है, लेकिन इस स्पष्ट समझ के साथ कि उस मामले में सभी दांव बंद हैं।

हां, पूरी तरह से सहमत हैं कि हमें एक "आकार" की आवश्यकता है जिसका उपयोग हम शेड्यूलिंग के लिए करते हैं और (अनजाने में) ओवरकमिट से बचने के लिए करते हैं। और हम वैश्विक वीएम थ्रैश से भी बचना चाहते हैं, क्योंकि लिनक्स के पास इससे उबरने में खराब समय है। हम _do_ चाहते हैं कि कर्नेल _able_ हो ताकि अनाम मेमोरी को स्वैप किया जा सके और उस रैम को किसी और चीज़ के लिए पुन: उपयोग किया जा सके, जहां यह समझ में आता है, क्योंकि यह उस सिस्टम से सख्ती से बेहतर है जो ऐसा नहीं कर सकता। आदर्श रूप से हम अलग-अलग कंटेनरों को रैम/डिस्क ट्रेडऑफ़ का प्रबंधन करने में सक्षम होना चाहते हैं, और अन्य कंटेनरों पर न्यूनतम प्रभाव के साथ अपने स्वयं के संसाधन (अधिक/अंडरआवंटित) विकल्पों के परिणामों का सामना करना चाहते हैं।

बस यह दिखाने के लिए कि मैं इसके साथ कहाँ जा रहा हूँ, मेरा वर्तमान स्ट्रॉमैन प्रस्ताव है:

• रूपक यह है कि प्रत्येक कंटेनर ऐसा व्यवहार करता है जैसे यह मशीन पर एक निश्चित मात्रा में रैम ( limits.memory द्वारा दिया गया) और स्वैप के साथ होता है।
• अन्य संसाधनों के समान: requests.memory पर आधारित शेड्यूल, limits.memory आधार पर सीमा लागू करें। इस मामले में "मेमोरी" का अर्थ है "राम" - स्वैप उपयोग निःशुल्क है।
• विशेष रूप से k8s requests.memory -> cgroup memory.low (किसी भी overcommit कारक द्वारा कम किया गया); k8s limits.memory -> cgroup memory.high ।
• यदि कोई कंटेनर अपनी कॉन्फ़िगर की गई मेमोरी सीमा से अधिक हो जाता है, तो यह स्वैप करना शुरू कर देता है - उपलब्ध मुफ्त रैम की मात्रा की परवाह किए बिना। cgroups के लिए धन्यवाद, यह _not_ केवल VM उपयोग है, लेकिन इसमें कंटेनर के कारण ब्लॉक कैश, सॉकेट बफ़र्स आदि भी शामिल हैं। यह हमें अन्य कंटेनरों (या होस्ट प्रक्रियाओं) पर स्मृति दबाव डालने से रोकता है। बेदखल करने के लिए किसी पृष्ठ की तलाश करते समय, कर्नेल उन कंटेनरों की तलाश करेगा जो उनके मेमोरी अनुरोध आकार से अधिक हैं।
• कुल-स्वैप-उपयोग क्यूबलेट सॉफ्ट सीमा का परिचय दें जहां k8s होस्ट पर नए पॉड्स को शेड्यूल करना बंद कर देगा (बिल्कुल अन्य "साझा फ़ाइल सिस्टम" जैसे कि इमेजफ़्स की तरह)।
• अगर हम टोटल-स्वैप-यूसेज हार्ड लिमिट तक पहुंच जाते हैं, तो क्यूओएस-क्लास/प्राथमिकता और "अनुरोधों" से ऊपर के वीएम आकार के आधार पर पॉड्स को निकालना शुरू करें (बिल्कुल अन्य "साझा फाइल सिस्टम" जैसे कि इमेजफ्स की तरह)।
• यदि कोई कंटेनर अपने कामकाजी सेट ( requests.memory ) से बहुत अधिक है तो यह थ्रैश हो सकता है (यदि यह limits.memory या मेजबान पर पर्याप्त रैम उपलब्ध न हो)। हम संसाधन तंत्र के माध्यम से इस बारे में स्पष्ट रूप से कुछ भी नहीं करते हैं। यदि कंटेनर स्वैप-थ्रैशिंग है तो यह (संभवतः) जीवंतता/तत्परता जांच जांच में विफल हो जाएगा और उस तंत्र के माध्यम से मारा जाएगा (यानी: स्वैप-थ्रैशिंग ठीक है यदि हमारे पास कोई कॉन्फ़िगर प्रतिक्रिया एसएलए नहीं है)।

अंतिम परिणाम यह है कि व्यवस्थापक प्रत्येक सिस्टम पर "पर्याप्त" स्वैप को कॉन्फ़िगर करने के लिए जिम्मेदार है। एप्लिकेशन को limits.memory को उस _max_ ram के साथ कॉन्फ़िगर करना चाहिए जिसका वे कभी भी उपयोग करना चाहते हैं, और requests.memory को उनके इच्छित कार्य सेट (कर्नेल बफ़र्स, आदि सहित) के साथ कॉन्फ़िगर करना चाहिए। अन्य संसाधनों की तरह, qos वर्ग गारंटीकृत (सीमा==अनुरोध), फटने योग्य (सीमा अपरिभाषित या !=अनुरोध), सर्वोत्तम प्रयास (कोई सीमा या अनुरोध नहीं) अभी भी लागू होते हैं। विशेष रूप से, यह फटने योग्य प्रक्रियाओं को उनके इच्छित कार्य-सेट (कोई बड़ा सुरक्षा बफर नहीं) के करीब घोषित करने के लिए प्रोत्साहित करता है, जो कुशल आवंटन की अनुमति देता है (आदर्श रूप से काम करने वाले सेट के लिए आवंटित राम का 100%) और कंटेनर से अधिक होने पर एक सुचारू प्रदर्शन गिरावट देता है - सीपीयू जैसे अन्य "क्षमा करने वाले" संसाधनों की तरह।

मुझे लगता है कि यह लिनक्स cgroups के भीतर लागू करने योग्य है, अलगाव की चिंताओं को संबोधित करता है, अन्य k8s संसाधनों द्वारा निर्धारित वैचारिक मिसालों को जारी रखता है, और स्वैप अक्षम होने पर मौजूदा व्यवहार को नीचा दिखाता है (माइग्रेशन को आसान बनाता है)। मेरे पास एकमात्र खुला प्रश्न यह है कि क्या यह _ पहले से ही लागू है ("स्वैप्स" क्यूबलेट सॉफ्ट/हार्ड लिमिट घटाकर) - इससे पहले कि मैं एक ठोस प्रस्ताव और कार्रवाई आइटम लिख सकूं, मुझे वास्तविक क्यूबलेट/सीआरआई सीग्रुप्स कोड को पढ़ने और पढ़ने की जरूरत है .

उपरोक्त पर टिप्पणियां/चर्चा शायद इस जीथब मुद्दे में उपयुक्त नहीं हैं (यह एक खराब चर्चा मंच है)। अगर उपरोक्त में कुछ भी गलत है तो मैं k8s slack पर guslees के फीडबैक का स्वागत करता हूं, अन्यथा मैं एक उचित दस्तावेज़ लिखूंगा और किसी बिंदु पर सामान्य डिज़ाइन चर्चा के माध्यम से जाऊंगा।

मैं एक औपचारिक दस्तावेज़ लिखने की सलाह देता हूँ ताकि हमारे पास चर्चा के लिए एक बेहतर मंच हो सके।

माना। मुझे केईपी लिखने में मदद करने में खुशी हो रही है, क्योंकि इसके लिए मेरे पास कुछ निश्चित विचार हैं, लेकिन मैंने पहले कभी ऐसा नहीं किया है और इसके बजाय पतवार पर अधिक अनुभवी हाथ होगा।

लेकिन, साथ ही, मेरे पास अपने खाली समय में स्लैक चैनल के साथ बने रहने के लिए बैंडविड्थ नहीं है; यदि समन्वय करने का कोई और अतुल्यकालिक तरीका है, तो मुझे बताएं।

बस चीजों को जीवित रखने के लिए: मुझे अभी भी केईपी पर काम करने और/या इसके कार्यान्वयन में बहुत दिलचस्पी है; एक बार चीजें ठीक हो जाएं (मेरे पास अगले सप्ताहांत की तैयारी के लिए एक वर्कशॉप है), मैं स्लैक चैनल से जुड़ने की कोशिश करूंगा।

नमस्ते क्या वर्तमान में इस मुद्दे पर कोई सार्वजनिक चर्चा हो रही है? (K8s स्लैक फिलहाल सभी के लिए खुला नहीं है, और मुझे लगता है कि यह कुछ समय के लिए नहीं होगा)।

@leonaves वर्तमान में AFAIK पर चल रहे स्लैक पर कोई चर्चा नहीं है। @guslees की अंतिम टिप्पणी चर्चा की अंतिम है। ध्यान दें कि कुबेरनेट्स/एन्हांसमेंट रेपो में विवरण के साथ एक केईपी होना चाहिए ताकि चीजों को बंद किया जा सके और संभवत: मेलिंग लिस्ट थ्रेड भी।

ऐसा लगता है कि सुरंग को फिर से खोलने के साथ-साथ बहुत जल्द सुरंग का अंत हो जाएगा। मेरी उँगलियों को क्रॉस करो।

जैसा कि यह पता चला है, मेरे पास अभी तक एक और स्लैक चैनल में शामिल होने के लिए मानसिक बैंडविड्थ नहीं है। मैं अभी भी इस ईमेल पर सहयोग करने के लिए तैयार हूं।

उन लोगों के लिए एक समाधान जो वास्तव में स्वैप चाहते हैं। अगर तुम

• क्यूबलेट को --fail-swap-on=false
• अपने नोड्स में स्वैप जोड़ें
• कंटेनर जो _not_ स्मृति आवश्यकता निर्दिष्ट करते हैं, डिफ़ॉल्ट रूप से स्वैप सहित सभी मशीन मेमोरी का उपयोग करने में सक्षम होंगे।

हम यही तो कर रहे हैं। या कम से कम, मुझे पूरा यकीन है कि यह है, मैंने वास्तव में इसे व्यक्तिगत रूप से लागू नहीं किया था, लेकिन मैं यही इकट्ठा करता हूं।

यह वास्तव में केवल एक व्यवहार्य रणनीति हो सकती है यदि आपका कोई भी कंटेनर कभी भी स्पष्ट स्मृति आवश्यकता निर्दिष्ट नहीं करता है ...

क्या यह तरीका अब काम नहीं कर रहा है !? मैं स्वैप चालू करता हूं और मेमोरी सेटिंग के बिना एक पॉड तैनात करता हूं, और यह कंटेनर मिला

$ docker inspect <dockerID> | grep Memory
            "Memory": 0,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": 0,
            "MemorySwappiness": -1

मेमोरीस्वैप "0" है, जिसका अर्थ है कि यह कंटेनर स्वैप तक नहीं पहुंच सकता :(

90d निष्क्रियता के बाद मुद्दे पुराने हो जाते हैं।
/remove-lifecycle stale साथ समस्या को ताज़ा के रूप में चिह्नित करें।
अतिरिक्त 30d निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

अगर इस मुद्दे को अभी बंद करना सुरक्षित है तो कृपया /close साथ ऐसा करें।

sig-testing, Kubernetes/test-infra और/या fejta को फ़ीडबैक भेजें।
/जीवनचक्र बासी

/निकालें-जीवनचक्र बासी।

/निकालें-जीवनचक्र बासी

इस अंक के पाठकों के लिए इसे यहां एक और संदर्भ के रूप में छोड़ने जा रहे हैं: https://chrisdown.name/2018/01/02/in-defence-of-swap.html

संबंधित-से: https://serverfault.com/questions/881517/why-disable-swap-on-kubernetes

90d निष्क्रियता के बाद मुद्दे पुराने हो जाते हैं।
/remove-lifecycle stale साथ समस्या को ताज़ा के रूप में चिह्नित करें।
अतिरिक्त 30d निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

अगर इस मुद्दे को अभी बंद करना सुरक्षित है तो कृपया /close साथ ऐसा करें।

sig-testing, Kubernetes/test-infra और/या fejta को फ़ीडबैक भेजें।
/जीवनचक्र बासी

/निकालें-जीवनचक्र बासी

कुछ उपयोग के मामलों में इस सुविधा की वास्तव में आवश्यकता है। वर्तमान में हम मशीन सीखने के लिए k8s का उपयोग कर रहे हैं और कभी-कभी हमें स्मृति में बड़े मॉडल लोड करने की आवश्यकता होती है (हमारे मामले में कभी-कभी 500 एमबी प्रति एपीआई अनुरोध!), और भौतिक स्मृति की सीमाएं गंभीर समस्याएं पैदा कर रही हैं। स्केलिंग आउट तकनीकी पीओवी से काम करेगा लेकिन लागत छत के माध्यम से जाएगी, अगर हमारे पास एक विकल्प के रूप में वर्चुअल मेमोरी होती तो यह बहुत अच्छा होता।

कोई मौका है कि यह टिकट फिर से रोडमैप पर वापस आ जाए?

एमएमएपी के लिए एक मामले की तरह लगता है।

मुझे भी इस फीचर में बहुत दिलचस्पी है। क्या इस पर कोई खबर है?

मुझे इस पर ध्यान देना शुरू करने में खुशी होगी जब मेरे पास समय होगा, जो अभी कम आपूर्ति में है, लेकिन एक विहित मामला या दो होना अच्छा होगा जो समस्या को बढ़ा देता है ताकि इसे और अधिक पूरी तरह से चित्रित किया जा सके ("इससे परे" पिटाई शुरू हो जाती है और सब कुछ नरक में चला जाता है") और अंतिम दृष्टिकोण और फिक्स मान्य।

किसी भी संभावित समाधान को स्वैप के सुरक्षा प्रभावों पर भी विचार करना चाहिए। यह, जाहिर है, यूनिक्स के वातावरण में चल रही किसी भी चीज़ के बारे में सच है, लेकिन अगर लोगों को k8s पॉड्स को बिना स्वैप की छद्म गारंटी के साथ चलाने की आदत हो गई है और स्मृति अनुशासन के बारे में आलसी हो गए हैं, तो यह एक बहुत ही कठोर आश्चर्य हो सकता है यदि यह इसके द्वारा सक्षम है चूक जाना।

एक विहित मामला या दो होना अच्छा होगा जो समस्या को बढ़ा देता है ताकि इसे और अधिक पूरी तरह से चित्रित किया जा सके

यह एक केईपी की तरह लगता है।

किसी भी संभावित समाधान को स्वैप के सुरक्षा प्रभावों पर भी विचार करना चाहिए। यह, जाहिर है, यूनिक्स के वातावरण में चल रही किसी भी चीज़ के बारे में सच है, लेकिन अगर लोगों को k8s पॉड्स को बिना स्वैप की छद्म गारंटी के साथ चलाने की आदत हो गई है और स्मृति अनुशासन के बारे में आलसी हो गए हैं, तो यह एक बहुत ही कठोर आश्चर्य हो सकता है यदि यह इसके द्वारा सक्षम है चूक जाना।

यह तर्क कंटेनरों के मिश्रण में चलने वाली किसी भी प्रक्रिया पर लागू होगा, भले ही कुबेरनेट्स उपयोग में हो या नहीं।

माना! लेकिन डॉकर पहले से ही स्वैप के साथ चलने का स्पष्ट रूप से समर्थन करता है। Kubernetes स्पष्ट रूप से नहीं करता है (हालाँकि आप इसे बाध्य कर सकते हैं)। मेरा तर्क यह है कि इसे कम से कम बाहर बुलाया जाना चाहिए, क्योंकि यह हर किसी के लिए खतरे के मॉडल में नहीं है, खासकर अगर उन्हें पहले इसके बारे में सोचना नहीं पड़ा है।

इसके अलावा हाँ, @sftim , यह करता है। :-) मुझे लगता है कि मैं जो कह रहा हूं वह यह है कि मैं एक केईपी में लिखना/योगदान देना चाहता हूं, लेकिन मैं एक न्यूनतम परीक्षण केस या दो देखना चाहता हूं जो किसी दिए गए परीक्षण प्रणाली पर समस्या का विश्वसनीय रूप से अभ्यास करने से पहले समस्या का अभ्यास करता है। ताकि हम सुनिश्चित हो सकें कि हम सही समस्याओं का समाधान कर रहे हैं।

@superdave आपके मन में किस तरह का टेस्ट केस है?

यहाँ एक तुच्छ परीक्षण है:

1. 1 नोड, 16 GiB RAM और 64GiB पेजफाइल के साथ एक क्लस्टर सेट करें।
2. 20 पॉड्स शेड्यूल करने का प्रयास करें, प्रत्येक में 1GiB मेमोरी अनुरोध और 1GiB मेमोरी सीमा है।
3. ध्यान दें कि यह सब शेड्यूल नहीं करता है।

यहाँ एक और है:

1. 6 मशीनें स्थापित करें, जिनमें से प्रत्येक में 16 जीबी रैम और 64 जीबी पेजफाइल है।
2. कुबेरनेट्स क्लस्टर के रूप में इन मशीनों को कॉन्फ़िगर करने के लिए डिफ़ॉल्ट विकल्पों के साथ kubeadm का उपयोग करने का प्रयास करें।
3. ध्यान दें कि kubeadm स्वैप के उपयोग में होने से खुश नहीं है।

अब अधिकांश सम्मानित क्लाउड प्लेटफॉर्म पर एसएसडी के लिए बहुत बड़ा बदलाव है और लिनक्स पर एसएसडी पर स्वैपिंग के लिए समर्पित अनुकूलन को देखते हुए https://lwn.net/Articles/704478/ संपीड़न की अतिरिक्त संभावना के साथ, यह स्थिति स्वैप का उपयोग करने का एक नया अवसर बनाती है। स्मृति दबाव के मामले में अतिरिक्त रैम के लिए अनुमानित और तेज़ संसाधन।
अक्षम स्वैप व्यर्थ संसाधन बन जाता है उसी तरह अप्रयुक्त RAM बर्बाद हो जाता है यदि I/O बफ़र्स के लिए उपयोग नहीं किया जाता है।

@superdave

माना! लेकिन डॉकर पहले से ही स्वैप के साथ चलने का स्पष्ट रूप से समर्थन करता है। Kubernetes स्पष्ट रूप से नहीं करता है (हालाँकि आप इसे बाध्य कर सकते हैं)। मेरा तर्क यह है कि इसे कम से कम बाहर बुलाया जाना चाहिए, क्योंकि यह हर किसी के लिए खतरे के मॉडल में नहीं है, खासकर अगर उन्हें पहले इसके बारे में सोचना नहीं पड़ा है।

उस स्थिति में यह मान लेना उचित होगा कि kubelet इसकी मेमोरी स्पेस mlock() और OOM किल प्राथमिकता को कम कर देगा ताकि स्वैप आउट या OOM मारे जाने से बचा जा सके, और सभी कंटेनरों को cgroups में swapiness साथ चलाया जा सके। 0 swapiness सेट है। अगर कोई फॉर्म स्वैपिंग का लाभ लेना चाहता है तो वह पॉड में विशेष कंटेनर के लिए एक विकल्प यानी enableSwapiness: 50 उपयोग करके ऑप्ट-इन कर सकता है।
कोई आश्चर्य नहीं, बैटरी शामिल है।

@sftim वे प्रदर्शित करेंगे कि a) क्यूबलेट कंटेनरों को शेड्यूल नहीं करना चाहता है और b) क्यूबलेट डिफ़ॉल्ट रूप से स्वैप के साथ नहीं चलेगा। मैं जो व्यायाम करना चाहता हूं वह है @derekwaynecarr द्वारा धागे के शीर्ष पर

स्वैप के लिए समर्थन गैर-तुच्छ है। गारंटीकृत पॉड्स को कभी भी स्वैप की आवश्यकता नहीं होनी चाहिए। बर्स्टेबल पॉड्स को स्वैप की आवश्यकता के बिना उनके अनुरोधों को पूरा करना चाहिए। BestEffort पॉड्स की कोई गारंटी नहीं होती है। क्यूबलेट में अभी पॉड्स में सही मात्रा में अनुमानित व्यवहार प्रदान करने के लिए स्मार्ट की कमी है।

हमने इस विषय पर इस वर्ष की शुरुआत में आमने-सामने संसाधन एमजीएमटी पर चर्चा की। हम इसे प्राप्त होने वाले लाभों के सापेक्ष निकट अवधि में इससे निपटने में सुपर रुचि नहीं रखते हैं। हम दबाव का पता लगाने के आसपास विश्वसनीयता में सुधार करना पसंद करेंगे, और स्वैप के लिए अनुकूलित करने का प्रयास करने से पहले विलंबता के आसपास के मुद्दों को अनुकूलित करेंगे, लेकिन अगर यह आपके लिए एक उच्च प्राथमिकता है, तो हम आपकी मदद से प्यार करेंगे।

और इसके ठीक नीचे @matthiasr से

यहां चर्चा में और संदर्भ हैं: # 7294 - स्वैप उपलब्ध होने से स्मृति सीमाओं के साथ बहुत ही अजीब और खराब बातचीत होती है। उदाहरण के लिए, एक कंटेनर जो अपनी मेमोरी सीमा को हिट करता है, वह _then_ स्वैप में फैलना शुरू कर देगा (यह f4edaf2 के बाद से तय किया गया प्रतीत होता है - उन्हें किसी भी स्वैप का उपयोग करने की अनुमति नहीं होगी चाहे वह वहां हो या नहीं)।

वे दोनों पहले से देखे गए मुद्दों पर एक अच्छा दृष्टिकोण देते हैं, लेकिन ज्ञात, प्रतिलिपि प्रस्तुत करने योग्य परिदृश्यों की समझ प्राप्त करना अच्छा होगा जो समस्याओं को बढ़ा सकते हैं। मैं खुद उनके साथ आ सकता हूं, लेकिन अगर किसी और ने पहले ही ऐसा कर लिया है, तो यह एक पहिया है, मुझे फिर से आविष्कार करने में कोई दिक्कत नहीं होगी।

@superdave

माना! लेकिन डॉकर पहले से ही स्वैप के साथ चलने का स्पष्ट रूप से समर्थन करता है। Kubernetes स्पष्ट रूप से नहीं करता है (हालाँकि आप इसे बाध्य कर सकते हैं)। मेरा तर्क यह है कि इसे कम से कम बाहर बुलाया जाना चाहिए, क्योंकि यह हर किसी के लिए खतरे के मॉडल में नहीं है, खासकर अगर उन्हें पहले इसके बारे में सोचना नहीं पड़ा है।

उस स्थिति में यह मान लेना उचित होगा कि kubelet इसकी मेमोरी स्पेस mlock() और OOM किल प्राथमिकता को कम कर देगा ताकि स्वैप आउट या OOM मारे जाने से बचा जा सके, और सभी कंटेनरों को cgroups में swapiness साथ चलाया जा सके। 0 swapiness सेट है। अगर कोई फॉर्म स्वैपिंग का लाभ लेना चाहता है तो वह पॉड में विशेष कंटेनर के लिए एक विकल्प यानी enableSwapiness: 50 उपयोग करके ऑप्ट-इन कर सकता है।
कोई आश्चर्य नहीं, बैटरी शामिल है।

मुझे लगता है कि मैं यहां हर चीज से सहमत हूं। अप्रिय आश्चर्य से बचने के लिए वर्तमान व्यवहार के लिए डिफ़ॉल्ट।

यहां एक उदाहरण है कि एक साधारण एप्लिकेशन कैसा दिख सकता है, जहां किसी कारण से स्मृति का एक बड़ा हिस्सा आवंटित किया जाता है लेकिन फिर कभी एक्सेस नहीं किया जाता है। एक बार सभी उपलब्ध मेमोरी भर जाने के बाद, एप्लिकेशन या तो हैंग हो जाता है या एक अंतहीन लूप में गिर जाता है जो मूल रूप से संसाधनों को अवरुद्ध करता है या मेमोरी किलर को बाहर करने के लिए मजबूर करता है:

#include <iostream>
#include <vector>
#include <unistd.h>
int main() {
  std::vector<int> data;
  try
    {
        while(true) { data.resize(data.size() + 200); };
    }
    catch (const std::bad_alloc& ex)
    {
        std::cerr << "Now we filled up memory, so assume we never access that stuff again and just moved on, or we're stuck in an endless loop of some sort...";
        while(true) { usleep(20000); };
    }
  return 0;
}

उन लोगों के लिए एक समाधान जो वास्तव में स्वैप चाहते हैं। अगर तुम

• क्यूबलेट को --fail-swap-on=false
• अपने नोड्स में स्वैप जोड़ें
• कंटेनर जो _not_ स्मृति आवश्यकता निर्दिष्ट करते हैं, डिफ़ॉल्ट रूप से स्वैप सहित सभी मशीन मेमोरी का उपयोग करने में सक्षम होंगे।

हम यही तो कर रहे हैं। या कम से कम, मुझे पूरा यकीन है कि यह है, मैंने वास्तव में इसे व्यक्तिगत रूप से लागू नहीं किया था, लेकिन मैं यही इकट्ठा करता हूं।

यह वास्तव में केवल एक व्यवहार्य रणनीति हो सकती है यदि आपका कोई भी कंटेनर कभी भी स्पष्ट स्मृति आवश्यकता निर्दिष्ट नहीं करता है ...

हाय @hjwp , आपकी जानकारी के लिए धन्यवाद। यह वास्तव में बहुत मदद करता है!

क्या मैं इसके बाद एक प्रश्न पूछ सकता हूँ?

जैसा आपने कहा था सब कुछ सेट करने के बाद, क्या कंटेनरों द्वारा स्वैप मेमोरी उपयोग के उपयोग को सीमित करने का कोई तरीका है?

मैं डॉकर के --memory-swap पैरा सेट करने के बारे में सोच रहा था
https://docs.docker.com/config/containers/resource_constraints/# --memory-swap-details
वर्तमान में, मेरे कंटेनर में स्वैप उपयोग की कोई सीमा नहीं है ( "मेमोरीस्वैप": -1 )

sudo docker inspect 482d70f73c7c | grep Memory
            "Memory": 671088640,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": -1,
            "MemorySwappiness": null,

लेकिन मैं इस परम को k8s में उजागर नहीं कर सका।

वैसे, क्या पॉड मेमोरी की सीमा भी स्वैप के उपयोग को रोक देगी?

मेरी vm-संबंधित सेटिंग्स

vm.overcommit_kbytes = 0
vm.overcommit_memory = 1
vm.overcommit_ratio = 50
vm.swappiness = 20
vm.vfs_cache_pressure = 1000

शुक्रिया!

@pai911 मुझे नहीं लगता कि यह संभव है,

वर्तमान में, CRI का समर्थन नहीं करता है कि, देखना यह है, वहाँ की तरह कोई विकल्प नहीं है --memory-swap डोकर में

हालांकि यह सीआरआई सीमा है, ओसीआई स्पेक इस विकल्प का समर्थन

एक संभव (सैद्धांतिक रूप से) समाधान विशेषाधिकार प्राप्त डेमनसेट बनाना है जो बदले में पॉड से एनोटेशन डेटा पढ़ता है, और फिर डेमनसेट मैन्युअल रूप से cgroup मान को संपादित करता है

सीग्रुप

हाय @ विन-टी,

धन्यवाद प्रतिक्रिया देना के लिए!

तो अभी के लिए, यह विकल्प केवल आंतरिक उपयोग के लिए है?

क्या आपको पता है कि इस --memory-swap विकल्प के लिए cgroup मान क्या मैप किया गया है?

तो अभी के लिए, यह विकल्प केवल आंतरिक उपयोग के लिए है?

हां, आप इस विकल्प को सेट नहीं कर सकते, क्योंकि वे k8s . में प्रदर्शित नहीं होते हैं

Btw, MemorySwap डोकर में निरीक्षण के साथ ही होना चाहिए Memory के अनुसार इस , मैं नहीं जानता कि आप कैसे प्राप्त कर सकते हैं -1 आपके डोकर में निरीक्षण

क्या आपको पता है कि इस --memory-swap विकल्प के लिए cgroup मान क्या मैप किया गया है?

• --memory डॉकटर मैप में memory.limit_in_bytes cgroup v1 . में
• --memory-swap डॉकटर मैप में memory.memsw.limit_in_bytes cgroup v1 . में

@ विन-टी बहुत बहुत धन्यवाद!

मैं निम्नलिखित संस्करण का उपयोग कर रहा हूँ

Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.5", GitCommit:"20c265fef0741dd71a66480e35bd69f18351daea", GitTreeState:"clean", BuildDate:"2019-10-15T19:16:51Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.10", GitCommit:"1bea6c00a7055edef03f1d4bb58b773fa8917f11", GitTreeState:"clean", BuildDate:"2020-02-11T20:05:26Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}

और मैंने इतिहास देखा। ऐसा लगता है कि इस कमिट में फिक्स जोड़ा गया था

शायद यह मेरे द्वारा चलाए जा रहे संस्करण में शामिल नहीं है?

तो अभी के लिए, यह विकल्प केवल आंतरिक उपयोग के लिए है?

हां, आप इस विकल्प को सेट नहीं कर सकते, क्योंकि वे k8s . में प्रदर्शित नहीं होते हैं

Btw, MemorySwap डोकर में निरीक्षण के साथ ही होना चाहिए Memory के अनुसार इस , मैं नहीं जानता कि आप कैसे प्राप्त कर सकते हैं -1 आपके डोकर में निरीक्षण

क्या आपको पता है कि इस --memory-swap विकल्प के लिए cgroup मान क्या मैप किया गया है?

• --memory डॉकटर मैप में memory.limit_in_bytes cgroup v1 . में
• --memory-swap डॉकटर मैप में memory.memsw.limit_in_bytes cgroup v1 . में

यह गलत है।

मैं कोप्स + डेबियन का उपयोग कर रहा था, और डॉकर निरीक्षण से पता चलता है कि स्वैप मेमोरी की कोई सीमा नहीं है
(डॉकर मेरे द्वारा पहले पोस्ट की गई जानकारी का निरीक्षण करता है)

लेकिन फिर मैंने अमेज़ॅन लिनक्स छवि पर स्विच किया, और यही मुझे मिला

            "Memory": 671088640,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": 671088640,
            "MemorySwappiness": null,

मैं कुछ और जांच करूँगा और देख सकता हूँ कि क्या यह एक बग है

तो अभी के लिए, यह विकल्प केवल आंतरिक उपयोग के लिए है?

हां, आप इस विकल्प को सेट नहीं कर सकते, क्योंकि वे k8s . में प्रदर्शित नहीं होते हैं
Btw, MemorySwap डोकर में निरीक्षण के साथ ही होना चाहिए Memory के अनुसार इस , मैं नहीं जानता कि आप कैसे प्राप्त कर सकते हैं -1 आपके डोकर में निरीक्षण

क्या आपको पता है कि इस --memory-swap विकल्प के लिए cgroup मान क्या मैप किया गया है?

• --memory डॉकटर मैप में memory.limit_in_bytes cgroup v1 . में
• --memory-swap डॉकटर मैप में memory.memsw.limit_in_bytes cgroup v1 . में

यह गलत है।

मैं कोप्स + डेबियन का उपयोग कर रहा था, और डॉकर निरीक्षण से पता चलता है कि स्वैप मेमोरी की कोई सीमा नहीं है
(डॉकर मेरे द्वारा पहले पोस्ट की गई जानकारी का निरीक्षण करता है)

लेकिन फिर मैंने अमेज़ॅन लिनक्स छवि पर स्विच किया, और यही मुझे मिला

            "Memory": 671088640,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": 671088640,
            "MemorySwappiness": null,

मैं कुछ और जांच करूँगा और देख सकता हूँ कि क्या यह एक बग है

मैं अब इस मुद्दे को पुन: पेश कर सकता हूं जो आधिकारिक डेबियन छवि में मौजूद है kops

ऐसा लगता है कि यह कोप्स आधिकारिक छवि स्वैप मेमोरी को असीमित बना देगी
kope.io/k8s-1.15-debian-stretch-amd64-hvm-ebs-2020-01-17

प्रजनन चरण:

मेरे kops इंस्टेंस समूह को निम्न के रूप में परिभाषित किया गया है:

apiVersion: kops.k8s.io/v1alpha2
kind: InstanceGroup
metadata:
  creationTimestamp: "2020-03-12T06:33:09Z"
  generation: 5
  labels:
    kops.k8s.io/cluster: solrcluster.k8s.local
  name: node-2
spec:
  additionalUserData:
  - content: |
      #!/bin/sh
      sudo cp /etc/fstab /etc/fstab.bak
      sudo mkfs -t ext4 /dev/nvme1n1
      sudo mkdir /data
      sudo mount /dev/nvme1n1 /data
      echo '/dev/nvme1n1       /data   ext4    defaults,nofail        0       2' | sudo tee -a /etc/fstab
      sudo fallocate -l 2G /data/swapfile
      sudo chmod 600 /data/swapfile
      sudo mkswap /data/swapfile
      sudo swapon /data/swapfile
      echo '/data/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
      sudo sysctl vm.swappiness=10
      sudo sysctl vm.overcommit_memory=1
      echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf
      echo 'vm.overcommit_memory=1' | sudo tee -a /etc/sysctl.conf
    name: myscript.sh
    type: text/x-shellscript
  image: kope.io/k8s-1.15-debian-stretch-amd64-hvm-ebs-2020-01-17
  instanceProtection: true
  kubelet:
    failSwapOn: false
  machineType: t3.micro

कदम:

1. क्लस्टर के ऊपर और चलने के बाद।

2. निम्नलिखित संसाधन सेटिंग के साथ सोलर हेल्म चार्ट को परिनियोजित करें

resources:
  limits:
    cpu: "1"
    memory: 640Mi
  requests:
    cpu: 100m
    memory: 256Mi

** कोई अन्य पॉड भी काम करना चाहिए

1. कंटेनर आईडी खोजने के लिए कंटेनरों की सूची बनाएं
   sudo docker container ls

2. एक कंटेनर की मेमोरी पैराम्स का निरीक्षण करें
   sudo docker inspect d67a72bba427 | grep Memory

            "Memory": 671088640,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": -1,
            "MemorySwappiness": null,

क्या मुझे इस मुद्दे को कहीं जमा करना चाहिए? k8s या कोप्स?

कदम:

1. क्लस्टर के ऊपर और चलने के बाद।
2. निम्नलिखित संसाधन सेटिंग के साथ सोलर हेल्म चार्ट को परिनियोजित करें

resources:
  limits:
    cpu: "1"
    memory: 640Mi
  requests:
    cpu: 100m
    memory: 256Mi

** कोई अन्य पॉड भी काम करना चाहिए

1. कंटेनर आईडी खोजने के लिए कंटेनरों की सूची बनाएं
   sudo docker container ls
2. एक कंटेनर की मेमोरी पैराम्स का निरीक्षण करें
   sudo docker inspect d67a72bba427 | grep Memory

            "Memory": 671088640,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": -1,
            "MemorySwappiness": null,

क्या मुझे इस मुद्दे को कहीं जमा करना चाहिए? k8s या कोप्स?

मैं पुष्टि कर सकता हूं कि मैं केवल Amazon Linux पर सही व्यवहार देख सकता हूं
ami-0cbc6aae997c6538a : amzn2-ami-hvm-2.0.20200304.0-x86_64-gp2

            "Memory": 671088640,
            "CpusetMems": "",
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": 671088640,
            "MemorySwappiness": null,

वह है: "मेमोरी स्वैप" == "मेमोरी"

अन्य दो छवियों में एक ही सेटिंग है: "MemorySwap": -1 , जो असीमित स्वैप उपयोग की ओर ले जाती है।

• डेबियन
  
  
  
  • ami-075e61ad77b1269a7 : k8s-1.15-debian-stretch-amd64-hvm-ebs-2020-01-17
  
  
• उबंटू
  
  
  
  • ami-09a4a9ce71ff3f20b : ubuntu/images/hvm-ssd/ubuntu-bionic-18.04-amd64-server-20200112
  
  

तो मुझे लगता है कि यह k8s का मुद्दा हो सकता है?

प्रयोक्ता कहानियां:

(१) मेरे विक्रेता द्वारा प्रदान किया गया प्रोग्राम एक भाषा रनटाइम का उपयोग करता है जो प्रोग्राम कोड के स्रोत तक पहुंच को अनिवार्य करता है। इसके कारण, इनिशियलाइज़ करते समय, सभी प्रोग्राम सोर्स कोड को एक अलग मेमोरी एरिना में व्यवस्थित किया जाता है। एक बार प्रोग्राम शुरू हो जाने और कंटेनर तैयार हो जाने के बाद, इस मेमोरी को एक्सेस नहीं किया जाएगा (आप इसे साबित नहीं कर सकते, लेकिन यह नहीं होगा)। इसके अतिरिक्त, प्रोग्राम कस्टम OOM हैंडलिंग के लिए आरक्षित करने के लिए कुछ पृष्ठ आवंटित करता है। इस मेमोरी को स्वैप किया जा सकता है। मैं नहीं चाहता कि यह "मृत स्मृति" अन्य क्लस्टर अनुप्रयोगों को भीड़ दे। मैं ठीक से स्मृति की मात्रा की गणना कर सकता हूं जो मृत हो जाएगी और इसे पॉड स्पेक में स्वैप के अनुरोध के रूप में सूचीबद्ध कर सकता है।

(२) मैं एक मशीन लर्निंग या डेटा विश्लेषण कार्यभार चला रहा हूँ जहाँ मेमोरी का उपयोग अचानक गुब्बारा और पीछे हट सकता है। यह ठीक है अगर ये एप्लिकेशन धीमा हो जाते हैं, जब तक कि वे समाप्त नहीं होते हैं और अंततः समाप्त हो जाते हैं। जब ये मेमोरी गुब्बारे होते हैं तो मैं निष्कासन को कम करने के लिए क्लस्टर को स्वैप के साथ प्रावधान करना चाहता हूं। इन पॉड्स में मेमोरी और स्वैप के लिए कम अनुरोध होंगे, एक मध्यम मेमोरी लिमिट - शायद बेसलाइन + एक वर्किंग सेट के लिए पर्याप्त - और एक बड़ी स्वैप लिमिट।

(३) मैं एक दुभाषिया में एक वेब सर्वर चला रहा हूं (उदाहरण के लिए रेल पर रूबी) जिसे कभी-कभी फोर्क + निष्पादन की आवश्यकता होती है। सख्त स्मृति लेखांकन परिणाम फोर्क विफलताओं में, जो अस्वीकार्य हैं। मैं स्वैप का प्रावधान करना चाहता हूं ताकि कर्नेल में फोर्क और निष्पादन कॉल के बीच प्रक्रिया व्यवहार को कवर करने के लिए गारंटीकृत मेमोरी हेडरूम हो। vm.swappiness मान को स्वैपिंग को बेहद हतोत्साहित करने के लिए सेट किया जा सकता है, और यदि स्वैप वास्तव में उत्पादन के दौरान उपयोग किया जाता है तो मैं संचालन को सूचित करने के लिए अलर्ट सेट करता हूं। पॉड स्पेक स्वैप अनुरोध और सीमा को उसी मान पर सेट करेगा।

हाल ही में हमने अपनी सभी डॉकटर-आधारित सेवाओं को कुबेरनेट्स में माइग्रेट करने का प्रयास किया, लेकिन स्वैप असमर्थित होने के कारण परियोजना को छोड़ना पड़ा।

हमने पाया कि वर्तमान में हम स्वैप सक्षम के साथ चल रहे कंटेनरों की ठीक उसी संख्या का समर्थन करने के लिए हार्डवेयर की मात्रा का 3 गुना प्रावधान करने की आवश्यकता होगी।

मुख्य मुद्दा यह है कि हमारे कार्यभार में कई कंटेनर होते हैं जो 1Gb या उससे अधिक मेमोरी (या स्वैप) तक का उपयोग कर सकते हैं, लेकिन सामान्य रूप से सामान्य रूप से संचालन करते समय लगभग 50Mb का उपयोग करते हैं।

स्वैप करने में सक्षम नहीं होने का मतलब यह था कि जब बड़े 'नौकरियों' से निपटने की आवश्यकता होती है, तो स्वैप के ब्लॉक उपलब्ध होने के बजाय हमें सबसे बड़े संभावित भार के लिए सबकुछ डिजाइन करना पड़ता है।

हमने कुबेरनेट्स में अपने प्रवास को छोड़ दिया और अस्थायी रूप से सब कुछ झुंड में स्थानांतरित कर दिया, इस उम्मीद में कि भविष्य में स्वैप का समर्थन किया जाएगा।

मुख्य मुद्दा यह है कि हमारे कार्यभार में कई कंटेनर होते हैं जो 1Gb या उससे अधिक मेमोरी (या स्वैप) तक का उपयोग कर सकते हैं, लेकिन सामान्य रूप से सामान्य रूप से संचालन करते समय लगभग 50Mb का उपयोग करते हैं।

कोई यह कहने का साहस कर सकता है कि उन कंटेनरों में चल रहे एप्लिकेशन अविश्वसनीय रूप से खराब लिखे गए हैं।

कोई यह कहने का साहस कर सकता है कि उन कंटेनरों में चल रहे एप्लिकेशन अविश्वसनीय रूप से खराब लिखे गए हैं।

यह एक तरह से अप्रासंगिक है, और उंगलियों की ओर इशारा करना शायद ही कभी रचनात्मक होता है। Kubernetes पारिस्थितिकी तंत्र एप्लिकेशन प्रोफाइल की विस्तृत श्रृंखला का समर्थन करने के लिए बनाया गया है, और उनमें से किसी एक को इस तरह से अलग करने का कोई मतलब नहीं है।

मुख्य मुद्दा यह है कि हमारे कार्यभार में कई कंटेनर होते हैं जो 1Gb या उससे अधिक मेमोरी (या स्वैप) तक का उपयोग कर सकते हैं, लेकिन सामान्य रूप से सामान्य रूप से संचालन करते समय लगभग 50Mb का उपयोग करते हैं।

कोई यह कहने का साहस कर सकता है कि उन कंटेनरों में चल रहे एप्लिकेशन अविश्वसनीय रूप से खराब लिखे गए हैं।

योग्य, यह एक कर्नेल सुविधा है, एक एप्लिकेशन shm फ़ाइल पर madvise(2) उपयोग कर सकता है, और हम मैडविज़ syscall को ब्लॉक नहीं करते हैं,
इसलिए यह उपयोगकर्ता के लिए उनके डिज़ाइन पर इस सुविधा का लाभ उठाने के योग्य है, आप यह नहीं कह सकते कि "अविश्वसनीय रूप से खराब लिखा गया है",

मुख्य मुद्दा यह है कि हमारे कार्यभार में कई कंटेनर होते हैं जो 1Gb या उससे अधिक मेमोरी (या स्वैप) तक का उपयोग कर सकते हैं, लेकिन सामान्य रूप से सामान्य रूप से संचालन करते समय लगभग 50Mb का उपयोग करते हैं।

कोई यह कहने का साहस कर सकता है कि उन कंटेनरों में चल रहे एप्लिकेशन अविश्वसनीय रूप से खराब लिखे गए हैं।

आपका उत्तर इंगित करता है कि आप कार्यभार को नहीं समझते हैं जिसके साथ कई डेवलपर काम कर रहे हैं।

मैंने जिस कार्यभार का उल्लेख किया है, वह उपयोगकर्ताओं द्वारा प्रदान किए गए विभिन्न आकार के डेटा सेट से संबंधित है, इसलिए संभवतः संसाधन आवश्यकताओं की एक बड़ी श्रृंखला है।

निश्चित रूप से, हम मेमोरी के उपयोग को लगातार बनाए रखने के लिए मेमोरी मैप की गई फ़ाइलों का उपयोग कर सकते हैं। फिर हमें स्मृति मैपिंग का उपयोग करने के लिए किसी भी पुस्तकालय को फिर से लिखना होगा, जिसमें कम से कम हर मौजूदा पुस्तकालय शामिल होगा ... कभी भी।

लेकिन तब हमने वह बनाया होगा जो अनिवार्य रूप से एक एप्लिकेशन विशिष्ट पेजफाइल है, जो लगभग निश्चित रूप से कर्नेल द्वारा प्रबंधित एक से भी बदतर प्रदर्शन करेगा।

कुछ कुबेरनेट्स परिनियोजन को स्वैप की आवश्यकता है

मेरे पास एक वैध उपयोग का मामला है - मैं एक ऑन-प्रिमाइसेस उत्पाद विकसित कर रहा हूं, लिनक्स डिस्ट्रो, कुबेदम के साथ शामिल है। डिजाइन द्वारा कोई क्षैतिज स्केलिंग नहीं। अवसरवादी स्मृति चोटियों और अभी भी कार्य (लेकिन धीमी) से बचने के लिए, मुझे निश्चित रूप से स्वैप की आवश्यकता है ।

स्वैप सक्षम के साथ kubeadm स्थापित करने के लिए

1. सामग्री के साथ /etc/systemd/system/kubelet.service.d/20-allow-swap.conf में एक फ़ाइल बनाएँ:

   [Service]
   Environment="KUBELET_EXTRA_ARGS=--fail-swap-on=false"
   

2. Daud

   sudo systemctl daemon-reload
   

3. ध्वज के साथ kubeadm प्रारंभ करें --ignore-preflight-errors=Swap

   kubeadm init --ignore-preflight-errors=Swap
   

https://stackoverflow.com/a/62158455/3191896

एक भोले सॉफ़्टवेयर डेवलपर के रूप में, गैर-स्वैप व्यवहार का अनुरोध करने के लिए समय संवेदनशील वर्कलोड वाले सिस्टम पॉड्स के लिए यह मेरे लिए पूरी तरह से उचित लगता है, और अन्य वर्कलोड (डिफ़ॉल्ट रूप से) एक सर्वोत्तम प्रयास श्रेणी में धकेल दिया जाता है। क्या इससे सभी चिंताओं का समाधान नहीं होगा?

मेरी अपनी जरूरतों के लिए, मेरे बहुत से ऐप्स कैश से लाभान्वित होते हैं। उस ने कहा, अगर किसी ऐप को अचानक मेमोरी की एक गुच्छा की आवश्यकता होती है, तो सबसे पुराने कैश को डिस्क पर धकेलना पसंद किया जाएगा यदि वे ऐप मेमोरी के दबाव को कम करने के अनुरोध का जवाब नहीं देते हैं, तो नए वर्कलोड को मेमोरी से बाहर निकलने देने के लिए, या है भौतिक मेमोरी के साथ बर्स्ट को वापस करने के लिए + रोलिंग परिनियोजन के लिए अधिक + संभावित नोड विफलता के लिए अधिक।

@metatic ने कहा:

बेशक, हम स्मृति उपयोग संगत रखने के लिए स्मृति मैप की गई फ़ाइलों का उपयोग कर सकते हैं। फिर हमें स्मृति मैपिंग का उपयोग करने के लिए किसी भी पुस्तकालय को फिर से लिखना होगा, जिसमें कम से कम हर मौजूदा पुस्तकालय शामिल होगा ... कभी भी।

लिनक्स मानक सी पुस्तकालय स्मृति आवंटनकर्ता को बदलने के लिए डिज़ाइन किया गया है; malloc , realloc और free को उस उद्देश्य के लिए पॉइंटर्स के माध्यम से बुलाया जाता है। तो आप केवल एक पुस्तकालय LD_PRELOAD कर सकते हैं जो उन्हें एक mmapped फ़ाइल से आवंटित करने के लिए ओवरराइड करेगा।

लेकिन तब हमने वह बनाया होगा जो अनिवार्य रूप से एक एप्लिकेशन विशिष्ट पेजफाइल है, जो लगभग निश्चित रूप से कर्नेल द्वारा प्रबंधित एक से भी बदतर प्रदर्शन करेगा।

यह वास्तव में सामान्य स्वैप के रूप में प्रदर्शन करेगा, क्योंकि इसे कर्नेल में उसी कोड द्वारा प्रबंधित किया जाएगा। फर्क सिर्फ इतना होगा कि इसकी प्राथमिकता को समायोजित करने के लिए स्वेपनेस पैरामीटर की कमी होगी।

मेरे पास एकमात्र खुला प्रश्न यह है कि क्या यह पहले से ही लागू है ("स्वैप्स" क्यूबलेट सॉफ्ट/हार्ड लिमिट घटाकर) - मुझे एक ठोस प्रस्ताव और कार्रवाई आइटम लिखने से पहले वास्तविक क्यूबलेट/सीआरआई सीग्रुप कोड को पढ़ने और पढ़ने की जरूरत है .

@anguslees ,
क्या आपने कभी व्यवहार की जांच करने के लिए इधर-उधर किया। यदि हां, तो क्या आप कुछ संकल्प या एक लिंक जोड़ सकते हैं, कृपया?

धन्यवाद,
जनवरी

क्या आपने कभी व्यवहार की जांच करने के लिए इधर-उधर किया। यदि हां, तो क्या आप कुछ संकल्प या एक लिंक जोड़ सकते हैं, कृपया?

मैंने नहीं। (मैंने डॉकर कोड में थोड़ी खुदाई की, लेकिन मैं अब तक इसके बारे में सब भूल गया हूं और मुझे फिर से शुरू करने की आवश्यकता होगी)

अन्य स्वयंसेवकों का स्वागत है! मुझे आशा है कि मैंने यह कहकर किसी से ऑक्सीजन नहीं चुराई कि मैं इस पर काम करूंगा और फिर इसका पालन करने में असफल रहा :(

@metatic की कहानी में जोड़ने के लिए:

मैं वर्तमान में कुबेरनेट्स के शीर्ष पर चल रहे अपने मेजबान के रूप में गिगालिक्सिर का उपयोग करता हूं। यह एक वेब ऐप है। कभी-कभी, क्लाइंट फ़ोटो का एक बैच अपलोड करते हैं, इसलिए मेरा ऐप उन्हें आकार देने के लिए (यूघ) इमेजमैजिक प्रक्रियाओं का एक समूह बनाता है। मेमोरी उपयोग स्पाइक्स, ओओएम हत्यारा ट्रिगर होता है, और मेरा ऐप नीचे चला जाता है (संक्षेप में) और अपलोड बर्बाद हो जाता है।

मुझे अंततः स्पाइकी उपयोग के कारण गिगालिक्सिर को टन अधिक भुगतान करना पड़ता है। जैसा कि अन्य ने उल्लेख किया है।

हो सकता है कि आपको डिज़ाइन के दृष्टिकोण से स्वैप पसंद न हो, लेकिन आपका निर्णय व्यवसायियों के पैसे खर्च कर रहा है ... और यह बेकार है।

कृपया ठीक करें। :)

यह भी मेरे लिए बहुत बड़ा मुद्दा है। मेरे उपयोग के मामले में, मुझे ज्यादातर समय ~ 100MB का उपयोग करने वाले पॉड चलाने की आवश्यकता होगी, लेकिन समय-समय पर, जब कोई उपयोगकर्ता विशिष्ट घटनाओं को ट्रिगर करता है, तो यह वापस छोड़ने से पहले कुछ मिनटों के लिए 2GB RAM तक फट सकता है (और नहीं, ऐसा इसलिए नहीं है क्योंकि यह खराब लिखा गया है, यह कार्यभार की वास्तविकता है)।
मैं 16GB मशीनों पर स्वैप के साथ एक बार में ऐसे लगभग सौ वर्कलोड चलाता हूं। मैं बस उस कार्यभार को कुबेरनेट्स पर नहीं ले जा सकता क्योंकि वह बिल्कुल भी काम नहीं करेगा। तो अभी, मेरे पास अपना खुद का ऑर्केस्ट्रेटर है जो गैर-कुबेरनेट सिस्टम पर इन वर्कलोड को चलाता है जबकि मेरा मुख्य ऐप कुबेरनेट्स में चलता है, और यह मेरे माइग्रेशन के उद्देश्य को k8s में हरा देता है। स्वैप के बिना, या तो यह मारा जाता है, या मुझे कुछ मिनटों के लिए हमेशा उपलब्ध रैम को बर्बाद करने की आवश्यकता होती है, जो ऐप्स फट सकते हैं (या नहीं)।

यदि आप एक सीपीयू सीमा निर्धारित कर सकते हैं, जो एक पॉड के लिए सीपीयू को थ्रॉटल करता है, तो आपको एक मेमोरी सीमा निर्धारित करने में सक्षम होना चाहिए जो एक पॉड द्वारा उपयोग की जाने वाली मेमोरी को थ्रॉटल करता है। मेमोरी सीमा तक पहुंचने पर एक पॉड को मारना उतना ही हास्यास्पद है जितना कि एक को मारना यदि वह अधिक CPU संसाधनों का उपयोग करता है जो कि CPU सीमा निर्धारित की गई थी (क्षमा करें, लेकिन प्रत्येक पॉड एक प्रतिकृति नहीं है जिसे बिना किसी परिणाम के नीचे लाया जा सकता है)।

Kubernetes नोड पर स्वैप सेट के साथ काम नहीं कर सकता क्योंकि यह पूरे क्लस्टर के पूरे प्रदर्शन को प्रभावित कर सकता है, ठीक है (हालांकि मुझे नहीं लगता कि यह एक वैध तर्क है)। आदर्श रूप से, यह करने की आवश्यकता होगी कि पॉड में स्वयं एक पॉड-स्तरीय स्वैप फ़ाइल होगी जिसमें केवल उन कंटेनरों के भीतर की प्रक्रियाओं की अदला-बदली की जाएगी। यह सैद्धांतिक रूप से पॉड्स के रैम उपयोग और प्रदर्शन (स्वैपिंग के कारण) को थ्रॉटल कर देगा, जो उनकी मेमोरी सीमा से अधिक है, ठीक उसी तरह जैसे सीपीयू उन्हें थ्रॉटल करता है।
दुर्भाग्य से, ऐसा नहीं लगता है कि cgroups एक स्वैप फ़ाइल निर्दिष्ट कर सकते हैं, केवल उनकी अदला-बदली, और आप कर्नेल को "स्वैप अगर मेम का उपयोग इस सीमा से ऊपर है" के बारे में नहीं बता सकते हैं, क्योंकि इसके बजाय ऐसा लगता है कि अंतिम के आधार पर स्वैप कब करना है पहुंच और अन्य मीट्रिक।

लेकिन इस बीच, एक नोड पर स्वैप क्यों न होने दें, उन पॉड्स के लिए स्वैपनेस को 0 पर सेट करें जिनकी कोई सीमा निर्धारित नहीं है, और जब एक सीमा निर्धारित की जाती है (या "swapInsteadOfKill" कहने के लिए कोई अन्य विशिष्ट फ़ील्ड) सेट करें एक गैर शून्य मूल्य के लिए अदला-बदली?

"स्वैप या नॉट टू स्वैप" के बारे में चर्चा के अलावा यह मुझे उत्सुक करता है कि

मैं पुष्टि कर सकता हूं कि डॉकर डेमन मेमोरी सेटिंग्स के संबंध में क्यूबलेट अलग तरह से व्यवहार करता है (और कुछ ओएस पर ऊपर बताए गए कोड के अनुसार नहीं)। हमारे क्लस्टर SUSE लाइनक्स पर चलते हैं और हम https://github.com/kubernetes/kubernetes/issues/53533#issuecomment -598056151 में उल्लिखित समान असीमित स्वैप उपयोग का अनुभव कर रहे हैं।

ओएस विवरण: SUSE Linux Enterprise Server 12 SP4 - Linux 4.12.14-95.45-default

वैसे भी k8s में स्वैप के लिए उचित समर्थन के बिना, मैं कम से कम यह चाहता हूं कि क्यूबलेट अंतर्निहित ओएस की परवाह किए बिना लगातार डॉकर मेमोरी सेटिंग्स को संभाल ले।

मैंने यह देखने के लिए एजेंडा पर अदला-बदली की है कि 1.21 में इसे आगे बढ़ाने में मदद करने के लिए समुदाय की भूख है या स्वयंसेवक। जैसा कि मैंने 2017 में उल्लेख किया था, मुझे स्वैप का समर्थन करने में कोई आपत्ति नहीं है, इसे केवल यह सुनिश्चित करने की आवश्यकता है कि क्यूबलेट बेदखली, पॉड प्राथमिकता, सेवा की पॉड गुणवत्ता को भ्रमित न करें, और महत्वपूर्ण रूप से पॉड्स को यह कहने में सक्षम होना चाहिए कि वे स्वैप को सहन करते हैं या नहीं। पॉड्स पोर्टेबल हैं यह सुनिश्चित करने के लिए ये सभी चीजें महत्वपूर्ण हैं।

NUMA संरेखित स्मृति कार्य जैसी चीज़ों को बनाने पर हाल ही में बहुत सारी ऊर्जा पर ध्यान केंद्रित किया गया है, लेकिन अगर ऐसे लोग हैं जो कम प्रदर्शन संवेदनशील हैं और इस स्थान को आगे बढ़ाने में मदद करने के लिए समान रूप से प्रेरित हैं, तो हम डिजाइन पर एक शुरुआत प्राप्त करने में मदद करना पसंद करेंगे इस स्पेस में विस्तृत केईपी।

मैंने हाल ही में सामुदायिक प्रक्रिया को बहुत अच्छी तरह से नहीं रखा है क्योंकि हाल ही में चीजें मेरे लिए बहुत व्यस्त रही हैं, हालांकि ऐसा लगता है कि उन्हें जल्द ही कुछ हद तक शांत हो जाना चाहिए। क्या कोई तरीका है जिससे मैं स्लैक चैनल में शामिल हुए बिना जुड़ सकता हूं?