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

यस वर्ष, युरोपको प्रमुख कुबर्नेट्स सम्मेलन - कुबेकन + क्लाउडनेटिभकन युरोप २०२० - भर्चुअल थियो। यद्यपि, ढाँचामा यो परिवर्तनले हामीलाई हाम्रो खुला स्रोत परियोजनामा ​​समर्पित हाम्रो लामो-योजनाबद्ध भाषण, "जानुहोस्? बाश! शेल अपरेटरलाई भेट्नुहोस्" प्रदान गर्नबाट रोकेन। शेल अपरेटर.

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

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

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

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

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

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

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

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

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

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

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

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

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

शेल अपरेटर

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

एउटा साधारण उदाहरण: गोप्य कुराहरूको प्रतिलिपि बनाउने

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

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

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

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

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

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

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

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

Bash मा अपरेटर सिर्जना गर्दै

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

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

#!/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;
    • यदि स्थानीय गोप्य फेला परेन भने, यसले केही गर्दैन।

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

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

यद्यपि, गोप्य कुराहरू प्रतिलिपि गर्नु उपयोगिताको एक मात्र प्रयोग होइन। यसको क्षमताहरू प्रदर्शन गर्न यहाँ केही थप उदाहरणहरू छन्।

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

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

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

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

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

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

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

तपाईंलाई थाहा छ, कुबर्नेट्सले तपाईंलाई अनुकूलन वस्तु प्रकारहरू (प्रकारहरू) सिर्जना गर्न अनुमति दिन्छ। उदाहरणका लागि, तपाईं एक प्रकार सिर्जना गर्न सक्नुहुन्छ 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)। यो क्युइङ मेकानिजमले हामीलाई हुकहरूसँग काम गर्दा सबै स्रोत व्यवस्थापन समस्याहरू पूर्ण रूपमा समाधान गर्न अनुमति दिन्छ।

निष्कर्षमा

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

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

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

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

प्रदर्शनको भिडियो (~२३ मिनेट):

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

PS

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

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

स्रोत: www.habr.com