🥇 ڪبرنيٽس استعمال ڪرڻ وقت 10 عام غلطيون

نوٽ. ترجموهن مضمون جا ليکڪ هڪ ننڍڙي چيڪ ڪمپني پائپ ٽيل جا انجنيئر آهن. انهن ڪبرنيٽس ڪلسٽر هلائڻ سان لاڳاپيل [ڪڏهن ڪڏهن معمولي، پر اڃا تائين تمام لاڳاپيل] مسئلن ۽ غلط فهمين جي هڪ قابل ذڪر فهرست مرتب ڪئي آهي.

ڪبرنيٽس استعمال ڪرڻ جي سالن کان، اسان وڏي تعداد ۾ ڪلسٽرن سان ڪم ڪيو آهي (ٻنهي منظم ۽ غير منظم - GCP، AWS، ۽ Azure تي). وقت سان گڏ، اسان ڪجهه بار بار ٿيندڙ غلطيون محسوس ڪرڻ شروع ڪيون. جڏهن ته، ان ۾ ڪو به شرم جي ڳالهه ناهي: اسان انهن مان گهڻا پاڻ ڪيا آهن!

هن مضمون ۾ سڀ کان وڌيڪ عام غلطيون شامل آهن ۽ انهن کي درست ڪرڻ جي معلومات پڻ فراهم ڪئي وئي آهي.

1. وسيلا: درخواستون ۽ حدون

هي نقطو يقيني طور تي سڀ کان وڌيڪ ڌيان ۽ فهرست ۾ پهرين جڳهه جو مستحق آهي.

عام طور تي سي پي يو جي درخواست يا ته بلڪل مقرر نه آهي يا ان جي قيمت تمام گهٽ آهي. (هر نوڊ تي ممڪن حد تائين گھڻا پوڊ رکڻ لاءِ). ان جي نتيجي ۾ نوڊس اوورلوڊ ٿين ٿا. وڌيڪ لوڊ جي دور ۾، نوڊ جي سي پي يو جي گنجائش مڪمل طور تي استعمال ڪئي ويندي آهي، ۽ ڏنل ڪم لوڊ صرف اهو حاصل ڪري ٿو جيڪو ان ذريعي "درخواست" ڪئي هئي. سي پي يو ٿروٽلنگان جي ڪري ايپليڪيشن جي دير، وقت ختم ٿيڻ، ۽ ٻيا ناخوشگوار نتيجا وڌي ويندا آهن. (هن بابت وڌيڪ ڄاڻ لاءِ، اسان جو ٻيو تازو ترجمو ڏسو: "سي پي يو جي حدن ۽ ڪبرنيٽس ۾ جارحيت وارو تختو"- لڳ ڀڳ. ترجمو.)

بهترين ڪوشش (انتهائي نه سفارش ٿيل):

resources: {}

انتهائي گهٽ سي پي يو درخواست (انتهائي نه سفارش ٿيل):

   resources:
      Requests:
        cpu: "1m"

ٻئي طرف، سي پي يو جي حد هجڻ ڪري پوڊس غير ضروري طور تي چڪر کي گهٽائي سگهن ٿا، جيتوڻيڪ نوڊ جو سي پي يو مڪمل طور تي استعمال نه ڪيو ويو آهي. اهو پڻ دير ۾ اضافو ڪري سگهي ٿو. هن پيرا ميٽر جي چوڌاري بحث جاري آهي. سي پي يو سي ايف ايس ڪوٽا بنيادي ۾ Linux и троттлинга CPU в зависимости от установленных лимитов, а также отключении квоты CFS… Увы, лимиты CPU могут вызвать больше проблем, чем способны решить. Подробнее об этом можно узнать по ссылке ниже.

گهڻي رطوبت (حد کان وڌيڪ ڪم ڪرڻ) ياداشت وڌيڪ وسيع مسئلا پيدا ڪري سگهي ٿي. سي پي يو جي حد تائين پهچڻ سان سائيڪلون ڇڏي ڏنيون وينديون آهن، جڏهن ته ياداشت جي حد تائين پهچڻ سان پوڊ ختم ٿي ويندو آهي. ڇا توهان ڪڏهن ڏٺو آهي؟ او او ڪل؟ ها، بلڪل اهو ئي آهي جنهن بابت اسين ڳالهائي رهيا آهيون.

