🥇Kubernetese laiendamine ja täiendamine (ülevaade ja videoreportaaž)

8. aprillil konverentsil Saint HighLoad++ 2019, osana “DevOps ja operatsioonid” anti aruanne “Kubernetese laiendamine ja täiendamine”, mille loomisel osales kolm Flanti ettevõtte töötajat. Selles räägime arvukatest olukordadest, milles soovisime Kubernetese võimalusi laiendada ja täiendada, kuid millele me valmis ja lihtsat lahendust ei leidnud. Vajalikud lahendused on meil avatud lähtekoodiga projektide näol olemas ja ka käesolev kõne on neile pühendatud.

Traditsiooni kohaselt on meil hea meel esitleda video raportist (50 minutit, palju informatiivsem kui artikkel) ja põhiline kokkuvõte teksti kujul. Mine!

Tuum ja täiendused K8s

Kubernetes muudab pikka aega väljakujunenud tööstust ja lähenemisviise haldusele:

Tänu talle abstraktsioonid, me ei tööta enam selliste mõistetega nagu konfiguratsiooni seadistamine või käsu käivitamine (Chef, Ansible...), vaid kasutame konteinerite, teenuste jne rühmitamist.
Saame taotlusi ette valmistada ilma nüanssidele mõtlemata konkreetne sait, millel see käivitatakse: paljas metall, ühe pakkuja pilv jne.
K8-dega pole te kunagi olnud kättesaadavam parimad tavad infrastruktuuri korraldamise kohta: skaleerimistehnikad, iseparanemine, tõrketaluvus jne.

Kõik ei ole aga muidugi nii sujuv: Kubernetes tõi ka omad uued väljakutsed.

Kubernetes ei on kombain, mis lahendab kõigi kasutajate kõik probleemid. Kernel Kubernetes vastutab ainult minimaalsete vajalike funktsioonide komplekti eest iga klaster:

Kubernetese tuum määratleb põhiliste primitiivide komplekti konteinerite rühmitamiseks, liikluse haldamiseks ja nii edasi. Me rääkisime neist üksikasjalikumalt aruanne 2 aastat tagasi.

Teisest küljest pakub K8s suurepäraseid võimalusi olemasolevate funktsioonide laiendamiseks, mis aitavad teisi sulgeda - spetsiifiline — kasutajate vajadused. Kubernetese täienduste eest vastutavad klastri administraatorid, kes peavad installima ja konfigureerima kõik vajaliku, et saada klastrit õigesse vormi [oma konkreetsete probleemide lahendamiseks]. Mis lisandid need on? Vaatame mõnda näidet.

Lisandmoodulite näited

Pärast Kubernetese installimist võime olla üllatunud, et võrgustik, mis on nii sõlmesiseseks kui ka sõlmedevaheliseks koostoimeks nii vajalik, ei tööta iseenesest. Kubernetese tuum ei garanteeri vajalikke ühendusi, vaid määrab võrgu liides (CNI) kolmandate osapoolte lisandmoodulite jaoks. Peame installima ühe neist lisandmoodulitest, mis vastutab võrgu konfigureerimise eest.

Lähedane näide on andmesalvestuslahendused (kohalik ketas, võrguploki seade, Ceph...). Algselt olid nad tuumas, kuid tulekuga CSI olukord muutub millekski sarnaseks juba kirjeldatud: liides on Kubernetesis ja selle rakendamine on kolmanda osapoole moodulites.

Muud näited hõlmavad järgmist:

Ingress- kontrollerid (vt nende arvustust meie hiljutine artikkel).
sert-juhataja:
Ettevõtjad on terve klass lisandmooduleid (mis hõlmab ka mainitud serdihaldurit), need määratlevad primitiivi(d) ja kontrolleri(d). Nende töö loogikat piirab ainult meie kujutlusvõime ja see võimaldab meil muuta valmis infrastruktuuri komponendid (näiteks DBMS) primitiivideks, millega on palju lihtsam töötada (kui konteinerite ja nende seadete komplektiga). Kirjutatud on tohutult palju operaatoreid – isegi kui paljud neist pole veel tootmiseks valmis, on see vaid aja küsimus:
Mõõdikud - veel üks näide sellest, kuidas Kubernetes eraldas liidese (Metrics API) juurutusest (kolmanda osapoole lisandmoodulid, nagu Prometheuse adapter, Datadogi klastri agent...).
eest seire ja statistika, kus praktikas pole vaja mitte ainult Prometheus ja Grafana, aga ka kube-state-metrics, node-exporter jne.

