🥇Kā savienot Kubernetes klasterus dažādās datu centrās

Laipni lūdzam Kubernetes īso rokasgrāmatu sērijā. Šī ir regulāra kolonna ar interesantākajiem jautājumiem, kurus saņemam tiešsaistē un mūsu apmācībās. Atbild eksperts par Kubernetes.

Šodienas eksperts ir Daniēls Polenčiks (Daniele Polencic). Daniēls strādā kā instruktors un programmatūras izstrādētājs uzņēmumā Learnk8s.

Ja vēlaties saņemt atbildi uz savu jautājumu nākamajā rakstā, sazinieties ar mums, izmantojot e-pastu vai uz Twitter: @learnk8s.

Palaidāt iepriekšējos rakstus? Meklējiet tos šeit.

Kā savienot Kubernetes klasterus dažādās datu centrā?

Īsi: drīzumā iznāks Kubefed v2, un vēl es iesaku izlasīt par Shipper un multi-cluster-scheduler projektā..

Salīdzinoši bieži infrastruktūra tiek replikēta un izplatīta dažādos reģionos, īpaši kontrolētās vidēs.

Ja viens reģions nav pieejams, datplūsma tiek novirzīta uz citu, lai izvairītos no traucējumiem.

Kubernetes var izmantot līdzīgu stratēģiju un izplatīt darba slodzes pa dažādiem reģioniem.

Jums var būt viens vai vairāki klasteri uz komandu, reģionu, vidi vai šo elementu kombināciju.

Jūsu klasteri var atrasties dažādās mākonī un lokālajā vidē.

Bet kā plānot infrastruktūru šādam ģeogrāfiskam izkliedējumam?
Vai jāizveido viens liels klasteris vairākām mākoņu vidēm pa vienotu tīklu?
Vai jāpievieno daudzi mazi klasteri un jāatrod veids, kā tos kontrolēt un sinhronizēt?

Viens vadības klasteris

Izveidot vienu klasteri pa vienotu tīklu nav tik viegli.

Iedomājieties, ka jums ir avārija, un ir zaudēta savienojamība starp klastera segmentiem.

Ja jums ir viens galvenais serveris, puse resursu nevarēs saņemt jaunas komandas, jo tās nevarēs sazināties ar galveno serveri.

Un šajā brīdī jums ir vecas maršrutēšanas tabulas (kube-proxy nav iespējams ielādēt jaunas) un nekādu papildu podu (kubelet nevar pieprasīt atjauninājumus).

Kas vēl sliktāk, ja Kubernetes neredz mezglu, tas to atzīmē kā zaudētu un izplata trūkstošos podus esošajos mezglos.

Rezultātā podu skaits jums būs divreiz lielāks.

Ja katram reģionam izveidosiet vienu galveno serveri, būs problēmas ar konsensa algoritmu datu bāzē etcd. (piezīme red. — Patiesībā etcd datubāze nav obligāti jāatrodas uz master serveriem. To var palaist uz atsevišķas serveru grupas vienā reģionā. Taču tas radītu klastera kļūmes punktu. Toties ātri.)

etcd izmanto raft algoritmu, lai saskaņotu vērtību pirms tās ierakstīšanas diskā.
Tas nozīmē, ka lielākajai daļai eksemplāru jāpanāk konsenss, pirms stāvokli var ierakstīt etdc.

Ja aizture starp etdc eksemplāriem pakāpeniski pieaug, kā tas ir ar trim etdc eksemplāriem dažādos reģionos, ir nepieciešams daudz laika, lai saskaņotu vērtību un ierakstītu to diskā.
Tas ietekmē arī Kubernetes kontrolierus.

Kontrolieru menedžerim nepieciešams vairāk laika, lai uzzinātu par izmaiņām un ierakstītu atbildi datubāzē.

Un, ja kontrolieru ir vairāki, tiek radīta ķēdes reakcija, un viss klasteris sāk darboties ļoti lēni..

etcd ir tik jutīgs pret aizturi, ka oficiālajā dokumentācijā ieteicams izmantot SSD diskus, nevis parastos cietos diskus..

