10 عام غلطيون جڏهن ڪبرنيٽس استعمال ڪندي

نوٽ. ترجمو: هن مضمون جا ليکڪ هڪ ننڍڙي چيڪ ڪمپنيءَ جا انجنيئر آهن، pipetail. هنن ڪبرنيٽس ڪلسٽرز جي آپريشن سان لاڳاپيل [ڪڏهن ڪڏهن عام، پر اڃا تائين] تمام ضروري مسئلن ۽ غلط فهمين جي هڪ شاندار فهرست گڏ ڪرڻ جو انتظام ڪيو.

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

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

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

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

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

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

resources: {}

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

   resources:
      Requests:
        cpu: "1m"

ٻئي طرف، سي پي يو جي حد جي موجودگي پوڊز طرفان ڪلاڪ جي چڪر جي غير معقول لڪائڻ جي ڪري سگھي ٿي، جيتوڻيڪ نوڊ پروسيسر مڪمل طور تي لوڊ نه ڪيو ويو آهي. ٻيهر، اهو وڌائي سگھي ٿو دير دير سان. پيرا ميٽر جي چوڌاري تڪرار جاري آهي CPU CFS ڪوٽا لينڪس ڪنيل ۽ سي پي يو ۾ ٺهڪندڙ حدن تي منحصر آهي، انهي سان گڏ CFS ڪوٽا کي غير فعال ڪرڻ ... افسوس، سي پي يو جي حدن کي حل ڪرڻ کان وڌيڪ مسئلا پيدا ڪري سگهي ٿي. ان بابت وڌيڪ معلومات هيٺ ڏنل لنڪ تي ملي سگهي ٿي.

گھڻي چونڊ (زبردست) ياداشت جا مسئلا وڏا مسئلا پيدا ڪري سگھن ٿا. سي پي يو جي حد تائين پهچڻ ۾ گھڙيءَ جي چڪر کي لڪائڻ شامل آهي، جڏهن ته ياداشت جي حد تائين پهچڻ پوڊ کي مارڻ شامل آهي. توهان ڪڏهن مشاهدو ڪيو آهي OOMkill؟ ها، اهو ئي آهي جيڪو اسان بابت ڳالهائي رهيا آهيون.

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

ڦاٽڻ لائق (OOM مارڻ جو وڌيڪ موقعو):

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

تصديق ٿيل:

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

وسيلن کي ترتيب ڏيڻ وقت ڇا ممڪن طور تي مدد ڪندو؟

جي مدد سان ميٽرڪس-سرور توهان ڏسي سگهو ٿا موجوده CPU وسيلن جو استعمال ۽ ميموري استعمال پوڊس (۽ انهن جي اندر ڪنٽينر). گهڻو ڪري، توهان اڳ ۾ ئي استعمال ڪري رهيا آهيو. بس ھيٺ ڏنل حڪمن کي هلائڻ:

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

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

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

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

2. جاندار ۽ تياري جي جاچ

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

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

اهي تجربا اڪثر هڪ ٻئي سان پريشان آهن:

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

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

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

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

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

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

3. هر HTTP خدمت لاءِ لوڊ بيلنس

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

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

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

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

4. هڪ ڪلستر کي خودڪار اسڪيلنگ ان جي خاصيتن کي اڪائونٽ ۾ وٺڻ کان سواء

جڏهن نوڊس کي شامل ڪرڻ ۽ انهن کي ڪلستر مان هٽائڻ، توهان کي ڪجهه بنيادي ميٽرڪ تي ڀروسو نه ڪرڻ گهرجي جهڙوڪ سي پي يو استعمال انهن نوڊس تي. پوڊ جي منصوبه بندي ڪرڻ گهرجي ڪيترن ئي حساب ۾ پابنديون، جهڙوڪ پوڊ/نوڊ لاڳاپو، داغ ۽ رواداري، وسيلن جي درخواست، QoS، وغيره. هڪ خارجي آٽو اسڪيلر استعمال ڪندي جيڪي انهن نونسن کي حساب ۾ نٿا وٺن مسئلا پيدا ڪري سگهن ٿا.

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

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

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

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

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

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

