Kubernetes Quick Start сериясына қош келдіңіз. Бұл онлайн және тренингтерімізде бізге түсетін ең қызықты сұрақтары бар тұрақты айдар. Kubernetes сарапшысы жауап береді.
Бүгінгі сарапшы - Даниэль Поленчик (). Даниел нұсқаушы және бағдарламалық жасақтаманы әзірлеуші болып жұмыс істейді .
Сұрағыңызға келесі постта жауап алғыңыз келсе, немесе .
Алдыңғы жазбаларды жіберіп алдыңыз ба? .
Әртүрлі деректер орталықтарында Kubernetes кластерлерін қалай қосуға болады?
Қысқаша: , және мен де туралы оқуды ұсынамын и .
Көбінесе инфрақұрылым әртүрлі аймақтарда, әсіресе басқарылатын орталарда қайталанады және таратылады.
Бір аймақ қолжетімсіз болса, кедергілерді болдырмау үшін трафик басқа аймаққа қайта бағытталады.
Kubernetes көмегімен сіз ұқсас стратегияны пайдалана аласыз және жұмыс жүктемелерін әртүрлі аймақтарға тарата аласыз.
Әр топ, аймақ, орта немесе осы элементтердің тіркесімі үшін бір немесе бірнеше кластер болуы мүмкін.
Кластерлеріңізді әртүрлі бұлттарда және жергілікті жерде орналастыруға болады.
Бірақ мұндай географиялық таралу үшін инфрақұрылымды қалай жоспарлайсыз?
Бір желі арқылы бірнеше бұлттық орталар үшін бір үлкен кластерді жасау керек пе?
Немесе көптеген шағын кластерлер бар және оларды басқару және синхрондау жолын табасыз ба?
Бір көшбасшылық кластер
Бір желіде бір кластерді құру оңай емес.
Сізде апат болды деп елестетіп көріңіз, кластер сегменттері арасындағы байланыс жоғалды.
Егер сізде бір негізгі сервер болса, ресурстардың жартысы жаңа пәрмендерді ала алмайды, себебі олар шебермен байланыса алмайды.
Сонымен қатар сізде ескі маршруттау кестелері бар (kube-proxy жаңаларын жүктеп ала алмайды) және қосымша қосқыштар жоқ (kubelet жаңартуларды сұрай алмайды).
Нашарлау үшін, егер Кубернетес түйінді көрмесе, оны жетім деп белгілеп, жетіспейтін түйіндерді бар түйіндерге таратады.
Нәтижесінде сізде екі есе көп бүршіктер бар.
Әрбір аймақ үшін бір басты сервер жасасаңыз, etcd дерекқорындағы консенсус алгоритміне қатысты мәселелер туындайды. (шамамен. ред. — Шын мәнінде, etcd дерекқоры міндетті түрде негізгі серверлерде орналасуы қажет емес. Оны бір аймақтағы серверлердің бөлек тобында іске қосуға болады. Рас, сонымен қатар кластердің сәтсіз нүктесін алу. Бірақ тез.)
т.б. пайдаланады дискіге жазбас бұрын мәнді келісу үшін.
Яғни, мемлекет және т.б.-ге жазбас бұрын даналардың көпшілігі консенсусқа жетуі керек.
Әртүрлі аймақтардағы үш etcd данасы сияқты, etcd даналарының арасындағы кідіріс күрт артса, мәнді келісу және оны дискіге жазу көп уақытты алады.
Бұл Kubernetes контроллерлерінде көрсетілген.
Контроллер менеджеріне өзгерту туралы білу және дерекқорға жауапты жазу үшін көбірек уақыт қажет.
Бір емес, бірнеше контроллер болғандықтан, тізбекті реакция пайда болады және бүкіл кластер өте баяу жұмыс істей бастайды.
etcd кешігуге өте сезімтал, сондықтан .
Қазіргі уақытта бір кластер үшін үлкен желінің жақсы үлгілері жоқ.
Негізінде әзірлеушілер қауымдастығы мен SIG кластері тобы Кубернетес контейнерлерді реттейтіндей кластерлерді қалай ұйымдастыру керектігін анықтауға тырысады.
1-нұсқа: kubefed көмегімен кластерлік федерация
SIG кластерінің ресми жауабы - .
Алғаш рет біз kube федерациясы құралын пайдаланып кластерлер жинағын бір нысан ретінде басқаруға тырыстық.
Басталуы жақсы болды, бірақ соңында кубе федерациясы ешқашан танымал бола алмады, өйткені ол барлық ресурстарды қолдамады.
Ол, мысалы, StatefulSets емес, федеративтік жеткізілімдер мен қызметтерге қолдау көрсетті.
Сондай-ақ, федерация конфигурациясы аннотациялар түрінде берілді және икемді болмады.
Тек аннотацияларды пайдаланып, федерациядағы әрбір кластер үшін реплика бөлімін қалай сипаттауға болатынын елестетіп көріңіз.
Бұл толық тәртіпсіздік болды.
SIG-кластері kubefed v1-ден кейін көп жұмыс жасады және мәселеге басқа қырынан қарауды шешті.
Аннотациялардың орнына олар кластерлерде орнатылған контроллерді шығаруды шешті. Оны Custom Resource Definitions (CRDs) арқылы теңшеуге болады.
Федерацияның бөлігі болатын әрбір ресурс үшін сізде үш бөлімнен тұратын теңшелетін 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 туралы көбірек біліңіз Кубернетес туралы блогта және in .
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 және жөнелтуші кластер федерациясымен жұмыс істейді, реттелетін ресурс анықтамасы арқылы кластерлерге жаңа ресурстар береді.
Бірақ біріктіру үшін барлық жеткізілімдерді, StatefulSets, DaemonSets және т.б. қайта жазғыңыз келмесе ше?
YAML өзгертпестен бар кластерді федерацияға қалай қосуға болады?
, ол кластерлердегі жұмыс жүктемелерін жоспарлаумен айналысады.
Бірақ кластермен өзара әрекеттесу және ресурстарды реттелетін анықтамаларға орау үшін жаңа жолды ойлап табудың орнына, көп кластер-жоспарлағыш стандартты Kubernetes өмірлік цикліне ендірілген және подкасттарды жасайтын барлық қоңырауларды ұстайды.
Әрбір жасалған подвод бірден манекенмен ауыстырылады.
көп кластерлік жоспарлаушыны пайдаланады қоңырауды ұстап алу және бос жалған подкаст жасау үшін.
Түпнұсқа подкаст басқа жоспарлау циклінен өтеді, онда бүкіл федерацияны сұраудан кейін орналастыру туралы шешім қабылданады.
Соңында, подвод мақсатты кластерге жеткізіледі.
Нәтижесінде сізде ешнәрсе жасамайтын, жай ғана орын алатын қосымша қақпақ бар.
Артықшылығы мынада: жабдықты біріктіру үшін жаңа ресурстарды жазудың қажеті жоқ.
Қондырғы жасайтын әрбір ресурс біріктіруге автоматты түрде дайын болады.
Бұл қызық, өйткені кенеттен сізде бірнеше аймақтарға жеткізілген материалдар пайда болды және сіз тіпті байқамай қалдыңыз. Дегенмен, бұл өте қауіпті, өйткені мұнда бәрі сиқырға негізделген.
Бірақ жөнелтуші негізінен жеткізілімдердің әсерін азайтуға тырысқанымен, көп кластерлік жоспарлаушы жалпылама тапсырмаларды орындайды және пакеттік тапсырмалар үшін жақсырақ болуы мүмкін.
Оның біртіндеп жеткізудің жетілдірілген механизмі жоқ.
Көп кластерді жоспарлаушы туралы қосымша ақпаратты мына жерден табуға болады .
Егер сіз көп кластерлік жоспарлаушы туралы оқығыңыз келсе, Admiralty бар — жұмыс үрдістері, оқиғалар, CI және CD Kubernetes.
Басқа құралдар мен шешімдер
Бірнеше кластерді қосу және басқару күрделі міндет және әмбебап шешім жоқ.
Егер сіз осы тақырыпты әрі қарай зерттегіңіз келсе, мұнда кейбір ресурстар:
- әртүрлі Kubernetes кластерлерінің қабаттасатын желілерін қосатын құрал.
- Бөлшек сауда желісі Мақсатты пайдалану .
- IPV6 және пайдаланып көріңіз .
- Мысалы, қызмет көрсету торын пайдалануға болады .
- Cilium, контейнерлік желі интерфейсінің плагині ұсынады , бұл бірнеше кластерді біріктіруге мүмкіндік береді
Бүгінгі күннің бәрі осы
Соңына дейін оқығаныңызға рахмет!
Бірнеше кластерді тиімдірек қосу жолын білсеңіз, .
Біз сіздің әдісіңізді сілтемелерге қосамыз.
Крис Несбитт-Смитке ерекше рахмет () және Винсент де Сме () (сенімділік бойынша инженер ) мақаланы оқып, федерацияның жұмысы туралы пайдалы ақпаратпен бөліскеніңіз үшін.
Ақпарат көзі: www.habr.com