ڪبرنيٽس پوڊ وسيلن تائين ڪيئن رسائي حاصل ڪجي

توحيد طرفان انعام

جڏهن ڪبرنيٽس سان شروع ڪندي، اهو عام آهي ته ڪنٽينر وسيلن کي ترتيب ڏيڻ جي باري ۾ وساريو. هن نقطي تي، اهو يقيني بڻائڻ لاء ڪافي آهي ته Docker تصوير ڪم ڪري ٿي ۽ ڪبرنيٽس ڪلستر کي ترتيب ڏئي سگهجي ٿو.

پر بعد ۾ ايپليڪيشن کي ٻين ايپليڪيشنن سان گڏ پيداوار جي ڪلستر ۾ ترتيب ڏيڻ جي ضرورت آهي. هن کي ڪرڻ لاءِ، توهان کي ڪنٽينر لاءِ وسيلا مختص ڪرڻا پوندا ۽ پڪ ڪرڻ جي ضرورت آهي ته انهن مان ڪافي آهن ايپليڪيشن کي حاصل ڪرڻ ۽ هلائڻ لاءِ، ۽ ٻيون هلندڙ ايپليڪيشنن کي مسئلن جو تجربو نه ٿيندو.

ٽيم Mail.ru کان Kubernetes aaS ڪنٽينر وسيلن (سي پي يو ۽ ايم اي ايم)، درخواستون ۽ وسيلن جي حدن بابت هڪ مضمون ترجمو ڪيو. توهان انهن سيٽنگن جا فائدا سکندا ۽ جيڪڏهن توهان انهن کي سيٽ نه ڪيو ته ڇا ٿيندو.

ڪمپيوٽنگ وسيلن

اسان وٽ ٻن قسمن جا وسيلا آھن جن وٽ ھيٺيون يونٽ آھن:

• مرڪزي پروسيسنگ يونٽ (سي پي يو) - ڪور؛
• ياداشت (MEM) - بائيٽ.

هر ڪنٽينر لاءِ وسيلا بيان ڪيا ويا آهن. ھيٺ ڏنل پوڊ YAML فائل ۾، توھان ڏسندا ھڪڙو وسيلا سيڪشن جنھن ۾ درخواست ٿيل ۽ محدود وسيلن تي مشتمل آھي.

• درخواست ٿيل پوڊ وسيلا = سڀني ڪنٽينرز جي درخواست ڪيل وسيلن جو مجموعو؛
• پوڊ وسيلن جي حد = سڀني پوڊ وسيلن جي حدن جو مجموعو.

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod-name
  labels:
    application: backend
spec:
  containers:
    — name: main-container
      image: my-backend
      tag: v1
      ports:
      — containerPort: 8080
      resources:
        requests:
          cpu: 0.2 # REQUESTED CPU: 200m cores
          memory: "1Gi" # REQUESTED MEM: 1Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi
    — name: other-container
      image: other-app
      tag: v1
      ports:
      — containerPort: 8000
      resources:
        requests:
          cpu: "200m" # REQUESTED CPU: 200m cores
          memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi

درخواست ڪيل ۽ محدود وسيلن جو مثال

ميدان resources.requested وضاحتن مان پوڊ ھڪڙو عنصر آھي جيڪو مطلوب نوڊ ڳولڻ لاء استعمال ڪيو ويندو آھي. توھان اڳ ۾ ئي پلان ڪري سگھو ٿا پوڊ جي ٺاھ جوڙ لاءِ. توهان هڪ مناسب نوڊ ڪيئن ڳوليندا آهيو؟

Kubernetes ڪيترن ئي حصن تي مشتمل آهي، جنهن ۾ ماسٽر نوڊ يا ماسٽر نوڊ (Kubernetes ڪنٽرول جهاز). ماسٽر نوڊ ۾ ڪيترائي عمل آھن: kube-apiserver، kube-controller-manager ۽ kube-scheduler.