ڇا توهان هن جي امڪان کي گهٽ ڪرڻ چاهيو ٿا؟ ياداشت کي وڌيڪ مختص نه ڪريو ۽ گارنٽيڊ QoS (سروس جي معيار) استعمال ڪريو، ياداشت جي درخواست کي حد جي برابر مقرر ڪريو (جيئن هيٺ ڏنل مثال ۾). ان بابت وڌيڪ پڙهو هيننگ جيڪب جون پيشڪشون (زالانڊو ۾ ليڊ انجنيئر).

برسٽبل (او او ايم جي قتل ٿيڻ جو وڌيڪ امڪان):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

تصديق ٿيل:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

وسيلن کي قائم ڪرڻ وقت ڪهڙي شيءِ ممڪن طور تي مدد ڪري سگهي ٿي؟

جي مدد سان ميٽرڪس-سرور توهان پوڊس (۽ انهن اندر ڪنٽينرز) جي موجوده سي پي يو ۽ ميموري استعمال کي ڏسي سگهو ٿا. توهان شايد اڳ ۾ ئي ان کي استعمال ڪري رهيا آهيو. صرف هيٺيان حڪم هلايو:

kubectl top pods
kubectl top pods --containers
kubectl top nodes

جڏهن ته، اهي صرف موجوده استعمال ڏيکارين ٿا. اهو توهان کي شدت جي ترتيب جو هڪ معمولي خيال ڏئي سگهي ٿو، پر آخرڪار توهان کي ضرورت پوندي وقت سان گڏ ميٽرڪ تبديلين جي تاريخ (سوالن جا جواب ڏيڻ لاءِ جيئن: "سي پي يو جو چوٽي لوڊ ڇا هو؟"، "ڪالهه صبح جو لوڊ ڇا هو؟" - وغيره) ان لاءِ توهان استعمال ڪري سگهو ٿا Prometheus, DataDog ۽ ٻيا اوزار. اهي صرف ميٽرڪس-سرور مان ميٽرڪس حاصل ڪن ٿا ۽ انهن کي ذخيرو ڪن ٿا، صارف کي انهن کان سوال ڪرڻ ۽ لاڳاپيل گراف ٺاهڻ جي اجازت ڏين ٿا.

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

ڪمپيوٽنگ پاور کي موثر طريقي سان استعمال ڪرڻ مشڪل آهي. اهو مسلسل ٽيٽرس کيڏڻ وانگر آهي. جيڪڏهن توهان گهٽ اوسط وسيلن (چئو، ~ 10٪) استعمال ڪندي ڪمپيوٽنگ پاور لاءِ تمام گهڻو ادا ڪري رهيا آهيو، ته اسان AWS فارگيٽ يا ورچوئل ڪيوبليٽ تي ٻڌل شين تي غور ڪرڻ جي صلاح ڏيون ٿا. اهي شيون هڪ سرور کان سواءِ/پي-في-استعمال بلنگ ماڊل استعمال ڪن ٿيون، جيڪو انهن حالتن ۾ سستو ٿي سگهي ٿو.

2. جيئرو ۽ تيارگي جاچ

ڪبرنيٽس ۾ ڊفالٽ طور تي زندگي ۽ تياري جي چڪاس فعال نه آهن. ۽ ڪڏهن ڪڏهن، ماڻهو انهن کي فعال ڪرڻ وساري ڇڏيندا آهن...

پر هڪ خطرناڪ غلطي جي صورت ۾ سروس ٻيهر ڪيئن شروع ڪري سگهجي ٿي؟ ۽ لوڊ بيلنس ڪندڙ کي ڪيئن خبر پوي ٿي ته هڪ پوڊ ٽرئفڪ قبول ڪرڻ لاءِ تيار آهي؟ يا اهو وڌيڪ ٽرئفڪ سنڀالي سگهي ٿو؟

