نهه کبرنیټس د فعالیت لارښوونې

سلام و ټولو ته! زما نوم Oleg Sidorenkov دی، زه په DomClick کې د زیربناوو د ټیم د مشر په توګه کار کوم. موږ له دریو کلونو څخه ډیر وخت لپاره کوبیک په تولید کې کاروو ، او پدې موده کې موږ د دې سره ډیری مختلف په زړه پوري شیبې تجربه کړې. نن ورځ زه به تاسو ته ووایم چې څنګه، د سمې طریقې سره، تاسو کولی شئ د خپل کلستر لپاره د وینیلا کبرنیټس څخه حتی نور فعالیت وخورئ. چمتو ولاړ ولاړ شه!

تاسو ټول ښه پوهیږئ چې کوبرنیټس د کانټینر آرکیسټریشن لپاره د توزیع وړ خلاصې سرچینې سیسټم دی؛ ښه، یا 5 بائنریونه چې په سرور چاپیریال کې ستاسو د مایکرو خدماتو د ژوند دورې اداره کولو سره جادو کار کوي. سربیره پردې ، دا یو کافي انعطاف وړ وسیله ده چې د مختلف دندو لپاره اعظمي تخصیص لپاره د لیګو په څیر راټول کیدی شي.

او هرڅه سم ښکاري: سرورونه په کلستر کې لکه د لرګیو لرګیو ته اور واچوئ، او تاسو به هیڅ غم ونه پیژنئ. مګر که تاسو د چاپیریال لپاره یاست، نو تاسو به فکر وکړئ: "څنګه کولی شم اور وسوزوم او ځنګل وساتم؟" په بل عبارت، د زیربنا د ښه کولو او لګښتونو کمولو لپاره څنګه لارې چارې ومومئ.

1. د څار ټیم او د غوښتنلیک سرچینې

یو له ډیرو عامو، مګر اغیزمنو میتودونو څخه د غوښتنو / محدودیتونو معرفي کول دي. غوښتنلیکونه د نوم ځایونو او د پرمختیایی ټیمونو لخوا د نوم ځایونو په واسطه تقسیم کړئ. د پلي کولو دمخه ، د پروسیسر وخت ، حافظې او لنډمهاله ذخیره مصرف لپاره د غوښتنلیک ارزښتونه تنظیم کړئ.

resources:
   requests:
     memory: 2Gi
     cpu: 250m
   limits:
     memory: 4Gi
     cpu: 500m

د تجربې له لارې، موږ دې پایلې ته ورسیدو: تاسو باید د حد څخه غوښتنې دوه ځله زیاتې نه کړئ. د کلستر حجم د غوښتنو پراساس محاسبه کیږي، او که تاسو غوښتنلیکونه په سرچینو کې توپیر ورکړئ، د بیلګې په توګه، 5-10 ځله، نو تصور وکړئ چې ستاسو نوډ به څه پیښ شي کله چې دا د پوډونو څخه ډک شي او ناڅاپه بار ترلاسه کړي. هیڅ شی ښه نه دی. په لږ تر لږه، تروتلینګ، او په اعظمي توګه، تاسو به کارګر ته الوداع ووایاست او د پوډونو حرکت پیل کولو وروسته په پاتې نوډونو کې سایکلیک بار ترلاسه کړئ.

برسېره پردې، د مرستې سره limitranges په پیل کې، تاسو کولی شئ د کانټینر لپاره د سرچینو ارزښتونه وټاکئ - لږترلږه، اعظمي او ډیفالټ:

➜  ~ kubectl describe limitranges --namespace ops
Name:       limit-range
Namespace:  ops
Type        Resource           Min   Max   Default Request  Default Limit  Max Limit/Request Ratio
----        --------           ---   ---   ---------------  -------------  -----------------------
Container   cpu                50m   10    100m             100m           2
Container   ephemeral-storage  12Mi  8Gi   128Mi            4Gi            -
Container   memory             64Mi  40Gi  128Mi            128Mi          2

