Kubernetes क्लस्टरमा प्वालहरू फिक्स गर्दै। DevOpsConf बाट रिपोर्ट र ट्रान्सक्रिप्ट

Pavel Selivanov, Southbridge Solutions आर्किटेक्ट र Slurm शिक्षकले DevOpsConf 2019 मा एक प्रस्तुतीकरण दिए। यो वार्ता Kubernetes "Slurm Mega" मा गहन पाठ्यक्रमको एक विषयको अंश हो।

स्लर्म बेसिक: कुबर्नेट्सको परिचय नोभेम्बर 18-20 मा मास्को मा हुन्छ।
Slurm Mega: Kubernetes को हुड अन्तर्गत हेर्दै - मस्को, नोभेम्बर 22-24।
Slurm अनलाइन: दुबै Kubernetes पाठ्यक्रमहरू सधैं उपलब्ध।

कट तल रिपोर्ट को एक ट्रान्सक्रिप्ट छ।

शुभ दिउँसो, सहकर्मीहरू र उनीहरूसँग सहानुभूति राख्नेहरू। आज म सुरक्षाको बारेमा कुरा गर्नेछु।

मैले आज हलमा धेरै सुरक्षा गार्डहरू देखेको छु। यदि मैले सुरक्षाको संसारबाट सर्तहरू प्रयोग गरें भने म तपाइँसँग पहिले नै माफी चाहन्छु जुन तपाइँको प्रचलनमा छैन।

यो यस्तो भयो कि करिब छ महिना अघि मैले एउटा सार्वजनिक कुबर्नेट्स क्लस्टर भेटें। पब्लिकको अर्थ हो कि त्यहाँ नामस्थानहरूको nth संख्या छ; यी नेमस्पेसहरूमा त्यहाँ प्रयोगकर्ताहरू तिनीहरूको नेमस्पेसमा अलग छन्। यी सबै प्रयोगकर्ताहरू विभिन्न कम्पनीहरूसँग सम्बन्धित छन्। खैर, यो क्लस्टर एक CDN को रूप मा प्रयोग गरिनु पर्छ कि मानिएको थियो। त्यो हो, तिनीहरूले तपाईंलाई क्लस्टर दिन्छन्, तिनीहरूले तपाईंलाई त्यहाँ प्रयोगकर्ता दिन्छन्, तपाईं त्यहाँ आफ्नो नेमस्पेसमा जानुहुन्छ, तपाईंको मोर्चाहरू तैनात गर्नुहोस्।

मेरो अघिल्लो कम्पनीले यस्तो सेवा बेच्ने प्रयास गर्यो। र मलाई यो समाधान उपयुक्त छ वा छैन भनेर हेर्न क्लस्टर पोक गर्न भनियो।

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

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

मैले यो कसरी गरें र यसबाट आफूलाई कसरी जोगाउने भनेर म उदाहरणहरू सहित बताउनेछु।

तर पहिले, मलाई आफ्नो परिचय दिनुहोस्। मेरो नाम पावेल Selivanov हो। म साउथब्रिजमा आर्किटेक्ट हुँ। म Kubernetes, DevOps र सबै प्रकारका फैंसी चीजहरू बुझ्छु। साउथब्रिज इन्जिनियरहरू र म यो सबै निर्माण गर्दैछौं, र म परामर्श गर्दैछु।

हाम्रा मुख्य गतिविधिहरूका अतिरिक्त, हामीले हालै स्लर्म्स नामक परियोजनाहरू सुरु गरेका छौं। हामी Kubernetes सँग काम गर्ने हाम्रो क्षमतालाई जनतामा अलिकति ल्याउने प्रयास गर्दैछौं, अरू मानिसहरूलाई पनि K8s सँग काम गर्न सिकाउन।