اهي ٽيسٽ اڪثر هڪ ٻئي سان پريشان هوندا آهن:

حياتي ڏيڻ - هڪ لائيونس چيڪ جيڪو ناڪام ٿيڻ جي صورت ۾ پوڊ کي ٻيهر شروع ڪري ٿو؛
تيارگي — هڪ تياري جي جانچ، جيڪا، جيڪڏهن ناڪام ٿئي ٿي، ته پوڊ کي ڪبرنيٽس سروس کان ڌار ڪري ٿي (هن کي استعمال ڪندي چيڪ ڪري سگهجي ٿو kubectl get endpoints) ۽ ايندڙ چيڪ ڪاميابي سان مڪمل ٿيڻ تائين ڪا به ٽرئفڪ نه ملندي.

اهي ٻئي ٽيسٽ پوڊ جي پوري زندگي جي چڪر دوران پرفارم ڪيو ويوهي تمام ضروري آهي.

اهو هڪ عام غلط فهمي آهي ته ريڊينيس پروبس صرف شروعات ۾ هلايا ويندا آهن ته جيئن لوڊ بيلنس ڪندڙ کي خبر پوي ته پوڊ تيار آهي (Ready) ۽ ٽرئفڪ جي پروسيسنگ شروع ڪري سگھي ٿو. بهرحال، هي صرف ممڪن استعمالن مان هڪ آهي.

ٻيو اهو ڄاڻڻ جي صلاحيت آهي ته پوڊ تي ٽرئفڪ تمام گهڻو آهي ۽ ان کي اوور لوڊ ڪري ٿو (يا پوڊ وسيلن جي لحاظ کان گهربل حساب ڪتاب ڪري رهيو آهي). هن صورت ۾، تياري جي جانچ مدد ڪري ٿي پوڊ تي لوڊ گھٽايو ۽ ان کي "ٿڌو" ڪريومستقبل ۾ تياري جي جانچ جي ڪامياب مڪمل ٿيڻ جي اجازت ڏئي ٿي پوڊ تي لوڊ ٻيهر وڌايوهن صورت ۾ (جيڪڏهن تياري جو امتحان ناڪام ٿئي ٿو)، جيوت جي امتحان ۾ ناڪام ٿيڻ تمام گهڻو نقصانڪار هوندو. هڪ صحتمند ۽ محنتي پوڊ کي ٻيهر شروع ڇو ڪجي؟

تنهن ڪري، ڪجهه حالتن ۾، چيڪن کي مڪمل طور تي ختم ڪرڻ انهن کي غلط ترتيب ڏنل پيرا ميٽرز سان فعال ڪرڻ کان بهتر آهي. جيئن مٿي ذڪر ڪيو ويو آهي، جيڪڏهن زندهه رهڻ جي چڪاس ڪاپيون تياري جي چڪاس، ته پوءِ توهان وڏي مصيبت ۾ آهيو. هڪ ممڪن آپشن سيٽ اپ ڪرڻ آهي صرف تياري جو امتحان۽ خطرناڪ زندگي ڇڏي ڏيو.

جڏهن شيئر ٿيل انحصار ناڪام ٿين ٿا ته ٻنهي قسمن جي چيڪن کي ناڪام نه ٿيڻ گهرجي، ٻي صورت ۾ اهو سڀني پوڊس جي ڪيسڪيڊنگ (برفاني برفاني طوفان وانگر) ناڪامي جو سبب بڻجندو. ٻين لفظن ۾، پاڻ کي نقصان نه پهچايو..

3. هر HTTP سروس لاءِ لوڊ بيلنس

گهڻو ڪري، توهان جي ڪلسٽر ۾ HTTP خدمتون آهن جيڪي توهان ٻاهرين دنيا ۾ ظاهر ڪرڻ چاهيندا.

