जाना? दे घुमा के! शेल-ऑपरेटर से मिलें (KubeCon EU'2020 से समीक्षा और वीडियो रिपोर्ट)

इस वर्ष, मुख्य यूरोपीय कुबेरनेट्स सम्मेलन - क्यूबकॉन + क्लाउडनेटिवकॉन यूरोप 2020 - आभासी था। हालाँकि, प्रारूप में इस तरह के बदलाव ने हमें अपनी लंबे समय से नियोजित रिपोर्ट "जाओ?" देने से नहीं रोका। दे घुमा के! हमारे ओपन सोर्स प्रोजेक्ट के लिए समर्पित शेल-ऑपरेटर से मिलें शेल-ऑपरेटर.

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

परिचय रिपोर्ट का वीडियो (~23 मिनट अंग्रेजी में, लेख की तुलना में काफ़ी अधिक जानकारीपूर्ण) और पाठ्य रूप में इसका मुख्य अंश। जाना!

फ़्लैंट में हम हर चीज़ को लगातार अनुकूलित और स्वचालित करते हैं। आज हम एक और रोमांचक अवधारणा के बारे में बात करेंगे। मिलो: क्लाउड-नेटिव शेल स्क्रिप्टिंग!

हालाँकि, आइए उस संदर्भ से शुरू करें जिसमें यह सब होता है: कुबेरनेट्स।

कुबेरनेट्स एपीआई और नियंत्रक

कुबेरनेट्स में एपीआई को प्रत्येक प्रकार के ऑब्जेक्ट के लिए निर्देशिकाओं के साथ एक प्रकार के फ़ाइल सर्वर के रूप में दर्शाया जा सकता है। इस सर्वर पर ऑब्जेक्ट (संसाधन) को YAML फ़ाइलों द्वारा दर्शाया जाता है। इसके अलावा, सर्वर में एक बुनियादी एपीआई है जो आपको तीन चीजें करने की अनुमति देती है:

• प्राप्त करना संसाधन अपने प्रकार और नाम से;
• परिवर्तन संसाधन (इस मामले में, सर्वर केवल "सही" ऑब्जेक्ट संग्रहीत करता है - सभी गलत तरीके से बनाई गई या अन्य निर्देशिकाओं के लिए इरादा छोड़ दिया जाता है);
• नज़र रखें संसाधन के लिए (इस मामले में, उपयोगकर्ता को तुरंत इसका वर्तमान/अद्यतित संस्करण प्राप्त होता है)।

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

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

नियंत्रक दो मुख्य प्रकार के होते हैं. पहला कुबेरनेट्स से जानकारी लेता है, इसे नेस्टेड लॉजिक के अनुसार संसाधित करता है, और इसे K8s पर लौटाता है। दूसरा कुबेरनेट्स से जानकारी लेता है, लेकिन, पहले प्रकार के विपरीत, कुछ बाहरी संसाधनों की स्थिति को बदल देता है।

आइए कुबेरनेट्स में परिनियोजन बनाने की प्रक्रिया पर करीब से नज़र डालें:

• परिनियोजन नियंत्रक (शामिल) kube-controller-manager) परिनियोजन के बारे में जानकारी प्राप्त करता है और एक रेप्लिकासेट बनाता है।
• रेप्लिकासेट इस जानकारी के आधार पर दो प्रतिकृतियां (दो पॉड) बनाता है, लेकिन ये पॉड अभी तक शेड्यूल नहीं किए गए हैं।
• शेड्यूलर पॉड्स को शेड्यूल करता है और उनके YAMLs में नोड जानकारी जोड़ता है।
• क्यूबलेट्स बाहरी संसाधन में परिवर्तन करते हैं (डॉकर कहते हैं)।

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

शैल-ऑपरेटर

