Maligayang pagdating sa aming Kubernetes Quick Start series. Ito ay isang regular na column na may mga pinakakawili-wiling tanong na natatanggap namin online at sa aming mga pagsasanay. Mga sagot ng eksperto sa Kubernetes.
Ang dalubhasa ngayon ay si Daniel Polenchik (). Nagtatrabaho si Daniel bilang isang instructor at software developer sa .
Kung gusto mong masagot ang iyong tanong sa susunod na post, o .
Na-miss ang mga nakaraang post? .
Paano ikonekta ang mga kumpol ng Kubernetes sa iba't ibang mga sentro ng data?
Sa madaling sabi: , at inirerekumenda ko rin ang pagbabasa tungkol sa ΠΈ .
Kadalasan, ang imprastraktura ay ginagaya at ipinamamahagi sa iba't ibang rehiyon, lalo na sa mga kontroladong kapaligiran.
Kung hindi available ang isang rehiyon, ire-redirect ang trapiko sa isa pa upang maiwasan ang mga pagkaantala.
Sa Kubernetes, maaari kang gumamit ng katulad na diskarte at ipamahagi ang mga workload sa iba't ibang rehiyon.
Maaari kang magkaroon ng isa o higit pang mga kumpol sa bawat koponan, rehiyon, kapaligiran, o kumbinasyon ng mga elementong ito.
Maaaring i-host ang iyong mga cluster sa iba't ibang cloud at on-premise.
Ngunit paano mo pinaplano ang imprastraktura para sa naturang geographic spread?
Kailangan mo bang lumikha ng isang malaking kumpol para sa ilang cloud environment sa isang network?
O may maraming maliliit na kumpol at humanap ng paraan para kontrolin at i-synchronize ang mga ito?
Isang kumpol ng pamumuno
Ang paglikha ng isang kumpol sa isang solong network ay hindi napakadali.
Isipin na naaksidente ka, nawala ang koneksyon sa pagitan ng mga segment ng cluster.
Kung mayroon kang isang master server, kalahati ng mga mapagkukunan ay hindi makakatanggap ng mga bagong command dahil hindi nila magagawang makipag-ugnayan sa master.
At sa parehong oras mayroon kang mga lumang routing table (kube-proxy hindi makapag-download ng mga bago) at walang karagdagang mga pod (hindi maaaring humiling ng mga update ang kubelet).
Ang masama pa nito, kung walang nakikitang node ang Kubernetes, minarkahan ito bilang ulila at ibinabahagi ang mga nawawalang pod sa mga kasalukuyang node.
Bilang resulta, mayroon kang dobleng dami ng mga pod.
Kung gumawa ka ng isang master server para sa bawat rehiyon, magkakaroon ng mga problema sa consensus algorithm sa etcd database. (tinatayang ed. β Sa katunayan, ang etcd database ay hindi kinakailangang matatagpuan sa mga master server. Maaari itong patakbuhin sa isang hiwalay na pangkat ng mga server sa parehong rehiyon. Totoo, sa parehong oras ay nakakakuha ng isang punto ng kabiguan ng kumpol. Ngunit mabilis.)
etcd gamit upang makipag-ayos sa halaga bago ito isulat sa disk.
Iyon ay, ang karamihan ng mga pagkakataon ay dapat maabot ang pinagkasunduan bago maisulat ang estado sa etcd.
Kung ang latency sa pagitan ng etcd instance ay tumaas nang husto, tulad ng kaso sa tatlong etcd instance sa iba't ibang rehiyon, ito ay tumatagal ng mahabang panahon upang makipag-ayos ng isang value at isulat ito sa disk.
Ito ay makikita sa mga Kubernetes controllers.
Ang controller manager ay nangangailangan ng mas maraming oras upang malaman ang tungkol sa pagbabago at isulat ang tugon sa database.
At dahil walang isang controller, ngunit marami, nagreresulta ang isang chain reaction at ang buong cluster ay nagsimulang gumana nang napakabagal.
etcd ay sobrang latency sensitive na .
Sa kasalukuyan ay walang magandang halimbawa ng isang malaking network para sa isang kumpol.
Sa pangkalahatan, sinusubukan ng komunidad ng developer at ng grupong SIG-cluster na malaman kung paano i-orkestrate ang mga cluster sa parehong paraan na inoorkestrate ng Kubernetes ang mga container.
Opsyon 1: cluster federation na may kubefed
Opisyal na tugon mula sa SIG-cluster - .
Sa unang pagkakataon, sinubukan naming pamahalaan ang isang koleksyon ng mga kumpol bilang isang bagay gamit ang tool ng kube federation.
Maganda ang simula, ngunit sa huli ay hindi naging sikat ang kube federation dahil hindi nito sinusuportahan ang lahat ng resources.
Sinuportahan nito ang mga federated na paghahatid at serbisyo, ngunit hindi StatefulSets, halimbawa.
Gayundin, ang pagsasaayos ng federation ay ipinadala sa anyo ng mga anotasyon at hindi nababaluktot.
Isipin kung paano mo mailalarawan ang replica partitioning para sa bawat cluster sa isang federation gamit lang ang mga anotasyon.
Ito ay isang ganap na gulo.
Ang SIG-cluster ay gumawa ng maraming trabaho pagkatapos ng kubefed v1 at nagpasya na lapitan ang problema mula sa ibang anggulo.
Sa halip na mga anotasyon, nagpasya silang maglabas ng controller na naka-install sa mga cluster. Maaari itong i-customize gamit ang Custom Resource Definition (CRDs).
Para sa bawat mapagkukunan na magiging bahagi ng federation, mayroon kang custom na kahulugan ng CRD na may tatlong seksyon:
- karaniwang kahulugan ng isang mapagkukunan, halimbawa deployment;
- seksyon
placement, kung saan mo tutukuyin kung paano ipapamahagi ang mapagkukunan sa federation; - seksyon
override, kung saan para sa isang partikular na mapagkukunan maaari mong i-override ang timbang at mga parameter mula sa pagkakalagay.
Narito ang isang halimbawa ng pinagsamang paghahatid na may mga seksyon ng placement at 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: 5Tulad ng nakikita mo, ang supply ay ipinamamahagi sa dalawang kumpol: cluster1 ΠΈ cluster2.
Ang unang cluster ay nagbibigay ng tatlong replika, at ang pangalawa ay nakatakda sa 5.
Kung kailangan mo ng higit pang kontrol sa bilang ng mga replika, nagbibigay ang kubefed2 ng bagong ReplicaSchedulingPreference object kung saan maaaring timbangin ang mga replika:
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 istraktura ng CRD at API ay hindi pa handa, at ang aktibong gawain ay isinasagawa sa opisyal na repositoryo ng proyekto.
Pagmasdan ang kubefed2, ngunit tandaan na hindi pa ito angkop para sa produksyon.
Matuto pa tungkol sa kubefed2 mula sa sa blog tungkol sa Kubernetes at sa .
Opsyon 2: pagsasama-sama ng mga cluster sa istilong Booking.com
Ang mga developer ng Booking.com ay hindi gumana sa kubefed v2, ngunit nakabuo sila ng Shipper - isang operator para sa paghahatid sa ilang mga cluster, sa ilang mga rehiyon at sa ilang mga ulap.
medyo katulad ng kubefed2.
Ang parehong mga tool ay nagbibigay-daan sa iyo na i-customize ang iyong multi-cluster na diskarte sa pag-deploy (kung aling mga cluster ang ginagamit at kung gaano karaming mga replika ang mayroon sila).
Pero Ang layunin ng Shipper ay bawasan ang panganib ng mga error sa panahon ng paghahatid.
Sa Shipper, maaari mong tukuyin ang isang serye ng mga hakbang na naglalarawan sa paghahati ng mga replika sa pagitan ng nakaraan at kasalukuyang deployment at ang dami ng papasok na trapiko.
Kapag nag-push ka ng resource sa isang cluster, ang Shipper controller ay unti-unting inilalabas ang pagbabagong iyon sa lahat ng pinagsamang cluster.
Gayundin, ang Shipper ay napakalimitado.
Halimbawa, tumatanggap ito ng mga helm chart bilang input at hindi sumusuporta sa mga mapagkukunan ng vanilla.
Sa pangkalahatan, gumagana ang Shipper nang ganito.
Sa halip na karaniwang paghahatid, kailangan mong gumawa ng mapagkukunan ng application na may kasamang 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: 3Ang Shipper ay isang magandang opsyon para sa pamamahala ng maraming cluster, ngunit ang malapit na kaugnayan nito sa Helm ay nakakasagabal lamang.
Paano kung lahat tayo ay lumipat mula sa Helm sa o ?
Alamin ang higit pa tungkol sa Shipper at ang pilosopiya nito sa .
Kung gusto mong maghukay sa code, .
Opsyon 3: "magic" cluster merge
Gumagana ang Kubefed v2 at Shipper sa cluster federation, na nagbibigay ng mga bagong resource sa mga cluster sa pamamagitan ng custom na resource definition.
Ngunit paano kung ayaw mong muling isulat ang lahat ng mga paghahatid, StatefulSets, DaemonSets, atbp. upang pagsamahin?
Paano isama ang isang umiiral na kumpol sa isang pederasyon nang hindi binabago ang YAML?
, na tumatalakay sa pag-iskedyul ng mga workload sa mga cluster.
Ngunit sa halip na makabuo ng bagong paraan upang makipag-ugnayan sa cluster at mag-wrap ng mga mapagkukunan sa mga custom na kahulugan, ang multi-cluster-scheduler ay naka-embed sa karaniwang Kubernetes lifecycle at humarang sa lahat ng tawag na gumagawa ng mga pod.
Ang bawat nilikha na pod ay agad na pinapalitan ng isang dummy.
paggamit ng multi-cluster-scheduler para harangin ang tawag at gumawa ng idle dummy pod.
Ang orihinal na pod ay dumadaan sa isa pang yugto ng pagpaplano kung saan, pagkatapos ng botohan sa buong pederasyon, isang desisyon sa paglalagay.
Sa wakas, ang pod ay naihatid sa target na kumpol.
Bilang resulta, mayroon kang dagdag na pod na walang ginagawa, kumukuha lang ng espasyo.
Ang kalamangan ay hindi mo kailangang magsulat ng mga bagong mapagkukunan upang pagsamahin ang mga supply.
Ang bawat mapagkukunan na lumilikha ng pod ay awtomatikong handang i-merge.
Ito ay kawili-wili, dahil bigla kang nagkaroon ng mga supply na ipinamahagi sa maraming rehiyon, at hindi mo man lang napansin. Gayunpaman, ito ay medyo mapanganib, dahil ang lahat dito ay nakasalalay sa magic.
Ngunit habang sinusubukan ng Shipper na halos pagaanin ang epekto ng mga paghahatid, pinangangasiwaan ng multi-cluster-scheduler ang mas pangkalahatang mga gawain at marahil ay mas angkop para sa mga batch na trabaho.
Wala itong advanced na mekanismo ng unti-unting paghahatid.
Higit pa tungkol sa multi-cluster-scheduler ay matatagpuan sa .
Kung gusto mong basahin ang tungkol sa multi-cluster-scheduler sa aksyon, mayroon ang Admiralty β mga daloy ng trabaho, mga kaganapan, CI at CD Kubernetes.
Iba pang mga tool at solusyon
Ang pagkonekta at pamamahala ng maraming kumpol ay isang kumplikadong gawain, at walang pangkalahatang solusyon.
Kung gusto mong galugarin pa ang paksang ito, narito ang ilang mapagkukunan:
- ay isang tool na nag-uugnay sa mga overlay na network ng iba't ibang Kubernetes cluster.
- Mga gamit ng retail chain na Target .
- Subukang gamitin ang IPV6 at .
- Maaari kang gumamit ng mesh ng serbisyo, halimbawa .
- Nag-aalok ang Cilium, isang container network interface plugin , na nagpapahintulot sa iyo na pagsamahin ang ilang mga kumpol
Yan lamang para sa araw na ito
Salamat sa pagbabasa hanggang dulo!
Kung alam mo kung paano ikonekta ang maramihang mga kumpol nang mas mahusay, .
Idaragdag namin ang iyong pamamaraan sa mga link.
Espesyal na pasasalamat kay Chris Nesbitt-Smith () at Vincent de Sme () (inhinyero ng pagiging maaasahan sa ) para sa pagbabasa ng artikulo at pagbabahagi ng kapaki-pakinabang na impormasyon tungkol sa kung paano gumagana ang pederasyon.
Pinagmulan: www.habr.com