🥇कुबेरनेट्स क्लस्टर में छेद बंद करना। DevOpsConf से रिपोर्ट और प्रतिलेख

साउथब्रिज सॉल्यूशंस आर्किटेक्ट और स्लम शिक्षक पावेल सेलिवानोव ने DevOpsConf 2019 में एक प्रस्तुति दी। यह वार्ता कुबेरनेट्स "स्लम मेगा" पर गहन पाठ्यक्रम के विषयों में से एक का हिस्सा है।

स्लम बेसिक: कुबेरनेट्स का एक परिचय 18-20 नवंबर को मॉस्को में होगा।
स्लम मेगा: कुबेरनेट्स के हुड के नीचे देख रहे हैं — मॉस्को, 22-24 नवंबर।
स्लम ऑनलाइन: दोनों कुबेरनेट्स पाठ्यक्रम हमेशा उपलब्ध।

कट के नीचे रिपोर्ट की एक प्रतिलेख है।

शुभ दोपहर, सहकर्मियों और उनसे सहानुभूति रखने वालों को। आज मैं सुरक्षा के बारे में बात करूंगा.

मैं देख रहा हूं कि आज हॉल में कई सुरक्षा गार्ड हैं। यदि मैं सुरक्षा की दुनिया से ऐसे शब्दों का उपयोग करता हूं जो आपके लिए सामान्य नहीं हैं तो मैं आपसे पहले ही माफी मांगता हूं।

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

मेरी पिछली कंपनी ने ऐसी सेवा बेचने का प्रयास किया था। और मुझसे यह देखने के लिए क्लस्टर में जांच करने के लिए कहा गया कि यह समाधान उपयुक्त है या नहीं।

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

ऐसा हुआ कि दो मिनट में मुझे उनके क्लस्टर में एक व्यवस्थापक मिला, मैंने सभी पड़ोसी नामस्थानों को देखा, वहां उन कंपनियों के चल रहे उत्पादन मोर्चों को देखा जिन्होंने पहले ही सेवा खरीद ली थी और तैनात कर दी थी। मैं मुश्किल से खुद को किसी के सामने जाने और मुख्य पृष्ठ पर कुछ अपशब्द डालने से रोक सका।

मैं आपको उदाहरणों के साथ बताऊंगा कि मैंने यह कैसे किया और इससे खुद को कैसे बचाया जाए।

लेकिन पहले मैं अपना परिचय दे दूं. मेरा नाम पावेल सेलिवानोव है। मैं साउथब्रिज में एक वास्तुकार हूं। मैं कुबेरनेट्स, डेवऑप्स और सभी प्रकार की फैंसी चीजों को समझता हूं। साउथब्रिज के इंजीनियर और मैं यह सब बना रहे हैं और परामर्श दे रहे हैं।

अपनी मुख्य गतिविधियों के अलावा, हमने हाल ही में स्लर्म्स नामक परियोजनाएँ भी लॉन्च की हैं। हम कुबेरनेट्स के साथ काम करने की अपनी क्षमता को थोड़ा जन-जन तक पहुंचाने की कोशिश कर रहे हैं, ताकि अन्य लोगों को भी K8s के साथ काम करना सिखा सकें।

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

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

वस्तुतः तीन बिंदु हैं जिनके बारे में मैं आज बात करूंगा:

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

एक और सामान्य बात जिसका मैं उल्लेख करूंगा वह यह है कि मैंने इन सबका परीक्षण किस पर किया, जिस पर मैं निश्चित रूप से कह सकता हूं कि यह सब काम करता है।

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

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

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

kubectl apply -f pod.yaml

यह पॉड कुबेरनेट्स क्लस्टर के मास्टर्स में से एक के पास पहुंचेगा। और इसके बाद क्लस्टर ख़ुशी-ख़ुशी हमें admin.conf नामक फ़ाइल लौटा देगा। क्यूब में, यह फ़ाइल सभी व्यवस्थापक प्रमाणपत्र संग्रहीत करती है, और साथ ही क्लस्टर एपीआई को कॉन्फ़िगर करती है। मुझे लगता है कि 98% कुबेरनेट्स समूहों तक व्यवस्थापक पहुंच प्राप्त करना इतना आसान है।

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

और अब एक विशेष रूप से तैयार की गई फली के बारे में। हम इसे किसी भी छवि पर चलाते हैं। आइए एक उदाहरण के रूप में डेबियन:जेसी को लें।

हमारे पास यह चीज़ है:

tolerations:
-   effect: NoSchedule 
    operator: Exists 
