🥇Kubernetes-ийн гүйцэтгэлийг сайжруулах есөн зөвлөгөө

Сайн уу! Намайг Олег Сидоренков гэдэг, би DomClick-д дэд бүтцийн багийн ахлагчаар ажилладаг. Бид Cube-г худалдаанд ашиглаад гурван жил гаруй болж байгаа бөгөөд энэ хугацаанд бид түүнтэй хамт олон янзын сонирхолтой мөчүүдийг туулсан. Өнөөдөр би танд зөв хандлагын тусламжтайгаар кластерт зориулж ванилийн Кубернетесээс илүү их гүйцэтгэлийг хэрхэн яаж шахаж болохыг хэлэх болно. Тогтвортой явахад бэлэн!

Kubernetes бол контейнер зохион байгуулахад зориулагдсан өргөтгөх боломжтой нээлттэй эхийн систем гэдгийг та бүгд сайн мэднэ; сайн, эсвэл серверийн орчинд таны микро үйлчилгээний амьдралын мөчлөгийг удирдах замаар ид шид хийдэг 5 хоёртын файлууд. Нэмж дурдахад энэ нь янз бүрийн даалгавруудыг хамгийн дээд хэмжээнд тохируулахын тулд Lego бүтээгч шиг угсарч болох нэлээд уян хатан хэрэгсэл юм.

Бүх зүйл зүгээр юм шиг байна: серверүүдээ галын хайрцаг руу түлээ шиг хий, уй гашууг бүү мэд. Гэхдээ хэрэв та байгаль орчны төлөө хүн бол "Би яаж зууханд гал асааж, ойдоо харамсах вэ?" гэж бодох болно. Өөрөөр хэлбэл, дэд бүтцийг сайжруулах, зардлаа бууруулах арга замыг хэрхэн олох вэ.

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, хэрэв ops команд нь өөр 10 cpu ашиглах pods суулгахыг хүсвэл төлөвлөгч үүнийг хийхийг зөвшөөрөхгүй бөгөөд алдаа гаргана:

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. Хамгийн сайн файл хадгалах газрыг сонго

Энд би байнгын эзлэхүүний сэдэв болон Kubernetes ажилчны зангилааны дискний дэд системийн талаар хөндөхийг хүсч байна. Үйлдвэрлэлд HDD дээр "Cube" -ийг хэн ч ашигладаггүй гэж би найдаж байна, гэхдээ заримдаа ердийн SSD ч хангалттай биш байдаг. Бид ийм асуудалтай тулгарсан тул логууд нь оролт / гаралтын үйлдлээр дискийг устгаж байсан бөгөөд энд тийм ч олон шийдэл байхгүй байна:

Өндөр хүчин чадалтай SSD ашиглах эсвэл NVMe руу шилжих (хэрэв та өөрийн техник хангамжийг удирдаж байгаа бол).
Бүртгэлийн түвшинг бууруулах.
Дискийг гэмтээдэг хонхорцог "ухаалаг" тэнцвэржүүлээрэй (podAntiAffinity).

Дээрх дэлгэцийн агшинд access_logs идэвхжсэн үед диск бүхий nginx-ingress-controller-д юу болдгийг харуулж байна (~12k logs/sc). Ийм төлөв нь мэдээжийн хэрэг, энэ зангилаа дээрх бүх програмуудын доройтолд хүргэж болзошгүй юм.

PV-ийн хувьд харамсалтай нь би бүгдийг туршиж үзээгүй. төрлийн Байнгын хэмжээ. Өөрт тохирсон хамгийн сайн сонголтыг ашигла. Манай улсад үйлчилгээний багахан хэсэг нь RWX-ийн эзлэхүүнийг шаарддаг түүхтэй бөгөөд эртнээс тэд NFS санах ойг энэ ажилд ашиглаж эхэлсэн. Хямдхан бас ... хангалттай. Мэдээжийн хэрэг, бид түүнтэй хамт баас идсэн - эрүүл байгаарай, гэхдээ бид түүнийг хэрхэн тааруулж сурсан, толгой нь өвдөхөө больсон. Боломжтой бол S3 объектын санах ой руу шилжинэ үү.

3. Оновчтой зураг бүтээх

Кубернетес тэдгээрийг илүү хурдан татаж, илүү үр дүнтэй гүйцэтгэхийн тулд контейнерийг оновчтой болгосон зургуудыг ашиглах нь хамгийн сайн арга юм.

Оновчлол гэдэг нь зураг гэсэн үг:

