🥇Stækka og bæta við Kubernetes (endurskoðun og myndbandsskýrsla)

8. apríl á ráðstefnunni Saint HighLoad++ 2019, sem hluti af „DevOps and Operations“ hlutanum, var gefin skýrsla „Expanding and complementing Kubernetes“, sem þrír starfsmenn Flant-fyrirtækisins tóku þátt í. Þar erum við að tala um fjölmargar aðstæður þar sem við vildum auka og bæta við getu Kubernetes, en við fundum ekki tilbúna og einfalda lausn fyrir. Við erum með nauðsynlegar lausnir í formi Open Source verkefna og þessi ræða er einnig tileinkuð þeim.

Samkvæmt hefð erum við ánægð að kynna myndband af skýrslunni (50 mínútur, mun fróðlegri en greinin) og aðalsamantekt í textaformi. Farðu!

Kjarni og viðbætur í K8s

Kubernetes er að breyta iðnaðinum og aðferðum við stjórnsýslu sem hefur lengi verið komið á fót:

Þökk sé honum útdrættir, við vinnum ekki lengur með hugtök eins og að setja upp stillingar eða keyra skipun (Chef, Ansible...), heldur notum við flokkun gáma, þjónustu o.s.frv.
Við getum undirbúið umsóknir án þess að hugsa um blæbrigði ákveðin síða, þar sem það verður hleypt af stokkunum: ber málmur, ský frá einum af veitendum osfrv.
Með K8 hefurðu aldrei verið aðgengilegri bestu aðferðir um skipulagningu innviða: mælikvarðatækni, sjálfsheilun, bilanaþol o.fl.

Hins vegar er auðvitað ekki allt svo slétt: Kubernetes kom líka með sínar eigin nýjar áskoranir.

Kubernetes ekki er blanda sem leysir öll vandamál allra notenda. Kjarna Kubernetes ber aðeins ábyrgð á safni af lágmarks nauðsynlegum aðgerðum sem eru til staðar í hvert þyrping:

Kubernetes kjarninn skilgreinir grunnsett af frumstæðum til að flokka gáma, stjórna umferð og svo framvegis. Við ræddum þau nánar í skýrslu fyrir 2 árum.

Á hinn bóginn býður K8s upp á frábær tækifæri til að auka tiltækar aðgerðir, sem hjálpa til við að loka öðrum - sérstakur - þarfir notenda. Viðbætur við Kubernetes eru á ábyrgð klasastjórnenda, sem verða að setja upp og stilla allt sem þarf til að koma klasanum sínum „í rétta mynd“ [til að leysa sín sérstöku vandamál]. Hvers konar viðbætur eru þetta? Við skulum skoða nokkur dæmi.

Dæmi um viðbætur

Eftir að hafa sett upp Kubernetes gætum við verið hissa á því að netkerfið sem er svo nauðsynlegt fyrir samskipti fræbelgja bæði innan hnúts og milli hnúta virkar ekki eitt og sér. Kubernetes kjarninn ábyrgist ekki nauðsynlegar tengingar; þess í stað ákvarðar hann netið tengi (CNI) fyrir viðbætur frá þriðja aðila. Við verðum að setja upp eina af þessum viðbótum, sem mun bera ábyrgð á netstillingunni.

Nærtækt dæmi eru gagnageymslulausnir (staðbundinn diskur, netblokkunarbúnaður, Ceph...). Í upphafi voru þeir í kjarnanum, en með tilkomu CSI ástandið breytist í eitthvað svipað því sem þegar hefur verið lýst: viðmótið er í Kubernetes og útfærsla þess er í einingum frá þriðja aðila.

Önnur dæmi eru:

Innstreymi-stýringar (sjá umfjöllun þeirra í nýleg grein okkar).
vottstjóri:
Stjórnandi er heill flokkur af viðbótum (sem inniheldur nefndan cert-manager), þær skilgreina frumstæða(r) og stýringar(a). Rökfræði vinnu þeirra takmarkast aðeins af ímyndunarafli okkar og gerir okkur kleift að breyta tilbúnum innviðahlutum (til dæmis DBMS) í frumefni, sem er miklu auðveldara að vinna með (en með sett af ílátum og stillingum þeirra). Mikill fjöldi rekstraraðila hefur verið skrifaður - jafnvel þótt margir þeirra séu ekki enn tilbúnir til framleiðslu, þá er það aðeins spurning um tíma:
Mælingar - önnur mynd af því hvernig Kubernetes aðskildi viðmótið (Metrics API) frá útfærslunni (viðbætur frá þriðja aðila eins og Prometheus millistykki, Datadog klasa umboðsmaður...).
Fyrir eftirlit og tölfræði, þar sem í reynd er ekki aðeins þörf Prometheus og Grafana, en einnig kúbe-state-mælingar, hnúta-útflytjandi o.s.frv.

Og þetta er ekki tæmandi listi yfir viðbætur... Til dæmis hjá Flant fyrirtækinu sem við setjum upp núna 29 viðbætur (sem allir búa til alls 249 Kubernetes hluti). Einfaldlega sagt, við getum ekki séð líf klasa án viðbóta.

Sjálfvirkni

Rekstraraðilar eru hönnuð til að gera sjálfvirkan venjubundnar aðgerðir sem við lendum í á hverjum degi. Hér eru dæmi úr raunveruleikanum þar sem að skrifa rekstraraðila væri frábær lausn:

Það er einkaskrá (þ.e. þarfnast innskráningar) með myndum fyrir forritið. Gert er ráð fyrir að hverjum belg sé úthlutað sérstöku leyndarmáli sem leyfir auðkenningu í skránni. Verkefni okkar er að tryggja að þetta leyndarmál sé að finna í nafnarýminu svo að fræbelgir geti halað niður myndum. Það getur verið mikið af forritum (þarf hvert um sig leyndarmál) og það er gagnlegt að uppfæra leyndarmálin sjálf reglulega, þannig að möguleikinn á að leggja út leyndarmál með höndunum er útilokaður. Þetta er þar sem rekstraraðilinn kemur til bjargar: við búum til stjórnandi sem mun bíða eftir að nafnrýmið birtist og, byggt á þessum atburði, bætir leyndarmál við nafnrýmið.
Sjálfgefið er bannaður aðgangur frá belgjum að internetinu. En stundum getur verið nauðsynlegt: það er rökrétt að aðgangsheimildarkerfið virki einfaldlega, án þess að krefjast sérstakrar kunnáttu, til dæmis með því að vera til staðar ákveðinn merkimiði í nafnrýminu. Hvernig getur rekstraraðilinn hjálpað okkur hér? Stýribúnaður er búinn til sem bíður eftir að merkið birtist í nafnrýminu og bætir við viðeigandi stefnu fyrir netaðgang.
Svipað ástand: segjum að við þyrftum að bæta við ákveðinni spilla, ef það hefur svipaðan merkimiða (með einhvers konar forskeyti). Aðgerðirnar með rekstraraðilanum eru augljósar...

Í hvaða klasa sem er þarf að leysa venjubundin verkefni og rétt þetta er hægt að gera með því að nota rekstraraðila.

Þegar við tókum saman allar sögurnar sem lýst er, komumst við að þeirri niðurstöðu fyrir þægilega vinnu í Kubernetes sem þú þarft:A) setja upp viðbætur, b) þróa rekstraraðila (til að leysa dagleg stjórnunarverkefni).

Hvernig á að skrifa yfirlýsingu fyrir Kubernetes?

Almennt séð er kerfið einfalt:

... en svo kemur í ljós að:

Kubernetes API er frekar óléttvægur hlutur sem tekur mikinn tíma að ná tökum á;
Forritun er heldur ekki fyrir alla (Go tungumálið var valið sem ákjósanlegt tungumál vegna þess að það er sérstakur rammi fyrir það - SDK rekstraraðila);
Svipað er uppi á teningnum með umgjörðina sjálfa.

