Operatorji za Kubernetes: kako zagnati aplikacije s stanjem

Težava z aplikacijami s stanjem v Kubernetesu

Konfiguracija, zagon in nadaljnje skaliranje aplikacij in storitev je enostavno, ko gre za primere, ki so razvrščeni kot brez stanja, tj. brez shranjevanja podatkov. Takšne storitve je priročno izvajati v Kubernetesu z uporabo njegovih standardnih API-jev, ker se vse zgodi "izven škatle": v skladu s standardnimi konfiguracijami, brez vključevanja kakršnih koli posebnosti ali čarovnije.

Preprosto povedano, če želite zagnati še pet kopij ozadja v PHP/Ruby/Python v gruči vsebnikov, morate le petkrat nastaviti nov strežnik in kopirati izvorne kode. Ker sta na sliki tako izvorna koda kot začetni skript, postane skaliranje aplikacije brez stanja povsem osnovno. Kot ljubitelji vsebnikov in arhitekture mikrostoritev dobro vedo, se težava začne pri aplikacije s stanjem, tj. z obstojnostjo podatkov, kot so baze podatkov in predpomnilniki (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra ...). To velja tako za programsko opremo, ki neodvisno implementira kvorumsko gručo (na primer Percona XtraDB in Cassandra), kot za programsko opremo, ki zahteva ločene pripomočke za upravljanje (kot so Redis, MySQL, PostgreSQL ...).

Težave nastanejo, ker izvorna koda in zagon storitve ne zadostujeta več - opraviti je treba še nekaj korakov. Vsaj kopirajte podatke in/ali se pridružite gruči. Natančneje, te storitve zahtevajo razumevanje, kako jih pravilno prilagoditi, posodobiti in znova konfigurirati brez izgube podatkov ali začasne nerazpoložljivosti. Upoštevanje teh potreb se imenuje "operativno znanje".

Operaterji CoreOS

Da bi "sprogramirali" operativno znanje, konec lanskega leta projekt CoreOS uveden »nov razred programske opreme« za platformo Kubernetes - Operatorji (iz angleškega »operation«, tj. »operacija«).

Operaterji, ki uporabljajo in razširjajo osnovne zmogljivosti Kubernetesa (vklj. StatefulSets, glejte razliko spodaj) omogočajo strokovnjakom DevOps, da dodajo operativno znanje kodi aplikacije.

Namen operaterja — zagotovite uporabniku API, ki vam omogoča upravljanje več entitet aplikacij s statusom v gruči Kubernetes, ne da bi razmišljali o tem, kaj je pod pokrovom (kateri podatki in kaj storiti z njimi, katere ukaze je še treba izvesti za vzdrževanje gruče ). Pravzaprav je Operater zasnovan tako, da čim bolj poenostavi delo z aplikacijo znotraj gruče, avtomatizira izvajanje operativnih nalog, ki jih je bilo prej treba reševati ročno.

Kako delujejo operaterji

ReplicaSets Kubernetes vam omogoča, da določite želeno število delujočih podov, krmilniki pa poskrbijo, da se njihovo število ohranja (z ustvarjanjem in brisanjem podov). Operater deluje na podoben način in standardnemu viru in krmilniku Kubernetes doda nabor operativnega znanja, ki vam omogoča izvajanje dodatnih dejanj za podporo zahtevanemu številu entitet aplikacije.

Kako se to razlikuje od StatefulSets, zasnovan za aplikacije, ki zahtevajo, da jim gruča zagotovi vire s stanjem, kot so shranjevanje podatkov ali statični IP-ji? Za takšne aplikacije lahko operaterji uporabljajo StatefulSets (namesto ReplicaSets) kot osnova, ponudba dodatno avtomatizacijo: izvedite potrebna dejanja v primeru zrušitev, naredite varnostne kopije, posodobite konfiguracijo itd.

Torej, kako vse to deluje? Operater je upraviteljski demon, ki:

1. se naroči na API dogodka v Kubernetesu;
2. od njega prejema podatke o sistemu (o svojem ReplicaSets, stroki, Storitve in tako naprej.);
3. prejema podatke o Viri tretjih oseb (glej primere spodaj);
4. reagira na videz/spremembe Viri tretjih oseb (na primer za spremembo velikosti, spremembo različice itd.);
5. reagira na spremembe v stanju sistema (o svojem ReplicaSets, stroki, Storitve in tako naprej.);
6. najpomembnejše:
   1. pokliče Kubernetes API, da ustvari vse, kar potrebuje (spet svoje ReplicaSets, stroki, Storitve...),
   2. izvede nekaj čarovnije (za poenostavitev si lahko predstavljate, da operater gre v same pode in pokliče ukaze, na primer za pridružitev gruči ali za nadgradnjo formata podatkov pri posodabljanju različice).

Pravzaprav je, kot je razvidno iz slike, v Kubernetes preprosto dodana ločena aplikacija (običajna Deployment с ReplicaSet), ki se imenuje operater. Živi v navadnem stroku (običajno samo enem) in je praviloma odgovoren le za svoje Imenski prostor. Ta operaterska aplikacija izvaja svoj API - čeprav ne neposredno, ampak prek Viri tretjih oseb v Kubernetesu.

Tako, potem ko smo ustvarili v Imenski prostor Operater, lahko ga dodamo Viri tretjih oseb.

Primer za itd (glej spodaj za podrobnosti):

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

Primer za 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

Zahteve za operaterje

