Манай Kubernetes Quick Start цувралд тавтай морил. Энэ бол бидний онлайнаар болон бидний сургалтанд ирдэг хамгийн сонирхолтой асуултуудын тогтмол булан юм. Kubernetes шинжээчийн хариулт.
Өнөөдрийн мэргэжилтэн бол Даниел Поленчик (). Даниел багш, программ хангамж хөгжүүлэгчээр ажилладаг .
Хэрэв та асуултынхаа хариултыг дараагийн бичлэгт оруулахыг хүсвэл болон .
Өмнөх нийтлэлээ орхисон уу? .
Өөр өөр мэдээллийн төвд Кубернетес кластеруудыг хэрхэн холбох вэ?
Товчхондоо: , мөн би мөн тухай уншихыг зөвлөж байна и .
Ихэнх тохиолдолд дэд бүтцийг өөр өөр бүс нутагт, ялангуяа хяналттай орчинд хуулбарлаж, хуваарилдаг.
Хэрэв нэг бүс боломжгүй бол тасалдал үүсэхээс зайлсхийхийн тулд урсгалыг нөгөө рүү шилжүүлдэг.
Kubernetes-ийн тусламжтайгаар та ижил төстэй стратеги ашиглаж, ажлын ачааллыг өөр өөр бүс нутагт хуваарилах боломжтой.
Та баг, бүс нутаг, хүрээлэн буй орчин эсвэл эдгээр элементүүдийн хослол бүрт нэг буюу хэд хэдэн кластертай байж болно.
Таны кластеруудыг өөр өөр үүл болон газар дээр байрлуулах боломжтой.
Гэхдээ ийм газарзүйн тархалтын дэд бүтцийг хэрхэн төлөвлөх вэ?
Та нэг сүлжээгээр хэд хэдэн үүлэн орчинд зориулж нэг том кластер үүсгэх шаардлагатай юу?
Эсвэл олон жижиг кластертай байж, тэдгээрийг хянах, синхрончлох арга замыг олох уу?
Нэг манлайллын кластер
Нэг сүлжээгээр нэг кластер үүсгэх нь тийм ч хялбар биш юм.
Та осолд орсон гэж төсөөлөөд үз дээ, кластерын сегментүүдийн хоорондын холболт тасарсан.
Хэрэв танд нэг мастер сервер байгаа бол нөөцийн тал хувь нь мастертай холбогдох боломжгүй тул шинэ тушаалуудыг хүлээн авах боломжгүй болно.
Үүний зэрэгцээ танд хуучин чиглүүлэлтийн хүснэгтүүд байна (kube-proxy шинийг татаж авах боломжгүй) болон нэмэлт pods байхгүй (kubelet шинэчлэлт хүсэх боломжгүй).
Бүр дордуулахын тулд хэрэв Кубернетес зангилаа олж харахгүй бол түүнийг өнчин гэж тэмдэглэж, дутуу хонхорцог одоо байгаа зангилаа руу тараана.
Үүний үр дүнд та хоёр дахин их хонхорхойтой болно.
Хэрэв та бүс бүрт нэг мастер сервер хийвэл etcd мэдээллийн сан дахь зөвшилцлийн алгоритмтай холбоотой асуудал гарна. (ойролцоогоор. ed. — Үнэн хэрэгтээ, etcd мэдээллийн сан нь заавал мастер серверүүд дээр байх албагүй. Үүнийг нэг бүс дэх серверүүдийн тусдаа бүлэг дээр ажиллуулж болно. Үүний зэрэгцээ кластерийн бүтэлгүйтлийн цэгийг олж авах нь үнэн. Гэхдээ хурдан.)
гэх мэтийг ашигладаг диск рүү бичихээс өмнө утгыг тохиролцох.
Өөрөөр хэлбэл, төрийг etcd руу бичихээс өмнө ихэнх тохиолдол зөвшилцөлд хүрэх ёстой.
Хэрэв etcd тохиолдлын хоорондох хоцролт нь өөр өөр бүс нутагт байгаа гурван etcd тохиолдлын адил эрс нэмэгдвэл утгыг тохиролцож, диск рүү бичихэд удаан хугацаа шаардагдана.
Энэ нь Kubernetes хянагчдад тусгагдсан байдаг.
Хянагчийн менежер өөрчлөлтийн талаар мэдэж, мэдээллийн санд хариу бичихэд илүү их цаг хугацаа шаардагдана.
Нэг хянагч биш, хэд хэдэн байдаг тул гинжин урвал үүсч, бүхэл бүтэн кластер маш удаан ажиллаж эхэлдэг.
etcd нь хоцрогдолд маш мэдрэмтгий байдаг .
Нэг кластерт зориулсан том сүлжээний сайн жишээ одоогоор алга байна.
Үндсэндээ хөгжүүлэгчдийн нийгэмлэг болон SIG кластерын бүлэг нь Кубернетес контейнеруудыг зохион байгуулдагтай адил кластеруудыг хэрхэн зохион байгуулахыг олохыг хичээж байна.
Сонголт 1: kubefed-тэй кластерын холбоо
SIG кластерийн албан ёсны хариу - .
Бид анх удаа kube холбооны хэрэгслийг ашиглан кластеруудын цуглуулгыг нэг объект болгон удирдахыг оролдсон.
Эхлэл сайн байсан ч эцэст нь кубын холбоо бүх нөөц бололцоогоо дэмжээгүй тул хэзээ ч алдартай болсонгүй.
Энэ нь нэгдсэн хүргэлт, үйлчилгээг дэмждэг байсан ч жишээлбэл StatefulSets-ийг дэмждэггүй.
Мөн холбооны тохиргоог тайлбар хэлбэрээр дамжуулж, уян хатан биш байсан.
Холбооны кластер бүрийн хуулбар хуваалтыг зөвхөн тэмдэглэгээ ашиглан хэрхэн дүрсэлж болохыг төсөөлөөд үз дээ.
Энэ бол бүрэн замбараагүй байдал байсан.
SIG-cluster нь 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-ийн талаар нэмэлт мэдээлэл аваарай Kubernetes болон 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-тэй ойр дотно харилцаатай байх нь зөвхөн саад болдог.
Хэрэв бид бүгдээрээ Helm-ээс солигдвол яах вэ? буюу ?
Shipper болон түүний философийн талаар илүү ихийг эндээс авна уу .
Хэрэв та кодыг ухахыг хүсвэл, .
Сонголт 3: "шидэт" кластер нэгтгэх
Kubefed v2 болон Shipper нь кластерын холбоотой хамтран ажиллаж, тусгай нөөцийн тодорхойлолтоор дамжуулан кластеруудад шинэ нөөцийг өгдөг.
Гэхдээ та бүх хүргэлт, StatefulSets, DaemonSets гэх мэтийг нэгтгэхийн тулд дахин бичихийг хүсэхгүй байвал яах вэ?
YAML-ийг өөрчлөхгүйгээр одоо байгаа кластерийг хэрхэн холбоонд оруулах вэ?
, энэ нь кластерууд дээрх ажлын ачааллыг төлөвлөхтэй холбоотой.
Гэхдээ кластертай харилцах, нөөцийг захиалгат тодорхойлолтонд оруулах шинэ аргыг бодож олохын оронд олон кластер хуваарьлагчийг стандарт Кубернетын амьдралын мөчлөгт суулгаж, pods үүсгэдэг бүх дуудлагыг таслан зогсоодог.
Үүсгэсэн pod бүрийг шууд даммигаар солино.
олон кластерт хуваарьлагчийг ашигладаг дуудлагыг таслан зогсоож, сул зогсолтыг бий болгох.
Анхны pod нь бүхэл бүтэн холбоог санал асуулгын дараа байршуулах шийдвэр гаргадаг төлөвлөлтийн өөр мөчлөгийг дамждаг.
Эцэст нь pod нь зорилтот кластерт хүргэгдэнэ.
Үүний үр дүнд та юу ч хийдэггүй, зүгээр л зай эзэлдэг нэмэлт podтой болно.
Давуу тал нь хангамжийг нэгтгэхийн тулд шинэ эх сурвалж бичих шаардлагагүй байсан.
Под үүсгэгч нөөц бүр автоматаар нэгтгэгдэхэд бэлэн байна.
Энэ нь сонирхолтой юм, учир нь гэнэт та хэд хэдэн бүс нутагт хангамж тараагдсан бөгөөд та үүнийг анзаарсангүй. Гэсэн хэдий ч энэ нь нэлээд эрсдэлтэй, учир нь энд бүх зүйл ид шид дээр тулгуурладаг.
Гэхдээ Ачаалагч нь хүргэлтийн нөлөөллийг бууруулахыг хичээж байгаа ч олон кластерт хуваарьлагч нь илүү ерөнхий ажлуудыг гүйцэтгэдэг бөгөөд багц ажилд илүү тохиромжтой байдаг.
Энэ нь аажмаар хүргэх дэвшилтэт механизмгүй.
Олон кластер хуваарийн талаар илүү ихийг эндээс олж болно .
Хэрэв та ажиллаж байгаа олон кластер хуваарийн талаар уншихыг хүсвэл Адмиралти энд байна - ажлын урсгал, үйл явдал, CI болон CD Kubernetes.
Бусад хэрэгсэл, шийдэл
Олон кластеруудыг холбох, удирдах нь нарийн төвөгтэй ажил бөгөөд бүх нийтийн шийдэл байдаггүй.
Хэрэв та энэ сэдвийг илүү нарийвчлан судлахыг хүсч байвал зарим эх сурвалжийг эндээс авна уу:
- янз бүрийн Kubernetes кластеруудын давхардсан сүлжээг холбодог хэрэгсэл юм.
- Жижиглэнгийн сүлжээ Зорилтот хэрэглээ .
- IPV6 болон ашиглаж үзээрэй .
- Жишээлбэл, та үйлчилгээний торыг ашиглаж болно .
- Cilium, чингэлэг сүлжээний интерфейсийн залгаас санал болгож байна , энэ нь хэд хэдэн кластеруудыг нэгтгэх боломжийг олгодог
Өнөөдрийн хувьд энэ л байна
Эцсээ хүртэл уншсан танд баярлалаа!
Хэрэв та олон кластеруудыг хэрхэн илүү үр дүнтэй холбохыг мэддэг бол, .
Бид таны аргыг холбоос дээр нэмэх болно.
Крис Несбитт-Смитэд онцгой талархал илэрхийлье () болон Винсент де Сме () (найдвартай байдлын инженер ) нийтлэлийг уншиж, холбоо хэрхэн ажилладаг талаар хэрэгтэй мэдээллийг хуваалцсан.
Эх сурвалж: www.habr.com