जाउ? बास! शेल-अपरेटरलाई भेट्नुहोस् (कुबेकन EU'2020 बाट समीक्षा र भिडियो रिपोर्ट)

यस वर्ष, मुख्य यूरोपीयन कुबर्नेट्स सम्मेलन - KubeCon + CloudNativeCon Europe 2020 - भर्चुअल थियो। जे होस्, ढाँचामा यस्तो परिवर्तनले हामीलाई हाम्रो लामो-नियोजित रिपोर्ट डेलिभर गर्नबाट रोकेन "जानुहोस्? बास! हाम्रो खुला स्रोत परियोजनामा ​​समर्पित शेल-अपरेटरलाई भेट्नुहोस् शेल अपरेटर.

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

परिचय दिँदै रिपोर्ट को भिडियो (अङ्ग्रेजीमा ~23 मिनेट, लेख भन्दा उल्लेखनीय रूपमा अधिक जानकारीमूलक) र पाठ फारममा यसको मुख्य अंश। जाउ!

फ्ल्यान्टमा हामी निरन्तर सबै कुरालाई अप्टिमाइज र स्वचालित गर्छौं। आज हामी अर्को रोचक अवधारणा बारे कुरा गर्नेछौं। भेट्नुहोस्: क्लाउड-नेटिभ शेल स्क्रिप्टिङ!

जे होस्, यो सबै हुन्छ भन्ने सन्दर्भबाट सुरु गरौं: कुबर्नेट्स।

Kubernetes API र नियन्त्रकहरू

Kubernetes मा API लाई प्रत्येक प्रकारको वस्तुको लागि डाइरेक्टरीहरू सहितको फाइल सर्भरको रूपमा प्रतिनिधित्व गर्न सकिन्छ। यस सर्भरमा वस्तुहरू (संसाधनहरू) YAML फाइलहरूद्वारा प्रतिनिधित्व गरिन्छ। थप रूपमा, सर्भरसँग आधारभूत API छ जसले तपाईंलाई तीन चीजहरू गर्न अनुमति दिन्छ:

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

यसरी, Kubernetes ले तीनवटा आधारभूत विधिहरू (YAML manifests को लागि) फाइल सर्भरको एक प्रकारको रूपमा कार्य गर्दछ (हो, वास्तवमा त्यहाँ अरूहरू छन्, तर हामी तिनीहरूलाई अहिलेको लागि छोड्नेछौं)।

समस्या यो हो कि सर्भरले मात्र जानकारी भण्डार गर्न सक्छ। यसलाई काम गर्न तपाईंलाई आवश्यक छ नियन्त्रक - Kubernetes को संसारमा दोस्रो सबैभन्दा महत्त्वपूर्ण र आधारभूत अवधारणा।

त्यहाँ दुई मुख्य प्रकारका नियन्त्रकहरू छन्। पहिलोले Kubernetes बाट जानकारी लिन्छ, यसलाई नेस्टेड तर्क अनुसार प्रशोधन गर्छ, र K8s मा फर्काउँछ। दोस्रोले Kubernetes बाट जानकारी लिन्छ, तर, पहिलो प्रकारको विपरीत, केहि बाह्य स्रोतहरूको अवस्था परिवर्तन गर्दछ।

Kubernetes मा डिप्लोइमेन्ट सिर्जना गर्ने प्रक्रियालाई नजिकबाट हेरौं:

• डिप्लोइमेन्ट कन्ट्रोलर (समावेश kube-controller-manager) डिप्लोइमेन्टको बारेमा जानकारी प्राप्त गर्दछ र प्रतिकृतिसेट सिर्जना गर्दछ।
• ReplicaSet ले यस जानकारीको आधारमा दुई प्रतिकृतिहरू (दुई पोडहरू) सिर्जना गर्दछ, तर यी पोडहरू अझै निर्धारित गरिएका छैनन्।
• अनुसूचकले पोडहरू अनुसूचित गर्दछ र तिनीहरूको YAML मा नोड जानकारी थप्छ।
• कुबेलेट्सले बाह्य स्रोतमा परिवर्तन गर्दछ (डकर भन्नुहोस्)।

त्यसपछि यो सम्पूर्ण अनुक्रम उल्टो क्रममा दोहोर्याइएको छ: कुबेलेटले कन्टेनरहरू जाँच गर्दछ, पोडको स्थिति गणना गर्दछ र यसलाई फिर्ता पठाउँछ। ReplicaSet नियन्त्रकले स्थिति प्राप्त गर्दछ र प्रतिकृति सेटको स्थिति अद्यावधिक गर्दछ। एउटै कुरा डिप्लोयमेन्ट कन्ट्रोलरसँग हुन्छ र प्रयोगकर्ताले अन्ततः अद्यावधिक (वर्तमान) स्थिति प्राप्त गर्दछ।

शेल अपरेटर

यो बाहिर जान्छ कि Kubernetes विभिन्न नियन्त्रकहरूको संयुक्त काममा आधारित छ (Kubernetes अपरेटरहरू पनि नियन्त्रकहरू हुन्)। प्रश्न उठ्छ, कसरी न्यूनतम प्रयासमा आफ्नै अपरेटर सिर्जना गर्ने? र यहाँ हामीले विकसित गरेको उद्धारको लागि आउँछ शेल अपरेटर। यसले प्रणाली प्रशासकहरूलाई परिचित विधिहरू प्रयोग गरेर आफ्नै बयानहरू सिर्जना गर्न अनुमति दिन्छ।

सरल उदाहरण: गोप्य प्रतिलिपि

एउटा साधारण उदाहरण हेरौं।

मानौं हामीसँग कुबेरनेट क्लस्टर छ। यसमा नाम स्थान छ default केहि गोप्य संग mysecret। थप रूपमा, त्यहाँ क्लस्टरमा अन्य नेमस्पेसहरू छन्। तिनीहरूमध्ये केही तिनीहरूसँग एक विशिष्ट लेबल संलग्न छ। हाम्रो लक्ष्य लेबलको साथ नेमस्पेसहरूमा गोप्य प्रतिलिपि गर्ने हो।

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

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

कसरी शेल-अपरेटर काम गर्दछ

Kubernetes मा अन्य वर्कलोडहरू जस्तै, शेल-अपरेटर आफ्नै पोडमा चल्छ। डाइरेक्टरी मा यो पोड मा /hooks कार्यान्वयनयोग्य फाइलहरू भण्डारण गरिएका छन्। यी Bash, Python, Ruby, आदि मा स्क्रिप्ट हुन सक्छ। हामी त्यस्ता कार्यान्वयनयोग्य फाइलहरूलाई हुक (हुकहरु).

शेल-अपरेटरले Kubernetes घटनाहरूको सदस्यता लिन्छ र हामीलाई आवश्यक पर्ने घटनाहरूको प्रतिक्रियामा यी हुकहरू चलाउँछ।

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

Bash मा अपरेटर बनाउँदै

अब हामी कार्यान्वयनको लागि तयार छौं। यो गर्नको लागि, हामीले दुई प्रकार्यहरू लेख्न आवश्यक छ (वैसे, हामी सिफारिस गर्दछौं पुस्तकालय shell_lib, जसले बासमा लेख्ने हुकहरूलाई धेरै सरल बनाउँछ):

• पहिलो कन्फिगरेसन चरणको लागि आवश्यक छ - यसले बाध्यकारी सन्दर्भ प्रदर्शन गर्दछ;
• दोस्रोले हुकको मुख्य तर्क समावेश गर्दछ।

#!/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

तपाईले देख्न सक्नुहुन्छ, नामको साथ कन्फिगरेसनमा नयाँ फिल्ड देखा परेको छ jqFilter। जसरी यसको नामले सुझाव दिन्छ, 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;
    • स्थानीय गोप्य पत्ता लागेन भने, यसले केही गर्दैन।

Bash मा एल्गोरिथ्म को कार्यान्वयन तपाईं हाम्रो मा डाउनलोड गर्न सक्नुहुन्छ उदाहरणका साथ भण्डारहरू.

यसरी हामीले YAML कन्फिगरेसनको 35 लाइनहरू र बास कोडको समान मात्रा प्रयोग गरेर एउटा साधारण Kubernetes नियन्त्रक सिर्जना गर्न सक्षम भयौं! शेल-अपरेटरको काम तिनीहरूलाई एकसाथ जोड्नु हो।

जे होस्, गोप्य प्रतिलिपि गर्नु उपयोगिताको आवेदनको मात्र क्षेत्र होइन। उहाँ के सक्षम हुनुहुन्छ भनी देखाउन यहाँ केही उदाहरणहरू छन्।

उदाहरण १: कन्फिगम्यापमा परिवर्तनहरू गर्दै

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

अब मानौं कि कन्फिगम्याप परिवर्तन भएको छ (v.2)। यद्यपि, पोडहरूले ConfigMap (v.1) को अघिल्लो संस्करण प्रयोग गर्नेछ:

म तिनीहरूलाई नयाँ कन्फिगम्याप (v.2) मा स्विच गर्न कसरी प्राप्त गर्न सक्छु? जवाफ सरल छ: टेम्प्लेट प्रयोग गर्नुहोस्। खण्डमा चेकसम एनोटेसन थपौं template डिप्लोइमेन्ट कन्फिगरेसनहरू:

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

यदि प्रयोगकर्ताले कन्फिगम्यापमा परिवर्तन गर्छ भने, शेल-अपरेटरले तिनीहरूलाई याद गर्नेछ र चेकसम पुन: गणना गर्नेछ। जस पछि कुबर्नेट्सको जादू खेलमा आउनेछ: अर्केस्ट्रेटरले पोडलाई मार्नेछ, नयाँ सिर्जना गर्नेछ, यो बन्नको लागि पर्खनुहोस्। Ready, र अर्कोमा जान्छ। नतिजाको रूपमा, डिप्लोइमेन्ट सिङ्क्रोनाइज हुनेछ र कन्फिगम्यापको नयाँ संस्करणमा स्विच हुनेछ।

उदाहरण २: अनुकूलन स्रोत परिभाषाहरूसँग काम गर्दै

तपाईंलाई थाहा छ, Kubernetes ले तपाईंलाई वस्तुहरूको अनुकूलन प्रकारहरू सिर्जना गर्न अनुमति दिन्छ। उदाहरणका लागि, तपाईं प्रकार सिर्जना गर्न सक्नुहुन्छ MysqlDatabase। यस प्रकारको दुई मेटाडेटा प्यारामिटरहरू छन् भनौं: name и namespace.

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

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

उदाहरण ३: क्लस्टर नेटवर्क निगरानी

तपाईलाई थाहा छ, पिङ प्रयोग गर्नु भनेको सञ्जाल निगरानी गर्ने सबैभन्दा सरल तरिका हो। यस उदाहरणमा हामी शेल-अपरेटर प्रयोग गरेर यस्तो निगरानी कसरी लागू गर्ने भनेर देखाउनेछौं।

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

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
}