Pašlaik nav labu piemēru liels tīklam vienam klasterim.

Galvenokārt izstrādātāju kopiena un SIG-cluster grupa cenšas saprast, kā orķestrēt klasterus tāpat kā Kubernetes orķestrē konteinerus.

1. variants: klasteru federācija ar kubefed

Oficiālā atbilde no SIG-cluster — kubefed2, jaunā versija avota klientam un kube federācijas operatoram..

Pirmo reizi pārvaldīt klasteru kopumu kā vienu objektu mēģināja ar kube federācijas rīku.

Sākums bija labs, bet galu galā kube federācija tā arī nekļuva populāra, jo neatbalstīja visus resursus.

Tas atbalstīja apvienotā piedāvājuma un pakalpojumu funkciju, taču, piemēram, ne StatefulSets.
Un arī federācijas konfigurācija tika nodota kā anotācijas, un tai nebija elastības.

Iedomājieties, kā varētu aprakstīt replikāciju katram klasterim federācijā ar vienām anotācijām.

Tas izveidoja pilnīgu haosu.

SIG-cluster veica lielu darbu pēc kubefed v1 un nolēma pievērsties problēmai no cita skatpunkta.

Tā vietā, lai izmantotu anotācijas, viņi nolēma izlaist kontrolieri, kurš tiek uzstādīts klasteros. To var konfigurēt, izmantojot pielāgotus resursu definīcijas (Custom Resource Definition, CRD).

Katram resursam, kas būs federācijas sastāvdaļa, jums ir pielāgota CRD definīcija trīs sadaļās:

standarta resursa definīcija, piemēram, izvietojums;
sadaļā novietojums, kur jūs nosakāt, kā resurss tiks sadalīts federācijā;
sadaļā pārrakstīšana, kur konkrētam resursam var pārrakstīt svarus un parametrus no novietojuma.

Šeit ir piemērs apvienotās piegādes ar sadaļām novietojuma un pārrakstīšanas.

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

Kā redzat, piegāde ir sadalīta starp diviem klastiem: cluster1 un cluster2.

Pirmais klasteris piegādā trīs replikas, bet otrajam norādīta vērtība 5.

Ja jums nepieciešama lielāka kontrole pār replikām, kubefed2 sniedz jaunu objektu ReplicaSchedulingPreference, kur replikas var sadalīt pēc svara:

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 un API struktūra vēl nav pilnībā gatava, un oficiālajā projekta repozitorijā tiek aktīvi strādāts.

Sekojiet līdzi kubefed2, bet atcerieties, ka tas pašlaik nav piemērots ražošanas videi.

Uzziniet vairāk par kubefed2 no oficiālās kubefed2 raksta Kubernetes emuārā un oficiālā kubefed projekta repozitorija.

Varianta 2: klasteru apvienošana Booking.com stilā

Booking.com izstrādātāji nenodarbojās ar kubefed v2, taču izstrādāja Shipper — operatoru piegādēm vairāku klasteru, reģionu un mākoņu ietvaros.

Shipper daļēji līdzīgs kubefed2.

Abi rīki ļauj konfigurēt izvietošanas stratēģiju vairāku klasteru ietvaros (kuri klasteri tiek izmantoti un cik tos ir replikas).

Bet Shipper uzdevums ir samazināt kļūdu risku piegādē.

Shipper var definēt virkni soļu, kas apraksta replikāciju sadalījumu starp iepriekšējo un pašreizējo izvietojumu un ienākošā dat plūsmu.

Kad nosūtāt resursu klasterī, Shipper kontrolieris pakāpeniski ieviests šo izmaiņu visos apvienotajos klasteros.

Un vēl Shipper ir ļoti ierobežots.

Piemēram, tas pieņem Helm shēmas kā ievades datus. un un atbalsta vanilla resursus.
Vispārīgi runājot, Shipper darbojas šādi.

Vietā standarta piegādes jāizveido lietojumprogrammas resurss, kas ietver Helm-chart:

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 ir labs variants vairāku klasteru pārvaldībai, bet tā ciešā saistība ar Helm tikai traucē.