د نوم ځای سرچینې محدودول مه هیروئ ترڅو یو ټیم نشي کولی د کلستر ټولې سرچینې په غاړه واخلي:

➜  ~ kubectl describe resourcequotas --namespace ops
Name:                   resource-quota
Namespace:              ops
Resource                Used          Hard
--------                ----          ----
limits.cpu              77250m        80
limits.memory           124814367488  150Gi
pods                    31            45
requests.cpu            53850m        80
requests.memory         75613234944   150Gi
services                26            50
services.loadbalancers  0             0
services.nodeports      0             0

لکه څنګه چې د توضیحاتو څخه لیدل کیدی شي resourcequotas، که چیرې د عملیات ټیم وغواړي پوډونه ځای په ځای کړي چې نور 10 cpu مصرف کړي ، مهالویش به دې ته اجازه ورنکړي او یوه تېروتنه به وکړي:

Error creating: pods "nginx-proxy-9967d8d78-nh4fs" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10

د دې ستونزې د حل لپاره، تاسو کولی شئ یوه وسیله ولیکئ، د بیلګې په توګه، لکه دا، د قوماندې سرچینو حالت ذخیره کولو او ژمن کولو وړ.

2. غوره فایل ذخیره غوره کړئ

دلته زه غواړم د دوامداره حجمونو موضوع او د کوبرنیټس کارګر نوډونو ډیسک فرعي سیسټم باندې اړیکه ونیسم. زه امید لرم چې هیڅوک په تولید کې په HDD کې "کیوب" نه کاروي ، مګر ځینې وختونه منظم SSD نور کافي ندي. موږ له یوې ستونزې سره مخ شو چیرې چې لاګونه د I/O عملیاتو له امله ډیسک وژني ، او ډیری حلونه شتون نلري:

• د لوړ فعالیت SSDs وکاروئ یا NVMe ته لاړشئ (که تاسو خپل هارډویر اداره کړئ).

• د ننوتلو کچه کمه کړئ.

• د پوډونو "سمارټ" توازن وکړئ چې ډیسک جنسي تیري کوي (podAntiAffinity).

پورته سکرین ښیې چې ډیسک ته د nginx-ingress-controller لاندې څه پیښیږي کله چې د لاسرسي_logs لاګنګ فعال شوی وي (~ 12 زره لاګ/sec). دا حالت، البته، کولی شي پدې نوډ کې د ټولو غوښتنلیکونو تخریب لامل شي.

لکه څنګه چې د PV لپاره، افسوس، ما هرڅه هڅه نه ده کړې نظريات دوامداره حجمونه. غوره انتخاب وکاروئ چې تاسو سره مناسب وي. په تاریخي توګه، دا زموږ په هیواد کې پیښ شوي چې د خدماتو یوه کوچنۍ برخه د RWX حجمونو ته اړتیا لري، او ډیر وخت دمخه دوی د دې کار لپاره د NFS ذخیره کارول پیل کړل. ارزانه او ... کافي. البته، هغه او ما خندا وخوړله - تاسو ته برکت درکړو، مګر موږ دا زده کړل، او زما سر نور درد نه کوي. او که امکان ولري، د S3 اعتراض ذخیره ته لاړ شئ.

3. مطلوب انځورونه راټول کړئ

دا غوره ده چې د کانټینر غوره شوي عکسونه وکاروئ ترڅو کبرنیټس وکولی شي دوی ګړندي ترلاسه کړي او په مؤثره توګه یې اجرا کړي. 

اصلاح شوی مطلب دا دی چې انځورونه:

• یوازې یو غوښتنلیک لري یا یوازې یو فعالیت ترسره کوي؛

• په اندازې کې کوچنی، ځکه چې لوی عکسونه په شبکه کې خراب لیږدول کیږي؛