Ja see pole täielik täienduste nimekiri... Näiteks ettevõttes Flant, mida me praegu paigaldame 29 täiendust (mis kõik loovad kokku 249 Kubernetese objekti). Lihtsamalt öeldes ei näe me klastri elu ilma täiendusteta.

Automaatika

Operaatorid on loodud automatiseerima rutiinseid toiminguid, millega me iga päev kokku puutume. Siin on näiteid elust, mille jaoks operaatori kirjutamine oleks suurepärane lahendus:

Rakenduse jaoks on piltidega privaatne (st sisselogimist nõudev) register. Eeldatakse, et igale taskule on määratud spetsiaalne saladus, mis võimaldab registris autentimist. Meie ülesanne on tagada, et see saladus leitaks nimeruumist, et kaunad saaksid pilte alla laadida. Rakendusi võib olla palju (igaüks neist vajab saladust) ja saladusi endid on kasulik regulaarselt värskendada, nii et käsitsi saladuste väljapaneku võimalus on välistatud. Siin tuleb appi operaator: loome kontrolleri, mis ootab nimeruumi ilmumist ja lisab selle sündmuse põhjal nimeruumi saladuse.
Let vaikimisi juurdepääs kaunadest Internetti on keelatud. Kuid mõnikord võib see olla vajalik: on loogiline, et juurdepääsulubade mehhanism töötab lihtsalt, ilma konkreetseid oskusi nõudmata, näiteks teatud sildi olemasolu tõttu nimeruumis. Kuidas saab operaator meid siin aidata? Luuakse kontroller, mis ootab sildi ilmumist nimeruumi ja lisab Interneti-juurdepääsu jaoks sobiva poliitika.
Sarnane olukord: oletame, et peame lisama teatud rikutud, kui sellel on sarnane silt (mingisuguse eesliitega). Tegevused operaatoriga on ilmsed...

Igas klastris tuleb lahendada rutiinsed ülesanded ja õigesti seda saab teha operaatorite abil.

Kõiki kirjeldatud lugusid kokku võttes jõudsime järeldusele, et mugavaks Kubernetes töötamiseks vajate: A) installige lisandmooduleid, b) arendada operaatoreid (igapäevaste administraatoriülesannete lahendamiseks).

Kuidas Kubernetesile avaldust kirjutada?

Üldiselt on skeem lihtne:

... aga siis selgub, et:

Kubernetes API on üsna mittetriviaalne asi, mille valdamine võtab palju aega;
programmeerimine pole ka kõigile (eelistatud keeleks valiti Go keel, kuna selle jaoks on spetsiaalne raamistik - Operaator SDK);
Sarnane on olukord raamistiku endaga.

Tulemus: kontrolleri kirjutamiseks (operaator) peab kulutada märkimisväärseid ressursse materjali uurima. See oleks õigustatud "suurte" operaatorite jaoks - näiteks MySQL DBMS-i jaoks. Aga kui meenub ülalkirjeldatud näited (saladuste lahtipakkimine, kaunade ligipääs Internetti...), mida tahame samuti õigesti teha, siis mõistame, et kulutatud jõupingutused kaaluvad üles praegu vajamineva tulemuse:

Üldiselt tekib dilemma: kulutada palju ressursse ja leida väidete kirjutamiseks õige tööriist või teha seda vanamoodsalt (aga kiiresti). Selle lahendamiseks – nende äärmuste vahel kompromissi leidmiseks – lõime oma projekti: kesta operaator (vaata ka tema hiljutine teadaanne rummu peal).

Shell-operaator

Kuidas ta töötab? Klastris on kaust, mis sisaldab Go-binaarfaili koos shell-operaatoriga. Tema kõrval on komplekt konksud (üksikasju nende kohta - vt allpool). Shell-operaator ise tellib teatud arengud Kubernetes API-s, mille ilmnemisel käivitab vastavad konksud.

Kuidas kooreoperaator teab, milliseid konkse milliste sündmuste puhul helistada? Selle teabe edastavad kesta operaatorile konksud ise ja nad teevad seda väga lihtsalt.

Konks on Bashi skript või mis tahes muu käivitatav fail, mis aktsepteerib ühte argumenti --config ja vastab JSON-iga. Viimane määrab, millised objektid teda huvitavad ja millistele sündmustele (nende objektide puhul) tuleks reageerida:

Illustreerin ühe meie näite rakendamist shell-operaatoril - rakenduse piltidega privaatsele registrile juurdepääsu saladuste lagunemine. See koosneb kahest etapist.

Harjutus: 1. Kirjutage konks

Esiteks töötleme konksus --config, mis näitab, et meid huvitavad nimeruumid ja täpsemalt nende loomise hetk:

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