nodeSelector: 
    node-role.kubernetes.io/master: ""

सहिष्णुता क्या है? कुबेरनेट्स क्लस्टर में मास्टर्स को आमतौर पर कलंक नामक चीज़ से चिह्नित किया जाता है। और इस "संक्रमण" का सार यह है कि यह कहता है कि पॉड्स को मास्टर नोड्स को नहीं सौंपा जा सकता है। लेकिन कोई भी किसी भी पॉड में यह बताने की जहमत नहीं उठाता कि यह "संक्रमण" के प्रति सहनशील है। टॉलरेंस अनुभाग केवल यह कहता है कि यदि किसी नोड में NoSchedule है, तो हमारा नोड ऐसे संक्रमण के प्रति सहनशील है - और कोई समस्या नहीं है।

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

इन दो खंडों के साथ वह निश्चित रूप से गुरु के पास आएगा। और उसे वहां रहने की अनुमति दी जाएगी.

लेकिन केवल गुरु के पास आना ही हमारे लिए पर्याप्त नहीं है। इससे हमें कुछ नहीं मिलेगा. तो आगे हमारे पास ये दो चीज़ें हैं:

hostNetwork: true 
hostPID: true

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

फिर ये तो छोटी-छोटी बातों की बात है. वगैरह लो और जो चाहो पढ़ो।

सबसे दिलचस्प बात यह कुबेरनेट्स सुविधा है, जो डिफ़ॉल्ट रूप से वहां मौजूद है।

volumeMounts:
- mountPath: /host 
  name: host 
volumes:
- hostPath: 
    path: / 
    type: Directory 
  name: host

और इसका सार यह है कि हम उस पॉड में कह सकते हैं जिसे हम लॉन्च करते हैं, इस क्लस्टर के अधिकारों के बिना भी, कि हम होस्टपाथ प्रकार का वॉल्यूम बनाना चाहते हैं। इसका अर्थ है होस्ट से वह पथ लेना जिस पर हम लॉन्च करेंगे - और इसे वॉल्यूम के रूप में लेना। और फिर हम इसे नाम कहते हैं: होस्ट. हम इस पूरे होस्टपाथ को पॉड के अंदर माउंट करते हैं। इस उदाहरण में, /होस्ट निर्देशिका में।

मैं इसे दोबारा दोहराऊंगा. हमने पॉड को मास्टर के पास आने, वहां होस्टनेटवर्क और होस्टपीआईडी प्राप्त करने और मास्टर के पूरे रूट को इस पॉड के अंदर माउंट करने के लिए कहा।

आप समझते हैं कि डेबियन में हमारे पास बैश चल रहा है, और यह बैश रूट के नीचे चलता है। अर्थात्, कुबेरनेट्स क्लस्टर में कोई अधिकार न होने पर, हमें बस मास्टर पर रूट प्राप्त हुआ।

फिर पूरा काम उपनिर्देशिका /होस्ट /etc/kubernetes/pki पर जाना है, अगर मैं गलत नहीं हूं, तो वहां क्लस्टर के सभी मास्टर प्रमाणपत्र उठाएं और तदनुसार, क्लस्टर प्रशासक बनें।

यदि आप इसे इस तरह से देखें, तो ये पॉड्स में सबसे खतरनाक अधिकारों में से कुछ हैं - चाहे उपयोगकर्ता के पास कोई भी अधिकार हो:

यदि मेरे पास क्लस्टर के कुछ नेमस्पेस में पॉड चलाने का अधिकार है, तो इस पॉड के पास डिफ़ॉल्ट रूप से ये अधिकार हैं। मैं विशेषाधिकार प्राप्त पॉड चला सकता हूं, और ये आम तौर पर सभी अधिकार हैं, व्यावहारिक रूप से नोड पर निहित हैं।

मेरा पसंदीदा रूट उपयोगकर्ता है. और कुबेरनेट्स के पास यह रन एज़ नॉन-रूट विकल्प है। यह हैकर से एक प्रकार की सुरक्षा है। क्या आप जानते हैं "मोल्डावियन वायरस" क्या है? यदि आप अचानक एक हैकर हैं और मेरे कुबेरनेट्स क्लस्टर में आते हैं, तो हम, गरीब प्रशासक, पूछते हैं: "कृपया अपने पॉड्स में इंगित करें कि आप मेरे क्लस्टर को किससे हैक करेंगे, गैर-रूट के रूप में चलाएं। अन्यथा, ऐसा होगा कि आप प्रक्रिया को अपने पॉड में रूट के तहत चलाएंगे, और आपके लिए मुझे हैक करना बहुत आसान हो जाएगा। कृपया अपने आप को अपने आप से बचाएं।"