• د روغتیا او چمتووالي پای ټکي لري چې کوبرنیټس ته اجازه ورکوي چې د وخت په وخت کې اقدام وکړي؛

• د کانټینر دوستانه عملیاتي سیسټمونو څخه کار واخلئ (لکه الپین یا CoreOS)، کوم چې د ترتیب کولو غلطیو لپاره ډیر مقاومت لري؛

• د څو مرحلې جوړونه وکاروئ نو تاسو کولی شئ یوازې تالیف شوي غوښتنلیکونه ځای په ځای کړئ او نه ورسره سرچینې.

ډیری وسیلې او خدمات شتون لري چې تاسو ته اجازه درکوي په الوتنه کې عکسونه چیک او غوره کړئ. دا مهمه ده چې دوی تل تازه وساتئ او د خوندیتوب لپاره ازموینه وکړئ. په پایله کې تاسو ترلاسه کوئ:

1. په ټول کلستر کې د شبکې بار کم شوی.

2. د کانټینر د پیل وخت کمول.

3. ستاسو د ټول ډاکر راجسټری کوچنۍ اندازه.

4. د DNS کیچ وکاروئ

که موږ د لوړ بارونو په اړه وغږیږو ، نو د کلسټر DNS سیسټم له تنظیم کولو پرته ژوند خورا خراب دی. په یو وخت کې، د Kubernetes پراختیا کونکو د دوی د کیوب-dns حل ملاتړ کاوه. دا دلته هم پلي شوی و، مګر دا سافټویر په ځانګړې توګه نه و جوړ شوی او د اړتیا وړ فعالیت یې نه دی تولید کړی، که څه هم دا یو ساده کار ښکاري. بیا کورډنز څرګند شو، کوم چې موږ یې بدل کړ او هیڅ غم یې نه درلود؛ دا وروسته په K8s کې د ډیفالټ DNS خدمت شو. په یو وخت کې، موږ د DNS سیسټم ته 40 زره rps ته وده ورکړه، او دا حل هم ناکافي شو. مګر، د خوشبختۍ سره، نوډلوکلډنس بهر راغی، اکا نوډ محلي کیچ، اکا NodeLocal DNSCache.

ولې موږ دا کاروو؟ د لینکس کرنل کې یوه ستونزه شتون لري چې کله د UDP په اړه د کانټریک NAT له لارې ډیری زنګونه وي، د کانټریک جدولونو کې د ننوتلو لپاره د ریس حالت رامینځته کوي ، او د NAT له لارې د ترافیک یوه برخه له لاسه ورکوي (د خدماتو له لارې هر سفر NAT دی). Nodelocaldns دا ستونزه د NAT څخه د خلاصون له لارې حل کوي او د DNS پورته کولو لپاره TCP ته د پیوستون لوړولو سره ، په بیله بیا په سیمه ایزه توګه د اپسټریم DNS پوښتنو کیچ کول (د لنډ 5 ثانیې منفي کیچ په شمول).

5. پوډونه په افقي او عمودي ډول په اتوماتيک ډول اندازه کړئ

ایا تاسو کولی شئ په ډاډ سره ووایاست چې ستاسو ټول مایکرو خدمات د بار دوه څخه تر درې چنده زیاتوالي لپاره چمتو دي؟ څنګه ستاسو غوښتنلیکونو ته سرچینې په سمه توګه تخصیص کړئ؟ د یو څو پوډونو ساتل د کاري بار څخه هاخوا روان کیدی شي بې کاره وي ، مګر د دوی بیرته شا ته ساتل خدمت ته د ترافیک ناڅاپي زیاتوالي څخه د ځنډیدو خطر سره مخ کوي. خدمتونه لکه افقی پوډ آټوسکلر и عمودی پوډ آټوسکلر.

