🥇Rozširovanie a dopĺňanie Kubernetes (recenzia a videoreportáž)

8. apríla na konferencii Saint HighLoad++ 2019, v rámci sekcie “DevOps and Operations” odznela správa “Rozširovanie a dopĺňanie Kubernetes”, na tvorbe ktorej sa podieľali traja zamestnanci spoločnosti Flant. Hovoríme v ňom o početných situáciách, v ktorých sme chceli rozšíriť a doplniť možnosti Kubernetes, no nenašli sme pre ne hotové a jednoduché riešenie. Máme potrebné riešenia v podobe Open Source projektov, ktorým je venovaný aj tento prejav.

Tradične s radosťou predstavujeme video zo správy (50 minút, oveľa informatívnejšie ako článok) a hlavné zhrnutie v textovej podobe. Choď!

Jadro a doplnky v K8

Kubernetes mení odvetvie a prístupy k správe, ktoré sú už dlho zavedené:

Jeho vďaka abstrakcie, už neoperujeme s pojmami ako nastavenie konfigurácie alebo spustenie príkazu (Chef, Ansible...), ale využívame zoskupovanie kontajnerov, služieb a pod.
Môžeme pripraviť aplikácie bez toho, aby sme premýšľali o nuansách konkrétne miesto, na ktorom bude spustený: holý kov, cloud jedného z poskytovateľov a pod.
S K8 ste nikdy neboli dostupnejší osvedčené postupy o organizačnej infraštruktúre: techniky škálovania, samoliečenie, odolnosť voči chybám atď.

Všetko však, samozrejme, nie je také hladké: Kubernetes tiež priniesol svoje vlastné nové výzvy.

Kubernetes nie je kombajn, ktorý rieši všetky problémy všetkých užívateľov. jadro Kubernetes je zodpovedný iba za súbor minimálnych potrebných funkcií, ktoré sú v ňom prítomné každý klaster:

Jadro Kubernetes definuje základnú sadu primitív na zoskupovanie kontajnerov, správu návštevnosti atď. Podrobnejšie sme o nich hovorili v nahlásiť pred 2 rokmi.

Na druhej strane K8s ponúka skvelé príležitosti na rozšírenie dostupných funkcií, ktoré pomáhajú zatvoriť ostatných - špecifické — potreby používateľov. Za pridania do Kubernetes sú zodpovední správcovia klastra, ktorí musia nainštalovať a nakonfigurovať všetko potrebné, aby sa ich klaster „dostal do správnej formy“ [aby sa vyriešili ich špecifické problémy]. O aké doplnky ide? Pozrime sa na niekoľko príkladov.

Príklady doplnkov

Po nainštalovaní Kubernetes nás môže prekvapiť, že sieť, ktorá je taká potrebná na interakciu modulov v rámci uzla aj medzi uzlami, nefunguje sama o sebe. Jadro Kubernetes nezaručuje potrebné pripojenia, ale určuje sieť rozhranie (CNI) pre doplnky tretích strán. Musíme nainštalovať jeden z týchto doplnkov, ktorý bude zodpovedný za konfiguráciu siete.

Blízkym príkladom sú riešenia ukladania dát (lokálny disk, sieťové blokové zariadenie, Ceph...). Spočiatku boli v jadre, ale s príchodom CSI situácia sa mení na niečo podobné, ako už bolo opísané: rozhranie je v Kubernetes a jeho implementácia je v moduloch tretích strán.

Medzi ďalšie príklady patria:

Ingress-ovládače (pozri ich recenziu v náš nedávny článok).
cert-manager:
prevádzkovatelia je celá trieda doplnkov (kam patrí aj spomínaný cert-manager), definujú primitíva(y) a controller(y). Logika ich práce je obmedzená len našou predstavivosťou a umožňuje nám premeniť hotové komponenty infraštruktúry (napríklad DBMS) na primitíva, s ktorými sa pracuje oveľa jednoduchšie (ako so sadou kontajnerov a ich nastavením). Bolo napísaných veľké množstvo operátorov – aj keď mnohí z nich ešte nie sú pripravení na výrobu, je to len otázka času:
Metriky - ďalšia ilustrácia toho, ako Kubernetes oddelil rozhranie (Metrics API) od implementácie (doplnky tretích strán ako adaptér Prometheus, agent klastra Datadog...).
pre monitorovanie a štatistiky, kde sú v praxi nielen potrebné Prometheus a Grafana, ale aj kube-state-metrics, node-exporter atď.

A to nie je úplný zoznam doplnkov... Napríklad u firmy Flant, ktorú momentálne inštalujeme 29 dodatkov (všetky vytvárajú spolu 249 objektov Kubernetes). Jednoducho povedané, nemôžeme vidieť život klastra bez prídavkov.

