🥇 A Kubernetes operátorai: állapotalapú alkalmazások futtatása

Probléma az állapotalapú alkalmazásokkal a Kubernetesben

Az alkalmazások és szolgáltatások konfigurálása, indítása és további méretezése egyszerű, ha állapotmentesnek minősített esetekről van szó, pl. adatok mentése nélkül. Kényelmes az ilyen szolgáltatásokat a Kubernetesben futtatni, annak szabványos API-jait használva, mert minden „dobozból” történik: szabványos konfigurációk szerint, különösebb részletek vagy varázslat nélkül.

Egyszerűen fogalmazva, a PHP/Ruby/Python háttérrendszer további öt példányának elindításához egy konténerfürtben mindössze ötször kell beállítania egy új szervert, és át kell másolnia a forrásokat. Mivel a forráskód és az init szkript is benne van a képben, az állapot nélküli alkalmazások méretezése teljesen elemivé válik. Ahogy a konténerek és a mikroszolgáltatás-architektúra rajongói jól tudják, a nehézség ott kezdődik állapotjelző alkalmazások, azaz adatperzisztenciával, például adatbázisokkal és gyorsítótárakkal (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Ez vonatkozik mind azokra a szoftverekre, amelyek önállóan valósítanak meg kvórumfürtöt (például Percona XtraDB és Cassandra), mind pedig olyan szoftverekre, amelyek külön felügyeleti segédprogramokat igényelnek (például Redis, MySQL, PostgreSQL...).

Nehézségek merülnek fel, mert a forráskód és a szolgáltatás elindítása már nem elegendő - további lépéseket kell végrehajtania. Legalább másolja át az adatokat és/vagy csatlakozzon a fürthöz. Pontosabban, ezek a szolgáltatások megkövetelik annak megértését, hogyan lehet megfelelően méretezni, frissíteni és újrakonfigurálni őket adatvesztés vagy átmeneti elérhetetlenség nélkül. Ezen igények figyelembe vételét „operatív tudásnak” nevezzük.

CoreOS üzemeltetők

A működési ismeretek "programozása" érdekében tavaly év végén a CoreOS projektet benyújtott „egy új szoftverosztály” a Kubernetes platformhoz – Operátorok (az angol „operation”, azaz „operation” szóból).

A Kubernetes alapvető képességeit használó és bővítő üzemeltetők (pl. StatefulSets, lásd az alábbi különbséget) lehetővé teszik a DevOps-szakemberek számára, hogy működési ismereteket adhassanak az alkalmazás kódjához.

Üzemeltető célja — biztosítson a felhasználónak egy API-t, amely lehetővé teszi több állapottartó alkalmazás entitás kezelését egy Kubernetes-fürtben, anélkül, hogy átgondolná, mi van a burkolat alatt (milyen adatok és mit kell tenni velük, milyen parancsokat kell még végrehajtani a fürt karbantartásához ). Valójában az Operator célja, hogy a lehető legnagyobb mértékben leegyszerűsítse a klaszteren belüli alkalmazással végzett munkát, automatizálva a korábban manuálisan megoldandó üzemeltetési feladatok végrehajtását.

Hogyan működnek az üzemeltetők

ReplicaSets A Kubernetes lehetővé teszi a futó podok kívánt számának megadását, a vezérlők pedig biztosítják számuk fenntartását (a podok létrehozásával és törlésével). Az üzemeltető hasonló módon működik, és olyan működési ismereteket ad hozzá egy szabványos Kubernetes-erőforráshoz és vezérlőhöz, amely lehetővé teszi további műveletek végrehajtását a szükséges számú alkalmazási entitás támogatása érdekében.

Miben különbözik ez attól StatefulSets, amelyet olyan alkalmazásokhoz terveztek, amelyek megkövetelik, hogy a fürt állapotalapú erőforrásokat biztosítson számukra, például adattárolást vagy statikus IP-címeket? Az ilyen alkalmazásokhoz az üzemeltetők használhatják StatefulSets (helyett ReplicaSets) alapként, felajánlásként további automatizálás: összeomlás esetén hajtsa végre a szükséges műveleteket, készítsen biztonsági másolatot, frissítse a konfigurációt stb.

Így hogy működik ez az egész? Az operátor egy menedzser démon, amely:

előfizet a Kubernetes esemény API-jára;
adatokat kap tőle a rendszerről (annak ReplicaSets, Pods, Szolgáltatások stb.);
ról kap adatokat Harmadik fél forrásai (lásd alább a példákat);
reagál a megjelenésre/változásra Harmadik fél forrásai (például a méret megváltoztatásához, a verzió módosításához stb.);
reagál a rendszer állapotában bekövetkezett változásokra (kb ReplicaSets, Pods, Szolgáltatások stb.);
legfontosabb:
1. felhívja a Kubernetes API-t, hogy hozzon létre mindent, amire szüksége van (megint a sajátját ReplicaSets, Pods, Szolgáltatások...),
2. némi varázslatot hajt végre (az egyszerűsítés kedvéért gondolhatjuk úgy, hogy az operátor maga is bemegy a pod-okba, és parancsokat hív meg például egy fürthöz való csatlakozáshoz vagy az adatformátum frissítéséhez egy verzió frissítésekor).

Valójában, amint az a képen látható, egy külön alkalmazás egyszerűen hozzáadódik a Kuberneteshez (egy szokásos bevetés с ReplicaSet), amelyet Operátornak neveznek. Egy közönséges hüvelyben él (általában csak egyben), és általában csak ezért felelős névtér. Ez az operátor alkalmazás implementálja az API-ját - bár nem közvetlenül, hanem keresztül Harmadik fél forrásai Kubernetesben.

Így, miután létrehoztuk névtér Üzemeltető, hozzátehetjük Harmadik fél forrásai.

Példa az etcd-re (a részletekért lásd alább):

apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
  name: example-etcd-cluster
spec:
  size: 3
  version: 3.1.0

Példa az Elasticsearch-re:

apiVersion: enterprises.upmc.com/v1
kind: ElasticsearchCluster
metadata:
  name: example-es-cluster
spec:
  client-node-replicas: 3
  master-node-replicas: 2
  data-node-replicas: 3
  zones:
  - us-east-1c
  - us-east-1d
  - us-east-1e
  data-volume-size: 10Gi
  java-options: "-Xms1024m -Xmx1024m"
  snapshot:
    scheduler-enabled: true
    bucket-name: elasticsnapshots99
    cron-schedule: "@every 2m"
  storage:
    type: gp2
    storage-class-provisioner: kubernetes.io/aws-ebs

Az üzemeltetőkre vonatkozó követelmények

A CoreOS megfogalmazta azokat a fő mintákat, amelyeket a mérnökök az üzemeltetőkön dolgoztak. Annak ellenére, hogy minden Operátor egyéni (egy adott alkalmazáshoz, annak sajátosságaival és igényeivel készült), létrehozásuknak egyfajta keretrendszeren kell alapulnia, amely a következő követelményeket támasztja:

A telepítést egyen keresztül kell elvégezni bevetés: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - és nem igényel további műveleteket.
Operátor telepítésekor a Kubernetesben új, harmadik féltől származó típust kell létrehozni (ThirdPartyResource). Alkalmazáspéldányok (fürtpéldányok) indításához és további kezeléséhez (verziók frissítése, átméretezés stb.) a felhasználó ezt a típust használja.
Amikor csak lehetséges, használd a Kubernetesbe épített primitíveket, mint pl Szolgáltatások и ReplicaSetsjól tesztelt és érthető kódot használni.
Az operátorok visszafelé kompatibilitását és a felhasználók által létrehozott erőforrások régebbi verzióinak támogatását igényli.
Ha az Operátort eltávolítják, magának az alkalmazásnak továbbra is változtatások nélkül kell működnie.
A felhasználóknak képesnek kell lenniük meghatározni a kívánt alkalmazásverziót, és meg kell szervezni az alkalmazásverzió frissítéseit. A szoftverfrissítések hiánya a működési és biztonsági problémák gyakori forrása, ezért az üzemeltetőknek segíteniük kell a felhasználókat ebben a kérdésben.
Az operátorokat olyan eszközzel kell tesztelni, mint a Chaos Monkey, amely azonosítja a podokban, konfigurációkban és a hálózatban előforduló lehetséges hibákat.

etcd Operátor

Üzemeltetői megvalósítási példa - etcd kezelő, előkészített e koncepció kihirdetésének napján. Az etcd fürt konfigurációja összetett lehet a kvórum fenntartása, a fürttagság újrakonfigurálása, biztonsági mentések létrehozása stb. miatt. Például egy etcd-fürt kézi méretezése azt jelenti, hogy létre kell hoznia egy DNS-nevet egy új fürttag számára, új etcd entitást kell indítania, és figyelmeztetnie kell a fürtöt az új tagról (etcdctl tag hozzáadása). Az Operator esetében a felhasználónak csak a klaszter méretét kell módosítania - minden más automatikusan megtörténik.

És mivel az etcd-t is CoreOS-ben hozták létre, teljesen logikus volt, hogy az Operator jelenik meg először. Hogyan dolgozik? Kezelői logika stb három összetevő határozza meg:

Figyeld meg. Az operátor a Kubernetes API segítségével figyeli a fürt állapotát.
Elemzés. Megkeresi az aktuális és a kívánt (a felhasználói konfiguráció által meghatározott) állapot közötti különbségeket.
Akció. Megoldja az észlelt eltéréseket az etcd és/vagy Kubernetes szolgáltatás API-k használatával.

Ennek a logikának a megvalósítására az Operatorban funkciókat készítettek elő Létrehozása/megsemmisítése (etcd fürttagok létrehozása és törlése) és Átméretezése (a klasztertagok számának változása). Működésének helyességét a Netflix Chaos Monkey hasonlatosságára létrehozott segédprogram segítségével ellenőrizték, azaz. stbd hüvelyek véletlenszerű megölése.

Az etcd teljes körű működéséhez az Operator további szolgáltatásokat biztosít: mentés (automatikus és a felhasználók számára láthatatlan biztonsági másolatok készítése - a konfigurációban elegendő meghatározni, hogy milyen gyakran és mennyit kell tárolni -, majd az adatok visszaállítása azokból) és frissítés (az etcd telepítések frissítése leállás nélkül).

Hogyan néz ki az operátorral való munka?

$ kubectl create -f https://coreos.com/operators/etcd/latest/deployment.yaml
$ kubectl create -f https://coreos.com/operators/etcd/latest/example-etcd-cluster.yaml
$ kubectl get pods
NAME                             READY     STATUS    RESTARTS   AGE
etcd-cluster-0000                1/1       Running   0          23s
etcd-cluster-0001                1/1       Running   0          16s
etcd-cluster-0002                1/1       Running   0          8s
etcd-cluster-backup-tool-rhygq   1/1       Running   0          18s

Az etcd Operator jelenlegi állapota béta verzió, amelyhez Kubernetes 1.5.3+ és etcd 3.0+ szükséges. A forráskód és a dokumentáció (beleértve a használati utasítást is) a címen érhető el GitHub.

Létrejött egy másik példa megvalósítás a CoreOS-ből - Prometheus operátor, de még mindig alfa verzióban van (nem minden tervezett funkció valósult meg).

Állapot és kilátások

5 hónap telt el a Kubernetes Operators bejelentése óta. Még mindig csak két megvalósítás érhető el a hivatalos CoreOS tárolóban (az etcd és a Prometheus számára). Mindkettő még nem érte el a stabil verzióját, de az elkövetéseket naponta megfigyelik.

A fejlesztők olyan jövőt képzelnek el, amelyben a felhasználók a Postgres Operatorokat, a Cassandra Operatorokat vagy a Redis Operatorokat telepítik Kubernetes-fürtjeikre, és olyan egyszerűen dolgozhatnak ezen alkalmazások méretezhető entitásaival, mint ma az állapot nélküli webalkalmazások replikáinak telepítése. Első Operátorok harmadik féltől származó fejlesztőktől tényleg elkezdett megjelenni:

Elasticsearch operátor az UPMC Enterprises-tól;
PostgreSQL operátor a Crunchy Data-tól (bejelentve 2017. március végén);
Bástya kezelő egy Ceph alapú elosztott adattároló rendszer szerzőitől (a Rook alfa státuszban van);
Openstack operátorok az SAP CCloudból.

A legnagyobb európai ingyenes szoftverkonferencián, a FOSDEM-en, amelyre 2017 februárjában került sor Brüsszelben, Josh Wood, a CoreOS munkatársa bejelentette, hogy Operators jelentés (a linken elérhető videó!), aminek hozzá kell járulnia a koncepció népszerűségének növekedéséhez a szélesebb Open Source közösségben.

PS Köszönjük érdeklődését a cikk iránt! Iratkozzon fel hubunkra, hogy ne maradjunk le a DevOps és a GNU/Linux rendszeradminisztrációról szóló új anyagokról és receptekről – rendszeresen közzétesszük!

Forrás: will.com

Kubernetes operátorok: állapottartó alkalmazások futtatása