🥇Kubernetesтин иштешин жакшыртуу үчүн тогуз кеңеш

Баарына салам! Менин атым Олег Сидоренков, мен DomClickте инфраструктуралык топтун жетекчиси болуп иштейм. Биз Кубикти өндүрүштө үч жылдан ашык убакыттан бери колдонуп келебиз жана бул убакыттын ичинде аны менен көптөгөн түрдүү кызыктуу учурларды баштан кечирдик. Бүгүн мен сизге кантип туура мамиле кылуу менен кластериңиз үчүн ваниль Кубернетестен дагы да көбүрөөк өндүрүмдүүлүктү сыгып аларыңызды айтып берем. Туруктуу кетүүгө даяр!

Баарыңар жакшы билесиңер, 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, эгерде операциялык команда дагы 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. Оптималдуу файл сактагычты тандаңыз

Бул жерде мен туруктуу томдор жана Kubernetes жумушчу түйүндөрүнүн дисктик подсистемасы темасына токтолгум келет. Мен өндүрүштө HDD боюнча эч ким "Cube" колдонбойт деп үмүттөнөм, бирок кээде кадимки SSD жетишсиз. Киргизүү/чыгаруу операцияларынан улам журналдар дискти өлтүрүп жаткан көйгөйгө туш болдук жана көп чечимдер жок:

Жогорку өндүрүмдүүлүктөгү SSD дисктерин колдонуңуз же NVMeге которулуңуз (эгер сиз өзүңүздүн аппараттык жабдыктарыңызды башкарсаңыз).
Каттоо деңгээлин төмөндөтүңүз.
Дискти зордуктаган кабыктардын "акылдуу" тең салмактуулугун жасаңыз (podAntiAffinity).

Жогорудагы экран access_logs журналы иштетилгенде дискке nginx-ingress-controller астында эмне болорун көрсөтөт (~12 миң журнал/сек). Бул шарт, албетте, бул түйүндөгү бардык тиркемелердин деградациясына алып келиши мүмкүн.

PV келсек, тилекке каршы, мен баарын сынай элекмин түрлөрү Persistent Volumes. Сизге ылайыктуу эң жакшы вариантты колдонуңуз. Тарыхый жактан алганда, биздин өлкөдө кызматтардын бир аз бөлүгү RWX көлөмдөрүн талап кылган жана көп убакыт мурун бул тапшырма үчүн NFS сактагычын колдоно башташкан. Арзан жана... жетиштүү. Албетте, ал экөөбүз бок жедик - батаңыз, бирок биз аны жөндөп алганды үйрөндүк, эми башым оорубайт. Мүмкүн болсо, S3 объект сактагычына өтүңүз.

3. оптималдаштырылган сүрөттөрдү чогултуу

Кубернетес аларды тезирээк алып, натыйжалуураак аткарышы үчүн контейнерге ылайыкташтырылган сүрөттөрдү колдонуу эң жакшы.

Оптимизацияланган сүрөттөр төмөнкүнү билдирет:

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

Сүрөттөрдү учуп текшерүүгө жана оптималдаштырууга мүмкүндүк берген көптөгөн куралдар жана кызматтар бар. Аларды ар дайым жаңыртып туруу жана коопсуздукту текшерүү маанилүү. Натыйжада сиз аласыз:

Бүткүл кластерге тармактык жүктөм кыскартылды.
Контейнерди ишке киргизүү убактысын кыскартуу.
Бүтүндөй Docker реестриңиздин кичине өлчөмү.

4. DNS кэшин колдонуңуз