зөвхөн нэг програмыг агуулсан эсвэл зөвхөн нэг функцийг гүйцэтгэх;
жижиг хэмжээтэй, учир нь том зургууд нь сүлжээгээр илүү муу дамжуулагддаг;
Кубернетес сул зогсолтын үед арга хэмжээ авахад ашиглаж болох эрүүл мэнд, бэлэн байдлын эцсийн цэгүүдтэй байх;
тохиргооны алдаанд илүү тэсвэртэй, контейнерт ээлтэй үйлдлийн системийг (Alpine эсвэл CoreOS гэх мэт) ашиглах;
Олон үе шаттай бүтээцийг ашигласнаар та зөвхөн эмхэтгэсэн програмуудыг ашиглах боломжтой болохоос дагалдах эх сурвалжийг ашиглахгүй.

Зургийг шууд шалгаж, оновчтой болгох олон хэрэгсэл, үйлчилгээ байдаг. Тэдгээрийг байнга шинэчилж, аюулгүй байлгах нь чухал юм. Үүний үр дүнд та дараахь зүйлийг авна.

Бүх кластер дээрх сүлжээний ачааллыг бууруулсан.
Савыг эхлүүлэх хугацаа багассан.
Таны бүх Docker бүртгэлийн жижиг хэмжээтэй.

4. DNS кэш ашиглах

Хэрэв бид өндөр ачааллын талаар ярих юм бол кластерын DNS системийг тохируулахгүйгээр амьдрал үнэхээр муухай юм. Нэгэн цагт Kubernetes-ийн хөгжүүлэгчид kube-dns шийдлийг дэмжиж байсан. Энэ нь манай улсад хэрэгжсэн боловч энэ програм хангамж нь тийм ч сайн тааруулж чадаагүй бөгөөд шаардлагатай гүйцэтгэлийг өгөөгүй боловч даалгавар нь энгийн мэт санагдаж байна. Дараа нь бид уй гашууг мэддэггүй coredns гарч ирсэн бөгөөд хожим нь K8s-ийн анхдагч DNS үйлчилгээ болсон. Хэзээ нэгэн цагт бид DNS системд 40 мянган rps хүртэл өссөн бөгөөд энэ шийдэл нь бас хангалтгүй байв. Гэвч азтай тохиолдлоор Nodelocaldns гарч ирэв, aka node local cache, aka NodeLocal DNSCache.

Бид яагаад үүнийг ашиглаж байна вэ? Линуксийн цөмд алдаа байгаа бөгөөд NAT холболтоор UDP-ээр олон удаа хандалт хийснээр холболтын хүснэгтүүд рүү бичих уралдааны нөхцөл үүсч, NAT-аар дамжих урсгалын нэг хэсэг алга болдог (Үйлчилгээгээр дамжих аялал бүр NAT). Nodelocaldns нь NAT-аас салж, TCP холболтыг дээд урсгалын DNS болгон сайжруулж, мөн дээд урсгалын DNS асуулгад (5 секундын богино сөрөг кэшийг оруулаад) кэш хийх замаар энэ асуудлыг шийддэг.

5. Будлагуудыг хэвтээ болон босоо байдлаар автоматаар масштаблана

Таны бүх бичил үйлчилгээ ачааллыг XNUMX-XNUMX дахин нэмэгдүүлэхэд бэлэн байна гэж та итгэлтэйгээр хэлж чадах уу? Програмдаа нөөцийг хэрхэн зөв хуваарилах вэ? Ажлын ачааллаас хэтэрсэн хэд хэдэн хонхорцог ажиллуулах нь илүүц байж болох бөгөөд ар араас нь байлгах нь үйлчилгээ рүү чиглэсэн урсгал гэнэт нэмэгдэхээс болж зогсолт хийх эрсдэлтэй. Алтан дундаж нь үйлчилгээ зэрэг үржүүлэх шившлэгт хүрэхэд тусалдаг Хэвтээ pod Autoscaler и Босоо Pod Autoscaler.

VPA Бодит хэрэглээнд үндэслэн савны хүсэлт/хязгаарыг автоматаар нэмэгдүүлэх боломжийг танд олгоно. Энэ нь яаж ашигтай байж болох вэ? Хэрэв танд ямар нэг шалтгаанаар хэвтээ байдлаар томруулах боломжгүй (энэ нь бүрэн найдвартай биш) Pods байгаа бол та VPA-д итгэж нөөцийг нь өөрчлөхийг оролдож болно. Үүний онцлог нь метрик серверийн түүхэн болон одоогийн өгөгдөлд суурилсан зөвлөмжийн систем тул хэрэв та хүсэлт/хязгаарыг автоматаар өөрчлөхийг хүсэхгүй байгаа бол та өөрийн контейнерт санал болгож буй нөөцүүдийг хянаж, CPU болон санах ойг хэмнэх тохиргоог оновчтой болгох боломжтой. кластерт.

