ProHoster > Блог > басқарма > Әртүрлі деректер орталықтарында Kubernetes кластерлерін қалай қосуға болады
Әртүрлі деректер орталықтарында Kubernetes кластерлерін қалай қосуға болады
Kubernetes Quick Start сериясына қош келдіңіз. Бұл онлайн және тренингтерімізде бізге түсетін ең қызықты сұрақтары бар тұрақты айдар. Kubernetes сарапшысы жауап береді.
Бүгінгі сарапшы - Даниэль Поленчик (Даниэле Поленчич). Даниел нұсқаушы және бағдарламалық жасақтаманы әзірлеуші болып жұмыс істейді Learnk8s.
Көбінесе инфрақұрылым әртүрлі аймақтарда, әсіресе басқарылатын орталарда қайталанады және таратылады.
Бір аймақ қолжетімсіз болса, кедергілерді болдырмау үшін трафик басқа аймаққа қайта бағытталады.
Kubernetes көмегімен сіз ұқсас стратегияны пайдалана аласыз және жұмыс жүктемелерін әртүрлі аймақтарға тарата аласыз.
Әр топ, аймақ, орта немесе осы элементтердің тіркесімі үшін бір немесе бірнеше кластер болуы мүмкін.
Кластерлеріңізді әртүрлі бұлттарда және жергілікті жерде орналастыруға болады.
Бірақ мұндай географиялық таралу үшін инфрақұрылымды қалай жоспарлайсыз?
Бір желі арқылы бірнеше бұлттық орталар үшін бір үлкен кластерді жасау керек пе?
Немесе көптеген шағын кластерлер бар және оларды басқару және синхрондау жолын табасыз ба?
Бір көшбасшылық кластер
Бір желіде бір кластерді құру оңай емес.
Сізде апат болды деп елестетіп көріңіз, кластер сегменттері арасындағы байланыс жоғалды.
Егер сізде бір негізгі сервер болса, ресурстардың жартысы жаңа пәрмендерді ала алмайды, себебі олар шебермен байланыса алмайды.
Сонымен қатар сізде ескі маршруттау кестелері бар (kube-proxy жаңаларын жүктеп ала алмайды) және қосымша қосқыштар жоқ (kubelet жаңартуларды сұрай алмайды).
Нашарлау үшін, егер Кубернетес түйінді көрмесе, оны жетім деп белгілеп, жетіспейтін түйіндерді бар түйіндерге таратады.
Нәтижесінде сізде екі есе көп бүршіктер бар.
Әрбір аймақ үшін бір басты сервер жасасаңыз, etcd дерекқорындағы консенсус алгоритміне қатысты мәселелер туындайды. (шамамен. ред. — Шын мәнінде, etcd дерекқоры міндетті түрде негізгі серверлерде орналасуы қажет емес. Оны бір аймақтағы серверлердің бөлек тобында іске қосуға болады. Рас, сонымен қатар кластердің сәтсіз нүктесін алу. Бірақ тез.)
т.б. пайдаланады сал алгоритмідискіге жазбас бұрын мәнді келісу үшін.
Яғни, мемлекет және т.б.-ге жазбас бұрын даналардың көпшілігі консенсусқа жетуі керек.
Әртүрлі аймақтардағы үш etcd данасы сияқты, etcd даналарының арасындағы кідіріс күрт артса, мәнді келісу және оны дискіге жазу көп уақытты алады.
Бұл Kubernetes контроллерлерінде көрсетілген.
Контроллер менеджеріне өзгерту туралы білу және дерекқорға жауапты жазу үшін көбірек уақыт қажет.
Бір емес, бірнеше контроллер болғандықтан, тізбекті реакция пайда болады және бүкіл кластер өте баяу жұмыс істей бастайды.
Қазіргі уақытта бір кластер үшін үлкен желінің жақсы үлгілері жоқ.
Негізінде әзірлеушілер қауымдастығы мен SIG кластері тобы Кубернетес контейнерлерді реттейтіндей кластерлерді қалай ұйымдастыру керектігін анықтауға тырысады.
Алғаш рет біз kube федерациясы құралын пайдаланып кластерлер жинағын бір нысан ретінде басқаруға тырыстық.
Басталуы жақсы болды, бірақ соңында кубе федерациясы ешқашан танымал бола алмады, өйткені ол барлық ресурстарды қолдамады.
Ол, мысалы, StatefulSets емес, федеративтік жеткізілімдер мен қызметтерге қолдау көрсетті.
Сондай-ақ, федерация конфигурациясы аннотациялар түрінде берілді және икемді болмады.
Тек аннотацияларды пайдаланып, федерациядағы әрбір кластер үшін реплика бөлімін қалай сипаттауға болатынын елестетіп көріңіз.
Бұл толық тәртіпсіздік болды.
SIG-кластері kubefed v1-ден кейін көп жұмыс жасады және мәселеге басқа қырынан қарауды шешті.
Аннотациялардың орнына олар кластерлерде орнатылған контроллерді шығаруды шешті. Оны Custom Resource Definitions (CRDs) арқылы теңшеуге болады.
Федерацияның бөлігі болатын әрбір ресурс үшін сізде үш бөлімнен тұратын теңшелетін CRD анықтамасы бар:
Booking.com әзірлеушілері kubefed v2-де жұмыс істемеді, бірақ олар Shipper - бірнеше кластерлерде, бірнеше аймақтарда және бірнеше бұлттарда жеткізуге арналған операторды ойлап тапты.
Екі құрал да көп кластерді орналастыру стратегияңызды (қай кластерлер пайдаланылады және олардың қанша көшірмелері бар) теңшеуге мүмкіндік береді.
бірақ Жүк жөнелтушінің мақсаты жеткізу кезінде қателер қаупін азайту болып табылады.
Жөнелтушіде алдыңғы және ағымдағы орналастыру және кіріс трафик көлемі арасындағы көшірмелердің бөлінуін сипаттайтын қадамдар қатарын анықтауға болады.
Ресурсты кластерге итергенде, жөнелтуші контроллері барлық біріктірілген кластерлерде бұл өзгерісті біртіндеп шығарады.
Сондай-ақ, жөнелтуші өте шектеулі.
Мысалы, ол кіріс диаграммаларын қабылдайды және ванильді ресурстарды қолдамайды.
Жалпы алғанда, Shipper осылай жұмыс істейді.
Стандартты жеткізудің орнына Helm диаграммасын қамтитын қолданба ресурсын жасау керек:
Бірақ кластермен өзара әрекеттесу және ресурстарды реттелетін анықтамаларға орау үшін жаңа жолды ойлап табудың орнына, көп кластер-жоспарлағыш стандартты Kubernetes өмірлік цикліне ендірілген және подкасттарды жасайтын барлық қоңырауларды ұстайды.
Әрбір жасалған подвод бірден манекенмен ауыстырылады.
Түпнұсқа подкаст басқа жоспарлау циклінен өтеді, онда бүкіл федерацияны сұраудан кейін орналастыру туралы шешім қабылданады.
Соңында, подвод мақсатты кластерге жеткізіледі.
Нәтижесінде сізде ешнәрсе жасамайтын, жай ғана орын алатын қосымша қақпақ бар.
Артықшылығы мынада: жабдықты біріктіру үшін жаңа ресурстарды жазудың қажеті жоқ.
Қондырғы жасайтын әрбір ресурс біріктіруге автоматты түрде дайын болады.
Бұл қызық, өйткені кенеттен сізде бірнеше аймақтарға жеткізілген материалдар пайда болды және сіз тіпті байқамай қалдыңыз. Дегенмен, бұл өте қауіпті, өйткені мұнда бәрі сиқырға негізделген.
Бірақ жөнелтуші негізінен жеткізілімдердің әсерін азайтуға тырысқанымен, көп кластерлік жоспарлаушы жалпылама тапсырмаларды орындайды және пакеттік тапсырмалар үшін жақсырақ болуы мүмкін.
Оның біртіндеп жеткізудің жетілдірілген механизмі жоқ.
Көп кластерді жоспарлаушы туралы қосымша ақпаратты мына жерден табуға болады ресми репозиторий беті.
Егер сіз көп кластерлік жоспарлаушы туралы оқығыңыз келсе, Admiralty бар Аргомен қызықты пайдалану жағдайы — жұмыс үрдістері, оқиғалар, CI және CD Kubernetes.
Басқа құралдар мен шешімдер
Бірнеше кластерді қосу және басқару күрделі міндет және әмбебап шешім жоқ.
Егер сіз осы тақырыпты әрі қарай зерттегіңіз келсе, мұнда кейбір ресурстар:
Ранчердің сүңгуір қайығы әртүрлі Kubernetes кластерлерінің қабаттасатын желілерін қосатын құрал.
Cilium, контейнерлік желі интерфейсінің плагині ұсынады кластерлік тор функциясы, бұл бірнеше кластерді біріктіруге мүмкіндік береді
Бүгінгі күннің бәрі осы
Соңына дейін оқығаныңызға рахмет!
Бірнеше кластерді тиімдірек қосу жолын білсеңіз, бізге айт.
Біз сіздің әдісіңізді сілтемелерге қосамыз.
Крис Несбитт-Смитке ерекше рахмет (Крис Несбит-Смит) және Винсент де Сме (Винсент Де Смет) (сенімділік бойынша инженер swatmobile.io) мақаланы оқып, федерацияның жұмысы туралы пайдалы ақпаратпен бөліскеніңіз үшін.