جيڪڏهن توهان سروس کوليو ٿا جيئن type: LoadBalancer، ان جو ڪنٽرولر (سروس فراهم ڪندڙ تي منحصر آهي) هڪ ٻاهرين لوڊ بيلنس فراهم ڪندو ۽ ان سان ڳالهه ٻولهه ڪندو (ضروري ناهي ته L7 تي هلندو هجي، گهڻو ڪري L4 تي به)، ۽ اهو قيمت تي اثر انداز ٿي سگهي ٿو (خارجي جامد IPv4 پتو، ڪمپيوٽنگ پاور، في سيڪنڊ بلنگ) ڇاڪاڻ ته اهڙن وسيلن جي وڏي تعداد ٺاهڻ جي ضرورت آهي.

هن صورت ۾، هڪ خارجي لوڊ بيلنس ڪندڙ استعمال ڪرڻ تمام گهڻو سمجهه ۾ اچي ٿو، خدمتن کي کولڻ جي طور تي type: NodePortيا، اڃا به بهتر، ڪجهه اهڙي ترتيب ڏيو nginx-ingress-ڪنٽرولر (يا پيچرو)، جيڪو پرفارم ڪرڻ وارو اڪيلو هوندو نوڊ پورٽ هڪ خارجي لوڊ بيلنسر سان لاڳاپيل اينڊ پوائنٽ ۽ ڪلسٽر اندر ٽرئفڪ کي استعمال ڪندي روٽ ڪندو داخل ٿيڻ- ڪبرنيٽس وسيلا.

ٻيون انٽرا ڪلسٽر (مائڪرو) خدمتون جيڪي هڪ ٻئي سان لهه وچڙ ۾ اچن ٿيون، اهي هن قسم جي خدمتن کي استعمال ڪندي "ڳالهه ٻولهه" ڪري سگهن ٿيون. ڪلستر پي ۽ هڪ بلٽ ان DNS سروس دريافت ميڪانيزم. بس انهن جي عوامي DNS/IP پتي کي استعمال نه ڪريو، ڇاڪاڻ ته اهو دير تي اثر انداز ٿي سگهي ٿو ۽ ڪلائوڊ سروس جي قيمتن کي وڌائي سگهي ٿو.

4. ڪلسٽر جي خاصيتن کي نظر ۾ رکڻ کان سواءِ آٽو اسڪيلنگ

ڪلسٽر مان نوڊس شامل ڪرڻ ۽ ڪڍڻ وقت، انهن نوڊس تي سي پي يو جي استعمال جهڙي بنيادي ميٽرڪس تي ڀروسو نه ڪريو. پوڊ شيڊولنگ مختلف عنصرن کي ذهن ۾ رکندي ڪيو وڃي. پابنديون، جهڙوڪ پوڊ/نوڊ افينٽي، ٽينٽ ۽ برداشت، وسيلن جي درخواست، QoS، وغيره. هڪ ٻاهرين آٽو اسڪيلر استعمال ڪرڻ جيڪو انهن باریکين کي نظر ۾ نٿو رکي، مسئلا پيدا ڪري سگهي ٿو.

تصور ڪريو ته هڪ پوڊ کي شيڊول ڪرڻ جي ضرورت آهي، پر سڀ موجود سي پي يو گنجائش گهربل/مختص ڪئي وئي آهي ۽ پوڊ حالت ۾ ڦاسي پوي ٿو Pendingٻاهرين آٽو اسڪيلر سراسري موجوده سي پي يو لوڊ ڏسي ٿو (درخواست ڪيل نه) ۽ واڌ شروع نٿو ڪري. (اسڪيل آئوٽ) — ٻيو نوڊ شامل نٿو ڪري. نتيجي طور، هي پوڊ شيڊول نه ٿيندو.

