Turli ma'lumotlar markazlarida Kubernetes klasterlarini qanday ulash mumkin

Kubernetes Quick Start seriyamizga xush kelibsiz. Bu bizning onlayn va treninglarimizda eng qiziqarli savollarga ega bo'lgan muntazam rukn. Kubernetes mutaxassisi javob beradi.

Bugungi mutaxassis - Daniel Polenchik (Daniele Polensich). Daniel o'qituvchi va dasturiy ta'minot ishlab chiqaruvchisi sifatida ishlaydi Learnk8s.

Savolingizga keyingi postda javob olishni istasangiz, elektron pochta orqali biz bilan bog'laning yoki Twitter: @learnk8s.

Oldingi postlarni o'tkazib yubordingizmi? Ularni shu yerda toping.

Turli ma'lumotlar markazlarida Kubernetes klasterlarini qanday ulash mumkin?

Qisqacha: Kubefed v2 tez orada, va men ham haqida o'qishni tavsiya qilaman Yuk tashuvchi и ko'p klasterli rejalashtirish loyihasi.

Ko'pincha infratuzilma ko'paytiriladi va turli mintaqalar bo'ylab taqsimlanadi, ayniqsa nazorat qilinadigan muhitda.

Agar biror hudud mavjud bo'lmasa, uzilishlar oldini olish uchun trafik boshqasiga yo'naltiriladi.

Kubernetes yordamida siz shunga o'xshash strategiyadan foydalanishingiz va ish yuklarini turli mintaqalar bo'ylab taqsimlashingiz mumkin.

Har bir jamoa, mintaqa, muhit yoki ushbu elementlarning kombinatsiyasi uchun bir yoki bir nechta klasterga ega bo'lishingiz mumkin.

Klasterlaringizni turli bulutlarda va mahalliy joylarda joylashtirish mumkin.

Ammo bunday geografik tarqalish uchun infratuzilmani qanday rejalashtirasiz?
Bitta tarmoq orqali bir nechta bulutli muhitlar uchun bitta katta klaster yaratishingiz kerakmi?
Yoki ko'plab kichik klasterlarga ega va ularni boshqarish va sinxronlashtirish yo'lini topasizmi?

Bitta etakchilik klasteri

Bitta tarmoq orqali bitta klaster yaratish unchalik oson emas.

Tasavvur qiling-a, sizda baxtsiz hodisa yuz berdi, klaster segmentlari orasidagi aloqa yo'qoldi.

Agar sizda bitta asosiy server bo'lsa, resurslarning yarmi yangi buyruqlarni qabul qila olmaydi, chunki ular master bilan bog'lana olmaydi.