हामी नोडहरूको सूची मार्फत पुनरावृत्ति गर्छौं, तिनीहरूको नाम र IP ठेगानाहरू पाउनुहोस्, तिनीहरूलाई पिंग गर्नुहोस् र परिणामहरू प्रोमेथियसलाई पठाउनुहोस्। शेल-अपरेटरले प्रोमेथियसमा मेट्रिक्स निर्यात गर्न सक्छ, तिनीहरूलाई वातावरण चरमा निर्दिष्ट मार्ग अनुसार अवस्थित फाइलमा बचत गर्दै $METRICS_PATH.

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

लामबद्ध संयन्त्र

शेल-अपरेटरमा निर्मित अर्को महत्त्वपूर्ण संयन्त्रको वर्णन नगरी यो लेख अपूर्ण हुनेछ। कल्पना गर्नुहोस् कि यसले क्लस्टरमा भएको घटनाको प्रतिक्रियामा केही प्रकारको हुक कार्यान्वयन गर्दछ।

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

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

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

साथै यी घटनाहरूलाई एक ठूलोमा जोड्न सकिन्छ। प्यारामिटर यसको लागि जिम्मेवार छ group बाध्यकारी कन्फिगरेसनमा।

तपाईं कुनै पनि संख्यामा लाम/हुकहरू र तिनीहरूका विभिन्न संयोजनहरू सिर्जना गर्न सक्नुहुन्छ। उदाहरण को लागी, एक लाम दुई हुक संग काम गर्न सक्छ, वा विपरित।

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