VPA تاسو ته اجازه درکوي په اوتومات ډول په پوډ کې ستاسو د کانټینرونو غوښتنې / محدودیتونه د ریښتیني کارونې پورې اړه لري. دا څنګه ګټور کیدی شي؟ که تاسو پوډونه لرئ چې د یو دلیل لپاره په افقی ډول اندازه نشي کولی (کوم چې په بشپړ ډول د اعتبار وړ ندي)، نو تاسو کولی شئ هڅه وکړئ د دې سرچینو بدلونونه VPA ته وسپارئ. د دې ځانګړتیا د میټریک سرور څخه د تاریخي او اوسني ډیټا پراساس د سپارښتنې سیسټم دی ، نو که تاسو نه غواړئ په اوتومات ډول غوښتنې / حدونه بدل کړئ ، تاسو کولی شئ په ساده ډول د خپلو کانټینرونو لپاره وړاندیز شوي سرچینې وڅارئ او د CPU او خوندي کولو لپاره تنظیمات اصلاح کړئ. په کلستر کې حافظه.

عکس له https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 څخه اخیستل شوی

په کبرنیټس کې مهالویش تل د غوښتنو پراساس وي. هر هغه ارزښت چې تاسو یې هلته وساتئ، مهالویش به د دې پر بنسټ د مناسب نوډ لټون وکړي. د کیوبیلټ لپاره د حدودو ارزښتونو ته اړتیا ده ترڅو پوه شي چې کله پوزه وهل یا وژل کیږي. او څنګه چې یوازینی مهم پیرامیټر د غوښتنو ارزښت دی، VPA به ورسره کار وکړي. هرکله چې تاسو یو غوښتنلیک عمودی اندازه کړئ، تاسو تعریف کړئ چې غوښتنې باید څه وي. بیا به حدود څه وي؟ دا پیرامیټر به هم په تناسب اندازه شي.

د مثال په توګه، دلته د معمول پوډ ترتیبات دي:

resources:
   requests:
     memory: 250Mi
     cpu: 200m
   limits:
     memory: 500Mi
     cpu: 350m

د سپارښتنې انجن ټاکي چې ستاسو غوښتنلیک د سم چلولو لپاره 300m CPU او 500Mi ته اړتیا لري. تاسو به لاندې ترتیبات ترلاسه کړئ:

resources:
   requests:
     memory: 500Mi
     cpu: 300m
   limits:
     memory: 1000Mi
     cpu: 525m

لکه څنګه چې پورته یادونه وشوه، دا متناسب اندازه کول دي چې په منشور کې د غوښتنو/حدود تناسب پراساس دي:

• CPU: 200m → 300m: تناسب 1:1.75؛

• حافظه: 250Mi → 500Mi: تناسب 1:2.

د HPAنو بیا د عملیاتو میکانیزم ډیر شفاف دی. میټریکونه لکه CPU او حافظه د حد څخه تیریږي، او که د ټولو نقلونو اوسط له حد څخه ډیر وي، غوښتنلیک د +1 فرعي لخوا اندازه کیږي تر هغه چې ارزښت د حد څخه ښکته وي یا تر هغه چې د نقلونو اعظمي شمیر ته ورسیږي.

عکس له https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 څخه اخیستل شوی

د معمول میټریکونو لکه CPU او حافظې سربیره ، تاسو کولی شئ د پرومیتیس څخه په خپل دودیز میټریکونو کې حدونه تنظیم کړئ او د دوی سره کار وکړئ که تاسو فکر کوئ چې دا ستاسو د غوښتنلیک اندازه کولو لپاره ترټولو دقیق نښه ده. یوځل چې غوښتنلیک د ټاکل شوي میټریک حد څخه لاندې ثبات ومومي ، HPA به د پوډونو اندازه کول پیل کړي د نقلونو لږترلږه شمیر ته یا تر هغه چې بار ټاکل شوی حد پوره کړي.

6. د نوډ تړاو او د پوډ تړاو په اړه مه هېروئ

