Tilallisten sovellusten ongelma Kubernetesissa
Sovellusten ja palveluiden konfigurointi, käynnistäminen ja edelleen skaalaus on yksinkertaista, kun on kyse valtiottomaksi luokitelluista tapauksista, ts. tallentamatta tietoja. Tällaisia palveluita on kätevä ajaa Kubernetesissa sen standardisovellusliittymien avulla, koska kaikki tapahtuu suoraan: vakiokokoonpanojen mukaan ilman erityispiirteitä ja taikuutta.
Yksinkertaisesti sanottuna, jotta voit ajaa vielä viisi kopiota PHP/Ruby/Python-taustaohjelmasta klusterissa säilöistä, sinun tarvitsee vain nostaa uusi palvelin viisi kertaa ja kopioida lähteet. Koska sekä lähdekoodi että init-skripti ovat kuvassa, tilattoman sovelluksen skaalauksesta tulee melko alkeellista. Kuten konttien ja mikropalveluarkkitehtuurien ystävät hyvin tietävät, vaikeudet alkavat tilallisia sovelluksia, eli tietojen, kuten tietokantojen ja välimuistien (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra…) kanssa. Tämä koskee sekä ohjelmistoja, jotka toteuttavat itsenäisesti quorum-klusterin (esimerkiksi Percona XtraDB ja Cassandra), että ohjelmistoja, jotka vaativat erilliset hallintaapuohjelmat (kuten Redis, MySQL, PostgreSQL ...).
Vaikeuksia syntyy, koska lähdekoodi ja palvelun käynnistäminen eivät riitä - sinun on suoritettava lisää toimintoja. Kopioi vähintään tiedot ja/tai liity klusteriin. Tarkemmin sanottuna nämä palvelut edellyttävät ymmärrystä, kuinka ne voidaan skaalata, päivittää ja määrittää uudelleen ilman tietojen menetystä ja tilapäistä poissaoloa. Näiden tarpeiden huomioon ottamista kutsutaan "operatiiviseksi tiedoksi" (operational information).
CoreOS-operaattorit
Operatiivisen tiedon "ohjelmoimiseksi" viime vuoden lopulla CoreOS-projekti "Uusi ohjelmistoluokka" Kubernetes-alustalle - Operaattorit (Operators, englannin sanasta "operation", eli "operaatio").
Operaattorit, jotka käyttävät ja laajentavat Kubernetesin perusominaisuuksia (sis. StatefulSets, katso erot alta) antaa DevOpsille mahdollisuuden lisätä käyttötietoa sovelluskoodiin.
Operaattorin tarkoitus - tarjota käyttäjälle API, jonka avulla voit hallita monia tilallisen sovelluksen entiteettejä Kubernetes-klusterissa ajattelematta, mitä konepellin alla on (mitä tietoja ja mitä niille tehdä, mitä komentoja on vielä suoritettava ylläpitääkseen klusteri). Itse asiassa Operator on suunniteltu yksinkertaistamaan työskentelyä sovelluksen kanssa klusterin sisällä niin paljon kuin mahdollista, automatisoimalla sellaisten operatiivisten tehtävien suorittamista, jotka aiemmin piti ratkaista manuaalisesti.
Kuinka operaattorit toimivat
ReplicaSets Kubernetes antaa sinun määrittää halutun määrän käynnissä olevia podeja, ja ohjaimet varmistavat, että niiden lukumäärä säilyy (luomalla ja poistamalla podeja). Samoin Operaattori toimii, joka lisää joukon toiminnallista tietoa Kubernetes-standardin resurssiin ja ohjaimeen, jolloin voit suorittaa lisätoimintoja ylläpitääksesi tarvittavaa määrää sovelluskokonaisuuksia.
Miten tämä eroaa StatefulSetssovelluksille, jotka edellyttävät klusterin tarjoavan niille tilallisia resursseja, kuten tietojen tallennusta tai staattisia IP-osoitteita? Tällaisissa sovelluksissa operaattorit voivat käyttää StatefulSets (eikä ReplicaSets) perustana, tarjouksena lisäautomaatiota: suorita tarvittavat toimet kaatuessa, tee varmuuskopiot, päivitä asetukset jne.
Niin, miten se kaikki toimii? Operaattori on ohjausdaemon, joka:
- tilaa tapahtumasovellusliittymän Kubernetesissa;
- vastaanottaa siltä tietoja järjestelmästä (sen ReplicaSets, palot, Palvelut ja niin edelleen.);
- saa tietoa aiheesta Kolmannen osapuolen resurssit (katso esimerkkejä alla);
- reagoi ulkonäköön/muutokseen Kolmannen osapuolen resurssit (esimerkiksi koon muuttaminen, version muuttaminen ja niin edelleen);
- reagoi muutokseen järjestelmän tilassa (noin ReplicaSets, palot, Palvelut ja niin edelleen.);
- tärkein:
- käyttää Kubernetes APIa luodakseen kaiken tarvitsemasi (jälleen oman ReplicaSets, palot, Palvelut...),
- suorittaa jonkin verran taikuutta (voit yksinkertaisuuden vuoksi ajatella, että Operaattori menee itse podeihin ja kutsuu komentoja esimerkiksi liittyäkseen klusteriin tai päivittääkseen tietomuotoa versiota päivitettäessä).
Itse asiassa, kuten kuvasta näkyy, Kubernetesiin lisätään yksinkertaisesti erillinen sovellus (tavallinen käyttöönoton с Replikasarja), jota kutsutaan Operaattoriksi. Se elää tavallisessa palossa (yleensä yksittäisessä) ja on pääsääntöisesti vastuussa vain omastaan nimiavaruus. Tämä operaattorisovellus toteuttaa sen API - mutta ei suoraan, vaan sen kautta Kolmannen osapuolen resurssit Kubernetesissa.
Näin ollen, kun olemme luoneet nimiavaruus Operaattori, voimme lisätä siihen Kolmannen osapuolen resurssit.
Esimerkki jne (katso yksityiskohdat alla):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Esimerkki Elasticsearchista:
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
Vaatimukset operaattoreille
CoreOS muotoili tärkeimmät mallit, jotka insinöörit saivat työskennellessään operaattoreiden parissa. Huolimatta siitä, että kaikki Operaattorit ovat yksilöllisiä (ne on luotu tiettyyn sovellukseen, jolla on omat ominaisuudet ja tarpeet), niiden luomisen on perustuttava eräänlaiseen kehykseen, joka asettaa seuraavat vaatimukset:
- Asennus tulee tehdä yhdellä käyttöönoton: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - eivätkä vaadi lisätoimenpiteitä.
- Operaattorin asentamisen Kubernetesiin pitäisi luoda uusi vieras tyyppi (Kolmannen osapuolen resurssi). Käyttäjä käyttää tätä tyyppiä käynnistääkseen sovellusesiintymiä (klusteriesiintymiä) ja hallitakseen niitä edelleen (päivittää versioita, muuttaa kokoa jne.).
- Aina kun mahdollista, tulee käyttää Kubernetesin sisäänrakennettuja primitiivejä, kuten Palvelut и ReplicaSetskäyttää hyvin testattua ja ymmärrettävää koodia.
- Tarvitaan operaattoreiden taaksepäin yhteensopivuus ja tuki käyttäjien luomien resurssien vanhemmille versioille.
- Kun Operaattori poistetaan, sovelluksen itsensä pitäisi jatkaa toimintaansa ilman muutoksia.
- Käyttäjien pitäisi pystyä määrittämään haluttu sovellusversio ja organisoida sovellusversiopäivitykset. Ohjelmistopäivitysten puute on yleinen toiminta- ja turvallisuusongelmien lähde, ja operaattoreiden tulee auttaa käyttäjiä tässä asiassa.
- Operaattoreita tulee testata Chaos Monkeyn kaltaisella työkalulla, joka havaitsee mahdolliset viat podeissa, kokoonpanoissa ja verkossa.
etcd Operaattori
Operaattorin toteutusesimerkki - etcd Operaattori, tämän konseptin julkistamispäivään asti. Etcd-klusterin määritys voi olla monimutkaista, koska on tarpeen ylläpitää päätösvaltaisuutta, määrittää klusterin jäsenyys uudelleen, luoda varmuuskopioita ja niin edelleen. Esimerkiksi etcd-klusterin manuaalinen skaalaus tarkoittaa DNS-nimen luomista uudelle klusterin jäsenelle, uuden etcd-yksikön käynnistämistä, klusterille ilmoittamista uudesta jäsenestä (etcdctl jäsenen lisäys). Operaattorin tapauksessa riittää, että käyttäjä muuttaa klusterin kokoa - kaikki muu tapahtuu automaattisesti.
Ja koska etcd luotiin myös CoreOS:ssä, oli varsin loogista nähdä sen Operatorin ulkonäkö ensin. Miten hän toimii? etcd Operator Logic määritellään kolmella osalla:
- Havainto. Operaattori tarkkailee klusterin tilaa Kubernetes API:n avulla.
- Analyysi (Analysoi). Etsii erot nykyisen tilan ja halutun tilan välillä (määritetty käyttäjän kokoonpanon mukaan).
- Toimi (laki). Poistaa havaitut erot etcd- ja/tai Kubernetes-palvelusovellusliittymien avulla.
Tämän logiikan toteuttamiseksi Operaattori on valmistellut toimintoja Luo/tuhoa (luoda ja poista klusterin jäseniä jne.) ja Kokoa (muutos klusterin jäsenten lukumäärässä). Sen suorituskyvyn oikeellisuuden tarkistaminen tarkistettiin Netflixin Chaos Monkeyn kaltaisella apuohjelmalla, ts. tappaa etcd-palot satunnaisesti.
Etdd:n täydellistä toimintaa varten Operaattori tarjoaa lisäominaisuuksia: Varmuuskopiointi (automaattinen ja huomaamaton, että käyttäjät luovat varmuuskopioita - konfiguraatiossa riittää määrittää, kuinka usein ne tulee tehdä ja kuinka paljon tallentaa - ja myöhemmin tietojen palautus niistä) ja parantaa (päivitetään etcd-asennukset ilman seisokkeja).
Miltä näyttää työskentely Operaattorin kanssa?
$ 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
Etdd Operatorin nykyinen tila on beta-versio, joka vaatii Kubernetes 1.5.3+ ja etcd 3.0+ toimiakseen. Lähdekoodi ja dokumentaatio (mukaan lukien käyttöohjeet) ovat saatavilla osoitteessa .
Toinen toteutusesimerkki CoreOS:stä on luotu - , mutta se on edelleen alfavaiheessa (kaikkia suunniteltuja ominaisuuksia ei ole otettu käyttöön).
Tila ja näkymät
Kubernetes-operaattoreiden julkistamisesta on kulunut 5 kuukautta. Vain kaksi toteutusta on edelleen saatavilla virallisessa CoreOS-varastossa (etcd:lle ja Prometheukselle). Kumpikaan ei ole vielä saavuttanut vakaata versiotaan, mutta niihin sitoutuu päivittäin.
Kehittäjät odottavat tulevaisuutta, jossa käyttäjät asentavat Postgres-, Cassandra- tai Redis-operaattorit Kubernetes-klusteriinsa ja työskentelevät näiden sovellusten skaalautuvien entiteettien kanssa yhtä helposti kuin tilattomien sovellusten replikoiden käyttöönotto verkossa tänään. Ensimmäinen Kolmannen osapuolen operaattorit alkoi todella näkyä.
- UPMC Enterprisesilta;
- Crunchy Datasta (ilmoitettu maaliskuun lopussa 2017 .);
- Ceph-pohjaisen hajautetun tallennusjärjestelmän tekijöiltä (Rook on alfa-tilassa);
- SAP CCloudista.
Euroopan suurimmassa ilmaisten ohjelmistojen konferenssissa FOSDEM, joka pidettiin helmikuussa 2017 Brysselissä, CoreOS:n Josh Wood ilmoitti Operaattorit (video löytyy linkistä!), jonka pitäisi edistää tämän konseptin suosion kasvua laajemmassa avoimen lähdekoodin yhteisössä.
PS. Kiitos mielenkiinnostasi artikkelia kohtaan! Tilaa keskuksemme, jotta et menetä uusia materiaaleja ja reseptejä DevOps- ja GNU/Linux-järjestelmänhallinnassa - julkaisemme ne säännöllisesti!
Lähde: will.com