ڪوبي شيڊيولر عمل نئين ٺاهيل پوڊس جو جائزو وٺڻ ۽ ممڪن ڪم ڪندڙ نوڊس ڳولڻ جو ذميوار آهي جيڪي سڀني پوڊ درخواستن سان ملن ٿا، بشمول درخواست ڪيل وسيلن جو تعداد. kube-scheduler پاران مليل نوڊس جي فهرست درجه بندي ڪئي وئي آهي. پوڊ نوڊ تي مقرر ڪيو ويو آهي بلند ترين اسڪور سان.

جامني پوڊ ڪٿي رکيو ويندو؟

تصوير ۾ توهان ڏسي سگهو ٿا ته ڪوبي شيڊولر کي نئين جامني پوڊ کي شيڊول ڪرڻ گهرجي. ڪبرنيٽس ڪلسٽر ٻن نوڊس تي مشتمل آهي: A ۽ B. جيئن توهان ڏسي سگهو ٿا، ڪوبي شيڊيولر هڪ پوڊ کي نوڊ A تي شيڊول نٿو ڪري سگهي - موجود (غير درخواست ٿيل) وسيلا جامني پوڊ جي درخواستن سان نه ٿا ملن. تنهن ڪري، ميموري جي 1 GB جي درخواست ڪئي وئي جامني پوڊ پاران نوڊ اي تي مناسب نه هوندي، ڇو ته دستياب ميموري 0,5 GB آهي. پر نوڊ بي وٽ ڪافي وسيلا آهن. نتيجي طور، kube-scheduler فيصلو ڪري ٿو ته جامني پوڊ جي منزل نوڊ B آهي.

ھاڻي اسان ڄاڻون ٿا ته درخواست ڪيل وسيلا پوڊ کي هلائڻ لاء نوڊ جي چونڊ کي ڪيئن متاثر ڪن ٿا. پر حدن جي وسيلن جو اثر ڇا آهي؟

وسيلن جي حد هڪ حد آهي جنهن کي CPU/MEM پار نٿو ڪري سگهي. بهرحال، سي پي يو وسيلو لچڪدار آهي، تنهن ڪري ڪنٽينر جيڪي پنهنجي سي پي يو جي حدن تائين پهچي ويندا آهن پوڊ کي نڪرڻ جو سبب نه هوندا. ان جي بدران، سي پي يو جي ٺهڻ شروع ٿيندي. جيڪڏهن MEM استعمال جي حد تائين پهچي وڃي ٿي، ڪنٽينر کي OOM-Killer جي ڪري روڪيو ويندو ۽ ٻيهر شروع ڪيو ويندو جيڪڏهن RestartPolicy سيٽنگ جي اجازت ڏني وڃي.

درخواست ڪئي ۽ وڌ ۾ وڌ وسيلن جي تفصيل ۾

Docker ۽ Kubernetes جي وچ ۾ وسيلن جي رابطي

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

ياداشت: درخواست ۽ حد

containers:
...
 resources:
   requests:
     memory: "0.5Gi"
   limits:
     memory: "1Gi"

جيئن مٿي ذڪر ڪيو ويو آهي، ياداشت بائيٽ ۾ ماپي ويندي آهي. تي مبني Kubernetes دستاويز، اسان ميموري کي نمبر طور بيان ڪري سگھون ٿا. عام طور تي اهو هڪ عدد آهي، مثال طور 2678 - يعني 2678 بائيٽ. توھان پڻ استعمال ڪري سگھوٿا suffixes G и Gi، بنيادي شيء ياد رکڻ آهي ته اهي برابر نه آهن. پهريون آهي ڊيسيمل ۽ ٻيو آهي بائنري. k8s دستاويزن ۾ ذڪر ڪيل مثال وانگر: 128974848, 129e6, 129M, 123Mi - اهي عملي طور تي برابر آهن.

Kubernetes اختيار limits.memory پرچم سان مطابقت --memory Docker کان. جي صورت ۾ request.memory Docker لاءِ ڪوبه تير نه آهي ڇاڪاڻ ته Docker هن فيلڊ کي استعمال نٿو ڪري. توھان پڇي سگھو ٿا، ڇا اھو ضروري آھي؟ ها ضرورت آهي. جيئن مون اڳ ۾ چيو، فيلڊ جي اهميت ڪبرنيٽس لاءِ. ان مان معلومات جي بنياد تي، ڪوب-شيڊيولر فيصلو ڪري ٿو ته ڪهڙي نوڊ تي پوڊ کي شيڊول ڪيو وڃي.