The botn lína: að skrifa stjórnandi (rekstraraðili) þarf að eyða umtalsverðu fjármagni að læra efni. Þetta væri réttlætanlegt fyrir „stóra“ rekstraraðila - segjum fyrir MySQL DBMS. En ef við munum eftir dæmunum sem lýst er hér að ofan (frumvarpa leyndarmál, fá aðgang að netinu...), sem við viljum líka gera rétt, þá munum við skilja að átakið sem lagt er í mun vega þyngra en árangurinn sem við þurfum núna:

Almennt séð kemur upp vandamál: eyða miklu fjármagni og finna rétta tólið til að skrifa fullyrðingar, eða gera það á gamaldags hátt (en fljótt). Til að leysa það - til að finna málamiðlun milli þessara öfga - bjuggum við til okkar eigið verkefni: skel-rekstraraðili (sjá einnig hans nýleg tilkynning á miðstöðinni).

Skeljarstjóri

Hvernig virkar hann? Þyrpingin er með belg sem inniheldur Go-tvíundir með skeljarvirkja. Við hlið hans er sett af krókar (nánari upplýsingar um þau - sjá hér að neðan). The skel-rekstraraðili sjálfur gerist áskrifandi að ákveðnum þróun í Kubernetes API, þegar það kemur upp ræsir það samsvarandi króka.

Hvernig veit skeljarstjórinn hvaða króka hann á að kalla á hvaða atburði? Þessar upplýsingar eru sendar til skeljarstjórans með krókunum sjálfum og þeir gera það mjög einfaldlega.

Krókur er Bash handrit eða önnur keyranleg skrá sem tekur við einum rökum --config og svarar með JSON. Hið síðarnefnda ákvarðar hvaða hlutir eru áhugaverðir fyrir það og hvaða atburði (fyrir þessa hluti) ætti að bregðast við:

Ég mun útskýra útfærslu á skeljarstjóra einu af dæmunum okkar - niðurbrot leyndarmála til að fá aðgang að einkaskrá með forritamyndum. Það samanstendur af tveimur stigum.

Æfing: 1. Skrifaðu krók

Fyrst af öllu, í króknum munum við vinna --config, sem gefur til kynna að við höfum áhuga á nafnrýmum, og sérstaklega augnablikinu þegar þau voru til:

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

Hvernig myndi rökfræðin líta út? Einnig frekar einfalt:

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

Fyrsta skrefið er að finna út hvaða nafnrými var búið til og annað er að búa það til með því að nota kubectl leyndarmál fyrir þetta nafnrými.

Æfing: 2. Að setja saman myndina

Allt sem er eftir er að koma króknum sem búið var til til skeljarstjórans - hvernig á að gera þetta? Skeljarstjórinn sjálfur kemur sem Docker mynd, svo verkefni okkar er að bæta króknum við sérstaka möppu á þessari mynd:

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

Allt sem er eftir er að setja það saman og ýta því:

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

Síðasta snertingin er að dreifa myndinni í þyrpinguna. Til að gera þetta skulum við skrifa dreifing:

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

Það eru tveir punktar sem þarf að huga að:

vísbending um nýstofnaða mynd;
Þetta er kerfishluti sem (að minnsta kosti) þarf réttindi til að gerast áskrifandi að viðburðum í Kubernetes og til að úthluta leyndarmálum til nafnarýma, þannig að við búum til Þjónustureikning (og sett af reglum) fyrir krókinn.

Niðurstaða - við leystum vandamál okkar ættingja fyrir Kubernetes á þann hátt að búa til rekstraraðila til að brjóta niður leyndarmál.

Aðrir eiginleikar sem stjórna skel

Til að takmarka hluti af þinni tegund sem krókurinn mun vinna með, þau má sía, velja samkvæmt ákveðnum merkimiðum (eða nota matchExpressions):

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

Veitt aftvíföldunarkerfi, sem - með jq síu - gerir þér kleift að breyta stórum JSON hlutum í litla, þar sem aðeins þær breytur eru eftir sem við viljum fylgjast með með tilliti til breytinga.

Þegar hringt er í krók fer skeljarstjórinn framhjá honum gögn um hlut, sem hægt er að nota fyrir hvaða þörf sem er.

