Kubernetesi laiendamine ja täiendamine (ülevaade ja video ettekandest)

8. aprill konverentsil Saint HighLoad++ 2019, DevOps ja haldamise sektsiooni raames toimus ettekande "Kubernetesi laiendamine ja täiendamine" esitus, mille koostamisel osalesid kolm ettevõtte "Flant" töötajat. Selles räägime mitmetest olukordadest, kus soovisime Kuberneteset laiendada ja täiendada, kuid ei leidnud selleks valmis ja lihtsat lahendust. Vajalikud lahendused ilmusid meile Open Source projektide näol, millele see ettekande ka pühendatud.

Traditsiooniliselt oleme uhked esitama ettekande video vaatamiseks (50 minutit, palju informatiivsem kui artikkel) ja peamise kokkuvõtte tekstivormis. Alustame!

K8si tuum ja lisandused

Kubernetes muudab valdkonda ja administreerimise lähenemisi, mis on juba ammu kindlaks kujunenud:

• Tänu tema abstraktsioonidele, opereme me enam mitte selliste mõistetega nagu konfi seadistamine või käsu käivitamine (Chef, Ansible…), vaid kasutame konteinerite rühmitamist, teenuseid jne.
• Saame rakendusi valmistada, mõtlemata konkreetse platvormi, millel see käivitub: bare metal, ühe teenusepakkuja pilv jne.
• K8si abil on muutunud kergemaks parimate praktikate kasutamine infrastruktuuri korraldamise osas: skaleerimise, enesetäiustamise, vigade taastumise tehnikaid jne.

Kuid loomulikult ei ole kõik nii sujuv: koos Kubernetesega tulid ka uued väljakutsed.

Kubernetes ei on kombain, mis lahendab kõigi kasutajate probleemid. Tuuma Kubernetes vastutab ainult minimaalsete vajalike funktsioonide komplekti eest, mis on olemas igal klastril:

Kubernetes tuum määratleb põhikomplekti primitiive — konteinerite rühmitamiseks, liikluse haldamiseks ning nii edasi. Rääkisime neist lähemalt kahe aasta taguses ettekandes.

Teiselt poolt pakub K8s suurepäraseid võimalusi olemasolevate funktsioonide laiendamiseks, et katta ka teised — spetsiifilised kasutajate vajadused. Kubernetese täienduste eest vastutavad klastri administraatorid, kes peavad kõik vajalikud koostisosad installima ja konfigureerima, et nende klaster "omandaks vajaliku vormi" [nende spetsiifiliste ülesannete lahendamiseks]. Millised need täiendused on? Vaatame mõnda näidet.

Täienduste näited

Kubernetes'i seadistamisel võime olla üllatunud, et pod-ide omavaheline suhtlemine, nii sõlmede sees kui ka nende vahel, ei toimi. Kubernetes'i süda ei taga vajalikke ühendusi — selle asemel defineerib see võrgu liidese (CNI) kolmandate osapoolte pluginatele. Me peame installima ühe sellise plugina, mis vastutab võrgu seadistamise eest.

Lähedane näide — andmesalvestuslahendused (kohalik kett, võrgutöötlusseade, Ceph...). Alguses olid need süsteemi sees, kuid koos CSI muutub olukord sarnaseks juba kirjeldatule: Kubernetes'is on liides ja selle teostamine on kolmandate osapoolte moodulites.

Teiste näidete seast:

• Ingress-kontrollerid (ülevaate saamiseks vt meie hiljutist artiklit).
• cert-manager:

  

• Operaatorid — on terve rikka klass laiendusi (kuhu kuulub ka mainitud cert-manager), mis määratleb primitiivid ja kontrollijad. Nende töö loogika on piiratud vaid meie kujutlusvõimega ning võimaldab muuta olemasolevad infrastruktuuri komponendid (näiteks andmebaasid) primitiivideks, millega on palju lihtsam töötada (kui konteinerite ja nende seadistuste kogumiga). Operaatoreid on kirjutatud tohutult palju — ja kuigi paljud neist pole veel produzentsiks valmis, on see vaid aja küsimus:

  

• Mõõdikud — veel üks illustratsioon, kuidas Kubernetes eraldas liidese (Metrics API) rakendusest (kolmandate osapoolte laiendused, nagu Prometheus adapter, Datadog cluster agent…)
• Kuna monitooringu ja statistika, kus praktikas on vajalikud mitte ainult Prometheus ja Grafana, vaid ka kube-state-metrics, node-exporter jpt.