ڇا ٿيندو جيڪڏهن توهان درخواست لاءِ ڪافي ميموري مقرر نه ڪيو؟

جيڪڏهن ڪنٽينر گهربل ميموري جي حد تائين پهچي ويو آهي، ته پوڊ پوڊ جي هڪ گروپ ۾ رکيل آهي جيڪو بند ٿي وڃي ٿو جڏهن نوڊ ۾ ڪافي ياداشت نه آهي.

ڇا ٿيندو جيڪڏھن توھان ميموري جي حد تمام گھٽ سيٽ ڪريو؟

جيڪڏهن ڪنٽينر ميموري جي حد کان وڌي ٿو، ته اهو OOM-Killed جي ڪري ختم ڪيو ويندو. ۽ جيڪڏهن ممڪن هجي ته ٻيهر شروع ٿيندو RestartPolicy جي بنياد تي جتي ڊفالٽ قيمت آهي Always.

ڇا ٿيندو جيڪڏهن توهان درخواست ڪيل ياداشت جي وضاحت نه ڪندا آهيو؟

Kubernetes حد جي قيمت وٺي ويندي ۽ ان کي ڊفالٽ قيمت طور مقرر ڪندو.

ڇا ٿي سگھي ٿو جيڪڏھن توھان ميموري جي حد مقرر نه ڪريو؟

ڪنٽينر تي ڪا به پابندي ناهي؛ اهو استعمال ڪري سگهي ٿو جيترو ميموري اهو چاهي ٿو. جيڪڏهن هو نوڊ جي سڀني موجود ميموري کي استعمال ڪرڻ شروع ڪري ٿو، ته پوءِ OOM کيس ماريندو. ڪنٽينر وري شروع ڪيو ويندو جيڪڏهن ممڪن هجي ته RestartPolicy جي بنياد تي.

ڇا ٿيندو جيڪڏهن توهان ميموري جي حدن جي وضاحت نه ڪندا آهيو؟

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

جيڪڏهن گهربل ميموري نوڊ کان وڌيڪ آهي پيش ڪري سگھي ٿي، پوڊ شيڊول نه ڪيو ويندو. اهو ياد رکڻ ضروري آهي Requests.memory - گھٽ ۾ گھٽ قدر نه. هي ميموري جي مقدار جو بيان آهي ته ڪنٽينر کي مسلسل هلائڻ لاءِ ڪافي آهي.

اهو عام طور تي ساڳئي قدر مقرر ڪرڻ جي صلاح ڏني وئي آهي request.memory и limit.memory. اهو يقيني بڻائي ٿو ته ڪبرنيٽس هڪ نوڊ تي پوڊ شيڊول نه ڪندو جنهن ۾ پوڊ کي هلائڻ لاءِ ڪافي ياداشت آهي پر ان کي هلائڻ لاءِ ڪافي ناهي. ذهن ۾ رکو: ڪبرنيٽس پوڊ پلاننگ صرف اڪائونٽ ۾ وٺندو آهي requests.memory۽ limits.memory حساب ۾ نه رکندو آھي.

سي پي يو: درخواست ۽ حد

containers:
...
 resources:
   requests:
     cpu: 1
   limits:
     cpu: "1200m"

هڪ سي پي يو سان هر شي ٿورو وڌيڪ پيچيده آهي. Kubernetes ۽ Docker جي وچ ۾ تعلق جي تصوير ڏانهن موٽڻ، توهان ڏسي سگهو ٿا ته request.cpu соответствует --cpu-shares، جڏهن ته limit.cpu پرچم سان مطابقت cpus Docker ۾.

سي پي يو جنهن کي ڪبرنيٽس درخواست ڪري ٿو 1024 سان ضرب ڪيو ويو آهي، سي پي يو چڪر جو تناسب. جيڪڏهن توهان 1 مڪمل ڪور جي درخواست ڪرڻ چاهيو ٿا، توهان کي شامل ڪرڻ گهرجي cpu: 1جيئن مٿي ڏيکاريل آهي.

