ڪبرنيٽس کي وڌائڻ ۽ مڪمل ڪرڻ (جائزو ۽ وڊيو رپورٽ)

8 اپريل ڪانفرنس ۾ سينٽ هاءِ لوڊ ++ 2019"DevOps ۽ آپريشنز" سيڪشن جي حصي جي طور تي، هڪ رپورٽ ڏني وئي هئي "وڌائڻ ۽ مڪمل ڪرڻ ڪبرنيٽس"، جنهن جي ٺهڻ ۾ فلانٽ ڪمپني جي ٽن ملازمن شرڪت ڪئي. ان ۾، اسان ڪيترن ئي حالتن جي باري ۾ ڳالهايون ٿا جن ۾ اسان ڪبرنيٽس جي صلاحيتن کي وڌائڻ ۽ مڪمل ڪرڻ چاهيون ٿا، پر جن لاء اسان کي تيار ڪيل ۽ سادي حل نه مليو. اسان وٽ اوپن سورس پروجيڪٽ جي صورت ۾ ضروري حل آهن، ۽ هي تقرير پڻ انهن لاءِ وقف آهي.

روايت موجب، اسان پيش ڪرڻ تي راضي آهيون رپورٽ جي وڊيو (50 منٽ، مضمون کان گهڻو وڌيڪ معلوماتي) ۽ بنيادي خلاصو ٽيڪسٽ فارم ۾. وڃ!

K8s ۾ ڪور ۽ اضافو

ڪبرنيٽس انڊسٽري کي تبديل ڪري رهيو آهي ۽ انتظاميه ڏانهن طريقا جيڪي ڊگهي قائم ڪيا ويا آهن:

• هن جي مهرباني خلاصيون، اسان هاڻي تصورن سان نه هلون ٿا جهڙوڪ هڪ ترتيب ترتيب ڏيڻ يا ڪمانڊ هلائڻ (شيف، جوابي...)، پر ڪنٽينرز، خدمتن وغيره جي گروپنگ کي استعمال ڪريو.
• اسان ايپليڪيشنن کي تيار ڪري سگھون ٿا بغير سوچڻ جي مخصوص سائيٽ، جنهن تي ان کي لانچ ڪيو ويندو: ننگي ڌاتو، فراهم ڪندڙن مان هڪ جو ڪڪر، وغيره.
• K8s سان توهان ڪڏهن به وڌيڪ رسائي نه ڪيو آهي بهترين مشقون انفراسٹرڪچر کي منظم ڪرڻ تي: اسڪيلنگ ٽيڪنڪ، خود شفا، غلطي رواداري، وغيره.

بهرحال، يقينا، هر شيء بلڪل آسان ناهي: ڪبرنيٽس پڻ پنهنجون نوان چئلينج کڻي آيا.

ڪوبنيٿس نه هڪ گڏيل آهي جيڪو سڀني صارفين جي سڀني مسئلن کي حل ڪري ٿو. نيوڪلي ڪبرنيٽس صرف ان ۾ موجود گهٽ ۾ گهٽ ضروري ڪمن جي هڪ سيٽ لاءِ ذميوار آهي هر ڪلستر:

ڪبرنيٽس ڪور ڪنٽينرز کي گروپ ڪرڻ، ٽريفڪ کي منظم ڪرڻ، وغيره لاءِ پرائمري جو بنيادي سيٽ بيان ڪري ٿو. اسان ان بابت وڌيڪ تفصيل سان ڳالهايو رپورٽ 2 سال اڳ.

