لاړ شه؟ باش! د شیل آپریټر سره لیدنه وکړئ (د KubeCon EU'2020 څخه بیاکتنه او ویډیو راپور)

سږکال، د اروپا د Kubernetes اصلي کنفرانس - KubeCon + CloudNativeCon اروپا 2020 - مجازی و. په هرصورت، په بڼه کې دا ډول بدلون زموږ د اوږد پلان شوي راپور وړاندې کولو مخه نه نیسي "لاړ؟ باش! زموږ د خلاصې سرچینې پروژې ته وقف شوي د شیل آپریټر سره لیدنه وکړئ شیل چلونکی.

دا مقاله، د خبرو څخه الهام اخیستې، د کوبرنیټس لپاره د آپریټرونو رامینځته کولو پروسې ساده کولو لپاره یوه تګلاره وړاندې کوي او ښیې چې تاسو څنګه کولی شئ د شیل آپریټر په کارولو سره لږترلږه هڅې سره خپل ځان جوړ کړئ.

معرفي کول د راپور ویډیو (په انګلیسي کې ~ 23 دقیقې، د مقالې په پرتله د پام وړ ډیر معلوماتي) او د متن په بڼه یې اصلي استخراج. لاړ شه!

په فلانټ کې موږ په دوامداره توګه هرڅه غوره او اتومات کوو. نن موږ به د یو بل په زړه پورې مفهوم په اړه خبرې وکړو. ملاقات: د بادل اصلي شیل سکریپټینګ!

په هرصورت، راځئ چې د هغه شرایطو سره پیل وکړو په کوم کې چې دا ټول پیښیږي: Kubernetes.

Kubernetes API и контроллеры

په کبرنیټس کې API د هر ډول څیز لپاره لارښودونو سره د فایل سرور ډول ډول نمایش کیدی شي. په دې سرور کې توکي (سرچینې) د YAML فایلونو لخوا نمایش کیږي. سربیره پردې، سرور یو بنسټیز API لري چې تاسو ته اجازه درکوي درې شیان ترسره کړئ:

• ترلاسه کول سرچینه د خپل ډول او نوم له مخې؛
• بدلول سرچینې (په دې حالت کې، سرور یوازې "سم" توکي ذخیره کوي - ټول په غلط ډول جوړ شوي یا د نورو لارښودونو لپاره ټاکل شوي رد شوي)؛
• تعقیب د سرچینې لپاره (په دې حالت کې، کاروونکي سمدلاسه خپل اوسنی / تازه شوی نسخه ترلاسه کوي).

په دې توګه، Kubernetes د یو ډول فایل سرور په توګه کار کوي (د YAML ښکاره کولو لپاره) د دریو بنسټیزو میتودونو سره (هو، په حقیقت کې نور هم شتون لري، مګر موږ به یې د اوس لپاره پریږدو).

ستونزه دا ده چې سرور یوازې معلومات ذخیره کولی شي. د دې کار کولو لپاره تاسو اړتیا لرئ کنټرولر - د Kubernetes په نړۍ کې دوهم خورا مهم او بنسټیز مفهوم.

د کنټرولر دوه اصلي ډولونه شتون لري. لومړی د Kubernetes څخه معلومات اخلي، دا د nested منطق سره سم پروسس کوي، او K8s ته یې بیرته راولي. دوهم د Kubernetes څخه معلومات اخلي، مګر، د لومړي ډول برعکس، د ځینو بهرنیو سرچینو حالت بدلوي.

راځئ چې په Kubernetes کې د ځای پرځای کولو پروسې ته نږدې کتنه وکړو:

• د ګمارنې کنټرولر (په کې شامل دي kube-controller-manager) د ځای پرځای کولو په اړه معلومات ترلاسه کوي او یو ریپلیکا سیټ رامینځته کوي.
• ReplicaSet د دې معلوماتو پراساس دوه عکسونه (دوه پوډونه) رامینځته کوي ، مګر دا پوډونه لاهم ټاکل شوي ندي.
• مهالویش کونکی پوډونه مهالویش کوي او د دوی YAMLs ته د نوډ معلومات اضافه کوي.
• کوبیلیټ په بهرنۍ سرچینې کې بدلونونه رامینځته کوي (وایی ډاکر).

بیا دا ټول ترتیب په برعکس ترتیب کې تکرار کیږي: کوبیلټ کانټینرونه ګوري، د پوډ حالت محاسبه کوي او بیرته یې لیږي. د ریپلیکا سیټ کنټرولر وضعیت ترلاسه کوي او د نقل سیټ حالت تازه کوي. ورته شی د ځای پرځای کولو کنټرولر سره پیښیږي او کارونکي په پای کې تازه (اوسني) حالت ترلاسه کوي.

شیل چلونکی

دا معلومه شوه چې Kubernetes د مختلفو کنټرولرانو د ګډ کار پر بنسټ والړ دی (Kubernetes چلونکي هم کنټرولر دي). پوښتنه راپورته کیږي، څنګه د لږې هڅې سره خپل آپریټر جوړ کړئ؟ او دلته هغه څوک چې موږ وده کړې د ژغورنې لپاره راځي شیل چلونکی. دا د سیسټم مدیرانو ته اجازه ورکوي چې د پیژندل شوي میتودونو په کارولو سره خپل بیانات رامینځته کړي.

Простой пример: копирование секретов

راځئ چې یو ساده مثال وګورو.

راځئ چې ووایو موږ د کبرنیټس کلستر لرو. دا د نوم ځای لري default د یو څه راز سره mysecret. سربیره پردې، په کلستر کې نور نوم ځایونه شتون لري. ځینې ​​​​یې یو ځانګړی لیبل لري چې دوی سره وصل دي. زموږ هدف د لیبل سره د نوم ځایونو کې راز کاپي کول دي.

دنده د دې حقیقت له مخې پیچلې ده چې ممکن په کلستر کې نوي نوم ځایونه څرګند شي ، او ځینې یې ممکن دا لیبل ولري. له بلې خوا، کله چې لیبل حذف شي، راز هم باید حذف شي. سربیره پردې ، راز پخپله هم بدلیدلی شي: پدې حالت کې ، نوی راز باید د لیبلونو سره ټولو نوم ځایونو ته کاپي شي. که راز په تصادفي ډول په کوم نوم ځای کې حذف شوی وي ، زموږ آپریټر باید سمدلاسه بیرته بحال کړي.

اوس چې دا دنده جوړه شوې، دا وخت دی چې د شیل آپریټر په کارولو سره یې پلي کول پیل کړئ. مګر لومړی دا د شیل آپریټر په اړه یو څو کلمې ویلو ارزښت لري.

د شیل آپریټر څنګه کار کوي

په Kubernetes کې د نورو کاري بارونو په څیر، شیل آپریټر په خپل پوډ کې چلوي. په ډایرکټر کې په دې پوډ کې /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 کاروي. کله چې پوډونه پیل شول، ConfigMap په یو ټاکلي حالت کې و (راځئ چې دا v.1 ووایو). په دې اساس، ټول پوډونه د ConfigMap دا ځانګړې نسخه کاروي.

اوس راځئ چې فرض کړو چې ConfigMap بدل شوی (v.2). په هرصورت، پوډونه به د ConfigMap پخوانی نسخه وکاروي (v.1):

زه څنګه کولی شم چې دوی نوي ConfigMap (v.2) ته واړوم؟ ځواب ساده دی: یو ټیمپلیټ وکاروئ. راځئ چې برخې ته د چکسم تشریح اضافه کړو template د ځای پرځای کولو تشکیلات:

د پایلې په توګه، دا چکسم به په ټولو پوډونو کې ثبت شي، او دا به د ځای پرځای کولو په څیر وي. اوس تاسو اړتیا لرئ چې تشریح تازه کړئ کله چې ConfigMap بدلون ومومي. او د شیل آپریټر پدې قضیه کې په کار راځي. ټول هغه څه چې تاسو یې کولو ته اړتیا لرئ برنامه ده یو هک چې د ConfigMap کې ګډون وکړي او چیکسم تازه کړي.

که چیرې کاروونکي په ConfigMap کې بدلون راولي، د شیل آپریټر به دوی ته پام وکړي او د چکسم بیا حساب کړي. له هغه وروسته چې د کوبرنیټس جادو به په لاره واچول شي: آرکیسټرټر به پوډ ووژني ، یو نوی رامینځته کړي ، د هغې کیدو لپاره انتظار وکړئ Ready، او بل ته حرکت کوي. د پایلې په توګه، ګمارل به همغږي شي او د ConfigMap نوې نسخه ته لاړ شي.

2 بېلګه: د ګمرکي سرچینو تعریفونو سره کار کول

لکه څنګه چې تاسو پوهیږئ، Kubernetes تاسو ته اجازه درکوي د شیانو دودیز ډولونه جوړ کړئ. د مثال په توګه، تاسو کولی شئ ډول جوړ کړئ MysqlDatabase. راځئ چې ووایو دا ډول دوه میټاډاټا پیرامیټونه لري: name и namespace.

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

موږ د مختلف نوم ځایونو سره د Kubernetes کلستر لرو په کوم کې چې موږ کولی شو د 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). دا قطار کولو میکانیزم تاسو ته اجازه درکوي په بشپړ ډول د سرچینو مدیریت ټولې ستونزې حل کړئ کله چې د هکس سره کار کوئ.

