Добре дошли в серия от кратки ръководства за Kubernetes. Това е редовна колона с най-интригуващите въпроси, които получаваме онлайн и на нашите обучения. Отговаря експерт по Kubernetes.
Днешният експерт е Даниел Поленчик (). Даниел е инструктор и разработчик на софтуер в .
Ако искате да получите отговор на вашия въпрос в следващия пост, или в .
Пропуснали ли сте предишните постове? .
Как да свържем Kubernetes клъстери в различни дата центрове?
Кратко: , а освен това ви съветвам да прочете за и .
Доста често инфраструктурата се репликира и разпределя в различни региони, особено в контролирани среди.
Ако един регион е недостъпен, трафикът се пренасочва в друг, за да се избегне спиране.
С Kubernetes можете да използвате подобна стратегия и да разпределяте работните натоварвания в различни региони.
Можете да имате един или няколко клъстера на екип, регион, среда или комбинация от тези елементи.
Вашите клъстери могат да се намират в различни облаци и в локална среда.
Но как да планирате инфраструктурата за такова географско разпръскване?
Трябва ли да създадете един голям клъстер на няколко облачни среди по единна мрежа?
Или да създадете много малки клъстери и да намерите начин да ги контролирате и синхронизирате?
Един ръководен клъстер
Създаването на един клъстер по единна мрежа не е толкова просто.
Представете си, имате авария, свързаността между сегментите на клъстера е загубена.
Ако имате един master сървър, половината ресурси няма да могат да получават нови заповеди, защото не успяват да се свържат с майстора.
И при това имате стари маршрутизационни таблици (kube-proxy не може да зареди нови) и никакви допълнителни pod-ове (kubelet не може да проверява актуализации).
Още по-лошо, ако Kubernetes не вижда възел, той го маркира като изгубен и разпределя липсващите pod-ове на съществуващите възли.
В крайна сметка имате два пъти повече pod-ове.
Ако имате по един master сървър за всеки регион, ще има проблеми с алгоритъма за постигане на консенсус в базата данни etcd. (бел. ред. — Всъщност базата данни etcd не е необходимо да се намира на master сървърите. Може да бъде стартирана на отделна група сървъри в един регион. Но в този случай ще получите точка на отказ на клъстера. Затова е бързо.)
etcd използва , за да синхронизира стойността, преди да я запише на диск.
Т.е. повечето инстанции трябва да постигнат консенсус, преди състоянието да може да бъде записано в etcd.
Ако забавянето между инстанциите на etcd рязко се увеличи, както е случаят с три инстанции на etcd в различни региони, отнема много време, за да се постигне консенсус и да се запише стойността на диска.
Това влияе и на Kubernetes контролерите.
Контролерът има нужда от повече време, за да разбере промените и да запише отговора в базата данни.
И тъй като контролерите не са един, а няколко, създава се верижна реакция и целият клъстер започва да работи много бавно..
etcd е толкова чувствителен към забавяне, че .
В момента не съществуват добри примери за голямо мрежово решение за един клъстер.
По принцип общността на разработчиците и групата SIG-cluster се опитват да разберат как да оркестрират клъстери, точно както Kubernetes оркестрира контейнери.
Опция 1: федерация на клъстери с kubefed.
Официалният отговор от SIG-cluster е, .
За първи път опитаха да управляват колекция от клъстери като единичен обект чрез инструмента kube федерация.
Началото беше добро, но в крайна сметка kube федерацията не стана популярна, защото не поддържаше всички ресурси.
Тя поддържаше само обединени доставки и услуги, но, например, не и StatefulSets.
Освен това конфигурацията на федерацията се предаваше под формата на анотации и не се отличаваше с гъвкавост.
Представете си как може да се опише разпределението на реплики за всеки клъстер във федерацията само с анотации.
Получава се пълен безредие.
SIG-cluster извършиха значителна работа след kubefed v1 и решиха да се справят с проблема от друга страна.
Вместо анотации те решиха да пуснат контролер, който се инсталира на клъстерите. Може да се конфигурира с помощта на потребителски определения на ресурси (Custom Resource Definition, CRD).
За всеки ресурс, който ще влезе във федерацията, имате потребителско определение CRD от три раздела:
- стандартно определение на ресурса, например деплой;
- раздел
разположение,където определяте как ресурсът ще бъде разпределен във федерацията; - раздел
презаписване,където за конкретен ресурс можете да пренастроите теглото и параметрите от разположението.
Ето пример за обединена доставка с разделите за разположение и презаписване.
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 и перехваща всички повиквания, които създават подове.
Всеки създаден под веднага се заменя с placeholder.
multi-cluster-scheduler използва , за да перехване повикването и да създаде неактивен pod-placeholder.
Първоначалният под преминава през още един цикъл на планиране, където след запитване на цялата федерация се взима решение за разположение.
Накрая, подът се предоставя на целевия клъстер.
В резултат на това имате излишен под, който не прави нищо, просто заема място.
Предимството е, че не трябваше да пишете нови ресурси за обединяване на доставките.
Всеки ресурс, който създава под, автоматично е готов за обединяване.
Интересно е, че внезапно имате доставки, разпределени в няколко региона, без дори да сте забелязали. Обаче, това е доста рисковано, тъй като всичко зависи от магията.
Но ако Shipper се опитва основно да смекчи последствията от доставките, multi-cluster-scheduler изпълнява по-общи задачи и вероятно е по-подходящ за пакетни задания.
Той няма напреднал механизъм за постепенни доставки.
Повече за multi-cluster-scheduler можете да научите на .
Ако желаете да прочетете за multi-cluster-scheduler в действие, Admiralty има — работни процеси, събития, CI и CD на Kubernetes.
Други инструменти и решения
Свързването и управлението на няколко клъстера е сложно предизвикателство, универсално решение не съществува.
Ако искате да проучите тази тема по-задълбочено, ето ви няколко ресурса:
- — инструментът, който свързва overlay мрежи на различни клъстери на Kubernetes.
- Търговската мрежа Target използва .
- Опитайте да използвате IPV6 и .
- Можете да използвате service mesh, например .
- Cilium, модулът на контейнерната мрежа, предлага , която позволява комбинирането на няколко клъстера.
Това е всичко за днес.
Благодаря, че прочетохте до края!
Ако знаете как по-ефективно да свържете няколко клъстера, .
Ние ще добавим вашия метод в линковете.
Специални благодарности на Крис Несбитт-Смит () и Венсан де Смет () (инженер по надеждност в ) за това, че прегледаха статията и споделиха полезна информация за начина, по който работи федерацията.
Източник: habr.com
