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

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

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

कटौती के तहत - रिपोर्ट का प्रतिलेख।

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

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

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

उन्होंने मेरी पिछली कंपनी को ऐसी सेवा बेचने की कोशिश की। और मुझे इस विषय पर एक क्लस्टर प्रहार करने के लिए कहा गया - क्या यह समाधान उपयुक्त है या नहीं।

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

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

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

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

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

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

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

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

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

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

एक आधार के रूप में, हम Kubernetes क्लस्टर की स्थापना Kubespray का उपयोग करते हैं। यदि कोई नहीं जानता है, तो यह वास्तव में 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 

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

मैं एक बार फिर दोहराता हूं। हमने फली को मास्टर के पास आने के लिए कहा, hostNetwork और hostPID प्राप्त करें - और इस फली के अंदर मास्टर की पूरी जड़ को माउंट करें।

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

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

यदि आप इस तरह देखते हैं, तो ये पॉड्स के कुछ सबसे खतरनाक अधिकार हैं - उपयोगकर्ता के अधिकारों के बावजूद:

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

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

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

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

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

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

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

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

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

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

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

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

इसके अलावा हमारे पास एक निश्चित देव ns है, इसमें एक निश्चित तहत लॉन्च करना संभव है। और इस चूल्हा से आगे इस तरह करना बहुत आसान है:

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

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

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

kube_pod_container_info {namespace = "kube-system", pod = "kube-apiserver-k8s-1", कंटेनर = "kube-apiserver", छवि =

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

, Image_id = "डोकर-pullable: //gcr.io/google-containers/kube- apiserver @ SHA256: e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989", container_id = "डोकर: // 7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b"} 1

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

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

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

PSP के साथ की तरह, यह समस्या की तरह लगता है कि इन सभी फैशनेबल प्रौद्योगिकियों - Kubernetes, Prometheus - वे सिर्फ काम नहीं करते हैं और छेद से भरे हुए हैं। वास्तव में नहीं।

ऐसी एक चीज है - नेटवर्क पॉलिसी ।

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

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

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

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

क्या करें?

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

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

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

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

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

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

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

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

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

पहला तरीका। संसाधनों से बाहर भाग रहा है।

हम एक और विशेष को लॉन्च करते हैं। उसके पास ऐसा एक सेक्शन होगा।

 resources: requests: cpu: 4 memory: 4Gi 

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

अगर मैं इसे चलाता हूं, तो मैं एक आदेश दूंगा:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.

. ?
. Pod Security Policy — . , , - .

Network Policy — - . , .

LimitRange/ResourceQuota — . , , . , .

, , , . .

. , warlocks , .

, , . , ResourceQuota, Pod Security Policy . .

.