आज म के कुरा गरुँ? रिपोर्ट को विषय स्पष्ट छ - Kubernetes क्लस्टर को सुरक्षा को बारे मा। तर म तुरुन्तै भन्न चाहन्छु कि यो विषय धेरै ठूलो छ - र त्यसैले म तुरुन्तै स्पष्ट गर्न चाहन्छु कि म निश्चित रूपमा के कुरा गर्दिन। म ह्याकनी सर्तहरूको बारेमा कुरा गर्दिन जुन पहिले नै इन्टरनेटमा सय पटक प्रयोग भइसकेको छ। सबै प्रकारका RBAC र प्रमाणपत्रहरू।

Kubernetes क्लस्टरमा सुरक्षाको बारेमा मलाई र मेरा सहकर्मीहरूलाई के पीडा हुन्छ भन्ने बारेमा म कुरा गर्नेछु। हामी यी समस्याहरू Kubernetes क्लस्टरहरू प्रदान गर्ने प्रदायकहरू र हामीकहाँ आउने ग्राहकहरू बीच दुवै देख्छौं। र अन्य परामर्श व्यवस्थापक कम्पनीहरूबाट हामीलाई आउने ग्राहकहरूबाट पनि। अर्थात्, त्रासदीको मापन वास्तवमा धेरै ठूलो छ।

त्यहाँ शाब्दिक रूपमा तीन बुँदाहरू छन् जुन म आज कुरा गर्नेछु:

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

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

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

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

मैले वाचा गरें कि हामीले गर्ने पहिलो कुरा क्लस्टरमा प्रशासक अधिकारहरू प्राप्त गर्ने हो। हामीलाई विशेष रूपमा तयार गरिएको पोड चाहिन्छ जसले Kubernetes क्लस्टरलाई तोड्नेछ। हामीले के गर्नु पर्छ यसलाई Kubernetes क्लस्टरमा लागू गर्नु हो।

kubectl apply -f pod.yaml

यो पोड Kubernetes क्लस्टर को एक मास्टर मा आइपुग्छ। र यसपछि क्लस्टरले हामीलाई admin.conf भनिने फाइल खुसीसाथ फिर्ता गर्नेछ। क्यूबमा, यो फाइलले सबै प्रशासक प्रमाणपत्रहरू भण्डार गर्दछ, र एकै समयमा क्लस्टर API कन्फिगर गर्दछ। यो कत्ति सजिलो छ प्रशासक पहुँच प्राप्त गर्न, मलाई लाग्छ, 98% Kubernetes क्लस्टरहरू।

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

र अब एक विशेष तयार पोड बारेमा। हामी यसलाई कुनै पनि छविमा चलाउँछौं। उदाहरणको रूपमा डेबियन: जेसी लिनुहोस्।

हामीसँग यो चीज छ:

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

सहिष्णुता भनेको के हो? Kubernetes क्लस्टरमा मास्टरहरू सामान्यतया दाग भनिने चीजले चिन्ह लगाइन्छ। र यस "संक्रमण" को सार यो हो कि यसले पोडहरू मास्टर नोडहरूमा असाइन गर्न सकिँदैन। तर कुनै पनि पोडमा यो "संक्रमण" को लागी सहिष्णु छ भनेर संकेत गर्न कसैले चिन्ता गर्दैन। सहिष्णुता खण्डले केवल भन्छ कि यदि कुनै नोडमा NoSchedule छ भने, हाम्रो नोड यस्तो संक्रमणलाई सहनशील छ - र त्यहाँ कुनै समस्या छैन।

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

यी दुई खण्डहरू लिएर उनी अवश्य मास्टरकहाँ आउनेछन्। र उसलाई त्यहाँ बस्न अनुमति दिइनेछ।

तर गुरुकहाँ आएर मात्र पुग्दैन। यसले हामीलाई केही दिने छैन। त्यसोभए हामीसँग यी दुई चीजहरू छन्:

hostNetwork: true 
hostPID: true 

