Көптөр тиркемени Kubernetesке өткөрүп берүү жетиштүү деп ойлошот (Helm менен же кол менен) - ошондо бакыт болот. Бирок баары ушунчалык жөнөкөй эмес.
команда DevOps инженери Джулиан Гиндинин макаласын которгон. Бир эле тырмоону басып калбашыңыз үчүн, ал миграция процессинде анын компаниясы кандай кыйынчылыктарга туш болгонун айтып берет.
Биринчи кадам: Pod сурамдарын жана чектөөлөрдү орнотуңуз
Келгиле, биздин породалар иштей турган таза чөйрөнү орнотуудан баштайлы. Kubernetes подкасттарды пландаштырууда жана иштен чыгарууда сонун. Бирок пландоочу ийгиликтүү иштеши үчүн канча ресурс керек экенин эсептөө кыйын болсо, кээде подставаны коё албайт экен. Бул жерде ресурстарга жана чектөөлөргө суроо-талаптар пайда болот. Суроо-талаптарды жана чектөөлөрдү коюунун эң жакшы ыкмасы жөнүндө көп талаш-тартыштар бар. Кээде бул чындап эле илимге караганда искусство окшойт. Мына биздин мамилебиз.
Под сурамдары пландоочу поддонду оптималдуу жайгаштыруу үчүн колдонгон негизги маани.
чейин : Чыпка кадамы Pod пландаштырыла турган түйүндөр топтомун аныктайт. Мисалы, PodFitsResources чыпкасы түйүндүн поддондун белгилүү бир ресурс суроо-талаптарын канааттандыруу үчүн жетиштүү ресурстары бар-жогун текшерет.
Колдонмонун суроо-талаптарын биз канча ресурстарды баалай тургандай колдонобуз Чындыгында Колдонмого туура иштеши керек. Ушундай жол менен пландаштыруучу түйүндөрдү реалдуу жайгаштыра алат. Башында, биз ар бир Pod үчүн жетиштүү ресурстарды камсыз кылуу үчүн суроо-талаптарды ашыкча графикке киргизгибиз келди, бирок биз пландаштыруу убактысы кыйла көбөйгөнүн жана кээ бир Podдор үчүн ресурс суроо-талаптары жоктой, толук пландаштырылган эмес экенин байкадык.
Бул учурда, пландоочу көп учурда поддондорду "кысып чыгарып" жана аларды кайра пландаштыра албайт, анткени башкаруу учагында тиркемеге канча ресурстар керек болорун түшүнгөн эмес, бул график алгоритминин негизги компоненти болуп саналат.
Под чектер бир поддон үчүн ачык-айкын чек болуп саналат. Бул кластер контейнерге бөлүштүрө турган ресурстардын максималдуу көлөмүн билдирет.
Дагы, тартып : Эгерде контейнердин эстутумунун чеги 4 ГБ болсо, анда kubelet (жана контейнердин иштөө убактысы) аны ишке ашырат. Иштөө убактысы контейнердин белгиленген ресурс чегинен ашык колдонуусуна жол бербейт. Мисалы, контейнердеги процесс эстутумдун уруксат берилген көлөмүнөн ашык колдонууга аракет кылганда, системанын өзөгү процессти "эсте калган" (OOM) катасы менен токтотот.
Контейнер ар дайым ресурстук суроо-талап көрсөткөндөн көбүрөөк ресурстарды колдоно алат, бирок ал эч качан чектен ашык колдоно албайт. Бул маанини туура коюу кыйын, бирок бул абдан маанилүү.
Идеалында, биз тутумдагы башка процесстерге тоскоолдук кылбастан, процесстин жашоо циклинин жүрүшүндө поддондун ресурстук талаптары өзгөрүшүн каалайбыз - бул чектерди коюунун максаты.
Тилекке каршы, мен кандай баалуулуктарды коюу керектиги боюнча конкреттүү көрсөтмөлөрдү бере албайм, бирок биз өзүбүз төмөнкү эрежелерди карманабыз:
- Жүктөлгөн тестирлөө куралын колдонуу менен биз трафиктин базалык деңгээлин имитациялайбыз жана подкалдык ресурстардын (эс тутум жана процессор) колдонулушун байкайбыз.
- Кошумча суроо-талаптарды өзүм билемдик менен төмөн мааниге коюңуз (ресурстун чеги сурамдардын маанисинен болжол менен 5 эсе көп) жана байкаңыз. Сурамдардын деңгээли өтө төмөн болгондо, процесс башталбай калат, бул көп учурда сырдуу Go иштөө убактысынын каталарын жаратат.
Мен жогорку ресурстук чектөөлөр пландаштырууну кыйындатат, анткени подкага жетиштүү ресурстары бар максаттуу түйүн керек.
Сизде 4 ГБ эстутум сыяктуу өтө жогорку ресурстук чектөөсү бар жеңил веб-сервериңиз бар жагдайды элестетиңиз. Бул процесс, кыязы, горизонталдуу түрдө кеңейтилиши керек болот жана ар бир жаңы подключ кеминде 4 ГБ жеткиликтүү эс тутуму бар түйүндө пландаштырылышы керек. Эгерде андай түйүн жок болсо, кластер бул подкукту иштетүү үчүн жаңы түйүн киргизиши керек, ал бир аз убакытты талап кылышы мүмкүн. Тез жана жылмакай масштабдоону камсыз кылуу үчүн ресурстук суроо-талаптар менен чектөөлөрдүн ортосундагы минималдуу айырмага жетишүү маанилүү.
Экинчи кадам: Жашоо жана Даярдык тесттерин орнотуңуз
Бул Kubernetes коомчулугунда көп талкууланган дагы бир тымызын тема. Жашоо жана Даярдык тесттерин жакшы түшүнүү маанилүү, анткени алар программалык камсыздоонун туруктуу иштешинин механизмин камсыздайт жана токтоп калууларды азайтат. Бирок, алар туура конфигурацияланбаса, колдонмоңуздун иштешине олуттуу таасир этиши мүмкүн. Төмөндө эки үлгүлөрдүн кыскача маалыматы келтирилген.
Жашоо контейнер иштеп жатканын көрсөтөт. Эгер ал ишке ашпай калса, kubelet контейнерди өлтүрөт жана ал үчүн кайра баштоо саясаты иштетилет. Эгерде контейнер Liveness Probe менен жабдылбаса, анда айтылгандай демейки абал ийгиликтүү болот .
Жашоо зонддору арзан болушу керек, б.а. көп ресурстарды керектебеши керек, анткени алар тез-тез иштешет жана Kubernetesке тиркеме иштеп жаткандыгы жөнүндө маалымат бериши керек.
Эгер сиз секунд сайын иштетүү параметрин койсоңуз, бул секундасына 1 суроону кошот, андыктан бул трафикти иштетүү үчүн кошумча ресурстар талап кылынарын эске алыңыз.
Биздин компанияда Liveness тесттери, маалыматтар (мисалы, алыскы маалымат базасынан же кэштен) толук жеткиликтүү болбосо дагы, тиркеменин негизги компоненттерин сынайт.
Биз колдонмолордо 200 жооп кодун кайтаруучу "ден соолук" акыркы чекитин орноттук. Бул процесс иштеп жатканын жана суроо-талаптарды (бирок азырынча трафикти эмес) иштетүүгө жөндөмдүү экендигинин көрсөткүчү.
Аракет кыл даярдык контейнер суроо-талаптарды тейлөөгө даяр экендигин көрсөтөт. Даярдык текшерүүсү иштебей калса, акыркы чекит контроллери поддондун IP дарегин подкокко дал келген бардык кызматтардын акыркы чекиттеринен алып салат. Бул Kubernetes документтеринде да айтылат.
Даярдык текшерүүлөрү көбүрөөк ресурстарды керектешет, анткени алар тиркеме суроо-талаптарды кабыл алууга даяр экенин көрсөтүү үчүн арткы тарапка тийиши керек.
Коомчулукта маалымат базасына түз кирүү керекпи деген талаш-тартыштар көп. Кошумча чыгымдарды эске алуу менен (текшерүүлөр тез-тез болуп турат, бирок аларды көзөмөлдөөгө болот), биз кээ бир колдонмолор үчүн трафикти тейлөөгө даярдыгы жазуулар базадан кайтарылганын текшергенден кийин гана эсептелет деп чечтик. Жакшы иштелип чыккан даярдык сыноолору жеткиликтүүлүктүн жогорку деңгээлин камсыз кылды жана жайылтуу учурунда токтоп калууларды жок кылды.
Эгер сиз арызыңыздын даярдыгын текшерүү үчүн маалымат базасына суроо берүүнү чечсеңиз, анын мүмкүн болушунча арзан экенин текшериңиз. Бул суроону алалы:
SELECT small_item FROM table LIMIT 1Бул жерде биз Kubernetes бул эки баалуулуктарды конфигурациялоонун мисалы:
livenessProbe:
httpGet:
path: /api/liveness
port: http
readinessProbe:
httpGet:
path: /api/readiness
port: http periodSeconds: 2
Сиз кээ бир кошумча конфигурация параметрлерин кошо аласыз:
initialDelaySeconds- контейнерди учуруу менен зонддорду ишке киргизүүнүн ортосунда канча секунд өтөт.periodSeconds— үлгүлөрдү өткөрүүнүн ортосундагы күтүү аралыгы.timeoutSeconds— подлок авариялык деп эсептелген секунданын саны. Кадимки күтүү.failureThresholdкайра күйгүзүү сигналы подкетке жөнөтүлгөнгө чейинки сыноо каталарынын саны.successThreshold- поддон даяр абалга өткөнгө чейинки ийгиликтүү сыноолордун саны (подборка ишке киргенде же калыбына келгенде ийгиликсиз болгондон кийин).
Үчүнчү кадам: Поддун демейки тармак саясатын орнотуу
Kubernetesтин "жалпак" тармак топографиясы бар, демейки шартта бардык поддондор бири-бири менен түз байланышат. Кээ бир учурларда бул каалабайт.
Потенциалдуу коопсуздук маселеси чабуулчу тармактын бардык подколоруна трафик жөнөтүү үчүн бир аялуу тиркемени колдонушу мүмкүн. Коопсуздуктун көптөгөн чөйрөлөрүндөгүдөй эле, бул жерде эң аз артыкчылык принциби колдонулат. Идеалында, тармактык саясаттар подкладкалардын ортосунда кайсы байланыштарга уруксат берилген жана кайсынысына тыюу салынганын ачык айтышы керек.
Мисалы, төмөнкү белгилүү бир аталыш мейкиндиги үчүн бардык келген трафикти четке каккан жөнөкөй саясат:
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
spec:
podSelector: {}
policyTypes:
- Ingress
Бул конфигурациянын визуализациясы:
(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
Кененирээк .
Төртүнчү кадам: Илгичтер жана Init контейнерлери менен колдонуучунун жүрүм-туруму
Биздин негизги максаттарыбыздын бири иштеп чыгуучулар үчүн токтоп калбастан Kubernetes'те жайылтууларды камсыз кылуу болгон. Бул кыйын, анткени тиркемелерди өчүрүү жана алардын колдонулган ресурстарын чыгаруу үчүн көптөгөн варианттар бар.
менен өзгөчө кыйынчылыктар пайда болду . Бул Поддорду ырааттуу жайгаштыруу учурунда активдүү байланыштар ийгиликтүү аяктаганга чейин үзгүлтүккө учураганын байкадык.
Интернетте кеңири изилдөөлөрдөн кийин, Kubernetes Nginx туташуулары подключканы өчүрүүдөн мурда түгөнүшүн күтпөй турганы белгилүү болду. Pre-stop илгичтин жардамы менен биз төмөнкү функцияларды ишке ашырдык жана токтоп калуудан толугу менен арылдык:
lifecycle:
preStop:
exec:
command: ["/usr/local/bin/nginx-killer.sh"]
Мынакей nginx-killer.sh:
#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
echo "Waiting while shutting down nginx..."
sleep 10
done
Дагы бир абдан пайдалуу парадигма - бул конкреттүү тиркемелерди ишке киргизүү үчүн init контейнерлерин колдонуу. Бул колдонмо башталганга чейин иштетилиши керек болгон ресурстарды көп талап кылган маалымат базасын көчүрүү процесси болсо, өзгөчө пайдалуу. Сиз ошондой эле негизги колдонмо үчүн мындай чек коюусуз бул процесс үчүн жогорку ресурстук чектөөнү белгилей аласыз.
Дагы бир кеңири таралган схема инит контейнериндеги сырларга кирүү болуп саналат, ал бул эсептик дайындарды негизги модулга берет, бул негизги тиркеме модулунун өзүнөн сырларга уруксатсыз кирүүгө жол бербейт.
Адаттагыдай эле, документациядан цитата: init контейнерлери колдонмонун контейнер сүрөтүнүн коопсуздугуна зыян келтире турган колдонуучу кодун же утилиталарды коопсуз иштетет. Керексиз куралдарды өзүнчө сактоо менен, сиз колдонмонун контейнер сүрөтүнүн чабуул бетин чектейсиз.
Бешинчи кадам: ядро конфигурациясы
Акыр-аягы, бир кыйла өркүндөтүлгөн техника жөнүндө сөз кылалы.
Kubernetes - бул өтө ийкемдүү платформа, ал сизге жумуш жүктөмдөрүн сиз туура деп эсептесеңиз да иштетүүгө мүмкүндүк берет. Бизде ресурсту өтө көп талап кылган бир катар эффективдүү колдонмолор бар. Кеңири жүктөмдү тестирлөөдөн өткөндөн кийин, демейки Kubernetes жөндөөлөрү иштеп турганда, колдонмолордун бири күтүлгөн трафиктин жүгүн көтөрө албай кыйналып жатканын таптык.
Бирок, Kubernetes сизге артыкчылыктуу контейнерди иштетүүгө мүмкүндүк берет, ал белгилүү бир поддон үчүн ядронун параметрлерин гана өзгөртөт. Бул жерде биз ачык байланыштардын максималдуу санын өзгөртүү үчүн колдонгонбуз:
initContainers:
- name: sysctl
image: alpine:3.10
securityContext:
privileged: true
command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]
Бул көп учурда кереги жок бир кыйла өнүккөн техника. Бирок, эгер сиздин колдонмоңуз оор жүктү көтөрө албай жатса, бул жөндөөлөрдүн айрымдарын өзгөртүүгө аракет кылсаңыз болот. Бул процесс жана ар кандай баалуулуктарды орнотуу жөнүндө көбүрөөк маалымат - ар дайым .
Жыйынтык
Kubernetes кутудан тышкаркы чечим сыяктуу сезилиши мүмкүн, бирок колдонмолордун үзгүлтүксүз иштеши үчүн бир нече негизги кадамдарды жасоо керек.
Кубернетеске өтүү учурунда "жүк тестирлөө циклин" кармануу маанилүү: тиркемени иштетиңиз, аны жүктөө астында сынаңыз, метрикага жана масштабдуу жүрүм-турумга көз салыңыз, ушул маалыматтардын негизинде конфигурацияны тууралаңыз, андан кийин бул циклди кайра кайталаңыз.
Күтүлгөн трафик боюнча реалдуу болуңуз жана кайсы компоненттер биринчи бузулаарын көрүү үчүн анын чегинен чыгууга аракет кылыңыз. Бул итеративдик ыкма менен, ийгиликке жетүү үчүн саналган сунуштардын бир нечеси гана жетиштүү болушу мүмкүн. Же тереңирээк ыңгайлаштырууну талап кылышы мүмкүн.
Ар дайым өзүңүзгө бул суроолорду бериңиз:
- Тиркемелер канча ресурстарды керектейт жана бул сумма кандай өзгөрөт?
- Чыныгы масштабдоо талаптары кандай? Колдонмо орточо канча трафикти көтөрөт? Трафиктин чокусу жөнүндө эмне айтууга болот?
- Кызматтын масштабы канчалык көп болушу керек? Трафикти кабыл алуу үчүн жаңы поддондор канчалык тез ишке кириши керек?
- Капчыктар канчалык кооз жабылат? Дегеле керекпи? Иштебей туруп ишке киргизүүгө мүмкүнбү?
- Коопсуздук тобокелдиктерин кантип азайтуу жана ар кандай бузулган капчыктардан келтирилген зыянды кантип чектөө керек? Кандайдыр бир кызматтардын аларга кереги жок уруксаттары же мүмкүнчүлүктөрү барбы?
Kubernetes укмуштуудай платформаны камсыздайт, ал сизге кластерде миңдеген кызматтарды жайылтуу үчүн мыкты тажрыйбаларды колдонууга мүмкүндүк берет. Бирок, бардык колдонмолор ар кандай. Кээде ишке ашыруу бир аз көбүрөөк иштөөнү талап кылат.
Бактыга жараша, Kubernetes бардык техникалык максаттарга жетүү үчүн керектүү орнотууларды камсыз кылат. Ресурстук суроо-талаптарды жана чектөөлөрдү, Жашоо жана Даярдык текшерүүлөрүн, башталгыч контейнерлерди, тармак саясатын жана өзөктү ыңгайлаштырууну тууралоонун айкалышын колдонуу менен, каталарга чыдамдуулук жана тез масштабдалуу менен бирге жогорку өндүрүмдүүлүккө жетише аласыз.
Дагы эмнени окуу керек:
- .
- .
- .
Source: www.habr.com