Problém se stavovými aplikacemi v Kubernetes
Konfigurace, spouštění a další škálování aplikací a služeb je snadné, pokud jde o případy klasifikované jako bezstavové, tzn. bez ukládání dat. Je vhodné spouštět takové služby v Kubernetes pomocí jeho standardních API, protože vše se děje „z krabice“: podle standardních konfigurací, bez jakýchkoliv specifik nebo magie.
Jednoduše řečeno, ke spuštění dalších pěti kopií backendu v PHP/Ruby/Pythonu v clusteru kontejnerů stačí 5x nastavit nový server a zkopírovat zdroje. Vzhledem k tomu, že zdrojový kód i init skript jsou v obraze, stává se škálování bezstavové aplikace zcela základní. Jak fanoušci kontejnerů a architektury mikroslužeb dobře vědí, obtíž začíná stavové aplikace, tj. s perzistencí dat, jako jsou databáze a cache (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). To se týká jak softwaru, který nezávisle implementuje cluster kvora (například Percona XtraDB a Cassandra), tak softwaru, který vyžaduje samostatné nástroje pro správu (jako je Redis, MySQL, PostgreSQL...).
Potíže nastávají, protože zdrojový kód a spuštění služby již nestačí – je potřeba provést několik dalších kroků. Minimálně zkopírujte data a/nebo se připojte ke clusteru. Přesněji řečeno, tyto služby vyžadují pochopení toho, jak je správně škálovat, aktualizovat a překonfigurovat bez ztráty dat nebo dočasné nedostupnosti. Zohlednění těchto potřeb se nazývá „provozní znalosti“.
Operátoři CoreOS
Aby bylo možné „naprogramovat“ provozní znalosti, koncem loňského roku projekt CoreOS „nová třída softwaru“ pro platformu Kubernetes – Operátoři (z anglického „operation“, tedy „operace“).
Operátoři využívající a rozšiřující základní možnosti Kubernetes (vč. Stavové sady, viz rozdíl níže) umožňují specialistům DevOps přidávat provozní znalosti do kódu aplikace.
Účel operátora — poskytnout uživateli rozhraní API, které vám umožní spravovat více stavových aplikačních entit v clusteru Kubernetes, aniž byste přemýšleli o tom, co je pod kapotou (jaká data a co s nimi dělat, jaké příkazy je ještě třeba provést pro údržbu clusteru ). Operátor je ve skutečnosti navržen tak, aby co nejvíce zjednodušil práci s aplikací v rámci clusteru a automatizoval provádění provozních úloh, které bylo dříve nutné řešit ručně.
Jak operátoři pracují
ReplicaSets Kubernetes umožňuje zadat požadovaný počet spuštěných podů a řadiče zajistí, že jejich počet bude zachován (vytvořením a odstraněním podů). Operátor funguje podobným způsobem a přidává sadu provozních znalostí ke standardnímu prostředku a řadiči Kubernetes, který vám umožňuje provádět další akce na podporu požadovaného počtu entit aplikace.
Jak se to liší od Stavové sady, určený pro aplikace, které vyžadují, aby jim cluster poskytoval stavové prostředky, jako je úložiště dat nebo statické IP adresy? Pro takové aplikace mohou Operátoři použít Stavové sady (místo ReplicaSets) jako základ, nabídka další automatizace: provádět potřebné akce v případě selhání, zálohovat, aktualizovat konfiguraci atd.
To znamená, jak to všechno funguje? Operátor je manažerský démon, který:
- přihlásí se k odběru API událostí v Kubernetes;
- přijímá od něj data o systému (o jeho ReplicaSets, Lusky, Služby a tak dále.);
- přijímá data o Zdroje třetích stran (viz příklady níže);
- reaguje na vzhled/změnu Zdroje třetích stran (například změnit velikost, změnit verzi atd.);
- reaguje na změny stavu systému (o jeho ReplicaSets, Lusky, Služby a tak dále.);
- nejdůležitější:
- zavolá rozhraní Kubernetes API, aby vytvořilo vše, co potřebuje (opět své vlastní ReplicaSets, Lusky, Služby...),
- provádí nějaká kouzla (pro zjednodušení si můžete myslet, že Operátor jde do samotných modulů a volá příkazy, například pro připojení ke clusteru nebo pro upgrade datového formátu při aktualizaci verze).
Ve skutečnosti, jak je vidět z obrázku, je do Kubernetes jednoduše přidána samostatná aplikace (běžná Rozvinutí с Sada replik), která se nazývá Provozovatel. Žije v obyčejném lusku (většinou jen jednom) a zpravidla zodpovídá pouze za něj Namespace. Tato operátorská aplikace implementuje své API – i když ne přímo, ale prostřednictvím Zdroje třetích stran v Kubernetes.
Takže poté, co jsme vytvořili v Namespace Operátor, můžeme k tomu přidat Zdroje třetích stran.
Příklad pro etcd (podrobnosti viz níže):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Příklad pro Elasticsearch:
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
Požadavky na operátory
CoreOS formuloval hlavní vzory získané inženýry při práci na Operatorech. Navzdory skutečnosti, že všichni Operátoři jsou individuální (vytvořeni pro konkrétní aplikaci s vlastními vlastnostmi a potřebami), jejich tvorba musí vycházet z jakéhosi rámce, který klade následující požadavky:
- Instalace musí být provedena přes jeden Rozvinutí: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - a nevyžadují další akce.
- Při instalaci operátora v Kubernetes je třeba vytvořit nový typ třetí strany (zdroj třetí strany). Tento typ uživatel využije pro spouštění instancí aplikací (instancí clusteru) a jejich další správu (aktualizace verzí, změna velikosti atd.).
- Kdykoli je to možné, měli byste používat primitiva zabudovaná do Kubernetes, jako je např Služby и ReplicaSetspoužívat dobře otestovaný a srozumitelný kód.
- Vyžaduje zpětnou kompatibilitu operátorů a podporu starších verzí zdrojů vytvořených uživatelem.
- Pokud je Operátor odebrán, samotná aplikace by měla nadále fungovat beze změn.
- Uživatelé by měli být schopni definovat požadovanou verzi aplikace a organizovat aktualizace verzí aplikace. Nedostatek aktualizací softwaru je častým zdrojem provozních a bezpečnostních problémů, takže operátoři musí uživatelům v této záležitosti pomáhat.
- Operátoři by měli být testováni pomocí nástroje jako Chaos Monkey, který identifikuje potenciální selhání modulů, konfigurací a sítě.
operátor etcd
Příklad implementace operátora - operátor etcd, v den vyhlášení této koncepce. Konfigurace clusteru etcd může být složitá kvůli potřebě udržovat kvorum, potřebě překonfigurovat členství v clusteru, vytvářet zálohy atd. Například ruční škálování clusteru etcd znamená, že musíte vytvořit název DNS pro nového člena clusteru, spustit novou entitu etcd a upozornit cluster na nového člena (etcdctl člen přidat). V případě Operátora bude uživateli stačit pouze změnit velikost clusteru – vše ostatní proběhne automaticky.
A protože etcd byl vytvořen také v CoreOS, bylo celkem logické, že se nejprve objevil jeho Operátor. Jak pracuje? Logika operátora atd je určeno třemi složkami:
- Pozorovat. Operátor sleduje stav clusteru pomocí Kubernetes API.
- Analýza. Vyhledá rozdíly mezi aktuálním stavem a požadovaným (definovaným uživatelskou konfigurací).
- Akce. Řeší zjištěné rozdíly pomocí rozhraní API služby etcd a/nebo Kubernetes.
Pro implementaci této logiky byly v Operátoru připraveny funkce Vytvořit/Zničit (vytváření a mazání členů clusteru etcd) a Změna velikosti (změna počtu členů klastru). Správnost jeho fungování byla kontrolována pomocí utility vytvořené v podobizně Chaos Monkey od Netflixu, tzn. zabíjení etcd podů náhodně.
Pro plný provoz etcd poskytuje Operátor další funkce: Zálohování (automatické a pro uživatele neviditelné vytváření záložních kopií - v konfiguraci stačí určit, jak často je vytvářet a kolik ukládat - a následná obnova dat z nich) a Aktualizujte (aktualizace instalací etcd bez prostojů).
Jak vypadá spolupráce s operátorem?
$ 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
Aktuální stav operátora etcd je beta verze, která ke spuštění vyžaduje Kubernetes 1.5.3+ a etcd 3.0+. Zdrojový kód a dokumentace (včetně návodu k použití) jsou k dispozici na .
Byla vytvořena další ukázková implementace z CoreOS - , ale stále je v alfa verzi (nebyly implementovány všechny plánované funkce).
Stav a vyhlídky
Od oznámení Kubernetes Operators uplynulo 5 měsíců. V oficiálním repozitáři CoreOS jsou stále k dispozici pouze dvě implementace (pro etcd a Prometheus). Oba ještě nedosáhli své stabilní verze, ale commity jsou sledovány denně.
Vývojáři si představují „budoucnost, ve které uživatelé instalují Postgres Operators, Cassandra Operators nebo Redis Operators na své clustery Kubernetes a budou pracovat se škálovatelnými entitami těchto aplikací stejně snadno, jako je dnes nasazení replik bezstavových webových aplikací. První Operátoři od vývojářů třetích stran se opravdu začalo objevovat:
- od UPMC Enterprises;
- od Crunchy Data (oznámeno koncem března 2017);
- od autorů distribuovaného systému ukládání dat založeného na Ceph (Rook je ve stavu alfa);
- ze SAP CCloud.
Na největší evropské konferenci svobodného softwaru FOSDEM, která se konala v únoru 2017 v Bruselu, oznámil Josh Wood z CoreOS Operátory v (video je k dispozici na odkazu!), což by mělo přispět k růstu popularity tohoto konceptu v širší Open Source komunitě.
PS Děkujeme za váš zájem o článek! Přihlaste se k odběru našeho centra, aby vám neunikly nové materiály a recepty na správu systému DevOps a GNU/Linux – budeme je pravidelně zveřejňovat!
Zdroj: www.habr.com