Kubernetes-eko operadoreak: egoera-aplikazioak nola exekutatu

Kubernetes-en egoera-aplikazioen arazoa

Aplikazio eta zerbitzuen konfigurazioa, abiaraztea eta eskalatzea erraza da estaturik gabeko kasuei dagokienez, hau da. datuak gorde gabe. Erosoa da Kubernetesen horrelako zerbitzuak exekutatu, bere API estandarrak erabiliz, dena "kutxatik kanpo" gertatzen delako: konfigurazio estandarren arabera, zehaztasunik edo magiarik sartu gabe.

Besterik gabe, PHP/Ruby/Python-en backendaren beste bost kopia abiarazteko edukiontzi multzo batean, zerbitzari berri bat 5 aldiz konfiguratu eta iturriak kopiatu besterik ez duzu behar. Iturburu-kodea eta hasierako script-a irudian daudenez, estaturik gabeko aplikazio bat eskalatzea guztiz oinarrizkoa bihurtzen da. Edukiontzien eta mikrozerbitzuen arkitekturaren zaleek ondo dakitenez, zailtasuna hasten da estatuko aplikazioak, hau da. datu-iraunkortasunarekin, hala nola datu-baseak eta cacheak (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Hau quorum kluster bat modu independentean inplementatzen duen softwareari aplikatzen zaio (adibidez, Percona XtraDB eta Cassandra), bai kudeaketa-erabilgarritasun bereiziak behar dituen softwareari (adibidez, Redis, MySQL, PostgreSQL...).

Zailtasunak sortzen dira iturburu-kodea eta zerbitzua abiaraztea nahikoa ez delako - urrats gehiago egin behar dituzu. Gutxienez, kopiatu datuak eta/edo elkartu kluster. Zehatzago esanda, zerbitzu hauek behar bezala nola eskalatu, eguneratu eta birkonfiguratu jakitea eskatzen dute datu-galerarik edo aldi baterako erabilgarritasunik gabe. Behar horiek kontuan hartzeari “ezagutza operatiboa” esaten zaio.

CoreOS Operadoreak

Ezagutza operatiboak "programatzeko", iazko amaieran CoreOS proiektua aurkeztu Kubernetes plataformarako "software-klase berri bat" - Operadoreak (ingelesezko "operazio"tik, hau da, "eragiketa").

Kubernetesen oinarrizko gaitasunak erabiltzen eta hedatzen dituzten eragileek (inkl. StatefulSets, ikusi behean aldea) DevOps-eko espezialistei ezagutza operatiboak gehitzeko aukera ematen die aplikazio-kodeari.

Operadorearen helburua — erabiltzaileari Kubernetes kluster batean hainbat egoeratako aplikazio-entitate kudeatzeko aukera ematen dion API bat eskaintzea, kaputxaren azpian zer dagoen pentsatu gabe (zer datu eta zer egin horrekin, zein komando exekutatu behar diren oraindik klusterra mantentzeko. ). Izan ere, Eragilea klusterraren barruan aplikazioarekin egindako lana ahalik eta gehien errazteko diseinatuta dago, lehen eskuz konpondu behar ziren zeregin operatiboen exekuzioa automatizatuz.

Eragileek nola funtzionatzen duten

Erreplika multzoak Kubernetes-ek exekutatzen ari diren pod-kopurua nahi duzun zehaztea ahalbidetzen du, eta kontrolatzaileek haien kopurua mantentzen dela ziurtatzen dute (podak sortuz eta ezabatuz). Eragile batek antzera funtzionatzen du, eta Kubernetes baliabide eta kontrolagailu estandar bati ezagutza operatibo multzo bat gehituz, aplikazio-entitate kopurua onartzen duen ekintza osagarriak egiteko aukera ematen dizu.

Nola desberdina da hau StatefulSets, klusterrak egoera-baliabideez hornitzea eskatzen duten aplikazioetarako diseinatua, hala nola datuak biltegiratzea edo IP estatikoak? Horrelako aplikazioetarako, Operadoreek erabil dezakete StatefulSets (ordez Erreplika multzoak) oinarri gisa, eskaintza automatizazio osagarria: hutsegiteen kasuan beharrezko ekintzak egin, babeskopiak egin, konfigurazioa eguneratu, etab.

Horrela, nola funtzionatzen du honek guztiak? Eragilea kudeatzailearen deabru bat da:

1. Kubernetes-eko gertaeren APIra harpidetzen da;
2. sistemari buruzko datuak jasotzen ditu bertatik (bere Erreplika multzoak, lekak, Zerbitzuak eta abar.);
3. buruzko datuak jasotzen ditu Hirugarrenen baliabideak (ikus beheko adibideak);
4. itxura/aldaketaren aurrean erreakzionatzen du Hirugarrenen baliabideak (adibidez, tamaina aldatzeko, bertsioa aldatzeko eta abar);
5. sistemaren egoera aldaketei erreakzionatzen die (bere buruz Erreplika multzoak, lekak, Zerbitzuak eta abar.);
6. garrantzitsuena:
   1. Kubernetes APIari dei egiten dio behar duen guztia sortzeko (berriz ere, berea Erreplika multzoak, lekak, Zerbitzuak...),
   2. magia pixka bat egiten du (sinplifikatzeko, pentsa dezakezu Operadorea ontzietan sartzen dela eta komandoak deitzen dituela, adibidez, kluster batean sartzeko edo bertsio bat eguneratzean datu-formatua berritzeko).

Izan ere, irudian ikus daitekeen bezala, Kubernetes-era aparteko aplikazio bat gehitzen da (ohiko bat Inplementazio с Erreplika multzoa), Eragilea deritzona. Leka arrunt batean bizi da (normalean bakarrean) eta, oro har, haren erantzule da soilik Aukerak. Operadore-aplikazio honek bere APIa inplementatzen du - zuzenean ez bada ere, bidez baizik Hirugarrenen baliabideak Kubernetes-en.

Horrela, sortu ondoren Aukerak Eragilea, gehi diezaiokegu Hirugarrenen baliabideak.

etcd-ren adibidea (ikus behean xehetasunak ikusteko):

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

Elasticsearch-en adibidea:

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

Operadoreentzako eskakizunak

CoreOS-ek ingeniariek lortutako eredu nagusiak formulatu zituen Operadoreetan lan egiten zuten bitartean. Eragile guztiak indibidualak izan arren (bere ezaugarri eta beharrak dituen aplikazio zehatz baterako sortuak), haien sorrerak baldintza hauek ezartzen dituen esparru moduko batean oinarritu behar da:

1. Instalazioa bakar baten bidez egin behar da Inplementazio: kubectl sortu -f SOME_OPERATOR_URL/deployment.yaml - eta ez dute ekintza osagarririk behar.
2. Kubernetes-en Operadore bat instalatzean, hirugarrenen mota berri bat sortu behar da (Hirugarrenen baliabidea). Aplikazio-instantziak (kluster-instantziak) abiarazteko eta gehiago kudeatzeko (bertsioak eguneratzea, tamaina aldatzea, etab.), erabiltzaileak mota hau erabiliko du.
3. Ahal den guztietan, Kubernetes-en integratutako primitiboak erabili behar dituzu, adibidez Zerbitzuak и Erreplika multzoakondo probatutako eta ulergarria den kodea erabiltzeko.
4. Eragileen atzerako bateragarritasuna eta erabiltzaileek sortutako baliabideen bertsio zaharragoetarako laguntza eskatzen du.
5. Eragilea kentzen bada, aplikazioak berak aldaketarik gabe funtzionatzen jarraitu beharko luke.
6. Erabiltzaileek nahi den aplikazioaren bertsioa definitzeko eta aplikazioaren bertsioen eguneraketak orkestratzeko gai izan behar dute. Software-eguneratze falta funtzionamendu- eta segurtasun-arazoen iturri arrunta da, beraz, Operadoreek erabiltzaileei lagundu behar diete gai honetan.
7. Operadoreak Chaos Monkey bezalako tresna batekin probatu behar dira, potentzian, konfigurazioetan eta sarean akatsak identifikatzen dituena.

etcd Eragilea

Operadorearen ezarpenaren adibidea - etcd operadorea, prestatuta kontzeptu hau iragartzen den egunean. Etcd klusterraren konfigurazioa konplexua izan daiteke quoruma mantendu beharragatik, kluster-kidetasuna birkonfiguratu beharragatik, babeskopiak sortu, etab. Adibidez, etcd kluster bat eskuz eskalatzeak esan nahi du klusterreko kide berri baten DNS izen bat sortu behar duzula, etcd entitate berri bat abiarazi eta klusterari kide berriaren berri eman behar duzula (etcdctl kidea gehitu). Operadorearen kasuan, erabiltzaileak kluster-tamaina bakarrik aldatu beharko du - gainerako guztia automatikoki gertatuko da.

Eta etcd CoreOSen ere sortu zenez, nahiko logikoa zen bere Operadorea lehenik agertzea. Nola egiten du lan? Eragilearen logika etab hiru osagaik zehazten dute:

1. Behatu. Operadoreak klusterraren egoera kontrolatzen du Kubernetes APIa erabiliz.
2. Analisia. Uneko egoeraren eta nahi denaren arteko desberdintasunak aurkitzen ditu (erabiltzaileen konfigurazioak zehaztuta).
3. Ekintza. Etcd eta/edo Kubernetes zerbitzuko APIak erabiliz antzemandako desberdintasunak konpontzen ditu.

Logika hori ezartzeko, funtzioak prestatu dira Operatzailean Sortu/Suntsitu (etcd cluster kideak sortu eta ezabatzea) eta Resize (kluster-eko kide kopuruaren aldaketa). Bere funtzionamenduaren zuzentasuna Netflix-en Chaos Monkey-ren antzera sortutako utilitate baten bidez egiaztatu zen, hau da. etcd lekak ausaz hiltzea.

Etcd-ren funtzionamendu osoa lortzeko, Operadoreak ezaugarri gehigarriak eskaintzen ditu: Babeskopia egitea (Erabiltzaileentzako segurtasun kopiak automatikoki eta ikusezinak sortzea - ​​konfigurazioan nahikoa da zenbat aldiz egin behar diren eta zenbat gorde behar diren zehaztea - eta ondorengo datuak berreskuratzea) eta Berritu (etcd instalazioak eguneratzea geldialdirik gabe).

Nolakoa da Operadore batekin lan egitea?

$ 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

Etcd Operator-en egungo egoera beta bertsioa da, eta Kubernetes 1.5.3+ eta etcd 3.0+ exekutatu behar dira. Iturburu kodea eta dokumentazioa (erabiltzeko argibideak barne) helbidean daude eskuragarri GitHub.

CoreOS-en beste inplementazio adibide bat sortu da - Prometheus operadorea, baina oraindik alfa bertsioan dago (ez dira aurreikusitako eginbide guztiak ezarri).

Egoera eta aurreikuspenak

5 hilabete igaro dira Kubernetes Operadoreak iragarri zirenetik. Oraindik bi inplementazio baino ez daude eskuragarri CoreOS biltegi ofizialean (etcd eta Prometheus-erako). Biak ez dira oraindik beren bertsio egonkorra iritsi, baina egunerokoan konpromezuak ikusten dira.

Garatzaileek "etorkizuna non erabiltzaileek Postgres Operadoreak, Cassandra Operadoreak edo Redis Operadoreak instalatuko dituzte Kubernetes klusterretan eta aplikazio horien entitate eskalagarriekin lan egingo duten estaturik gabeko web aplikazioen erreplikak hedatzea bezain erraz". Lehenengoa Hirugarrenen garatzaileen operadoreak benetan hasi zen agertzen:

• Elasticsearch operadorea UPMC Enpresak;
• PostgreSQL operadorea Crunchy Data-tik (2017ko martxoaren amaieran iragarria);
• Rook operadorea Ceph-en oinarritutako datu-biltegiratze sistema banatu baten egileen eskutik (Rook alfa egoeran dago);
• Openstack eragileak SAP CCloud-etik.

2017ko otsailean Bruselan egin zen FOSDEM Europako software librearen konferentzia handienean, CoreOSeko Josh Wood-ek Operators-en iragarri zuen. txostena (bideo bat eskuragarri dago estekan!), eta horrek kontzeptu honen ospea hazten lagundu beharko luke Iturburu Irekiko komunitate zabalean.

PS Eskerrik asko artikuluan duzun interesagatik! Harpidetu gure zentrora, DevOps eta GNU/Linux sistema-administrazioari buruzko material eta errezeta berriak galdu ez daitezen - aldizka argitaratuko ditugu!

Iturria: www.habr.com