Ang problema sa stateful application sa Kubernetes
Ang pagsasaayos, paglulunsad at karagdagang pag-scale ng mga application at serbisyo ay madali pagdating sa mga kaso na inuri bilang stateless, i.e. nang hindi nagse-save ng data. Maginhawang patakbuhin ang mga naturang serbisyo sa Kubernetes, gamit ang mga karaniwang API nito, dahil lahat ng bagay ay nangyayari βout of the boxβ: ayon sa mga karaniwang configuration, nang hindi kinasasangkutan ng anumang partikular o magic.
Sa madaling salita, para maglunsad ng lima pang kopya ng backend sa PHP/Ruby/Python sa isang kumpol ng mga container, kailangan mo lang mag-set up ng bagong server nang 5 beses at kopyahin ang mga source. Dahil ang source code at init script ay nasa larawan, ang pag-scale ng stateless na application ay nagiging ganap na elementarya. Tulad ng alam ng mga tagahanga ng mga container at microservice architecture, nagsisimula ang kahirapan stateful apps, ibig sabihin. na may pagtitiyaga ng data tulad ng mga database at cache (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Nalalapat ito sa parehong software na independyenteng nagpapatupad ng isang quorum cluster (halimbawa, Percona XtraDB at Cassandra), at software na nangangailangan ng magkahiwalay na mga utility sa pamamahala (gaya ng Redis, MySQL, PostgreSQL...).
Ang mga paghihirap ay lumitaw dahil ang source code at paglulunsad ng serbisyo ay hindi na sapat - kailangan mong magsagawa ng ilang karagdagang mga hakbang. Hindi bababa sa, kopyahin ang data at/o sumali sa cluster. Mas tiyak, ang mga serbisyong ito ay nangangailangan ng pag-unawa sa kung paano maayos na sukatin, i-update at muling i-configure ang mga ito nang walang pagkawala ng data o pansamantalang hindi available. Ang pagsasaalang-alang sa mga pangangailangang ito ay tinatawag na "kaalaman sa pagpapatakbo".
Mga Operator ng CoreOS
Upang "iprograma" ang kaalaman sa pagpapatakbo, huling bahagi ng nakaraang taon ang proyekto ng CoreOS "isang bagong klase ng software" para sa platform ng Kubernetes - Mga Operator (mula sa English na "operasyon", ibig sabihin, "operasyon").
Mga operator na gumagamit at nagpapalawak ng mga pangunahing kakayahan ng Kubernetes (kabilang ang. StatefulSets, tingnan ang pagkakaiba sa ibaba) payagan ang mga espesyalista sa DevOps na magdagdag ng kaalaman sa pagpapatakbo sa code ng aplikasyon.
Layunin ng Operator β bigyan ang user ng API na nagbibigay-daan sa iyong pamahalaan ang maramihang stateful na application entity sa isang Kubernetes cluster, nang hindi iniisip kung ano ang nasa ilalim ng hood (anong data at kung ano ang gagawin dito, anong mga command ang kailangan pa ring isagawa upang mapanatili ang cluster ). Sa katunayan, ang Operator ay idinisenyo upang gawing simple ang trabaho sa application sa loob ng cluster hangga't maaari, na nag-automate sa pagpapatupad ng mga gawain sa pagpapatakbo na dati ay kailangang lutasin nang manu-mano.
Paano Gumagana ang mga Operator
Mga ReplicaSets Binibigyang-daan ka ng Kubernetes na tukuyin ang nais na bilang ng mga tumatakbong pod, at tinitiyak ng mga controller na ang kanilang numero ay pinananatili (sa pamamagitan ng paggawa at pagtanggal ng mga pod). Gumagana ang isang Operator sa katulad na paraan, nagdaragdag ng isang hanay ng kaalaman sa pagpapatakbo sa isang karaniwang mapagkukunan at controller ng Kubernetes na nagbibigay-daan sa iyong magsagawa ng mga karagdagang aksyon upang suportahan ang kinakailangang bilang ng mga entity ng application.
Paano ito naiiba sa StatefulSets, na idinisenyo para sa mga application na nangangailangan ng cluster na magbigay sa kanila ng stateful resources gaya ng data storage o static IPs? Para sa mga naturang application, maaaring gamitin ng mga Operator StatefulSets (sa halip ng Mga ReplicaSets) bilang batayan, pag-aalok karagdagang automation: gawin ang mga kinakailangang aksyon sa kaso ng mga pag-crash, gumawa ng mga backup, i-update ang configuration, atbp.
Kaya, paano gumagana ang lahat ng ito? Ang operator ay isang manager daemon na:
- nag-subscribe sa API ng kaganapan sa Kubernetes;
- tumatanggap mula dito ng data tungkol sa system (tungkol sa Mga ReplicaSets, pods, Serbisyo at iba pa.);
- tumatanggap ng data tungkol sa Mga Mapagkukunan ng Third Party (tingnan ang mga halimbawa sa ibaba);
- tumutugon sa hitsura/pagbabago Mga Mapagkukunan ng Third Party (halimbawa, upang baguhin ang laki, baguhin ang bersyon, at iba pa);
- tumutugon sa mga pagbabago sa estado ng system (tungkol sa Mga ReplicaSets, pods, Serbisyo at iba pa.);
- pinakamahalaga:
- tumatawag sa Kubernetes API upang likhain ang lahat ng kailangan nito (muli, sarili nito Mga ReplicaSets, pods, Serbisyo...),
- gumaganap ng ilang mahika (upang pasimplehin, maaari mong isipin na ang Operator mismo ay pumupunta sa mga pod at tumatawag ng mga utos, halimbawa, upang sumali sa isang cluster o upang i-upgrade ang format ng data kapag nag-a-update ng isang bersyon).
Sa katunayan, tulad ng makikita mula sa larawan, ang isang hiwalay na aplikasyon ay idinagdag lamang sa Kubernetes (isang regular paglawak Ρ ReplicaSet), na tinatawag na Operator. Nakatira ito sa isang ordinaryong pod (karaniwan ay isa lang) at, bilang panuntunan, ay responsable lamang para dito Namespace. Ang operator application na ito ay nagpapatupad ng API nito - bagaman hindi direkta, ngunit sa pamamagitan ng Mga Mapagkukunan ng Third Party sa Kubernetes.
Kaya, pagkatapos naming lumikha sa Namespace Operator, maaari naming idagdag ito Mga Mapagkukunan ng Third Party.
Halimbawa para sa etcd (tingnan sa ibaba para sa mga detalye):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Halimbawa para sa 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
Mga Kinakailangan para sa mga Operator
Binuo ng CoreOS ang mga pangunahing pattern na nakuha ng mga inhinyero habang nagtatrabaho sa Mga Operator. Sa kabila ng katotohanan na ang lahat ng Operator ay indibidwal (nilikha para sa isang partikular na aplikasyon na may sarili nitong mga katangian at pangangailangan), ang kanilang paglikha ay dapat na batay sa isang uri ng balangkas na nagpapataw ng mga sumusunod na kinakailangan:
- Ang pag-install ay dapat gawin sa pamamagitan ng isang solong paglawak: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - at hindi nangangailangan ng mga karagdagang aksyon.
- Kapag nag-i-install ng Operator sa Kubernetes, dapat gumawa ng bagong uri ng third-party (ThirdPartyResource). Upang ilunsad ang mga instance ng application (mga cluster instance) at higit pang pamahalaan ang mga ito (pag-update ng mga bersyon, pagbabago ng laki, atbp.), gagamitin ng user ang ganitong uri.
- Hangga't maaari, dapat mong gamitin ang mga primitive na nakapaloob sa Kubernetes, gaya ng Serbisyo ΠΈ Mga ReplicaSetsupang gumamit ng mahusay na nasubok at nauunawaan na code.
- Nangangailangan ng backward compatibility ng mga Operator at suporta para sa mga mas lumang bersyon ng mga mapagkukunang ginawa ng user.
- Kung ang Operator ay tinanggal, ang application mismo ay dapat na patuloy na gumana nang walang mga pagbabago.
- Ang mga gumagamit ay dapat na matukoy ang nais na bersyon ng application at ayusin ang mga update sa bersyon ng application. Ang kakulangan ng mga update sa software ay isang karaniwang pinagmumulan ng mga problema sa pagpapatakbo at seguridad, kaya dapat tulungan ng mga Operator ang mga user sa bagay na ito.
- Dapat subukan ang mga operator gamit ang isang tool tulad ng Chaos Monkey, na tumutukoy sa mga potensyal na pagkabigo sa mga pod, configuration, at network.
etcd Operator
Halimbawa ng Pagpapatupad ng Operator - etcd Operator, sa araw ng pag-anunsyo ng konseptong ito. Ang configuration ng etcd cluster ay maaaring maging kumplikado dahil sa pangangailangan na mapanatili ang quorum, ang pangangailangan na muling i-configure ang cluster membership, lumikha ng mga backup, atbp. Halimbawa, ang manu-manong pag-scale ng etcd cluster ay nangangahulugan na kailangan mong lumikha ng DNS name para sa isang bagong miyembro ng cluster, magsimula ng bagong etcd entity, at alertuhan ang cluster tungkol sa bagong miyembro (etcdctl member add). Sa kaso ng Operator, kakailanganin lamang ng user na baguhin ang laki ng kumpol - lahat ng iba pa ay awtomatikong mangyayari.
At dahil ang etcd ay nilikha din sa CoreOS, medyo lohikal na makita ang Operator nito na unang lumitaw. Paano siya nagtatrabaho? Logic ng operator atbp ay tinutukoy ng tatlong sangkap:
- Magmasid. Sinusubaybayan ng operator ang estado ng cluster gamit ang Kubernetes API.
- Pagsusuri. Naghahanap ng mga pagkakaiba sa pagitan ng kasalukuyang katayuan at ng ninanais (tinukoy ng configuration ng user).
- Aksyon. Lutasin ang mga nakitang pagkakaiba gamit ang etcd at/o mga API ng serbisyo ng Kubernetes.
Upang ipatupad ang lohika na ito, ang mga function ay inihanda sa Operator Lumikha / Wasakin (paglikha at pagtanggal ng mga miyembro ng etcd cluster) at Baguhin ang laki (pagbabago sa bilang ng mga miyembro ng cluster). Ang kawastuhan ng operasyon nito ay sinuri gamit ang isang utility na nilikha sa pagkakahawig ng Chaos Monkey mula sa Netflix, i.e. random na pagpatay ng etcd pods.
Para sa buong operasyon ng etcd, ang Operator ay nagbibigay ng mga karagdagang tampok: Backup (awtomatiko at hindi nakikita ng mga gumagamit ang paglikha ng mga backup na kopya - sa config ay sapat na upang matukoy kung gaano kadalas gawin ang mga ito at kung gaano karaming iimbak - at kasunod na pagpapanumbalik ng data mula sa kanila) at I-upgrade (pag-update ng etcd installation nang walang downtime).
Ano ang hitsura ng pagtatrabaho sa isang 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
Ang kasalukuyang status ng etcd Operator ay isang beta na bersyon, na nangangailangan ng Kubernetes 1.5.3+ at etcd 3.0+ upang tumakbo. Ang source code at dokumentasyon (kabilang ang mga tagubilin para sa paggamit) ay makukuha sa .
Ang isa pang halimbawa ng pagpapatupad mula sa CoreOS ay nilikha - , ngunit nasa alpha version pa rin ito (hindi lahat ng nakaplanong feature ay naipatupad).
Katayuan at mga prospect
5 buwan na ang lumipas mula nang ipahayag ang mga Kubernetes Operators. Mayroon pa ring dalawang pagpapatupad na magagamit sa opisyal na imbakan ng CoreOS (para sa etcd at Prometheus). Parehong hindi pa nakakarating sa kanilang mga stable na bersyon, ngunit ang mga commit ay sinusunod araw-araw.
Naiisip ng mga developer ang "isang hinaharap kung saan ang mga user ay nag-i-install ng mga Postgres Operators, Cassandra Operators o Redis Operators sa kanilang mga Kubernetes clusters at nakikipagtulungan sa mga nasusukat na entity ng mga application na ito nang kasingdali ng pag-deploy ng mga replika ng stateless na mga web application ngayon." Una Mga operator mula sa mga developer ng third party talagang nagsimulang lumitaw:
- mula sa UPMC Enterprises;
- mula sa Crunchy Data (inanunsyo noong huling bahagi ng Marso 2017);
- mula sa mga may-akda ng isang distributed data storage system batay sa Ceph (Rook ay nasa alpha status);
- mula sa SAP CCloud.
Sa pinakamalaking European free software conference na FOSDEM, na naganap noong Pebrero 2017 sa Brussels, inihayag ni Josh Wood mula sa CoreOS ang mga Operator sa (may makukuhang video sa link!), na dapat mag-ambag sa paglago ng kasikatan ng konseptong ito sa mas malawak na komunidad ng Open Source.
PS Salamat sa iyong interes sa artikulo! Mag-subscribe sa aming hub, para hindi makaligtaan ang mga bagong materyales at recipe sa DevOps at GNU/Linux system administration - regular naming ilalathala ang mga ito!
Pinagmulan: www.habr.com