automatizácia

Operátory sú navrhnuté tak, aby automatizovali rutinné operácie, s ktorými sa stretávame každý deň. Tu sú príklady zo skutočného života, pre ktoré by bolo napísanie operátora vynikajúcim riešením:

Pre aplikáciu existuje súkromný (t. j. vyžadujúci prihlásenie) register s obrázkami. Predpokladá sa, že každý modul má priradené špeciálne tajomstvo, ktoré umožňuje autentifikáciu v registri. Našou úlohou je zabezpečiť, aby sa toto tajomstvo našlo v mennom priestore, aby si moduly mohli stiahnuť obrázky. Môže existovať veľa aplikácií (každá z nich potrebuje tajomstvo) a je užitočné pravidelne aktualizovať samotné tajomstvá, takže odpadá možnosť ručného rozloženia tajomstiev. Tu prichádza na pomoc operátor: vytvoríme ovládač, ktorý počká, kým sa objaví menný priestor a na základe tejto udalosti pridá do menného priestoru tajomstvo.
V predvolenom nastavení je prístup z modulov na internet zakázaný. Niekedy to však môže byť potrebné: je logické, aby mechanizmus prístupových povolení fungoval jednoducho, bez toho, aby vyžadoval špecifické zručnosti, napríklad prítomnosťou určitého označenia v mennom priestore. Ako nám tu môže operátor pomôcť? Vytvorí sa ovládač, ktorý čaká, kým sa štítok objaví v mennom priestore, a pridá príslušnú politiku pre prístup na internet.
Podobná situácia: Predpokladajme, že potrebujeme pridať určité nakaziť, ak má podobný štítok (s nejakou predponou). Akcie s operátorom sú zrejmé...

V každom klastri musia byť vyriešené rutinné úlohy a správne to je možné vykonať pomocou operátorov.

Zhrnutím všetkých opísaných príbehov sme dospeli k záveru, že pre pohodlnú prácu v Kubernetes potrebujete: A) nainštalovať doplnky, b) rozvíjať operátorov (na riešenie každodenných úloh správcu).

Ako napísať vyhlásenie pre Kubernetes?

Vo všeobecnosti je schéma jednoduchá:

... ale potom sa ukáže, že:

Kubernetes API je pomerne netriviálna vec, ktorej zvládnutie zaberie veľa času;
programovanie tiež nie je pre každého (jazyk Go bol vybraný ako preferovaný jazyk, pretože preň existuje špeciálny rámec - SDK operátora);
Podobná situácia je aj so samotným rámcom.

Zrátané a podčiarknuté: napísať ovládač (operátor) musí míňať značné zdroje študovať materiál. To by bolo opodstatnené pre „veľkých“ operátorov – povedzme pre MySQL DBMS. Ale ak si spomenieme na vyššie popísané príklady (odhaľovanie tajomstiev, pristupovanie k podom na internet...), ktoré tiež chceme robiť správne, potom pochopíme, že vynaložené úsilie preváži výsledok, ktorý teraz potrebujeme:

Vo všeobecnosti vzniká dilema: minúť veľa prostriedkov a nájsť ten správny nástroj na písanie vyhlásení, alebo to urobiť staromódnym spôsobom (ale rýchlo). Aby sme to vyriešili - aby sme našli kompromis medzi týmito extrémami - vytvorili sme vlastný projekt: shell-operátor (pozri aj jeho nedávne oznámenie na náboji).

Shell-operátor

ako pracuje? Klaster má modul obsahujúci binárny súbor Go s operátorom shellu. Vedľa je sada háčiky (podrobnejšie o nich - pozri nižšie). Samotný operátor shellu sa prihlási k určitým vývoj v Kubernetes API, pri výskyte ktorého spustí zodpovedajúce háky.

Ako shell-operátor vie, ktoré háky má zavolať na ktoré udalosti? Tieto informácie prenášajú operátorovi shellu samotné háky a robia to veľmi jednoducho.

Hák je Bash skript alebo akýkoľvek iný spustiteľný súbor, ktorý akceptuje jeden argument --config a odpovie pomocou JSON. Ten určuje, ktoré objekty sú pre neho zaujímavé a na ktoré udalosti (pre tieto objekty) by sa malo reagovať:

Implementáciu na shell-operátorovi ukážem na jednom z našich príkladov – rozklad tajomstiev pre prístup do súkromného registra s obrázkami aplikácií. Pozostáva z dvoch etáp.

Cvičenie: 1. Napíšte háčik

Po prvé, v háku spracujeme --config, čo naznačuje, že nás zaujímajú menné priestory a konkrétne moment ich vytvorenia:

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

Ako by vyzerala logika? Tiež celkom jednoduché:

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

