Менин атым Сергей, мен ITSummaдан болом жана мен сизге Кубернетестеги ашыкча мамилеге кандай карай турганыбызды айткым келет. Акыркы убакта мен ар кандай командалар үчүн ар кандай devops чечимдерин ишке ашыруу боюнча көп консультациялык иштерди аткарып жатам жана, атап айтканда, мен K8s колдонуп долбоорлор менен тыгыз иштешип жатам. Татаал архитектуралардагы ашыкчалыкка арналган Uptime day 4 конференциясында мен "кубдун" ашыкчалыгы жөнүндө презентация жасадым жана бул жерде анын эркин баяны. Мен алдын ала эскертип коеюн, бул иш-аракетке түздөн-түз жетекчилик эмес, тескерисинче, бул тема боюнча ойлорду жалпылоо.
Негизи, мониторинг жана ашыкча ар кандай долбоордун катачылыкка чыдамдуулугун жогорулатуунун эки негизги куралы болуп саналат. Бирок куберде баары тең салмакта, баары өзүнөн өзү таразалайт дейсиң, бир нерсе болуп кетсе өзүнөн өзү көтөрүлөт... Тактап айтканда, теманы биринчи үстүртөн изилдөө учурунда, K8s резервациясына ким кандай мамиле кылат деген суроого , Интернет мага "эмне үчүн?" Көптөгөн адамдар куберди бардык инфраструктуралык көйгөйлөрдөн арылтып, долбоор эч качан ишке ашпай тургандай сыйкырдуу нерсе деп ойлошот. Бирок... дүйнө көрүнгөндөй эмес.
Камдык көчүрмөнү сактоо процессине мурда кандай мамиле кылчубуз? Бизде бирдей хостинг платформалары болгон — виртуалдык же аппараттык болобу. серверлер, анда биз үч негизги тажрыйбаны колдондук:
- код менен статиканы синхрондоштуруу
- конфигурацияны синхрондоштуруу
- маалымат базасын репликациялоо
Жана войла: каалаган учурда биз резервдик сайтка которулабыз, бардыгы кубанышат, биз туруп кетебиз.
Биздин kubernetes тиркемесинин дайыма жеткиликтүүлүгүн жогорулатуу үчүн алар бизге эмнени сунуштайт? Бейрасмий документацияда айтылган биринчи нерсе - көп машиналарды орнотуу, көп мастерлерди жасоо - алардын саны кластердин ичинде кворумга жетүү шарттарын канааттандырышы керек жана ар бирине etcd, api, MC, пландоочу орнотулушу керек. мастерлер... Жана, баары жакшы окшойт : Эгерде бир нече жумушчу түйүндөр же мастерлер иштебей калса, биздин кластер балансташып, тиркеме иштей берет. Кайра сыйкырдуу окшойт! Бирок көбүнчө биздин кластер бир маалымат борборунун ичинде жайгашкан жана бул белгилүү суроолорду жаратышы мүмкүн. Экскаватор келип кабелди казып, чагылган тийип, дүйнөлүк суу ташкыны болуп кетсечи? Баары камтылган, биздин кластер мындан ары жок. Проблеманын ушул жагын эске алуу менен резервацияларга кандай мамиле кылуу керек?
Биринчиден, сизде ысык күтүү режиминде дагы бир кластер болушу керек, башкача айтканда, каалаган убакта которула турган кластер. Анын үстүнө, кубдун көз карашынан алганда, инфраструктуралар толугу менен бирдей болушу керек. Башкача айтканда, файл системасы менен иштөө үчүн кандайдыр бир стандарттуу эмес плагиндер, кирүү үчүн ыңгайлаштырылган чечимдер бар болсо, алар сиздин экөөңүздө толугу менен бирдей болушу керек (же үч же он, канча акча жана администратордун күчү жетиштүү экендигине жараша) кластерлер. Тиркемелердин эки топтомун так аныктоо керек (жайгаштыруулар, абалды аныктоочу топтомдор, демонсеттер, кронжобдор ж.б.): алардын кайсынысы дайыма күтүү режиминде иштей алат жана кайсынысы иш жүзүндө которулганга чейин иштетилбейт.
Демек, биздин резервдик кластер биздин согуштук кластерге толугу менен окшош болушу керекпи? Жок. Эгерде мурда монолиттүү долбоорлор менен, аппараттык инфраструктура менен иштөөдө биз дээрлик толугу менен бирдей чөйрөнү сактап калган болсок, анда кубердин алкагында мындай болбошу керек деп ойлойм. Келгиле, эмне үчүн экенин карап көрөлү.
Мисалы, Kubernetesтин негизги объектилеринен баштайлы - жайылтуулар - алар бирдей болушу керек. Каалаган убакта трафикти иштетүүгө тоскоол боло турган жана биздин долбоордун жашоосун уланта турган тиркемелерди ишке киргизүү керек. Эгер конфигурация файлдары жөнүндө сөз болсо, анда алар окшош болушу керекпи же жокпу, карап чыгышыбыз керек. Башкача айтканда, биз, акылдуу адамдар, эч кандай тыюу салынган заттарды колдонбосок жана K8де базаны сактабасак, анда биздин конфигмамаларда согуштук базага кирүү үчүн орнотуулар болушу керек (брондоо процесси өзүнчө курулган). Демек, резервдик маалымат базасынын инстанциясына кирүү мүмкүнчүлүгүн камсыз кылуу үчүн бизде өзүнчө конфигурация файлы (конфигмап) болушу керек. Биз сырлар менен дал ушундай иштейбиз: маалымат базасына кирүү үчүн сырсөздөр, api ачкычтары; Каалаган убакта бизде согуштук сыр же резервдик сыр болушу мүмкүн. Жалпысынан бизде эки кубернет объекти бар, алардын резервдик версиялары өндүрүштүк версияларга окшош болбошу керек. Кийинки көңүл бура турган объект - cronjob. Резервдеги кронжобдор эч кандай шартта өндүрүш кластериндеги кронжобдордун жыйындысына окшош болбошу керек! Эгерде биз камдык кластерди көтөрүп, аны бардык cronjobs иштетилген менен толугу менен көтөрсөк, анда, мисалы, адамдар бир эле учурда сизден бир каттын ордуна эки кат алышат. Же тышкы булактар менен маалыматтарды синхрондоштуруунун кандайдыр бир түрү эки жолу ишке ашат, ошого жараша биз ооруп, ыйлап, кыйкырып, сөгүп баштайбыз.
Интернеттеги адамдар ашыкча кластерди уюштурууну кантип сунушташат? Экинчи эң популярдуу жооп "эмне үчүн?" - Kubernetes федерациясын колдонуу.
Бул эмне? Бул, айталы, чоң мета-кластер. Эгерде биз Кубердин архитектурасын элестетсек - анда бизде мастер, бир нече түйүн бар - анда федерациянын көз карашынан алганда, бизде да мастер жана бир нече түйүн бар, ар бир түйүн өзүнчө кластер гана. Башкача айтканда, биз ошол эле объекттер менен, ошол эле примитивдер менен, бир эле куб менен иштейбиз, бир гана физикалык машиналарыбыз менен эмес, бүтүндөй кластерлер менен бурулуп, айлантабыз. Федерациянын алкагында бизде ата-энелерден урпактарга чейин федеративдүү ресурстарды толук синхрондоштуруу бар. Мисалы, федерация аркылуу кандайдыр бир жайылтууну ишке киргизсек, ал биздин ар бир бала кластерибизге жайылтылат. Эгерде биз кандайдыр бир конфигмапты, сырды алып, аны федерацияга жайылтсак, ал биздин бардык балдар кластерлерине тарайт; Ошол эле учурда федерация биздин ресурстарды балдарга ылайыкташтырууга мүмкүнчүлүк берет. Башкача айтканда, биз конфигматикалык картаны алдык, аны федерация аркылуу жайгаштырдык, анан конкреттүү кластерлерде бир нерсени оңдоо керек болсо, биз аны өзүнчө кластерге түзөтүүгө барабыз жана бул өзгөртүү эч жерде синхрондоштурууга болбойт.
Kubernetes Federation - бул жакында эле иштеп жаткан курал жана ал K8s өзү камсыз кылган ресурстардын толук топтомун колдобойт: документациянын биринчи версияларынын бири жарыяланган учурда, ал конфигурацияланган карталарды гана колдоо, репликаны жайылтуу жөнүндө айткан. коюу, жана кирүү. Сырлар колдоого алынган эмес, көлөм менен иштөө да колдоого алынган эмес. Өтө чектелген топтом. Айрыкча, эгер биз көңүл ачууну кааласак, мисалы, жеке ресурстарыбызды кубернеттерге ыңгайлаштырылган ресурс аныктамасы аркылуу өткөрүп берсек, биз аларды федерацияга түртпөйбүз. Башкача айтканда, бул ... чындыкка абдан окшош чечим, бирок ал бизди мезгил-мезгили менен бутубузга атып салууга мажбурлайт. Экинчи жагынан, федерация биздин репликасетибизди ийкемдүү башкарууга мүмкүнчүлүк берет. Мисалы, биз колдонмобуздун 10 репликасынын иштешин каалайбыз, демейки боюнча федерация бул санды кластерлердин санына пропорционалдуу түрдө бөлүштүрөт. Мунун баарын конфигурациялоого болот! Башкача айтканда, ресурстарды үнөмдөө үчүн же өзүңүздүн көңүл ачууңуз үчүн биздин тиркеменин 6 репликасын согуштук кластерде, ал эми резервдик кластерде биздин тиркеменин 4 гана репликасын сактоо керек экенин белгилей аласыз. Бул да абдан ыңгайлуу. Бирок федерация менен биз жаңы чечимдерди колдонушубуз керек, баратып бир нерсени иштеп чыгышыбыз керек, өзүбүздү дагы бир аз ойлонууга мажбурлашыбыз керек ...
Куберди ээлөө процессине жакыныраак жол барбы? Бизде кандай куралдар бар?
Биринчиден, бизде ар дайым кандайдыр бир ci/cd системасы бар, башкача айтканда, серверлерди түзүү/колдонуу боюнча кол менен барбайбыз же жазбайбыз. Система биздин контейнерлер үчүн ямлдерди жаратат.
Экинчиден, бир нече кластерлер бар, бизде бир же бир нече (эгер акылдуу болсок) реестр бар, аларды биз да алып, резервге алганбыз. Жана бир эле учурда бир нече кластерлер менен иштей ала турган kubectl деген сонун утилита бар.
Ошентип: менин оюмча, резервдик кластерди куруу үчүн эң жөнөкөй жана эң туура чечим - бул примитивдүү параллелдүү жайгаштыруу. ci/cd системасында кандайдыр бир түтүк бар; Биринчиден, биз контейнерлерибизди куруп, кубectl аркылуу бир нече көз карандысыз кластерлерге тиркемелерди сынап, жайылтабыз. Биз бир нече кластерлер үчүн бир эле убакта эсептөөлөрдү түзө алабыз. Демек, биз да ушул этапта конфигурацияларды жеткирүү жөнүндө чечим кабыл алабыз. Биз согуштук кластерибиз үчүн конфигурациялардын топтомун, резервдик кластер үчүн конфигурациялардын топтомун алдын ала аныктай алабыз жана ci/cd тутумунун деңгээлинде тамак-аш чөйрөсүн азык-түлүк кластерине, резервдик чөйрөнү камдык көчүрмөгө чыгара алабыз. кластер. Федерацияга салыштырмалуу, федеративдүү ресурсту аныктагандан кийин, ар бир бала кластерине барып, бир нерсени кайра аныктоонун кажети жок. Биз муну алдын ала жасаганбыз. Биз кандай сонун адамдарбыз.
Бирок... бар... Мен жаздым, “бардык жамандыктын тамыры” бар, бирок чындыгында алардын экөөсү бар. Биринчиден, файл системасы. PV кандайдыр бир түрү бар, же биз тышкы сактагычты колдонобуз. Эгерде биз файлдарды кластердин ичинде сактасак, анда биз аппараттык инфраструктуралардын күндөрүнөн калган эски тажрыйбаларды аткарышыбыз керек: мисалы, lsync менен синхрондоштуруу. Ооба, же жеке сиз каалаган башка балдак. Биз баарын башка унааларга салып, жашап жатабыз.
Экинчи, жана чындыгында андан да маанилүү жабышчаак чекит, маалымат базасы болуп саналат. Эгерде биз акылдуу адамдар болсок жана маалымат базасын куберде сактабасак, анда маалыматтардын камдык көчүрмөсүн сактоо процесси ошол эле эски схема боюнча жүрөт - мастер-кул репликациясы, андан кийин которулуу, биз репликаны кууп жетип, жакшы жашайбыз. Бирок, эгерде биз МБны кластердин ичинде сактасак, анда, негизинен, бир эле мастер-кул репликасын уюштуруу үчүн көптөгөн даяр чечимдер жана кубдун ичинде МБны көбөйтүү үчүн көптөгөн чечимдер бар.
Маалымат базасынын резервдик көчүрмөсү жөнүндө миллиарддаган отчеттор окулду, миллиард макалалар жазылды, жана, так айтканда, бул жерде жаңы эч нерсе керек эмес. Дегеле, кыялыңдын артынан ээрчи, каалаганыңдай жаша, өзүң үчүн бир нече татаал балдактарды ойлоп таб, бирок мунун баарын кантип сактай турганыңды ойлон.
Келгиле, өрт чыккан учурда бизде резервдик сайтка өтүү процесси кандай болору жөнүндө сүйлөшөлү. Биринчиден, биз жарандыгы жок тиркемелерди параллелдүү жайгаштырабыз. Алар биздин тиркемелерибиздин, биздин долбоордун бизнес логикасына эч кандай таасир этпейт, биз эки тиркеме топтомун үзгүлтүксүз иштете алабыз жана алар трафикти ала башташат. Камдык сайтка өтүү процессин карап көрүү абдан маанилүү: конфигурацияларды кайра аныктоо керекпи? Мисалы, бизде өндүрүштүк Kubernetes кластери, камдык Kubernetes кластери, тышкы башкы маалымат базасы жана резервдик башкы маалымат базасы бар. Биз өндүрүштөгү бул тиркемелер бири-бири менен өз ара аракеттене башташы үчүн төрт вариантыбыз бар. Биздин маалымат базабыз өзгөрүшү мүмкүн, жана биз тамак-аш кластериндеги трафикти жаңы базага которуу керек экен, же биздин кластер иштебей калышы мүмкүн - жана биз резервге өттүк, бирок тамак-аш базасы менен иштөөнү улантабыз, жакшы, үчүнчү параметр, бул биз менен болгон кезде, ошондой болду жана биз эки тиркемени тең алмаштырып, жаңы колдонмолор жаңы маалымат базасы менен иштеши үчүн конфигурациябызды кайра аныктайбыз.
Ооба, чындыгында, мунун баарынан кандай жыйынтык чыгарууга болот?
Биринчи корутунду: жашоо резерв менен жакшы. Бирок бул кымбат. Бирок идеалдуу түрдө бирден ашык резерв менен жаша. Идеалында, сиз жалпысынан бир нече коруктар менен жашашыңыз керек. Биринчиден, резерв, жок эле дегенде, бир DC, экинчиден, жок эле дегенде, башка хостерде болушу керек. Бул көп учурда болгон - жана менин практикамда мындай болгон. Тилекке каршы, мен долбоорлорду атай албайм, маалымат борборунда өрт чыкканда эле... Мен: резервге өтөлү! Ал эми резервдик серверлер бир стеллажда болгон ...
Же Амазонка Орусияда тыюу салынганын элестетиңиз (жана ушундай болду). Мунун баары: биздин коруктун башка Амазонкада жайгашканынын эмне кереги бар? Ал да жеткиликсиз. Ошентип, мен дагы бир жолу кайталайм: биз резервди, эң аз дегенде, башка DCда, жана эң жакшысы башка хосттерде сактайбыз.
Экинчи корутунду: эгерде сиздин кубедеги тиркемеңиз кээ бир тышкы булактар менен байланышса (бул маалымат базасы же кандайдыр бир тышкы api болушу мүмкүн), которуштуруу учурунда кайра жайылтпоо үчүн аны тышкы Endpoint менен кызмат катары аныктоону унутпаңыз. Бир эле базада тыкылдап жаткан 15 арызыңыз. Маалыматтар базасын өзүнчө кызмат катары аныктаңыз, аны өз кластериңиздин ичинде жүргөндөй тыкылдатыңыз: эгерде сизде маалымат базасы бар болсо, анда сиз IPди бир жерден алмаштырып, бактылуу жашай бересиз.
Акыр-аягы: мен "кубду" жакшы көрөм, ошондой эле аны менен болгон эксперименттер. Мен дагы бул эксперименттердин натыйжалары жана жалпысынан жеке тажрыйбам менен бөлүшкүм келет. Ошондуктан мен K8 жөнүндө бир катар вебинарларды жаздым, кош келиңиз чоо-жайы үчүн.
Source: www.habr.com