हामीले सुरु गर्ने हाम्रो पोड कर्नेल नेमस्पेस, नेटवर्क नेमस्पेस र PID नेमस्पेसमा रहनेछ भनेर निर्दिष्ट गर्छौं। मास्टरमा पोड सुरु भएपछि, यसले यस नोडको सबै वास्तविक, प्रत्यक्ष इन्टरफेसहरू हेर्न, सबै ट्राफिकहरू सुन्न र सबै प्रक्रियाहरूको PID हेर्न सक्षम हुनेछ।

त्यसपछि यो सानो कुराको कुरा हो। etcd लिनुहोस् र तपाईलाई के चाहानुहुन्छ पढ्नुहोस्।

सबैभन्दा चाखलाग्दो कुरा यो Kubernetes सुविधा हो, जुन त्यहाँ पूर्वनिर्धारित रूपमा अवस्थित छ।

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

र यसको सार यो हो कि हामी पोडमा भन्न सक्छौं कि हामीले सुरुवात गर्छौं, यस क्लस्टरको अधिकार बिना पनि, हामी होस्टपाथ प्रकारको भोल्युम सिर्जना गर्न चाहन्छौं। यसको मतलब होस्टबाट मार्ग लिनु हो जसमा हामीले सुरुवात गर्नेछौं - र यसलाई भोल्युमको रूपमा लिने। र त्यसपछि हामी यसलाई नाम भन्छौं: होस्ट। हामी यो सम्पूर्ण होस्टपाथ पोड भित्र माउन्ट गर्छौं। यस उदाहरणमा, /host डाइरेक्टरीमा।

म यसलाई फेरि दोहोर्याउनेछु। हामीले पोडलाई मास्टरमा आउन, hostNetwork र hostPID त्यहाँ प्राप्त गर्न भन्यौं - र यो पोड भित्र मास्टरको सम्पूर्ण रूट माउन्ट गर्नुहोस्।

तपाईंले बुझ्नुभयो कि डेबियनमा हामीसँग ब्यास चलिरहेको छ, र यो ब्यास रूट अन्तर्गत चल्छ। त्यो हो, हामीले भर्खरै मास्टरमा रूट प्राप्त गर्यौं, कुबेरनेट क्लस्टरमा कुनै अधिकार बिना।

त्यसपछि सम्पूर्ण कार्य उप-निर्देशिका /host /etc/kubernetes/pki मा जानु हो, यदि म गलत छैन भने, त्यहाँ क्लस्टरको सबै मास्टर प्रमाणपत्रहरू उठाउनुहोस् र, तदनुसार, क्लस्टर प्रशासक बन्नुहोस्।

यदि तपाइँ यसलाई यस तरिकाले हेर्नुहुन्छ भने, यी पोडहरूमा सबैभन्दा खतरनाक अधिकारहरू हुन् - प्रयोगकर्तासँग कुन अधिकार छ भन्ने कुराको पर्वाह नगरी:

यदि मसँग क्लस्टरको केही नेमस्पेसमा पोड चलाउने अधिकार छ भने, यस पोडमा पूर्वनिर्धारित रूपमा यी अधिकारहरू छन्। म विशेषाधिकार प्राप्त पोडहरू चलाउन सक्छु, र यी सामान्यतया सबै अधिकारहरू हुन्, व्यावहारिक रूपमा नोडमा रूट।

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

होस्ट पथ भोल्युम हो, मेरो विचारमा, Kubernetes क्लस्टरबाट इच्छित परिणाम प्राप्त गर्ने सबैभन्दा छिटो तरिका हो।

तर यो सबै संग के गर्ने?

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

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

Pod सुरक्षा नीतिको बारेमा सबैभन्दा चाखलाग्दो कुरा यो हो कि Kubernetes क्लस्टरमा, सबै PSP स्थापनाकर्ताहरू कुनै पनि तरिकाले वर्णन गरिएको छैन, तिनीहरू पूर्वनिर्धारित रूपमा असक्षम हुन्छन्। पोड सुरक्षा नीति प्रवेश प्लगइन प्रयोग गरेर सक्षम गरिएको छ।

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

र हामीसँग सबै ठीक छ जस्तो देखिन्छ। र हाम्रो Kubernetes क्लस्टर दुई मिनेटमा ह्याक हुन सक्दैन।