ټول نوډونه په ورته هارډویر کې نه چلیږي، او ټول پوډونه اړتیا نلري چې د کمپیوټ-ډېر غوښتنلیکونو چلولو ته اړتیا ولري. Kubernetes تاسو ته اجازه درکوي په کارولو سره د نوډونو او پوډونو تخصص تنظیم کړئ نوډ تړاو и د پوډ تړاو.

که تاسو داسې نوډونه لرئ چې د کمپیوټري ګړندي عملیاتو لپاره مناسب وي ، نو د اعظمي موثریت لپاره دا غوره ده چې غوښتنلیکونه اړونده نوډونو ته وتړئ. د دې کار کولو لپاره nodeSelector د نوډ لیبل سره.

راځئ چې ووایو تاسو دوه نوډونه لرئ: یو ورسره CPUType=HIGHFREQ او یو لوی شمیر ګړندی کورونه ، بل سره MemoryType=HIGHMEMORY ډیر حافظه او ګړندی فعالیت. ترټولو آسانه لاره دا ده چې نوډ ته ځای په ځای کړئ HIGHFREQبرخې ته اضافه کولو سره spec دا انتخاب کونکی:

…
nodeSelector:
	CPUType: HIGHFREQ

د دې کولو لپاره خورا ګران او ځانګړې لاره کارول دي nodeAffinity په ساحه کې affinity د spec. دوه اختیارونه شتون لري:

• requiredDuringSchedulingIgnoredDuringExecution: سخت ترتیب (شیډولر به پوډونه یوازې په ځانګړي نوډونو کې ځای په ځای کړي (او بل چیرې))؛

• preferredDuringSchedulingIgnoredDuringExecution: نرم ترتیب (شیډولر به هڅه وکړي چې ځانګړي نوډونو ته ځای په ځای کړي، او که دا ناکام شي، نو دا به هڅه وکړي چې راتلونکي موجود نوډ ته ځای په ځای کړي).

تاسو کولی شئ د نوډ لیبلونو اداره کولو لپاره یو ځانګړی ترکیب مشخص کړئ ، لکه In, NotIn, Exists, DoesNotExist, Gt او یا Lt. په هرصورت، په یاد ولرئ چې د لیبلونو په اوږد لیست کې پیچلې میتودونه به په نازکو حالاتو کې پریکړه کول ورو کړي. په بل عبارت، دا ساده وساتئ.

لکه څنګه چې پورته یادونه وشوه، Kubernetes تاسو ته اجازه درکوي د اوسني پوډونو تړاو تنظیم کړئ. دا دی، تاسو کولی شئ ډاډ ترلاسه کړئ چې ځینې پوډونه د ورته موجودیت زون کې د نورو پوډونو سره یوځای کار کوي (د بادونو لپاره اړونده) یا نوډونه.

В podAffinity ساحې affinity د spec ورته ساحې شتون لري لکه څنګه چې په قضیه کې nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. یوازینی توپیر دا دی matchExpressions پوډونه به یو نوډ سره وتړي کوم چې دمخه د دې لیبل سره پوډ چلوي.

Kubernetes هم یو ساحه وړاندې کوي podAntiAffinity، کوم چې ، په برعکس ، پوډ د ځانګړي پوډونو سره نوډ سره نه تړل کیږي.

د څرګندونو په اړه nodeAffinity ورته مشوره ورکول کیدی شي: هڅه وکړئ قواعد ساده او منطقي وساتئ، هڅه مه کوئ چې د پوډ مشخصات د پیچلي مقرراتو سره ډیر کړئ. د داسې قاعدې رامینځته کول خورا اسانه دي چې د کلستر شرایطو سره سمون ونلري ، په مهالویش کې غیر ضروري بار رامینځته کوي او ټول فعالیت کموي.

7. داغونه او زغم