होस्ट पथ वॉल्यूम, मेरी राय में, कुबेरनेट्स क्लस्टर से वांछित परिणाम प्राप्त करने का सबसे तेज़ तरीका है।

लेकिन इन सबका क्या करें?

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

यह एक yaml ऑब्जेक्ट है - हम इसे Kubernetes क्लस्टर में बना सकते हैं - जो विशेष रूप से पॉड्स के विवरण में सुरक्षा पहलुओं को नियंत्रित करता है। यानी, वास्तव में, यह किसी भी होस्टनेटवर्क, होस्टपीआईडी, कुछ वॉल्यूम प्रकारों का उपयोग करने के अधिकारों को नियंत्रित करता है जो स्टार्टअप पर पॉड्स में होते हैं। पॉड सिक्योरिटी पॉलिसी की मदद से यह सब बताया जा सकता है।

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

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

और ऐसा लगता है कि हमारे साथ सब कुछ ठीक है। और हमारे Kubernetes क्लस्टर को दो मिनट में हैक नहीं किया जा सकता।

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

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

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

आगे हमारे पास एक निश्चित डेव एनएस है, जिसमें आप एक निश्चित पॉड चला सकते हैं। और फिर इस पॉड से ऐसा कुछ करना बहुत आसान है:

$ curl http://prometheus-kube-state-metrics.monitoring

प्रोमेथियस-क्यूब-स्टेट-मेट्रिक्स प्रोमेथियस निर्यातकों में से एक है जो कुबेरनेट्स एपीआई से ही मेट्रिक्स एकत्र करता है। वहां बहुत सारा डेटा है, आपके क्लस्टर में क्या चल रहा है, यह क्या है, आपको इससे क्या समस्याएं हैं।

एक साधारण उदाहरण के रूप में:

kube_pod_container_info{namespace=“kube-system”,pod=”kube-apiserver-k8s- 1″,container=”kube-apiserver”,image=

"gcr.io/google-containers/kube-apiserver:v1.14.5"

,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1

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

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

और यहां सवाल उठता है कि क्या कोई बाहरी मॉनिटरिंग आपकी मॉनिटरिंग करती है. मुझे अपने लिए बिना किसी परिणाम के कुबेरनेट्स क्लस्टर में काम करने का अवसर मिला। आपको पता भी नहीं चलेगा कि मैं वहां काम कर रहा हूं, क्योंकि अब वहां कोई निगरानी नहीं है।

पीएसपी की तरह, ऐसा लगता है कि समस्या यह है कि ये सभी फैंसी प्रौद्योगिकियां - कुबेरनेट्स, प्रोमेथियस - वे काम नहीं करती हैं और खामियों से भरी हैं। ज़रूरी नहीं।

एक ऐसी बात है - नेटवर्क नीति.

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

भले ही आपने अपने सुरक्षा विशेषज्ञों को यह नहीं बताया हो कि अपने कुबेरनेट्स का उपयोग करके आप एक बहुत आसान और सरल फ़ायरवॉल बना सकते हैं, और साथ ही एक बहुत ही बारीक फ़ायरवॉल भी। यदि वे अभी तक यह नहीं जानते हैं और आपको परेशान नहीं करते हैं: "ठीक है, मुझे दो, मुझे दो..." तो किसी भी स्थिति में, आपको कुछ सेवा स्थानों तक पहुंच को अवरुद्ध करने के लिए नेटवर्क नीति की आवश्यकता होगी जिन्हें आपके क्लस्टर से खींचा जा सकता है बिना किसी प्राधिकरण के.

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

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

क्या करना है?

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

और समस्या वास्तव में बहुत ही सरलता से हल हो गई है। क्लस्टर में प्रमाणपत्र हैं, और आप जानते हैं कि आपके प्रमाणपत्र एक वर्ष में समाप्त हो जाएंगे। खैर, और आमतौर पर क्लस्टर में प्रमाणपत्रों के साथ एक सामान्य समाधान - हम चिंता क्यों कर रहे हैं, हम पास में एक नया क्लस्टर बनाएंगे, पुराने को सड़ने देंगे, और सब कुछ फिर से तैनात करेंगे। सच है, जब यह सड़ जाएगा, तो हमें एक दिन बैठना होगा, लेकिन यहाँ एक नया क्लस्टर है।

जब आप एक नया क्लस्टर बढ़ाते हैं, उसी समय फलालैन के स्थान पर केलिको डालें।

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

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

एक और छोटी समस्या है. प्रोमेथियस अकेला नहीं है जो अपनी मेट्रिक्स किसी को भी सौंप रहा है। हमारे सभी कुबेरनेट्स क्लस्टर घटक अपने स्वयं के मेट्रिक्स वापस करने में भी सक्षम हैं।

लेकिन जैसा कि मैंने पहले ही कहा, यदि आप क्लस्टर तक नहीं पहुंच सकते हैं और जानकारी एकत्र नहीं कर सकते हैं, तो आप कम से कम कुछ नुकसान तो पहुंचा सकते हैं।

तो मैं जल्दी से दो तरीके दिखाऊंगा कि कैसे कुबेरनेट्स क्लस्टर को बर्बाद किया जा सकता है।

जब मैं आपको यह बताऊंगा तो आप हंसेंगे, ये दो वास्तविक जीवन के मामले हैं।

विधि एक. संसाधन का क्षरण।

आइए एक और विशेष पॉड लॉन्च करें। इसमें इस तरह का एक सेक्शन होगा.

resources: 
    requests: 
        cpu: 4 
        memory: 4Gi

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

यदि मैं ऐसा पॉड चलाता हूं, तो मैं कमांड चलाऊंगा:

$ kubectl scale special-pod --replicas=...

फिर कोई भी कुबेरनेट्स क्लस्टर पर तैनात नहीं कर पाएगा। क्योंकि सभी नोड्स के अनुरोध समाप्त हो जायेंगे। और इस प्रकार मैं आपके कुबेरनेट्स क्लस्टर को रोक दूंगा। यदि मैं शाम को ऐसा करता हूं, तो मैं काफी लंबे समय के लिए तैनाती रोक सकता हूं।

यदि हम कुबेरनेट्स दस्तावेज़ को फिर से देखें, तो हमें लिमिट रेंज नामक यह चीज़ दिखाई देगी। यह क्लस्टर ऑब्जेक्ट के लिए संसाधन सेट करता है। आप yaml में एक लिमिट रेंज ऑब्जेक्ट लिख सकते हैं, इसे कुछ नामस्थानों पर लागू कर सकते हैं - और फिर इस नामस्थान में आप कह सकते हैं कि आपके पास पॉड्स के लिए डिफ़ॉल्ट, अधिकतम और न्यूनतम संसाधन हैं।

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

और यहीं से विधि संख्या दो आती है। हमने 11 पॉड लॉन्च किए। वह ग्यारह अरब है. ऐसा इसलिए नहीं है कि मैं ऐसा कोई नंबर लेकर आया हूं, बल्कि इसलिए कि मैंने इसे खुद देखा है।

सत्य घटना। देर शाम मैं ऑफिस से निकलने ही वाला था. मैं देखता हूं कि डेवलपर्स का एक समूह कोने में बैठा है, अपने लैपटॉप के साथ कुछ कर रहा है। मैं लोगों के पास जाता हूं और पूछता हूं: "तुम्हें क्या हुआ?"

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

सच है, यह कहानी कुबेरनेट्स पर नहीं घटी; उस समय यह खानाबदोश था। यह इस तथ्य के साथ समाप्त हुआ कि खानाबदोश को पैमाने पर लगातार प्रयास करने से रोकने के हमारे प्रयासों के एक घंटे के बाद, खानाबदोश ने जवाब दिया कि वह स्केलिंग बंद नहीं करेगा और कुछ और नहीं करेगा। "मैं थक गया हूँ, मैं जा रहा हूँ।" और वह सिकुड़ गया।

स्वाभाविक रूप से, मैंने कुबेरनेट्स पर भी ऐसा ही करने की कोशिश की। कुबेरनेट्स ग्यारह अरब पॉड्स से खुश नहीं थे, उन्होंने कहा: “मैं नहीं कर सकता। आंतरिक माउथ गार्ड से अधिक है।" लेकिन 1 पॉड हो सकते हैं।

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

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

लेकिन मैंने इससे भी आगे जाने का फैसला किया. जैसा कि आप जानते हैं, कुबेरनेट्स में सेवा नाम की एक चीज़ होती है। खैर, आपके क्लस्टर में डिफ़ॉल्ट रूप से, सबसे अधिक संभावना है, सेवा आईपी तालिकाओं का उपयोग करके काम करती है।

उदाहरण के लिए, यदि आप एक बिलियन पॉड चलाते हैं, और फिर कुबेरनेटिस को नई सेवाएँ बनाने के लिए मजबूर करने के लिए एक स्क्रिप्ट का उपयोग करते हैं:

for i in {1..1111111}; do
    kubectl expose deployment test --port 80  
        --overrides="{"apiVersion": "v1", 
           "metadata": {"name": "nginx$i"}}"; 