समस्या छ। सम्भवतः, यदि तपाइँसँग Kubernetes क्लस्टर छ भने, त्यसपछि तपाइँको क्लस्टरमा निगरानी स्थापना गरिएको छ। यदि तपाईंको क्लस्टरमा निगरानी छ भने, यसलाई प्रोमेथियस भनिनेछ भनी भविष्यवाणी गर्न म यहाँसम्म जान्छु।

म तपाईलाई के भन्न खोज्दै छु प्रोमेथियस अपरेटर र प्रोमेथियस दुबै को लागी यसको शुद्ध रूप मा डेलिभर को लागी मान्य हुनेछ। प्रश्न यो हो कि यदि मैले क्लस्टरमा यति चाँडो प्रशासक प्राप्त गर्न सक्दिन भने, यसको मतलब यो हो कि मैले अझ धेरै हेर्नु पर्छ। र म तपाईको निगरानीको मद्दतले खोज्न सक्छु।

सम्भवतः सबैले Habré मा उही लेखहरू पढ्छन्, र अनुगमन निगरानी नाम स्थानमा अवस्थित छ। हेल्म चार्ट सबैका लागि लगभग समान भनिन्छ। म अनुमान गर्दैछु कि यदि तपाईंले हेल्म स्थिर/प्रोमेथियस स्थापना गर्नुभयो भने, तपाईं लगभग उही नामहरूको साथ समाप्त हुनुहुनेछ। र सम्भवतः मैले तपाइँको क्लस्टरमा DNS नाम अनुमान गर्नुपर्दैन। किनभने यो मानक हो।

अर्को हामीसँग निश्चित devns छ, जसमा तपाइँ एक निश्चित पोड चलाउन सक्नुहुन्छ। र त्यसपछि यो पोडबाट यो केहि गर्न धेरै सजिलो छ:

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

prometheus-kube-state-metrics प्रोमिथियस निर्यातकहरू मध्ये एक हो जसले Kubernetes API बाट नै मेट्रिकहरू सङ्कलन गर्दछ। त्यहाँ धेरै डाटा छ, तपाईको क्लस्टरमा के चलिरहेको छ, यो के हो, तपाईलाई यसमा के समस्या छ।

साधारण उदाहरणको रूपमा:

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

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

र सबैभन्दा चाखलाग्दो कुरा यो हो कि kube-state-metrics पहुँच गर्नुको अतिरिक्त, तपाईं सजिलैसँग प्रोमेथियसलाई सीधा पहुँच गर्न सक्नुहुन्छ। तपाईं त्यहाँबाट मेट्रिक्स सङ्कलन गर्न सक्नुहुन्छ। तपाईं त्यहाँबाट मेट्रिक्स पनि निर्माण गर्न सक्नुहुन्छ। सैद्धान्तिक रूपमा पनि, तपाइँ प्रोमेथियसको क्लस्टरबाट यस्तो प्रश्न निर्माण गर्न सक्नुहुन्छ, जसले यसलाई बन्द गर्नेछ। र तपाईंको निगरानीले क्लस्टरबाट पूर्ण रूपमा काम गर्न बन्द गर्नेछ।

र यहाँ प्रश्न उठ्छ कि कुनै बाह्य निगरानीले तपाइँको अनुगमनलाई निगरानी गर्दछ। मैले भर्खरै कुबेरनेट क्लस्टरमा आफ्नो लागि कुनै परिणाम बिना काम गर्ने मौका पाएँ। तपाईलाई थाहा छैन कि म त्यहाँ काम गरिरहेको छु, किनकि त्यहाँ अब कुनै निगरानी छैन।

PSP को साथ जस्तै, यो समस्या जस्तो लाग्छ कि यी सबै फैंसी प्रविधिहरू - Kubernetes, Prometheus - तिनीहरू काम गर्दैनन् र प्वालहरूले भरिएका छन्। साँच्चै होइन।