ٻئي طرف، K8s پيش ڪري ٿو بهترين موقعا موجود ڪمن کي وڌائڻ لاءِ، جيڪي ٻين کي بند ڪرڻ ۾ مدد ڪن ٿا. مخصوص - استعمال ڪندڙ جي ضرورت. Kubernetes ۾ اضافو ڪلسٽر منتظمين جي ذميواري آهي، جن کي لازمي طور تي هر شي کي انسٽال ڪرڻ ۽ ترتيب ڏيڻ گهرجي ته جيئن انهن جي ڪلستر کي "صحيح شڪل ۾" حاصل ڪرڻ لاءِ [پنهنجي مخصوص مسئلن کي حل ڪرڻ لاءِ]. اهي ڪهڙي قسم جا اضافو آهن؟ اچو ته ڪجهه مثالن تي نظر رکون.

اضافو جا مثال

Kubernetes کي نصب ڪرڻ سان، اسان کي حيرت ٿي سگھي ٿي ته نيٽ ورڪنگ جيڪا نوڊ جي اندر ۽ نوڊس جي وچ ۾ پوڊ جي رابطي لاء تمام ضروري آهي، اهو پنهنجو پاڻ تي ڪم نٿو ڪري. Kubernetes ڪنيال ضروري ڪنيڪشن جي ضمانت نٿو ڏئي؛ ان جي بدران، اهو نيٽ ورڪ کي طئي ڪري ٿو انفارميشن (سي اين آء) ٽئين پارٽي اضافو لاءِ. اسان کي انهن مان هڪ اضافو انسٽال ڪرڻ گهرجي، جيڪو نيٽ ورڪ جي ترتيب لاءِ ذميوار هوندو.

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

ٻيا مثال شامل آهن:

• اندر اچڻ- ڪنٽرولرز (ڏسو انهن جو جائزو اسان جو تازو مضمون).
• سرٽيفڪيشن مئنيجر:

  

• آپريٽرز add-ons جو هڪ مڪمل ڪلاس آهي (جنهن ۾ ذڪر ڪيل سرٽيفڪيشن مئنيجر شامل آهي)، اهي تعريف ڪن ٿا primitive(s) ۽ ڪنٽرولر(s). انهن جي ڪم جو منطق صرف اسان جي تخيل تائين محدود آهي ۽ اسان کي اجازت ڏئي ٿو ته تيار ڪيل بنيادي ڍانچي جي اجزاء (مثال طور، هڪ ڊي بي ايم ايس) کي بنياديات ۾، جنهن سان ڪم ڪرڻ تمام آسان آهي (ڪنٽينرز جي سيٽ ۽ انهن جي سيٽنگن جي ڀيٽ ۾). آپريٽرز جو هڪ وڏو تعداد لکيو ويو آهي - جيتوڻيڪ انهن مان ڪيترائي اڃا تائين پيداوار لاء تيار نه آهن، اهو صرف وقت جو معاملو آهي:

  

• ميٽرڪس - هڪ ٻيو مثال ته ڪبرنيٽس انٽرفيس کي ڪيئن الڳ ڪيو (ميٽرڪس API) عمل درآمد کان (ٽي پارٽي ايڊ-آنز جهڙوڪ پروميٿيوس اڊاپٽر، ڊيٽاڊاگ ڪلستر ايجنٽ...).
• لاء نگراني ۽ شماريات، جتي عملي طور تي نه رڳو ضرورت آهي Prometheus ۽ Grafana, but also kube-state-metrics, node-exporter, etc.

۽ هي اضافون جي مڪمل فهرست ناهي... مثال طور، فلانٽ ڪمپني ۾ اسان في الحال انسٽال ڪريون ٿا 29 اضافو (جيڪي سڀ ڪل 249 ڪبرنيٽس شيون ٺاهيندا آهن). آسان لفظ ۾، اسان بغير ڪنهن اضافن جي ڪلستر جي زندگي نه ڏسي سگهون ٿا.

خودڪار

آپريٽرز ٺهيل آهن معمول جي عملن کي خودڪار ڪرڻ لاءِ جيڪي اسان کي هر روز ملن ٿا. هتي حقيقي زندگي جا مثال آهن جن لاءِ هڪ آپريٽر لکڻ هڪ بهترين حل هوندو:

1. ايپليڪيشن لاءِ تصويرن سان گڏ هڪ خانگي (يعني لاگ ان گهربل) رجسٽري آهي. اهو فرض ڪيو ويو آهي ته هر پوڊ کي هڪ خاص راز لڳايو ويو آهي جيڪو رجسٽري ۾ تصديق جي اجازت ڏئي ٿو. اسان جو ڪم اهو آهي ته پڪ ڪرڻ لاءِ ته هي راز نالي جي جاءِ ۾ مليو وڃي ته جيئن پوڊ تصويرون ڊائون لوڊ ڪري سگهن. اتي ڪيتريون ئي ايپليڪيشنون ٿي سگهن ٿيون (جن مان هر هڪ راز جي ضرورت آهي)، ۽ اهو راز کي باقاعدي طور تي تازه ڪاري ڪرڻ لاء ڪارائتو آهي، تنهنڪري هٿ سان راز رکڻ جو اختيار ختم ٿي ويو آهي. هي اهو آهي جتي آپريٽر بچاء ۾ اچي ٿو: اسان هڪ ڪنٽرولر ٺاهيندا آهيون جيڪو انتظار ڪندو نالو اسپيس جي ظاهر ٿيڻ لاء ۽، هن واقعي جي بنياد تي، نالي جي جاء تي هڪ راز شامل ڪندو.
2. پوڊ کان انٽرنيٽ تائين ڊفالٽ رسائي منع ٿيل آهي. پر ڪڏهن ڪڏهن اهو گهربل ٿي سگهي ٿو: اهو منطقي آهي رسائي جي اجازت واري ميکانيزم لاءِ ڪم ڪرڻ لاءِ، خاص صلاحيتن جي ضرورت کان سواءِ، مثال طور، نالي جي جاءِ ۾ هڪ مخصوص ليبل جي موجودگيءَ سان. آپريٽر اسان کي هتي ڪيئن مدد ڪري سگهي ٿو؟ ھڪڙو ڪنٽرولر ٺاھيو ويو آھي جيڪو انتظار ڪري ٿو ليبل جي نالي جي جڳھ ۾ ظاهر ٿيڻ ۽ انٽرنيٽ جي رسائي لاءِ مناسب پاليسي شامل ڪري ٿو.
3. ساڳي صورتحال: فرض ڪريو اسان کي ڪجهه شامل ڪرڻ جي ضرورت آهي داغ، جيڪڏهن اهو ساڳيو ليبل آهي (ڪجهه قسم جي اڳڪٿي سان). آپريٽر سان ڪارناما واضح آهن ...

ڪنهن به ڪلستر ۾، معمولي ڪمن کي حل ڪيو وڃي، ۽ صحيح اهو آپريٽرز استعمال ڪندي ڪري سگهجي ٿو.

بيان ڪيل سڀني ڪهاڻين کي گڏ ڪري، اسان ان نتيجي تي پهتاسين Kubernetes ۾ آرام واري ڪم لاءِ توهان کي ضرورت آهي:ا) add-ons انسٽال ڪريوب) آپريٽرز کي ترقي ڪريو (روزمره جي انتظامي ڪمن کي حل ڪرڻ لاءِ).

ڪبرنيٽس لاءِ بيان ڪيئن لکجي؟

عام طور تي، اسڪيم سادو آهي:

... پر پوءِ معلوم ٿيو ته:

• Kubernetes API هڪ بلڪه غير معمولي شيء آهي جنهن کي ماسٽر ڪرڻ لاء گهڻو وقت وٺندو آهي؛
• پروگرامنگ پڻ هر ڪنهن لاءِ ناهي (گو ٻولي کي ترجيحي ٻولي طور چونڊيو ويو ڇاڪاڻ ته ان لاءِ هڪ خاص فريم ورڪ آهي - آپريٽر SDK);
• صورتحال پاڻ فريم ورڪ سان ساڳي آهي.