Зургийг https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231-ээс авсан

Кубернетес дэх төлөвлөгч нь үргэлж хүсэлт дээр суурилдаг. Тэнд та ямар ч үнэ цэнийг тавьсан бай, хуваарь гаргагч түүн дээр тулгуурлан тохирох цэгийг хайж олох болно. Хязгаарын утга нь хонхорцог хэзээ дарах эсвэл алахыг мэдэхийн тулд kublet-д хэрэгтэй. Цорын ганц чухал параметр бол хүсэлтийн утга учир VPA түүнтэй ажиллах болно. Та програмаа босоогоор нь масштаблах бүрдээ ямар хүсэлт байх ёстойг тодорхойлдог. Тэгээд хязгаарлалт юу болох вэ? Энэ параметрийг мөн пропорциональ хэмжээгээр хуваах болно.

Жишээлбэл, энд ердийн pod тохиргоонууд байна:

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

Зөвлөмжийн систем нь таны програмыг зөв ажиллуулахын тулд 300м CPU болон 500Mi хэрэгтэйг тодорхойлдог. Та эдгээр тохиргоог авах болно:

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

Дээр дурдсанчлан энэ нь манифест дахь хүсэлт/хязгаарлалтын харьцаанд суурилсан пропорциональ масштаб юм:

CPU: 200м → 300м: харьцаа 1:1.75;
Санах ой: 250Mi → 500Mi: 1:2 харьцаа.

Тухайд HPA, дараа нь үйл ажиллагааны механизм илүү ил тод болно. Босгыг процессор, санах ой зэрэг хэмжигдэхүүнд тохируулдаг бөгөөд хэрэв бүх хуулбарын дундаж нь босго хэмжээнээс хэтэрсэн бол утгыг босго хэмжээнээс доош буулгах хүртэл буюу хамгийн их хуулбарын тоонд хүрэх хүртэл програмыг +1 pod-оор хэмждэг.

Зургийг https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231-ээс авсан

CPU болон санах ой гэх мэт ердийн хэмжигдэхүүнүүдээс гадна та өөрийн Prometheus хэмжигдэхүүндээ босго тогтоож, энэ нь програмаа хэзээ томруулахыг тодорхойлох хамгийн зөв арга гэж бодож байвал тэдэнтэй ажиллах боломжтой. Аппликешн нь тогтоосон хэмжүүрийн босго хэмжээнээс доогуур тогтворжсоны дараа HPA нь подкуудыг хамгийн бага хуулбарын тоо хүртэл эсвэл ачаалал заасан босго хэмжээнд хүрэх хүртэл багасгаж эхэлнэ.

6. Node Affinity болон Pod Affinity-ийн талаар бүү мартаарай

Бүх зангилаа нэг техник хангамж дээр ажилладаггүй бөгөөд бүх pods нь тооцоолол их шаарддаг програмуудыг ажиллуулах шаардлагагүй. Kubernetes нь зангилаа ба хонгилын мэргэшлийг тодорхойлох боломжийг танд олгоно Зангилааны хамаарал и Pod Affinity.

Хэрэв танд тооцоолол их шаарддаг үйл ажиллагаанд тохиромжтой зангилаа байгаа бол хамгийн их үр ашигтай байхын тулд програмуудыг тохирох зангилаатай холбох нь дээр. Үүнийг хийхийн тулд ашиглана уу nodeSelector зангилааны шошготой.

Танд хоёр зангилаа байна гэж бодъё: нэг нь CPUType=HIGHFREQ мөн олон тооны хурдан цөм, өөр нэг нь MemoryType=HIGHMEMORY илүү их санах ой, илүү хурдан гүйцэтгэл. Хамгийн хялбар арга бол зангилаанд pod deployment оноох явдал юм HIGHFREQхэсэгт нэмэх замаар spec иймэрхүү сонгогч:

…
nodeSelector:
	CPUType: HIGHFREQ

Үүнийг хийх илүү үнэтэй бөгөөд тодорхой арга бол ашиглах явдал юм nodeAffinity талбайд affinity Хэсэг spec. Хоёр сонголт байна:

requiredDuringSchedulingIgnoredDuringExecution: хатуу тохиргоо (төлөвлөгч нь зөвхөн тодорхой зангилаанууд дээр (мөн өөр хаана ч байхгүй) хонхорцог байрлуулах болно);
preferredDuringSchedulingIgnoredDuringExecution: зөөлөн тохиргоо (төлөвлөгч нь тодорхой зангилаа руу байрлуулахыг оролдох бөгөөд амжилтгүй болбол дараагийн боломжтой зангилаа руу байрлуулахыг оролдох болно).

Та зангилааны шошгыг удирдах тусгай синтаксийг зааж өгч болно, жишээлбэл, In, NotIn, Exists, DoesNotExist, Gt буюу Lt. Гэсэн хэдий ч шошгоны урт жагсаалт дахь нарийн төвөгтэй аргууд нь эгзэгтэй нөхцөл байдалд шийдвэр гаргах явцыг удаашруулна гэдгийг санаарай. Өөрөөр хэлбэл, хэт төвөгтэй болгох хэрэггүй.

Дээр дурдсанчлан Kubernetes танд одоогийн хонхорцог холболтыг тохируулах боломжийг олгодог. Өөрөөр хэлбэл, та тодорхой хонхорцогуудыг ижил боломжийн бүсэд (үүлэнд хамааралтай) эсвэл зангилаа дахь бусад подкуудтай хамт ажиллуулж болно.

В podAffinity талбайнууд affinity Хэсэг spec тохиолдолтой ижил талбарууд байдаг nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. Ганц ялгаа нь үүнд л байгаа юм matchExpressions нь уг шошготой pod ажиллуулж байгаа зангилаатай холбох болно.

Илүү Kubernetes талбарыг санал болгодог podAntiAffinity, энэ нь эсрэгээрээ, тодорхой хонхорцог бүхий зангилаатай хонхорцог холбодоггүй.

Илэрхийллийн тухай nodeAffinity Үүнтэй ижил зөвлөгөөг өгч болно: дүрмийг энгийн бөгөөд логиктой байлгахыг хичээ, нарийн төвөгтэй дүрмүүдээр pod тодорхойлолтыг хэт ачаалахыг бүү оролд. Кластерын нөхцөлтэй тохирохгүй дүрмийг бий болгох нь маш хялбар бөгөөд хуваарьт нэмэлт ачаалал өгч, ерөнхий гүйцэтгэлийг муутгадаг.

7. Хорт бодис ба тэсвэрлэх чадвар

Төлөвлөгчийг удирдах өөр нэг арга бий. Хэрэв танд хэдэн зуун зангилаа, мянга мянган микро үйлчилгээ бүхий том кластер байгаа бол тодорхой зангилаанууд нь тодорхой pods-уудыг байршуулахаас урьдчилан сэргийлэхэд маш хэцүү байдаг.

Бохирдлын механизм - хориглох дүрэм нь үүнд тусалдаг. Жишээлбэл, та тодорхой тохиолдлуудад тодорхой зангилаануудыг pod ажиллуулахаас сэргийлж болно. Тодорхой зангилаанд будаг түрхэхийн тулд сонголтыг ашиглана уу taint kubectl дээр. Түлхүүр болон утгыг зааж өгөөд дараа нь үүнтэй төстэй NoSchedule буюу NoExecute:

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

Бохирдлын механизм нь гурван үндсэн нөлөөг дэмждэг гэдгийг тэмдэглэх нь зүйтэй. NoSchedule, NoExecute и PreferNoSchedule.

NoSchedule pod тодорхойлолтод харгалзах оруулга байх хүртэл гэсэн үг tolerations, үүнийг зангилаа руу байрлуулах боломжгүй (энэ жишээнд node10).
PreferNoSchedule - хялбаршуулсан хувилбар NoSchedule. Энэ тохиолдолд хуваарь гаргагч нь тохирох оруулгагүй подкуудыг хуваарилахгүй байхыг хичээх болно. tolerations нэг зангилаа, гэхдээ энэ нь хатуу хязгаар биш юм. Хэрэв кластерт нөөц байхгүй бол энэ зангилаа дээр pods байрлуулж эхэлнэ.
NoExecute - энэ нөлөө нь тохирох оруулгагүй хонхорцог нэн даруй нүүлгэн шилжүүлэхэд хүргэдэг tolerations.

Хачирхалтай нь энэ зан үйлийг тэвчих механизмыг ашиглан буцаах боломжтой. Энэ нь "хориотой" зангилаа байгаа тохиолдолд тохиромжтой бөгөөд та зөвхөн дэд бүтцийн үйлчилгээг байрлуулах шаардлагатай болно. Үүнийг хэрхэн хийх вэ? Зөвхөн тохирох хүлцэл бүхий хонхорцогуудыг зөвшөөрнө.

