Kubernetes - кластердик өндүрүш чөйрөсүндө Docker контейнерлерин иштетүү үчүн эң сонун курал. Бирок, Kubernetes чече албаган көйгөйлөр бар. Өндүрүштү тез-тез жайылтуу үчүн, процессте токтоп калбоо үчүн бизге толук автоматташтырылган Көк/Жашыл жайгаштыруу керек, ал ошондой эле тышкы HTTP суроо-талаптарын жана SSL жүктөөлөрүн аткарышы керек. Бул ha-proxy сыяктуу жүк баланстоочу менен интеграцияны талап кылат. Дагы бир кыйынчылык - булут чөйрөсүндө иштегенде Кубернетес кластеринин өзүн жарым-жартылай автоматтык түрдө масштабдоо, мисалы, түн ичинде кластерди жарым-жартылай кичирейтүү.
Kubernetesте мындай өзгөчөлүктөр жок болсо да, ал сиз ушул сыяктуу көйгөйлөрдү чечүү үчүн колдоно турган API менен камсыз кылат. Кубернетес кластерин автоматташтырылган Көк/Жашыл жайгаштыруу жана масштабдоо үчүн куралдар ачык булактын негизинде түзүлгөн Cloud RTI долбоорунун алкагында иштелип чыккан.
Бул макала, видео транскрипт, өндүрүштө токтоп калбастан, git commitтин кодун кабыл алган өндүрүшкө даяр чөйрөнү түзүү үчүн башка ачык булак компоненттери менен бирге Kubernetes кантип орнотууну көрсөтөт.
Ошентип, сиз тышкы дүйнөдөн тиркемелериңизге кирүү мүмкүнчүлүгүнө ээ болгондон кийин, сиз автоматташтырууну толугу менен орното баштасаңыз болот, башкача айтканда, аны git милдеттенмесин аткара турган баскычка алып келип, бул гит милдеттенмеси өндүрүштө бүтөөрүнө ынаныңыз. Албетте, бул кадамдарды ишке ашырууда, жайылтууну ишке ашырууда, биз токтоп калууга туш болгубуз келбейт. Ошентип, Kubernetesтеги бардык автоматташтыруу API менен башталат.
Kubernetes кутудан тышкары жемиштүү колдонула турган курал эмес. Албетте, сиз муну кыла аласыз, kubectl жана башкаларды колдоно аласыз, бирок дагы эле API бул платформанын эң кызыктуу жана пайдалуу нерсеси. API'ни функциялардын жыйындысы катары колдонуу менен, сиз Kubernetes'те кылгыңыз келген дээрлик бардык нерсеге жете аласыз. kubectl өзү да REST API колдонот.
Бул REST, андыктан сиз бул API менен иштөө үчүн каалаган тилди же куралды колдоно аласыз, бирок сиздин жашооңуз ыңгайлаштырылган китепканалар аркылуу бир топ жеңилдейт. Менин командам ушундай 2 китепкана жазды: бири Java/OSGi үчүн жана бири Go үчүн. Экинчиси көп колдонулбайт, бирок кандай болгон күндө да бул пайдалуу нерселер сиздин карамагыңызда. Алар жарым-жартылай лицензияланган ачык булактуу долбоор. Ар кандай тилдер үчүн мындай китепканалар көп, ошондуктан сиз өзүңүзгө ылайыктууларын тандай аласыз.
Ошентип, сиз жайгаштырууну автоматташтырууну баштоодон мурун, процесс эч кандай токтоп калбасын текшеришиңиз керек. Мисалы, биздин команда адамдар тиркемелерди эң көп колдонуп жаткан күндүн ортосунда өндүрүштүк жайылтууларды жүргүзөт, ошондуктан бул процессте кечигүүлөрдү болтурбоо маанилүү. Иштебей калууларды болтурбоо үчүн 2 ыкма колдонулат: көк/жашыл жайылтуу же жаңыртуу. Акыркы учурда, эгер сизде иштеп жаткан тиркеменин 5 репликасы болсо, алар ырааттуу түрдө биринин артынан бири жаңыртылат. Бул ыкма сонун иштейт, бирок жайылтуу процессинде бир эле учурда сизде тиркеменин ар кандай версиялары болсо ылайыктуу эмес. Бул учурда, сиз колдонуучунун интерфейсин жаңырта аласыз, ал эми сервер эски версияны иштетип жатканда, тиркеме иштебей калат. Ошондуктан, программалоо көз карашынан алганда, мындай шарттарда иштөө бир топ кыйын.
Бул биздин тиркемелерибизди жайгаштырууну автоматташтыруу үчүн көк/жашыл жайылтууну колдонууну жактыруунун себептеринин бири. Бул ыкма менен сиз бир эле учурда колдонмонун бир гана версиясы активдүү болушун камсыз кылышыңыз керек.
Көк/жашыл жайылтуу механизми ушундай көрүнөт. Биз өзүбүздүн тиркемелерибиз үчүн трафикти ha-proxy аркылуу алабыз, ал аны ошол эле версиянын тиркемесинин иштеп жаткан репликаларына жөнөтөт.
Жаңы жайгаштыруу жасалганда, биз Deployer колдонобуз, ал жаңы компоненттерди берип, жаңы версиясын жайылтат. Тиркеменин жаңы версиясын жайылтуу репликалардын жаңы топтомунун "көтөрүлгөнүн" билдирет, андан кийин жаңы версиянын бул репликалары өзүнчө, жаңы подкестеде ишке киргизилет. Бирок, ha-proxy алар жөнүндө эч нерсе билбейт жана азырынча аларга эч кандай жүк таштабайт.
Ошондуктан, биринчи кезекте, репликалар жүктү тейлөөгө даяр экендигин текшерүү үчүн ден соолукту текшерүүнүн жаңы версияларынын натыйжалуулугун текшерүү керек.
Бардык жайгаштыруу компоненттери ден соолукту текшерүүнүн кандайдыр бир түрүн колдоого алышы керек. Бул өтө жөнөкөй HTTP чалуу текшерүүсү болушу мүмкүн, 200 статусу бар кодду алганыңызда же репликалардын маалымат базасы жана башка кызматтар менен байланышын, динамикалык чөйрө байланыштарынын туруктуулугун текшерген тереңирээк текшерүү. , жана баары туура башталып, иштейби. Бул процесс өтө татаал болушу мүмкүн.
Система бардык жаңыланган репликалар иштеп жатканын текшергенден кийин, Deployer конфигурацияны жаңыртып, ha-проксиди кайра конфигурациялай турган туура конфигурацияны өткөрүп берет.
Ошондон кийин гана трафик жаңы версиянын репликалары бар подкокко багытталат жана эски подкаст жок болот.
Бул механизм Kubernetes өзгөчөлүгү эмес. Көк/жашыл жайылтуу концепциясы бир топ убакыттан бери болуп келген жана ал ар дайым жүк балансын колдонуп келген. Биринчиден, сиз бардык трафикти тиркеменин эски версиясына багыттайсыз жана жаңыртылгандан кийин аны толугу менен жаңы версияга өткөрөсүз. Бул принцип Kubernetes гана эмес, колдонулат.
Эми мен сизди жаңы жайгаштыруу компоненти менен тааныштырам - ден соолукту текшерип, проксилерди кайра конфигурациялайт жана башкалар. Бул тышкы дүйнөгө тиешеси жок жана Kubernetes ичинде бар түшүнүк. Мен сизге ачык булак куралдарын колдонуу менен өзүңүздүн Deployer концепцияңызды кантип түзө аларыңызды көрсөтөм.
Ошентип, Deployer жасаган биринчи нерсе - Kubernetes API аркылуу RC репликация контроллерин түзүү. Бул API андан ары жайылтуу үчүн подкасттарды жана кызматтарды түзөт, башкача айтканда, биздин тиркемелерибиз үчүн таптакыр жаңы кластерди түзөт. RC репликалар иштей баштаганына ынанар замат, алардын иштешине Ден соолук текшерүүсүн жүргүзөт. Бул үчүн, Deployer GET /health буйругун колдонот. Ал тиешелүү скандоочу компоненттерди иштетет жана кластердин иштешин колдогон бардык элементтерди текшерет.
Бардык поддондор алардын ден соолугун кабарлагандан кийин, Deployer жаңы конфигурация элементин түзөт - etcd бөлүштүрүлгөн сактагыч, аны Kubernetes ичинде колдонот, анын ичинде жүк балансынын конфигурациясын сактоо. Биз etcdге маалыматтарды жазабыз жана жаңы маалыматтар үчүн confd monitors etcd деп аталган кичинекей курал.
Эгерде ал баштапкы конфигурацияда кандайдыр бир өзгөрүүлөрдү аныктаса, жаңы орнотуулар файлын түзүп, аны ha-proxyге өткөрөт. Бул учурда, ha-proxy эч кандай байланышты жоготпостон кайра жүктөлөт жана биздин тиркемелерибиздин жаңы версиясынын иштешин камсыз кылган жаңы кызматтарга жүктөлөт.
Көрүнүп тургандай, компоненттердин көптүгүнө карабастан, бул жерде татаал эч нерсе жок. Сиз жөн гана API жана башкаларга көбүрөөк көңүл бурушуңуз керек. Мен сизге биз өзүбүз колдонгон ачык булак жайлоочусу - Amdatu Kubernetes Deployer жөнүндө айткым келет.
Бул Kubernetes жайылтууларын уюштуруу үчүн курал жана төмөнкү өзгөчөлүктөргө ээ:
- Көк/Жашыл жайылтуу;
- тышкы жүк балансын орнотуу;
- жайгаштыруу дескрипторун башкаруу;
- иш жүзүндө жайгаштырууну башкаруу;
- жайгаштыруу учурунда Ден соолук текшерүүлөрүнүн функционалдуулугун текшерүү;
- чөйрө өзгөрмөлөрүнүн поддокторго ишке ашырылышы.
Бул Deployer Kubernetes API үстүнө курулган жана туткаларды жана жайылтууларды башкаруу үчүн REST API менен камсыз кылат, ошондой эле жайгаштыруу процессинде журналдарды агылтуу үчүн Websocket API менен камсыз кылат.
Ал жүгүн тең салмактоочу конфигурация дайындарын etcd ичине киргизет, андыктан кутудан тышкаркы колдоосу менен ha-proxy колдонуунун кажети жок, бирок өзүңүздүн жүк баланстоочу конфигурация файлыңызды оңой колдонуңуз. Amdatu Deployer, Kubernetesтин өзү сыяктуу Go программасында жазылган жана Apache тарабынан лицензияланган.
Деплойердин бул версиясын колдонуудан мурун, мен керектүү параметрлерди көрсөткөн төмөнкү жайылтуу дескрипторун колдондум.
Бул коддун маанилүү параметрлеринин бири "useHealthCheck" желегин иштетүү. Жайгаштыруу процессинде акыл-эсти текшерүү жүргүзүлүшү керек экенин такташыбыз керек. Бул жөндөө текшерүүнү талап кылбаган үчүнчү тараптын контейнерлерин колдонгондо өчүрүлүшү мүмкүн. Бул дескриптор ошондой эле репликалардын санын жана ha-proxy талап кылган алдыңкы URL дарегин көрсөтөт. Аягында "podspec" спецификациясынын желеги бар, ал порт конфигурациясы, сүрөт ж. Бул абдан жөнөкөй JSON дескриптору.
Ачык булактуу Amdatu долбоорунун бир бөлүгү болгон дагы бир курал - Deploymentctl. Ал жайгаштырууларды конфигурациялоо үчүн UI бар, жайылтуу тарыхын сактайт жана үчүнчү тараптын колдонуучуларынан жана иштеп чыгуучуларынан кайра чалуу үчүн вебхуктарды камтыйт. Сиз UIди колдоно албайсыз, анткени Amdatu Deployer өзү REST API, бирок бул интерфейс эч кандай API катышпастан сиз үчүн жайылтууну бир топ жеңилдетет. Deploymentctl Angular 2 аркылуу OSGi/Vertxте жазылган.
Эми мен алдын ала жазылган жазууну колдонуп экранда жогорудагыларды көрсөтөм, андыктан күтпөйсүз. Биз жөнөкөй Go колдонмосун орнотобуз. Go'ну мурда сынап көрбөгөн болсоңуз, кабатыр болбоңуз, бул абдан жөнөкөй тиркеме, андыктан аны түшүнүп алышыңыз керек.
Бул жерде биз /денсоолукка гана жооп берген HTTP серверин түзүп жатабыз, андыктан бул колдонмо ден соолукту текшерүүнү гана текшерет жана башка эч нерсе жок. Текшерүү өтүп кетсе, төмөндө көрсөтүлгөн JSON түзүмү колдонулат. Ал колдонмонун жайгаштыруучу тарабынан орнотула турган версиясын, файлдын жогору жагында көргөн билдирүүнү жана логикалык берилиштердин түрүн камтыйт - биздин колдонмо иштеп жатабы же жокпу.
Мен акыркы сапты бир аз алдап койдум, анткени мен файлдын жогору жагына белгиленген логикалык маанини койдум, ал келечекте мага атүгүл “сапасыз” тиркемени жайылтууга жардам берет. Муну кийинчерээк чечебиз.
Ошентип, баштайлы. Биринчиден, ~ kubectl get pods буйругун колдонуп, иштеп жаткан поддондордун бар-жоктугун текшеребиз жана фронталдык URL'ден жооптун жоктугуна таянып, учурда эч кандай жайгаштыруу жүргүзүлбөй жатканына ынанабыз.
Кийинки экранда мен айткан Deploymentctl интерфейсин көрөсүз, анда жайылтуу параметрлери коюлган: аттар мейкиндиги, колдонмонун аталышы, жайылтуу версиясы, репликалардын саны, алдыңкы URL, контейнердин аталышы, сүрөт, ресурс чектөөлөрү, ден соолукту текшерүү үчүн порт номери, ж.б. Ресурстук чектөөлөр абдан маанилүү, анткени алар сиз аппараттык каражаттардын максималдуу мүмкүн болгон көлөмүн пайдаланууга мүмкүндүк берет. Бул жерден сиз Жайгаштыруу журналын да көрө аласыз.
Эгерде сиз азыр ~ kubectl get pods буйругун кайталасаңыз, система 20 секундага "тоңуп калганын" көрө аласыз, анын жүрүшүндө ha-прокси кайра конфигурацияланат. Андан кийин, подкаст башталат жана биздин репликаны жайылтуу журналында көрүүгө болот.
Мен видеодон 20 секунд күтүүнү кесип салдым, эми экранда колдонмонун биринчи версиясы орнотулганын көрө аласыз. Мунун баары бир гана UI колдонуу менен жасалган.
Эми экинчи версиясын колдонуп көрөлү. Бул үчүн, мен колдонмонун билдирүүсүн "Салам, Кубернетес!" “Салам, Deployer!” дегенде, система бул сүрөттү жаратат жана аны Docker реестрине жайгаштырат, андан кийин биз жөн гана Deploymentctl терезесиндеги “Орнотуу” баскычын кайрадан басабыз. Бул учурда, жайылтуу журналы тиркеменин биринчи версиясын жайгаштыруу учурундагыдай эле автоматтык түрдө ишке киргизилет.
~ kubectl get pods буйругу учурда тиркеменин 2 версиясы иштеп жатканын көрсөтүп турат, бирок алдыңкы версия биз дагы эле 1-версияны иштетип жатканыбызды көрсөтүп турат.
Трафикти жаңы версияга багыттоодон мурун жүк баланстоочу ден соолукту текшерүүнүн аягына чыгышын күтөт. 20 секунддан кийин, биз curl режимине өтүп, бизде азыр колдонмонун 2-версиясы орнотулганын жана биринчиси жок кылынганын көрөбүз.
Бул "ден соолугу чың" тиркеменин жайылтуу болгон. Колдонмонун жаңы версиясы үчүн Ден-соолук параметрин чындыктан жалганга өзгөртсөм, башкача айтканда, ден соолук текшерүүсүнөн өтпөй калган зыяндуу тиркемени жайылтууга аракет кылсам, эмне болорун карап көрөлү. Бул иштеп чыгуу стадиясында тиркемеде кээ бир конфигурация каталары кетирилип, ал ушул формада өндүрүшкө жөнөтүлгөн болсо, ушундай болушу мүмкүн.
Көрүнүп тургандай, жайгаштыруу жогорудагы бардык кадамдардан өтөт жана ~kubectl алуу pods эки поддондун тең иштеп жатканын көрсөтөт. Бирок мурунку жайгаштыруудан айырмаланып, журнал күтүү мөөнөтүн көрсөтөт. Башкача айтканда, ден соолугун текшерүүдөн өтпөй калгандыктан, колдонмонун жаңы версиясын жайылтуу мүмкүн эмес. Натыйжада, сиз тутум тиркеменин эски версиясын колдонууга кайтып келгенин жана жаңы версия жөн гана өчүрүлгөнүн көрөсүз.
Мунун жакшы жери, тиркемеге бир эле учурда көп сандагы суроо-талаптарыңыз болсо да, алар жайылтуу процедурасын ишке ашырууда токтоп калган убакытты байкабай калышат. Эгер сиз бул тиркемени мүмкүн болушунча көп сурамдарды жөнөткөн Gatling алкагынын жардамы менен сынасаңыз, анда бул сурамдардын бири да четке кагылбайт. Бул биздин колдонуучулар реалдуу убакытта версия жаңыртууларын байкабай калышат дегенди билдирет. Эгер ал ишке ашпай калса, эски версияда иш уланат, ал ийгиликтүү болсо, колдонуучулар жаңы версияга өтүшөт.
Бир гана нерсе ишке ашпай калышы мүмкүн - эгерде ден-соолукту текшерүү ийгиликтүү болсо, бирок колдонмо ага иш жүктөмү жүктөлгөндөн кийин иштебей калса, башкача айтканда, кыйроо жайылтуу аяктагандан кийин гана болот. Бул учурда, сиз кол менен эски версияга кайтууга туура келет. Ошентип, биз Kubernetesти ал үчүн иштелип чыккан ачык булак куралдары менен кантип колдонууну карадык. Эгерде сиз бул куралдарды Build/Deploy куурларыңызга курсаңыз, жайылтуу процесси бир топ жеңилдейт. Ошол эле учурда, жайылтууну баштоо үчүн, сиз колдонуучу интерфейсин колдоно аласыз же бул процессти толугу менен автоматташтыра аласыз, мисалы, өздөштүрүү.
Биздин Build Server Docker сүрөтүн түзүп, аны Docker Hub же сиз колдонгон реестрге түртөт. Docker Hub вебхукту колдойт, ошондуктан биз Deployer аркылуу жогоруда көрсөтүлгөн жол менен алыстан жайылтууну иштете алабыз. Ушундай жол менен сиз колдонмоңузду потенциалдуу өндүрүшкө жайылтууну толугу менен автоматташтыра аласыз.
Келгиле, кийинки темага өтөбүз - Kubernetes кластерин масштабдоо. kubectl буйругу масштабдоо буйругу экенин эске алыңыз. Көбүрөөк жардам менен биз учурдагы кластерибиздеги репликалардын санын оңой эле көбөйтө алабыз. Бирок, иш жүзүндө, биз адатта түйүндөрдүн санын көбөйтүүнү каалайбыз.
Ошол эле учурда, жумуш убактысында сиз көбөйтүү керек болушу мүмкүн, ал эми түнкүсүн Amazon кызматтарынын баасын төмөндөтүү үчүн, иштеп жаткан тиркеме инстанцияларынын санын кыскартуу керек болушу мүмкүн. Бул бир гана түйүндөрдүн санын масштабдоо жетиштүү болот дегенди билдирбейт, анткени түйүндөрдүн бири иштебей турган болсо дагы, сиз Amazonга ал үчүн төлөшүңүз керек болот. Башкача айтканда, төө буурчактарды масштабдоо менен бирге, колдонулган машиналардын санын көбөйтүү керек.
Бул кыйын болушу мүмкүн, анткени биз Amazon же башка булут кызматын колдонобузбу, Кубернетес колдонулган машиналардын саны жөнүндө эч нерсе билбейт. Бул түйүн деңгээлинде системаны масштабдатууга мүмкүндүк берген курал жок.
Ошентип, биз түйүндөрдү да, кабыктарды да кам көрүшүбүз керек. Kubernetes жумушчу түйүндөрүнүн санын конфигурациялоо үчүн AWS API жана Scaling тобунун машиналарын колдонуу менен жаңы түйүндөрдү ишке киргизүүнү оңой масштабдай алабыз. Kubernetes кластериндеги түйүндөрдү каттоо үчүн cloud-init же ушуга окшош скриптти да колдонсоңуз болот.
Жаңы машина Scaling тобунда башталат, өзүн түйүн катары баштап, мастердин реестринде катталып, иштей баштайт. Андан кийин, сиз пайда болгон түйүндөрдө колдонуу үчүн репликалардын санын көбөйтө аласыз. Масштабды азайтуу көбүрөөк күч-аракетти талап кылат, анткени мындай кадам "керексиз" машиналарды өчүргөндөн кийин иштеп жаткан тиркемелерди жок кылууга алып келбей турганына ынануу керек. Мындай сценарийдин алдын алуу үчүн түйүндөрдү "пландалбаган" абалына коюу керек. Бул DaemonSet подкасттарын пландаштырууда демейки пландоочу бул түйүндөргө көңүл бурбай турганын билдирет. Пландоочу бул серверлерден эч нерсени жок кылбайт, бирок ал жерде жаңы контейнерлерди ишке киргизбейт. Кийинки кадам - бул дренаждык түйүндү чыгаруу, башкача айтканда, андан башка машинага же бул үчүн жетиштүү кубаттуулугу бар башка түйүндөргө иштеп жаткан поддондорду өткөрүп берүү. Бул түйүндөрдө контейнерлер жок экенине ынанганыңыздан кийин, аларды Kubernetesтен алып салсаңыз болот. Андан кийин, алар жөн гана Kubernetes үчүн жок болот. Андан кийин, керексиз түйүндөрдү же машиналарды өчүрүү үчүн AWS API колдонушуңуз керек.
Сиз Amdatu Scalerd, AWS API окшош башка ачык булак масштабдоо куралын колдоно аласыз. Бул кластердеги түйүндөрдү кошуу же алып салуу үчүн CLI берет. Анын кызыктуу өзгөчөлүгү төмөнкү json файлын колдонуу менен пландаштыргычты конфигурациялоо мүмкүнчүлүгү.
Көрсөтүлгөн код түнкү мезгилде кластердин сыйымдуулугун эки эсеге азайтат. Ал жеткиликтүү репликалардын санын да, Amazon кластеринин каалаган сыйымдуулугун да конфигурациялайт. Бул пландаштыргычты колдонуу түнкү түйүндөрдүн санын автоматтык түрдө азайтып, эртең менен аларды көбөйтүп, Amazon сыяктуу булут сервисинен түйүндөрдү колдонуунун баасын үнөмдөйт. Бул өзгөчөлүк Kubernetes ичине орнотулган эмес, бирок Scalerd колдонуу бул платформаны каалагандай масштабдатууга мүмкүндүк берет.
Көптөр мага: "Мунун баары жакшы, бирок менин маалымат базам жөнүндө эмне айтууга болот?" Кантип Kubernetes сыяктуу динамикалык чөйрөдө ушуга окшош нерсени иштете аласыз? Менин оюмча, сиз муну кылбашыңыз керек, Kubernetesте маалымат кампасын иштетүүгө аракет кылбашыңыз керек. Бул техникалык жактан мүмкүн жана Интернетте бул тема боюнча окуу куралдары бар, бирок бул сиздин жашооңузду олуттуу түрдө татаалдантат.
Ооба, Kubernetes'те туруктуу дүкөндөр деген түшүнүк бар жана сиз Mongo же MySQL сыяктуу маалымат дүкөндөрүн иштетүүгө аракет кылсаңыз болот, бирок бул абдан көп эмгекти талап кылган иш. Бул маалымат кампалары динамикалык чөйрө менен өз ара аракеттенүүнү толук колдобой тургандыгы менен шартталган. Көпчүлүк маалымат базалары олуттуу конфигурацияны, анын ичинде кластердин кол менен конфигурациясын талап кылат, автоскалоону жана башка ушул сыяктуу нерселерди жактырбайт.
Ошондуктан, сиз Кубернетесте маалымат кампасын иштетүүгө аракет кылып, жашооңузду татаалдаштырбашыңыз керек. Тааныш кызматтарды колдонуу менен өз ишин салттуу түрдө уюштуруңуз жана жөн гана Kubernetesке аларды колдонуу мүмкүнчүлүгүн бериңиз.
Теманы жыйынтыктоо үчүн, мен сиздерди менин командам иштеп жаткан Kubernetes негизиндеги Cloud RTI платформасы менен тааныштыргым келет. Ал борборлоштурулган каттоону, тиркемени жана кластердик мониторингди жана башка көптөгөн пайдалуу функцияларды камсыз кылат. Мониторингди көрсөтүү үчүн Grafana сыяктуу ар кандай ачык булак куралдарын колдонот.
Эмне үчүн Ha-proxy жүк балансын Kubernetes менен колдонуш керек деген суроо пайда болду. Жакшы суроо, анткени учурда жүктү балансташтыруунун 2 деңгээли бар. Kubernetes кызматтары дагы эле виртуалдык IP даректеринде жашайт. Аларды тышкы хост машиналарындагы порттор үчүн колдоно албайсыз, анткени Amazon өзүнүн булут хостун ашыкча жүктөсө, дарек өзгөрөт. Мына ошондуктан биз ha-проксиди кызматтардын алдына жайгаштырабыз - трафиктин Кубернетес менен үзгүлтүксүз байланышы үчүн статикалык структураны түзүү.
Дагы бир жакшы суроо - көк/жашыл жайылтууда маалымат базасынын схемасын өзгөртүүгө кантип кам көрө аласыз? Чындыгында, Kubernetes колдонулушуна карабастан, маалымат базасынын схемасын өзгөртүү кыйын иш. Эски жана жаңы схеманын шайкеш келишин камсыздашыңыз керек, андан кийин маалымат базасын жаңыртып, андан кийин тиркемелерди өздөрү жаңырта аласыз. Сиз маалымат базасын ысык алмаштырып, анан тиркемелерди жаңырта аласыз. Мен жаңы схема менен таптакыр жаңы маалымат базасы кластерин жүктөгөн адамдарды билем, эгерде сизде Mongo сыяктуу схемасыз маалымат базаңыз болсо, бул вариант, бирок баары бир бул оңой иш эмес. Башка суроолоруңуз жок болсо, көңүл бурганыңыз үчүн рахмат!
Кээ бир жарнамалар 🙂
Биз менен болгонуңуз үчүн рахмат. Биздин макалалар сизге жагабы? Көбүрөөк кызыктуу мазмунду көргүңүз келеби? Буйрутма берүү же досторуңузга сунуштоо менен бизди колдоңуз, , биз сиз үчүн ойлоп тапкан баштапкы деңгээлдеги серверлердин уникалдуу аналогу: (RAID1 жана RAID10 менен жеткиликтүү, 24 өзөккө чейин жана 40 ГБ DDR4 чейин).
Dell R730xd Амстердамдагы Equinix Tier IV маалымат борборунда 2 эсе арзанбы? Бул жерде гана Нидерландыда! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 доллардан! Жөнүндө окуу
Source: www.habr.com