यह पता चला है कि कुबेरनेट्स विभिन्न नियंत्रकों के संयुक्त कार्य पर आधारित है (कुबेरनेट्स ऑपरेटर भी नियंत्रक हैं)। सवाल उठता है कि न्यूनतम प्रयास से अपना खुद का ऑपरेटर कैसे बनाया जाए? और यहां जिसे हमने विकसित किया वह बचाव के लिए आता है शेल-ऑपरेटर. यह सिस्टम प्रशासकों को परिचित तरीकों का उपयोग करके अपने स्वयं के स्टेटमेंट बनाने की अनुमति देता है।

सरल उदाहरण: रहस्यों की नकल करना

आइए एक सरल उदाहरण देखें.

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

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

अब जब कार्य तैयार हो गया है, तो शेल-ऑपरेटर का उपयोग करके इसे लागू करना शुरू करने का समय आ गया है। लेकिन सबसे पहले शेल-ऑपरेटर के बारे में कुछ शब्द कहना उचित है।

शेल-ऑपरेटर कैसे काम करता है

कुबेरनेट्स में अन्य कार्यभार की तरह, शेल-ऑपरेटर अपने स्वयं के पॉड में चलता है। इस पॉड में निर्देशिका में /hooks निष्पादन योग्य फ़ाइलें संग्रहीत की जाती हैं। ये बैश, पायथन, रूबी आदि में स्क्रिप्ट हो सकते हैं। हम ऐसी निष्पादन योग्य फ़ाइलों को हुक कहते हैं (हुक).

शेल-ऑपरेटर कुबेरनेट्स इवेंट की सदस्यता लेता है और उन इवेंट के जवाब में इन हुक को चलाता है जिनकी हमें आवश्यकता होती है।

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

बैश में एक ऑपरेटर बनाना

अब हम कार्यान्वयन के लिए तैयार हैं। ऐसा करने के लिए, हमें दो फ़ंक्शन लिखने होंगे (वैसे, हम अनुशंसा करते हैं पुस्तकालय शेल_लिब, जो बैश में हुक लिखने को बहुत सरल बनाता है):

• कॉन्फ़िगरेशन चरण के लिए पहले की आवश्यकता है - यह बाइंडिंग संदर्भ प्रदर्शित करता है;
• दूसरे में हुक का मुख्य तर्क शामिल है।

#!/bin/bash

source /shell_lib.sh

function __config__() {
  cat << EOF
    configVersion: v1
    # BINDING CONFIGURATION
EOF
}

function __main__() {
  # THE LOGIC
}

hook::run "$@"

अगला कदम यह तय करना है कि हमें किन वस्तुओं की आवश्यकता है। हमारे मामले में, हमें ट्रैक करने की आवश्यकता है:

• परिवर्तनों के लिए स्रोत रहस्य;
• क्लस्टर में सभी नामस्थान, ताकि आप जान सकें कि किसके साथ एक लेबल जुड़ा हुआ है;
• लक्ष्य रहस्य यह सुनिश्चित करने के लिए कि वे सभी स्रोत रहस्य के साथ समन्वयित हैं।

गुप्त स्रोत की सदस्यता लें

इसके लिए बाइंडिंग कॉन्फ़िगरेशन काफी सरल है। हम नाम के साथ संकेत देते हैं कि हम रहस्य में रुचि रखते हैं mysecret नेमस्पेस में default:

function __config__() {
  cat << EOF
    configVersion: v1
    kubernetes:
    - name: src_secret
      apiVersion: v1
      kind: Secret
      nameSelector:
        matchNames:
        - mysecret
      namespace:
        nameSelector:
          matchNames: ["default"]
      group: main
EOF

परिणामस्वरूप, स्रोत रहस्य बदलने पर हुक चालू हो जाएगा (src_secret) और निम्नलिखित बाध्यकारी संदर्भ प्राप्त करें:

जैसा कि आप देख सकते हैं, इसमें नाम और संपूर्ण वस्तु शामिल है।

नामस्थानों का ट्रैक रखना

अब आपको नेमस्पेस की सदस्यता लेनी होगी। ऐसा करने के लिए, हम निम्नलिखित बाइंडिंग कॉन्फ़िगरेशन निर्दिष्ट करते हैं:

- name: namespaces
  group: main
  apiVersion: v1
  kind: Namespace
  jqFilter: |
    {
      namespace: .metadata.name,
      hasLabel: (
       .metadata.labels // {} |  
         contains({"secret": "yes"})
      )
    }
  group: main
  keepFullObjectsInMemory: false

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

इसमें एक सारणी है filterResults क्लस्टर में प्रत्येक नामस्थान के लिए। बूलियन चर hasLabel इंगित करता है कि कोई लेबल किसी दिए गए नामस्थान से जुड़ा हुआ है या नहीं। चयनकर्ता keepFullObjectsInMemory: false इंगित करता है कि संपूर्ण वस्तुओं को स्मृति में रखने की कोई आवश्यकता नहीं है।

लक्ष्य रहस्यों पर नज़र रखना

हम उन सभी रहस्यों की सदस्यता लेते हैं जिनमें एक एनोटेशन निर्दिष्ट है managed-secret: "yes" (ये हमारा लक्ष्य हैं dst_secrets):

- name: dst_secrets
  apiVersion: v1
  kind: Secret
  labelSelector:
    matchLabels:
      managed-secret: "yes"
  jqFilter: |
    {
      "namespace":
        .metadata.namespace,
      "resourceVersion":
        .metadata.annotations.resourceVersion
    }
  group: main
  keepFullObjectsInMemory: false

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

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

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

• अगर hasLabel मामलों true वर्तमान नामस्थान के लिए:
  • वैश्विक रहस्य की तुलना स्थानीय रहस्य से करता है:
    • यदि वे समान हैं, तो इससे कुछ नहीं होता;
    • यदि वे भिन्न हैं - निष्पादित करता है kubectl replace या create;
• अगर hasLabel मामलों false वर्तमान नामस्थान के लिए:
  • यह सुनिश्चित करता है कि सीक्रेट दिए गए नेमस्पेस में नहीं है:
    • यदि स्थानीय रहस्य मौजूद है, तो इसका उपयोग करके इसे हटा दें kubectl delete;
    • यदि स्थानीय रहस्य का पता नहीं चलता है, तो यह कुछ नहीं करता है।

बैश में एल्गोरिदम का कार्यान्वयन आप हमारे में डाउनलोड कर सकते हैं उदाहरण सहित रिपॉजिटरी.

इस तरह हम YAML कॉन्फिगरेशन की 35 लाइनों और लगभग उतनी ही मात्रा में बैश कोड का उपयोग करके एक सरल Kubernetes नियंत्रक बनाने में सक्षम हुए! शेल-ऑपरेटर का काम उन्हें एक साथ जोड़ना है।

हालाँकि, रहस्यों की प्रतिलिपि बनाना उपयोगिता के अनुप्रयोग का एकमात्र क्षेत्र नहीं है। यह दिखाने के लिए यहां कुछ और उदाहरण दिए गए हैं कि वह क्या करने में सक्षम है।

उदाहरण 1: कॉन्फ़िगमैप में परिवर्तन करना

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

अब मान लेते हैं कि कॉन्फिग मैप बदल गया है (v.2)। हालाँकि, पॉड्स कॉन्फ़िगमैप के पिछले संस्करण (v.1) का उपयोग करेंगे:

मैं उन्हें नए कॉन्फिग मैप (v.2) पर कैसे स्विच करवा सकता हूं? उत्तर सरल है: एक टेम्पलेट का उपयोग करें। आइए अनुभाग में एक चेकसम एनोटेशन जोड़ें template परिनियोजन कॉन्फ़िगरेशन:

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

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

उदाहरण 2: कस्टम संसाधन परिभाषाओं के साथ कार्य करना

जैसा कि आप जानते हैं, कुबेरनेट्स आपको कस्टम प्रकार के ऑब्जेक्ट बनाने की अनुमति देता है। उदाहरण के लिए, आप तरह बना सकते हैं MysqlDatabase. मान लें कि इस प्रकार में दो मेटाडेटा पैरामीटर हैं: name и namespace.

apiVersion: example.com/v1alpha1
kind: MysqlDatabase
metadata:
  name: foo
  namespace: bar

हमारे पास विभिन्न नामस्थानों वाला एक कुबेरनेट्स क्लस्टर है जिसमें हम MySQL डेटाबेस बना सकते हैं। इस मामले में शेल-ऑपरेटर का उपयोग संसाधनों को ट्रैक करने के लिए किया जा सकता है MysqlDatabase, उन्हें MySQL सर्वर से कनेक्ट करना और क्लस्टर की वांछित और देखी गई स्थितियों को सिंक्रनाइज़ करना।

उदाहरण 3: क्लस्टर नेटवर्क मॉनिटरिंग

जैसा कि आप जानते हैं, पिंग का उपयोग किसी नेटवर्क की निगरानी करने का सबसे सरल तरीका है। इस उदाहरण में हम दिखाएंगे कि शेल-ऑपरेटर का उपयोग करके ऐसी निगरानी कैसे लागू की जाए।

सबसे पहले, आपको नोड्स की सदस्यता लेनी होगी। शेल ऑपरेटर को प्रत्येक नोड के नाम और आईपी पते की आवश्यकता होती है। उनकी मदद से वह इन नोड्स को पिंग करेगा।

configVersion: v1
kubernetes:
- name: nodes
  apiVersion: v1
  kind: Node
  jqFilter: |
    {
      name: .metadata.name,
      ip: (
       .status.addresses[] |  
        select(.type == "InternalIP") |
        .address
      )
    }
  group: main
  keepFullObjectsInMemory: false
  executeHookOnEvent: []
schedule:
- name: every_minute
  group: main
  crontab: "* * * * *"

प्राचल executeHookOnEvent: [] हुक को किसी भी घटना के जवाब में चलने से रोकता है (यानी, नोड्स को बदलने, जोड़ने, हटाने के जवाब में)। हालाँकि, वह दौड़ेगा (और नोड्स की सूची अपडेट करें) अनुसूचित - हर मिनट, जैसा कि फ़ील्ड द्वारा निर्धारित किया गया है schedule.

अब सवाल यह उठता है कि पैकेट खोने जैसी समस्याओं के बारे में हमें वास्तव में कैसे पता चलता है? आइए कोड पर एक नज़र डालें:

function __main__() {
  for i in $(seq 0 "$(context::jq -r '(.snapshots.nodes | length) - 1')"); do
    node_name="$(context::jq -r '.snapshots.nodes['"$i"'].filterResult.name')"
    node_ip="$(context::jq -r '.snapshots.nodes['"$i"'].filterResult.ip')"
    packets_lost=0
    if ! ping -c 1 "$node_ip" -t 1 ; then
      packets_lost=1
    fi
    cat >> "$METRICS_PATH" <<END
      {
        "name": "node_packets_lost",
        "add": $packets_lost,
        "labels": {
          "node": "$node_name"
        }
      }
END
  done
}

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

यहाँ तो आप क्लस्टर में सरल नेटवर्क मॉनिटरिंग के लिए एक ऑपरेटर बना सकते हैं।

कतारबद्ध तंत्र

शेल-ऑपरेटर में निर्मित एक अन्य महत्वपूर्ण तंत्र का वर्णन किए बिना यह लेख अधूरा होगा। कल्पना करें कि यह क्लस्टर में किसी घटना के जवाब में किसी प्रकार का हुक निष्पादित करता है।

• यदि उसी समय क्लस्टर में कुछ घटित हो जाए तो क्या होगा? एक और आयोजन?
• क्या शेल-ऑपरेटर हुक का दूसरा उदाहरण चलाएगा?
• क्या होगा यदि, कहें, क्लस्टर में एक साथ पाँच घटनाएँ घटित हों?
• क्या शेल-ऑपरेटर उन्हें समानांतर में संसाधित करेगा?
• मेमोरी और सीपीयू जैसे उपभोग किए गए संसाधनों के बारे में क्या?

सौभाग्य से, शेल-ऑपरेटर के पास एक अंतर्निहित कतार तंत्र है। सभी घटनाओं को कतारबद्ध और क्रमिक रूप से संसाधित किया जाता है।

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

ये भी घटनाओं को एक बड़ी घटना में जोड़ा जा सकता है. इसके लिए पैरामीटर जिम्मेदार है group बाइंडिंग कॉन्फ़िगरेशन में.

आप कितनी भी संख्या में कतारें/हुक और उनके विभिन्न संयोजन बना सकते हैं। उदाहरण के लिए, एक कतार दो हुक के साथ काम कर सकती है, या इसके विपरीत।

आपको बस फ़ील्ड को तदनुसार कॉन्फ़िगर करना है queue बाइंडिंग कॉन्फ़िगरेशन में. यदि कतार का नाम निर्दिष्ट नहीं है, तो हुक डिफ़ॉल्ट कतार पर चलता है (default). यह कतार तंत्र आपको हुक के साथ काम करते समय सभी संसाधन प्रबंधन समस्याओं को पूरी तरह से हल करने की अनुमति देता है।

निष्कर्ष

हमने समझाया कि शेल-ऑपरेटर क्या है, दिखाया कि इसका उपयोग कुबेरनेट्स ऑपरेटरों को जल्दी और आसानी से बनाने के लिए कैसे किया जा सकता है, और इसके उपयोग के कई उदाहरण दिए।

शेल-ऑपरेटर के बारे में विस्तृत जानकारी, साथ ही इसका उपयोग करने के तरीके पर एक त्वरित ट्यूटोरियल संबंधित में उपलब्ध है GitHub पर रिपॉजिटरी. प्रश्नों के लिए हमसे संपर्क करने में संकोच न करें: आप उन पर विशेष चर्चा कर सकते हैं टेलीग्राम समूह (रूसी में) या में यह मंच (अंग्रेजी में)।

और यदि आपको यह पसंद आया, तो हम हमेशा GitHub पर नए अंक/पीआर/सितारों को देखकर प्रसन्न होते हैं, जहां, वैसे, आप अन्य पा सकते हैं दिलचस्प परियोजनाएँ. उनमें से यह हाइलाइट करने लायक है addon-ऑपरेटर, जो शेल-ऑपरेटर का बड़ा भाई है. यह उपयोगिता ऐड-ऑन स्थापित करने के लिए हेल्म चार्ट का उपयोग करती है, अपडेट प्रदान कर सकती है और विभिन्न चार्ट पैरामीटर/मानों की निगरानी कर सकती है, चार्ट की स्थापना प्रक्रिया को नियंत्रित कर सकती है, और क्लस्टर में घटनाओं के जवाब में उन्हें संशोधित भी कर सकती है।

वीडियो और स्लाइड

प्रदर्शन से वीडियो (~23 मिनट):

रिपोर्ट की प्रस्तुति:

पुनश्च

हमारे ब्लॉग पर भी पढ़ें:

• «शेल-ऑपरेटर के साथ कुबेरनेट्स ऑपरेटरों का आसान निर्माण: वर्ष भर में परियोजना की प्रगति";
• «शेल-ऑपरेटर का परिचय: कुबेरनेट्स के लिए ऑपरेटर बनाना अब आसान हो गया है";
• «क्या कुबेरनेट्स क्लस्टर तैयार करना आसान और सुविधाजनक है? ऐडऑन-ऑपरेटर की घोषणा";
• «कुबेरनेट्स का विस्तार और पूरक" (समीक्षा और वीडियो रिपोर्ट).

स्रोत: www.habr.com