Эгерде биз жогорку жүктер жөнүндө айта турган болсок, анда кластердин DNS тутумун тууралоосуз жашоо абдан начар. Бир кезде Kubernetes иштеп чыгуучулары кубе-днс чечимдерин колдошкон. Бул жерде да ишке ашырылган, бирок бул программалык камсыздоо өзгөчө жөндөлгөн эмес жана талап кылынган өндүрүмдүүлүктү берген эмес, бирок бул жөнөкөй иш болуп көрүнгөн. Андан кийин коредндер пайда болду, аларга биз которулдук жана эч кандай кайгырбадык; кийинчерээк ал K8sдеги демейки DNS кызматы болуп калды. Бир убакта биз DNS тутумуна 40 миң rps чейин өстүк жана бул чечим да жетишсиз болуп калды. Бирок, бактыга жараша, Nodelocaldns чыкты, aka node локалдык кэш, ака NodeLocal DNSCache.

Эмне үчүн биз муну колдонобуз? Linux ядросунда ката бар, ал UDP аркылуу NAT аркылуу бир нече чалуулар контрак таблицаларындагы жазуулардын жарыш абалына алып келет жана NAT аркылуу трафиктин бир бөлүгү жоголот (Кызмат аркылуу ар бир сапар NAT). Nodelocaldns бул көйгөйдү NATдан арылуу жана TCP менен жогорку агымдык DNSке туташууну өркүндөтүү, ошондой эле жергиликтүү DNS сурамдарын (анын ичинде кыска 5 секунддук терс кэшти) кэштөө аркылуу чечет.

5. Капчаларды туурасынан жана тигинен автоматтык түрдө масштаблаңыз

Сиздин бардык микросервисиңиз жүктөмдү эки-үч эсеге көбөйтүүгө даяр деп ишенимдүү айта аласызбы? Тиркемелериңизге ресурстарды кантип туура бөлүштүрүү керек? Жумуштун жүгүнөн тышкары бир нече поддонду кармап туруу ашыкча болушу мүмкүн, бирок аларды артка кайтаруу кызматка трафиктин кескин көбөйүшүнөн токтоп калуу коркунучун жаратат. сыяктуу кызматтар Horizontal Pod Autoscaler и Vertical Pod Autoscaler.

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

Сунуштоо кыймылдаткычы колдонмоңуз туура иштеши үчүн 300м CPU жана 500Mi талап кылаарын аныктайт. Сиз төмөнкү орнотууларды аласыз:

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

Жогоруда айтылгандай, бул манифесттеги суроо-талаптар/лимиттер катышына негизделген пропорционалдуу масштабдоо:

CPU: 200m → 300m: катышы 1:1.75;
Эстутум: 250Mi → 500Mi: катышы 1:2.

эске алуу менен мбар, анда иштөө механизми ачык-айкын болот. CPU жана эстутум сыяктуу көрсөткүчтөр босого болуп саналат жана бардык репликалардын орточо мааниси босогодон ашып кетсе, маани босогодон ылдый түшкөнгө чейин же репликалардын максималдуу санына жеткенге чейин колдонмо +1 суб масштабдалат.

Сүрөт https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 алынган

Кадимки CPU жана эс тутум сыяктуу көрсөткүчтөрдөн тышкары, сиз Prometheus'тан ыңгайлаштырылган көрсөткүчтөрүңүзгө босоголорду коюп, алар менен иштей аласыз, эгерде сиз бул колдонмоңузду качан масштабдоону эң так көрсөткүч деп ойлосоңуз. Тиркеме белгиленген метрикалык босогодон төмөн турукташкандан кийин, HPA репликалардын минималдуу санына чейин же жүк көрсөтүлгөн босогого жеткенге чейин кичирейе баштайт.

6. Node Affinity жана Pod Affinity жөнүндө унутпаңыз

Бардык түйүндөр бир эле жабдыкта иштей бербейт жана бардык подколор эсептөө интенсивдүү колдонмолорду иштетүүгө муктаж эмес. Kubernetes аркылуу түйүндөрдүн жана поддондордун адистешин орнотууга мүмкүндүк берет Түйүндүн жакындыгы и Pod Affinity.