هن صورت ۾، ريورس اسڪيلنگ (اسڪيل-ان) — ڪلسٽر مان نوڊ ڪڍڻ هميشه لاڳو ڪرڻ وڌيڪ ڏکيو هوندو آهي. تصور ڪريو ته توهان وٽ هڪ اسٽيٽ فل پوڊ آهي (منسلڪ مسلسل اسٽوريج سان). مسلسل جلدون عام طور تي تعلق رکن ٿا هڪ مخصوص دستيابي وارو علائقو ۽ علائقي اندر نقل نه ڪيا ويا آهن. تنهن ڪري، جيڪڏهن ڪو ٻاهرين آٽو اسڪيلر هن پوڊ سان هڪ نوڊ کي ختم ڪري ٿو، ته شيڊولر هن پوڊ کي ٻئي نوڊ تي شيڊول ڪرڻ جي قابل نه هوندو، ڇاڪاڻ ته اهو صرف دستيابي زون ۾ ٿي سگهي ٿو جتي مسلسل اسٽوريج واقع آهي. پوڊ حالت ۾ ڦاسي پوندو. Pending.

اهو ڪبرنيٽس برادري ۾ تمام گهڻو مشهور آهي. ڪلسٽر-آٽو اسڪيلراهو هڪ ڪلسٽر ۾ هلندو آهي، وڏن ڪلائوڊ فراهم ڪندڙن جي APIs کي سپورٽ ڪري ٿو، سڀني پابندين جو احترام ڪري ٿو، ۽ مٿي ذڪر ڪيل ڪيسن ۾ اسڪيل ڪري سگهي ٿو. اهو سڀني قائم ٿيل پابندين کي برقرار رکندي اسڪيل-ان پڻ ڪري سگهي ٿو، انهي ڪري پئسا بچائي سگهي ٿو (جيڪو ٻي صورت ۾ غير استعمال ٿيل گنجائش تي ضايع ٿيندو).

5. IAM/RBAC صلاحيتن کي نظرانداز ڪرڻ

مسلسل رازن سان IAM استعمال ڪندڙن کي استعمال ڪرڻ کان خبردار رهو مشينون ۽ ايپليڪيشنونرولز ۽ سروس اڪائونٽس استعمال ڪندي عارضي رسائي فراهم ڪريو. (سروس اڪائونٽس).

اسان کي اڪثر اهڙين حالتن جو منهن ڏسڻو پوي ٿو جتي رسائي ڪيز (۽ راز) ايپليڪيشن ڪنفيگريشن ۾ هارڊ ڪوڊ ٿيل آهن، ۽ انهي سان گڏ جتي ڪلائوڊ IAM تائين رسائي هجڻ جي باوجود راز جي گردش کي نظرانداز ڪيو ويندو آهي. جتي مناسب هجي اتي استعمال ڪندڙن جي بدران IAM ڪردار ۽ سروس اڪائونٽس استعمال ڪريو.

kube2iam کي وساريو ۽ سروس اڪائونٽس لاءِ سڌو IAM رولز ڏانهن وڃو (جيئن بيان ڪيو ويو آهي ساڳئي نالي جو نوٽ اسٽيپان وراني):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

هڪ وضاحت. ايترو ڏکيو نه، صحيح؟

انهي سان گڏ، سروس اڪائونٽس ۽ انسٽنس پروفائلز کي مراعات نه ڏيو. admin и cluster-admin، جيستائين انهن کي ان جي ضرورت نه هجي. اهو لاڳو ڪرڻ ٿورو وڌيڪ ڏکيو آهي، خاص طور تي K8s RBAC ۾، پر اهو يقيني طور تي ڪوشش جي لائق آهي.

6. پوڊس لاءِ خودڪار اينٽي افينٽي تي ڀروسو نه ڪريو.

تصور ڪريو ته توهان وٽ هڪ نوڊ تي هڪ خاص ڊيپلائيمينٽ جا ٽي نقل آهن. نوڊ هيٺ لهي ويندو آهي، ۽ ان سان گڏ سڀئي نقل. تمام خراب، صحيح؟ پر سڀئي نقل هڪ ئي نوڊ تي ڇو هئا؟ ڇا ڪبرنيٽس کي اعليٰ دستيابي (HA) فراهم ڪرڻ نه گهرجي؟!

بدقسمتي سان، ڪبرنيٽس شيڊولر رضاڪارانه طور تي الڳ وجود جي ضابطن کي لاڳو نٿو ڪري. (مخالف تعلق) پوڊس لاءِ. انهن کي واضح طور تي بيان ڪيو وڃي:

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