Atburðir sem kalla á króka takmarkast ekki við Kubernetes viðburði: skeljarstjórinn veitir stuðning við kalla króka eftir tíma (svipað og crontab í hefðbundnum tímaáætlun), sem og sérstakur viðburður við ræsingu. Hægt er að sameina alla þessa viðburði og tengja við sama krókinn.

Og tveir fleiri eiginleikar skeljarstjórans:

Það virkar ósamstilltur. Þar sem Kubernetes atburður (eins og hlutur sem verið er að búa til) var móttekinn, gætu aðrir atburðir (eins og sama hlutnum var eytt) hafa átt sér stað í þyrpingunni og krókar þurfa að gera grein fyrir þessu. Ef krókurinn var keyrður með villu, þá verður það sjálfgefið hringja aftur þar til henni er lokið (þessa hegðun er hægt að breyta).
Það flytur út mæligildi fyrir Prometheus, sem þú getur skilið hvort skeljarstjórinn sé að virka, finndu út fjölda villna fyrir hvern krók og núverandi biðraðarstærð.

Til að draga saman þennan hluta skýrslunnar:

Setur upp viðbætur

Fyrir þægilega vinnu með Kubernetes var einnig minnst á þörfina á að setja upp viðbætur. Ég mun segja þér frá því með því að nota dæmið um leið fyrirtækisins okkar að því hvernig við gerum það núna.

Við byrjuðum að vinna með Kubernetes með nokkrum klösum, eina viðbótin við það var Ingress. Það þurfti að setja það upp á annan hátt í hverjum klasa og við gerðum nokkrar YAML stillingar fyrir mismunandi umhverfi: ber málmur, AWS...

Þar sem það voru fleiri klasar voru fleiri stillingar. Að auki bættum við þessar stillingar sjálfar, þar af leiðandi urðu þær nokkuð ólíkar:

Til að koma öllu í röð og reglu byrjuðum við á handriti (install-ingress.sh), sem tók sem rök hvers konar klasa sem við munum dreifa til, bjó til nauðsynlegar YAML stillingar og rúllaði henni út til Kubernetes.

Í stuttu máli var frekari leið okkar og rökin sem henni tengdust eftirfarandi:

til að vinna með YAML stillingar þarf sniðmátsvél (á fyrstu stigum er þetta einfalt sed);
með fjölgun þyrpinga kom þörfin fyrir sjálfvirka uppfærslu (elsta lausnin var að setja handritið í Git, uppfæra það með cron og keyra það);
svipað handrit var krafist fyrir Prometheus (install-prometheus.sh), það er hins vegar athyglisvert fyrir þá staðreynd að það krefst miklu meiri inntaksgagna, sem og geymslu þeirra (á góðan hátt - miðlæg og í klasa), og sum gögn (lykilorð) gætu myndast sjálfkrafa:
hættan á því að eitthvað rangt færi út í vaxandi fjölda klasa var stöðugt að aukast, svo við áttum okkur á því að uppsetningaraðilar (þ.e. tvö handrit: fyrir Ingress og Prometheus) sviðsetning var þörf (nokkrar greinar í Git, nokkrar crons til að uppfæra þær í samsvarandi: stöðugum eða prófþyrpingum);
с kubectl apply það er orðið erfitt að vinna með það vegna þess að það er ekki lýsandi og getur aðeins búið til hluti, en ekki tekið ákvarðanir um stöðu þeirra/eytt þeim;
Okkur vantaði nokkrar aðgerðir sem við höfðum alls ekki innleitt á þeim tíma:
- fulla stjórn á niðurstöðu klasauppfærslna,
- sjálfvirk ákvörðun sumra breytu (inntak fyrir uppsetningarforskriftir) byggt á gögnum sem hægt er að fá úr klasanum (uppgötvun),
- rökrétt þróun þess í formi stöðugrar uppgötvunar.

Við innleiddum alla þessa uppsöfnuðu reynslu innan ramma hins verkefnis okkar - addon-rekstraraðili.

Addon-stjórnandi