د مهالویش اداره کولو لپاره بله لاره شتون لري. که تاسو د سلګونو نوډونو او زرګونو مایکرو خدماتو سره لوی کلستر لرئ، نو دا خورا ستونزمن کار دی چې ځینې پوډونه په ځانګړو نوډونو کې کوربه کولو ته اجازه ورنکړي.

د داغونو میکانیزم - د مخنیوي مقررات - پدې کې مرسته کوي. د مثال په توګه، په ځینو سناریوګانو کې تاسو کولی شئ ځینې نوډونه د پوډونو چلولو څخه منع کړئ. په ځانګړي نوډ کې د رنګ پلي کولو لپاره تاسو اړتیا لرئ اختیار وکاروئ taint په kubectl کې. کلیدي او ارزښت مشخص کړئ او بیا یې په څیر رنګ کړئ NoSchedule او یا NoExecute:

$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoSchedule

دا هم د یادونې وړ ده چې د رنګ میکانیزم د دریو اصلي اغیزو ملاتړ کوي: NoSchedule, NoExecute и PreferNoSchedule.

• NoSchedule پدې معنی چې د اوس لپاره به د پوډ توضیحاتو کې ورته ننوتل شتون ونلري tolerations، دا به د دې وړتیا ونلري چې په نوډ کې ځای په ځای شي (په دې مثال کې node10).

• PreferNoSchedule - ساده نسخه NoSchedule. پدې حالت کې ، مهالویش کونکی به هڅه وکړي چې هغه پوډونه تخصیص نه کړي چې د ورته ننوتلو سره ندي tolerations فی نوډ، مګر دا یو سخت محدودیت ندی. که چیرې په کلستر کې سرچینې شتون ونلري، نو پوډونه به په دې نوډ کې ځای پرځای کول پیل کړي.

• NoExecute - دا اغیزه د پوډونو سمدستي ایستل هڅوي چې ورته ننوتل نه لري tolerations.

په زړه پورې، دا چلند د زغم میکانیزم په کارولو سره لغوه کیدی شي. دا مناسب دی کله چې د "منع شوي" نوډ شتون ولري او تاسو اړتیا لرئ یوازې زیربنا خدمات ځای په ځای کړئ. دا څنګه وکړو؟ یوازې هغه پوډرو ته اجازه ورکړئ چې مناسب زغم ولري.

دلته هغه څه دي چې د پوډ مشخصات به ورته ښکاري:

spec:
   tolerations:
     - key: "node-role.kubernetes.io/ingress"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"

دا پدې معنی ندي چې راتلونکی بیا ځای په ځای کول به پدې ځانګړي نوډ باندې راشي ، دا د نوډ تړاو میکانیزم ندی او nodeSelector. مګر د ډیری ځانګړتیاو په یوځای کولو سره، تاسو کولی شئ خورا انعطاف منونکي مهالویش تنظیمات ترلاسه کړئ.

8. د پوډ ځای پرځای کولو لومړیتوب ټاکئ

یوازې د دې لپاره چې تاسو نوډونو ته پوډونه ګمارلي دا پدې معنی ندي چې ټول پوډونه باید د ورته لومړیتوب سره چلند وشي. د مثال په توګه، تاسو ممکن د نورو څخه مخکې ځینې پوډونه ځای په ځای کړئ.

Kubernetes د پوډ لومړیتوب او پریمپشن تنظیم کولو مختلفې لارې وړاندې کوي. ترتیب له څو برخو څخه جوړ دی: اعتراض PriorityClass او د ساحې توضیحات priorityClassName د پوډ مشخصاتو کې. راځئ چې یو مثال وګورو:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 99999
globalDefault: false
description: "This priority class should be used for very important pods only"

