Hûn bi xêr hatin rêzika meya Destpêka Zûtirîn Kubernetes. Ev stûnek birêkûpêk e bi pirsên herî balkêş ên ku em li serhêl û di perwerdehiyên xwe de digirin. Pisporê Kubernetes bersiv dide.
Pisporê îro Daniel Polenchik e (). Daniel li wir wekî mamoste û pêşdebirkerek nermalavê dixebite .
Ger hûn dixwazin ku pirsa we di posta paşîn de were bersivandin, an .
Mesajên berê wenda kir? .
Meriv çawa komên Kubernetes li navendên daneyên cihêreng ve girêdide?
Bi kurt: , û ez jî xwendina li ser pêşniyar dikim и .
Pir caran, binesaziya li herêmên cihêreng, nemaze li hawîrdorên kontrolkirî, tê dubare kirin û belav kirin.
Ger herêmek ne berdest be, seyrûsefer ber bi ya din ve tê veguheztin da ku ji navberan dûr nekevin.
Bi Kubernetes re, hûn dikarin stratejiyek wekhev bikar bînin û barkêşan li herêmên cihêreng belav bikin.
Hûn dikarin ji her tîm, herêm, jîngeh, an jî berhevokek van hêmanan yek an çend koman hebin.
Komên we dikarin di ewr û cîhên cûda de werin mêvan kirin.
Lê hûn çawa binesaziya ji bo belavbûna erdnîgarî ya weha plan dikin?
Ma hûn hewce ne ku ji bo çend hawîrdorên ewr li ser yek torê yek komek mezin biafirînin?
An jî gelek komên piçûk hene û rêyek ji bo kontrolkirin û hevdengkirina wan dibînin?
Yek koma serokatiyê
Afirandina yek komê li ser yek torê ne ew çend hêsan e.
Bifikirin ku we qezayek heye, girêdana di navbera beşên komê de winda dibe.
Ger serverek weya sereke hebe, nîvê çavkaniyan dê nikaribin emrên nû bistînin ji ber ku ew ê nikaribin bi masterê re têkilî daynin.
Û di heman demê de we tabloyên rêgezê yên kevn hene (kube-proxy nikare yên nû dakêşîne) û tu podên din tune (kubelet nikare nûvekirinan bixwaze).
Ji bo ku mesele xirabtir bibe, heke Kubernetes girêkek nabîne, ew wê wekî sêwî nîşan dide û pêlên winda li girêkên heyî belav dike.
Wekî encamek, hûn du caran pirtir pit hene.
Ger hûn ji bo her herêmê yek serverek master çêbikin, dê di databasa etcd de bi algorîtmaya lihevhatinê re pirsgirêk hebin. (approx. ed. - Bi rastî, databasa etcd ne hewce ye ku li ser serverên sereke were cîh kirin. Ew dikare li ser komek serverên cihêreng ên li heman herêmê were xebitandin. Rast e, di heman demê de xalek têkçûna komê digire. Lê bi lez.)
etcd bikar tîne berî nivîsandina wê li ser dîskê nirxê danûstandinê bikin.
Ango, berî ku dewlet ji bo hwd were nivîsandin, divê pirraniya bûyeran bigihîjin hev.
Ger derengiya di navbera mînakên etcd de bi rengek berbiçav zêde bibe, wekî ku di nav deverên cihêreng de sê mînakên etcd-ê ye, demek dirêj hewce dike ku meriv nirxek danûstandinê bike û wê li ser dîskê binivîse.
Ev di kontrolkerên Kubernetes de tê xuyang kirin.
Rêvebirê kontrolker bêtir dem hewce dike ku li ser guhartinê fêr bibe û bersivê li databasê binivîse.
Û ji ber ku ne yek kontrolker, lê çend kes hene, reaksiyonek zincîreyê encam dide û tevahiya komê pir hêdî dest bi xebatê dike.
etcd ew qas dereng hesas e ku .
Niha mînakên baş ên torgilokek mezin ji bo yek komê tune.
Di bingeh de, civata pêşdebir û koma SIG-kluster hewl didin ku fêhm bikin ka meriv çawa koman bi heman awayê ku Kubernetes konteyneran saz dike.
Vebijêrk 1: federasyona komê bi kubefed
Bersiva fermî ji SIG-cluster - .
Ji bo cara yekem, me hewl da ku bi karanîna amûra federasyona kube ve berhevokek koman wekî yek tişt bi rê ve bibe.
Destpêk baş bû, lê di dawiyê de federasyona kube qet populer nebû ji ber ku piştgirî neda hemî çavkaniyan.
Ew teslîmî û karûbarên federasyonê piştgirî kir, lê ne ji bo nimûne StatefulSets.
Di heman demê de, veavakirina federasyonê di forma şîroveyan de hate şandin û ne nerm bû.
Bifikirin ka hûn çawa dikarin dabeşkirina replica ji bo her komê di federasyonê de tenê bi karanîna şîroveyan vebêjin.
Ew tevliheviyek tam bû.
SIG-cluster piştî kubefed v1 gelek kar kir û biryar da ku ji aliyek cûda ve nêzikî pirsgirêkê bibe.
Li şûna şîroveyan, wan biryar da ku kontrolkerek ku li ser koman hatî saz kirin azad bikin. Ew dikare bi karanîna Pênaseyên Çavkaniya Xweser (CRD) were xweş kirin.
Ji bo her çavkaniyek ku dê bibe beşek ji federasyonê, we bi sê beşan pênaseyek CRD-ya xwerû heye:
- pênaseya standard a çavkaniyekê, ji bo nimûne bicihkirin;
- liq
placement, ku hûn diyar dikin ka çavkanî dê di federasyonê de çawa were belavkirin; - liq
override, li ku derê ji bo çavkaniyek taybetî hûn dikarin giranî û pîvanên ji danînê bişopînin.
Li vir mînakek radestkirina hevgirtî ya bi beşên bicîhkirin û paşguhkirinê re ye.
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: 5Wekî ku hûn dikarin bibînin, peyda li ser du koman têne belav kirin: cluster1 и cluster2.
Koma yekem sê kopiyan peyda dike, û ya duyemîn li 5 tê danîn.
Ger ji we re bêtir kontrol li ser hejmara kopyayan hewce be, kubefed2 hêmanek nû ya ReplicaSchedulingPreference peyda dike ku li wir kopya dikarin giran bibin:
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: 2Struktura CRD û API hîn ne amade ne, û xebata çalak di depoya projeya fermî de didome.
Çavê xwe bidin kubefed2, lê ji bîr mekin ku ew hîn ji bo hilberînê ne maqûl e.
Di derbarê kubefed2 de bêtir fêr bibin di blogê de li ser Kubernetes û li .
Vebijêrk 2: berhevkirina koman bi şêwaza Booking.com
Pêşdebirên Booking.com li ser kubefed v2 nexebitin, lê wan bi Shipper - operatorek ji bo radestkirina li ser gelek koman, li çend deveran û di çend ewran de xebitîn.
hinekî dişibe kubefed2.
Her du amûr dihêlin ku hûn stratejiya xweya birêkûpêkkirina pir-klusterê xweş bikin (kîjan kom têne bikar anîn û çend kopiyên wan hene).
di heman demê de Armanca Shipper kêmkirina xetera xeletiyan di dema radestkirinê de ye.
Di Shipper de, hûn dikarin rêzek gavan diyar bikin ku dabeşkirina kopiyan di navbera danîna berê û ya heyî û qebareya seyrûsefera hatinê de diyar dike.
Gava ku hûn çavkaniyekê ber bi komê ve dikişînin, kontrolkerê Shipper bi zêdeyî wê guherînê li hemî komên hevgirtî derdixe.
Di heman demê de, Shipper pir kêm e.
Ji bo nimûne, ew nexşeyên helmê wekî têketinê qebûl dike û çavkaniyên vanilla piştgirî nake.
Bi gelemperî, Shipper bi vî rengî dixebite.
Li şûna radestkirina standard, hûn hewce ne ku çavkaniyek serîlêdanê biafirînin ku nexşeyek Helm vedihewîne:
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 ji bo birêvebirina gelek koman vebijarkek baş e, lê têkiliya wê ya nêzîk bi Helm re tenê rê li ber digire.
Heke em hemî ji Helmê biguherînin an ?
Li ser Shipper û felsefeya wê bêtir fêr bibin .
Ger hûn dixwazin kodê bişopînin, .
Vebijêrk 3: Yekbûna koma "efsûnî".
Kubefed v2 û Shipper bi federasyona komê re dixebitin, bi pênasekirina çavkaniya xwerû çavkaniyên nû ji koman re peyda dikin.
Lê heke hûn nexwazin ku hemî radestkirin, StatefulSets, DaemonSets, hwd ji nû ve binivîsin da ku yek bibin?
Meriv çawa komek heyî di nav federasyonê de bêyî guheztina YAML-ê vedihewîne?
, ku bi plansazkirina barkêşên xebatê yên li ser koman re mijûl dibe.
Lê li şûna ku meriv rêyek nû peyda bike da ku bi komê re têkilî daynin û çavkaniyan di pênaseyên xwerû de bipêçin, pir-cluster-scheduler di çerxa jiyanê ya standard a Kubernetes de tête bicîh kirin û hemî bangên ku potan diafirînin digire.
Her podek çêkirî tavilê bi dummyek tê guhertin.
pir-cluster-scheduler bikar tîne da ku bangê biqedînin û podek dummy bêkar biafirînin.
Podê orîjînal di nav çerxek plansaziyek din re derbas dibe ku, piştî dengdana tevaya federasyonê, biryarek bi cihkirinê tê girtin.
Di dawiyê de, pod ji koma armancê re tê radest kirin.
Wekî encamek, we pêvekek zêde heye ku tiştek nake, tenê cîh digire.
Awantaj ev e ku hûn ne hewce ne ku hûn çavkaniyên nû binivîsin da ku pêlavan berhev bikin.
Her çavkaniyek ku podek çêdike bixweber amade ye ku were yek kirin.
Ev balkêş e, ji ber ku ji nişka ve we pêdivî hene ku li çend deveran hatine belav kirin, û we jî hay jê nekiriye. Lêbelê, ev pir xeternak e, ji ber ku her tişt li vir li ser sêrbaziyê dimîne.
Lê dema ku Shipper hewl dide ku bi piranî bandora radestkirinê sivik bike, pir-cluster-planger peywirên gelemperî digire û belkî ji bo karên komê çêtir e.
Ew mekanîzmayek radestkirina gav bi gav pêşkeftî nîne.
Zêdetir li ser pir-cluster-scheduler dikare li vir were dîtin .
Ger hûn dixwazin di çalakiyê de li ser pir-cluster-scheduler bixwînin, Admiralty heye - karûbar, bûyer, CI û CD Kubernetes.
Amûr û çareseriyên din
Girêdan û birêvebirina gelek koman karekî tevlihev e, û çareseriyek gerdûnî tune.
Heke hûn dixwazin vê mijarê bêtir lêkolîn bikin, li vir çend çavkaniyan hene:
- Amûrek e ku torên sergirtî yên komên cûda yên Kubernetes girêdide.
- Zincîra firotanê Target bikar tîne .
- Biceribînin IPV6 bikar bînin û .
- Ji bo nimûne, hûn dikarin tevnek karûbarê bikar bînin .
- Cilium, pêvekek pêveka torê ya konteynerê, pêşkêşî dike , ku destûrê dide te ku hûn çend koman bihev bikin
Ji bo îro her tişt e
Spas dikim ji bo xwendina heta dawiyê!
Ger hûn dizanin ka meriv çawa gelek koman bi bandortir ve girêdide, .
Em ê rêbaza we li girêdanan zêde bikin.
Spasiyên taybetî ji Chris Nesbitt-Smith () û Vincent de Sme () (endazyarê pêbaweriyê li ) ji bo xwendina gotarê û parvekirina agahdariya kêrhatî li ser ka federasyon çawa dixebite.
Source: www.habr.com