La problemo kun ŝtataj aplikoj en Kubernetes
Agordo, lanĉo kaj plia skalo de aplikoj kaj servoj estas facilaj kiam temas pri kazoj klasifikitaj kiel sennaciaj, t.e. sen konservi datumojn. Estas oportune funkciigi tiajn servojn en Kubernetes, uzante ĝiajn normajn API-ojn, ĉar ĉio okazas "el la skatolo": laŭ normaj agordoj, sen impliki iujn ajn specifaĵojn aŭ magion.
Simple dirite, por lanĉi kvin pliajn kopiojn de la backend en PHP/Ruby/Python en aro da ujoj, vi nur bezonas agordi novan servilon 5 fojojn kaj kopii la fontojn. Ĉar kaj la fontkodo kaj la init-skripto estas en la bildo, grimpi sennacian aplikaĵon fariĝas tute elementa. Kiel ŝatantoj de ujoj kaj mikroserva arkitekturo bone scias, la malfacilaĵo komenciĝas per ŝtataj programoj, t.e. kun datenpersisto kiel datumbazoj kaj kaŝmemoroj (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Ĉi tio validas por kaj programaro kiu sendepende efektivigas kvoruman grapolon (ekzemple, Percona XtraDB kaj Cassandra), kaj programaro kiu postulas apartajn administradservaĵojn (kiel ekzemple Redis, MySQL, PostgreSQL...).
Malfacilaĵoj aperas ĉar la fontkodo kaj lanĉo de la servo ne plu sufiĉas - vi devas fari kelkajn pliajn paŝojn. Minimume kopiu la datumojn kaj/aŭ aliĝu al la areto. Pli precize, ĉi tiuj servoj postulas komprenon pri kiel ĝuste skali, ĝisdatigi kaj reagordi ilin sen datumperdo aŭ provizora nehavebleco. Konsideri ĉi tiujn bezonojn estas nomata "funkcia scio".
Operaciistoj de CoreOS
Por "programi" operacian scion, fine de la pasinta jaro la projekto CoreOS "nova klaso de programaro" por la platformo Kubernetes - Operatoroj (el la angla "operacio", t.e. "operacio").
Funkciistoj uzantaj kaj etendantaj la kernkapablojn de Kubernetes (inkl. StatefulSets, vidu la diferencon malsupre) permesas al specialistoj de DevOps aldoni funkcian scion al aplika kodo.
La Celo de Operaciisto — provizi la uzanton per API, kiu ebligas al vi administri plurajn ŝtatajn aplikajn entojn en Kubernetes-areto, sen pensi pri kio estas sub la kapuĉo (kiaj datumoj kaj kion fari kun ĝi, kiaj komandoj ankoraŭ devas esti ekzekutitaj por konservi la grapolon). ). Fakte, la Operaciisto estas desegnita por simpligi la laboron kun la aplikaĵo ene de la grapolo kiel eble plej multe, aŭtomatigante la plenumon de operaciaj taskoj, kiuj antaŭe devis esti solvitaj permane.
Kiel Funkciistoj
ReplicaSets Kubernetes permesas al vi specifi la deziratan nombron da kurantaj podoj, kaj regiloj certigas, ke ilia nombro estas konservita (kreante kaj forigante podojn). Operaciisto funkcias simile, aldonante aron de operaciaj scioj al norma rimedo kaj regilo de Kubernetes, kiu ebligas al vi fari pliajn agojn por subteni la bezonatan nombron da aplikaĵaj entoj.
Kiel tio diferencas de StatefulSets, desegnita por aplikoj kiuj postulas la areton provizi ilin per ŝtataj rimedoj kiel datumstokado aŭ senmovaj IP-oj? Por tiaj aplikoj, Operaciantoj povas uzi StatefulSets (anstataŭe ReplicaSets) kiel bazo, oferto kroma aŭtomatigo: plenumi la necesajn agojn en kazo de kraŝoj, fari sekurkopiojn, ĝisdatigi la agordon ktp.
Kaj tiel, kiel ĉio ĉi funkcias? La funkciigisto estas administranto-demono kiu:
- abonas la eventon API en Kubernetes;
- ricevas de ĝi datumojn pri la sistemo (pri ĝia ReplicaSets, Podoj, servoj kaj tiel plu.);
- ricevas datumojn pri Triaj Rimedoj (vidu ekzemplojn malsupre);
- reagas al aspekto/ŝanĝo Triaj Rimedoj (ekzemple por ŝanĝi la grandecon, ŝanĝi la version, ktp);
- reagas al ŝanĝoj en la stato de la sistemo (pri ĝia ReplicaSets, Podoj, servoj kaj tiel plu.);
- la plej grava:
- alvokas la Kubernetes API krei ĉion, kion ĝi bezonas (denove, sian propran ReplicaSets, Podoj, servoj...),
- faras iun magion (por simpligi, vi povas pensi, ke la Operaciisto eniras la podojn mem kaj vokas komandojn, ekzemple, por aliĝi al areto aŭ por ĝisdatigi la datumformaton kiam ĝi ĝisdatigas version).
Fakte, kiel videblas de la bildo, aparta aplikaĵo estas simple aldonita al Kubernetes (kutima deplojo с ReplicaSet), kiu estas nomita la Operaciisto. Ĝi vivas en ordinara balgo (kutime nur unu) kaj, kiel regulo, respondecas nur pri ĝia Nomspaco. Ĉi tiu operacianta aplikaĵo efektivigas sian API - kvankam ne rekte, sed pere Triaj Rimedoj en Kubernetes.
Tiel, post kiam ni kreis en Nomspaco Operatoro, ni povas aldoni al ĝi Triaj Rimedoj.
Ekzemplo por etcd (vidu malsupre por detaloj):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Ekzemplo por 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
Postuloj por Operaciistoj
CoreOS formulis la ĉefajn ŝablonojn akiritajn de inĝenieroj laborante pri Funkciigistoj. Malgraŭ la fakto, ke ĉiuj Operaciantoj estas individuaj (kreitaj por specifa aplikaĵo kun siaj propraj trajtoj kaj bezonoj), ilia kreado devas baziĝi sur speco de kadro, kiu trudas la sekvajn postulojn:
- Instalado devas esti farita per unuopa deplojo: kubectl krei -f IUJ_OPERATOR_URL/deployment.yaml - kaj ne postulas pliajn agojn.
- Kiam oni instalas Operaciiston en Kubernetes, oni devas krei novan trian tipon (TriaParona Rimedo). Por lanĉi aplikaĵinstancojn (grupoj) kaj plu administri ilin (ĝisdatigi versiojn, regrandigi ktp.), la uzanto uzos ĉi tiun tipon.
- Kiam ajn eblas, vi devus uzi la primitivulojn enkonstruitajn en Kubernetes, kiel ekzemple servoj и ReplicaSetsuzi bone elprovitan kaj kompreneblan kodon.
- Postulas malantaŭan kongruon de Operaciantoj kaj subtenon por pli malnovaj versioj de uzantkreitaj rimedoj.
- Se la Operaciisto estas forigita, la aplikaĵo mem devus daŭre funkcii sen ŝanĝoj.
- Uzantoj devus povi difini la deziratan aplikaĵversion kaj reĝisori aplikaĵversion-ĝisdatigojn. Manko de programaj ĝisdatigoj estas ofta fonto de operaciaj kaj sekurecaj problemoj, do Operaciantoj devas helpi uzantojn pri ĉi tiu afero.
- Operaciantoj devus esti provitaj per ilo kiel Chaos Monkey, kiu identigas eblajn fiaskojn en podoj, agordoj kaj la reto.
etcd Operatoro
Ekzemplo de Efektivigo de Operaciisto - etcd Operatoro, en la tago de la anonco de ĉi tiu koncepto. La etcd-aretkonfiguracio povas esti kompleksa pro la bezono konservi kvorumon, la bezono reagordi aretmembrecon, krei sekurkopiojn, ktp. Ekzemple, mane grimpi etcd-grupon signifas, ke vi devas krei DNS-nomon por nova aretmembro, komenci novan etcd-enton kaj atentigi la areton pri la nova membro (etcdctl membro add). En la kazo de la Operaciisto, la uzanto devos nur ŝanĝi la grapolgrandon - ĉio alia okazos aŭtomate.
Kaj ĉar etcd ankaŭ estis kreita en CoreOS, estis sufiĉe logike vidi ĝian Operaciiston aperi unue. Kiel li laboras? Operatora logiko ktpd estas determinita de tri komponantoj:
- Observu. La funkciigisto kontrolas la staton de la areto uzante la Kubernetes API.
- Analizo. Trovas diferencojn inter la nuna stato kaj la dezirata (difinita de la uzanta agordo).
- Ago. Solvas detektitajn diferencojn uzante la etcd kaj/aŭ Kubernetes-servajn APIojn.
Por efektivigi ĉi tiun logikon, funkcioj estis preparitaj en la Operaciisto Krei/Detrui (kreado kaj forigo de etcd-grupanoj) kaj Regrandigi (ŝanĝo en la nombro da aretmembroj). La ĝusteco de ĝia funkciado estis kontrolita uzante ilon kreitan en la simileco de Chaos Monkey de Netflix, t.e. mortigante etcd pods hazarde.
Por plena funkciado de etcd, la Operaciisto disponigas kromajn funkciojn: apogilo (aŭtomata kaj nevidebla por uzantoj kreado de rezervaj kopioj - en la agordo sufiĉas determini kiom ofte fari ilin kaj kiom da stoki - kaj posta restarigo de datumoj de ili) kaj ĝisdatigo (ĝisdatigi etcd-instalaĵojn sen malfunkcio).
Kiel aspektas labori kun Operaciisto?
$ 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
La nuna stato de etcd Operator estas beta-versio, postulante Kubernetes 1.5.3+ kaj etcd 3.0+ por funkcii. Fontkodo kaj dokumentaro (inkluzive de instrukcioj por uzo) estas haveblaj ĉe .
Alia ekzempla efektivigo de CoreOS estis kreita - , sed ĝi ankoraŭ estas en alfa versio (ne ĉiuj planitaj funkcioj estis efektivigitaj).
Statuso kaj perspektivoj
5 monatoj pasis ekde la anonco de Kubernetes Operatoroj. Estas ankoraŭ nur du efektivigoj disponeblaj en la oficiala CoreOS-deponejo (por etcd kaj Prometheus). Ambaŭ ankoraŭ ne atingis siajn stabilajn versiojn, sed kommits estas observitaj ĉiutage.
La programistoj antaŭvidas "estonton en kiu uzantoj instalas Postgres Operatorojn, Cassandra Operatorojn aŭ Redis Operatorojn sur siaj Kubernetes-aretoj kaj laboras kun la skaleblaj entoj de ĉi tiuj aplikoj tiel facile kiel deploji kopiojn de sennaciaj TTT-aplikoj estas hodiaŭ." Unue Funkciigistoj de triapartneraj programistoj vere komencis aperi:
- de UPMC Enterprises;
- de Crunchy Data (anoncita malfrua marto 2017);
- de la aŭtoroj de distribua datumstokado-sistemo bazita sur Ceph (Rook estas en alfa-statuso);
- de SAP CCloud.
En la plej granda eŭropa konferenco de libera programaro FOSDEM, kiu okazis en februaro 2017 en Bruselo, Josh Wood de CoreOS anoncis Operatorojn en (vidbendo haveblas ĉe la ligilo!), kiu devus kontribui al la kresko de populareco de ĉi tiu koncepto en la pli larĝa Malfermfonta komunumo.
PS Dankon pro via intereso pri la artikolo! Abonu nian centron, por ne maltrafi novajn materialojn kaj receptojn pri DevOps kaj GNU/Linukso-sistema administrado - ni publikigos ilin regule!
fonto: www.habr.com