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