ProHoster > блог > Администрација > Како да ги поврзете Kubernetes кластерите во различни центри за податоци
Како да ги поврзете Kubernetes кластерите во различни центри за податоци
Добре дојдовте во нашата серија Кубернетес Брз почеток. Ова е редовна рубрика со најинтересните прашања што ги добиваме на интернет и на нашите обуки. Одговори експертот на Кубернетес.
Денешниот експерт е Даниел Поленчик (Даниеле Поленчиќ). Даниел работи како инструктор и развивач на софтвер во Learnk8s.
Доста често, инфраструктурата се реплицира и дистрибуира низ различни региони, особено во контролирани средини.
Ако еден регион е недостапен, сообраќајот се пренасочува во друг за да се избегнат прекини.
Со Kubernetes, можете да користите слична стратегија и да дистрибуирате оптоварувања низ различни региони.
Може да имате еден или повеќе кластери по тим, регион, средина или комбинација од овие елементи.
Вашите кластери може да се сместат во различни облаци и во простории.
Но, како планирате инфраструктура за такво географско ширење?
Дали треба да креирате еден голем кластер за неколку облак околини преку една мрежа?
Или имате многу мали кластери и најдете начин да ги контролирате и синхронизирате?
Еден лидерски кластер
Создавањето еден кластер преку една мрежа не е толку лесно.
Замислете дека имате несреќа, поврзаноста помеѓу сегментите на кластерот е изгубена.
Ако имате еден главен сервер, половина од ресурсите нема да можат да примаат нови команди бидејќи нема да можат да контактираат со господарот.
И во исто време имате стари табели за насочување (kube-proxy не може да презема нови) и нема дополнителни подлоги (кубелет не може да бара ажурирања).
Работите да бидат уште полоши, ако Kubernetes не види јазол, го означува како сираче и ги дистрибуира деловите што недостасуваат до постоечките јазли.
Како резултат на тоа, имате двојно повеќе мешунки.
Ако направите еден главен сервер за секој регион, ќе има проблеми со консензусниот алгоритам во базата на податоци etcd. (прибл. ед. — Всушност, базата на податоци etcd не мора нужно да се наоѓа на главните сервери. Може да се извршува на посебна група сервери во истиот регион. Точно, во исто време добивате точка на неуспех на кластерот. Но брзо.)
etcd користи сплав алгоритамда се преговара за вредноста пред да се запише на дискот.
Односно, мнозинството случаи мора да постигнат консензус пред државата да биде напишана на итн.
Ако доцнењето помеѓу примероците на etcd драматично се зголеми, како што е случајот со три примероци на etcd во различни региони, потребно е долго време да се преговара за вредност и да се запише на дискот.
Ова се рефлектира во контролорите на Kubernetes.
На менаџерот на контролорот му треба повеќе време за да дознае за промената и да го напише одговорот во базата на податоци.
И бидејќи нема еден контролер, туку неколку, резултира со верижна реакција и целиот кластер почнува да работи многу бавно.
Во моментов нема добри примери за голема мрежа за еден кластер.
Во основа, заедницата на програмери и групата SIG-кластери се обидуваат да откријат како да ги оркестрираат кластерите на ист начин како што Kubernetes ги оркестрира контејнерите.
За прв пат, се обидовме да управуваме со збирка кластери како единствен објект користејќи ја алатката за федерација kube.
Почетокот беше добар, но на крајот Кубе федерацијата никогаш не стана популарна затоа што не ги поддржуваше сите ресурси.
Поддржуваше федерални испораки и услуги, но не и StatefulSets, на пример.
Исто така, конфигурацијата на федерацијата беше пренесена во форма на прибелешки и не беше флексибилна.
Замислете како можете да ја опишете поделбата на репликата за секој кластер во федерацијата користејќи само прибелешки.
Беше целосен хаос.
SIG-cluster направи многу работа по kubefed v1 и реши да му пристапи на проблемот од поинаков агол.
Наместо прибелешки, тие одлучија да пуштат контролер кој е инсталиран на кластери. Може да се прилагоди со користење на прилагодени дефиниции за ресурси (CRD).
За секој ресурс што ќе биде дел од федерацијата, имате прилагодена дефиниција за CRD со три секции:
стандардна дефиниција на ресурс, на пример распоредување;
дел placement, каде што дефинирате како ќе се дистрибуира ресурсот во федерацијата;
дел override, каде што за одреден ресурс можете да ја отфрлите тежината и параметрите од поставеноста.
Еве пример за комбинирана испорака со секции за поставување и префрлање.
Опција 2: комбинирање кластери во стилот на Booking.com
Програмерите на Booking.com не работеа на kubefed v2, туку смислија Shipper - оператор за испорака на неколку кластери, во неколку региони и во неколку облаци.
Двете алатки ви дозволуваат да ја приспособите стратегијата за распоредување на повеќе кластери (кои кластери се користат и колку реплики имаат).
Но Целта на испраќачот е да го намали ризикот од грешки при испораката.
Во Доставувачот, можете да дефинирате серија чекори што ја опишуваат поделбата на репликите помеѓу претходното и тековното распоредување и обемот на дојдовниот сообраќај.
Кога туркате ресурс во кластерот, контролорот на испраќачот постепено ја пренесува таа промена низ сите споени кластери.
Исто така, испраќачот е многу ограничен.
На пример, ги прифаќа табелите на кормилото како влез и не поддржува ресурси од ванила.
Општо земено, Shipper работи вака.
Наместо стандардна испорака, треба да креирате ресурс за апликација што вклучува дијаграм на Helm:
Но, наместо да се смисли нов начин за интеракција со кластерот и да се заокружат ресурсите во прилагодени дефиниции, распоредувачот на повеќе кластери е вграден во стандардниот животен циклус на Kubernetes и ги пресретнува сите повици што создаваат подлоги.
Секоја создадена мешунка веднаш се заменува со кукла.
Оригиналната мешунка минува низ друг циклус на планирање каде што, по анкетирањето на целата федерација, се донесува одлука за пласман.
Конечно, подлогата се доставува до целниот кластер.
Како резултат на тоа, имате дополнителна подлога што не прави ништо, само зафаќа простор.
Предноста е што не требаше да пишувате нови ресурси за да ги комбинирате набавките.
Секој ресурс што создава подлога е автоматски подготвен за спојување.
Ова е интересно, бидејќи одеднаш имате залихи дистрибуирани низ неколку региони, а не сте ни забележале. Сепак, ова е доста ризично, бидејќи сè овде почива на магија.
Но, додека Shipper се обидува најмногу да го ублажи влијанието на испораките, распоредувачот со повеќе кластери се справува со поопшти задачи и можеби е подобро прилагоден за сериски работи.
Нема напреден механизам за постепена испорака.
Повеќе за распоредувачот на повеќе кластери може да најдете на официјална страница на складиштето.
Ако сакате да прочитате за распоредувачот со повеќе кластери во акција, Admiralty има интересна употреба со Argo — работни текови, настани, CI и CD Kubernetes.
Други алатки и решенија
Поврзувањето и управувањето со повеќе кластери е сложена задача и не постои универзално решение.
Ако сакате дополнително да ја истражите оваа тема, еве неколку ресурси:
Подморница од Ранчер е алатка која поврзува преклопени мрежи на различни кластери на Кубернет.
Цилиум, приклучок за мрежен интерфејс за контејнери, нуди кластер мрежа функција, кој ви овозможува да комбинирате неколку кластери
Тоа е се за денес
Ви благодариме што прочитавте до крај!
Ако знаете како поефикасно да поврзете повеќе кластери, Кажи НИ.
Ќе го додадеме вашиот метод на врските.
Посебна благодарност до Крис Несбит-Смит (Крис Несбит-Смит) и Винсент де Сме (Винсент Де Смет) (инженер за доверливост во swatmobile.io) за читање на статијата и споделување корисни информации за тоа како функционира федерацијата.