kube2iam جي باري ۾ وساريو ۽ سڌو وڃو IAM رولز لاءِ سروس اڪائونٽس (جيئن بيان ڪيو ويو آهي ساڳئي نالي جو نوٽ Štěpán Vraný):

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جيڪڏهن انهن کي ضرورت ناهي. اهو لاڳو ڪرڻ ٿورو وڌيڪ ڏکيو آهي، خاص طور تي RBAC K8s ۾، پر ضرور ڪوشش جي لائق آهي.

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

تصور ڪريو ته توھان وٽ ھڪڙو نوڊ تي ڪجھ ٺاھڻ جا ٽي نقل آھن. نوڊ پوي ٿو، ۽ ان سان گڏ سڀئي نقل. ناپسنديده صورتحال، صحيح؟ پر ڇو سڀئي نقل ساڳيا نوڊ تي هئا؟ ڇا Kubernetes کي اعلي دستيابي (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 کي نظرانداز ڪرڻ

تصور ڪريو ته توھان وٽ ھڪڙو پيداوار لوڊ آھي Kubernetes ڪلستر تي. وقتي طور تي، نوڊس ۽ ڪلستر پاڻ کي اپڊيٽ ڪيو وڃي ٿو (يا ختم ٿيل). A PodDisruptionBudget (PDB) ڪلستر منتظمين ۽ صارفين جي وچ ۾ خدمت جي ضمانت واري معاهدي وانگر ڪجهه آهي.

PDB توهان کي اجازت ڏئي ٿو ته نوڊس جي کوٽ سبب سروس جي رڪاوٽن کان بچڻ لاءِ:

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

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

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

8. هڪ عام ڪلستر ۾ گهڻن صارفين يا ماحول

Kubernetes نالي جي جڳھ (نالن جي جڳھ) مضبوط موصليت فراهم نه ڪريو.

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

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

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

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

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

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

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

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

10. ڪلستر سان جڙيل نه ٿيو ۽ ڪنٽرول جهاز کي غلط استعمال نه ڪريو

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

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

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

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

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

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

پر اهو اڳ ۾ ئي هڪ کلاسک آهي. تازو اسان هن ٽيڪنڪ کي گهٽ ۾ گهٽ ڏٺو آهي، ڇاڪاڻ ته ڪيترن ئي، تلخ تجربن مان سکي، ٽيگ استعمال ڪرڻ بند ڪري ڇڏيو آهي. :latest ۽ ورجن پنڻ شروع ڪيو. هوري!

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

خلاصو

هر شي کي رات جو ڪم ڪرڻ جي اميد نه رکو: ڪبرنيٽس هڪ علاج نه آهي. خراب ايپ ڪبرنيٽس ۾ به ائين ئي رهندو (۽ اهو شايد خراب ٿي ويندو). لاپرواهيءَ سان ڪنٽرول پرت جي تمام گهڻي پيچيدگي، سست ۽ دٻاءُ وارو ڪم ٿيندو. اضافي طور تي، توهان کي آفت جي بحالي واري حڪمت عملي جي بغير ڇڏي وڃڻ جو خطرو آهي. اميد نه رکو ڪبرنيٽس کي دٻي کان ٻاهر اڪيلائي ۽ اعلي دستيابي فراهم ڪرڻ. ڪجھ وقت گذاريو توھان جي ايپليڪيشن کي واقعي ڪلائوڊ اصلي بڻائڻ.

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

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

پي ايس مترجم کان

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

• «ڊيزائننگ ڪبرنيٽس ڪلستر: ڪيترا هجڻ گهرجن؟"؛
• «ڪبرنيٽس ۾ سيڪيورٽي جو ABC: تصديق، اختيار، آڊيٽنگ"؛
• «Kubernetes ۾ خودڪار اسڪيلنگ ۽ وسيلن جو انتظام"(جائزو ۽ وڊيو رپورٽ)؛
• «Kubernetes ۾ ConfigMaps: nuances بابت ڄاڻڻ جي قابل».

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