Prvým krokom je zistiť, ktorý menný priestor bol vytvorený, a druhým je jeho vytvorenie pomocou kubectl tajomstvo pre tento menný priestor.

Cvičenie: 2. Skladanie obrazu

Zostáva len odovzdať vytvorený hák operátorovi shellu - ako to urobiť? Samotný shell-operátor prichádza ako obrázok Docker, takže našou úlohou je pridať háčik do špeciálneho adresára v tomto obrázku:

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

Zostáva len zostaviť a zatlačiť:

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

Posledným krokom je nasadenie obrázka do klastra. Aby sme to urobili, napíšme rozvinutie:

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

Je potrebné venovať pozornosť dvom bodom:

označenie novovytvoreného obrázka;
Toto je systémový komponent, ktorý (minimálne) potrebuje práva na odber udalostí v Kubernetes a na prideľovanie tajomstiev priestorom názvov, takže pre háčik vytvoríme ServiceAccount (a súbor pravidiel).

Výsledok - vyriešili sme náš problém príbuzných pre Kubernetes spôsobom, ktorý vytvára operátora na rozklad tajomstiev.

Ďalšie funkcie operátora shellu

Ak chcete obmedziť objekty zvoleného typu, s ktorými bude háčik pracovať, dajú sa filtrovať, výberom podľa určitých štítkov (alebo pomocou matchExpressions):

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

Za predpokladu deduplikačný mechanizmus, ktorý – pomocou jq filtra – umožňuje konvertovať veľké objekty JSON na malé, kde zostanú len tie parametre, ktoré chceme sledovať kvôli zmenám.

Keď sa zavolá hák, operátor shellu ho prejde objektové dáta, ktorý je možné použiť na akúkoľvek potrebu.

Udalosti, ktoré spúšťajú háky, nie sú obmedzené na udalosti Kubernetes: operátor shell poskytuje podporu volanie háčikov podľa času (podobne ako crontab v tradičnom plánovači), ako aj špeciálna udalosť na začiatku. Všetky tieto udalosti je možné kombinovať a priradiť k rovnakému háku.

A ďalšie dve funkcie operátora shellu:

Funguje to asynchrónne. Od prijatia udalosti Kubernetes (napríklad vytvárania objektu) sa v klastri mohli vyskytnúť ďalšie udalosti (napríklad vymazanie rovnakého objektu) a háčiky s tým musia počítať. Ak bol hák vykonaný s chybou, potom bude predvolene znovu zavolať až do úspešného dokončenia (toto správanie je možné zmeniť).
Vyváža sa metriky pre Prometheus, pomocou ktorého môžete pochopiť, či funguje operátor shellu, zistiť počet chýb pre každý háčik a aktuálnu veľkosť frontu.

Ak chcete zhrnúť túto časť správy:

Inštalácia doplnkov

Pre pohodlnú prácu s Kubernetes bola spomenutá aj nutnosť inštalácie doplnkov. Poviem vám o tom na príklade cesty našej spoločnosti k tomu, ako to robíme teraz.

S Kubernetes sme začali pracovať s niekoľkými klastrami, ku ktorým jediným doplnkom bol Ingress. V každom klastri ho bolo potrebné nainštalovať inak a urobili sme niekoľko konfigurácií YAML pre rôzne prostredia: holý kov, AWS...

Čím viac klastrov, tým viac konfigurácií. Okrem toho sme vylepšili samotné tieto konfigurácie, v dôsledku čoho sa stali dosť heterogénnymi:

Aby sme dali všetko do poriadku, začali sme so scenárom (install-ingress.sh), ktorý si ako argument zobral typ klastra, do ktorého nasadíme, vygeneroval potrebnú konfiguráciu YAML a zaviedol ju do Kubernetes.

Stručne povedané, naša ďalšia cesta a úvahy s ňou spojené boli nasledovné:

na prácu s konfiguráciami YAML je potrebný nástroj šablón (v prvých fázach je to jednoduché);
s nárastom počtu klastrov prišla potreba automatickej aktualizácie (najskoršie riešenie bolo vložiť skript do Gitu, aktualizovať ho pomocou cronu a spustiť);
podobný skript bol potrebný pre Prometheus (install-prometheus.sh), je však pozoruhodný tým, že vyžaduje oveľa viac vstupných údajov, ako aj ich uloženie (v dobrom slova zmysle - centralizované a v klastri) a niektoré údaje (heslá) je možné generovať automaticky:
riziko zavedenia niečoho nesprávneho do rastúceho počtu klastrov neustále rástlo, takže sme si uvedomili, že inštalatéri (t. j. dva skripty: pre Ingress a Prometheus) bolo potrebné staging (niekoľko vetiev v Gite, niekoľko cronov na ich aktualizáciu v zodpovedajúcich: stabilných alebo testovacích klastroch);
с kubectl apply začalo sa s ním ťažko pracovať, pretože nie je deklaratívne a môže objekty iba vytvárať, ale nie rozhodovať o ich stave/odstraňovať ich;
Chýbali nám niektoré funkcie, ktoré sme v tom čase vôbec neimplementovali:
- plnú kontrolu nad výsledkom aktualizácií klastra,
- automatické určenie niektorých parametrov (vstup pre inštalačné skripty) na základe údajov, ktoré je možné získať z klastra (discovery),
- jeho logický vývoj v podobe neustáleho objavovania.