بس اهو ئي آهي. هاڻي پوڊس مختلف نوڊس تي شيڊول ڪيا ويندا (هي حالت صرف شيڊولنگ دوران چيڪ ڪئي ويندي آهي، پر انهن جي آپريشن دوران نه - تنهن ڪري requiredDuringSchedulingIgnoredDuringExecution).

هتي اسين ڳالهائي رهيا آهيون podAntiAffinity مختلف نوڊس تي: topologyKey: "kubernetes.io/hostname"، ۽ مختلف دستيابي زونن بابت نه. مڪمل HA لاڳو ڪرڻ لاءِ، اسان کي هن موضوع ۾ وڌيڪ کوٽائي ڪرڻي پوندي.

7. PodDisruptionBudgets کي نظرانداز ڪرڻ

تصور ڪريو ته توهان وٽ ڪبرنيٽس ڪلسٽر ۾ پيداوار جو ڪم لوڊ آهي. وقت بوقت، نوڊس ۽ ڪلسٽر کي اپڊيٽ ڪرڻ (يا ختم ڪرڻ) جي ضرورت آهي. پوڊ ڊسڪشن بجيٽ (PDB) ڪلسٽر ايڊمنسٽريٽرن ۽ استعمال ڪندڙن جي وچ ۾ هڪ قسم جو گارنٽي ٿيل سروس معاهدو آهي.

پي ڊي بي نوڊ جي کوٽ جي ڪري سروس بندش کان بچڻ ۾ مدد ڪري ٿو:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

هن مثال ۾، توهان، هڪ ڪلسٽر استعمال ڪندڙ جي حيثيت سان، منتظمين کي ٻڌائي رهيا آهيو: "هي، مون وٽ هڪ زو ڪيپر سروس آهي، ۽ توهان ڇا به ڪريو، مان چاهيان ٿو ته هن سروس جون گهٽ ۾ گهٽ 2 نقلون هميشه دستياب هجن."

توهان هن بابت وڌيڪ هتي پڙهي سگهو ٿا هتي.

8. هڪ عام ڪلسٽر ۾ ڪيترائي استعمال ڪندڙ يا ماحول

ڪبرنيٽس نيم اسپيسز (نيمز اسپيس) مضبوط موصليت فراهم نه ڪريو.

اهو هڪ عام غلط فهمي آهي ته جيڪڏهن توهان هڪ نالي واري جاءِ ۾ هڪ غير پروڊ لوڊ ۽ ٻئي ۾ هڪ پروڊ لوڊ لڳايو ٿا، ته اهي ڪنهن به طرح هڪ ٻئي تي اثر انداز نه ٿيندا… بهرحال، وسيلن جي درخواستن/حدود، ڪوٽا مقرر ڪرڻ، ۽ ترجيحي ڪلاسن جي وضاحت ذريعي ڪجهه سطح جي اڪيلائي حاصل ڪري سگهجي ٿي. لاڳاپو، برداشت، ۽ داغ (يا نوڊ چونڊيندڙ) ڊيٽا جهاز ۾ ڪجهه "جسماني" اڪيلائي فراهم ڪن ٿا، پر اهڙي علحدگي ڪافي آهي. پيچيده لاڳو ڪرڻ.

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

9. خارجي ٽرئفڪ پاليسي: ڪلسٽر

گهڻو ڪري اسان ڏسون ٿا ته ڪلسٽر ۾ سڀ ٽرئفڪ نوڊ پورٽ جهڙي سروس ذريعي اچي ٿي، جنهن لاءِ ڊفالٽ پاليسي مقرر ڪئي وئي آهي. externalTrafficPolicy: Cluster... اِن جو مطلب آهي نوڊ پورٽ ڪلسٽر ۾ هر نوڊ تي کليل، ۽ توهان انهن مان ڪنهن به کي گهربل سروس (پوڊس جو سيٽ) سان رابطو ڪرڻ لاءِ استعمال ڪري سگهو ٿا.