مڪمل ڪنٽينل جي درخواست ڪرڻ (تناسب = 1024) جو مطلب اهو ناهي ته توهان جو ڪنٽينر اهو وصول ڪندو. جيڪڏهن توهان جي ميزبان مشين ۾ صرف هڪ ڪور آهي ۽ توهان هڪ کان وڌيڪ ڪنٽينر هلائي رهيا آهيو، پوء سڀني ڪنٽينرز کي انهن جي وچ ۾ موجود سي پي يو کي حصيداري ڪرڻ گهرجي. اهو ڪيئن ٿو ٿئي؟ اچو ته تصوير کي ڏسو.

سي پي يو درخواست - سنگل ڪور سسٽم

اچو ته تصور ڪريو ته توهان وٽ هڪ واحد-ڪور ميزبان سسٽم هلندڙ ڪنٽينرز آهي. مام (Kubernetes) هڪ پائي (سي پي يو) کي پڪڙيو ۽ ان کي ٻارن جي وچ ۾ ورهائڻ چاهي ٿو (ڪنٽينرز). ٽي ٻار هڪ پوري پائي چاهين ٿا (تناسب = 1024)، ٻيو ٻار اڌ پائي چاهي ٿو (512). ماء منصفانه ٿيڻ چاهي ٿي ۽ هڪ سادي حساب ڪري ٿو.

# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%

ڳڻپيوڪر جي بنياد تي، ٽن ٻارن کي ملندو 28٪ ڪور جو، ۽ نه سڄي ڪور. چوٿين ٻار کي پوري داڻي جو 14 سيڪڙو ملندو، اڌ نه. پر شيون مختلف هونديون جيڪڏهن توهان وٽ ملٽي ڪور سسٽم آهي.

سي پي يو جي درخواست - ملٽي-ڪور (4) سسٽم

مٿي ڏنل تصوير ۾ توهان ڏسي سگهو ٿا ته ٽي ٻار هڪ پوري پائي چاهين ٿا، ۽ هڪ اڌ چاهي ٿو. جيئن ته ماءُ چار پياز پکايا آهن، انهن مان هر هڪ ٻار کي ملي ويندا جيترو اهي چاهيندا. هڪ ملٽي-ڪور سسٽم ۾، پروسيسر وسيلن کي سڀني موجود پروسيسر ڪور ۾ ورهايو ويو آهي. جيڪڏهن هڪ ڪنٽينر هڪ مڪمل سي پي يو ڪور کان گهٽ تائين محدود آهي، اهو اڃا تائين ان کي استعمال ڪري سگهي ٿو 100٪.

مٿين حسابن کي سمجھڻ لاءِ آسان ڪيو ويو آھي ته ڪيئن CPU ڪنٽينرز ۾ ورهائجي. يقينن، پاڻ ڪنٽينرز کان علاوه، ٻيا عمل آهن جيڪي سي پي يو وسيلن کي پڻ استعمال ڪن ٿا. جڏهن هڪ ڪنٽينر ۾ عمل بيڪار آهن، ٻيا ان جي وسيلن کي استعمال ڪري سگهن ٿا. CPU: "200m" соответствует CPU: 0,2، جنهن جو مطلب آهي تقريبن 20٪ هڪ ڪور جو.

هاڻي اچو ته بابت ڳالهايون limit.cpu. CPU جنهن کي ڪبرنيٽس جي حدن کي 100 سان ضرب ڪيو ويو آهي. نتيجو اهو آهي ته وقت جو مقدار جيڪو ڪنٽينر هر 100 µs استعمال ڪري سگهي ٿو (cpu-period).

limit.cpu Docker پرچم سان ملندو آهي --cpus. هي پراڻي جو هڪ نئون ميلاپ آهي --cpu-period и --cpu-quota. ان کي ترتيب ڏيڻ سان، اسان ظاھر ڪريون ٿا ته سي پي يو جا ڪيترا وسيلا موجود آھن ڪنٽينر وڌ کان وڌ استعمال ڪري سگھن ٿا ان کان اڳ جو ٺاھڻ شروع ٿئي:

