وڃ؟ باش! شيل آپريٽر سان ملو (جائزو ۽ وڊيو رپورٽ KubeCon EU'2020 کان)

هن سال، مکيه يورپي Kubernetes ڪانفرنس - KubeCon + CloudNativeCon يورپ 2020 - مجازي هئي. بهرحال، شڪل ۾ اهڙي تبديلي اسان کي اسان جي ڊگهي رٿيل رپورٽ پهچائڻ کان نه روڪيو "وڃو؟ باش! اسان جي اوپن سورس پروجيڪٽ لاءِ وقف ڪيل شيل آپريٽر سان ملو شيل آپريٽر.

هي آرٽيڪل، ڳالهين کان متاثر ٿي، Kubernetes لاءِ آپريٽر ٺاهڻ جي عمل کي آسان ڪرڻ جو هڪ طريقو پيش ڪري ٿو ۽ ڏيکاري ٿو ته توهان شيل آپريٽر استعمال ڪندي گهٽ ۾ گهٽ ڪوشش سان پنهنجو پاڻ ڪيئن ٺاهي سگهو ٿا.

وڃ؟ باش! شيل آپريٽر سان ملو (جائزو ۽ وڊيو رپورٽ KubeCon EU'2020 کان)

تعارف ڪرائڻ رپورٽ جي وڊيو (انگريزي ۾ ~ 23 منٽ، خاص طور تي آرٽيڪل کان وڌيڪ معلوماتي) ۽ ان مان مکيه اقتباس ٽيڪسٽ فارم ۾. وڃ!

فلانٽ تي اسان مسلسل هر شي کي بهتر ۽ خودڪار ڪندا آهيون. اڄ اسان هڪ ٻي دلچسپ تصور بابت ڳالهائينداسين. ملن: ڪلائوڊ-آبائي شيل اسڪرپٽنگ!

بهرحال، اچو ته ان حوالي سان شروع ڪريون جنهن ۾ اهو سڀ ڪجهه ٿئي ٿو: ڪبرنيٽس.

Kubernetes API ۽ ڪنٽرولرز

Kubernetes ۾ API کي هر قسم جي اعتراض لاء ڊائريڪٽرن سان گڏ فائل سرور جي هڪ قسم جي طور تي نمائندگي ڪري سگهجي ٿو. هن سرور تي شيون (وسيلا) YAML فائلن جي نمائندگي ڪري رهيا آهن. ان کان علاوه، سرور وٽ ھڪڙو بنيادي API آھي جيڪو توھان کي ٽن شين کي ڪرڻ جي اجازت ڏئي ٿو:

  • حاصل ڪريو وسيلا ان جي قسم ۽ نالي سان؛
  • تبديل ڪريو وسيلا (هن صورت ۾، سرور صرف "صحيح" شيون محفوظ ڪري ٿو - سڀئي غلط ٺهيل آهن يا ٻين ڊائريڪٽرن لاء ارادو رد ڪيا ويا آهن)؛
  • ٽريڪ وسيلن لاء (هن صورت ۾، صارف کي فوري طور تي ان جي موجوده / تازه ڪاري ورزن حاصل ڪري ٿو).

اهڙيء طرح، ڪبرنيٽس هڪ قسم جي فائل سرور جي طور تي ڪم ڪري ٿو (YAML ظاهر ڪرڻ لاء) ٽن بنيادي طريقن سان (ها، اصل ۾ ٻيا به آهن، پر اسان انهن کي هاڻي لاء ڇڏي ڏينداسين).

وڃ؟ باش! شيل آپريٽر سان ملو (جائزو ۽ وڊيو رپورٽ KubeCon EU'2020 کان)

مسئلو اهو آهي ته سرور صرف معلومات محفوظ ڪري سگهي ٿو. اهو ڪم ڪرڻ لاء توهان کي ضرورت آهي ڪنٽرولر - Kubernetes جي دنيا ۾ ٻيو سڀ کان اهم ۽ بنيادي تصور.

ڪنٽرولرز جا ٻه مکيه قسم آهن. پهريون ڪبرنيٽس کان معلومات وٺي ٿو، ان کي nested منطق جي مطابق پروسيس ڪري ٿو، ۽ ان کي K8s ڏانهن موٽائي ٿو. ٻيو ڪوبرنيٽس کان معلومات وٺي ٿو، پر، پهرين قسم جي برعڪس، ڪجهه خارجي وسيلن جي حالت کي تبديل ڪري ٿو.

اچو ته ڪبرنيٽس ۾ ٺاھڻ جي عمل تي وڌيڪ نظر رکون:

  • تعیناتي ڪنٽرولر (شامل kube-controller-manager) ترتيب ڏيڻ جي باري ۾ معلومات حاصل ڪري ٿي ۽ هڪ ReplicaSet ٺاهي ٿي.
  • ReplicaSet هن معلومات جي بنياد تي ٻه replicas (ٻه پوڊ) ٺاهي ٿو، پر اهي پوڊ اڃا تائين مقرر نه ڪيا ويا آهن.
  • شيڊيولر پوڊ کي شيڊول ڪري ٿو ۽ نوڊ جي معلومات کي پنھنجي YAMLs ۾ شامل ڪري ٿو.
  • Kubelets هڪ خارجي وسيلن ۾ تبديليون آڻيندا آهن (چوندا Docker).

پوءِ هي سڄو سلسلو ورجائي ٿو ورجايو آرڊر: ڪوبلٽ ڪنٽينرز کي چيڪ ڪري ٿو، پوڊ جي حيثيت کي ڳڻائي ٿو ۽ ان کي واپس موڪلي ٿو. ReplicaSet ڪنٽرولر اسٽيٽس حاصل ڪري ٿو ۽ ريپليڪا سيٽ جي حالت کي اپڊيٽ ڪري ٿو. ساڳي شيء ڊيپلومينٽ ڪنٽرولر سان ٿئي ٿي ۽ صارف آخرڪار تازه ڪاري (موجوده) حيثيت حاصل ڪري ٿو.

وڃ؟ باش! شيل آپريٽر سان ملو (جائزو ۽ وڊيو رپورٽ KubeCon EU'2020 کان)

شيل آپريٽر

اهو ظاهر ٿئي ٿو ته Kubernetes مختلف ڪنٽرولرز جي گڏيل ڪم تي ٻڌل آهي (Kubernetes آپريٽرز پڻ ڪنٽرولرز آهن). سوال پيدا ٿئي ٿو، توهان جو پنهنجو آپريٽر ڪيئن ٺاهيو گهٽ ۾ گهٽ ڪوشش سان؟ ۽ هتي جيڪو اسان ترقي ڪيو آهي اهو بچاء لاء اچي ٿو شيل آپريٽر. اهو سسٽم جي منتظمين کي واقف طريقن کي استعمال ڪندي پنهنجن بيانن کي ٺاهڻ جي اجازت ڏئي ٿو.

وڃ؟ باش! شيل آپريٽر سان ملو (جائزو ۽ وڊيو رپورٽ KubeCon EU'2020 کان)

سادي مثال: نقل ڪرڻ راز

اچو ته هڪ سادي مثال تي نظر.

اچو ته چوندا آهيون اسان وٽ ڪبرنيٽس ڪلستر آهي. ان ۾ هڪ نالي جي جاءِ آهي default ڪجهه رازن سان mysecret. ان کان علاوه، ڪلستر ۾ ٻيا نالا آهن. انهن مان ڪجهه انهن سان ڳنڍيل هڪ مخصوص ليبل آهي. اسان جو مقصد هڪ ليبل سان نالي جي جڳهن ۾ راز کي نقل ڪرڻ آهي.

اهو ڪم پيچيده آهي حقيقت اها آهي ته نيون نالا اسپيس ڪلستر ۾ ظاهر ٿي سگهن ٿيون، ۽ انهن مان ڪجهه شايد هي ليبل هجي. ٻئي طرف، جڏهن ليبل ختم ڪيو وڃي، راز کي پڻ ختم ڪيو وڃي. ان کان علاوه، راز پاڻ کي پڻ تبديل ڪري سگهي ٿو: هن صورت ۾، نئين راز کي ليبل سان سڀني نالن جي جڳهن تي نقل ڪيو وڃي. جيڪڏهن راز غلطيءَ سان ڪنهن نالي واري جاءِ ۾ ڊهي وڃي ٿو، اسان جي آپريٽر کي ان کي فوري طور تي بحال ڪرڻ گهرجي.

ھاڻي اھو ڪم ٺاھيو ويو آھي، اھو وقت آھي ان کي لاڳو ڪرڻ شروع ڪرڻ جو شيل آپريٽر استعمال ڪندي. پر پهرين ان کي شيل آپريٽر پاڻ جي باري ۾ چند لفظن چوڻ جي قابل آهي.

شيل آپريٽر ڪيئن ڪم ڪندو آهي

ڪبرنيٽس ۾ ٻين ڪم لوڊ وانگر، شيل آپريٽر پنهنجي پوڊ ۾ هلندو آهي. ڊاريڪٽري ۾ هن پوڊ ۾ /hooks executable فائلون محفوظ آهن. اهي اسڪرپٽ ٿي سگهن ٿيون Bash، Python، Ruby، وغيره ۾. اسان اهڙين ايگزيڪيوٽيبل فائلن کي ٿلهو چئون ٿا (ٿلهو).

وڃ؟ باش! شيل آپريٽر سان ملو (جائزو ۽ وڊيو رپورٽ KubeCon EU'2020 کان)

شيل آپريٽر سبسڪرائب ڪري ٿو Kubernetes واقعن ۽ انهن ٿڪن کي هلائي ٿو انهن واقعن جي جواب ۾ جيڪي اسان کي گهربل آهن.

وڃ؟ باش! شيل آپريٽر سان ملو (جائزو ۽ وڊيو رپورٽ KubeCon EU'2020 کان)

شيل آپريٽر کي ڪيئن خبر پوي ٿي ته ڪهڙو ٿلهو هلائڻو آهي ۽ ڪڏهن؟ نقطي اهو آهي ته هر ٿلهو ٻه مرحلا آهن. شروعاتي دوران، شيل آپريٽر سڀني ٿلهن کي هڪ دليل سان هلائي ٿو --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:

وڃ؟ باش! شيل آپريٽر سان ملو (جائزو ۽ وڊيو رپورٽ KubeCon EU'2020 کان)

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) ۽ ھيٺ ڏنل پابند حوالا حاصل ڪريو:

وڃ؟ باش! شيل آپريٽر سان ملو (جائزو ۽ وڊيو رپورٽ KubeCon EU'2020 کان)

جئين توهان ڏسي سگهو ٿا، اهو نالو ۽ سڄو اعتراض تي مشتمل آهي.

نالي جي جاءِ تي نظر رکڻ

ھاڻي توھان کي رڪنيت حاصل ڪرڻ جي ضرورت آھي نالا اسپيس. هن کي ڪرڻ لاء، اسان هيٺ ڏنل پابند ٺاھ جوڙ بيان ڪريون ٿا:

- 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 اعتراض ٺاھي ٿو انھن شعبن سان جيڪي اسان جي دلچسپيءَ وارا آھن. هڪ جهڙي ترتيب سان هڪ ٿلهو هيٺ ڏنل پابند حوالو حاصل ڪندو:

وڃ؟ باش! شيل آپريٽر سان ملو (جائزو ۽ وڊيو رپورٽ KubeCon EU'2020 کان)

اهو هڪ صف تي مشتمل آهي filterResults ڪلستر ۾ هر نالي جي جڳهه لاءِ. Boolean variable 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. آخري پيٽرولر تشريح ڏانهن منظور ڪيو ويو جڏهن راز ٺاهيندي: اهو توهان کي رازن جي نسخن جي مقابلي ڪرڻ ۽ انهن کي تاريخ تائين رکڻ جي اجازت ڏئي ٿو.

هڪ ٿلهو هن طريقي سان ترتيب ڏنو ويندو، جڏهن عمل ڪيو ويندو، مٿي بيان ڪيل ٽن پابند مقصدن حاصل ڪندو. انهن کي هڪ قسم جي سنيپ شاٽ طور سمجهي سگهجي ٿو (اسپيڊ شاٽ) ڪلستر.

وڃ؟ باش! شيل آپريٽر سان ملو (جائزو ۽ وڊيو رپورٽ KubeCon EU'2020 کان)

انهن سڀني معلومات جي بنياد تي، هڪ بنيادي الگورتھم ٺاهي سگهجي ٿو. اهو سڀني نالي جي جڳهن تي ورجائي ٿو ۽:

  • جيڪڏهن hasLabel ڪم true موجوده نالي جي جڳھ لاءِ:
    • عالمي راز کي مقامي راز سان ڀيٽي ٿو:
      • جيڪڏھن اھي ساڳيا آھن، اھو ڪجھ به نه ڪندو آھي.
      • جيڪڏهن اهي مختلف آهن - عملدرآمد kubectl replace يا create;
  • جيڪڏهن hasLabel ڪم false موجوده نالي جي جڳھ لاءِ:
    • پڪ ڪري ٿو ته راز ڏنل نالي جي جڳهه ۾ نه آهي:
      • جيڪڏهن مقامي راز موجود آهي، ان کي استعمال ڪندي حذف ڪريو kubectl delete;
      • جيڪڏهن مقامي راز معلوم نه ڪيو ويو آهي، اهو ڪجهه به ناهي.

وڃ؟ باش! شيل آپريٽر سان ملو (جائزو ۽ وڊيو رپورٽ KubeCon EU'2020 کان)

بش ۾ الگورتھم جو نفاذ توھان ڊائون لوڊ ڪري سگھو ٿا اسان جي مثالن سان گڏ ذخيرو.

اهڙيءَ طرح اسان YAML ترتيب جي 35 لائينن ۽ بش ڪوڊ جي ساڳي رقم استعمال ڪندي هڪ سادي ڪبرنيٽس ڪنٽرولر ٺاهي سگهندا هئاسين! شيل آپريٽر جو ڪم انهن کي ڳنڍڻ آهي.

بهرحال، رازن کي نقل ڪرڻ صرف استعمال جي ايپليڪيشن جو علائقو ناهي. هتي ڪجهه وڌيڪ مثال آهن ته هو ڏيکارين ته هو ڪهڙي قابل آهي.

مثال 1: ConfigMap ۾ تبديليون ڪرڻ

اچو ته هڪ ڊيپلائيمينٽ تي نظر رکون جنهن ۾ ٽي پوڊ شامل آهن. پوڊس ڪنفيگريشن کي ذخيرو ڪرڻ لاءِ ConfigMap استعمال ڪندا آهن. جڏهن پوڊ شروع ڪيا ويا، ConfigMap هڪ خاص حالت ۾ هو (اچو ته ان کي سڏين ٿا v.1). ان جي مطابق، سڀئي پوڊ استعمال ڪن ٿا ConfigMap جو خاص نسخو.

هاڻي اچو ته فرض ڪريون ته ConfigMap تبديل ٿي ويو آهي (v.2). بهرحال، پوڊس استعمال ڪندا ConfigMap جو اڳوڻو نسخو (v.1):

وڃ؟ باش! شيل آپريٽر سان ملو (جائزو ۽ وڊيو رپورٽ KubeCon EU'2020 کان)

مان ڪيئن حاصل ڪري سگهان ٿو انهن کي نئين ConfigMap (v.2) ۾ تبديل ڪرڻ لاءِ؟ جواب سادو آهي: هڪ ٽيمپليٽ استعمال ڪريو. اچو ته سيڪشن ۾ چيڪسم تشريح شامل ڪريون template لڳائڻ جي جوڙجڪ:

وڃ؟ باش! شيل آپريٽر سان ملو (جائزو ۽ وڊيو رپورٽ KubeCon EU'2020 کان)

نتيجي طور، هي چيڪسم سڀني پوڊز ۾ رجسٽرڊ ڪيو ويندو، ۽ اهو ساڳيو ئي هوندو جيڪو ڊيپلائيشن جي. هاڻي توهان کي صرف تشريح کي اپڊيٽ ڪرڻ جي ضرورت آهي جڏهن ConfigMap تبديل ٿي. ۽ شيل آپريٽر هن معاملي ۾ هٿ ۾ اچي ٿو. توهان سڀني کي ڪرڻو آهي پروگرام هڪ ٿلهو جيڪو ConfigMap جي رڪنيت حاصل ڪندو ۽ چيڪسم کي اپڊيٽ ڪندو.

جيڪڏهن صارف ConfigMap ۾ تبديليون آڻيندو، شيل آپريٽر انهن کي نوٽيس ڪندو ۽ چيڪسم کي ٻيهر ڳڻپ ڪندو. جنهن کان پوءِ ڪبرنيٽس جو جادو اچي ويندو: آرڪيسٽرٽر پوڊ کي ماريندو، هڪ نئون ٺاهيندو، ان جي ٿيڻ جو انتظار ڪريو. Ready، ۽ اڳتي هلي اڳتي هلي. نتيجي طور، ڊيپلومينٽ هم وقت سازي ٿيندي ۽ ConfigMap جي نئين ورزن ۾ تبديل ٿيندي.

وڃ؟ باش! شيل آپريٽر سان ملو (جائزو ۽ وڊيو رپورٽ KubeCon EU'2020 کان)

مثال 2: حسب ضرورت وسيلن جي تعريف سان ڪم ڪرڻ

جئين توهان ڄاڻو ٿا، ڪبرنيٽس توهان کي اجازت ڏئي ٿو ته ڪسٽم قسم جا شيون ٺاهي. مثال طور، توهان قسم ٺاهي سگهو ٿا MysqlDatabase. اچو ته چوندا آهن ته هن قسم جا ٻه ميٽا ڊيٽا پيٽرولر آهن: name и namespace.

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

اسان وٽ هڪ ڪبرنيٽس ڪلستر آهي مختلف نالن جي جڳهن سان جنهن ۾ اسان MySQL ڊيٽابيس ٺاهي سگهون ٿا. هن معاملي ۾ شيل-آپريٽر وسيلن کي ٽريڪ ڪرڻ لاء استعمال ڪري سگهجي ٿو MysqlDatabase، انهن کي MySQL سرور سان ڳنڍيندي ۽ ڪلستر جي گهربل ۽ مشاهدو رياستن کي هم وقت سازي ڪندي.

وڃ؟ باش! شيل آپريٽر سان ملو (جائزو ۽ وڊيو رپورٽ KubeCon EU'2020 کان)

مثال 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.

هن وانگر توهان ڪلستر ۾ سادي نيٽ ورڪ جي نگراني لاءِ آپريٽر ٺاهي سگهو ٿا.

قطار لڳائڻ وارو ميڪانيزم

هي آرٽيڪل شيل آپريٽر ۾ ٺهيل هڪ ٻيو اهم ميکانيزم بيان ڪرڻ کان سواءِ نامڪمل هوندو. تصور ڪريو ته اهو ڪلستر ۾ واقعن جي جواب ۾ ڪجهه قسم جي ٿلهو تي عمل ڪري ٿو.

  • ڇا ٿيندو، ساڳئي وقت، ڪلستر ۾ ڪجهه ٿئي ٿو؟ هڪ وڌيڪ واقعو؟
  • ڇا شيل آپريٽر ٿلهو جو ٻيو مثال هلائيندو؟
  • ڇا جيڪڏهن، چئو، پنج واقعا هڪ ئي وقت ڪلستر ۾ ٿين ٿا؟
  • ڇا شيل آپريٽر انهن کي متوازي ۾ پروسيس ڪندو؟
  • استعمال ٿيل وسيلن جهڙوڪ ميموري ۽ سي پي يو بابت ڇا؟

خوشقسمتيء سان، شيل-آپريٽر هڪ تعمير ٿيل قطار ميڪانيزم آهي. سڀئي واقعا قطار ۾ رکيا ويا آهن ۽ ترتيب سان ترتيب ڏنل آهن.

اچو ته ان کي مثالن سان بيان ڪريون. اچو ته اسان وٽ ٻه ٿلها آهن. پهرئين واقعو پهرئين هيڪ ڏانهن وڃي ٿو. هڪ دفعو ان جي پروسيسنگ مڪمل ٿي ويندي آهي، قطار اڳتي وڌندي آهي. ايندڙ ٽن واقعن کي ٻئي ٿلهو ڏانهن منتقل ڪيو ويو آهي - اهي قطار مان هٽائي ويا آهن ۽ ان ۾ "بنڊل" ۾ داخل ڪيا ويا آهن. اهو آهي hook واقعن جو هڪ سلسلو حاصل ڪري ٿو - يا، وڌيڪ واضح طور تي، پابند ڪنٽينس جو هڪ صف.

پڻ اهي واقعن کي ھڪڙي وڏي ۾ گڏ ڪري سگھجي ٿو. پيرا ميٽر هن لاء ذميوار آهي group پابند جي جوڙجڪ ۾.

وڃ؟ باش! شيل آپريٽر سان ملو (جائزو ۽ وڊيو رپورٽ KubeCon EU'2020 کان)

توهان ڪي به نمبر ٺاهي سگهو ٿا قطار/هڪس ۽ انهن جا مختلف مجموعا. مثال طور، هڪ قطار ٻن ٿلهن سان ڪم ڪري سگهي ٿي، يا ان جي برعڪس.

وڃ؟ باش! شيل آپريٽر سان ملو (جائزو ۽ وڊيو رپورٽ KubeCon EU'2020 کان)

توھان سڀني کي ڪرڻ جي ضرورت آھي فيلڊ کي ترتيب ڏيو مطابق queue پابند جي جوڙجڪ ۾. جيڪڏهن قطار جو نالو بيان نه ڪيو ويو آهي، ٿلهو ڊفالٽ قطار تي هلندو آهي (default). هي قطار واري ميڪانيزم توهان کي مڪمل طور تي سڀني وسيلن جي انتظام جي مسئلن کي حل ڪرڻ جي اجازت ڏئي ٿي جڏهن ٿلهو سان ڪم ڪندي.

ٿڪل

اسان وضاحت ڪئي ته شيل آپريٽر ڇا آهي، ڏيکاريو ته اهو ڪيئن استعمال ڪري سگهجي ٿو تڪڙو ۽ آسانيءَ سان ڪبرنيٽس آپريٽر ٺاهڻ، ۽ ان جي استعمال جا ڪيترائي مثال ڏنائون.

شيل آپريٽر جي باري ۾ تفصيلي ڄاڻ، انهي سان گڏ ان کي ڪيئن استعمال ڪرڻ تي هڪ تڪڙو سبق، لاڳاپيل ۾ موجود آهي GitHub تي ذخيرو. سوالن سان اسان سان رابطو ڪرڻ ۾ سنکوڪ نه ڪريو: توھان انھن تي خاص بحث ڪري سگھو ٿا ٽيليگرام گروپ (روسي ۾) يا ۾ هي فورم (انگريزي ۾).

۽ جيڪڏھن توھان ان کي پسند ڪيو، اسان ھميشه خوش آھيون گيٽ ھب تي نوان مسئلا/پي آر/ستارون، جتي توھان ٻين کي ڳولي سگھوٿا دلچسپ منصوبا. انهن مان ان کي نمايان ڪرڻ جي قابل آهي اضافو آپريٽر، جيڪو شيل آپريٽر جو وڏو ڀاءُ آهي. هي يوٽيليٽي هيلم چارٽس استعمال ڪري ٿي ايڊ-آنس کي انسٽال ڪرڻ لاءِ، اپڊيٽ ڊيليور ڪري سگهي ٿي ۽ مختلف چارٽ پيرا ميٽرز/ويلوز مانيٽر ڪري ٿي، چارٽ جي انسٽاليشن جي عمل کي ڪنٽرول ڪري ٿي، ۽ ڪلسٽر ۾ واقعن جي جواب ۾ انهن کي به تبديل ڪري سگهي ٿي.

وڃ؟ باش! شيل آپريٽر سان ملو (جائزو ۽ وڊيو رپورٽ KubeCon EU'2020 کان)

وڊيوز ۽ سلائڊ

ڪارڪردگي کان وڊيو (~ 23 منٽ):


رپورٽ جي پيشڪش:

پي ايس

اسان جي بلاگ تي پڻ پڙهو:

جو ذريعو: www.habr.com

تبصرو شامل ڪريو