Vandamálið með staðbundin forrit í Kubernetes
Stilling, ræsing og frekari skalun forrita og þjónustu er auðveld þegar kemur að málum sem flokkast sem ríkisfangslaus, þ.e. án þess að vista gögn. Það er þægilegt að keyra slíka þjónustu í Kubernetes, með því að nota staðlaða API þess, vegna þess að allt gerist „út úr kassanum“: samkvæmt stöðluðum stillingum, án þess að hafa í för með sér sérstakar upplýsingar eða töfra.
Einfaldlega sagt, til að ræsa fimm eintök til viðbótar af bakendanum í PHP/Ruby/Python í þyrping af gámum, þarftu aðeins að setja upp nýjan netþjón 5 sinnum og afrita heimildirnar. Þar sem bæði frumkóði og init handritið eru í myndinni, verður skala ríkisfangslauss forrits algjörlega grunnatriði. Eins og aðdáendur gáma og örþjónustuarkitektúrs vita vel byrja erfiðleikarnir með ríkjandi öpp, þ.e. með gagnaþol eins og gagnagrunna og skyndiminni (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Þetta á bæði við um hugbúnað sem útfærir sjálfstætt sveitarþyrping (til dæmis Percona XtraDB og Cassandra), og hugbúnað sem krefst sérstakrar stjórnunartóla (eins og Redis, MySQL, PostgreSQL...).
Erfiðleikar koma upp vegna þess að frumkóði og ræsing þjónustunnar er ekki lengur nóg - þú þarft að framkvæma fleiri skref. Afritaðu að minnsta kosti gögnin og/eða taktu þátt í klasanum. Nánar tiltekið, þessi þjónusta krefst skilnings á því hvernig á að skala, uppfæra og endurstilla þær á réttan hátt án gagnataps eða tímabundins óaðgengis. Að taka tillit til þessara þarfa er kallað „rekstrarþekking“.
CoreOS rekstraraðilar
Í því skyni að "forrita" rekstrarþekkingu, seint á síðasta ári CoreOS verkefnið „nýr flokkur hugbúnaðar“ fyrir Kubernetes vettvanginn - Rekstraraðilar (frá ensku „aðgerð“, þ.e. „aðgerð“).
Rekstraraðilar sem nota og auka kjarnagetu Kubernetes (þ.m.t. StatefulSets, sjá muninn hér að neðan) leyfa DevOps sérfræðingum að bæta rekstrarþekkingu við forritakóða.
Tilgangur rekstraraðila — útvegaðu notandanum API sem gerir þér kleift að stjórna mörgum opinberum forritaeiningum í Kubernetes klasa, án þess að hugsa um hvað er undir hettunni (hvaða gögn og hvað á að gera við þau, hvaða skipanir þarf enn að framkvæma til að viðhalda klasanum ). Reyndar er Operator hannaður til að einfalda vinnuna með forritinu innan klasans eins mikið og hægt er, gera sjálfvirkan framkvæmd rekstrarverkefna sem áður þurfti að leysa handvirkt.
Hvernig rekstraraðilar vinna
Eftirlíkingarsett Kubernetes gerir þér kleift að tilgreina æskilegan fjölda hlaupandi belg og stjórnendur tryggja að fjöldi þeirra sé viðhaldið (með því að búa til og eyða belg). Rekstraraðili vinnur á svipaðan hátt og bætir safni af rekstrarþekkingu við staðlaða Kubernetes tilföng og stjórnandi sem gerir þér kleift að framkvæma viðbótaraðgerðir til að styðja við nauðsynlegan fjölda forritaeininga.
Hvernig er þetta ólíkt StatefulSets, hannað fyrir forrit sem krefjast þess að þyrpingin veiti þeim staðbundnar auðlindir eins og gagnageymslu eða fasta IP-tölu? Fyrir slík forrit geta rekstraraðilar notað StatefulSets (í staðinn Eftirlíkingarsett) sem grundvöllur, bjóða auka sjálfvirkni: framkvæma nauðsynlegar aðgerðir ef hrun verður, taka afrit, uppfæra stillingar osfrv.
Svo, hvernig virkar þetta allt? Rekstraraðili er stjórnandapúki sem:
- gerist áskrifandi að viðburðar-API í Kubernetes;
- fær frá því gögn um kerfið (um það Eftirlíkingarsett, belg, Þjónusta og svo framvegis.);
- fær gögn um Auðlindir þriðja aðila (sjá dæmi hér að neðan);
- bregst við útliti/breytingum Auðlindir þriðja aðila (til dæmis til að breyta stærð, breyta útgáfu og svo framvegis);
- bregst við breytingum á ástandi kerfisins (um það Eftirlíkingarsett, belg, Þjónusta og svo framvegis.);
- mikilvægasti hluturinn:
- kallar á Kubernetes API til að búa til allt sem það þarf (aftur, sitt eigið Eftirlíkingarsett, belg, Þjónusta...),
- framkvæmir einhverja töfra (til einföldunar má halda að Operatorinn fari inn í belgina sjálfa og hringi í skipanir, til dæmis til að sameinast klasa eða til að uppfæra gagnasniðið við uppfærslu á útgáfu).
Reyndar, eins og sést á myndinni, er sérstöku forriti einfaldlega bætt við Kubernetes (venjulegt dreifing с ReplicaSet), sem kallast rekstraraðili. Hann lifir í venjulegum fræbelg (venjulega bara einn) og ber að jafnaði aðeins ábyrgð á því Nafnrými. Þetta rekstrarforrit innleiðir API þess - þó ekki beint, heldur í gegnum Auðlindir þriðja aðila í Kubernetes.
Svona, eftir að við höfum búið til í Nafnrými Rekstraraðili, við getum bætt við það Auðlindir þriðja aðila.
Dæmi um etcd (sjá nánar fyrir neðan):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Dæmi fyrir 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
Kröfur til rekstraraðila
CoreOS mótaði helstu mynstur sem verkfræðingar fengu meðan þeir unnu að rekstraraðila. Þrátt fyrir þá staðreynd að allir rekstraraðilar séu einstaklingsbundnir (búnir til fyrir tiltekið forrit með eigin eiginleika og þarfir), verður stofnun þeirra að byggjast á eins konar ramma sem setur eftirfarandi kröfur:
- Uppsetning verður að fara fram í gegnum einn dreifing: kubectl búa til -f SOME_OPERATOR_URL/deployment.yaml - og krefjast ekki frekari aðgerða.
- Þegar Operator er settur upp í Kubernetes verður að búa til nýja þriðja aðila (ThirdPartyResource). Til að ræsa forritstilvik (klasatilvik) og stjórna þeim frekar (uppfæra útgáfur, breyta stærð osfrv.), mun notandinn nota þessa tegund.
- Þegar mögulegt er ættirðu að nota frumstæðurnar sem eru innbyggðar í Kubernetes, svo sem Þjónusta и Eftirlíkingarsettað nota vel prófaðan og skiljanlegan kóða.
- Krefst afturábaks samhæfni rekstraraðila og stuðning fyrir eldri útgáfur af notendabúnum tilföngum.
- Ef rekstraraðilinn er fjarlægður ætti forritið sjálft að halda áfram að virka án breytinga.
- Notendur ættu að geta skilgreint æskilega forritaútgáfu og skipulagt uppfærslur forritaútgáfu. Skortur á hugbúnaðaruppfærslum er algeng uppspretta rekstrar- og öryggisvandamála, þannig að rekstraraðilar verða að aðstoða notendur í þessu máli.
- Rekstraraðilar ættu að prófa með tóli eins og Chaos Monkey, sem greinir hugsanlegar bilanir í belgjum, stillingum og netkerfinu.
etcd rekstraraðili
Dæmi um framkvæmd rekstraraðila - etcd rekstraraðili, þann dag sem þessi hugmynd var kynnt. Uppsetning etcd þyrpingarinnar getur verið flókin vegna þess að þörf er á að viðhalda ályktun, þörf á að endurstilla þyrpingaaðild, búa til afrit o.s.frv. Til dæmis, handstærð etcd klasa þýðir að þú þarft að búa til DNS nafn fyrir nýjan klasameðlim, stofna nýja etcd einingu og gera klasanum viðvart um nýja meðliminn (etcdctl meðlimur bæta við). Þegar um rekstraraðila er að ræða þarf notandinn aðeins að breyta klasastærðinni - allt annað gerist sjálfkrafa.
Og þar sem etcd var líka búið til í CoreOS, var alveg rökrétt að sjá Operator þess birtast fyrst. Hvernig virkar hann? Rógík rekstraraðila osfrv ræðst af þremur þáttum:
- Fylgstu með. Rekstraraðili fylgist með ástandi klasans með því að nota Kubernetes API.
- Greining. Finnur mun á núverandi stöðu og þeirri sem óskað er eftir (skilgreint af notendastillingu).
- Aðgerð. Leysir greindan mismun með því að nota etcd og/eða Kubernetes þjónustu API.
Til að útfæra þessa rökfræði hafa aðgerðir verið útbúnar í Operator Búa til/eyða (að búa til og eyða etcd klasameðlimum) og Breyta stærð (breyting á fjölda klasameðlima). Réttmæti virkni þess var athugað með því að nota tól sem búið var til í líkingu við Chaos Monkey frá Netflix, þ.e. drepa etcd belg af handahófi.
Fyrir fulla notkun á etcd, veitir rekstraraðilinn viðbótareiginleika: Afritun (sjálfvirkt og ósýnilegt fyrir notendur að búa til öryggisafrit - í stillingunni er nóg til að ákvarða hversu oft á að gera þau og hversu mörg á að geyma - og síðar endurheimt gagna úr þeim) og Uppfærsla (uppfæra etcd uppsetningar án niður í miðbæ).
Hvernig lítur það út að vinna með Operator?
$ 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
Núverandi staða etcd Operator er beta útgáfa, sem krefst Kubernetes 1.5.3+ og etcd 3.0+ til að keyra. Heimildarkóði og skjöl (þar á meðal notkunarleiðbeiningar) eru fáanlegar á .
Annað dæmi um útfærslu frá CoreOS hefur verið búið til - , en það er enn í alfa útgáfu (ekki hafa allir fyrirhugaðir eiginleikar verið innleiddir).
Staða og horfur
5 mánuðir eru liðnir frá tilkynningu Kubernetes Operators. Það eru enn aðeins tvær útfærslur í boði í opinberu CoreOS geymslunni (fyrir etcd og Prometheus). Báðir hafa ekki enn náð stöðugum útgáfum, en fylgst er með skuldbindingum daglega.
Hönnuðir sjá fyrir sér „framtíð þar sem notendur setja upp Postgres Operators, Cassandra Operators eða Redis Operators á Kubernetes þyrpingum sínum og vinna með skalanlegum einingum þessara forrita eins auðveldlega og að setja upp eftirlíkingar af ríkisfangslausum vefforritum er í dag. Fyrst Rekstraraðilar frá þriðja aðila verktaki byrjaði virkilega að birtast:
- frá UPMC Enterprises;
- frá Crunchy Data (tilkynnt seint í mars 2017);
- frá höfundum dreifðs gagnageymslukerfis byggt á Ceph (Rook er í alfa stöðu);
- frá SAP CCloud.
Á stærstu evrópsku ókeypis hugbúnaðarráðstefnunni FOSDEM, sem fram fór í febrúar 2017 í Brussel, tilkynnti Josh Wood frá CoreOS rekstraraðila í (myndband er fáanlegt á hlekknum!), sem ætti að stuðla að auknum vinsældum þessa hugmyndar í víðara Open Source samfélaginu.
PS Takk fyrir áhuga þinn á greininni! Gerast áskrifandi að miðstöðinni okkar, til að missa ekki af nýju efni og uppskriftum um DevOps og GNU/Linux kerfisstjórnun - við munum birta þau reglulega!
Heimild: www.habr.com