Ja see ei ole kaugeltki täielik nimekiri laiendustest… Näiteks installime meie ettevõttes „Flant” iga Kubernetes-klastrile tänaseks 29 laiendust (kõik loovad kokku 249 Kubernetes objekt). Teisisõnu, me ei näe klastrite elu ilma laiendusteta.

Automatiseerimine

Operaatoreid on loodud rutiinsete toimingute automatiseerimiseks, millega igapäevaselt kokku puutume. Siin on elust näited, mille jaoks oleks optimaalne lahendus operaatori kirjutamine:

1. On olemas privaatne (s.t. sisselogimist nõudev) register rakenduse piltide jaoks. Eeldatakse, et igale pod’ile seostatakse spetsiaalne saladus, mis võimaldab autentida ennast registris. Meie ülesanne on tagada, et see saladus asub nimedruumis, et pod’id saaksid pilte allalaadida. Rakendusi (kellel on igaühel vaja saladust) võib olla väga palju ja saladusi on mõistlik regulaarselt uuendada, nii et käsitsi saladuste paigutamine pole variant. Just siin tulebki abi operaatorist: loome kontrolleri, mis ootab nimedruumi ilmumist ja selle sündmuse puhul lisab saladuse nimedruumi.
2. Oletame, et vaikimisi on pod’ide internetiühendus keelatud. Kuid mõnikord võib see vajalik olla: loogiline on, et juurdepääsumehanism töötaks lihtsalt, ilma spetsiifiliste oskuste nõudmiseta — näiteks teatud silti olemasolu põhjal namespace’is. Kuidas saab operaator siin abiks olla? Loo kontrollija, mis ootab silti namespace’is ja lisab vastava poliitika internetiühenduse jaoks.
3. Sarnane olukord: oletame, et peame lisama sõlmele teatud taint, kui sellel on samasugune silt (mingi eesliitega). Tegevused operaatoriga on ilmsed…

Igas klastris tuleb lahendada rutiinseid ülesandeid ning õigesti seda teha — operaatorite abil.

Kokkuvõtteks kõigist kirjeldatud lugudest jõudsime järeldusele, et Kuberneteses mugavalt töötamiseks on vajalik: a) paigaldada lisandmooduleid, b) arendada operaatorite (igapäevaste administraatoriülesannete lahendamiseks).

Kuidas kirjutada Kubernetes'e operaatorit?

Üldiselt on skeem lihtne:

… kuid selgub, et:

• Kubernetes API on piisavalt mittetriviaalne asi, mis nõuab palju aega õppimiseks;
• programmeerimine ei ole ka kõigile (Go keel on valitud eelistatuna, sest selle jaoks on olemas spetsiaalne raamistik — Operator SDK);
• raamistikuga on olukord sarnane.