Kuidas loogika välja näeks? Samuti üsna lihtne:

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

Esimene samm on välja selgitada, milline nimeruum loodi, ja teine on selle loomine kubectl selle nimeruumi saladus.

Praktika: 2. Pildi kokkupanek

Jääb üle vaid loodud konks kestaoperaatorile edasi anda - kuidas seda teha? Shell-operaator ise tuleb Dockeri kujutisena, seega on meie ülesandeks lisada konks selle pildi spetsiaalsesse kataloogi:

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

Jääb vaid see kokku panna ja lükata:

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

Viimane puudutus on pildi juurutamine klastris. Selleks kirjutame Deployment:

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

Tähelepanu tuleb pöörata kahele punktile:

märge vastloodud pildi kohta;
See on süsteemikomponent, mis vajab (vähemalt) õigusi Kubernetese sündmuste tellimiseks ja nimeruumidele saladuste eraldamiseks, seega loome konksu jaoks teenusekonto (ja reeglistiku).

Tulemus – lahendasime oma probleemi sugulased Kubernetese jaoks viisil, mis loob operaatori saladuste lagundamiseks.

Muud kestaoperaatori funktsioonid

Et piirata valitud tüüpi objekte, millega konks töötab, neid saab filtreerida, valides teatud siltide järgi (või kasutades matchExpressions):

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

Tingimusel deduplikatsiooni mehhanism, mis - kasutades jq filtrit - võimaldab suuri JSON-objekte teisendada väikesteks, kus jäävad alles vaid need parameetrid, mille muutusi soovime jälgida.

Konksu kutsumisel möödub kesta operaator sellest objekti andmed, mida saab kasutada mis tahes vajaduse korral.

Sündmused, mis käivitavad konksud, ei piirdu ainult Kubernetese sündmustega: shell-operaator pakub tuge aja järgi kutsumine (sarnane crontabiga traditsioonilises ajakavas), samuti eriline sündmus alglaadimisel. Kõiki neid sündmusi saab kombineerida ja määrata samale konksule.

Ja veel kaks kestaoperaatori funktsiooni:

See töötab asünkroonselt. Kuna Kubernetese sündmus (nt loodav objekt) võeti vastu, võis klastris esineda muid sündmusi (nt sama objekti kustutamine) ja konksud peavad sellega arvestama. Kui konks täideti veaga, siis vaikimisi see nii on tagasikutsumine kuni eduka lõpetamiseni (seda käitumist saab muuta).
See ekspordib mõõdikud Prometheuse jaoks, mille abil saate aru, kas shell-operaator töötab, saate teada iga konksu vigade arvu ja praeguse järjekorra suuruse.

Aruande selle osa kokkuvõtteks:

Lisandmoodulite installimine

Mugavaks Kubernetesega töötamiseks mainiti ka lisandmoodulite installimise vajadust. Räägin teile sellest, kasutades näitel meie ettevõtte teed selleni, kuidas me seda praegu teeme.

Kubernetesega alustasime koostööd mitme klastriga, mille ainsaks lisanduseks oli Ingress. See tuli paigaldada igas klastris erinevalt ja tegime mitu YAML-i konfiguratsiooni erinevate keskkondade jaoks: paljas metall, AWS...

Kuna klastreid oli rohkem, seda rohkem oli ka konfiguratsioone. Lisaks täiustasime neid konfiguratsioone ise, mille tulemusena muutusid need üsna heterogeenseks:

Et kõik korda seada, alustasime skriptiga (install-ingress.sh), mis võttis argumendiks klastri tüübi, millesse juurutame, genereeris vajaliku YAML-i konfiguratsiooni ja avaldas selle Kubernetes.

Lühidalt, meie edasine tee ja sellega seotud põhjendused olid järgmised:

YAML-i konfiguratsioonidega töötamiseks on vaja mallimootorit (esimestel etappidel on see lihtne);
koos klastrite arvu suurenemisega tuli vajadus automaatse uuendamise järele (kõige varasem lahendus oli panna skript Giti, uuendada croniga ja käivitada);
sarnast skripti oli vaja ka Prometheuse jaoks (install-prometheus.sh), on see aga märkimisväärne selle poolest, et see nõuab palju rohkem sisendandmeid ja ka nende salvestamist (heas mõttes - tsentraliseeritud ja kobaras) ning mõned andmed (paroolid) saaks genereerida automaatselt:
oht, et üha suuremale hulgale klastritele midagi valesti levitatakse, kasvas pidevalt, nii et mõistsime, et paigaldajad (st kaks skripti: Ingressi ja Prometheuse jaoks) vaja oli lavastust (Gitis mitu haru, mitu kroni, et neid vastavates värskendada: stabiilsetes või testklastrites);
с kubectl apply sellega on raske töötada, kuna see ei ole deklaratiivne ja suudab ainult objekte luua, kuid mitte teha otsuseid nende staatuse kohta/kustutada;
Meil puudusid mõned funktsioonid, mida me polnud tol ajal üldse rakendanud:
- täielik kontroll klastri värskenduste tulemuste üle,
- mõne parameetri automaatne määramine (paigaldusskriptide sisend) klastrist saadavate andmete põhjal (avastus),
- selle loogiline areng pideva avastamise vormis.