Va shu bilan birga sizda eski marshrutlash jadvallari mavjud (kube-proxy yangilarini yuklab bo'lmaydi) va qo'shimcha podlar yo'q (kubelet yangilanishlarni talab qila olmaydi).

Eng yomoni, agar Kubernetes tugunni ko'rmasa, uni yetim deb belgilaydi va etishmayotgan bo'laklarni mavjud tugunlarga tarqatadi.

Natijada sizda ikki baravar ko'p podalar mavjud.

Agar siz har bir mintaqa uchun bitta asosiy server yaratsangiz, etcd ma'lumotlar bazasida konsensus algoritmi bilan bog'liq muammolar paydo bo'ladi. (taxminan. ed. — Aslida etcd maʼlumotlar bazasi asosiy serverlarda joylashgan boʻlishi shart emas. Uni bir xil hududdagi alohida serverlar guruhida ishga tushirish mumkin. To'g'ri, ayni paytda klasterning muvaffaqiyatsizlik nuqtasini olish. Lekin tez.)

etcd foydalanadi raft algoritmiqiymatni diskka yozishdan oldin kelishib olish.
Ya'ni, davlat va boshqalarga yozishdan oldin, aksariyat holatlar konsensusga erishishi kerak.

Agar etcd misollari orasidagi kechikish, turli mintaqalardagi uchta etcd misolida bo'lgani kabi, keskin oshsa, qiymatni muhokama qilish va uni diskka yozish uchun uzoq vaqt kerak bo'ladi.
Bu Kubernetes kontrollerlarida aks ettirilgan.

Nazoratchi menejeriga o'zgarishlar haqida bilish va ma'lumotlar bazasiga javob yozish uchun ko'proq vaqt kerak bo'ladi.

Va bitta boshqaruvchi emas, balki bir nechta bo'lgani uchun, zanjir reaktsiyasi yuzaga keladi va butun klaster juda sekin ishlay boshlaydi.

etcd shu qadar kechikishga sezgirki Rasmiy hujjatlar oddiy qattiq disklar o'rniga SSD'lardan foydalanishni tavsiya qiladi.

Hozirgi vaqtda bitta klaster uchun katta tarmoqning yaxshi namunalari yo'q.

Asosan, ishlab chiquvchilar hamjamiyati va SIG-klaster guruhi xuddi Kubernetes konteynerlarni boshqargani kabi klasterlarni qanday tashkil qilishni aniqlashga harakat qilmoqda.

Variant 1: kubefed bilan klaster federatsiyasi

SIG-klasteridan rasmiy javob - kubefed2, original kube federatsiyasi mijozi va operatorining yangi versiyasi.

Birinchi marta kube federatsiyasi vositasidan foydalanib, klasterlar to'plamini yagona ob'ekt sifatida boshqarishga harakat qildik.

Boshlanish yaxshi edi, lekin oxir-oqibat kube federatsiyasi hech qachon mashhur bo'lmadi, chunki u barcha resurslarni qo'llab-quvvatlamadi.

U federatsiyalangan yetkazib berish va xizmatlarni qo‘llab-quvvatladi, lekin, masalan, StatefulSets emas.
Shuningdek, federatsiya konfiguratsiyasi izohlar ko'rinishida uzatildi va moslashuvchan emas edi.

Federatsiyadagi har bir klaster uchun replika bo'linishini faqat izohlar yordamida qanday tasvirlashingiz mumkinligini tasavvur qiling.

Bu butunlay tartibsizlik edi.

SIG-klaster kubefed v1 dan keyin juda ko'p ish qildi va muammoga boshqa tomondan yondashishga qaror qildi.

Izohlar o'rniga ular klasterlarga o'rnatilgan kontrollerni chiqarishga qaror qilishdi. Uni Custom Resource Definitions (CRD) yordamida sozlash mumkin.

Federatsiya tarkibiga kiruvchi har bir resurs uchun sizda uchta bo'limdan iborat maxsus CRD ta'rifi mavjud:

• resursning standart ta'rifi, masalan, joylashtirish;
• bo'lim placement, bu erda resurs federatsiyada qanday taqsimlanishini aniqlaysiz;
• bo'lim override, bu erda ma'lum bir manba uchun siz joylashtirishdan og'irlik va parametrlarni bekor qilishingiz mumkin.

Bu erda joylashtirish va bekor qilish bo'limlari bilan birlashtirilgan yetkazib berish misoli keltirilgan.

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

Ko'rib turganingizdek, ta'minot ikkita klaster bo'yicha taqsimlanadi: cluster1 и cluster2.

Birinchi klaster uchta nusxani taqdim etadi, ikkinchisi esa 5 ga o'rnatiladi.

Agar sizga replikalar sonini ko'proq nazorat qilish kerak bo'lsa, kubefed2 replikalarni tortish mumkin bo'lgan yangi ReplicaSchedulingPreference ob'ektini taqdim etadi:

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 tuzilmasi va API hali toʻliq tayyor emas va loyihaning rasmiy omborida faol ish olib borilmoqda.

kubefed2 ni kuzatib boring, lekin u hali ishlab chiqarish uchun mos emasligini unutmang.

kubefed2 haqida ko'proq bilib oling kubefed2 haqida rasmiy maqola Kubernetes haqidagi blogda va in kubefed loyihasining rasmiy ombori.

Variant 2: Booking.com uslubida klasterlarni birlashtirish

Booking.com ishlab chiquvchilari kubefed v2 da ishlamadilar, biroq ular Shipper - bir nechta klasterlarda, bir nechta mintaqalarda va bir nechta bulutlarda yetkazib berish operatorini taklif qilishdi.

Yuk tashuvchi kubefed2 ga biroz o'xshaydi.

Ikkala vosita ham ko'p klasterli joylashtirish strategiyangizni sozlash imkonini beradi (qaysi klasterlar ishlatiladi va ularning qancha nusxalari bor).

lekin Yuk jo'natuvchining maqsadi etkazib berish paytida xatolar xavfini kamaytirishdir.

Yuboruvchida siz replikalarni oldingi va joriy joylashtirish va kiruvchi trafik hajmi o'rtasida taqsimlashni tavsiflovchi bir qator qadamlarni belgilashingiz mumkin.

Resursni klasterga bosganingizda, jo'natuvchi boshqaruvchisi bu o'zgarishlarni barcha birlashtirilgan klasterlar bo'ylab bosqichma-bosqich chiqaradi.

Bundan tashqari, jo'natuvchi juda cheklangan.

Misol uchun, u rul diagrammalarini kirish sifatida qabul qiladi va vanil manbalarini qo'llab-quvvatlamaydi.
Umuman olganda, Shipper shunday ishlaydi.

Standart yetkazib berish o'rniga, Helm diagrammasini o'z ichiga olgan dastur resursini yaratishingiz kerak:

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

Shipper bir nechta klasterlarni boshqarish uchun yaxshi imkoniyatdir, lekin uning Helm bilan yaqin aloqasi faqat yo'lni to'sib qo'yadi.

Agar hammamiz Helmdan o'tsak nima bo'ladi? moslashtirish yoki kapitan?

Shipper va uning falsafasi haqida ko'proq bilib oling ushbu rasmiy press-reliz.

Agar siz kodni o'rganmoqchi bo'lsangiz, rasmiy loyiha omboriga o'ting.

Variant 3: "sehrli" klasterni birlashtirish

Kubefed v2 va Shipper klaster federatsiyasi bilan ishlaydi va maxsus resurslarni aniqlash orqali klasterlarga yangi resurslarni taqdim etadi.

Ammo agar siz barcha etkazib berishlarni, StatefulSets, DaemonSets va hokazolarni birlashtirish uchun qayta yozishni xohlamasangiz nima bo'ladi?

YAMLni o'zgartirmasdan, mavjud klasterni federatsiyaga qanday kiritish mumkin?

multi-cluster-scheduler - bu Admirality loyihasi, bu klasterlarda ish yuklarini rejalashtirish bilan shug'ullanadi.

Biroq, klaster bilan o'zaro ta'sir qilish va resurslarni maxsus ta'riflarga o'tkazishning yangi usulini o'ylab topish o'rniga, ko'p klasterli rejalashtiruvchi standart Kubernetes hayot aylanishiga kiritilgan va podlarni yaratadigan barcha qo'ng'iroqlarni ushlab turadi.

Har bir yaratilgan pod darhol qo'g'irchoq bilan almashtiriladi.

ko'p klasterli rejalashtiruvchidan foydalanadi kirishni o'zgartirish uchun webhooksqo'ng'iroqni ushlab turish va bo'sh turgan qo'g'irchoq podni yaratish.

Asl pod boshqa rejalashtirish tsiklidan o'tadi, bu erda butun federatsiya bo'ylab so'rov o'tkazilgandan so'ng, joylashtirish qarori qabul qilinadi.

Nihoyat, pod maqsadli klasterga yetkaziladi.

Natijada, sizda hech narsa qilmaydigan, faqat joy egallagan qo'shimcha podka bor.

Afzalligi shundaki, siz materiallarni birlashtirish uchun yangi manbalarni yozishingiz shart emas edi.

Podni yaratadigan har bir resurs avtomatik ravishda birlashishga tayyor.

Bu qiziq, chunki to'satdan sizda materiallar bir nechta mintaqalar bo'ylab tarqatildi va siz buni sezmadingiz ham. Biroq, bu juda xavfli, chunki bu erda hamma narsa sehrga tayanadi.

Ammo jo'natuvchi asosan etkazib berish ta'sirini yumshatishga harakat qilsa-da, ko'p klasterli rejalashtiruvchi ko'proq umumiy vazifalarni bajaradi va, ehtimol, ommaviy ishlar uchun yaxshiroq mos keladi.

Bu ilg'or bosqichma-bosqich yetkazib berish mexanizmiga ega emas.

Ko'p klasterli rejalashtiruvchi haqida ko'proq ma'lumotni quyidagi manzilda topishingiz mumkin rasmiy ombor sahifasi.

Agar siz ko'p klasterli rejalashtirish haqida o'qishni istasangiz, Admiralty bor Argo bilan qiziqarli foydalanish holati — ish oqimlari, voqealar, CI va CD Kubernetes.

Boshqa vositalar va echimlar

Bir nechta klasterlarni ulash va boshqarish murakkab vazifa bo'lib, universal yechim yo'q.

Agar siz ushbu mavzuni batafsil o'rganmoqchi bo'lsangiz, bu erda ba'zi manbalar:

• Rancher tomonidan suv osti kemasi turli Kubernetes klasterlarining overlay tarmoqlarini birlashtiruvchi vositadir.
• Chakana savdo tarmog'idan maqsadli foydalanish Unimatrix Spinnaker bilan birlashtirilib, bir nechta klasterlarda joylashtirishni tartibga soladi.
• IPV6 va dan foydalanib ko'ring bir nechta hududlarda yagona tarmoq.
• Siz, masalan, xizmat ko'rsatish tarmog'idan foydalanishingiz mumkin Bir nechta klasterlarni ulash uchun Istio.
• Cilium, konteyner tarmoq interfeysi plaginini taklif qiladi klaster mesh funktsiyasi, bu sizga bir nechta klasterlarni birlashtirish imkonini beradi

Bugun hammasi shu

Oxirigacha o'qiganingiz uchun rahmat!

Agar siz bir nechta klasterlarni qanday qilib samaraliroq ulashni bilsangiz, bizga ayting.

Biz sizning usulingizni havolalarga qo'shamiz.

Kris Nesbitt-Smitga alohida rahmat (Kris Nesbitt-Smit) va Vinsent de Sme (Vinsent De Smet) (ishonchlilik muhandisi swatmobile.io) maqolani o'qish va federatsiya qanday ishlashi haqida foydali ma'lumot almashish uchun.

Manba: www.habr.com