ساڳئي وقت، مٿي ذڪر ڪيل نوڊ پورٽ سروس سان لاڳاپيل اصل پوڊ عام طور تي صرف ڪجهه تي موجود آهن انهن نوڊس جو ذيلي سيٽٻين لفظن ۾، جيڪڏهن مان ڪنهن اهڙي نوڊ سان ڳنڍيان ٿو جنهن ۾ مون کي گهربل پوڊ نه آهي، ته اهو ٽرئفڪ کي ٻئي نوڊ ڏانهن موڪليندو، ٽرانزٽ سيڪشن شامل ڪرڻ (هاپ) ۽ وڌندڙ دير (جيڪڏهن نوڊس مختلف دستيابي زونن/ڊيٽا سينٽرن ۾ آهن، ته دير تمام گهڻي ٿي سگهي ٿي؛ ان کان علاوه، نڪرڻ واري ٽرئفڪ جي قيمت وڌي ويندي).

ٻئي طرف، جيڪڏهن ڪا پاليسي ڪنهن خاص ڪبرنيٽس سروس لاءِ بيان ڪئي وئي آهي externalTrafficPolicy: Local، پوءِ نوڊ پورٽ صرف انهن نوڊس تي کوليو ويندو آهي جتي گهربل پوڊ اصل ۾ هلي رهيا آهن. جڏهن هڪ خارجي لوڊ بيلنسر استعمال ڪيو ويندو آهي جيڪو اسٽيٽس چيڪ ڪري ٿو (صحت جي چڪاس) آخري نقطا (اهو ڪيئن ڪندو آهي) AWS اي ايل بي)، هو صرف گهربل نوڊس ڏانهن ٽرئفڪ موڪليندو، جنهن جو دير، ڪمپيوٽنگ جي ضرورتن، نڪرڻ جي بلن تي مثبت اثر پوندو (۽ عام فهم ساڳيو ئي ڪم ڪري ٿو).

هڪ سٺو موقعو آهي ته توهان اڳ ۾ ئي ڪجهه استعمال ڪري رهيا آهيو جهڙوڪ پيچرو يا nginx-ingress-ڪنٽرولر HTTP انگريس ٽرئفڪ کي روٽ ڪرڻ لاءِ نوڊ پورٽ اينڊ پوائنٽ (يا لوڊ بيلنس، جيڪو نوڊ پورٽ پڻ استعمال ڪري ٿو) جي طور تي، ۽ هن آپشن کي سيٽ ڪرڻ سان اهڙين درخواستن لاءِ دير کي گهٽائي سگهجي ٿو.

В هن اشاعت توهان externalTrafficPolicy، ان جي فائدن ۽ نقصانن بابت وڌيڪ سکي سگهو ٿا.

10. ڪلسٽرن سان ڳنڍيل نه ٿيو ۽ ڪنٽرول جهاز جو گهڻو استعمال نه ڪريو.

اڳي، سرورز کي انهن جي صحيح نالن سان سڏڻ عام هو: Anton، HAL9000، ۽ ڪولوسس... اڄ، انهن کي بي ترتيب طور تي ٺاهيل سڃاڻپ ڪندڙن سان تبديل ڪيو ويو آهي. بهرحال، عادت رهي ٿي، ۽ هاڻي ڪلسٽر پنهنجا نالا حاصل ڪن ٿا.

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

ڪُلهن جي پالتو جانورن ۾ تبديل ٿيڻ ۾ ڪا به مزاحيه ڳالهه ناهي، تنهن ڪري اسان صلاح ڏيون ٿا ته وقت بوقت انهن کي هٽايو وڃي، جڏهن ته ساڳئي وقت مشق ڪئي وڃي آفت جي بحالي (هي مدد ڪندو افراتفري انجنيئرنگ - لڳ ڀڳ ترجمو.)ان کان علاوه، ڪنٽرول ليئر تي ڪم ڪرڻ ۾ ڪو به نقصان نه ٿيندو. (ڪنٽرول جهاز)کيس ڇهڻ جو خوف ڪا سٺي نشاني ناهي. وغيره مري ويو؟ دوستو، توهان تمام گهڻي مصيبت ۾ آهيو!

