🥇 Berfirehkirin û temamkirina Kubernetes (rapora vekolîn û vîdyoyê)

8ê Nîsanê li konferansê Saint HighLoad ++ 2019, wekî beşek ji beşa "DevOps û Operasyonên", raporek "Berfirehkirin û temamkirina Kubernetes" hate dayîn, ku di afirandina wê de sê xebatkarên pargîdaniya Flant beşdar bûn. Di wê de, em li ser gelek rewşên ku me dixwest ku kapasîteyên Kubernetes berfireh bikin û temam bikin, lê ji bo ku me çareseriyek amade û hêsan nedît. Di çarçoveya projeyên Çavkaniya Vekirî de çareseriyên pêwîst ên me hene û ev axaftin jî ji bo wan hatiye veqetandin.

Li gorî kevneşopiyê, em kêfxweş in ku pêşkêş dikin vîdyoya raporê (50 hûrdem, ji gotarê pir agahdartir) û kurteya bingehîn di forma nivîsê de. Ajotin!

Di K8s de bingehîn û zêdekirin

Kubernetes pîşesazî û nêzîkatiyên rêveberiya ku ji zû ve hatine damezrandin diguhezîne:

Spas ji bo wî abstractions, em êdî bi têgînên wekî sazkirina mîhengek an xebitandina fermanek (Chef, Ansible...) naxebitin, lê komkirina konteyneran, karûbaran, hwd.
Em dikarin serîlêdanan amade bikin bêyî ku li ser nuwazeyên wan bifikirin malpera taybetî, ku dê li ser wê were destpêkirin: metalê tazî, ewrê yek ji pêşkêşvanan, hwd.
Bi K8-an re hûn çu carî ne gihîştî bûn pratîkên herî baş li ser binesaziya birêxistinkirinê: teknîkên pîvandinê, xwe-samankirin, tolerasyona xeletiyê, hwd.

Lêbelê, bê guman, her tişt ne ew qas hêsan e: Kubernetes jî pirsgirêkên xwe yên nû anîn.

Kubernetes ne Kombînek e ku hemî pirsgirêkên hemî bikarhêneran çareser dike. Core Kubernetes tenê ji komek fonksiyonên herî kêm ên hewce yên ku tê de hene berpirsiyar e her kesî kom:

The core Kubernetes ji bo komkirina konteyneran, birêvebirina seyrûseferê, û hwd komek bingehîn a primitive diyar dike. Me li ser wan bi hûrgulî li wir axivî rapor 2 sal berê.

Ji hêla din ve, K8s ji bo berfirehkirina fonksiyonên berdest, ku ji girtina kesên din re dibe alîkar, derfetên mezin pêşkêşî dike - taybetî - hewcedariyên bikarhêner. Zêdekirinên Kubernetes berpirsiyariya rêveberên komê ne, ku divê her tiştê ku hewce dike saz bikin û mîheng bikin da ku koma xwe "di şeklê rast" de bigirin [ji bo çareserkirina pirsgirêkên xwe yên taybetî]. Ev çi cûre zêdekirin in? Ka em li çend mînakan binêrin.

Nimûneyên pêvekan

Ku Kubernetes saz kir, dibe ku em şaş bimînin ku tora ku ji bo danûstendina podan hem di hundurê girêkek û hem jî di navbera girêkan de ew qas hewce ye bi serê xwe naxebite. Kernelê Kubernetes girêdanên pêwîst garantî nake; li şûna wê, ew torê destnîşan dike navbeynkar (CNI) ji bo pêvekên partiya sêyemîn. Divê em yek ji van pêvekan saz bikin, ku dê ji veavakirina torê berpirsiyar be.

Mînakek nêzîk çareseriyên hilanîna daneyan e (dîska herêmî, cîhaza bloka torê, Ceph ...). Di destpêkê de ew di bingehîn de bûn, lê bi hatinê CSI rewş diguhezîne tiştek mîna ya ku berê hatî diyar kirin: navber di Kubernetes de ye, û pêkanîna wê di modulên partiya sêyemîn de ye.

Mînakên din jî hene:

Ingress-kontrolker (nirxandina wan li hundurê binêre gotara me ya dawî).
rêvebirê cert:
Operator tevahî çînek pêvekan e (ya ku sertîfîka-rêvebirê navborî tê de ye), ew primitive (s) û kontrolker (yan) diyar dikin. Mantiqa xebata wan tenê ji hêla xeyala me ve sînorkirî ye û dihêle ku em hêmanên binesaziyê yên amade (mînakî, DBMS) veguherînin primitives, ku bi wan re pir hêsantir dixebitin (ji komek konteyneran û mîhengên wan). Hejmarek mezin ji operatoran hatine nivîsandin - her çend gelek ji wan hîn ji bo hilberînê ne amade ne, ew tenê meseleyek dem e:
Metrics - Nimûneyek din a ka Kubernetes çawa pêvekê (Metrics API) ji pêkanînê veqetand (pêvekên sêyemîn ên wekî adapterê Prometheus, nûnerê komê Datadog ...).
bo çavdêrîkirin û statîstîk, ku di pratîkê de ne tenê hewce ne Prometheus û Grafana, lê di heman demê de kube-dewlet-metrics, node-exporter, hwd.

Û ev ne navnîşek tam a lêzêdekirinan e... Mînakî, li pargîdaniya Flantê ku em niha saz dikin 29 pêvek (hemû bi tevahî 249 tiştên Kubernetes diafirînin). Bi hêsanî, em nikanin jiyana komekê bêyî lêzêdekirinan bibînin.

Otomasyonê

Operator ji bo otomatîkkirina karûbarên rûtîn ên ku em her roj pê re rû bi rû dimînin hatine çêkirin. Li vir mînakên jiyana rast hene ku nivîsandina operatorek dê çareseriyek hêja be:

Ji bo serîlêdanê qeydek taybet (ango têketinek pêdivî ye) bi wêneyan heye. Tê texmîn kirin ku ji her podê re veşartîyek taybetî heye ku destûrê dide pejirandinê di qeydê de. Karê me ew e ku em pê ewle bin ku ev veşartî di nav cîhê navan de were dîtin da ku pod dikarin wêneyan dakêşin. Dibe ku gelek serîlêdan hebin (her yek ji wan hewceyê razek e), û kêrhatî ye ku meriv bi rêkûpêk razan bixwe nûve bike, ji ber vê yekê vebijarka danîna sirên bi destan ji holê radibe. Li vir operator tê rizgarkirinê: em kontrolkerek çêdikin ku dê li benda xuyangkirina cîhê navan bimîne û, li ser bingeha vê bûyerê, dê razek li cîhê navan zêde bike.
Bila ji hêla xwerû ve gihandina ji pods bo Înternetê qedexe ye. Lê carinan dibe ku hewce bike: mentiqî ye ku mekanîzmaya destûra gihîştinê bi hêsanî bixebite, bêyî ku jêhatîbûnên taybetî hewce bike, mînakî, bi hebûna nîşanek diyarkirî di cîhê navan de. Çawa operator dikare li vir alîkariya me bike? Kontrolkerek tête çêkirin ku li benda xuyangkirina etîketê di cîhê navan de ye û polîtîkaya guncan ji bo gihîştina Înternetê zêde dike.
Rewşek wusa: Bifikirin ku em hewce ne ku hindek zêde bikin qirêj kirin, heke ew etîketek wusa hebe (bi celebek pêşgirek). Çalakiyên bi operatorê re eşkere ne ...

Di her komê de, divê karên rûtîn bêne çareser kirin, û rast ev dikare bi karanîna operatoran were kirin.

Bi kurtkirina hemû çîrokên ku hatine vegotin, em gihîştin wê encamê ji bo karê rehet li Kubernetes hûn hewce ne: A) pêvekan saz bikin, b) operatoran pêşve bibin (ji bo çareserkirina peywirên rêveberê rojane).

Meriv çawa ji bo Kubernetes daxuyaniyek binivîse?

Bi gelemperî, planek hêsan e:

... lê paşê derket holê ku:

Kubernetes API tiştek ne-tiştek e ku ji bo masterê gelek wext digire;
bername jî ne ji bo her kesî ye (zimanê Go wekî zimanê bijarte hate hilbijartin ji ber ku çarçoveyek taybetî jê re heye - Operator SDK);
Di çarçoveya xwe de jî rewş wisa ye.

Bi kurtahî: kontrolkerek binivîse (operator) divê çavkaniyên girîng xerc bikin ji bo xwendina materyalê. Ev ê ji bo operatorên "mezin" rastdar be - bêje, ji bo MySQL DBMS. Lê heke em mînakên ku li jor hatine destnîşan kirin bi bîr bînin (veşartina razan, gihandina podên Înternetê...), ku em jî dixwazin rast bikin, wê hingê em ê fam bikin ku hewildana ku hatî xerckirin dê ji encama ku em nuha hewce ne girantir bike:

Bi gelemperî, dubendiyek derdikeve: gelek çavkaniyan xerc bikin û amûrek rast ji bo nivîsandina daxuyaniyan bibînin, an jî bi awayê kevneperest (lê zû) bikin. Ji bo çareserkirina wê - ji bo peydakirina lihevhatinek di navbera van tundûtûjiyan de - me projeya xwe çêkir: shell-operator (li wî jî binêre daxuyaniya dawî li ser hub).

Shell-operator

Ew çawa dixebite? Di komê de podek heye ku tê de binaryek Go bi operatorek şêl heye. Li kêleka wî komek ji hooks (Zêdetir hûrgulî li ser wan - li jêr binêrin). Operatorê şêl bi xwe ji hin kesan re dibe abone bûyeran di API-ya Kubernetes de, li ser rûdana ku ew çengên têkildar dest pê dike.

Meriv çawa şell-operator dizane ku li kîjan bûyeran bangî kîjan çengelê bike? Ev agahdarî ji hêla çengelên xwe ve ji operatorê şêl re tê veguheztin, û ew wiya pir hêsan dikin.

Hook skrîptek Bash an pelek din a îcrakar e ku argumanek yekane qebûl dike --config û bi JSON re bersiv dide. Ya paşîn diyar dike ka kîjan tiştên ku jê re eleqedar in û kîjan bûyeran (ji bo van tiştan) divê werin bersivandin:

Ez ê pêkanîna li ser şêl-operatorê yek ji nimûneyên me ronî bikim - veqetandina sirên ji bo gihîştina qeydek taybet bi wêneyên serîlêdanê. Ji du qonaxan pêk tê.

Bicihkirin: 1. Çêlekê binivîsin

Beriya her tiştî, di qulikê de em ê pêvajoyê bikin --config, destnîşan dike ku em bi cîhên navan re eleqedar dibin, û bi taybetî, dema afirandina wan:

[[ $1 == "--config" ]] ; then
  cat << EOF
{
  "onKubernetesEvent": [
    {
      "kind": "namespace",
      "event": ["add"]
    }
  ]
}
EOF
…

Mantiq dê çawa xuya bike? Her weha pir hêsan:

…
else
  createdNamespace=$(jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH)
  kubectl create -n ${createdNamespace} -f - << EOF
Kind: Secret
...
EOF
fi

Gava yekem ev e ku meriv fêr bibe ka kîjan navan hatiye afirandin, û ya duyemîn jî ew e ku meriv wê bi kar bîne kubectl veşartî ji bo vê navan.

Pratîk: 2. Komkirina wêneyê

Tiştê ku dimîne ev e ku meriv çenga hatî afirandin ji operatorê şêl re derbas bike - meriv çawa wiya dike? Shell-operator bixwe wekî wêneyek Docker tê, ji ber vê yekê peywira me ev e ku em di vê wêneyê de hookê li pelrêçek taybetî zêde bikin:

FROM flant/shell-operator:v1.0.0-beta.1
ADD my-handler.sh /hooks

Tiştê ku dimîne ev e ku meriv wê kom bike û bikişîne:

$ docker build -t registry.example.com/my-operator:v1 .
$ docker push registry.example.com/my-operator:v1

Têkiliya dawîn belavkirina wêneyê li komê ye. Ji bo vê yekê, em binivîsin Dêrîn:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-operator
spec:
  template:
    spec:
      containers:
      - name: my-operator
        image: registry.example.com/my-operator:v1 # 1
      serviceAccountName: my-operator              # 2

Du xal hene ku divê bala xwe bidinê:

nîşana wêneya nû hatî afirandin;
Ev hêmanek pergalê ye ku (bi kêmanî) hewceyê mafan e ku bibe abone li bûyerên Kubernetes û veqetandina nehêniyan li cîhên navan, ji ber vê yekê em Hesabek Service (û komek qaîdeyên) ji bo hookê diafirînin.

Encam - me pirsgirêka xwe çareser kir xizmên ji bo Kubernetes bi rengekî ku operatorek ji bo veqetandina razan diafirîne.

Taybetmendiyên din ên shell-operator

Ji bo bisînorkirina tiştên cureya weya bijartî ya ku çeng dê pê re bixebite, ew dikarin bên fîltrekirin, li gorî hin etîketan hilbijêrin (an bikar bînin matchExpressions):

"onKubernetesEvent": [
  {
    "selector": {
      "matchLabels": {
        "foo": "bar",
       },
       "matchExpressions": [
         {
           "key": "allow",
           "operation": "In",
           "values": ["wan", "warehouse"],
         },
       ],
     }
     …
  }
]