• سيپس - ميلاپ cpu-period и cpu-quota. cpus = 1.5 ترتيب ڏيڻ جي برابر cpu-period = 100000 и cpu-quota = 150000;
• CPU-مدت - مدت CPU CFS شيڊولر, ڊفالٽ 100 microseconds؛
• cpu- ڪوٽا - اندر microseconds جو تعداد cpu-period، جيڪو ڪنٽينر سان جڙيل آهي.

ڇا ٿيندو جيڪڏهن توهان اڻ گهربل CPU انسٽال ڪيو؟

جيڪڏهن ڪنٽينر کي ان کان وڌيڪ ضرورت آهي ته ان کي نصب ڪيو ويو آهي، اهو ٻين پروسيس کان سي پي يو چوري ڪندو.

ڇا ٿيندو جيڪڏھن توھان سيٽ ڪيو سي پي يو جي حد تمام گھٽ؟

جيئن ته سي پي يو وسيلن کي ترتيب ڏيڻ وارو آهي، throttling تي ڦيرايو ويندو.

ڇا ٿيندو جيڪڏهن توهان CPU جي درخواست جي وضاحت نه ڪندا آهيو؟

جيئن ياداشت سان، درخواست جي قيمت حد جي برابر آهي.

ڇا ٿيندو جيڪڏهن توهان سي پي يو جي حد مقرر نه ڪندا آهيو؟

ڪنٽينر جيترو CPU استعمال ڪندو جيترو ان کي ضرورت آھي. جيڪڏهن هڪ ڊفالٽ سي پي يو پاليسي (LimitRange) نالي جي جڳهه ۾ وضاحت ڪئي وئي آهي، پوء اها حد ڪنٽينر لاء پڻ استعمال ڪئي ويندي آهي.

ڇا ٿيندو جيڪڏهن توهان يا ته درخواست يا سي پي يو جي حد بيان نه ڪندا آهيو؟

جيئن ياداشت سان، هي بدترين صورت حال آهي. شيڊولر کي خبر ناهي ته توهان جي ڪنٽينر کي ڪيترا وسيلا گهرجن، ۽ اهو نوڊ تي سنگين مسئلا پيدا ڪري سگهي ٿو. ھن کان بچڻ لاءِ، توھان کي نالن جي جڳھن لاءِ ڊفالٽ حد مقرر ڪرڻ جي ضرورت آھي (LimitRange).

ياد رکو: جيڪڏهن توهان نوڊس کان وڌيڪ سي پي يو جي درخواست ڪري سگهو ٿا، پوڊ شيڊول نه ڪيو ويندو. Requests.cpu - گھٽ ۾ گھٽ قيمت نه، پر پوڊ شروع ڪرڻ ۽ ناڪامي کان سواء ڪم ڪرڻ لاء ڪافي قدر. جيڪڏهن ايپليڪيشن پيچيده حسابن کي انجام نه ڏئي، بهترين اختيار انسٽال ڪرڻ آهي request.cpu <= 1 ۽ ضرورت جي مطابق ڪيتريون ئي نقلون لانچ ڪريو.

گهربل وسيلن جي مثالي رقم يا وسيلن جي حد

اسان ڪمپيوٽنگ وسيلن جي حد جي باري ۾ سکيو. هاڻي اهو سوال جو جواب ڏيڻ جو وقت آهي: ”منهنجي پوڊ کي بغير ڪنهن مسئلي جي ايپليڪيشن کي هلائڻ لاءِ ڪيترا وسيلا گهربل آهن؟ مثالي رقم ڇا آهي؟

بدقسمتي سان، انهن سوالن جا واضح جواب نه آهن. جيڪڏهن توهان کي خبر ناهي ته توهان جي ايپليڪيشن ڪيئن ڪم ڪري ٿي يا ان کي ڪيتري سي پي يو يا ميموري جي ضرورت آهي، بهترين اختيار اهو آهي ته ايپليڪيشن کي تمام گهڻي ميموري ۽ سي پي يو ڏيو ۽ پوء پرفارمنس ٽيسٽ کي هلايو.