پایلې

موږ تشریح کړه چې د شیل آپریټر څه شی دی، وښودله چې دا څنګه په چټکه او اسانۍ سره د Kubernetes آپریټرونو رامینځته کولو لپاره کارول کیدی شي، او د دې کارولو ډیری مثالونه یې وړاندې کړل.

د شیل آپریټر په اړه مفصل معلومات ، او همدارنګه د دې کارولو څرنګوالي په اړه ګړندي ښوونه ، په اړوند کې شتون لري په GitHub کې ذخیره. د پوښتنو سره له موږ سره اړیکه ونیسئ: تاسو کولی شئ په ځانګړي ډول د دوی په اړه بحث وکړئ د ټیلیګرام ګروپ (په روسیه کې) یا په دا فورم (په انګلیسی کي).

او که تاسو دا خوښ کړی وي، موږ تل خوشحاله یو چې په GitHub کې نوي مسلې/PR/ستارونه وګورو، چیرته چې تاسو کولی شئ نور ومومئ په زړه پورې پروژې. د دوی په منځ کې دا د پام وړ ارزښت لري addon-operator، کوم چې د شیل آپریټر لوی ورور دی. دا افادیت د اډونونو نصبولو لپاره د هیلم چارټونه کاروي، کولی شي تازه معلومات وړاندې کړي او مختلف چارټ پیرامیټونه / ارزښتونه وڅاري، د چارټونو نصبولو پروسه کنټرولوي، او کولی شي په کلستر کې د پیښو په ځواب کې دوی تعدیل کړي.

ویډیوګانې او سلایډونه

د فعالیت څخه ویډیو (~ 23 دقیقې):

د راپور وړاندې کول:

PS

زموږ په بلاګ کې هم ولولئ:

• «د شیل آپریټر سره د کوبرنیټس آپریټرانو اسانه رامینځته کول: د کال په اوږدو کې د پروژې پرمختګ»
• «د شیل آپریټر معرفي کول: د کوبرنیټس لپاره آپریټرونه رامینځته کول خورا اسانه شوي»
• «ایا د Kubernetes کلستر چمتو کول اسانه او اسانه دي؟ د اډون آپریټر اعلان کول»
• «د Kubernetes پراخول او بشپړول" (بیاکتنه او ویډیو راپور).

سرچینه: www.habr.com