Welcome sa Kubernetes Quick Start Series. Kini usa ka regular nga kolum nga adunay labing makapaikag nga mga pangutana nga among makuha online ug sa among mga pagbansay. Mga tubag sa eksperto sa Kubernetes.
Ang eksperto karon mao si Daniel Polenchik (). Si Daniel nagtrabaho isip instruktor ug software developer sa .
Kung gusto nimo ang tubag sa imong pangutana sa sunod nga post, o .
Nawala ang nangaging mga post? .
Giunsa pagkonektar ang mga kumpol sa Kubernetes sa lainlaing mga sentro sa datos?
Sa mubo: , ug gitambagan ko usab ikaw sa pagbasa bahin sa и .
Kasagaran, ang imprastraktura gikopya ug giapod-apod sa lainlaing mga rehiyon, labi na sa mga kontrolado nga palibot.
Kung ang usa ka rehiyon dili magamit, ang trapiko ibalhin sa lain aron malikayan ang mga pagkabalda.
Uban sa Kubernetes, mahimo nimong gamiton ang parehas nga estratehiya ug ipang-apod-apod ang mga workload sa lainlaing mga rehiyon.
Mahimo kang adunay usa o daghan pang mga cluster kada team, rehiyon, palibot, o kombinasyon niini.
Ang imong mga cluster mahimong i-host sa daghang mga panganod ug sa lugar.
Apan unsaon pagplano ang imprastraktura alang sa ingon nga geographical nga pagkaylap?
Kinahanglan ba nimo nga maghimo usa ka dako nga cluster alang sa daghang mga cloud environment sa usa ka network?
O adunay daghang gagmay nga mga pungpong ug mangita usa ka paagi aron makontrol ug ma-synchronize kini?
Usa ka cluster sa pagpangulo
Ang paghimo og usa ka cluster sa usa ka network dili kaayo sayon.
Hunahunaa nga ikaw adunay usa ka aksidente, ang koneksyon tali sa mga bahin sa cluster nawala.
Kung ikaw adunay usa ka master server, ang katunga sa mga kapanguhaan dili makadawat mga bag-ong mando tungod kay dili sila makontak sa agalon.
Ug sa samang higayon aduna kay daan nga mga routing tables (kube-proxy dili maka-download ug mga bag-o) ug walay dugang nga mga pod (kubelet dili makapangutana sa mga update).
Mas grabe pa, kung ang Kubernetes dili makakita sa usa ka node, kini nagtimaan niini ingon nga mga ilo ug nag-apod-apod sa mga nawala nga mga pod sa mga kasamtangan nga mga node.
Ingon usa ka sangputanan, doble ang imong gidaghanon sa mga pod.
Kung maghimo ka usa ka master server matag rehiyon, adunay mga problema sa consensus algorithm sa etcd database. (gibanabana. ed. - Sa tinuud, ang etcd database dili kinahanglan nga mahimutang sa mga master server. Mahimo kini nga ipadagan sa usa ka lahi nga grupo sa mga server sa parehas nga rehiyon. Bisan pa, nga nakadawat sa samang higayon usa ka punto sa kapakyasan sa usa ka cluster. Apan kadali.)
etcd gamit sa pag-uyon sa usa ka bili sa dili pa kini isulat sa disk.
Kana mao, kadaghanan sa mga higayon kinahanglan nga makab-ot ang usa ka consensus sa dili pa ang estado mahimong isulat sa etcd.
Kung ang latency tali sa etcd nga mga higayon motaas, sama sa kaso sa tulo ka etcd nga mga higayon sa lain-laing mga rehiyon, kini nagkinahanglan og taas nga panahon sa pag-uyon sa usa ka bili ug isulat kini sa disk.
Gipakita usab kini sa mga tigkontrol sa Kubernetes.
Ang tigdumala sa tigdumala nanginahanglan daghang oras aron mahibal-an ang bahin sa pagbag-o ug isulat ang tubag sa database.
Ug tungod kay ang controller dili usa, apan daghan, nakuha ang kadena nga reaksyon, ug ang tibuuk nga cluster nagsugod sa pagtrabaho nga hinay kaayo.
etcd mao ang latency sensitibo nga .
Sa pagkakaron walay maayong mga pananglitan sa usa ka dako nga network alang sa usa ka cluster.
Sa panguna, ang komunidad sa nag-develop ug ang grupo sa SIG-cluster naningkamot nga mahibal-an kung giunsa ang pag-orkestrate sa mga kumpol sa parehas nga paagi nga gi-orkestra sa Kubernetes ang mga sulud.
Opsyon 1: i-federate ang mga cluster nga adunay kubefed
Opisyal nga tubag gikan sa SIG-cluster - .
Sa unang higayon, gisulayan namo ang pagdumala sa usa ka koleksyon sa mga cluster isip usa ka butang gamit ang kube federation tool.
Ang sinugdanan maayo, apan sa katapusan, ang kube federation wala nahimong popular, tungod kay wala kini nagsuporta sa tanan nga mga kapanguhaan.
Gisuportahan niini ang mga federated nga suplay ug serbisyo, apan dili StatefulSets, pananglitan.
Usab, ang configuration sa federation gipasa sa porma sa mga anotasyon ug dili flexible.
Hunahunaa kung giunsa nimo paghulagway ang pagbahin sa mga replika para sa matag cluster sa usa ka federation gamit ang usa ka anotasyon.
Nahimong bug-os nga kagubot.
Ang SIG-cluster nakahimo usa ka maayo nga trabaho pagkahuman sa kubefed v1 ug nakahukom sa pagduol sa problema gikan sa lainlaing anggulo.
Imbis nga mga anotasyon, nakahukom sila nga buhian ang usa ka controller nga gi-install sa mga cluster. Mahimo kini ma-configure gamit ang custom nga mga kahulugan sa kapanguhaan (Custom Resource Definition, CRD).
Para sa matag kahinguhaan nga i-federated, aduna kay custom CRD definition sa tulo ka seksyon:
- usa ka sumbanan nga kahulugan sa usa ka kapanguhaan, sama sa pag-deploy;
- seksyon
placement, diin imong gihubit kung unsaon pag-apod-apod ang kapanguhaan sa pederasyon; - seksyon
override, diin alang sa usa ka piho nga kapanguhaan mahimo nimong i-override ang gibug-aton ug mga parameter gikan sa pagbutang.
Ania ang usa ka pananglitan sa usa ka gihugpong nga pagpadala nga adunay pagbutang ug pag-override nga mga seksyon.
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: 5Sama sa imong nakita, ang suplay gibahin sa duha nga mga pungpong: cluster1 и cluster2.
Ang una nga cluster naghatag ug tulo ka mga replika, ug ang ikaduha adunay kantidad nga 5.
Kung kinahanglan nimo ang dugang nga kontrol sa gidaghanon sa mga replika, ang kubefed2 naghatag usa ka bag-ong butang nga ReplicaSchedulingPreference diin ang mga replika mahimong matimbang:
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: 2Ang istruktura sa CRD ug API dili pa andam, ug ang aktibo nga trabaho nagpadayon sa opisyal nga repositoryo sa proyekto.
Bantayi ang kubefed2, apan hinumdomi nga kini dili pa igo alang sa usa ka palibot sa produksiyon.
Pagkat-on og dugang mahitungod sa kubefed2 gikan sa sa Kubernetes blog ug .
Opsyon 2: Pag-cluster sa Estilo sa Booking.com
Ang mga nag-develop sa Booking.com wala mag-atubang sa kubefed v2, apan sila adunay Shipper, usa ka operator alang sa pagpadala sa daghang mga cluster, daghang mga rehiyon, ug daghang mga panganod.
medyo susama sa kubefed2.
Ang duha ka mga himan nagtugot kanimo sa pag-customize sa imong multi-cluster deployment nga estratehiya (unsa nga mga clusters ang gigamit ug kung pila ang ilang mga replika).
apan Ang trabaho sa Shipper mao ang pagpakunhod sa risgo sa mga sayup sa pagpadala.
Sa Shipper, mahimo nimong ipasabut ang usa ka serye sa mga lakang nga naghulagway sa pagbahin sa mga replika tali sa kaniadto ug karon nga mga pag-deploy ug ang gidaghanon sa umaabot nga trapiko.
Kung imong iduso ang usa ka kapanguhaan sa usa ka kumpol, ang tigkontrol sa Shipper padayon nga nag-deploy nga pagbag-o sa tanan nga mga federated cluster.
Usab ang Shipper limitado kaayo.
Kay sa panig-ingnan, nagkinahanglan kini og Helm charts isip input ug wala nagsuporta sa mga kahinguhaan sa vanilla.
Sa kinatibuk-ang termino, ang Shipper nagtrabaho sama sa mosunod.
Imbis nga usa ka standard nga pag-apod-apod, kinahanglan nimo nga maghimo usa ka kapanguhaan sa aplikasyon nga adunay usa ka tsart sa 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: 3Ang Shipper usa ka maayong kapilian alang sa pagdumala sa daghang mga kumpol, apan ang suod nga relasyon niini sa Helm nakababag lang.
Unsa kaha kon kitang tanan mobalhin gikan sa Helm ngadto sa o ?
Pagkat-on og dugang mahitungod sa Shipper ug sa iyang pilosopiya sa .
Kung gusto nimo nga magkalot sa code, .
Opsyon 3: "magic" cluster merging
Ang Kubefed v2 ug Shipper nagtrabaho kauban ang cluster federation pinaagi sa paghatag og bag-ong mga kapanguhaan sa mga clusters pinaagi sa custom resource definition.
Apan unsa man kung dili nimo gusto nga isulat pag-usab ang tanan nga mga suplay, StatefulSets, DaemonSets, ug uban pa nga i-merge?
Giunsa paglakip ang usa ka naa nga kumpol sa pederasyon nga wala usba ang YAML?
, nga naghisgot sa pag-iskedyul sa mga workload sa mga cluster.
Apan imbes nga mag-imbento ug bag-ong paagi sa pagpakig-uban sa cluster ug pagputos sa mga kahinguhaan sa custom definitions, ang multi-cluster-scheduler gi-inject sa standard Kubernetes lifecycle ug gi-intercept ang tanang tawag nga nagmugna og pods.
Ang matag gibuhat pod gipulihan dayon og dummy.
paggamit sa multi-cluster-scheduler aron ma-intercept ang tawag ug maghimo ug idle dummy pod.
Ang orihinal nga pod moagi sa laing siklo sa pag-iskedyul diin, human sa pagboto sa tibuok federation, usa ka desisyon sa pag-host ang gihimo.
Sa katapusan, ang pod ihatod sa target cluster.
Ingon usa ka sangputanan, ikaw adunay usa ka dugang nga pod nga wala’y mahimo, nagkinahanglag espasyo.
Ang bentaha mao nga dili nimo kinahanglan nga magsulat og bag-ong mga kapanguhaan aron makombinar ang mga suplay.
Ang matag kahinguhaan nga nagmugna og pod awtomatik nga andam nga i-federated.
Makapainteres kini, tungod kay kalit nga adunay mga suplay nga giapod-apod sa daghang mga rehiyon, ug wala nimo namatikdan. Bisan pa, kini peligroso kaayo, tungod kay dinhi ang tanan nagsalig sa salamangka.
Apan samtang ang Shipper nag-una nga naningkamot sa pagpagaan sa mga epekto sa mga padala, ang multi-cluster-scheduler mas kasagaran ug tingali mas haum alang sa mga batch nga trabaho.
Wala kini usa ka advanced nga hinay-hinay nga mekanismo sa paghatud.
Dugang pa bahin sa multi-cluster-scheduler makita sa .
Kung gusto nimo basahon ang bahin sa multi-cluster-scheduler sa aksyon, Admiralty adunay - mga workflow, panghitabo, CI ug CD Kubernetes.
Uban pang mga himan ug solusyon
Ang pagkonektar ug pagdumala sa daghang mga pungpong usa ka komplikado nga buluhaton, ug wala'y usa ka gidak-on nga mohaum sa tanan nga solusyon.
Kung gusto nimo mahibal-an ang dugang bahin sa kini nga hilisgutan, aniay pipila nga mga kapanguhaan:
- kay usa ka himan nga nagkonektar sa mga overlay nga network sa lain-laing Kubernetes clusters.
- Ang Target retail chain naggamit .
- Sulayi gamit ang IPV6 ug .
- Mahimo nimong gamiton ang usa ka service mesh, pananglitan .
- Ang Cilium, usa ka plugin sa interface sa sulud sa sulud, nagtanyag , nga nagtugot kanimo sa paghiusa sa daghang mga cluster
Kana lang para karong adlawa
Salamat sa pagbasa hangtod sa katapusan!
Kung nahibal-an nimo kung giunsa ang mas episyente nga pagkonektar sa daghang mga cluster, .
Idugang namo ang imong pamaagi sa mga link.
Espesyal nga pasalamat ngadto kang Chris Nesbitt-Smith () ug Vincent de Sme () (sa kasaligan nga engineer sa ) alang sa pagbasa sa artikulo ug pagpaambit sa mapuslanong impormasyon bahin sa kon sa unsang paagi ang pederasyon molihok.
Source: www.habr.com