Сардэчна запрашаем у серыю кароткіх кіраўніцтваў па Kubernetes. Гэта рэгулярная калонка з самымі цікавымі пытаннямі, якія мы атрымліваем анлайн і на нашых трэнінгах. Адказвае эксперт па Kubernetes.
Сённяшні эксперт - Даніэль Паленчык (). Даніэль працуе інструктарам і распрацоўшчыкам ПЗ у .
Калі вы хочаце атрымаць адказ на сваё пытанне ў наступным пасце, або ў .
Прапусцілі папярэднія пасады? .
Як злучыць кластары Kubernetes у розных дата-цэнтрах?
Коратка: , а яшчэ раю пачытаць пра и .
Даволі часта інфраструктура рэплікуецца і размяркоўваецца па розных рэгіёнах, асабліва ў кантраляваных асяроддзях.
Калі адзін рэгіён недаступны, трафік перанакіроўваецца ў іншы, каб пазбегнуць перабояў.
З Kubernetes можна выкарыстоўваць падобную стратэгію і размяркоўваць працоўныя нагрузкі па розных рэгіёнах.
У вас можа быць адзін ці некалькі кластараў на каманду, рэгіён, асяроддзе ці на камбінацыю гэтых элементаў.
Вашы кластары могуць размяшчацца ў розных аблоках і ў лакальным асяроддзі.
Але як спланаваць інфраструктуру для такога геаграфічнага роскіду?
Трэба стварыць адзін вялікі кластар на некалькі хмарных асяроддзяў па адзінай сетцы?
Ці завесці шмат маленькіх кластараў і знайсці спосаб кантраляваць і сінхранізаваць іх?
Адзін кіруючы кластар
Стварыць адзін кластар па адзінай сетцы не вось так проста.
Уявіце, у вас аварыя, страчана складнасць паміж сегментамі кластара.
Калі ў вас адзін майстар-сервер, палова рэсурсаў не змогуць атрымліваць новыя каманды, бо ім не ўдасца звязацца з майстрам.
І пры гэтым у вас старыя табліцы маршрутызацыі (kube-proxy не можа загрузіць новыя) і ніякіх дадатковых pod'аў (kubelet не можа запытваць абнаўлення).
Што яшчэ горш, калі Kubernetes не бачыць вузел, ен пазначае яго як страчаны і размяркоўвае адсутныя pod'ы па існуючых вузлах.
У выніку pod'ов у вас у два разы больш.
Калі вы зробіце па адным майстар-серверы на кожны рэгіён, будуць праблемы з алгарытмам дасягнення кансэнсусу ў базе дадзеных etcd. (заўв. рэд. - На самай справе база дадзеных etcd не абавязкова павінна знаходзіцца на майстар-серверах. Яе можна запусціць на асобнай групе сервераў у адным рэгіёне. Праўда, атрымаўшы пры гэтым кропку адмовы кластара. Затое хутка.)
etcd выкарыстоўвае , Каб узгадніць значэнне, перш чым запісаць яго на дыск.
Гэта значыць большасць асобнікаў павінны дасягнуць кансенсусу, перш чым стан можна будзе запісаць у etcd.
Калі затрымка паміж асобнікамі etcd рэзка расце, як у выпадку з трыма асобнікамі etcd у розных рэгіёнах, патрабуецца шмат часу, каб узгадніць значэнне і запісаць яго на дыск.
Гэта адбіваецца і на кантролерах Kubernetes.
Мэнэджару кантролераў трэба больш часу, каб даведацца аб змене і запісаць адказ у базу дадзеных.
А раз кантролер не адзін, а некалькі, атрымліваецца ланцуговая рэакцыя, і ўвесь кластар пачынае працаваць вельмі марудна..
etcd настолькі адчувальны да затрымкі, што .
Цяпер не існуе добрых прыкладаў вялікай сеткі для аднаго кластара.
У асноўным, супольнасць распрацоўшчыкаў і група SIG-cluster спрабуюць зразумець, як аркестраваць кластары гэтак жа, як Kubernetes аркеструе кантэйнеры.
Варыянт 1: федэрацыя кластараў з kubefed
Афіцыйны адказ ад SIG-cluster .
Упершыню кіраваць калекцыяй кластараў як адзіным аб'ектам спрабавалі з дапамогай прылады kube federation.
Пачатак быў добрым, але ў выніку kube federation так і не стаў папулярным, бо падтрымліваў не ўсе рэсурсы.
Ён падтрымліваў аб'яднаныя пастаўкі і сэрвісы, але, напрыклад, не StatefulSets.
А яшчэ канфігурацыя федэрацыі перадавалася ў выглядзе анатацый і не адрознівалася гнуткасцю.
Уявіце сабе, як можна апісаць падзел рэплік для кожнага кластара ў федэрацыі з дапамогай адных анатацый.
Атрымалася поўная бязладзіца.
SIG-cluster прарабілі вялікую працу пасля kubefed v1 і вырашылі падысці да праблемы з іншага боку.
Замест анатацый яны вырашылі выпусціць кантролер, які ўстанаўліваецца на кластарах. Яго можна наладжваць з дапамогай карыстацкіх азначэнняў рэсурсаў (Custom Resource Definition, CRD).
Для кожнага рэсурсу, які будзе ўваходзіць у федэрацыю, у вас ёсць карыстацкае вызначэнне CRD з трох раздзелаў:
- стандартнае вызначэнне рэсурсу, напрыклад дэплой;
- раздзел
placement, дзе вы вызначаеце, як рэсурс будзе размяркоўвацца ў федэрацыі; - раздзел
override, дзе для канкрэтнага рэсурсу можна перавызначыць вагу і параметры з placement.
Вось прыклад аб'яднанай пастаўкі з раздзеламі 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 - знізіць рызыку памылак пры пастаўцы.
У Shipper можна вызначыць шэраг крокаў, якія апісваюць падзел рэплік паміж папярэднім і бягучым дэплоем і аб'ём уваходнага трафіку.
Калі вы адпраўляеце рэсурс у кластар, кантролер Shipper пакрокава разгортвае гэтую змену па ўсіх аб'яднаных кластарах.
А яшчэ Shipper вельмі абмежаваны.
Напрыклад, ён прымае Helm-чарты як уваходныя дадзеныя і не падтрымлівае vanilla рэсурсы.
У агульных рысах, 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: 3Shipper нядрэнны варыянт для кіравання некалькімі кластарамі, але яго цесная сувязь з Helm толькі мяшае.
А раптам мы ўсё пяройдзем з Helm на або ?
Даведайцеся больш пра Shipper і яго філасофіі ў .
Калі жадаеце пакапацца ў кодзе, .
Варыянт 3: магічнае аб'яднанне кластараў
Kubefed v2 і Shipper працуюць з федэрацыяй кластараў, падаючы кластарам новыя рэсурсы праз карыстацкае вызначэнне рэсурсаў.
Але раптам вы не жадаеце перапісваць усе пастаўкі, StatefulSets, DaemonSets і т. д. для аб'яднання?
Як уключыць існуючы кластар у федэрацыю, не мяняючы YAML?
, Які займаецца працоўнымі нагрузкамі планавання ў кластарах.
Але замест таго, каб прыдумляць новы спосаб узаемадзеяння з кластарам і абгортваць рэсурсы ў карыстацкія азначэнні, multi-cluster-scheduler укараняецца ў стандартны жыццёвы цыкл Kubernetes і перахапляе ўсе выклікі, якія ствараюць поды.
Кожны ствараецца пад адразу замяняецца на пустышку.
multi-cluster-scheduler выкарыстоўвае , Каб перахапіць выклік і стварыць бяздзейны pod-пустышку.
Зыходны pod праходзіць праз яшчэ адзін цыкл планавання, дзе пасля апытання ўсёй федэрацыі прымаецца рашэнне аб размяшчэнні.
Нарэшце, pod пастаўляецца ў мэтавай кластар.
У выніку ў вас лішні pod, які нічога не робіць, проста займае месца.
Перавага ў тым, што вам не прыйшлося пісаць новыя рэсурсы для аб'яднання паставак.
Кожны рэсурс, які стварае pod, аўтаматычна гатовы для аб'яднання.
Гэта цікава, бо ў вас раптам з'яўляюцца пастаўкі, размеркаваныя па некалькіх рэгіёнах, а вы і не заўважылі. Зрэшты, гэта даволі рызыкоўна, бо тут усё трымаецца на магіі.
Але калі Shipper імкнецца, у асноўным, змякчыць наступствы паставак, multi-cluster-scheduler выконвае больш агульныя задачы і, магчыма, лепш падыходзіць для пакетных заданняў.
У яго няма прасунутага механізма паступовых паставак.
Больш пра multi-cluster-scheduler можна даведацца на .
Калі хочаце прачытаць аб multi-cluster-scheduler у дзеянні, у Admiralty ёсць - Працоўнымі працэсамі, падзеямі, CI і CD Kubernetes.
Іншыя інструменты і рашэнні
Злучэнне некалькіх кластараў і кіраванне імі - складаная задача, універсальнага рашэння не існуе.
Калі вы хочаце больш падрабязна вывучыць гэтую тэму, вось вам некалькі рэсурсаў:
- - Інструмент, які злучае оверлей-сеткі розных кластараў Kubernetes.
- Рознічная сетка Target выкарыстоўвае .
- Паспрабуйце выкарыстоўваць IPV6 і .
- Можна выкарыстоўваць service mesh, напрыклад .
- Cilium, убудова інтэрфейсу сеткі кантэйнераў, прапануе , якая дазваляе спалучаць некалькі кластараў
Вось і ўсё на сёння
Дзякуй, што дачыталі да канца!
Калі вы ведаеце, як эфектыўней злучыць некалькі кластараў, .
Мы дадамо ваш спосаб да спасылак.
Асаблівая падзяка Крысу Несбіту-Сміту () і Венсану дэ Сме () (інжынеру па надзейнасці ў ) за тое, што прачыталі артыкул і падзяліліся карыснай інфармацыяй аб тым, як працуе федэрацыя.
Крыніца: habr.com