Un, ja mēs visi pāriešam no Helm uz Vienkārša kustomization faila izmantošana vai kapitan?

Uzziniet vairāk par Shipper un tā filozofiju šajā oficiālajā preses relīzē.

Ja vēlaties pētīt kodu, dodieties uz oficiālo projekta repozitoriju.

Variants 3: "maģiskā" klasteru apvienošana

Kubefed v2 un Shipper darbojas ar klasteru federāciju, nodrošinot klasteriem jaunus resursus, izmantojot lietotāja definētos resursus.

Bet, ja jūs nevēlaties pārrakstīt visas piegādes, StatefulSets, DaemonSets utt. apvienošanai?

Kā iekļaut esošo klasteri federācijā, nemainot YAML?

multi-cluster-scheduler ir Admirality projekts, kas nodarbojas ar slodzes plānošanu klasteros.

Bet, nevis izdomāt jaunu veidu, kā mijiedarboties ar klasteri un iesaiņot resursus lietotāja definīcijās, multi-cluster-scheduler integrējas standarta Kubernetes dzīves ciklā un pārņem visus izsaukumus, kas izveido podus.

Katrs izveidotais pods nekavējoties tiek aizstāts ar tukšu podu.

multi-cluster-scheduler izmanto web-hookus, lai modificētu piekļuvi, lai pārņemtu izsaukumu un izveidotu neaktīvu podu - tukšu podu.

Izcelsmes pods iziet vēl vienu plānošanas ciklu, kur pēc visas federācijas apsekošanas tiek pieņemts lēmums par izvietojumu.

Visbeidzot, pods tiek piegādāts mērķa klasterim.

Galu galā jums ir lieks pods, kas neko nedara, tikai aizņem vietu.

Priekšrocība ir tāda, ka jums nebija jāraksta jauni resursi piegādes apvienošanai.

Katrs resurss, kas izveido podu, automātiski ir gatavs piegādes apvienošanai.

Tas ir interesanti, jo pēkšņi jums ir piegādes, kas izkliedētas pa vairākiem reģioniem, bet jūs pat nenojaušat. Tomēr tas ir diezgan riskanti, jo viss šeit balstās uz burvību.

Bet, ja Shipper cenšas galvenokārt mazināt piegādes sekas, multi-cluster-scheduler veic vispārīgākas funkcijas un, iespējams, labāk der partiju uzdevumiem.

Tam nav attīstīta pakāpenisku piegāžu mehānisma.

Vairāk par multi-cluster-scheduler var uzzināt oficiālā krātuvē.

Ja vēlaties izlasīt par multi-cluster-scheduler darbībā, Admiralty ir interesants pielietojums ar Argo — darba plūsmām, notikumiem, CI un CD Kubernetes.

Citi rīki un risinājumi

Daudzu klasteru savienošana un pārvaldība ir sarežģīta uzdevums, universālas atbildes nav.

Ja vēlaties padziļināti izpētīt šo tēmu, lūk, daži resursi:

Submariner no Rancher — rīks, kas savieno dažādu Kubernetes klāsteru overlay tīklus.
Mazumtirdzniecības tīkls Target izmanto Unimatrix kopā ar Spinnaker, lai orķestrētu izvietošanu vairākos klasteros..
Mēģiniet izmantot IPV6 un vienotu tīklu vairākos reģionos..
Var izmantot service mesh, piemēram, Istio, lai savienotu vairākus klasterus..
Cilium, konteineru tīkla spraudnis, piedāvā klastera mezglu funkcionalitāti, kas ļauj apvienot vairākus klasterus.

Tas ir viss šodien.

Paldies, ka izlasījāt līdz galam!

Ja zināt, kā efektīvāk savienot vairākus klasterus, pastāstiet mums..

Mēs pievienosim jūsu metodi saistītajām saitēm.

Īpaša pateicība Krisam Nesbitam-Smitam (Chris Nesbitt-Smith) un Vensānam de Smetam (Vincent De Smet) (uzticamības inženierim no swatmobile.io) par to, ka izlasījāt rakstu un dalījāties noderīgā informācijā par to, kā darbojas federācija.

Avots: habr.com