Дотор нь дараах байдлаар харагдах болно.

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

Энэ нь дараагийн дахин байршуулах үед подвол яг энэ зангилаанд хүрнэ гэсэн үг биш бөгөөд энэ нь Node Affinity механизм биш бөгөөд nodeSelector. Гэхдээ хэд хэдэн функцийг нэгтгэснээр та маш уян хатан хуваарийн тохиргоог хийж чадна.

8. Pod Deployment Priority-г тохируулна уу

Та pod-to-node холболтыг тохируулсан учраас бүх pods-д ижил ач холбогдол өгөх ёстой гэсэн үг биш юм. Жишээлбэл, та зарим нэг Pod-ыг бусдаас өмнө байрлуулахыг хүсч болно.

Kubernetes нь Pod Priority болон Preemption-ийг тохируулах өөр өөр аргыг санал болгодог. Тохиргоо нь хэд хэдэн хэсгээс бүрдэнэ: объект 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-аас бага буюу тэнцүү ямар ч 1 бит бүхэл тоо байж болно. Илүү өндөр утгууд нь чухал ач холбогдолтой системийн pods-д зориулагдсан бөгөөд ихэвчлэн урьдчилан сэргийлэх боломжгүй. Зөвхөн өндөр ач холбогдол бүхий хонхорхой эргэх газаргүй бол нүүлгэн шилжүүлэлт хийгдэнэ, дараа нь тодорхой зангилаанаас зарим хонхорцог нүүлгэн шилжүүлнэ. Хэрэв энэ механизм танд хэтэрхий хатуу байвал та сонголтыг нэмж болно preemptionPolicy: Never, дараа нь ямар ч давуу эрх байхгүй, pod нь дарааллын эхнийх байх бөгөөд хуваарьлагч түүнд зориулж үнэгүй нөөц олохыг хүлээнэ.

Дараа нь бид нэрээ зааж өгөх pod үүсгэнэ 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-ийг бүхэл бүтэн кластерын тархи гэж нэрлэж болно. "Куб" дахь үйл ажиллагааны хурд нь үүнээс хамаардаг тул энэ мэдээллийн сангийн ажиллагааг өндөр түвшинд байлгах нь маш чухал юм. Kube-apiserver-д хамгийн бага саатал гаргахын тулд мастер зангилаанууд дээр ETCD кластер байлгах нь нэлээд стандарт бөгөөд үүнтэй зэрэгцэн сайн шийдэл байх болно. Хэрэв энэ боломжгүй бол ETCD-ийг оролцогчдын хооронд сайн зурвасын өргөнтэй аль болох ойр байрлуулна уу. Мөн ETCD-ийн хэдэн зангилаа нь кластерт хор хөнөөл учруулахгүйгээр унаж болохыг анхаарч үзээрэй.

Кластерт оролцогчдын тоо хэт их нэмэгдэх нь гүйцэтгэлийн зардлаар алдааны хүлцлийг нэмэгдүүлж болзошгүй тул бүх зүйл дунд зэрэг байх ёстой гэдгийг санаарай.

Хэрэв бид үйлчилгээг тохируулах талаар ярих юм бол цөөн хэдэн зөвлөмжүүд байна:

Кластерын хэмжээнээс хамааран сайн техник хангамжтай байх (та уншиж болно энд).
Хэрэв та хос DC эсвэл сүлжээний хооронд кластер тарааж, дискнүүд хүссэн зүйлээ үлдээсэн бол цөөн хэдэн параметрүүдийг тохируулаарай (та уншиж болно. энд).

дүгнэлт

Энэ нийтлэлд манай багийн дагаж мөрдөхийг оролддог цэгүүдийг тайлбарласан болно. Энэ бол үйлдлүүдийн алхам алхмаар тайлбар биш, харин кластерын ачааллыг оновчтой болгоход тустай сонголтууд юм. Кластер бүр өөрийн гэсэн өвөрмөц бөгөөд тааруулах шийдлүүд нь маш өөр байж болох тул танаас санал авах нь сонирхолтой байх болно: Та Кубернетес кластераа хэрхэн хянах, түүний гүйцэтгэлийг хэрхэн сайжруулах вэ. Сэтгэгдэл хэсэгт туршлагаа хуваалцаарай, үүнийг мэдэх нь сонирхолтой байх болно.

Эх сурвалж: www.habr.com

Kubernetes гүйцэтгэлийн есөн зөвлөмж