निष्कर्षमा

हामीले शेल-अपरेटर के हो भनेर व्याख्या गर्यौं, यसलाई कसरी छिटो र सहज रूपमा Kubernetes अपरेटरहरू सिर्जना गर्न प्रयोग गर्न सकिन्छ भनेर देखायौं, र यसको प्रयोगका धेरै उदाहरणहरू दियौं।

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

र यदि तपाईंलाई यो मनपर्यो भने, हामी GitHub मा नयाँ मुद्दाहरू/PR/ताराहरू देख्न पाउँदा खुसी छौं, जहाँ, तपाईंले अरूलाई फेला पार्न सक्नुहुन्छ। रोचक परियोजनाहरू। तिनीहरू मध्ये यो हाइलाइट गर्न लायक छ addon-operator, जुन शेल अपरेटरको ठूलो भाइ हो। यो उपयोगिताले एड-अनहरू स्थापना गर्न हेल्म चार्टहरू प्रयोग गर्दछ, अपडेटहरू डेलिभर गर्न र विभिन्न चार्ट प्यारामिटरहरू/मानहरू निगरानी गर्न, चार्टहरूको स्थापना प्रक्रिया नियन्त्रण गर्न, र क्लस्टरमा भएका घटनाहरूको प्रतिक्रियामा तिनीहरूलाई परिमार्जन गर्न पनि सक्छ।

भिडियो र स्लाइडहरू

प्रदर्शनबाट भिडियो (~ 23 मिनेट):

प्रतिवेदन प्रस्तुति:

PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

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

स्रोत: www.habr.com