Pêşkêş kirin mekanîzmaya veqetandinê, ku - bi karanîna parzûnek jq - destûrê dide te ku hûn tiştên JSON-ê yên mezin veguhezînin yên piçûk, li wir tenê ew parametreyên ku em dixwazin ji bo guheztinan bişopînin dimînin.

Dema ku hookek tê gotin, şell-operator wê derbas dike daneyên objeyê, ku dikare ji bo her hewceyê bikar bînin.

Bûyerên ku çengelan çêdikin bi bûyerên Kubernetes re ne sînordar in: operator-shell piştgirî dide gazî çengelan bi demê re (wek crontab di plansaziyek kevneşopî de), û her weha bûyerek taybetî onStartup. Hemî van bûyeran dikarin werin berhev kirin û li heman hookê werin veqetandin.

Û du taybetmendiyên din ên shell-operator:

Ew dixebite asynchronously. Ji ber ku bûyerek Kubernetes (wek tiştek ku tê afirandin) hate wergirtin, bûyerên din (wek heman tiştê ku tê jêbirin) dikaribû di komê de çêbibe, û pêdivî ye ku hook vê yekê hesab bikin. Ger hook bi xeletiyek hate darve kirin, wê hingê ew ê bixweber be bişûndebangkirin heya qedandina serketî (ev tevger dikare were guheztin).
Hinarde dike metrics ji bo Prometheus, ku hûn pê re dikarin fêm bikin ka operator-şêl kar dike, ji bo her çîçekê hejmara xeletiyan û mezinahiya dorê ya heyî fêr bibin.

Ji bo kurtkirina vê beşa raporê:

Sazkirina pêvekan

Ji bo xebata rehet a bi Kubernetes re, hewcedariya sazkirina pêvekan jî hate gotin. Ez ê ji we re bi mînaka rêça pargîdaniya me ji we re vebêjim ka em çawa niha dikin.

Me bi Kubernetes re bi gelek koman re dest bi xebatê kir, yekane pêveka ku Ingress bû. Pêdivî bû ku ew di her komê de bi rengek cûda were saz kirin, û me ji bo hawîrdorên cihêreng gelek veavakirina YAML çêkir: metalê tazî, AWS ...

Ji ber ku kom zêdetir bûn, veavakirin jî zêdetir bûn. Wekî din, me van veavakirinan bixwe çêtir kir, di encamê de ew pir heterojen bûn:

Ji bo ku em her tiştî bi rêkûpêk bikin, me bi senaryoyek dest pê kir (install-ingress.sh), ya ku celebê koma ku em ê tê de bicîh bikin wekî arguman girt, veavakirina YAML ya pêwîst çêkir û ew derxist Kubernetes.

Bi kurtasî, rêça me ya pêştir û hincetên pê ve girêdayî ev bûn:

ji bo ku bi veavakirinên YAML re bixebitin, motorek şablonê hewce ye (di qonaxên yekem de ev sed sade ye);
bi zêdebûna hejmara koman re, hewcedariya nûvekirina otomatîkî hat (çareseriya pêşîn ew bû ku skrîptê li Git-ê bixin, bi karanîna cron-ê nûve bikin û wê bimeşînin);
ji bo Prometheus jî nivîseke wisa pêwîst bû (install-prometheus.sh), di heman demê de, ji ber vê yekê girîng e ku ew hewceyê bêtir daneyên têketinê, û hem jî hilanîna wan (bi awayek baş - navendî û di komekê de), û hin dane (şîfre) dikarin bixweber bêne çêkirin:
metirsiya derxistina tiştek xelet ji hejmareke mezin a koman re her ku diçe mezin dibû, ji ber vê yekê me fêm kir ku sazker (ango du nivîsar: ji bo Ingress û Prometheus) stasyon hewce bû (çend şaxên Git, çend kronan ji bo nûvekirina wan di rêzê de: komikên stabîl an ceribandinê);
с kubectl apply Ji ber ku ne diyarker e û tenê dikare tiştan biafirîne, lê li ser statûya wan biryarê nede/ jêbirin, karkirina pê re dijwar bûye;
Me hin fonksiyonên ku me di wê demê de qet pêk neanîbûn winda kiribûn:
- kontrola tam li ser encama nûvekirinên komê,
- destnîşankirina otomatîkî ya hin pîvanan (vedana ji bo skrîptên sazkirinê) li ser bingeha daneyên ku ji komê têne wergirtin (vedîtin),
- pêşveçûna wê ya mantiqî di forma vedîtina domdar de.

Me ev hemî ezmûna berhevkirî di çarçoveya projeya xwe ya din de bicîh kir - addon-operator.