त्यहाँ यस्तो चीज छ - नेटवर्क नीति.

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

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

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

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

मैले के गर्नु पर्छ?

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

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

जब तपाइँ नयाँ क्लस्टर उठाउनुहुन्छ, एकै समयमा फ्ल्यानलको सट्टा क्यालिको घुसाउनुहोस्।

यदि तपाइँको प्रमाणपत्र एक सय वर्षको लागि जारी गरिएको छ र तपाइँ क्लस्टर पुन: प्रयोग गर्न जाँदै हुनुहुन्छ भने के गर्ने? त्यहाँ Kube-RBAC-Proxy जस्तो चीज छ। यो एक धेरै राम्रो विकास हो, यसले तपाईंलाई कुबेरनेट क्लस्टरको कुनै पनि पोडमा साइडकार कन्टेनरको रूपमा इम्बेड गर्न अनुमति दिन्छ। र यसले वास्तवमा Kubernetes को RBAC मार्फत यो पोडमा प्राधिकरण थप्छ।

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

अर्को एउटा सानो समस्या छ। प्रोमेथियसले आफ्नो मेट्रिक्स कसैलाई मात्र हस्तान्तरण गर्ने मात्र होइन। हाम्रा सबै Kubernetes क्लस्टर कम्पोनेन्टहरू पनि आफ्नै मेट्रिकहरू फर्काउन सक्षम छन्।

तर मैले पहिले नै भनें, यदि तपाइँ क्लस्टर पहुँच गर्न र जानकारी सङ्कलन गर्न सक्नुहुन्न भने, तपाइँ कम्तिमा केहि हानि गर्न सक्नुहुन्छ।

त्यसोभए म चाँडै दुई तरिकाहरू देखाउनेछु कसरी कुबेरनेट क्लस्टरलाई बर्बाद गर्न सकिन्छ।

तिमी हाँस्नुहुनेछ जब म तिमीलाई यो भन्छु, यी दुई वास्तविक जीवनका घटना हुन्।

विधि एक। स्रोतको कमी।

अर्को विशेष पोड सुरु गरौं। यसमा यस्तो खण्ड हुनेछ।

resources: 
    requests: 
        cpu: 4 
        memory: 4Gi 

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

यदि मैले यस्तो पोड चलाउँछु भने, म आदेश चलाउनेछु:

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

त्यसपछि अरू कसैले Kubernetes क्लस्टरमा तैनात गर्न सक्षम हुनेछैन। किनभने सबै नोडहरू अनुरोधहरू समाप्त हुनेछन्। र यसरी म तिम्रो कुबेरनेट क्लस्टर बन्द गर्नेछु। यदि मैले यो साँझमा गरे भने, म धेरै लामो समयको लागि तैनातीहरू रोक्न सक्छु।

यदि हामीले Kubernetes कागजातमा फेरि हेर्‍यौं भने, हामीले यो कुरालाई Limit Range भनिने देख्नेछौं। यसले क्लस्टर वस्तुहरूको लागि स्रोतहरू सेट गर्दछ। तपाईंले yaml मा सीमा दायरा वस्तु लेख्न सक्नुहुन्छ, यसलाई निश्चित नेमस्पेसहरूमा लागू गर्नुहोस् - र त्यसपछि यो नेमस्पेसमा तपाईंले पोडहरूको लागि पूर्वनिर्धारित, अधिकतम र न्यूनतम स्रोतहरू छन् भनी भन्न सक्नुहुन्छ।

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

र यो जहाँ विधि नम्बर दुई बाट आउँछ। हामी 11 पोडहरू सुरु गर्छौं। त्यो एघार अर्ब। यो मैले त्यस्तो नम्बर लिएर आएको होइन, तर मैले आफैंले देखेको कारण हो।

वास्तविक कथा। साँझ अबेर अफिसबाट निस्कन लागेको थियो । मैले विकासकर्ताहरूको एउटा समूह कुनामा बसिरहेको देख्छु, तिनीहरूको ल्यापटपसँग पागलपनले केही गरिरहेको छु। म केटाहरूकहाँ गएर सोध्छु: "तिमीलाई के भयो?"

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