ٻئي طرف، توهان کي ان کي هٿ چراند ڪرڻ ۾ مشغول نه ٿيڻ گهرجي. وقت سان گڏ ڪنٽرول پرت سست ٿي سگهي ٿي.اهو گهڻو ڪري ان ڪري آهي جو گھڻي تعداد ۾ شيون بغير گھمڻ جي پيدا ڪيون ويون آهن (هڪ عام صورتحال جڏهن هيلم کي ڊفالٽ سيٽنگن سان استعمال ڪيو ويندو آهي، جيڪا ان جي حالت کي configmaps/secrets ۾ اپڊيٽ ٿيڻ کان روڪي ٿي - نتيجي ۾ هزارين شيون ڪنٽرول پرت ۾ جمع ٿين ٿيون) يا kube-api شين جي مسلسل ايڊيٽنگ (آٽو اسڪيلنگ، CI/CD، مانيٽرنگ، ايونٽ لاگ، ڪنٽرولرز، وغيره لاءِ).

اضافي طور تي، اسان توهان جي منظم ڪبرنيٽس فراهم ڪندڙ سان SLA/SLO معاهدن جو جائزو وٺڻ ۽ ڪنهن به ضمانت تي ڌيان ڏيڻ جي صلاح ڏيون ٿا. وڪرو ڪندڙ ضمانت ڏئي سگهي ٿو ڪنٽرول پرت جي دستيابي (يا ان جا ذيلي جزا)، پر توهان جي موڪليل درخواستن جي p99 دير نه. ٻين لفظن ۾، توهان داخل ڪري سگهو ٿا kubectl get nodes، ۽ صرف 10 منٽن ۾ جواب ملندو، ۽ اهو سروس معاهدي جي شرطن جي خلاف ورزي نه هوندي.

11. بونس: جديد ٽيگ استعمال ڪريو

هاڻي اهو هڪ ڪلاسيڪل آهي. اسان کي اڄڪلهه هي ٽيڪنڪ گهڻو نظر نٿي اچي، ڇاڪاڻ ته ڪيترن ئي، تلخ تجربي مان سکڻ کان پوءِ، ٽيگ استعمال ڪرڻ بند ڪري ڇڏيو آهي. :latest ۽ ورجن کي پن ڪرڻ شروع ڪيو. هورا!

اي سي آر تصوير جي ٽيگ کي تبديل نه ٿيڻ جي قابل بڻائي ٿو؛ اسان صلاح ڏيون ٿا ته توهان پاڻ کي هن قابل ذڪر خصوصيت سان واقف ڪرايو.

خلاصو

هر شيءِ جي فوري طور تي ڪم ڪرڻ جي اميد نه رکو: ڪبرنيٽس ڪو علاج ناهي. هڪ خراب ايپليڪيشن ڪبرنيٽس ۾ به ساڳيو رهندو (۽ اهو وڌيڪ خراب ٿي سگهي ٿو). اطمينان غير ضروري پيچيدگي، هڪ سست ۽ بوجھل ڪنٽرول جهاز، ۽ آفت جي بحالي جي حڪمت عملي کان سواءِ رهڻ جو خطرو پيدا ڪندو. ڪبرنيٽس کان اميد نه رکو ته هو آئسوليشن ۽ اعليٰ دستيابي کي دٻي کان ٻاهر سنڀاليندو. پنهنجي ايپليڪيشن کي واقعي ڪلائوڊ-نيٽيو ٺاهڻ ۾ ڪجهه وقت گذاريو.

توهان مختلف ٽيمن جي ناڪام تجربن بابت پڙهي سگهو ٿا ڪهاڻين جو هي مجموعو هيننگ جيڪبز پاران.

ڪو به ماڻهو جيڪو هن مضمون ۾ درج ٿيل غلطين جي فهرست ۾ شامل ڪرڻ چاهي ٿو، اهو اسان سان ٽوئيٽر تي رابطو ڪري سگهي ٿو (@مارڪ بارٽڪ, @MstrsObserver).