موږ جوړوو PriorityClassدا نوم، توضیح او ارزښت ورکړئ. لوړ value، هرڅومره لوړ لومړیتوب لري. ارزښت کیدای شي د 32-bit انټیجر له 1 څخه کم یا مساوي وي. لوړ ارزښتونه د ماموریت مهم سیسټم پوډونو لپاره ساتل شوي چې عموما د مخه نشي نیول کیدی. بې ځایه کیدنه به یوازې هغه وخت پیښ شي چې د لوړ لومړیتوب پوډ د شاوخوا ګرځیدو لپاره ځای ونلري، نو ځینې پوډونه به د یو ځانګړي نوډ څخه ویستل شي. که دا میکانیزم ستاسو لپاره خورا سخت وي، تاسو کولی شئ اختیار اضافه کړئ preemptionPolicy: Never، او بیا به هیڅ ډول مخنیوی شتون ونلري ، پوډ به لومړی په کتار کې ودریږي او مهالویش کونکي ته به انتظار وکړي ترڅو د دې لپاره وړیا سرچینې ومومي.

بیا، موږ یو پوډ جوړوو په کوم کې چې موږ نوم په ګوته کوو priorityClassName:

apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    role: myrole
 spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
  priorityClassName: high-priority
          

تاسو کولی شئ هرڅومره چې تاسو غواړئ د لومړیتوب ټولګي رامینځته کړئ، که څه هم دا سپارښتنه کیږي چې له دې سره مخ نه شئ (ووایه، خپل ځان ټیټ، متوسط ​​​​او لوړ لومړیتوب ته محدود کړئ).

په دې توګه، که اړتیا وي، تاسو کولی شئ د مهمو خدماتو ګمارلو موثریت زیات کړئ لکه nginx-ingress-controller، coredns، او نور.

9. د ETCD کلستر اصلاح کړئ

ETCD د ټول کلستر دماغ بلل کیدی شي. د دې ډیټابیس عملیات په لوړه کچه ساتل خورا مهم دي، ځکه چې په کیوب کې د عملیاتو سرعت پدې پورې اړه لري. یو کافي معیاري ، او په ورته وخت کې ، ښه حل به دا وي چې د ETCD کلسټر په ماسټر نوډونو کې وساتئ ترڅو د کیوب اپیسرور ته لږترلږه ځنډ ولرئ. که تاسو دا نشئ کولی، نو د ګډون کوونکو ترمنځ د ښه بینډ ویت سره، د امکان تر حده ETCD ځای ونیسئ. دا هم په پام کې ونیسئ چې د ETCD څخه څومره نوډونه کلستر ته زیان رسولو پرته راوتلی شي

په یاد ولرئ چې په کلستر کې د غړو شمیر په پراخه کچه زیاتوالی کولی شي د فعالیت په لګښت کې د غلطی زغم زیات کړي، هرڅه باید په اعتدال کې وي.

که موږ د خدماتو د تنظیم کولو په اړه وغږیږو، یو څو سپارښتنې شتون لري:

1. د کلستر اندازې پراساس ښه هارډویر ولرئ (تاسو لوستلی شئ دلته).

2. یو څو پیرامیټونه ټیک کړئ که تاسو د یوې جوړې DCs یا ستاسو شبکې ترمینځ کلستر خپور کړی وي او ډیسکونه ډیر څه پریږدي ترڅو مطلوب وي (تاسو لوستلی شئ دلته).

پایلې

دا مقاله هغه ټکي بیانوي چې زموږ ټیم یې د تعقیب هڅه کوي. دا د عملونو ګام په ګام توضیحات ندي، مګر هغه اختیارونه چې ممکن د کلستر سر د اصلاح کولو لپاره ګټور وي. دا روښانه ده چې هر کلستر په خپله طریقه ځانګړی دی، او د ترتیب کولو حلونه خورا توپیر کولی شي، نو دا به په زړه پورې وي چې ستاسو فیډبیک ترلاسه کړئ چې تاسو څنګه خپل د کوبرنیټس کلستر څارنه کوئ او څنګه تاسو د هغې فعالیت ښه کوئ. خپل تجربه په نظرونو کې شریک کړئ، دا به په زړه پورې وي چې پوه شي.

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