Všetky tieto nahromadené skúsenosti sme implementovali v rámci nášho ďalšieho projektu - operátor doplnku.

Operátor doplnkov

Jeho základom je už spomínaný shell-operátor. Celý systém vyzerá takto:

K háčikom operátora shellu sa pridáva toto:

ukladanie hodnôt,
Tabuľka kormidla,
komponent, ktorý monitoruje ukladanie hodnôt a - v prípade akýchkoľvek zmien - požiada Helma, aby pretočil graf.

Môžeme teda reagovať na udalosť v Kubernetes, spustiť hák a z tohto háčika môžeme vykonať zmeny v úložisku, po ktorých sa graf znova stiahne. Vo výslednom diagrame oddelíme množinu háčikov a graf do jedného komponentu, ktorý nazývame modul:

Modulov môže byť veľa a k nim pridáme globálne háčiky, globálny ukladací priestor hodnôt a komponent, ktorý tento globálny obchod monitoruje.

Teraz, keď sa niečo stane v Kubernetes, môžeme na to reagovať pomocou globálneho háku a zmeniť niečo v globálnom obchode. Táto zmena bude zaznamenaná a spôsobí uvedenie všetkých modulov v klastri:

Táto schéma spĺňa všetky vyššie uvedené požiadavky na inštaláciu doplnkov:

Helm je zodpovedný za tvorbu šablón a deklaratívnosť.
Problém s automatickou aktualizáciou bol vyriešený pomocou globálneho háku, ktorý ide do registra podľa plánu a ak tam uvidí nový obraz systému, spustí ho (t. j. „sám“).
Ukladanie nastavení v klastri je implementované pomocou ConfigMap, ktorý obsahuje primárne dáta pre úložiská (pri štarte sa načítajú do úložísk).
Problémy s generovaním hesla, objavovaním a priebežným objavovaním sa riešili pomocou hákov.
Staging je dosiahnutý vďaka tagom, ktoré Docker podporuje hneď po vybalení.
Výsledok je monitorovaný pomocou metrík, pomocou ktorých môžeme pochopiť stav.

Celý tento systém je implementovaný vo forme jedného binárneho súboru v Go, ktorý sa nazýva addon-operátor. Vďaka tomu bude diagram vyzerať jednoduchšie:

Hlavným komponentom v tomto diagrame je sada modulov (dole zvýraznené sivou farbou). Teraz môžeme s trochou úsilia napísať modul pre požadovaný doplnok a mať istotu, že sa nainštaluje do každého klastra, bude sa aktualizovať a reagovať na udalosti, ktoré v klastri potrebuje.

"Ploché" použitie operátor doplnku na 70+ klastroch Kubernetes. Momentálna situácia - alfa verzia. Teraz pripravujeme dokumentáciu na vydanie beta verzie, ale zatiaľ v úložisku dostupné príklady, na základe ktorej si môžete vytvoriť svoj vlastný doplnok.

Kde môžem získať moduly pre operátora doplnkov? Vydanie našej knižnice je pre nás ďalšou etapou, plánujeme to urobiť v lete.

Videá a diapozitívy

Video z predstavenia (~50 minút):

Prezentácia správy:

PS

Ďalšie správy na našom blogu:

«Databázy a Kubernetes»; (Dmitrij Stolyarov; 8. novembra 2018 na HighLoad++);
«Monitoring a Kubernetes»; (Dmitrij Stolyarov; 28. mája 2018 na RootConf);
«CI/CD Best Practices s Kubernetes a GitLab»; (Dmitrij Stolyarov; 7. novembra 2017 na HighLoad++);
«Naše skúsenosti s Kubernetes v malých projektoch»; (Dmitrij Stolyarov; 6. júna 2017 na RootConf).

Mohli by vás zaujímať aj nasledujúce publikácie:

«Predstavujeme shell-operátor: vytváranie operátorov pre Kubernetes je teraz jednoduchšie".

Zdroj: hab.com

Rozšírenie a doplnenie Kubernetes (prehľad a video správa)