Problemi me aplikacionet shtetërore në Kubernetes
Konfigurimi, lëshimi dhe shkallëzimi i mëtejshëm i aplikacioneve dhe shërbimeve është i lehtë kur bëhet fjalë për rastet e klasifikuara si pa shtetësi, d.m.th. pa ruajtur të dhëna. Është i përshtatshëm për të ekzekutuar shërbime të tilla në Kubernetes, duke përdorur API-të e tij standarde, sepse gjithçka ndodh "jashtë kutisë": sipas konfigurimeve standarde, pa përfshirë ndonjë specifikë ose magji.
E thënë thjesht, për të nisur pesë kopje të tjera të backend-it në PHP/Ruby/Python në një grup kontejnerësh, ju duhet vetëm të konfiguroni një server të ri 5 herë dhe të kopjoni burimet. Meqenëse kodi burimor dhe skripti fillestar janë në imazh, shkallëzimi i një aplikacioni pa shtetësi bëhet krejtësisht elementar. Siç e dinë mirë tifozët e kontejnerëve dhe arkitekturës së mikroshërbimeve, vështirësia fillon me aplikacione shtetërore, d.m.th. me qëndrueshmëri të të dhënave si bazat e të dhënave dhe cache (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Kjo vlen si për softuerin që zbaton në mënyrë të pavarur një grup kuorumi (për shembull, Percona XtraDB dhe Cassandra), ashtu edhe për softuerin që kërkon shërbime të veçanta të menaxhimit (të tilla si Redis, MySQL, PostgreSQL...).
Vështirësitë lindin sepse kodi burimor dhe nisja e shërbimit nuk mjaftojnë më - duhet të kryeni disa hapa të tjerë. Së paku, kopjoni të dhënat dhe/ose bashkohuni me grupin. Më saktësisht, këto shërbime kërkojnë të kuptuarit se si të shkallëzohen, përditësohen dhe rikonfigurohen siç duhet pa humbje të të dhënave ose pa disponueshmëri të përkohshme. Marrja parasysh e këtyre nevojave quhet "njohuri operacionale".
Operatorët CoreOS
Për të "programuar" njohuritë operative, në fund të vitit të kaluar projekti CoreOS "Një klasë e re softuerësh" për platformën Kubernetes - Operatorët (nga anglishtja "operacion", d.m.th. "operacion").
Operatorët që përdorin dhe zgjerojnë aftësitë kryesore të Kubernetes (përfshirë. StatefulSets, shikoni ndryshimin më poshtë) lejoni specialistët e DevOps të shtojnë njohuri operacionale në kodin e aplikacionit.
Qëllimi i Operatorit — Sigurojini përdoruesit një API që ju lejon të menaxhoni entitete të shumta shtetërore të aplikacionit në një grupim Kubernetes, pa menduar se çfarë është nën kapuç (çfarë të dhënash dhe çfarë të bëni me to, çfarë komandash duhet të ekzekutohen ende për të ruajtur grupin ). Në fakt, Operatori është krijuar për të thjeshtuar sa më shumë punën me aplikacionin brenda grupit, duke automatizuar ekzekutimin e detyrave operacionale që më parë duhej të zgjidheshin manualisht.
Si funksionojnë operatorët
ReplicaSets Kubernetes ju lejon të specifikoni numrin e dëshiruar të pods-ve që funksionojnë dhe kontrollorët sigurojnë që numri i tyre të ruhet (duke krijuar dhe fshirë pods). Një Operator punon në një mënyrë të ngjashme, duke shtuar një grup njohurish operacionale në një burim dhe kontrollues standard të Kubernetes që ju lejon të kryeni veprime shtesë për të mbështetur numrin e kërkuar të entiteteve të aplikacionit.
Si ndryshon kjo nga StatefulSets, i projektuar për aplikacione që kërkojnë që grupi t'u sigurojë burime të gjendjes si ruajtja e të dhënave ose IP statike? Për aplikacione të tilla, Operatorët mund të përdorin StatefulSets (në vend të ReplicaSets) si bazë, ofertë automatizimi shtesë: kryeni veprimet e nevojshme në rast përplasjeje, bëni kopje rezervë, përditësoni konfigurimin, etj.
Pra, si funksionon e gjithë kjo? Operatori është një demon menaxher që:
- abonohet në API të ngjarjes në Kubernetes;
- merr prej tij të dhëna për sistemin (për të ReplicaSets, pods, Sherbimet dhe kështu me radhë.);
- merr të dhëna për Burimet e Palës së Tretë (shih shembujt më poshtë);
- reagon ndaj pamjes/ndryshimit Burimet e Palës së Tretë (për shembull, për të ndryshuar madhësinë, për të ndryshuar versionin, e kështu me radhë);
- reagon ndaj ndryshimeve në gjendjen e sistemit (rreth tij ReplicaSets, pods, Sherbimet dhe kështu me radhë.);
- më e rëndësishmja:
- i bën thirrje Kubernetes API të krijojë gjithçka që i nevojitet (përsëri, të vetën ReplicaSets, pods, Sherbimet),
- kryen njëfarë magjie (për të thjeshtuar, mund të mendoni se Operatori hyn vetë në pods dhe thërret komanda, për shembull, për t'u bashkuar me një grup ose për të përmirësuar formatin e të dhënave kur përditëson një version).
Në fakt, siç shihet nga fotografia, Kubernetes thjesht i shtohet një aplikacion i veçantë (i rregullt shpërndarje с ReplicaSet), i cili quhet Operator. Ai jeton në një pod të zakonshëm (zakonisht vetëm një) dhe, si rregull, është përgjegjës vetëm për të Hapësira e emrave. Ky aplikacion operatori zbaton API-në e tij - edhe pse jo drejtpërdrejt, por përmes Burimet e Palës së Tretë në Kubernetes.
Kështu, pasi kemi krijuar në Hapësira e emrave Operator, ne mund ta shtojmë atë Burimet e Palës së Tretë.
Shembull për etjd (shih më poshtë për detaje):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Shembull për 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
Kërkesat për operatorët
CoreOS formuloi modelet kryesore të marra nga inxhinierët gjatë punës në Operatorë. Përkundër faktit se të gjithë Operatorët janë individualë (të krijuar për një aplikacion specifik me karakteristikat dhe nevojat e veta), krijimi i tyre duhet të bazohet në një lloj kuadri që imponon kërkesat e mëposhtme:
- Instalimi duhet të bëhet përmes një të vetme shpërndarje: kubectl krijoj -f SOME_OPERATOR_URL/deployment.yaml - dhe nuk kërkojnë veprime shtesë.
- Kur instaloni një Operator në Kubernetes, duhet të krijohet një lloj i ri i palës së tretë (ThirdPartyResource). Për të nisur instancat e aplikacionit (instancat e grupimit) dhe për t'i menaxhuar më tej ato (përditësimi i versioneve, ndryshimi i madhësisë, etj.), përdoruesi do të përdorë këtë lloj.
- Kurdoherë që është e mundur, duhet të përdorni primitivët e integruar në Kubernetes, si p.sh Sherbimet и ReplicaSetspër të përdorur kodin e mirë-testuar dhe të kuptueshëm.
- Kërkon përputhshmëri të prapambetur të operatorëve dhe mbështetje për versionet më të vjetra të burimeve të krijuara nga përdoruesit.
- Nëse Operatori hiqet, vetë aplikacioni duhet të vazhdojë të funksionojë pa ndryshime.
- Përdoruesit duhet të jenë në gjendje të përcaktojnë versionin e dëshiruar të aplikacionit dhe të orkestrojnë përditësimet e versionit të aplikacionit. Mungesa e përditësimeve të softuerit është një burim i zakonshëm i problemeve operative dhe të sigurisë, kështu që Operatorët duhet të ndihmojnë përdoruesit në këtë çështje.
- Operatorët duhet të testohen me një mjet si Chaos Monkey, i cili identifikon dështimet e mundshme në pods, konfigurime dhe rrjet.
etjd Operatori
Shembull i zbatimit të operatorit - Operatori etjd, në ditën e shpalljes së këtij koncepti. Konfigurimi i grupit etcd mund të jetë kompleks për shkak të nevojës për të ruajtur kuorumin, nevojës për të rikonfiguruar anëtarësimin në grup, për të krijuar kopje rezervë, etj. Për shembull, shkallëzimi manual i një grupi etcd do të thotë që ju duhet të krijoni një emër DNS për një anëtar të ri të grupimit, të filloni një entitet të ri etcd dhe të njoftoni grupin për anëtarin e ri (etjdctl anëtar shto). Në rastin e Operatorit, përdoruesi do të duhet vetëm të ndryshojë madhësinë e grupit - gjithçka tjetër do të ndodhë automatikisht.
Dhe meqenëse etcd u krijua gjithashtu në CoreOS, ishte mjaft logjike të shihej Operatori i tij të shfaqej fillimisht. Si punon ai? Logjika e operatorit etj përcaktohet nga tre komponentë:
- Vëzhgoni. Operatori monitoron gjendjen e grupit duke përdorur Kubernetes API.
- Analiza. Gjen dallimet midis statusit aktual dhe atij të dëshiruar (të përcaktuar nga konfigurimi i përdoruesit).
- Veprimi. Zgjidh dallimet e zbuluara duke përdorur API-të e shërbimit etcd dhe/ose Kubernetes.
Për të zbatuar këtë logjikë, funksionet janë përgatitur në Operator Krijo / Shkatërroj (krijimi dhe fshirja e anëtarëve të grupit etcd) dhe Resize (ndryshim në numrin e anëtarëve të grupit). Korrektësia e funksionimit të tij u kontrollua duke përdorur një mjet të krijuar në ngjashmërinë e Chaos Monkey nga Netflix, d.m.th. vrasjen e pods etcd rastësisht.
Për funksionimin e plotë të etcd, Operatori ofron veçori shtesë: Rikthim (krijimi automatik dhe i padukshëm për përdoruesit e kopjeve rezervë - në konfigurim mjafton të përcaktohet se sa shpesh duhet të bëhen dhe sa të ruhen - dhe restaurimi i mëvonshëm i të dhënave prej tyre) dhe upgrade (përditësimi i instalimeve etjd pa ndërprerje).
Si duket puna me një 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
Statusi aktual i operatorit etcd është një version beta, që kërkon Kubernetes 1.5.3+ dhe etcd 3.0+ për të ekzekutuar. Kodi burimor dhe dokumentacioni (duke përfshirë udhëzimet për përdorim) janë në dispozicion në .
Është krijuar një shembull tjetër i zbatimit nga CoreOS - , por është ende në versionin alfa (jo të gjitha tiparet e planifikuara janë zbatuar).
Statusi dhe perspektivat
Kanë kaluar 5 muaj nga shpallja e Kubernetes Operators. Ekzistojnë ende vetëm dy zbatime të disponueshme në depon zyrtare të CoreOS (për etcd dhe Prometheus). Të dy nuk kanë arritur ende versionet e tyre të qëndrueshme, por angazhimet vëzhgohen në baza ditore.
Zhvilluesit parashikojnë "një të ardhme në të cilën përdoruesit instalojnë Operatorët Postgres, Operatorët Cassandra ose Operatorët Redis në grupimet e tyre Kubernetes dhe të punojnë me entitetet e shkallëzueshme të këtyre aplikacioneve po aq lehtë sa vendosja e kopjeve të aplikacioneve në internet pa shtetësi është sot". Së pari Operatorët nga zhvilluesit e palëve të treta me të vërtetë filloi të shfaqej:
- nga UPMC Enterprises;
- nga Crunchy Data (shpallur në fund të marsit 2017);
- nga autorët e një sistemi të ruajtjes së të dhënave të shpërndarë bazuar në Ceph (Rook është në statusin alfa);
- nga SAP CCloud.
Në konferencën më të madhe evropiane të softuerit të lirë FOSDEM, e cila u zhvillua në shkurt 2017 në Bruksel, Josh Wood nga CoreOS njoftoi Operatorët në (një video është në dispozicion në lidhjen!), e cila duhet të kontribuojë në rritjen e popullaritetit të këtij koncepti në komunitetin më të gjerë të Open Source.
PS Faleminderit për interesimin tuaj në artikull! Abonohuni në qendrën tonë, për të mos humbur materiale dhe receta të reja mbi DevOps dhe administrimin e sistemit GNU/Linux - do t'i publikojmë rregullisht!
Burimi: www.habr.com