जाऊ? बाश! शेल-ऑपरेटरला भेटा (कुबेकॉन EU'2020 कडून पुनरावलोकन आणि व्हिडिओ अहवाल)

या वर्षी, मुख्य युरोपियन कुबर्नेट्स कॉन्फरन्स - KubeCon + CloudNativeCon Europe 2020 - आभासी होती. तथापि, स्वरूपातील अशा बदलामुळे आम्हाला आमचा दीर्घ नियोजित अहवाल वितरित करण्यापासून रोखले नाही “जा? बाश! आमच्या मुक्त स्रोत प्रकल्पाला समर्पित शेल-ऑपरेटरला भेटा शेल-ऑपरेटर.

चर्चेतून प्रेरित असलेला हा लेख, कुबर्नेट्ससाठी ऑपरेटर तयार करण्याची प्रक्रिया सुलभ करण्याचा दृष्टीकोन सादर करतो आणि शेल-ऑपरेटर वापरून कमीत कमी प्रयत्नात तुम्ही स्वतःचे कसे बनवू शकता हे दाखवते.

परिचय देत आहे अहवालाचा व्हिडिओ (इंग्रजीमध्ये ~ 23 मिनिटे, लेखापेक्षा अधिक माहितीपूर्ण) आणि त्यातील मुख्य उतारा मजकूर स्वरूपात. जा!

फ्लॅंटमध्ये आम्ही सतत सर्वकाही ऑप्टिमाइझ आणि स्वयंचलित करतो. आज आपण आणखी एका रोमांचक संकल्पनेबद्दल बोलू. भेटा: क्लाउड-नेटिव्ह शेल स्क्रिप्टिंग!

तथापि, ज्या संदर्भात हे सर्व घडते त्या संदर्भासह प्रारंभ करूया: कुबर्नेट्स.

Kubernetes API आणि नियंत्रक

Kubernetes मधील API प्रत्येक प्रकारच्या ऑब्जेक्टसाठी निर्देशिकांसह फाइल सर्व्हरचा एक प्रकार म्हणून प्रस्तुत केले जाऊ शकते. या सर्व्हरवरील ऑब्जेक्ट्स (संसाधने) YAML फाइल्सद्वारे दर्शविले जातात. याव्यतिरिक्त, सर्व्हरमध्ये मूलभूत API आहे जे आपल्याला तीन गोष्टी करण्याची परवानगी देते:

• मिळवा त्याच्या प्रकार आणि नावानुसार संसाधन;
• बदल संसाधन (या प्रकरणात, सर्व्हर फक्त "योग्य" वस्तू संग्रहित करतो - सर्व चुकीच्या पद्धतीने तयार केलेले किंवा इतर निर्देशिकांसाठी हेतू टाकून दिलेले आहेत);
• ट्रॅक संसाधनासाठी (या प्रकरणात, वापरकर्त्यास त्याची वर्तमान/अद्ययावत आवृत्ती त्वरित प्राप्त होते).

अशा प्रकारे, Kubernetes तीन मूलभूत पद्धतींसह (YAML मॅनिफेस्टसाठी) फाइल सर्व्हरचा एक प्रकार म्हणून कार्य करते (होय, प्रत्यक्षात इतरही आहेत, परंतु आम्ही त्यांना आत्ता वगळू).

समस्या अशी आहे की सर्व्हर फक्त माहिती साठवू शकतो. ते कार्य करण्यासाठी आपल्याला आवश्यक आहे नियंत्रक - कुबर्नेट्सच्या जगातील दुसरी सर्वात महत्वाची आणि मूलभूत संकल्पना.

नियंत्रकांचे दोन मुख्य प्रकार आहेत. प्रथम Kubernetes कडून माहिती घेतो, नेस्टेड लॉजिकनुसार त्यावर प्रक्रिया करतो आणि K8s वर परत करतो. दुसरा कुबर्नेट्सकडून माहिती घेतो, परंतु, पहिल्या प्रकाराप्रमाणे, काही बाह्य संसाधनांची स्थिती बदलतो.

कुबर्नेट्समध्ये उपयोजन तयार करण्याच्या प्रक्रियेवर बारकाईने नजर टाकूया:

• उपयोजन नियंत्रक (यात समाविष्ट आहे kube-controller-manager) उपयोजनाविषयी माहिती प्राप्त करते आणि एक प्रतिकृती सेट तयार करते.
• या माहितीच्या आधारे ReplicaSet दोन प्रतिकृती (दोन पॉड्स) तयार करते, परंतु या पॉड्स अद्याप शेड्यूल केलेले नाहीत.
• शेड्युलर पॉड्स शेड्युल करतो आणि त्यांच्या YAML मध्ये नोड माहिती जोडतो.
• कुबेलेट्स बाह्य संसाधनामध्ये बदल करतात (डॉकर म्हणा).

मग हा संपूर्ण क्रम उलट क्रमाने पुनरावृत्ती होतो: कुबेलेट कंटेनर तपासते, पॉडच्या स्थितीची गणना करते आणि ते परत पाठवते. ReplicaSet नियंत्रक स्थिती प्राप्त करतो आणि प्रतिकृती सेटची स्थिती अद्यतनित करतो. डिप्लॉयमेंट कंट्रोलरच्या बाबतीतही असेच घडते आणि वापरकर्त्याला शेवटी अद्यतनित (वर्तमान) स्थिती मिळते.

शेल-ऑपरेटर

असे दिसून आले की कुबर्नेट्स विविध नियंत्रकांच्या संयुक्त कार्यावर आधारित आहेत (कुबर्नेट्स ऑपरेटर देखील नियंत्रक आहेत). प्रश्न उद्भवतो, कमीत कमी प्रयत्नात स्वतःचा ऑपरेटर कसा तयार करायचा? आणि येथे आम्ही विकसित केलेला बचावासाठी येतो शेल-ऑपरेटर. हे सिस्टीम प्रशासकांना परिचित पद्धती वापरून त्यांची स्वतःची विधाने तयार करण्यास अनुमती देते.

साधे उदाहरण: गुपिते कॉपी करणे

एक साधे उदाहरण पाहू.

समजा आमच्याकडे कुबर्नेट्स क्लस्टर आहे. त्यात नेमस्पेस आहे default काही रहस्यांसह mysecret. याव्यतिरिक्त, क्लस्टरमध्ये इतर नेमस्पेस आहेत. त्यांच्यापैकी काहींना विशिष्ट लेबल जोडलेले आहे. लेबलसह नेमस्पेसमध्ये सिक्रेट कॉपी करणे हे आमचे ध्येय आहे.

क्लस्टरमध्ये नवीन नेमस्पेस दिसू शकतात आणि त्यापैकी काहींना हे लेबल असू शकते या वस्तुस्थितीमुळे हे कार्य गुंतागुंतीचे आहे. दुसरीकडे, जेव्हा लेबल हटविले जाते, तेव्हा गुप्त देखील हटविले जावे. या व्यतिरिक्त, गुप्त स्वतः देखील बदलू शकते: या प्रकरणात, नवीन गुप्त लेबलांसह सर्व नेमस्पेसमध्ये कॉपी करणे आवश्यक आहे. कोणत्याही नेमस्पेसमध्ये चुकून सिक्रेट हटवले असल्यास, आमच्या ऑपरेटरने ते त्वरित पुनर्संचयित केले पाहिजे.

आता कार्य तयार केले गेले आहे, शेल-ऑपरेटर वापरून त्याची अंमलबजावणी सुरू करण्याची वेळ आली आहे. परंतु प्रथम शेल-ऑपरेटरबद्दल काही शब्द बोलणे योग्य आहे.

शेल-ऑपरेटर कसे कार्य करते

कुबर्नेट्समधील इतर वर्कलोड्सप्रमाणे, शेल-ऑपरेटर स्वतःच्या पॉडमध्ये चालतो. निर्देशिकेत या पॉडमध्ये /hooks एक्झिक्युटेबल फाइल्स साठवल्या जातात. या बॅश, पायथन, रुबी इत्यादी मधील स्क्रिप्ट असू शकतात. आम्ही अशा एक्झिक्यूटेबल फाइल्सना हुक म्हणतो (हुक).

शेल-ऑपरेटर कुबर्नेट्स इव्हेंट्सची सदस्यता घेतो आणि आम्हाला आवश्यक असलेल्या इव्हेंटच्या प्रतिसादात हे हुक चालवतो.

कोणता हुक आणि कधी चालवावा हे शेल-ऑपरेटरला कसे कळते? मुद्दा असा आहे की प्रत्येक हुकचे दोन टप्पे असतात. स्टार्टअप दरम्यान, शेल-ऑपरेटर तर्काने सर्व हुक चालवतो --config हा कॉन्फिगरेशनचा टप्पा आहे. आणि त्यानंतर, हुक सामान्य मार्गाने लाँच केले जातात - ज्या इव्हेंटशी ते संलग्न आहेत त्यांना प्रतिसाद म्हणून. नंतरच्या प्रकरणात, हुकला बंधनकारक संदर्भ प्राप्त होतो (बंधनकारक संदर्भ) - JSON स्वरूपात डेटा, ज्याबद्दल आम्ही खाली अधिक तपशीलवार बोलू.

बॅश मध्ये ऑपरेटर बनवणे

आता आम्ही अंमलबजावणीसाठी तयार आहोत. हे करण्यासाठी, आम्हाला दोन कार्ये लिहिण्याची आवश्यकता आहे (तसे, आम्ही शिफारस करतो लायब्ररी 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;
    • जर स्थानिक गुपित सापडले नाही तर ते काहीही करत नाही.

बॅशमध्ये अल्गोरिदमची अंमलबजावणी आपण आमच्या मध्ये डाउनलोड करू शकता उदाहरणांसह भांडार.

अशाप्रकारे आम्ही YAML कॉन्फिगरेशनच्या 35 ओळी आणि त्याच प्रमाणात बॅश कोड वापरून एक साधा कुबर्नेट्स कंट्रोलर तयार करू शकलो! शेल-ऑपरेटरचे काम त्यांना एकत्र जोडणे आहे.

तथापि, गुपिते कॉपी करणे हे युटिलिटीच्या अर्जाचे एकमेव क्षेत्र नाही. तो काय सक्षम आहे हे दर्शविण्यासाठी येथे आणखी काही उदाहरणे आहेत.

उदाहरण 1: ConfigMap मध्ये बदल करणे

तीन शेंगा असलेली उपयोजन पाहू. पॉड्स काही कॉन्फिगरेशन संचयित करण्यासाठी ConfigMap वापरतात. जेव्हा पॉड्स लाँच केले गेले तेव्हा कॉन्फिगमॅप एका विशिष्ट स्थितीत होता (याला v.1 म्हणू या). त्यानुसार, सर्व पॉड्स कॉन्फिगमॅपची ही विशिष्ट आवृत्ती वापरतात.

आता ConfigMap बदलला आहे असे गृहीत धरू (v.2). तथापि, पॉड्स ConfigMap (v.1) ची मागील आवृत्ती वापरतील:

मी त्यांना नवीन कॉन्फिगमॅप (v.2) वर स्विच करण्यासाठी कसे मिळवू शकतो? उत्तर सोपे आहे: टेम्पलेट वापरा. विभागामध्ये चेकसम भाष्य जोडूया template उपयोजन कॉन्फिगरेशन:

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

वापरकर्त्याने कॉन्फिगमॅपमध्ये बदल केल्यास, शेल-ऑपरेटर ते लक्षात घेईल आणि चेकसमची पुनर्गणना करेल. ज्यानंतर कुबर्नेट्सची जादू कार्यात येईल: ऑर्केस्ट्रेटर पॉड मारेल, एक नवीन तयार करेल, ते होण्याची प्रतीक्षा करा Ready, आणि पुढील एकाकडे जाते. परिणामी, डिप्लॉयमेंट सिंक्रोनाइझ होईल आणि ConfigMap च्या नवीन आवृत्तीवर स्विच करेल.

उदाहरण 2: सानुकूल संसाधन व्याख्येसह कार्य करणे

तुम्हाला माहिती आहे की, कुबर्नेट्स तुम्हाला सानुकूल प्रकारच्या वस्तू तयार करण्याची परवानगी देतात. उदाहरणार्थ, आपण प्रकार तयार करू शकता MysqlDatabase. समजा या प्रकारात दोन मेटाडेटा पॅरामीटर्स आहेत: name и namespace.

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

आमच्याकडे वेगवेगळ्या नेमस्पेससह कुबर्नेट्स क्लस्टर आहे ज्यामध्ये आम्ही MySQL डेटाबेस तयार करू शकतो. या प्रकरणात शेल-ऑपरेटरचा वापर संसाधनांचा मागोवा घेण्यासाठी केला जाऊ शकतो MysqlDatabase, त्यांना MySQL सर्व्हरशी जोडणे आणि क्लस्टरच्या इच्छित आणि निरीक्षण केलेल्या स्थितींचे समक्रमण करणे.

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

तुम्हाला माहिती आहे की, पिंग वापरणे हा नेटवर्कचे निरीक्षण करण्याचा सर्वात सोपा मार्ग आहे. या उदाहरणात आपण शेल-ऑपरेटर वापरून असे मॉनिटरिंग कसे अंमलात आणायचे ते दाखवू.

सर्व प्रथम, आपल्याला नोड्सची सदस्यता घ्यावी लागेल. शेल ऑपरेटरला प्रत्येक नोडचे नाव आणि 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 वर नवीन अंक/PR/तारे पाहण्यात नेहमीच आनंद होतो, जिथे तुम्ही इतरांना शोधू शकता. मनोरंजक प्रकल्प. त्यापैकी ते हायलाइट करण्यासारखे आहे अॅडऑन-ऑपरेटर, जो शेल-ऑपरेटरचा मोठा भाऊ आहे. ही युटिलिटी अॅड-ऑन स्थापित करण्यासाठी हेल्म चार्ट वापरते, अद्यतने वितरीत करू शकते आणि विविध चार्ट पॅरामीटर्स/व्हॅल्यूजचे निरीक्षण करू शकते, चार्ट्सच्या इन्स्टॉलेशन प्रक्रियेवर नियंत्रण ठेवते आणि क्लस्टरमधील इव्हेंटच्या प्रतिसादात ते सुधारित देखील करू शकते.

व्हिडिओ आणि स्लाइड्स

कामगिरीमधील व्हिडिओ (~२३ मिनिटे):

अहवालाचे सादरीकरण:

PS

आमच्या ब्लॉगवर देखील वाचा:

• «शेल-ऑपरेटरसह कुबरनेट ऑपरेटरची सुलभ निर्मिती: वर्षभरात प्रकल्पाची प्रगती";
• «शेल-ऑपरेटर सादर करत आहे: कुबर्नेट्ससाठी ऑपरेटर तयार करणे आता सोपे झाले आहे";
• «कुबर्नेट्स क्लस्टर तयार करणे सोपे आणि सोयीचे आहे का? अॅडऑन-ऑपरेटरची घोषणा करत आहे";
• «कुबर्नेट्सचा विस्तार आणि पूरक" (पुनरावलोकन आणि व्हिडिओ अहवाल).

स्त्रोत: www.habr.com