Эгерде сизде интенсивдүү эсептөө операциялары үчүн ылайыктуу түйүндөр бар болсо, анда максималдуу эффективдүүлүк үчүн тиркемелерди тиешелүү түйүндөргө байлаган жакшы. Бул колдонуу үчүн 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.

Кызыктуусу, бул жүрүм-турум сабырдуулук механизмин колдонуу менен жокко чыгарылышы мүмкүн. Бул "тыюу салынган" түйүн болгондо ыңгайлуу жана ага инфраструктуралык кызматтарды коюу керек. Муну кандай жасаш керек? Ылайыктуу толеранттуулук бар шактарга гана уруксат бериңиз.

Бул жерде pod спецификациясы кандай болот:

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

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

8. Pod жайгаштыруу приоритеттерин коюу

Сизде түйүндөргө бөлүкчөлөр дайындалгандыктан, бул бардык уячаларга бирдей артыкчылык менен мамиле кылуу керек дегенди билдирбейт. Мисалы, сиз кээ бир поддондорду башкалардан мурун жайгаштыргыңыз келиши мүмкүн.

Kubernetes Pod Priority жана Preemption конфигурациялоонун ар кандай жолдорун сунуштайт. Орнотуу бир нече бөлүктөн турат: объект PriorityClass жана талаа сыпаттамалары priorityClassName pod спецификациясында. Келгиле, бир мисал карап көрөлү:

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 000 000 кем же барабар каалаган 000 биттик бүтүн сан болушу мүмкүн. Жогорку маанилер миссия үчүн критикалык система подкасттары үчүн сакталган, аларды жалпысынан алдын ала алуу мүмкүн эмес. Көчүрүү, эгерде жогорку артыкчылыктуу уячанын бурула турган жери жок болсо гана пайда болот, андан кийин белгилүү бир түйүндөгү уячалардын айрымдары эвакуацияланат. Бул механизм сиз үчүн өтө катаал болсо, сиз опцияны кошо аласыз 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 бүткүл кластердин мээси деп атоого болот. Бул маалымат базасынын иштешин жогорку деңгээлде кармап туруу абдан маанилүү, анткени Cubeдеги операциялардын ылдамдыгы андан көз каранды. Куб-аписерверге минималдуу кечигүү үчүн ETCD кластерин мастер түйүндөрдө сактоо кыйла стандарттуу жана ошол эле учурда жакшы чечим болмок. Эгер сиз муну кыла албасаңыз, анда ETCDди мүмкүн болушунча жакын жерге, катышуучулардын ортосунда өткөрүү жөндөмдүүлүгү жакшы. Ошондой эле ETCDден канча түйүн кластерге зыян келтирбестен чыгып кетиши мүмкүн экендигине көңүл буруңуз

Кластердеги мүчөлөрдүн санын ашыкча көбөйтүү каталарга чыдамдуулукту аткаруунун эсебинен жогорулата тургандыгын эстен чыгарбоо керек, бардыгы ченемде болушу керек.

Эгер кызматты орнотуу жөнүндө сөз кыла турган болсок, анда бир нече сунуштар бар:

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

жыйынтыктоо

Бул макалада биздин команда сактоого аракет кылган пункттар сүрөттөлөт. Бул иш-аракеттердин этап-этабы менен сүрөттөлүшү эмес, бирок кластердин кошумча чыгымдарын оптималдаштыруу үчүн пайдалуу болушу мүмкүн болгон варианттар. Ар бир кластер өз жолу менен уникалдуу экени түшүнүктүү жана конфигурация чечимдери абдан ар түрдүү болушу мүмкүн, андыктан Kubernetes кластериңизди кантип көзөмөлдөп жатканыңыз жана анын иштешин кантип жакшыртаарыңыз тууралуу пикириңизди алуу кызыктуу болмок. Комментарийлерде тажрыйбаңыз менен бөлүшүңүз, билүү кызыктуу болот.

Source: www.habr.com

Тогуз Кубернеттин аткаруу кеңештери