تري ليڪ: هڪ ڪنٽرولر لکڻ لاء (آپريٽر) کي گهرجي اهم وسيلا خرچ ڪرڻ مواد جو مطالعو ڪرڻ. اهو "وڏي" آپريٽرز لاءِ جائز هوندو - چئو، MySQL DBMS لاءِ. پر جيڪڏهن اسان مٿي بيان ڪيل مثالن کي ياد رکون ٿا (راز افشا ڪرڻ، انٽرنيٽ تائين پوڊس تائين رسائي...)، جنهن کي اسان به صحيح ڪرڻ چاهيون ٿا، ته پوءِ اسان سمجھنداسين ته خرچ ڪيل ڪوشش ان نتيجي کان وڌيڪ هوندي جنهن جي اسان کي هاڻي ضرورت آهي:

عام طور تي، هڪ مشڪوڪ پيدا ٿئي ٿو: تمام گهڻا وسيلا خرچ ڪريو ۽ بيان لکڻ لاء صحيح اوزار ڳوليو، يا اهو ڪريو پراڻي طريقي سان (پر جلدي). ان کي حل ڪرڻ لاءِ - انهن انتها پسندن جي وچ ۾ سمجهوتو ڳولڻ لاءِ - اسان پنهنجو منصوبو ٺاهيو: شيل آپريٽر (پڻ ڏسو سندس تازو اعلان حب تي).

شيل آپريٽر

هو ڪيئن ڪم ڪندو آهي؟ ڪلستر ۾ ھڪڙو پوڊ آھي جنھن ۾ ھڪڙي شيل آپريٽر سان گڏ گو بائنري آھي. هن جي اڳيان هڪ سيٽ آهي ٿلهو (انهن بابت وڌيڪ تفصيل - هيٺ ڏسو). شيل آپريٽر پاڻ کي ڪجهه رڪنيت حاصل ڪري ٿو واقعا Kubernetes API ۾، جنهن جي واقع ٿيڻ تي اهو لاڳاپيل ٿلهو شروع ڪري ٿو.

شيل آپريٽر کي ڪيئن خبر پوي ٿي ته ڪهڙن واقعن تي ڪهڙن ٿنڀن کي ڪال ڪرڻي آهي؟ اها معلومات شيل آپريٽر ڏانهن منتقل ڪئي وئي آهي پاڻ کي ٿلهو، ۽ اهي اهو بلڪل آسانيء سان ڪندا آهن.

هڪ ٿلهو هڪ بش اسڪرپٽ يا ڪنهن ٻئي قابل عمل فائل آهي جيڪو هڪ واحد دليل قبول ڪري ٿو --config ۽ JSON سان جواب ڏئي ٿو. بعد ۾ اهو طئي ڪري ٿو ته ڪهڙيون شيون ان سان دلچسپي رکن ٿيون ۽ ڪهڙن واقعن (هنن شين لاءِ) جواب ڏنو وڃي:

مان اسان جي مثالن مان هڪ شيل آپريٽر تي عمل درآمد کي بيان ڪندس - ايپليڪيشن تصويرن سان گڏ هڪ خانگي رجسٽري تائين رسائي حاصل ڪرڻ جا راز ختم ڪرڻ. اهو ٻن مرحلن تي مشتمل آهي.

مشق: 1. هڪ ٿلهو لکو

سڀ کان پهريان، ٿلهي ۾ اسان پروسيس ڪنداسين --config, اشارو ڪري ٿو ته اسان نالا اسپيس ۾ دلچسپي رکون ٿا، ۽ خاص طور تي، انهن جي تخليق جو لمحو:

[[ $1 == "--config" ]] ; then
  cat << EOF
{
  "onKubernetesEvent": [
    {
      "kind": "namespace",
      "event": ["add"]
    }
  ]
}
EOF
…

ڪهڙو منطق نظر ايندو؟ پڻ بلڪل سادو:

…
else
  createdNamespace=$(jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH)
  kubectl create -n ${createdNamespace} -f - << EOF
Kind: Secret
...
EOF
fi

پهريون قدم اهو ڳولڻ آهي ته ڪهڙي نالي جي جاء ٺاهي وئي هئي، ۽ ٻيو اهو آهي ته ان کي استعمال ڪندي ٺاهيو وڃي kubectl هن نالي جي جاء لاء راز.

مشق: 2. تصوير کي گڏ ڪرڻ

باقي اهو آهي ته ٺهيل ٿلهي کي شيل آپريٽر ڏانهن منتقل ڪرڻ - اهو ڪيئن ڪجي؟ شيل آپريٽر پاڻ هڪ ڊاکر تصوير جي طور تي اچي ٿو، تنهنڪري اسان جو ڪم هن تصوير ۾ هڪ خاص ڊاريڪٽري ۾ ٿلهو شامل ڪرڻ آهي:

FROM flant/shell-operator:v1.0.0-beta.1
ADD my-handler.sh /hooks

باقي رهي ٿو ان کي گڏ ڪرڻ ۽ ان کي دٻائڻ:

$ docker build -t registry.example.com/my-operator:v1 .
$ docker push registry.example.com/my-operator:v1

آخري رابطي تصوير کي ڪلستر تي ترتيب ڏيڻ آهي. ائين ڪرڻ لاء، اچو ته لکون رنيجرز:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-operator
spec:
  template:
    spec:
      containers:
      - name: my-operator
        image: registry.example.com/my-operator:v1 # 1
      serviceAccountName: my-operator              # 2

ڌيان ڏيڻ لاء ٻه نقطا آهن:

1. نئين ٺهيل تصوير جو اشارو؛
2. هي هڪ سسٽم جو حصو آهي جنهن کي (گهٽ ۾ گهٽ) حقن جي ضرورت آهي Kubernetes ۾ واقعن جي رڪنيت حاصل ڪرڻ ۽ نالن جي اسپيسز کي رازن کي مختص ڪرڻ لاءِ، تنهن ڪري اسان ٿلهو لاءِ هڪ ServiceAccount (۽ ضابطن جو هڪ سيٽ) ٺاهيون ٿا.

نتيجو - اسان پنهنجو مسئلو حل ڪيو مائٽ ڪبرنيٽس لاءِ هڪ طريقي سان جيڪو هڪ آپريٽر ٺاهي ٿو رازن کي ختم ڪرڻ لاءِ.

ٻيون شيل آپريٽر خاصيتون

توهان جي چونڊيل قسم جي شين کي محدود ڪرڻ لاءِ جنهن سان ٿلهو ڪم ڪندو، ان کي فلٽر ڪري سگهجي ٿوڪجهه مخصوص ليبلن جي مطابق چونڊيو (يا استعمال ڪندي matchExpressions):

"onKubernetesEvent": [
  {
    "selector": {
      "matchLabels": {
        "foo": "bar",
       },
       "matchExpressions": [
         {
           "key": "allow",
           "operation": "In",
           "values": ["wan", "warehouse"],
         },
       ],
     }
     …
  }
]

مهيا ڪيل نقل ڪرڻ واري ميڪانيزم، جيڪو - هڪ jq فلٽر استعمال ڪندي - توهان کي اجازت ڏئي ٿو وڏي JSON شين کي ننڍڙن شين ۾ تبديل ڪري، جتي صرف اهي پيرا ميٽر باقي رهن ٿا جيڪي اسان تبديلين جي نگراني ڪرڻ چاهيون ٿا.

جڏهن هڪ ٿلهو سڏيو ويندو آهي، شيل آپريٽر ان کي گذري ٿو اعتراض ڊيٽا، جيڪو ڪنهن به ضرورت لاءِ استعمال ڪري سگهجي ٿو.

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

