🥇 Fara? Bash! Hittu skeljarstjórann (endurskoðun og myndbandsskýrsla frá KubeCon EU'2020)

Í ár var helsta evrópska Kubernetes ráðstefnan - KubeCon + CloudNativeCon Europe 2020 - sýndar. Slík breyting á sniði kom þó ekki í veg fyrir að við skiluðum skýrslunni okkar sem lengi var áætlað „Áfram? Bash! Meet the Shell-operator“ tileinkað Open Source verkefninu okkar skel-rekstraraðili.

Þessi grein, innblásin af fyrirlestrinum, sýnir nálgun til að einfalda ferlið við að búa til rekstraraðila fyrir Kubernetes og sýnir hvernig þú getur búið til þína eigin með lágmarks fyrirhöfn með því að nota skeljarvirkja.

Kynning myndband af skýrslunni (~23 mínútur á ensku, áberandi upplýsandi en greinin) og aðalútdráttur úr henni í textaformi. Farðu!

Hjá Flant fínstillum og gerum við stöðugt allt sjálfvirkt. Í dag munum við tala um annað spennandi hugtak. Hittu: skýja-native skel scripting!

Hins vegar skulum við byrja á samhenginu sem allt þetta gerist í: Kubernetes.

Kubernetes API og stýringar

Forritaskilin í Kubernetes geta verið táknuð sem eins konar skráarþjónn með möppum fyrir hverja tegund af hlut. Hlutir (auðlindir) á þessum netþjóni eru táknaðir með YAML skrám. Að auki hefur þjónninn grunn API sem gerir þér kleift að gera þrennt:

að fá auðlind eftir tegund sinni og nafni;
breyta auðlind (í þessu tilviki geymir þjónninn aðeins „rétta“ hluti - öllum ranglega mynduðum eða ætluðum öðrum möppum er hent);
lag fyrir auðlindina (í þessu tilfelli fær notandinn strax núverandi/uppfærða útgáfu).

Þannig virkar Kubernetes sem eins konar skráarþjónn (fyrir YAML birtingarmyndir) með þremur grunnaðferðum (já, reyndar eru til aðrar, en við munum sleppa þeim í bili).

Vandamálið er að þjónninn getur aðeins geymt upplýsingar. Til að láta það virka þarftu stjórnandi - næst mikilvægasta og grundvallarhugtakið í heimi Kubernetes.

Það eru tvær megingerðir af stýringar. Sá fyrsti tekur upplýsingar frá Kubernetes, vinnur úr þeim samkvæmt hreiðri rökfræði og skilar þeim til K8s. Sú seinni tekur upplýsingar frá Kubernetes, en ólíkt þeirri fyrri breytir hún ástandi sumra ytri auðlinda.

Við skulum skoða nánar ferlið við að búa til dreifingu í Kubernetes:

Dreifingarstýringur (innifalinn í kube-controller-manager) fær upplýsingar um Deployment og býr til ReplicaSet.
ReplicaSet býr til tvær eftirmyndir (tveir belg) byggt á þessum upplýsingum, en þessi belg eru ekki tímasett ennþá.
Tímaáætlunin skipuleggur fræbelg og bætir hnútupplýsingum við YAML þeirra.
Kubelets gera breytingar á ytri auðlind (segjum Docker).

Síðan er öll röðin endurtekin í öfugri röð: kúbelet athugar gámana, reiknar út stöðu belgsins og sendir það til baka. ReplicaSet stjórnandi fær stöðuna og uppfærir stöðu eftirmyndarsettsins. Það sama gerist með Deployment Controller og notandinn fær loksins uppfærða (núverandi) stöðu.

Skeljarstjóri

Það kemur í ljós að Kubernetes byggir á sameiginlegu starfi ýmissa stjórnenda (Kubernetes rekstraraðilar eru líka stjórnendur). Spurningin vaknar, hvernig á að búa til eigin símafyrirtæki með lágmarks fyrirhöfn? Og hér kemur sá sem við þróuðum til bjargar skel-rekstraraðili. Það gerir kerfisstjórum kleift að búa til sínar eigin yfirlýsingar með kunnuglegum aðferðum.

Einfalt dæmi: afrita leyndarmál

Við skulum líta á einfalt dæmi.

Segjum að við höfum Kubernetes þyrping. Það hefur nafnrými default með einhverju Leyndarmáli mysecret. Að auki eru önnur nafnarými í þyrpingunni. Sum þeirra eru með sérstökum merkimiða á þeim. Markmið okkar er að afrita Secret inn í nafnrými með merkimiða.

Verkefnið er flókið vegna þess að ný nafnarými geta birst í þyrpingunni og sum þeirra kunna að hafa þetta merki. Á hinn bóginn, þegar merkinu er eytt, ætti einnig að eyða Secret. Auk þessa getur leyndarmálið sjálft einnig breyst: í þessu tilviki verður að afrita nýja leyndarmálið í öll nafnrými með merkimiðum. Ef Secret er óvart eytt í einhverju nafnarými ætti símafyrirtækið okkar að endurheimta það strax.

Nú þegar verkefnið hefur verið mótað, er kominn tími til að byrja að innleiða það með því að nota skeljarstjórann. En fyrst er það þess virði að segja nokkur orð um skeljarstjórann sjálfan.

Hvernig shell-operator virkar

Eins og annað vinnuálag í Kubernetes, keyrir shell-operator í sínum eigin belg. Í þessum pod í möppunni /hooks keyranlegar skrár eru geymdar. Þetta geta verið forskriftir í Bash, Python, Ruby o.s.frv. Við köllum slíkar keyrsluskrár krókar (krókar).

Shell-operator gerist áskrifandi að Kubernetes viðburðum og rekur þessa króka til að bregðast við þeim atburðum sem við þurfum.

Hvernig veit skeljarstjórinn hvaða krók hann á að keyra og hvenær? Aðalatriðið er að hver krókur hefur tvö stig. Við ræsingu rekur skeljarstjórinn alla króka með rifrildi --config Þetta er stillingarstigið. Og eftir það eru krókar hleypt af stokkunum á venjulegan hátt - til að bregðast við atburðunum sem þeir eru festir við. Í síðara tilvikinu fær krókurinn bindandi samhengi (bindandi samhengi) - gögn á JSON sniði, sem við munum tala nánar um hér að neðan.

Gerir rekstraraðila í Bash

Nú erum við tilbúin til framkvæmda. Til að gera þetta þurfum við að skrifa tvær aðgerðir (við the vegur, við mælum með bókasafn skel_lib, sem einfaldar til muna að skrifa króka í Bash):

það fyrsta er nauðsynlegt fyrir stillingarstigið - það sýnir bindandi samhengi;
annað inniheldur helstu rökfræði króksins.

#!/bin/bash

source /shell_lib.sh

function __config__() {
  cat << EOF
    configVersion: v1
    # BINDING CONFIGURATION
EOF
}

function __main__() {
  # THE LOGIC
}

hook::run "$@"

Næsta skref er að ákveða hvaða hluti við þurfum. Í okkar tilviki þurfum við að fylgjast með:

uppspretta leyndarmál fyrir breytingar;
öll nafnarými í þyrpingunni, svo að þú vitir hverjir eru með merkimiða við sig;
markleyndarmál til að tryggja að þau séu öll í takt við upprunaleyndarmálið.

Gerast áskrifandi að leynilegu heimildinni

Bindandi uppsetning fyrir það er frekar einföld. Við gefum til kynna að við höfum áhuga á Secret með nafninu mysecret í nafnrými default:

function __config__() {
  cat << EOF
    configVersion: v1
    kubernetes:
    - name: src_secret
      apiVersion: v1
      kind: Secret
      nameSelector:
        matchNames:
        - mysecret
      namespace:
        nameSelector:
          matchNames: ["default"]
      group: main
EOF

Fyrir vikið verður krókurinn ræstur þegar upprunaleyndarmálið breytist (src_secret) og fá eftirfarandi bindandi samhengi:

Eins og þú sérð inniheldur það nafnið og allan hlutinn.

Að halda utan um nafnarými

Nú þarftu að gerast áskrifandi að nafnasvæðum. Til að gera þetta tilgreinum við eftirfarandi bindandi stillingar:

- name: namespaces
  group: main
  apiVersion: v1
  kind: Namespace
  jqFilter: |
    {
      namespace: .metadata.name,
      hasLabel: (
       .metadata.labels // {} |  
         contains({"secret": "yes"})
      )
    }
  group: main
  keepFullObjectsInMemory: false

Eins og þú sérð hefur nýr reitur birst í uppsetningunni með nafninu jqSía. Eins og nafnið gefur til kynna, jqFilter síar út allar óþarfa upplýsingar og býr til nýjan JSON hlut með þeim sviðum sem eru áhugaverðir fyrir okkur. Krókur með svipaða uppsetningu mun fá eftirfarandi bindandi samhengi:

Það inniheldur fylki filterResults fyrir hvert nafnrými í klasanum. Boolean breyta hasLabel gefur til kynna hvort merki sé fest við tiltekið nafnrými. Valur keepFullObjectsInMemory: false gefur til kynna að ekki sé þörf á að geyma heila hluti í minni.

Rekja markleyndarmál

Við gerumst áskrifendur að öllum leyndarmálum sem eru með athugasemd managed-secret: "yes" (þetta eru markmið okkar dst_secrets):

- name: dst_secrets
  apiVersion: v1
  kind: Secret
  labelSelector:
    matchLabels:
      managed-secret: "yes"
  jqFilter: |
    {
      "namespace":
        .metadata.namespace,
      "resourceVersion":
        .metadata.annotations.resourceVersion
    }
  group: main
  keepFullObjectsInMemory: false

Í þessu tilfelli jqFilter síar út allar upplýsingar nema nafnrýmið og færibreytuna resourceVersion. Síðasta færibreytan var send í athugasemdina þegar leyndarmálið var búið til: það gerir þér kleift að bera saman útgáfur af leyndarmálum og halda þeim uppfærðum.

Krókur sem er stilltur á þennan hátt mun, þegar hann er keyrður, fá þrjú bindandi samhengi sem lýst er hér að ofan. Það má líta á þær sem eins konar skyndimynd (skyndimynd) þyrping.

Byggt á öllum þessum upplýsingum er hægt að þróa grunnalgrím. Það endurtekur sig yfir öll nafnarými og:

ef hasLabel mál true fyrir núverandi nafnrými:
- ber saman alþjóðlega leyndarmálið við það staðbundna:
  - ef þeir eru eins gerir það ekkert;
  - ef þeir eru ólíkir - framkvæmir kubectl replace eða create;
ef hasLabel mál false fyrir núverandi nafnrými:
- tryggir að Secret sé ekki í uppgefnu nafnrými:
  - ef staðbundið leyndarmál er til staðar skaltu eyða því með því að nota kubectl delete;
  - ef staðbundið leyndarmál finnst ekki gerir það ekkert.

Innleiðing reikniritsins í Bash þú getur halað niður í okkar geymslur með dæmum.

Þannig gátum við búið til einfaldan Kubernetes stjórnanda með því að nota 35 línur af YAML stillingum og um það bil sama magn af Bash kóða! Hlutverk skeljarstjóra er að tengja þau saman.

Hins vegar er afritun leyndarmála ekki eina notkunarsvið tólsins. Hér eru nokkur fleiri dæmi til að sýna hvers hann er megnugur.

Dæmi 1: Að gera breytingar á ConfigMap

Við skulum skoða dreifingu sem samanstendur af þremur belgjum. Pods nota ConfigMap til að geyma einhverjar stillingar. Þegar belgirnir voru settir af stað var ConfigMap í ákveðnu ástandi (köllum það v.1). Í samræmi við það nota allir belg þessa tilteknu útgáfu af ConfigMap.

Nú skulum við gera ráð fyrir að ConfigMap hafi breyst (v.2). Hins vegar munu hólf nota fyrri útgáfu ConfigMap (v.1):

Hvernig get ég fengið þá til að skipta yfir í nýja ConfigMap (v.2)? Svarið er einfalt: notaðu sniðmát. Við skulum bæta eftirlitssummuskýingu við hlutann template Uppsetningarstillingar:

Þess vegna verður þessi athugunarsumma skráð í alla belg og hún verður sú sama og dreifing. Nú þarftu bara að uppfæra athugasemdina þegar ConfigMap breytist. Og skeljarstjórinn kemur sér vel í þessu tilfelli. Allt sem þú þarft að gera er að forrita krók sem mun gerast áskrifandi að ConfigMap og uppfæra eftirlitssumman.

Ef notandinn gerir breytingar á ConfigMap mun skeljarstjórinn taka eftir þeim og endurreikna eftirlitssumman. Eftir það mun galdurinn í Kubernetes koma við sögu: hljómsveitarstjórinn mun drepa fræbelginn, búa til nýjan, bíða eftir að hann verði Ready, og heldur áfram í næsta. Fyrir vikið mun Deployment samstilla og skipta yfir í nýju útgáfuna af ConfigMap.

Dæmi 2: Vinna með sérsniðnar tilföngsskilgreiningar

Eins og þú veist gerir Kubernetes þér kleift að búa til sérsniðnar tegundir af hlutum. Til dæmis getur þú búið til tegund MysqlDatabase. Segjum að þessi tegund hafi tvær lýsigagnafæribreytur: name и namespace.

apiVersion: example.com/v1alpha1
kind: MysqlDatabase
metadata:
  name: foo
  namespace: bar

Við erum með Kubernetes þyrping með mismunandi nafnasvæðum þar sem við getum búið til MySQL gagnagrunna. Í þessu tilviki er hægt að nota skeljarstjóra til að rekja auðlindir MysqlDatabase, tengja þá við MySQL netþjóninn og samstilla æskilegt og athugað ástand þyrpingarinnar.

Dæmi 3: Vöktun klasanetsins

Eins og þú veist er ping einfaldasta leiðin til að fylgjast með neti. Í þessu dæmi munum við sýna hvernig á að innleiða slíka vöktun með því að nota skel-operator.

Fyrst af öllu þarftu að gerast áskrifandi að hnútum. Skeljarstjórinn þarf nafn og IP-tölu hvers hnúts. Með hjálp þeirra mun hann smella þessum hnútum.

configVersion: v1
kubernetes:
- name: nodes
  apiVersion: v1
  kind: Node
  jqFilter: |
    {
      name: .metadata.name,
      ip: (
       .status.addresses[] |  
        select(.type == "InternalIP") |
        .address
      )
    }
  group: main
  keepFullObjectsInMemory: false
  executeHookOnEvent: []
schedule:
- name: every_minute
  group: main
  crontab: "* * * * *"

Viðfang executeHookOnEvent: [] kemur í veg fyrir að krókurinn gangi sem svar við hvaða atburði sem er (þ.e. að bregðast við því að breyta, bæta við, eyða hnútum). Hins vegar, hann mun hlaupa (og uppfærðu lista yfir hnúta) Tímaáætlun - hverja mínútu, eins og reiturinn mælir fyrir um schedule.

Nú vaknar spurningin, hvernig nákvæmlega vitum við um vandamál eins og pakkatap? Við skulum kíkja á kóðann:

function __main__() {
  for i in $(seq 0 "$(context::jq -r '(.snapshots.nodes | length) - 1')"); do
    node_name="$(context::jq -r '.snapshots.nodes['"$i"'].filterResult.name')"
    node_ip="$(context::jq -r '.snapshots.nodes['"$i"'].filterResult.ip')"
    packets_lost=0
    if ! ping -c 1 "$node_ip" -t 1 ; then
      packets_lost=1
    fi
    cat >> "$METRICS_PATH" <<END
      {
        "name": "node_packets_lost",
        "add": $packets_lost,
        "labels": {
          "node": "$node_name"
        }
      }
END
  done
}

Við endurtökum í gegnum hnútalistann, fáum nöfn þeirra og IP-tölur, pingum þær og sendum niðurstöðurnar til Prometheus. Shell-rekstraraðili getur flutt út mælikvarða til Prometheus, vistar þær í skrá sem er staðsett í samræmi við slóðina sem tilgreind er í umhverfisbreytunni $METRICS_PATH.

Hér svo þú getur búið til rekstraraðila fyrir einfalda netvöktun í klasa.

Biðröð vélbúnaður

Þessi grein væri ófullnægjandi án þess að lýsa öðru mikilvægu kerfi sem er innbyggt í skel-rekstraraðilann. Ímyndaðu þér að það framkvæmi einhvers konar krók sem svar við atburði í þyrpingunni.

Hvað gerist ef eitthvað gerist á sama tíma í þyrpingunni? einn í viðbót atburður?
Mun skeljarstjóri keyra annað tilvik af króknum?
Hvað ef td fimm atburðir gerast í þyrpingunni í einu?
Mun skeljarstjórinn vinna úr þeim samhliða?
Hvað með neytt auðlindir eins og minni og CPU?

Sem betur fer er skeljarstjóri með innbyggðan biðröð. Allir atburðir eru í biðröð og unnar í röð.

Við skulum útskýra þetta með dæmum. Segjum að við höfum tvo króka. Fyrsti viðburðurinn fer í fyrsta krókinn. Þegar vinnslu þess er lokið færist röðin áfram. Næstu þremur viðburðum er vísað á annan krók - þeir eru fjarlægðir úr röðinni og færðir inn í hana í „búnti“. Það er að segja krókur tekur á móti fjölda atburða — eða, nánar tiltekið, margs konar bindandi samhengi.

Einnig þessar Hægt er að sameina viðburði í eitt stórt. Viðfangið ber ábyrgð á þessu group í bindandi uppsetningu.

Þú getur búið til hvaða fjölda biðraða/króka sem er og ýmsar samsetningar þeirra. Til dæmis getur ein biðröð unnið með tveimur krókum, eða öfugt.

Allt sem þú þarft að gera er að stilla reitinn í samræmi við það queue í bindandi uppsetningu. Ef nafn biðraðar er ekki tilgreint, keyrir krókurinn á sjálfgefna biðröð (default). Þessi biðröð gerir þér kleift að leysa öll auðlindastjórnunarvandamál þegar þú vinnur með krókum.

Ályktun

Við útskýrðum hvað skeljarvirki er, sýndum hvernig hægt er að nota hann til að búa til Kubernetes rekstraraðila fljótt og áreynslulaust og gáfum nokkur dæmi um notkun hans.

Ítarlegar upplýsingar um skeljarstjórann, svo og fljótleg kennslu um hvernig á að nota hann, eru fáanlegar í samsvarandi geymslur á GitHub. Ekki hika við að hafa samband við okkur með spurningar: þú getur rætt þær sérstaklega Telegram hópur (á rússnesku) eða á þessum vettvangi (á ensku).

Og ef þér líkaði við það, þá erum við alltaf ánægð að sjá ný tölublöð/PR/stjörnur á GitHub, þar sem þú getur fundið önnur áhugaverð verkefni. Meðal þeirra er vert að undirstrika addon-rekstraraðili, sem er stóri bróðir shell-operator. Þetta tól notar Helm töflur til að setja upp viðbætur, getur skilað uppfærslum og fylgst með ýmsum kortabreytum/gildum, stjórnar uppsetningarferli korta og getur einnig breytt þeim til að bregðast við atburðum í klasanum.

Myndbönd og glærur

Myndband frá gjörningnum (~23 mínútur):

Kynning á skýrslunni:

PS

Lestu líka á blogginu okkar:

Heimild: www.habr.com

Fara? Bash! Hittu skeljarstjórann (endurskoðun og myndbandsskýrsla frá KubeCon EU'2020)