done

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

मैंने इस पूरी चीज़ को कई हज़ार, दस तक पर जाँचा। और समस्या यह है कि पहले से ही इस सीमा पर नोड पर ssh करना काफी समस्याग्रस्त है। क्योंकि इतनी सारी जंजीरों से गुजरते हुए पैकेट बहुत अच्छे नहीं लगने लगते हैं।

और यह सब भी कुबेरनेट्स की मदद से हल किया गया है। ऐसी एक संसाधन कोटा वस्तु है। क्लस्टर में नेमस्पेस के लिए उपलब्ध संसाधनों और ऑब्जेक्ट की संख्या निर्धारित करता है। हम कुबेरनेट्स क्लस्टर के प्रत्येक नेमस्पेस में एक yaml ऑब्जेक्ट बना सकते हैं। इस ऑब्जेक्ट का उपयोग करके, हम कह सकते हैं कि हमारे पास इस नेमस्पेस के लिए एक निश्चित संख्या में अनुरोध और सीमाएं आवंटित हैं, और फिर हम कह सकते हैं कि इस नेमस्पेस में 10 सेवाएं और 10 पॉड बनाना संभव है। और एक अकेला डेवलपर कम से कम शाम को अपना गला घोंट सकता है। कुबेरनेट्स उसे बताएंगे: "आप अपने पॉड्स को उस मात्रा में नहीं बढ़ा सकते, क्योंकि संसाधन कोटा से अधिक है।" बस, समस्या हल हो गई। दस्तावेज़ीकरण यहाँ.

इस संबंध में एक समस्याग्रस्त बिंदु उठता है। आपको लगता है कि कुबेरनेट्स में नेमस्पेस बनाना कितना मुश्किल होता जा रहा है। इसे बनाने के लिए हमें बहुत सी बातों का ध्यान रखना होगा।

संसाधन कोटा + सीमा सीमा + आरबीएसी
• एक नेमस्पेस बनाएं
• अंदर एक लिमिटरेंज बनाएं
• आंतरिक संसाधनकोटा बनाएं
• सीआई के लिए एक सेवा खाता बनाएं
• सीआई और उपयोगकर्ताओं के लिए रोलबाइंडिंग बनाएं
• वैकल्पिक रूप से आवश्यक सर्विस पॉड्स लॉन्च करें

इसलिए, मैं इस अवसर का उपयोग अपने विकास को साझा करने के लिए करना चाहूंगा। SDK ऑपरेटर नाम की एक चीज़ होती है। यह कुबेरनेट्स क्लस्टर के लिए ऑपरेटर लिखने का एक तरीका है। आप Ansible का उपयोग करके कथन लिख सकते हैं।

सबसे पहले यह Ansible में लिखा गया था, और फिर मैंने देखा कि एक SDK ऑपरेटर था और Ansible भूमिका को एक ऑपरेटर में फिर से लिखा। यह कथन आपको कुबेरनेट्स क्लस्टर में एक ऑब्जेक्ट बनाने की अनुमति देता है जिसे कमांड कहा जाता है। एक कमांड के अंदर, यह आपको yaml में इस कमांड के लिए पर्यावरण का वर्णन करने की अनुमति देता है। और टीम के माहौल में, यह हमें यह वर्णन करने की अनुमति देता है कि हम इतने सारे संसाधन आवंटित कर रहे हैं।

खूबसूरत इस पूरी जटिल प्रक्रिया को आसान बनाना.

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

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

LimitRange/ResourceQuota - इसका उपयोग करने का समय आ गया है। हमने इसका उपयोग बहुत समय पहले शुरू किया था, और लंबे समय तक मुझे यकीन था कि हर कोई इसका उपयोग कर रहा था। यह पता चला कि यह दुर्लभ है.

रिपोर्ट के दौरान मैंने जो उल्लेख किया है उसके अलावा, ऐसी अनिर्दिष्ट विशेषताएं हैं जो आपको क्लस्टर पर हमला करने की अनुमति देती हैं। हाल ही में जारी किया गया कुबेरनेट्स कमजोरियों का व्यापक विश्लेषण.

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

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

आप सभी को धन्यवाद।

स्रोत: www.habr.com

कुबेरनेट्स क्लस्टर में छेद भरना। DevOpsConf से रिपोर्ट और प्रतिलेख

एक टिप्पणी जोड़ें उत्तर रद्द