Kubernetes менен иштөөнү баштаганда, адатта, контейнер ресурстарын орнотууну унутуп коюшат. Бул учурда, Docker сүрөтүнүн иштешин жана Kubernetes кластерине жайгаштырылышын камсыз кылуу жетиштүү.
Бирок кийинчерээк колдонмо башка тиркемелер менен бирге өндүрүш кластеринде жайгаштырылышы керек. Бул үчүн, сиз контейнерге ресурстарды бөлүп, тиркемени иштетүү жана иштетүү үчүн алардын жетиштүү экенине жана башка иштеп жаткан колдонмолор көйгөйлөргө туш болбошуна ынанышыңыз керек.
команда контейнер ресурстары (CPU & MEM), суроо-талаптар жана ресурстардын чектөөлөрү жөнүндө макаланы которгон. Бул жөндөөлөрдүн артыкчылыктарын жана аларды койбосоңуз эмне болорун билесиз.
Эсептөө ресурстары
Бизде төмөнкү бирдиктер менен ресурстардын эки түрү бар:
- Борбордук иштетүү бирдиги (CPU) - өзөктөрү;
- Эстутум (MEM) - байт.
Ар бир контейнер үчүн ресурстар көрсөтүлгөн. Төмөнкү Pod YAML файлында сиз суралган жана чектөө ресурстарын камтыган ресурс бөлүмүн көрөсүз:
- Суралган Pod ресурстары = бардык контейнерлердин суралган ресурстарынын суммасы;
- Под ресурстун чеги = Бардык Pod ресурстук чектөөлөрүнүн суммасы.
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 спецификациядан Pod - керектүү түйүндү табуу үчүн колдонулган элементтердин бири. Сиз буга чейин Pod жайгаштырууну пландаштырсаңыз болот. Ылайыктуу түйүндү кантип тапса болот?
Kubernetes бир нече компоненттерден турат, анын ичинде башкы түйүн же башкы түйүн (Kubernetes Control Plane). Мастер түйүндө бир нече процесстер бар: kube-аписервер, kube-контроллер-менеджер жана kube-график.
Kube-график процесси жаңы түзүлгөн подкасттарды карап чыгууга жана бардык поддон сурамдарына, анын ичинде суралган ресурстардын санына дал келген жумушчу түйүндөрүн табууга жооптуу. Кубе-график тарабынан табылган түйүндөрдүн тизмеси рейтингде турат. Подтук эң жогорку упайлары бар түйүнгө пландаштырылган.
Кызгылт көк под кайда жайгаштырылат?
Сүрөттө сиз kube-график жаңы кызгылт көк Pod пландаштырышы керек экенин көрө аласыз. Kubernetes кластеринде эки түйүн бар: A жана B. Көрүнүп тургандай, kube-график A түйүнүндөгү Pod графигин түзө албайт - жеткиликтүү (сурулбаган) ресурстар кызгылт көк Pod сурамдарына дал келбейт. Ошентип, кызгылт көк Pod сураган 1 ГБ эстутум А түйүнүнө туура келбейт, анткени жеткиликтүү эстутум 0,5 ГБ. Бирок В түйүнү жетиштүү ресурстарга ээ. Натыйжада, кубе-график кызгылт көк Pod бара турган жери Б түйүнү деп чечет.
Эми биз суралган ресурстар Podду иштетүү үчүн түйүндү тандоого кандай таасир тийгизерин билебиз. Бирок маржиналдык ресурстардын таасири кандай?
Ресурстун чеги CPU/MEM өтө албаган чек болуп саналат. Бирок, CPU ресурсу ийкемдүү, ошондуктан CPU чегине жеткен контейнерлер Podтун чыгышына себеп болбойт. Анын ордуна, CPU тескөө башталат. MEM колдонуу чегине жеткен болсо, контейнер OOM-Killer үчүн токтотулат жана RestartPolicy жөндөө уруксат берсе, кайра иштетилет.
Суралган жана максималдуу ресурстар деталдуу
Docker жана Kubernetes ортосундагы ресурстук байланыш
Ресурстук суроо-талаптар жана ресурс чектөөлөрү кантип иштээрин түшүндүрүүнүн эң жакшы жолу - Kubernetes менен Dockerдин ортосундагы мамилени киргизүү. Жогорудагы сүрөттө сиз Kubernetes талаалары жана Docker баштоо желектери кандай байланышта экенин көрө аласыз.
Эстутум: суроо-талап жана чектөө
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Жогоруда айтылгандай, эс байт менен өлчөнөт. Негизинде , эстутумду сан катары көрсөтө алабыз. Адатта, бул бүтүн сан, мисалы 2678 - башкача айтканда, 2678 байт. Суффикстерди да колдонсоңуз болот G и Gi, негизги нерсе, алар барабар эмес экенин эстен чыгарбоо керек. Биринчиси ондук, экинчиси экилик. k8s документтеринде айтылган мисал сыяктуу: 128974848, 129e6, 129M, 123Mi - алар иш жүзүндө эквиваленттүү.
Kubernetes опциясы limits.memory желекке дал келет --memory Докерден. болгон учурда request.memory Docker үчүн жебе жок, анткени Docker бул талааны колдонбойт. Сиз сурасаңыз болот, бул керекпи? Ооба керек. Мен мурда айткандай, талаа Кубернетес үчүн маанилүү. Андан алынган маалыматтын негизинде, кубе-график Подду кайсы түйүн пландаштырууну чечет.
Сурам үчүн эстутум жетишсиз болсо, эмне болот?
Эгерде контейнер суралган эс тутумдун чегине жеткен болсо, анда Pod түйүндө эстутум жетишсиз болгондо токтоп турган Pod тобуна жайгаштырылат.
Эстутум чегин өтө төмөн коюп койсоңуз эмне болот?
Эгерде контейнер эстутум чегинен ашып кетсе, ал OOM-Killed үчүн токтотулат. Жана мүмкүн болсо, демейки маани болгон RestartPolicy негизинде кайра башталат Always.
Суралган эстутумду көрсөтпөсөңүз эмне болот?
Kubernetes чек маанисин алып, аны демейки маани катары коёт.
Эстутум чегин көрсөтпөсөңүз, эмне болушу мүмкүн?
Контейнерде эч кандай чектөөлөр жок, ал каалагандай эстутумду колдоно алат. Эгерде ал түйүндүн бардык жеткиликтүү эс тутумун колдоно баштаса, анда OOM аны өлтүрөт. Андан кийин контейнер мүмкүн болсо, RestartPolicy негизинде кайра иштетилет.
Эстутум чектөөлөрүн көрсөтпөсөңүз эмне болот?
Бул эң начар сценарий: пландоочу контейнер канча ресурстарды талап кыларын билбейт жана бул түйүндө олуттуу көйгөйлөрдү жаратышы мүмкүн. Бул учурда, аттар мейкиндигинде демейки чектерге ээ болуу жакшы болмок (LimitRange тарабынан коюлган). Демейки чектөөлөр жок - Pod эч кандай чектөө жок, ал каалагандай көп эстутумду колдоно алат.
Эгерде суралган эс түйүн сунуштай тургандан көп болсо, Pod пландаштырылбайт. Муну эстен чыгарбоо маанилүү Requests.memory - минималдуу маани эмес. Бул контейнердин үзгүлтүксүз иштеши үчүн жетиштүү эстутум көлөмүнүн сүрөттөлүшү.
Адатта үчүн бирдей маанини коюу сунушталат request.memory и limit.memory. Бул Kubernetes Podду иштетүү үчүн эстутуму жетиштүү, бирок аны иштетүү үчүн жетишсиз болгон түйүндө Pod пландаштырбай тургандыгын камсыздайт. Эсиңизде болсун: Kubernetes Pod пландаштыруу гана эске алынат requests.memoryжана limits.memory эске албайт.
CPU: суроо-талап жана чектөө
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
CPU менен баары бир аз татаалыраак. Кубернетес менен Докердин ортосундагы мамиленин сүрөтүнө кайрылып, муну көрө аласыз request.cpu туура келет --cpu-shares, анда кандай limit.cpu желекке дал келет cpus Докерде.
Kubernetes сураган CPU CPU циклдеринин үлүшү 1024кө көбөйтүлөт. Эгер сиз 1 толук ядрону сурагыңыз келсе, кошушуңуз керек cpu: 1жогоруда көрсөтүлгөндөй.
Толук ядрону талап кылуу (пропорция = 1024) сиздин контейнериңиз аны алат дегенди билдирбейт. Эгерде сиздин хост машинаңызда бир гана өзөк болсо жана сиз бирден ашык контейнерди иштетип жатсаңыз, анда бардык контейнерлер алардын ортосунда жеткиликтүү CPU бөлүшүшү керек. Бул кантип болот? Сүрөттү карап көрөлү.
CPU суроо-талабы - бир негизги система
Келгиле, сизде контейнерлерди иштеткен бир өзөктүү хост системасы бар деп элестетип көрөлү. Апам (Кубернетес) пирог (CPU) бышырып, аны балдарга (контейнерлер) бөлгүсү келет. Үч бала бүтүн пирогту (пропорция = 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% алат. Бирок көп ядролуу система болсо, баары башкача болот.
CPU суроо-талап - көп ядролуу (4) системасы
Жогорудагы сүрөттө үч бала бүтүндөй пирогду, бирөө жарымын каалай турганын көрүүгө болот. Апам төрт пирог бышыргандыктан, анын ар бир баласы канча кааласа ошончо алат. Көп ядролуу системада процессордун ресурстары бардык колдо болгон процессор өзөктөрүнө бөлүштүрүлөт. Эгер контейнер бирден аз толук CPU өзөгү менен чектелсе, ал аны 100% колдоно алат.
Жогорудагы эсептөөлөр CPU контейнерлер арасында кантип бөлүштүрүлгөнүн түшүнүү үчүн жөнөкөйлөштүрүлгөн. Албетте, контейнерлердин өзүнөн тышкары, CPU ресурстарын колдонгон башка процесстер да бар. Бир контейнердеги процесстер иштебей турганда, башкалар анын ресурсун колдоно алышат. CPU: "200m" туура келет CPU: 0,2, бул бир ядронун болжол менен 20%ын билдирет.
Эми кеп кылалы limit.cpu. Kubernetes чектеген CPU 100гө көбөйтүлөт. Натыйжада контейнер ар 100 мкс сайын колдоно ала турган убакыттын көлөмү (cpu-period).
limit.cpu Docker желегине дал келет --cpus. Бул эскинин жаңы айкалышы --cpu-period и --cpu-quota. Аны орнотуу менен, биз контролдоо башталганга чейин контейнер канча жеткиликтүү CPU ресурстарын максималдуу колдоно ала тургандыгын көрсөтөбүз:
- cpus - айкалышы
cpu-periodиcpu-quota. cpus = 1.5орнотууга барабарcpu-period = 100000иcpu-quota = 150000; - CPU-период - мезгил , демейки 100 микросекунд;
- cpu-квота - ичиндеги микросекунддардын саны
cpu-period, контейнер менен чектелген.
Суралган CPU жетишсиз болсо, эмне болот?
Контейнер орнотулгандан көбүрөөк керек болсо, ал башка процесстерден CPU уурдайт.
Эгер сиз CPU чегин өтө төмөн коюп койсоңуз эмне болот?
CPU ресурсу жөнгө салынуучу болгондуктан, дроссель күйгүзүлөт.
CPU сурамын көрсөтпөсөңүз эмне болот?
Эстутумдагыдай эле, суроо-талаптын мааниси чекке барабар.
CPU чегин көрсөтпөсөңүз эмне болот?
Контейнер канча керек болсо, ошончо CPU колдонот. Эгерде аттар мейкиндигинде демейки CPU саясаты (LimitRange) аныкталса, анда бул чек контейнер үчүн да колдонулат.
Сурам же CPU чегин көрсөтпөсөңүз эмне болот?
Эстутумдагыдай эле, бул эң начар сценарий. Пландоочу сиздин контейнериңизге канча ресурстар керек экенин билбейт жана бул түйүндө олуттуу көйгөйлөрдү жаратышы мүмкүн. Мунун алдын алуу үчүн, сиз аттар мейкиндигине демейки чектөөлөрдү коюшуңуз керек (LimitRange).
Эсиңизде болсун: эгер сиз түйүндөр камсыз кылгандан көбүрөөк CPU сурасаңыз, Pod пландаштырылбайт. Requests.cpu - минималдуу маани эмес, Podту баштоо жана мүчүлүштүктөрсүз иштөө үчүн жетиштүү маани. Колдонмо татаал эсептөөлөрдү аткарбаса, эң жакшы вариант - орнотуу request.cpu <= 1 жана керек болсо ошончо репликаларды ишке киргизиңиз.
Суралган ресурстардын же ресурстун чегинин идеалдуу көлөмү
Биз эсептөө ресурстарын чектөө жөнүндө билдик. Эми суроого жооп берүүгө убакыт келди: "Менин Pod тиркемени эч кандай көйгөйсүз иштетүү үчүн канча ресурстарды талап кылат? Идеалдуу сумма кандай?
Тилекке каршы, бул суроолорго так жооптор жок. Колдонмоңуз кандай иштээрин же ага канча CPU же эстутум керек экенин билбесеңиз, эң жакшы вариант - бул колдонмого көп эстутум жана CPU берүү жана андан кийин аткаруу тесттерин жүргүзүү.
Өндүрүмдүүлүк тесттеринен тышкары, бир жума бою мониторингде колдонмонун жүрүм-турумун көзөмөлдөңүз. Эгерде графиктер колдонмоңуз сиз сурагандан азыраак ресурстарды керектеп жатканын көрсөтсө, сиз суралган CPU же эстутумдун көлөмүн азайтсаңыз болот.
Мисал катары муну караңыз . Ал суралган ресурстардын же ресурстун чеги менен учурдагы ресурстун колдонулушунун ортосундагы айырманы көрсөтөт.
жыйынтыктоо
Ресурстарды суроо жана чектөө Kubernetes кластериңизди дени сак сактоого жардам берет. Туура чек конфигурациясы чыгымдарды азайтат жана тиркемелерди ар дайым иштетет.
Кыскача айтканда, эске алуу керек болгон бир нече нерселер бар:
- Суралган ресурстар - бул ишке киргизүү учурунда (Kubernetes тиркемени жайгаштырууну пландаштырганда) эске алынган конфигурация. Ал эми, ресурстарды чектөө иштөө убагында маанилүү - тиркеме түйүндө иштеп жатканда.
- Эстутумга салыштырмалуу CPU жөнгө салынган ресурс болуп саналат. Эгерде CPU жетишсиз болсо, сиздин Pod өчпөйт жана дроссель механизми күйөт.
- Суралган ресурстар жана ресурстун чеги минималдуу жана максималдуу маанилер эмес! Суралган ресурстарды аныктоо менен, сиз колдонмо көйгөйсүз иштей тургандыгына кепилдик бересиз.
- Эстутум талабын эс чегине барабар коюу жакшы практика болуп саналат.
- Макул орнотуу суралды
CPU <=1, эгерде колдонмо татаал эсептөөлөрдү аткарбаса. - Эгер сиз түйүндө жеткиликтүү болгон ресурстардан көбүрөөк ресурстарды сурасаңыз, Pod эч качан ал түйүнгө пландаштырылбайт.
- Суралган ресурстардын/ресурстук чектөөлөрдүн туура көлөмүн аныктоо үчүн жүктөмдү текшерүүнү жана мониторингди колдонуңуз.
Бул макала сизге ресурстарды чектөөнүн негизги түшүнүгүн түшүнүүгө жардам берет деп үмүттөнөм. Жана бул билимди өз ишиңизде колдоно аласыз.
Ийгилик!
Дагы эмнени окуу керек:
- .
- .
- .
Source: www.habr.com