Problém so stavovými aplikáciami v Kubernetes
Konfigurácia, spúšťanie a ďalšie škálovanie aplikácií a služieb je jednoduché, pokiaľ ide o prípady klasifikované ako bezstavové, t.j. bez uloženia údajov. Je vhodné spúšťať takéto služby v Kubernetes pomocou jeho štandardných rozhraní API, pretože všetko sa deje „po vybalení“: podľa štandardných konfigurácií, bez akýchkoľvek špecifík alebo mágie.
Jednoducho povedané, na spustenie ďalších piatich kópií backendu v PHP/Ruby/Pythone v klastri kontajnerov stačí nastaviť nový server 5-krát a skopírovať zdroje. Keďže zdrojový kód aj init skript sú v obrázku, škálovanie bezstavovej aplikácie sa stáva úplne elementárne. Ako fanúšikovia kontajnerov a architektúry mikroslužieb dobre vedia, problém začína stavové aplikácie, t.j. s perzistenciou údajov, ako sú databázy a vyrovnávacie pamäte (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Týka sa to softvéru, ktorý nezávisle implementuje klaster kvór (napríklad Percona XtraDB a Cassandra), ako aj softvéru, ktorý vyžaduje samostatné nástroje na správu (napríklad Redis, MySQL, PostgreSQL...).
Ťažkosti vznikajú, pretože zdrojový kód a spustenie služby už nestačia – je potrebné vykonať niekoľko ďalších krokov. Minimálne skopírujte údaje a/alebo sa pripojte ku klastru. Presnejšie povedané, tieto služby vyžadujú pochopenie toho, ako ich správne škálovať, aktualizovať a prekonfigurovať bez straty údajov alebo dočasnej nedostupnosti. Zohľadnenie týchto potrieb sa nazýva „operačné znalosti“.
Operátori CoreOS
S cieľom „naprogramovať“ prevádzkové znalosti koncom minulého roka projekt CoreOS „nová trieda softvéru“ pre platformu Kubernetes – Operátori (z anglického „operation“, t. j. „operácia“).
Operátori využívajúci a rozširujúci základné možnosti Kubernetes (vrátane. Stavové sady, pozri rozdiel nižšie) umožňujú špecialistom DevOps pridať do kódu aplikácie prevádzkové znalosti.
Účel operátora — poskytnúť používateľovi rozhranie API, ktoré vám umožní spravovať viacero stavových aplikačných entít v klastri Kubernetes bez premýšľania o tom, čo je pod kapotou (aké údaje a čo s nimi robiť, aké príkazy je ešte potrebné vykonať na údržbu klastra ). Operátor je v skutočnosti navrhnutý tak, aby čo najviac zjednodušil prácu s aplikáciou v rámci klastra a zautomatizoval vykonávanie prevádzkových úloh, ktoré sa predtým museli riešiť manuálne.
Ako pracujú operátori
ReplicaSets Kubernetes vám umožňuje určiť požadovaný počet spustených modulov a ovládače zaisťujú zachovanie ich počtu (vytváraním a odstraňovaním modulov). Operátor funguje podobným spôsobom a pridáva k štandardnému zdroju a ovládaču Kubernetes sadu prevádzkových znalostí, ktoré vám umožňujú vykonávať ďalšie akcie na podporu požadovaného počtu aplikačných entít.
Ako sa to líši od Stavové sady, určený pre aplikácie, ktoré vyžadujú, aby im klaster poskytoval stavové zdroje, ako sú úložisko dát alebo statické adresy IP? Pre takéto aplikácie môžu operátori použiť Stavové sady (namiesto ReplicaSets) ako základ, ponuka dodatočná automatizácia: vykonať potrebné akcie v prípade zlyhania, zálohovať, aktualizovať konfiguráciu atď.
Takže, ako to všetko funguje? Operátor je manažérsky démon, ktorý:
- prihlási sa na odber API udalostí v Kubernetes;
- prijíma z neho údaje o systéme (o jeho ReplicaSets, struky, Služby atď.);
- prijíma údaje o Zdroje tretích strán (pozri príklady nižšie);
- reaguje na vzhľad/zmenu Zdroje tretích strán (napríklad zmeniť veľkosť, zmeniť verziu atď.);
- reaguje na zmeny stavu systému (o jeho ReplicaSets, struky, Služby atď.);
- najdôležitejšie:
- vyzýva rozhranie Kubernetes API, aby vytvorilo všetko, čo potrebuje (opäť svoje vlastné ReplicaSets, struky, Služby...),
- vykonáva nejakú mágiu (pre zjednodušenie si môžete myslieť, že operátor ide do samotných modulov a volá príkazy, napríklad na pripojenie ku klastri alebo na aktualizáciu formátu údajov pri aktualizácii verzie).
V skutočnosti, ako je zrejmé z obrázku, sa do Kubernetes jednoducho pridá samostatná aplikácia (bežná rozvinutie с Sada replík), ktorý sa nazýva Prevádzkovateľ. Žije v obyčajnom struku (zvyčajne len v jednom) a spravidla je zodpovedný iba zaň namespace. Táto operátorská aplikácia implementuje svoje API – aj keď nie priamo, ale prostredníctvom Zdroje tretích strán v Kubernetes.
Takže potom, čo sme vytvorili v namespace Operátor, môžeme k tomu pridať Zdroje tretích strán.
Príklad pre atď (podrobnosti nájdete nižšie):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Príklad pre 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žiadavky na operátorov
CoreOS sformuloval hlavné vzory získané inžiniermi pri práci na operátoroch. Napriek tomu, že všetci operátori sú individuálni (vytvorení pre konkrétnu aplikáciu s vlastnými charakteristikami a potrebami), ich tvorba musí vychádzať z akéhosi rámca, ktorý kladie nasledujúce požiadavky:
- Inštalácia musí byť vykonaná prostredníctvom jedného rozvinutie: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - a nevyžadujú ďalšie akcie.
- Pri inštalácii operátora v Kubernetes je potrebné vytvoriť nový typ tretej strany (zdroj tretej strany). Na spúšťanie inštancií aplikácie (inštancie klastra) a ich ďalšiu správu (aktualizácia verzií, zmena veľkosti a pod.) používateľ použije tento typ.
- Kedykoľvek je to možné, mali by ste používať primitívy zabudované do Kubernetes, ako napr Služby и ReplicaSetspoužívať dobre otestovaný a zrozumiteľný kód.
- Vyžaduje spätnú kompatibilitu operátorov a podporu pre staršie verzie zdrojov vytvorených používateľmi.
- V prípade odstránenia Operátora by samotná aplikácia mala naďalej fungovať bez zmien.
- Používatelia by mali byť schopní definovať požadovanú verziu aplikácie a organizovať aktualizácie verzie aplikácie. Nedostatok aktualizácií softvéru je bežným zdrojom prevádzkových a bezpečnostných problémov, takže operátori musia používateľom v tejto záležitosti pomáhať.
- Operátori by mali byť testovaní pomocou nástroja ako Chaos Monkey, ktorý identifikuje potenciálne zlyhania modulov, konfigurácií a siete.
operátor atď
Príklad implementácie operátora - operátor etcd, dňom oznámenia tejto koncepcie. Konfigurácia klastra etcd môže byť zložitá kvôli potrebe udržiavať kvórum, potrebe prekonfigurovať členstvo v klastri, vytvárať zálohy atď. Napríklad manuálne škálovanie klastra etcd znamená, že musíte vytvoriť názov DNS pre nového člena klastra, spustiť novú entitu etcd a upozorniť klaster na nového člena (etcdctl člen pridať). V prípade Operátora bude užívateľovi stačiť zmeniť veľkosť klastra – všetko ostatné prebehne automaticky.
A keďže etcd bol vytvorený aj v CoreOS, bolo celkom logické, že sa ako prvý objavil jeho Operátor. ako pracuje? Logika operátora atď je určená tromi zložkami:
- Pozorovať. Operátor monitoruje stav klastra pomocou Kubernetes API.
- Analýza. Nájde rozdiely medzi aktuálnym stavom a požadovaným (definovaným konfiguráciou používateľa).
- Akcia. Rieši zistené rozdiely pomocou rozhraní API služby etcd a/alebo Kubernetes.
Na implementáciu tejto logiky boli v operátorovi pripravené funkcie Vytvoriť/zničiť (vytváranie a odstraňovanie členov klastra etcd) a Zmena veľkosti (zmena počtu členov klastra). Správnosť jeho fungovania bola kontrolovaná pomocou utility vytvorenej v podobe Chaos Monkey od Netflixu, t.j. zabíjanie etcd podov náhodne.
Pre plnú prevádzku etcd poskytuje operátor ďalšie funkcie: zálohovanie (automatické a pre používateľov neviditeľné vytváranie záložných kópií - v konfigurácii stačí určiť, ako často ich vytvárať a koľko ukladať - a následné obnovenie dát z nich) a upgrade (aktualizácia inštalácií etcd bez prestojov).
Ako vyzerá práca s operátorom?
$ 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álny stav operátora etcd je beta verzia, ktorá vyžaduje na spustenie Kubernetes 1.5.3+ a etcd 3.0+. Zdrojový kód a dokumentácia (vrátane návodu na použitie) sú dostupné na .
Bol vytvorený ďalší príklad implementácie z CoreOS - , ale stále je v alfa verzii (nie všetky plánované funkcie boli implementované).
Stav a vyhliadky
Od oznámenia Kubernetes Operators uplynulo 5 mesiacov. V oficiálnom úložisku CoreOS sú stále dostupné iba dve implementácie (pre etcd a Prometheus). Obidve ešte nedosiahli svoje stabilné verzie, ale potvrdenia sa pozorujú na dennej báze.
Vývojári si predstavujú „budúcnosť, v ktorej si používatelia nainštalujú Postgres Operators, Cassandra Operators alebo Redis Operators na svoje klastre Kubernetes a budú pracovať so škálovateľnými entitami týchto aplikácií tak jednoducho, ako je to dnes s nasadením replík webových aplikácií bez stavu“. najprv Operátori od vývojárov tretích strán naozaj sa začali objavovať:
- od UPMC Enterprises;
- od Crunchy Data (ohlásené koncom marca 2017);
- od autorov distribuovaného systému na ukladanie dát založeného na Ceph (veža je v stave alfa);
- zo SAP CCloud.
Na najväčšej európskej konferencii o slobodnom softvéri FOSDEM, ktorá sa konala vo februári 2017 v Bruseli, oznámil Josh Wood z CoreOS Operátorov v r. (video je dostupné na odkaze!), čo by malo prispieť k rastu popularity tohto konceptu v širšej Open Source komunite.
PS Ďakujeme za váš záujem o článok! Prihláste sa na odber nášho centra, aby vám neunikli nové materiály a recepty na správu systému DevOps a GNU/Linux - budeme ich pravidelne zverejňovať!
Zdroj: hab.com