Ongi etorri Kubernetes Quick Start Series-era. Sarean eta gure entrenamenduetan jasotzen ditugun galdera interesgarrienen zutabe arrunta da hau. Kubernetes adituen erantzunak.
Gaurko aditua Daniel Polenchik da (). Danielek irakasle eta software garatzaile gisa lan egiten du .
Hurrengo mezuan zure galderaren erantzuna nahi baduzu, edo .
Aurreko mezuak galdu dituzu? .
Nola konektatu Kubernetes klusterrak datu-zentro ezberdinetan?
laburki: , eta irakurtzea ere gomendatzen dizut ΠΈ .
Askotan, azpiegiturak eskualde ezberdinetan errepikatu eta banatzen dira, batez ere ingurune kontrolatuetan.
Eskualde bat erabilgarri ez badago, trafikoa beste batera birbideratzen da etenaldiak saihesteko.
Kubernetes-ekin, antzeko estrategia bat erabil dezakezu eta lan-kargak eskualde ezberdinetan banatu ditzakezu.
Talde, eskualde, ingurune edo hauen konbinazio bakoitzeko kluster bat edo gehiago izan ditzakezu.
Zure klusterrak hainbat hodeitan eta lokaletan ostata daitezke.
Baina nola planifikatu azpiegiturak halako hedapen geografiko baterako?
Kluster handi bat sortu behar al duzu sare bakarrean hainbat hodei-ingurunetarako?
Edo kluster txiki asko dituzu eta haiek kontrolatzeko eta sinkronizatzeko modua aurkitu?
Lidergo kluster bat
Sare bakarrean kluster bat sortzea ez da hain erraza.
Imajinatu istripu bat duzula, kluster-segmentuen arteko konexioa galtzen dela.
Zerbitzari nagusi bat baduzu, baliabideen erdiak ezin izango ditu komando berriak jaso, ezin izango baitute maisuarekin harremanetan jarri.
Eta, aldi berean, bideratze-taula zaharrak dituzu (kube-proxy ezin ditu berririk deskargatu) eta ez dago osagarririk (kubelet-ek ezin du eguneratzerik eskatu).
Are okerragoa dena, Kubernetes-ek ezin badu nodorik ikusten, umezurtz gisa markatzen du eta falta diren lekak lehendik dauden nodoetara banatzen ditu.
Ondorioz, leka bikoitza duzu.
Eskualde bakoitzeko zerbitzari nagusi bat egiten baduzu, etcd datu-basean adostasun algoritmoarekin arazoak izango dira. (gutxi gorabehera. ed. - Izan ere, etcd datu-basea ez da zertan zerbitzari nagusietan kokatu. Eskualde bereko zerbitzari talde bereizi batean exekutatu daiteke. Hala ere, kluster baten hutsegite puntu bat aldi berean jaso izana. Baina azkar.)
etcd erabilerak balio bat adosteko diskoan idatzi aurretik.
Hau da, kasu gehienek adostasuna lortu behar dute estatua etcd-i idatzi aurretik.
Etcd instantzien arteko latentzia gora egiten badu, eskualde ezberdinetako hiru etcd instantziekin gertatzen den bezala, denbora asko behar da balio bat adosteko eta diskoan idazteko.
Hau Kubernetes kontrolagailuetan ere islatzen da.
Kontrolatzaileen kudeatzaileak denbora gehiago behar du aldaketari buruz ikasteko eta erantzuna datu-basean idazteko.
Eta kontrolatzailea ez denez bat, hainbat baizik, kate-erreakzio bat lortzen da, eta kluster osoa oso poliki hasten da lanean.
etcd hain da latentzia sentikorra dela .
Gaur egun ez dago sare handi baten adibide onik kluster bakarrerako.
Funtsean, garatzaileen komunitatea eta SIG-kluster taldea klusterrak nola antolatu Kubernetes-ek edukiontziak antolatzen dituen modu berean saiatzen ari dira.
1. aukera: federatu klusterrak kubefed-ekin
SIG-klusterren erantzun ofiziala - .
Lehen aldiz, kluster bilduma bat objektu bakar gisa kudeatzen saiatu gara kube federazio tresna erabiliz.
Hasiera ona izan zen, baina azkenean kube federazioa ez zen ezagun egin, baliabide guztiak onartzen ez zituelako.
Federatutako hornikuntzak eta zerbitzuak onartzen zituen, baina ez StatefulSets, adibidez.
Gainera, federazioaren konfigurazioa oharpen moduan pasa zen eta ez zen malgua.
Imajinatu nola deskriba dezakezun federazio bateko kluster bakoitzaren errepliken zatiketa oharpen bakarra erabiliz.
Nahaspila osoa izan zen.
SIG-cluster-ek lan bikaina egin zuen kubefed v1-en ondoren eta arazoari beste angelu batetik jorratzea erabaki zuen.
Oharpenen ordez, klusterretan instalatuta dagoen kontrolagailu bat kaleratzea erabaki zuten. Baliabideen definizio pertsonalizatuak (Custom Resource Definition, CRD) erabiliz konfigura daiteke.
Federatuko den baliabide bakoitzeko, CRD definizio pertsonalizatua duzu hiru ataletan:
- Baliabide baten definizio estandarra, esaterako, hedatzea;
- atala
placement, non federazioan baliabidea nola banatuko den definitzen duzun; - atala
override, non baliabide zehatz baterako pisua eta parametroak kokapenetik gainidatzi ditzakezu.
Hona hemen kokapen eta gainidazteko atalekin bateratutako entrega baten adibide bat.
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: 5Ikus dezakezunez, hornidura bi multzotan banatzen da: cluster1 ΠΈ cluster2.
Lehenengo klusterrak hiru erreplika hornitzen ditu, eta bigarrenak 5 balio du.
Erreplika kopuruaren gaineko kontrol gehiago behar baduzu, kubefed2-k ReplicaSchedulingPreference objektu berri bat eskaintzen du, non erreplikak haztatu daitezkeen:
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 egitura eta APIa ez daude guztiz prest oraindik, eta lan aktiboa egiten ari da proiektuaren biltegi ofizialean.
Begiratu kubefed2-ri, baina kontuan izan oraindik ez dela nahikoa ekoizpen-ingurune baterako.
Lortu informazio gehiago kubefed2-i buruz Kubernetes blogean eta .
2. aukera: Booking.com estiloa multzokatzea
Booking.com-en garatzaileek ez zuten kubefed v2-rekin jorratu, baina Shipper-ekin sortu zuten, hainbat kluster, eskualde eta hodei anitzetan entregatzeko operadorea.
kubefed2-ren antzeko samarra.
Bi tresnek aukera ematen dizute zure kluster anitzeko inplementazio estrategia pertsonalizatzeko (zein kluster erabiltzen diren eta zenbat erreplika dituzten).
Baina Bidaltzailearen lana entrega akatsen arriskua murriztea da.
Shipper-en, aurreko eta egungo inplementazioen arteko errepliken banaketa eta sarrerako trafikoaren zenbatekoa deskribatzen duten urrats batzuk defini ditzakezu.
Baliabide bat kluster batera bultzatzen duzunean, Shipper kontrolatzaileak pixkanaka zabaltzen du aldaketa hori federatutako kluster guztietan.
Bidaltzailea ere oso mugatua da.
Esate baterako, Helm diagramak hartzen ditu sarrera gisa eta ez ditu bainila baliabideak onartzen.
Orokorrean, Shipper honela funtzionatzen du.
Banaketa estandar baten ordez, Helm diagrama barne duen aplikazio-baliabide bat sortu behar duzu:
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 aukera ona da hainbat kluster kudeatzeko, baina Helm-ekin duen harreman estua oztopatzen du.
Zer gertatzen da denok Helm-era aldatzen bagara edo ?
Lortu informazio gehiago Shipper eta bere filosofiari buruz hemen .
Kodea sakondu nahi baduzu, .
3. aukera: kluster "magikoa" bateratzea
Kubefed v2 eta Shipper-ek kluster federazioarekin lan egiten dute klusterrei baliabide berriak eskainiz baliabide pertsonalizatuen definizio baten bidez.
Baina zer gertatzen da batu beharreko hornigai guztiak, StatefulSets, DaemonSets eta abar berridatzi nahi ez badituzu?
Nola sartu lehendik dagoen kluster bat federazioan YAML aldatu gabe?
, klusterren lan-kargak antolatzeaz arduratzen dena.
Baina klusterrekin elkarreragiteko modu berri bat asmatu beharrean eta baliabideak definizio pertsonalizatuetan biltzeko, multi-cluster-scheduler Kubernetes-en bizi-ziklo estandarrean sartzen da eta podak sortzen dituzten dei guztiak atzematen ditu.
Sortutako pod bakoitza maniki batekin ordezkatzen da berehala.
multi-cluster-scheduler erabilerak deia atzemateko eta inaktibo finko pod bat sortzeko.
Jatorrizko podak beste programazio-ziklo batetik pasatzen du, non, federazio osoari galdeketa egin ondoren, anfitrioiaren erabakia hartzen den.
Azkenik, pod-a xede-klusterera entregatzen da.
Ondorioz, ezer egiten ez duen leka gehigarri bat duzu, lekua hartzen duena.
Abantaila da ez duzula baliabide berririk idatzi behar hornikuntzak konbinatzeko.
Pod bat sortzen duen baliabide bakoitza automatikoki prest dago federatzeko.
Hau interesgarria da, bat-batean hainbat eskualdetan banatuta dituzulako hornigaiak, eta ez zarete ohartu. Hala ere, hau nahiko arriskutsua da, hemen dena magian oinarritzen delako.
Baina Shipper batik bat bidalketen ondorioak arintzen saiatzen ari den arren, multi-cluster-scheduler orokorragoa da eta agian hobeto egokitzen da loteetako lanetarako.
Ez du mailakako entrega mekanismo aurreraturik.
Multi-cluster-scheduler-ari buruzko informazio gehiago hemen aurki daiteke .
Multi-cluster-scheduler ekintzan irakurri nahi baduzu, Admiralty-k du - lan-fluxuak, gertaerak, CI eta CD Kubernetes.
Beste tresna eta irtenbide batzuk
Hainbat kluster konektatzea eta kudeatzea zeregin konplexua da, eta ez dago soluzio bakarra.
Gai honi buruz gehiago jakin nahi baduzu, hona hemen baliabide batzuk:
- Kubernetes kluster ezberdinen gainjarri sareak lotzen dituen tresna da.
- Target txikizkako kateak erabiltzen du .
- Saiatu IPV6 erabiltzen eta .
- Zerbitzu-sare bat erabil dezakezu, adibidez .
- Cilium, edukiontzi sareko interfazearen plugina eskaintzen du , hainbat kluster konbinatzeko aukera ematen duena
Hori da dena gaurko
Eskerrik asko amaiera arte irakurtzeagatik!
Hainbat kluster modu eraginkorragoan konektatzen badakizu, .
Zure metodoa gehituko dugu esteketan.
Esker berezia Chris Nesbitt-Smith-i () eta Vincent de Sme () (fidagarritasun ingeniariari ) artikulua irakurtzeagatik eta federazioaren funtzionamenduari buruzko informazio erabilgarria partekatzeko.
Iturria: www.habr.com