Добре дојдовте во нашата серија Кубернетес Брз почеток. Ова е редовна рубрика со најинтересните прашања што ги добиваме на интернет и на нашите обуки. Одговори експертот на Кубернетес.
Денешниот експерт е Даниел Поленчик (). Даниел работи како инструктор и развивач на софтвер во .
Ако сакате одговорот на вашето прашање во следниот пост, или .
Ги пропуштивте претходните објави? .
Како да ги поврзете кластерите на Kubernetes во различни центри за податоци?
Накратко: , а јас исто така препорачувам да прочитате за и .
Доста често, инфраструктурата се реплицира и дистрибуира низ различни региони, особено во контролирани средини.
Ако еден регион е недостапен, сообраќајот се пренасочува во друг за да се избегнат прекини.
Со Kubernetes, можете да користите слична стратегија и да дистрибуирате оптоварувања низ различни региони.
Може да имате еден или повеќе кластери по тим, регион, средина или комбинација од овие елементи.
Вашите кластери може да се сместат во различни облаци и во простории.
Но, како планирате инфраструктура за такво географско ширење?
Дали треба да креирате еден голем кластер за неколку облак околини преку една мрежа?
Или имате многу мали кластери и најдете начин да ги контролирате и синхронизирате?
Еден лидерски кластер
Создавањето еден кластер преку една мрежа не е толку лесно.
Замислете дека имате несреќа, поврзаноста помеѓу сегментите на кластерот е изгубена.
Ако имате еден главен сервер, половина од ресурсите нема да можат да примаат нови команди бидејќи нема да можат да контактираат со господарот.
И во исто време имате стари табели за насочување (kube-proxy не може да презема нови) и нема дополнителни подлоги (кубелет не може да бара ажурирања).
Работите да бидат уште полоши, ако Kubernetes не види јазол, го означува како сираче и ги дистрибуира деловите што недостасуваат до постоечките јазли.
Како резултат на тоа, имате двојно повеќе мешунки.
Ако направите еден главен сервер за секој регион, ќе има проблеми со консензусниот алгоритам во базата на податоци etcd. (прибл. ед. — Всушност, базата на податоци etcd не мора нужно да се наоѓа на главните сервери. Може да се извршува на посебна група сервери во истиот регион. Точно, во исто време добивате точка на неуспех на кластерот. Но брзо.)
etcd користи да се преговара за вредноста пред да се запише на дискот.
Односно, мнозинството случаи мора да постигнат консензус пред државата да биде напишана на итн.
Ако доцнењето помеѓу примероците на etcd драматично се зголеми, како што е случајот со три примероци на etcd во различни региони, потребно е долго време да се преговара за вредност и да се запише на дискот.
Ова се рефлектира во контролорите на Kubernetes.
На менаџерот на контролорот му треба повеќе време за да дознае за промената и да го напише одговорот во базата на податоци.
И бидејќи нема еден контролер, туку неколку, резултира со верижна реакција и целиот кластер почнува да работи многу бавно.
etcd е толку чувствителен на латентност што .
Во моментов нема добри примери за голема мрежа за еден кластер.
Во основа, заедницата на програмери и групата SIG-кластери се обидуваат да откријат како да ги оркестрираат кластерите на ист начин како што Kubernetes ги оркестрира контејнерите.
Опција 1: кластерска федерација со kubefed
Официјален одговор од SIG-кластерот - .
За прв пат, се обидовме да управуваме со збирка кластери како единствен објект користејќи ја алатката за федерација kube.
Почетокот беше добар, но на крајот Кубе федерацијата никогаш не стана популарна затоа што не ги поддржуваше сите ресурси.
Поддржуваше федерални испораки и услуги, но не и StatefulSets, на пример.
Исто така, конфигурацијата на федерацијата беше пренесена во форма на прибелешки и не беше флексибилна.
Замислете како можете да ја опишете поделбата на репликата за секој кластер во федерацијата користејќи само прибелешки.
Беше целосен хаос.
SIG-cluster направи многу работа по kubefed v1 и реши да му пристапи на проблемот од поинаков агол.
Наместо прибелешки, тие одлучија да пуштат контролер кој е инсталиран на кластери. Може да се прилагоди со користење на прилагодени дефиниции за ресурси (CRD).
За секој ресурс што ќе биде дел од федерацијата, имате прилагодена дефиниција за CRD со три секции:
- стандардна дефиниција на ресурс, на пример распоредување;
- дел
placement, каде што дефинирате како ќе се дистрибуира ресурсот во федерацијата; - дел
override, каде што за одреден ресурс можете да ја отфрлите тежината и параметрите од поставеноста.
Еве пример за комбинирана испорака со секции за поставување и префрлање.
apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
name: test-deployment
namespace: test-namespace
spec:
template:
metadata:
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
placement:
clusterNames:
- cluster2
- cluster1
overrides:
- clusterName: cluster2
clusterOverrides:
- path: spec.replicas
value: 5Како што можете да видите, понудата е дистрибуирана во два кластери: cluster1 и cluster2.
Првиот кластер обезбедува три реплики, а вториот е поставен на 5.
Ако ви треба поголема контрола врз бројот на реплики, kubefed2 обезбедува нов објект ReplicaSchedulingPreference каде што репликите може да се мерат:
apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
name: test-deployment
namespace: test-ns
spec:
targetKind: FederatedDeployment
totalReplicas: 9
clusters:
A:
weight: 1
B:
weight: 2Структурата на CRD и API сè уште не се сосема подготвени, а во тек е активна работа во официјалното складиште на проекти.
Внимавајте на kubefed2, но запомнете дека тој сè уште не е погоден за производство.
Дознајте повеќе за kubefed2 од во блогот за Kubernetes и во .
Опција 2: комбинирање кластери во стилот на Booking.com
Програмерите на Booking.com не работеа на kubefed v2, туку смислија Shipper - оператор за испорака на неколку кластери, во неколку региони и во неколку облаци.
нешто слично на kubefed2.
Двете алатки ви дозволуваат да ја приспособите стратегијата за распоредување на повеќе кластери (кои кластери се користат и колку реплики имаат).
Но Целта на испраќачот е да го намали ризикот од грешки при испораката.
Во Доставувачот, можете да дефинирате серија чекори што ја опишуваат поделбата на репликите помеѓу претходното и тековното распоредување и обемот на дојдовниот сообраќај.
Кога туркате ресурс во кластерот, контролорот на испраќачот постепено ја пренесува таа промена низ сите споени кластери.
Исто така, испраќачот е многу ограничен.
На пример, ги прифаќа табелите на кормилото како влез и не поддржува ресурси од ванила.
Општо земено, Shipper работи вака.
Наместо стандардна испорака, треба да креирате ресурс за апликација што вклучува дијаграм на Helm:
apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
name: super-server
spec:
revisionHistoryLimit: 3
template:
chart:
name: nginx
repoUrl: https://storage.googleapis.com/shipper-demo
version: 0.0.1
clusterRequirements:
regions:
- name: local
strategy:
steps:
- capacity:
contender: 1
incumbent: 100
name: staging
traffic:
contender: 0
incumbent: 100
- capacity:
contender: 100
incumbent: 0
name: full on
traffic:
contender: 100
incumbent: 0
values:
replicaCount: 3Доставувачот е добра опција за управување со повеќе кластери, но неговата блиска врска со Helm само му пречи.
Што ако сите се префрлиме од Хелм на или ?
Дознајте повеќе за Shipper и неговата филозофија на .
Ако сакате да се закопате во кодот, .
Опција 3: „магично“ спојување на кластери
Kubefed v2 и Shipper работат со федерација на кластери, обезбедувајќи нови ресурси за кластерите преку прилагодено дефинирање на ресурси.
Но, што ако не сакате да ги препишете сите испораки, StatefulSets, DaemonSets итн. за да се спојат?
Како да се вклучи постоечки кластер во федерација без промена на YAML?
, кој се занимава со закажување оптоварувања на кластерите.
Но, наместо да се смисли нов начин за интеракција со кластерот и да се заокружат ресурсите во прилагодени дефиниции, распоредувачот на повеќе кластери е вграден во стандардниот животен циклус на Kubernetes и ги пресретнува сите повици што создаваат подлоги.
Секоја создадена мешунка веднаш се заменува со кукла.
користи мулти-кластер-распоредувач да го пресретнете повикот и да создадете неактивен кукла под.
Оригиналната мешунка минува низ друг циклус на планирање каде што, по анкетирањето на целата федерација, се донесува одлука за пласман.
Конечно, подлогата се доставува до целниот кластер.
Како резултат на тоа, имате дополнителна подлога што не прави ништо, само зафаќа простор.
Предноста е што не требаше да пишувате нови ресурси за да ги комбинирате набавките.
Секој ресурс што создава подлога е автоматски подготвен за спојување.
Ова е интересно, бидејќи одеднаш имате залихи дистрибуирани низ неколку региони, а не сте ни забележале. Сепак, ова е доста ризично, бидејќи сè овде почива на магија.
Но, додека Shipper се обидува најмногу да го ублажи влијанието на испораките, распоредувачот со повеќе кластери се справува со поопшти задачи и можеби е подобро прилагоден за сериски работи.
Нема напреден механизам за постепена испорака.
Повеќе за распоредувачот на повеќе кластери може да најдете на .
Ако сакате да прочитате за распоредувачот со повеќе кластери во акција, Admiralty има — работни текови, настани, CI и CD Kubernetes.
Други алатки и решенија
Поврзувањето и управувањето со повеќе кластери е сложена задача и не постои универзално решение.
Ако сакате дополнително да ја истражите оваа тема, еве неколку ресурси:
- е алатка која поврзува преклопени мрежи на различни кластери на Кубернет.
- Малопродажниот синџир Target користи .
- Обидете се да користите IPV6 и .
- Можете да користите сервисна мрежа, на пример .
- Цилиум, приклучок за мрежен интерфејс за контејнери, нуди , кој ви овозможува да комбинирате неколку кластери
Тоа е се за денес
Ви благодариме што прочитавте до крај!
Ако знаете како поефикасно да поврзете повеќе кластери, .
Ќе го додадеме вашиот метод на врските.
Посебна благодарност до Крис Несбит-Смит () и Винсент де Сме () (инженер за доверливост во ) за читање на статијата и споделување корисни информации за тоа како функционира федерацијата.
Извор: www.habr.com