۽ شيل آپريٽر جا ٻه وڌيڪ خاصيتون:

1. اهو ڪم ڪري ٿو هم وقت سازي سان. جيئن ته ڪوبرنيٽس واقعو (جهڙوڪ هڪ شئي ٺاهي پئي وڃي) وصول ڪيو ويو، ٻيا واقعا (جهڙوڪ ساڳي شئي کي ختم ڪيو پيو وڃي) ڪلستر ۾ ٿي سگهي ٿو، ۽ ٿلهن کي ان لاءِ اڪائونٽ ڪرڻ جي ضرورت آهي. جيڪڏهن ٿلهو غلطي سان عمل ڪيو ويو، پوء ڊفالٽ طرفان اهو ٿيندو ٻيهر سڏڻ ڪامياب مڪمل ٿيڻ تائين (هي رويي کي تبديل ڪري سگهجي ٿو).
2. اهو برآمد ڪري ٿو ميٽرڪس Prometheus لاءِ، جنهن سان توهان سمجهي سگهو ٿا ته ڇا شيل آپريٽر ڪم ڪري رهيو آهي، هر ٿلهي لاءِ غلطين جو تعداد ۽ موجوده قطار جي سائيز معلوم ڪريو.

رپورٽ جي هن حصي کي اختصار ڪرڻ لاء:

ايڊ آنس انسٽال ڪرڻ

Kubernetes سان آرام سان ڪم لاء، اضافو انسٽال ڪرڻ جي ضرورت پڻ ذڪر ڪيو ويو آهي. مان توهان کي ان بابت ٻڌائيندس اسان جي ڪمپني جي رستي جو مثال استعمال ڪندي ته اسان اهو ڪيئن ڪندا آهيون.

اسان ڪبرنيٽس سان گڏ ڪم ڪرڻ شروع ڪيو ڪيترن ئي ڪلسترن سان، جنهن ۾ صرف هڪ اضافو هو Ingress. ان کي هر ڪلستر ۾ مختلف طريقي سان انسٽال ڪرڻ جي ضرورت آهي، ۽ اسان مختلف ماحولن لاءِ ڪيتريون ئي YAML ترتيبون ٺاهيون: ننگي ڌاتو، AWS...

جيئن ته وڌيڪ ڪلستر هئا، اتي وڌيڪ ترتيبون هيون. ان کان علاوه، اسان انهن ترتيبن کي پاڻ ۾ بهتر ڪيو، جنهن جي نتيجي ۾ اهي ڪافي متضاد بڻجي ويا:

هر شي کي ترتيب ڏيڻ لاء، اسان هڪ اسڪرپٽ سان شروع ڪيو (install-ingress.sh)، جنهن هڪ دليل طور ورتو ڪلستر جو قسم جنهن تي اسان ترتيب ڏينداسين، ضروري YAML ترتيب ٺاهي ۽ ان کي ڪبرنيٽس ڏانهن وڌايو.

مختصر ۾، اسان جو وڌيڪ رستو ۽ ان سان لاڳاپيل دليل هن ريت هئا:

• YAML ترتيبن سان ڪم ڪرڻ لاءِ، ھڪڙي ٽيمپليٽ انجڻ گھربل آھي (پهرين مرحلن تي اھو سادو آھي)؛
• ڪلسٽرن جي تعداد ۾ واڌ سان، پاڻمرادو اپڊيٽ ڪرڻ جي ضرورت پيش آئي (سڀ کان پھرين حل اھو ھو ته اسڪرپٽ کي گٽ ۾ وجھو، ان کي ڪرون استعمال ڪري تازه ڪاري ڪري)؛
• Prometheus (install-prometheus.sh)، جڏهن ته، اها حقيقت قابل ذڪر آهي ته ان کي وڌيڪ ان پٽ ڊيٽا جي ضرورت آهي، انهي سان گڏ انهن جي اسٽوريج (سٺو طريقي سان - مرڪزي ۽ ڪلستر ۾)، ۽ ڪجهه ڊيٽا (پاسورڊ) خودڪار طريقي سان ٺاهي سگھجن ٿيون:

  