Það er byggt á áðurnefndum skel-rekstraraðila. Allt kerfið lítur svona út:

Eftirfarandi bætist við skeljarkrókana:

verðmæti geymsla,
Hjálmarkort,
þáttur sem fylgist með verðmætaversluninni og - ef einhverjar breytingar verða - biður Helm um að rúlla töflunni aftur.

Þannig getum við brugðist við atburði í Kubernetes, ræst krók og frá þessum krók getum við gert breytingar á geymslunni, eftir það verður töflunni hlaðið niður aftur. Í skýringarmyndinni sem myndast, aðskiljum við krókasettið og töfluna í einn íhlut, sem við köllum mát:

Það geta verið margar einingar og við þær bætum við alþjóðlegum krókum, alþjóðlegri verðmætaverslun og íhlut sem fylgist með þessari alþjóðlegu verslun.

Nú, þegar eitthvað gerist í Kubernetes, getum við brugðist við því með því að nota alþjóðlegan krók og breytt einhverju í alþjóðlegu versluninni. Tekið verður eftir þessari breytingu og mun valda því að allar einingar í klasanum verða settar út:

Þetta kerfi uppfyllir allar kröfur til að setja upp viðbætur sem voru tilgreindar hér að ofan:

Helm ber ábyrgð á sniðmátum og yfirlýsingu.
Vandamálið með sjálfvirka uppfærslu var leyst með því að nota alþjóðlegan krók, sem fer í skrána á áætlun og, ef það sér nýja kerfismynd þar, rúllar það út (þ.e. „sjálfur“).
Geymsla stillingar í klasanum er útfærð með því að nota ConfigMap, sem inniheldur aðalgögnin fyrir geymslurnar (við ræsingu er þeim hlaðið inn í geymslurnar).
Vandamál með lykilorðagerð, uppgötvun og stöðuga uppgötvun voru leyst með því að nota króka.
Sviðsetning er náð þökk sé merkjum, sem Docker styður úr kassanum.
Fylgst er með niðurstöðunni með því að nota mælikvarða sem við getum skilið stöðuna með.

Allt þetta kerfi er útfært í formi eins tvöfalds í Go, sem er kallað addon-operator. Þetta gerir skýringarmyndina einfaldari:

Aðalhlutinn í þessari skýringarmynd er sett af einingum (merkt með gráu fyrir neðan). Nú getum við skrifað einingu fyrir nauðsynlega viðbót með smá fyrirhöfn og verið viss um að hún verði sett upp í hverjum klasa, verði uppfærð og svarað þeim atburðum sem það þarf í klasanum.

"Flant" notar addon-rekstraraðili á 70+ Kubernetes þyrpingum. Núverandi staða - alfa útgáfa. Nú erum við að undirbúa skjöl til að gefa út beta, en í bili í geymslunni fyrirliggjandi dæmi, á grundvelli þess geturðu búið til þína eigin viðbót.

Hvar get ég fengið einingarnar fyrir addon-operator? Útgáfa bókasafnsins okkar er næsti áfangi fyrir okkur; við ætlum að gera þetta í sumar.

Myndbönd og glærur

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

Kynning á skýrslunni:

PS

Aðrar skýrslur á blogginu okkar:

«Gagnasöfn og Kubernetes»; (Dmitry Stolyarov; 8. nóvember 2018 á HighLoad++);
«Vöktun og Kubernetes»; (Dmitry Stolyarov; 28. maí 2018 á RootConf);
«Bestu starfsvenjur CI/CD með Kubernetes og GitLab»; (Dmitry Stolyarov; 7. nóvember 2017 á HighLoad++);
«Reynsla okkar af Kubernetes í litlum verkefnum»; (Dmitry Stolyarov; 6. júní 2017 á RootConf).

Þú gætir líka haft áhuga á eftirfarandi ritum:

«Við kynnum skeljarstjóra: að búa til rekstraraðila fyrir Kubernetes er nú orðið auðveldara'.

Heimild: www.habr.com

Stækka og bæta Kubernetes (endurskoðun og myndbandsskýrsla)