Kokkuvõte: kontrolleri kirjutamiseks (operaatori) tuleb kulutada märkimisväärseid ressursse õpikute tundmiseks. See oleks põhjendatud "suuremate" operaatorite jaoks — näiteks MySQL andmebaasi jaoks. Kuid kui me meenutame eelnevalt kirjeldatud näiteid (saladuste jagamine, pod'ide juurdepääs internetis…), mida tahame samuti õigesti teha, siis saame aru, et tehtud pingutused ületavad vajaliku tulemuse:

Kokkuvõttes tekib dilemma: kulutada palju ressursse ja omandada õige tööriist operaatorite kirjutamiseks või tegutseda "vana viisi" (aga kiiresti). Selle lahendamiseks — kompromissi leidmiseks nende äärmuslike lähenemiste vahel — lõime oma projekti: shell-operator (vt ka selle hiljutine teadanne Habrast).

Shell-operator

Kuidas see töötab? Klusteris on pod, milles asub Go binaar shell-operatoriga. Selle kõrval hoitakse komplekti hook'ide (lisainfot nende kohta — vt allpool). Shell-operator ise kuulub kindlatele sündmustele Kubernetes API-s käivitavad vastavaid hübriidide vastavad sündmused.

Kuidas shell-operator mõistab, milliseid hübriide milliste sündmuste korral kutsuda? Selle teabe edastavad shell-operatorile hübriidid ise, tehes seda väga lihtsalt.

Hübro on Bash-skripti või mõne muu täidetava faili, mis toetab ühte argumenti --config ja tagastab selle peale JSON-i. Viimane määrab, millised objektid teda huvitavad ja millistele sündmustele (neid objekte silmas pidades) tuleks reageerida:

Illustreerin shell-operatori rakendust meie näitest — saladuste jaotamine privaatse registry-le rakenduse piltide juurdepääsuks. See koosneb kahest etapist.

Praktika: 1. Kirjutame hübriidi

Esimese asjana töötame hübriidi sees --config, märkides, et meid huvitavad namespace'id, ja konkreetsemalt — nende loomise hetk:

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

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

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

Esimese sammuna saame teada, milline namespace on loodud, ja teiseks — loome läbi kubectl saladuse selle nimede alale.

Praktika: 2. Loome pilti

Jäänud on edastada loodud käepide shell-operatorile — kuidas seda teha? Shell-operator tuleb Docker-pildina, seega meie ülesanne on lisada käepide spetsiaalsesse katalooge selles pildis:

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

Jääb alles see üles ehitada ja push'ida:

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

Viimane puudutus — laadida pilt klastrisse. 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

Siin tuleb tähelepanu pöörata kahele punktile:

1. just loodud pildi näitamine;
2. see on süsteemikomponent, millel (vähemalt) on vaja õigusi, et registreeruda Kubernetes'is sündmustele ja et jagada saladusi namespace'ide vahel, seega loome käepideme jaoks ServiceAccount'i (ja komplekti reegleid).

Tulemus — me lahendasime oma probleemi loodud Kubernetes'i viisil, luues operaatori saladuste jagamiseks.

Muud shell-operatori võimalused

Et piirata teie valitud tüüpi objekte, millega käepide töötama hakkab, saab neid filtreerida, valides etiketid valides on (või koos matchExpressions):

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

Kavandatud deduplikaatsiooni mehhanism, mis — jq-filtri abil — võimaldab suuri JSON objekte konverteerida väikesteks, kus jäävad alles vaid need parameetrid, mille muutust me tahame jälgida.

Hooki shell-operatori kutsumisel edastab ta andmed objekti kohta, mida saab kasutada igasugusteks vajadusteks.

Sündmused, mille korral hüpikuid kutsutakse, ei ole piiratud Kubernetes sündmustega: shell-operator toetab hüpikute kutsumist ajas (sarnane crontabile traditsioonilises ajakava koostajas), samuti spetsiaalset sündmust onStartup. Kõiki neid sündmusi saab kombineerida ja määrata ühele ja samale hüpikule.

Ja veel kaks omadust shell-operatori kohta:

1. Ta töötab asünkroonselt. Alates Kubernetes'i sündmuse (näiteks objekti loomise) saamisest on klastris võinud toimuda ka teisi sündmusi (näiteks sama objekti kustutamine), mida tuleb hookides arvesse võtta. Kui hook lõppes vea tõttu, siis kordab süsteem seda vaikimisi. korduvkutsumist kuni see õnnestub (seda käitumist saab muuta).
2. See eksportib metriika Prometheus'ele, millega on võimalik aru saada, kas shell-operator töötab, teada saada iga hooki vigade arvu ja praeguse järjekorra suuruse.

Kokkuvõttes selles osa ettekandest:

Lisandmoodulite installimine

Kubernetesega mugava töötamise jaoks mainiti ka lisandmoodulite installimise vajadust. Räägin sellest meie ettevõtte teekonna näitel, kuidas me seda praegu teeme.

Kubernetes'e kasutamine algas meil mitmest klastrist, kus ainsaks lisandmooduliks oli Ingress. Iga klastrisse tuli seda paigaldada erinevalt, ning tegime erinevate keskkondade jaoks mitmeid YAML-konfiguratsioone: bare metal, AWS…

Klastrite arv kasvas — koos suurenes ka konfiguratsioonide arv. Lisaks parandasime neid konfiguratsioone, mistõttu need muutusid üsna mitmekesisteks:

Ettevalmistamiseks alustasime skriptist (install-ingress.sh), mis võttis argumendiks klastrityübi, kuhu me oleme paigaldamas, genereeris vajaliku YAML-konfiguratsiooni ja edastas selle Kubernetesesse.

Lühidalt öeldes nägi meie edasine tee ja seotud arutlused välja sellised:

• YAML-konfiguratsioonide töötlemiseks on vajalik malligeneraator (esimestel etappidel oli see lihtne sed);
• klastrite arvu suurenedes tekkis vajadus automaatseks uuendamiseks (kõige varasem lahendus — panime skripti Git'i, uuendame seda cron'i abil ja käivitame);
• sarnast skripti nõuti ka Prometheusele (install-prometheus.sh), kuid see on tähelepanuväärne, kuna nõuab palju rohkem sisendandmeid ja nende säilitamist (ideaaljuhul — tsentraliseeritult klastris), lisaks olid mõned andmed (salasid) automaatselt genereeritavad:

  

• risk panna vale asi kasvavatesse klastritesse kasvas pidevalt, seega mõistsime, et installeerijatele (st kahe skripti: Ingressi ja Prometheuse jaoks) oli vajalik st stages (mitmed harud Git'is, mitmed cron'id nende uuendamiseks vastavalt: stabiilsetes või testklastrites);
• koos kubectl apply töötamine muutus keeruliseks, kuna see ei ole deklaratiivne ja oskab vaid objekte luua, kuid ei suuda nende staatust otsustada ega neid kustutada;
• puudusid mõned funktsioonid, mida me tol ajal täielikult ei rakendanud:
  • täielikku kontrolli klastrite uuendamise tulemuse üle,
  • automaatset teatud parameetrite määramist (sisseseadmise skriptide sisendeid) andmete põhjal, mida saab klastri (discovery) kaudu kätte saada,
  • loogilist arengut pideva avastamise kujul.

Kogu see kogunenud kogemus on rakendatud meie teises projektis — addon-operator.

Addon-operator

Selle põhielement on juba mainitud shell-operator. Kogu süsteem näeb välja järgmine:

Shell-operator'i hook'idele lisatakse:

• values hoidla,
• Helm-chart,
• komponent, mis jälgib values hoidlat ja — muudatuste korral — palub Helm'il välja lasta chart.

Nii saame reageerida sündmusele Kubernetes'is, käivitada hook'i ja sealt teha muudatusi hoidlas, mille järel chart uuesti välja antakse. Saadud skeemis eristame hulka hook'e ja chart'i üheks komponendiks, mida nimetame mooduliks:

Moduleid võib olla palju, ja nendele lisame globaalsete hook'ide, globaalsete väärtuste salvestusruumi ja komponendi, mis jälgib seda globaalset salvestusruumi.

Nüüd, kui Kubernetes'is midagi juhtub, saame sellele reageerida globaalse hook'i abil ja muuta midagi globaalsete väärtuste salvestusruumis. See muudatus märgatakse ja see käivitab kõigi klastris olevate moodulite uuendamise:

See skeem vastab kõigile lisandmoodulite installimise nõuetele, mis on eelnevalt välja toodud:

• Mallide loomise ja deklaratiivsuse eest vastutab Helm.
• Automaatse värskenduse küsimus lahendatakse globaalsete hook'ide abil, mis plaanipäraselt käivad registris ja, kui seal nähakse uut süsteemipilti, uuendavad selle (st "iseennast").
• Seadete salvestamine klastris on rakendatud läbi ConfigMap, kuhu on salvestatud algandmed salvestusruumide jaoks (käivitamisel laaditakse need salvestusruumidesse).
• Paroolide genereerimise, avastamise ja pideva avastamise probleemid on lahendatud hook'ide kaudu.
• Etapid on saavutatud tänu siltidele, mida Docker toetab otse välja.
• Tulemuse kontroll toimub meetrikate kaudu, mille abil saame aru staatusest.

Kogu see süsteem on teostatud ühe Go binaarprogrammina, mille nimi on addon-operator. Seetõttu tundub skeem lihtsam:

Selle skeemi peamine komponent on moodulite komplekt (tumedas hallis alt välja toodud). Nüüd suudame väikeste pingutustega kirjutada mooduli vajaliku lisafunktsiooni jaoks ja olla kindlad, et see installitakse igasse klastrisse, uuendatakse ja reageerib sealsetele vajalikele sündmustele.

Flant kasutab addon-operator üle 70 Kubernetes-klastri. Praegune staatus on alfaversioon. Praegu valmistame ette dokumentatsiooni, et välja anda beetaversioon, samal ajal on meie hoidlas näidised, mille põhjal suudate luua oma addon.

Kust saada addon-operatori mooduleid? Oma teegi avaldamine on meie jaoks järgmine samm, plaanime selle suvel teha.

Video ja slaidid

Esitlusvideo (~50 minutit):

Ettekande esitlus:

P.S.

Teised ettekanded meie blogis:

• «Andmebaasid ja Kubernetes»; (Dmitri Stolyarov; 8. november 2018 HighLoad++);
• «Jälgimine ja Kubernetes»; (Dmitri Stolyarov; 28. mai 2018 RootConf'is);
• «Parimad CI/CD praktikud Kubernetesega ja GitLabiga»; (Dmitri Stolyarov; 7. november 2017 HighLoad++);
• «Meie kogemus Kubernetesega väikestes projektides»; (Dmitri Stolyarov; 6. juuni 2017 RootConf'il).

Võib-olla huvitavad teid ka järgmised publikatsioonid:

• «Tutvustame shell-operatorit: Kubernetes'e operaatorite loomine on veelgi lihtsam».

Allikas: habr.com