Addon-operator

Ew li ser şell-operatorê ku berê hatî behs kirin bingeha xwe digire. Tevahiya pergalê wiha xuya dike:

Ya jêrîn li çîpên şelê-operatorê tê zêdekirin:

hilanîna nirxan,
Helm chart,
pêkhateya ku firoşgeha nirxan dişopîne û - di rewşek guhertinan de - ji Helm dipirse ku nexşeyê ji nû ve bizivirîne.

Bi vî rengî, em dikarin li hember bûyerek li Kubernetes reaksiyon bikin, çengek dest pê bikin, û ji vê çengê guheztinan li hilanînê bikin, piştî ku nexşe dê ji nû ve were dakêşandin. Di diagrama encam de, em komek çengelan û nexşeyê li yek pêkhateyek, ku em jê re dibêjin veqetînin module:

Dibe ku gelek modul hebin, û em li wan çîpên gerdûnî, firotgehek nirxên gerdûnî, û pêkhateyek ku çavdêriya vê firotgeha gerdûnî dike lê zêde dikin.

Naha, gava ku tiştek li Kubernetes diqewime, em dikarin bi karanîna çîçek gerdûnî re bertek nîşan bidin û di firotgeha gerdûnî de tiştek biguhezînin. Ev guhertin dê were dîtin û dê bibe sedem ku hemî modulên di komê de werin derxistin:

Ev nexşe hemî hewcedariyên ji bo sazkirina pêvekên ku li jor hatine destnîşan kirin têr dike:

Helm ji şablon û daxuyaniyê berpirsiyar e.
Pirsgirêka nûvekirina otomatîkî bi karanîna pêvekek gerdûnî hate çareser kirin, ku li gorî bernameyek diçe qeydê û, ger ew wêneyek pergalê nû li wir bibîne, wê derxe (ango "xwe").
Mîhengên hilanînê yên di komê de bi karanîna têne bicîh kirin ConfigMap, ku daneyên bingehîn ji bo depoyan vedihewîne (di destpêkê de ew di depoyan de têne barkirin).
Pirsgirêkên bi hilberîna şîfreyê, vedîtin û vedîtina domdar bi karanîna çengan hatin çareser kirin.
Staging bi saya etîketan, ku Docker ji qutiyê piştgirî dike, tê bidestxistin.
Encam bi karanîna metrîkên ku em dikarin statûyê fam bikin tê şopandin.

Tevahiya vê pergalê di Go-yê de di forma yek binary de tête bicîh kirin, ku jê re addon-operator tê gotin. Ev diagram hêsantir xuya dike:

Di vê diagramê de pêkhateya sereke komek modulan e (li jêr bi rengê gewr hatiye ronîkirin). Naha em dikarin bi hewldanek piçûk modulek ji bo pêveka hewce binivîsin û pê bawer bin ku ew ê di her komê de were saz kirin, dê were nûve kirin û bersivê bide bûyerên ku di komê de hewce dike.

"Flant" bikar tîne addon-operator li ser 70+ komên Kubernetes. Rewşa heyî - guhertoya alpha. Naha em ji bo berdana betayê belgeyan amade dikin, lê heya niha di depoyê de ye mînakên berdest, li ser bingeha ku hûn dikarin pêveka xwe biafirînin.

Ez dikarim modulên ji bo addon-operatorê li ku bistînim? Weşandina pirtûkxaneya me ji bo me qonaxa din e; em plan dikin ku havînê vê yekê bikin.

Vîdyo û slaytên

Vîdyo ji performansê (~ 50 hûrdem):

Pêşkêşkirina raporê:

PS

Raporên din ên li ser bloga me:

«Databases û Kubernetes»; (Dmitry Stolyarov; 8 Mijdar 2018 li ser HighLoad ++);
«Çavdêrî û Kubernetes»; (Dmitry Stolyarov; 28 Gulan 2018 li RootConf);
«Bi Kubernetes û GitLab re Pratîkên çêtirîn CI/CD»; (Dmitry Stolyarov; 7 Mijdar 2017 li ser HighLoad ++);
«Tecrûbeya me bi Kubernetes re di projeyên piçûk de»; (Dmitry Stolyarov; 6 Hezîran, 2017 li RootConf).

Hûn dikarin bi weşanên jêrîn re jî eleqedar bibin:

«Nasandina shell-operator: afirandina operatoran ji bo Kubernetes hêsantir bû".

Source: www.habr.com

Berfirehkirin û pêvekirina Kubernetes (rapora giştî û vîdyoyê)