ڪارڪردگي ٽيسٽ جي اضافي ۾، هڪ هفتي لاء نگراني ۾ ايپليڪيشن جي رويي جي نگراني ڪريو. جيڪڏهن گراف ظاهر ڪن ٿا ته توهان جي ايپليڪيشن توهان جي درخواست کان گهٽ وسيلا استعمال ڪري رهي آهي، توهان درخواست ڪيل CPU يا ميموري جي مقدار کي گهٽائي سگهو ٿا.

مثال طور هي ڏسو گرافانا ڊيش بورڊ. اهو ڏيکاري ٿو درخواست ڪيل وسيلن يا وسيلن جي حد ۽ موجوده وسيلن جي استعمال جي وچ ۾ فرق.

ٿڪل

وسيلن جي درخواست ۽ محدود ڪرڻ توهان جي ڪبرنيٽس ڪلستر کي صحتمند رکڻ ۾ مدد ڪري ٿي. مناسب حد جي ترتيب قيمت گھٽائي ٿي ۽ ايپليڪيشنن کي هر وقت هلائي رهي آهي.

مختصر ۾، ذهن ۾ رکڻ لاء ڪجھ شيون آهن:

1. درخواست ڪيل وسيلا ھڪ ٺاھ ٺاھيندا آھن جيڪي شروع ڪرڻ وقت (جڏھن ڪبرنيٽس ايپليڪيشن کي ميزباني ڪرڻ جو ارادو رکن ٿا) ۾ رکيو ويندو آھي. ان جي ابتڙ، وسيلن کي محدود ڪرڻ ضروري آهي رن ٽائم تي- جڏهن ايپليڪيشن اڳ ۾ ئي نوڊ تي هلي رهي آهي.
2. ميموري جي مقابلي ۾، سي پي يو هڪ منظم وسيلو آهي. جيڪڏهن ڪافي سي پي يو نه آهي، توهان جو پوڊ بند نه ٿيندو ۽ ٺهڪندڙ ميڪانيزم تي ڦيرايو ويندو.
3. گهربل وسيلن ۽ وسيلن جي حد گهٽ ۾ گهٽ ۽ وڌ ۾ وڌ قدر نه آهن! درخواست ڪيل وسيلن جي وضاحت ڪندي، توهان پڪ ڪريو ٿا ته ايپليڪيشن بغير ڪنهن مسئلن جي هلندي.
4. ھڪڙو سٺو عمل آھي ميموري جي درخواست کي ميموري جي حد جي برابر مقرر ڪرڻ.
5. ٺيڪ آهي انسٽال ڪرڻ جي درخواست ڪئي CPU <=1، جيڪڏهن ايپليڪيشن پيچيده حسابن کي انجام نه ڏئي.
6. جيڪڏهن توهان نوڊ تي دستياب کان وڌيڪ وسيلن جي درخواست ڪندا آهيو، پوڊ ڪڏهن به ان نوڊ تي مقرر نه ڪيو ويندو.
7. درخواست ڪيل وسيلن جي صحيح مقدار / وسيلن جي حدن کي طئي ڪرڻ لاء، لوڊ ٽيسٽ ۽ مانيٽرنگ استعمال ڪريو.

مون کي اميد آهي ته هي آرٽيڪل توهان کي وسيلن جي حد جي بنيادي تصور کي سمجهڻ ۾ مدد ڪندو. ۽ توهان هن علم کي پنهنجي ڪم ۾ لاڳو ڪرڻ جي قابل هوندا.

ڪامياب!

ٻيو ڇا پڙهو:

1. SRE مشاهدو: نالا اسپيس ۽ ميٽرڪ ساخت.
2. ڪبرنيٽس لاءِ 90+ مفيد اوزار: مقرري، انتظام، نگراني، سيڪيورٽي ۽ وڌيڪ.
3. اسان جو چينل Around Kubernetes ٽيليگرام ۾.

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