Kogu selle kogutud kogemuse rakendasime oma teise projekti raames - lisand-operaator.

Addon-operaator

See põhineb juba mainitud shell-operaatoril. Kogu süsteem näeb välja selline:

Korpuse operaatori konksudele lisatakse järgmine:

väärtuste salvestus,
Helmi diagramm,
komponent see jälgib väärtuste salvestust ja - muudatuste korral - palub Helmil graafik uuesti rullida.

Seega saame Kubernetes sündmusele reageerida, konksu käivitada ja sellest konksust teha salvestuses muudatusi, misjärel laaditakse diagramm uuesti alla. Saadud diagrammil eraldame konksude komplekti ja diagrammi üheks komponendiks, mida me nimetame moodul:

Moodulid võib olla palju ja neile lisame globaalsed konksud, globaalsete väärtuste poe ja komponendi, mis jälgib seda globaalset poodi.

Nüüd, kui Kubernetesis midagi juhtub, saame sellele globaalse konksu abil reageerida ja globaalses poes midagi muuta. Seda muudatust märgatakse ja selle tulemusel võetakse kasutusele kõik klastri moodulid:

See skeem vastab kõigile ülaltoodud lisandmoodulite installimise nõuetele:

Helm vastutab mallide ja deklaratiivsuse eest.
Automaatse värskendamise probleem lahendati globaalse konksu abil, mis läheb registrisse ajakava alusel ja kui ta näeb seal uut süsteemipilti, veeretab selle välja (st "ise").
Sätete salvestamine klastris on realiseeritud kasutades ConfigMap, mis sisaldab salvestusruumide esmaseid andmeid (käivitamisel laaditakse need salvestusruumidesse).
Parooli genereerimise, avastamise ja pideva avastamisega seotud probleemid lahendati konksude abil.
Lavastus saavutatakse tänu siltidele, mida Docker karbist väljas toetab.
Tulemust jälgitakse mõõdikute abil, mille abil saame olekust aru saada.

Kogu see süsteem on Go-s rakendatud ühe kahendfailina, mida nimetatakse addon-operaatoriks. See muudab diagrammi lihtsamaks:

Selle diagrammi põhikomponent on moodulite komplekt (allpool halliga esile tõstetud). Nüüd saame väikese vaevaga kirjutada vajalikule lisandmoodulile mooduli ja olla kindlad, et see paigaldatakse igasse klastris, uuendatakse ja reageerib klastris vajalikele sündmustele.

"Lamedad" kasutusalad lisand-operaator 70+ Kubernetese klastrites. Praegune seis - alfa versioon. Nüüd valmistame ette dokumentatsiooni beetaversiooni avaldamiseks, kuid praegu on see hoidlas näited saadaval, mille põhjal saate luua oma lisandmooduli.

Kust saada addon-operaatori mooduleid? Raamatukogu väljaandmine on meie jaoks järgmine etapp, plaanime seda teha suvel.

Videod ja slaidid

Video etendusest (~50 minutit):

Aruande esitlus:

PS

Teised aruanded meie ajaveebis:

«Andmebaasid ja Kubernetes"; (Dmitry Stolyarov; 8. november 2018, HighLoad++);
«Järelevalve ja Kubernetes"; (Dmitry Stolyarov; 28. mai 2018 RootConfis);
«CI/CD parimad tavad Kubernetese ja GitLabiga"; (Dmitry Stolyarov; 7. november 2017, HighLoad++);
«Meie kogemus Kubernetesega väikestes projektides"; (Dmitry Stolyarov; 6. juuni 2017 RootConfis).

Samuti võite olla huvitatud järgmistest väljaannetest:

«Tutvustame shell-operaatorit: operaatorite loomine Kubernetese jaoks muutus just lihtsamaks'.

Allikas: www.habr.com

Kubernetese laiendamine ja täiendamine (ülevaade ja videoaruanne)