• ڪلستر جي وڌندڙ تعداد ۾ ڪجهه غلط ٿيڻ جو خطرو مسلسل وڌي رهيو هو، تنهنڪري اسان محسوس ڪيو ته انسٽالر (يعني ٻه اسڪرپٽ: Ingress ۽ Prometheus لاءِ) اسٽيجنگ جي ضرورت هئي (گٽ ۾ ڪيتريون ئي شاخون، ڪيترن ئي ڪرون انهن کي لاڳاپيل ۾ تازه ڪاري ڪرڻ لاء: مستحڪم يا ٽيسٽ ڪلستر)؛
• с kubectl apply ان سان ڪم ڪرڻ ڏکيو ٿي ويو آهي ڇاڪاڻ ته اهو بيان ڪندڙ نه آهي ۽ صرف شيون ٺاهي سگهي ٿو، پر انهن جي حيثيت تي فيصلو نه ڪري سگهي ٿو / انهن کي حذف ڪري ٿو؛
• اسان ڪجھ ڪمن کي وڃائي رهيا هئاسين جيڪي اسان ان وقت لاڳو نه ڪيا هئا:
  • ڪلستر اپڊيٽ جي نتيجي تي مڪمل ڪنٽرول،
  • ڊيٽا جي بنياد تي ڪجھ پيٽرولرن جو پاڻمرادو تعين (انسٽاليشن اسڪرپٽس لاءِ ان پٽ) جيڪو ڪلستر مان حاصل ڪري سگھجي ٿو (دريافت)،
  • مسلسل دريافت جي صورت ۾ ان جي منطقي ترقي.

اسان اهو سڀ گڏ ڪيل تجربو پنهنجي ٻئي منصوبي جي فريم ورڪ ۾ لاڳو ڪيو. اضافو آپريٽر.

ايڊون آپريٽر

اهو اڳ ۾ ئي ذڪر ڪيل شيل آپريٽر تي ٻڌل آهي. سڄو سسٽم هن طرح نظر اچي ٿو:

شيل آپريٽر ٿلهو ۾ هيٺيون شامل ڪيو ويو آهي:

• قدر جو ذخيرو,
• هيلم چارٽ,
• جزو جو قدر جي دڪان مانيٽر ڪري ٿو ۽ - ڪنهن به تبديلي جي صورت ۾ - هيلم کي چارٽ ٻيهر رول ڪرڻ لاءِ پڇي ٿو.

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

اتي ڪيترائي ماڊل ٿي سگھن ٿا، ۽ انھن ۾ اسان گلوبل ٿلهو، ھڪڙو گلوبل ويلز اسٽور، ۽ ھڪڙو حصو شامل ڪريون ٿا جيڪو ھن گلوبل اسٽور جي نگراني ڪري ٿو.

هاڻي، جڏهن ڪوبرنيٽس ۾ ڪجهه ٿئي ٿو، اسان ان تي رد عمل ڪري سگهون ٿا گلوبل ٿلهو استعمال ڪندي ۽ گلوبل اسٽور ۾ ڪجهه تبديل ڪريو. هي تبديلي محسوس ڪئي ويندي ۽ ڪلستر ۾ سڀني ماڊلز کي رول آئوٽ ڪرڻ جو سبب بڻائيندو:

هي اسڪيم اضافن کي نصب ڪرڻ جي سڀني ضرورتن کي پورو ڪري ٿو جيڪي مٿي بيان ڪيون ويون آهن:

• هيلم templating ۽ declarativeness لاء ذميوار آهي.
• خودڪار تازه ڪاري جو مسئلو حل ڪيو ويو هڪ گلوبل ٿلهو استعمال ڪندي، جيڪو شيڊول تي رجسٽري ڏانهن وڃي ٿو ۽، جيڪڏهن اهو اتي هڪ نئين سسٽم جي تصوير ڏسي ٿو، ان کي رول ڪري ٿو (يعني "پاڻ").
• ڪلستر ۾ اسٽوريج سيٽنگون استعمال ڪندي لاڳو ڪئي وئي آهي ConfigMap، جنهن ۾ اسٽوريج لاءِ بنيادي ڊيٽا شامل آهي (شروعات ۾ اهي اسٽوريج ۾ لوڊ ڪيا ويندا آهن).
• پاسورڊ پيدا ڪرڻ، دريافت ۽ مسلسل دريافت سان مسئلا حل ڪيا ويا ٿلهو استعمال ڪندي.
• اسٽيجنگ حاصل ڪئي وئي آهي ٽيگ جي مهرباني، جنهن کي ڊاکر باڪس کان ٻاهر سپورٽ ڪري ٿو.
• نتيجو ميٽرڪ استعمال ڪندي مانيٽر ڪيو ويو آهي جنهن جي ذريعي اسان صورتحال کي سمجهي سگهون ٿا.

هي سڄو سسٽم گو ۾ هڪ واحد بائنري جي صورت ۾ لاڳو ٿئي ٿو، جنهن کي ايڊون آپريٽر سڏيو ويندو آهي. هي ڊراگرام آسان بڻائي ٿو:

هن آريگرام ۾ مکيه حصو ماڊلز جو هڪ سيٽ آهي (هيٺ ڳاڙهي رنگ ۾ نمايان ٿيل). ھاڻي اسان ٿورڙي ڪوشش سان گھربل ايڊ آن لاءِ ھڪڙو ماڊل لکي سگھون ٿا ۽ پڪ ڪريو ته اھو ھر ڪلسٽر ۾ انسٽال ڪيو ويندو، اپڊيٽ ڪيو ويندو ۽ ڪلستر ۾ گھربل واقعن جو جواب ڏنو ويندو.

"Flant" استعمال ڪري ٿو اضافو آپريٽر 70+ Kubernetes ڪلستر تي. موجوده حيثيت - الفا نسخو. هاڻي اسان بيٽا کي ڇڏڻ لاء دستاويز تيار ڪري رهيا آهيون، پر هاڻي لاء مخزن ۾ مثال موجود آهن، جنهن جي بنياد تي توهان پنهنجو پنهنجو اضافو ٺاهي سگهو ٿا.

مان ايڊون آپريٽر لاءِ ماڊل ڪٿي حاصل ڪري سگهان ٿو؟ اسان جي لائبريري کي شايع ڪرڻ اسان لاءِ ايندڙ مرحلو آهي؛ اسان اونهاري ۾ اهو ڪرڻ جو ارادو رکون ٿا.

وڊيوز ۽ سلائڊ

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

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

پي ايس

اسان جي بلاگ تي ٻيون رپورٽون:

• «ڊيٽابيس ۽ ڪبرنيٽس"؛ (دمتري اسٽوليروف؛ نومبر 8، 2018 HighLoad++ تي);
• «نگراني ۽ Kubernetes"؛ (دمتري اسٽولياروف؛ 28 مئي 2018 تي RootConf);
• «CI/CD بهترين طريقا ڪبرنيٽس ۽ گيٽ ليب سان"؛ (دمتري اسٽوليروف؛ نومبر 7، 2017 HighLoad++ تي);
• «اسان جو تجربو ڪبرنيٽس سان ننڍن منصوبن ۾"؛ (دمتري اسٽولياروف؛ 6 جون، 2017 تي RootConf).

توھان شايد ھيٺ ڏنل اشاعتن ۾ پڻ دلچسپي وٺندا.

• «شيل آپريٽر جو تعارف: ڪبرنيٽس لاءِ آپريٽر ٺاهڻ بلڪل آسان ٿي ويو آهي».

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