CoreOS je oblikoval glavne vzorce, ki so jih pridobili inženirji med delom na Operatorjih. Kljub dejstvu, da so vsi operaterji individualni (ustvarjeni za specifično aplikacijo s svojimi značilnostmi in potrebami), mora njihova izdelava temeljiti na nekakšnem okviru, ki nalaga naslednje zahteve:

1. Namestitev je treba opraviti prek enote Deployment: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - in ne zahtevajo dodatnih dejanj.
2. Pri namestitvi operaterja v Kubernetes je treba ustvariti novo vrsto tretje osebe (ThirdPartyResource). Za zagon instanc aplikacije (instance gruče) in nadaljnje upravljanje z njimi (posodabljanje različic, spreminjanje velikosti itd.) bo uporabnik uporabljal to vrsto.
3. Če je le mogoče, uporabite primitive, vgrajene v Kubernetes, kot je npr Storitve и ReplicaSetsuporabljati dobro preizkušeno in razumljivo kodo.
4. Zahteva povratno združljivost operaterjev in podporo za starejše različice virov, ki jih ustvarijo uporabniki.
5. Če je operater odstranjen, mora sama aplikacija še naprej delovati brez sprememb.
6. Uporabniki bi morali imeti možnost določiti želeno različico aplikacije in organizirati posodobitve različice aplikacije. Pomanjkanje posodobitev programske opreme je pogost vir operativnih in varnostnih težav, zato morajo operaterji pri tej zadevi pomagati uporabnikom.
7. Operaterje bi bilo treba preizkusiti z orodjem, kot je Chaos Monkey, ki identificira morebitne napake v sklopih, konfiguracijah in omrežju.

itdd Operater

Primer implementacije operaterja - operater etcd, pripravljeno na dan objave tega koncepta. Konfiguracija gruče itdd je lahko zapletena zaradi potrebe po ohranjanju kvoruma, potrebe po ponovni konfiguraciji članstva v gruči, ustvarjanju varnostnih kopij itd. Na primer, ročno spreminjanje velikosti gruče etcd pomeni, da morate ustvariti ime DNS za novega člana gruče, zagnati novo entiteto etcd in opozoriti gručo o novem članu (etcdctl dodatek članov). V primeru operaterja bo moral uporabnik spremeniti le velikost gruče – vse ostalo se bo zgodilo samodejno.

In ker je bil tudi etcd ustvarjen v CoreOS, je bilo povsem logično, da se najprej pojavi njegov Operator. Kako deluje? Operaterska logika itd določajo tri komponente:

1. Opazujte. Operater spremlja stanje gruče s pomočjo API-ja Kubernetes.
2. Analiza. Poišče razlike med trenutnim stanjem in želenim (določeno z uporabniško konfiguracijo).
3. Akcija. Odpravlja zaznane razlike z uporabo API-jev storitev etcd in/ali Kubernetes.

Za izvajanje te logike so v Operaterju pripravljene funkcije Ustvari/Uniči (ustvarjanje in brisanje članov gruče etcd) in Resize (sprememba števila članov grozda). Pravilnost njegovega delovanja je bila preverjena s pomočjo pripomočka, ustvarjenega po vzoru Chaos Monkey iz Netflixa, tj. naključno ubijanje itd.

Za popolno delovanje etcd operater ponuja dodatne funkcije: backup (samodejno in uporabnikom nevidno ustvarjanje varnostnih kopij - v konfiguraciji je dovolj, da določite, kako pogosto jih narediti in koliko jih shraniti - in naknadno obnovitev podatkov iz njih) in nadgradnja (posodabljanje namestitve etcd brez izpadov).

Kako izgleda delo z operaterjem?

$ 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

Trenutni status operaterja etcd je različica beta, ki za delovanje zahteva Kubernetes 1.5.3+ in etcd 3.0+. Izvorna koda in dokumentacija (vključno z navodili za uporabo) sta na voljo na GitHub.

Ustvarjen je bil še en primer izvedbe iz CoreOS - Operater Prometheus, vendar je še vedno v različici alfa (vse načrtovane funkcije niso bile implementirane).

Stanje in obeti

Minilo je 5 mesecev od objave operaterjev Kubernetes. V uradnem repozitoriju CoreOS sta še vedno na voljo samo dve izvedbi (za etcd in Prometheus). Oba še nista dosegla svojih stabilnih različic, vendar se zavezanosti opazujejo dnevno.

Razvijalci predvidevajo "prihodnost, v kateri uporabniki namestijo operaterje Postgres, operaterje Cassandra ali operaterje Redis na svoje gruče Kubernetes in delajo s prilagodljivimi entitetami teh aplikacij tako enostavno, kot je danes uvajanje replik spletnih aplikacij brez stanja." najprej Operaterji razvijalcev tretjih oseb res se je začelo pojavljati:

• Operater Elasticsearch od UPMC Enterprises;
• Operater PostgreSQL iz Crunchy Data (napovedano konec marca 2017);
• Rook Operater od avtorjev porazdeljenega sistema za shranjevanje podatkov, ki temelji na Cephu (Rook je v alfa statusu);
• Operatorji OpenStack iz SAP CCloud.

Na največji evropski konferenci o prosti programski opremi FOSDEM, ki je potekala februarja 2017 v Bruslju, je Josh Wood iz CoreOS napovedal Operators in poročilo (posnetek je na voljo na povezavi!), kar naj bi prispevalo k rasti priljubljenosti tega koncepta v širši odprtokodni skupnosti.

PS Hvala za zanimanje za članek! Naročite se na naše središče, da ne boste zamudili novih gradiv in receptov o sistemski administraciji DevOps in GNU/Linux – redno jih bomo objavljali!

Vir: www.habr.com