साँचो, यो कथा कुबेरनेटमा भएको थिएन; त्यो समयमा यो घुमन्ते थियो। यो तथ्यको साथ समाप्त भयो कि घुमन्तेलाई मापन गर्ने लगातार प्रयासबाट रोक्नको लागि हाम्रो प्रयासको एक घण्टा पछि, Nomad जवाफ दिए कि उसले स्केलिंग रोक्दैन र अरू केहि पनि गर्दैन। "म थाकेको छु, म जाँदैछु।" अनि ऊ झुक्कियो ।

स्वाभाविक रूपमा, मैले कुबेरनेटमा पनि त्यस्तै गर्ने प्रयास गरें। कुबर्नेट्स एघार अर्ब पोडसँग खुसी थिएनन्, उनले भने: "म सक्दिन। आन्तरिक माउथ गार्डहरू भन्दा बढी।" तर 1 pods सक्छ।

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

र एउटा थप समस्या... तपाईलाई थाहा छ, Kubernetes नियन्त्रण तत्वहरू एक केन्द्रीय चीज होइन, तर धेरै घटकहरू हुन्। विशेष गरी, त्यहाँ एक नियन्त्रक प्रबन्धक, अनुसूचक, र यस्तै छ। यी सबै केटाहरूले एकै समयमा अनावश्यक, बेवकूफ काम गर्न सुरु गर्नेछन्, जुन समयको साथमा अधिक र अधिक समय लाग्न थाल्छ। नियन्त्रक प्रबन्धकले नयाँ पोडहरू सिर्जना गर्नेछ। अनुसूचकले तिनीहरूको लागि नयाँ नोड फेला पार्न प्रयास गर्नेछ। तपाइँले तपाइँको क्लस्टरमा चाँडै नै नयाँ नोडहरू समाप्त हुनुहुनेछ। Kubernetes क्लस्टरले ढिलो र ढिलो काम गर्न सुरु गर्नेछ।

तर मैले अझ अगाडि जाने निर्णय गरें। तपाईलाई थाहा छ, Kubernetes मा सेवा भनिन्छ यस्तो चीज छ। ठीक छ, तपाइँको क्लस्टरहरूमा पूर्वनिर्धारित रूपमा, सम्भवतः, सेवाले IP तालिकाहरू प्रयोग गरेर काम गर्दछ।

यदि तपाइँ एक बिलियन पोडहरू चलाउनुहुन्छ, उदाहरणका लागि, र त्यसपछि कुबेरनेटिसलाई नयाँ सेवाहरू सिर्जना गर्न बाध्य पार्न स्क्रिप्ट प्रयोग गर्नुहोस्:

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

क्लस्टरको सबै नोडहरूमा, अधिक र अधिक नयाँ iptables नियमहरू लगभग एकै साथ उत्पन्न हुनेछ। यसबाहेक, प्रत्येक सेवाको लागि एक अरब iptables नियमहरू उत्पन्न गरिनेछ।

मैले यो सम्पूर्ण कुरा धेरै हजार, दस सम्म जाँच गरें। र समस्या यो छ कि यो थ्रेसहोल्डमा पहिले नै नोडमा ssh गर्न धेरै समस्याग्रस्त छ। किनभने प्याकेटहरू, धेरै चेनहरू मार्फत जाँदै, धेरै राम्रो महसुस गर्न थाल्छन्।

र यो, पनि, सबै Kubernetes को सहयोग संग हल गरिएको छ। त्यहाँ यस्तो संसाधन कोटा वस्तु छ। क्लस्टरमा नेमस्पेसका लागि उपलब्ध स्रोत र वस्तुहरूको सङ्ख्या सेट गर्छ। हामी Kubernetes क्लस्टरको प्रत्येक नेमस्पेसमा yaml वस्तु सिर्जना गर्न सक्छौं। यो वस्तु प्रयोग गरेर, हामी भन्न सक्छौं कि हामीसँग यो नेमस्पेसको लागि आवंटित अनुरोध र सीमाहरूको निश्चित संख्या छ, र त्यसपछि हामी भन्न सक्छौं कि यो नेमस्पेसमा 10 सेवाहरू र 10 पोडहरू सिर्जना गर्न सम्भव छ। र एकल विकासकर्ताले कम्तिमा साँझ आफैलाई निसासाउन सक्छ। कुबर्नेट्सले उसलाई भन्नेछन्: "तपाईले आफ्नो पोडलाई त्यो मात्रामा मापन गर्न सक्नुहुन्न, किनभने स्रोत कोटा भन्दा बढी छ।" त्यो हो, समस्या समाधान भयो। यहाँ कागजात.

यस सन्दर्भमा एउटा समस्याको विषय उठ्छ। Kubernetes मा नेमस्पेस बनाउन कत्ति गाह्रो भइरहेको छ भन्ने तपाईंले महसुस गर्नुहुन्छ। यसलाई सिर्जना गर्न, हामीले धेरै चीजहरूलाई ध्यानमा राख्नु पर्छ।

स्रोत कोटा + सीमा दायरा + RBAC
• एउटा नेमस्पेस बनाउनुहोस्
• भित्र एक सीमा दायरा सिर्जना गर्नुहोस्
• भित्र रिसोर्सकोटा सिर्जना गर्नुहोस्
• CI को लागि सेवा खाता सिर्जना गर्नुहोस्
• CI र प्रयोगकर्ताहरूको लागि रोलबाइन्डिङ सिर्जना गर्नुहोस्
• वैकल्पिक रूपमा आवश्यक सेवा पोडहरू सुरू गर्नुहोस्

त्यसकारण, म यो अवसरलाई मेरो विकास साझा गर्न चाहन्छु। त्यहाँ SDK अपरेटर भनिन्छ यस्तो चीज छ। यो Kubernetes क्लस्टरको लागि अपरेटरहरू लेख्ने तरिका हो। तपाईंले Ansible प्रयोग गरेर कथनहरू लेख्न सक्नुहुन्छ।

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

सानो एक यो सम्पूर्ण जटिल प्रक्रियालाई सजिलो बनाउन.

र निष्कर्षमा। यो सबै संग के गर्ने?
पहिले। पोड सुरक्षा नीति राम्रो छ। र यस तथ्यको बावजुद कुनै पनि Kubernetes स्थापनाकर्ताहरूले तिनीहरूलाई आजसम्म प्रयोग गर्दैनन्, तपाईंले अझै पनि तिनीहरूलाई आफ्नो क्लस्टरहरूमा प्रयोग गर्न आवश्यक छ।

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

LimitRange/ResourceQuota - यो प्रयोग गर्ने समय हो। हामीले यो लामो समय पहिले प्रयोग गर्न थाल्यौं, र लामो समयसम्म म पक्का थिएँ कि सबैले यसलाई प्रयोग गरिरहेका थिए। यो दुर्लभ छ कि बाहिर भयो।

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

कतिपय कुरा धेरै दुखद र पीडादायी हुन्छन् । उदाहरणका लागि, निश्चित अवस्थाहरूमा, कुबेरनेट क्लस्टरमा रहेको क्यूबलेटहरूले अनाधिकृत प्रयोगकर्तालाई warlocks डाइरेक्टरीका सामग्रीहरू दिन सक्छन्।

यहाँ मैले तपाईंलाई भनेको सबै कुरा कसरी पुन: उत्पादन गर्ने भन्ने बारे निर्देशनहरू छन्। रिसोर्सकोटा र पोड सुरक्षा नीति कस्तो देखिन्छ भन्ने उत्पादन उदाहरणहरू भएका फाइलहरू छन्। र तपाईं यो सबै छुन सक्नुहुन्छ।

सबैलाई धन्यवाद।

स्रोत: www.habr.com