Masalah karo aplikasi stateful ing Kubernetes
Konfigurasi, Bukak lan njongko luwih saka aplikasi lan layanan gampang nalika nerangake kasus diklasifikasikaké minangka stateless, i.e. tanpa nyimpen data. Iku trep kanggo mbukak layanan kasebut ing Kubernetes, nggunakake API standar sawijining, amarga kabeh mengkono "metu saka kothak": miturut konfigurasi standar, tanpa nglibatno spesifik utawa sihir.
Cukup, kanggo ngluncurake limang salinan backend ing PHP/Ruby/Python ing kluster wadhah, sampeyan mung kudu nyiyapake server anyar kaping 5 lan nyalin sumber kasebut. Amarga kode sumber lan skrip init ana ing gambar, skala aplikasi tanpa negara dadi dhasar. Minangka penggemar kontainer lan arsitektur microservice ngerti, kangelan wiwit karo aplikasi stateful, i.e. kanthi ketekunan data kayata database lan cache (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Iki ditrapake kanggo loro piranti lunak sing independen ngetrapake kluster kuorum (contone, Percona XtraDB lan Cassandra), lan piranti lunak sing mbutuhake utilitas manajemen sing kapisah (kayata Redis, MySQL, PostgreSQL...).
Kesulitan muncul amarga kode sumber lan ngluncurake layanan ora cukup maneh - sampeyan kudu nindakake sawetara langkah maneh. Minimal, nyalin data lan/utawa gabung karo kluster. Luwih tepate, layanan kasebut mbutuhake pangerten babagan cara ngukur, nganyari lan ngatur ulang kanthi bener tanpa mundhut data utawa ora kasedhiya sauntara. Nganggep kabutuhan kasebut diarani "kawruh operasional".
Operator CoreOS
Kanggo "program" kawruh operasional, pungkasan taun pungkasan project CoreOS "kelas anyar saka piranti lunak" kanggo platform Kubernetes - Operators (saka basa Inggris "operasi", i.e. "operasi").
Operator nggunakake lan ndawakake kapabilitas inti Kubernetes (kalebu. StatefulSets, deleng prabédan ing ngisor iki) ngidini spesialis DevOps nambah kawruh operasional menyang kode aplikasi.
Tujuan Operator - nyedhiyakake pangguna karo API sing ngidini sampeyan ngatur macem-macem entitas aplikasi stateful ing kluster Kubernetes, tanpa mikir babagan apa sing ana ing sangisore tutup (data apa lan apa sing kudu ditindakake, prentah apa sing isih kudu ditindakake kanggo njaga kluster kasebut. ). Nyatane, Operator dirancang kanggo nyederhanakake karya kanthi aplikasi ing kluster sabisa-bisa, ngotomatisasi eksekusi tugas operasional sing sadurunge kudu ditanggulangi kanthi manual.
Cara Kerja Operator
ReplicaSets Kubernetes ngidini sampeyan nemtokake jumlah polong sing dipengini, lan pengontrol mesthekake yen nomer kasebut dijaga (kanthi nggawe lan mbusak polong). Operator dianggo kanthi cara sing padha, nambahake sakumpulan kawruh operasional menyang sumber lan pengontrol Kubernetes standar sing ngidini sampeyan nindakake tindakan tambahan kanggo ndhukung jumlah entitas aplikasi sing dibutuhake.
Carane iki beda saka StatefulSets, dirancang kanggo aplikasi sing mbutuhake kluster kanggo nyedhiyakake sumber daya stateful kayata panyimpenan data utawa IP statis? Kanggo aplikasi kasebut, Operator bisa nggunakake StatefulSets (tinimbang ReplicaSets) minangka dhasar, kurban otomatisasi tambahan: nindakake tumindak sing perlu yen ana kacilakan, gawe serep, nganyari konfigurasi, lsp.
Supaya carane kabeh iki bisa? Operator kasebut minangka daemon manajer sing:
- langganan API acara ing Kubernetes;
- nampa saka iku data babagan sistem (bab sawijining ReplicaSets, pods, layanan lan liya-liyane.);
- nampa data babagan Sumber Daya Pihak Katelu (ndeleng conto ing ngisor iki);
- nanggepi tampilan / owah-owahan Sumber Daya Pihak Katelu (contone, kanggo ngganti ukuran, ngganti versi, lan sapiturute);
- nanggepi owah-owahan ing negara sistem (babagan sawijining ReplicaSets, pods, layanan lan liya-liyane.);
- sing paling penting:
- nelpon API Kubernetes kanggo nggawe kabeh sing dibutuhake (maneh, dhewe ReplicaSets, pods, layanan...),
- nindakake sawetara Piandel (kanggo menakake, sampeyan bisa mikir sing Operator dadi menyang pods piyambak lan nelpon printah, Contone, kanggo nggabungake kluster utawa upgrade format data nalika nganyari versi).
Nyatane, kaya sing bisa dideleng saka gambar, aplikasi sing kapisah mung ditambahake menyang Kubernetes (reguler penyebaran prajurit с ReplicaSet), sing diarani Operator. Iku urip ing pod biasa (biasane mung siji) lan, minangka aturan, mung tanggung jawab kanggo sawijining Jeneng jeneng. Aplikasi operator iki ngetrapake API - sanajan ora langsung, nanging liwat Sumber Daya Pihak Katelu ing Kubernetes.
Mangkono, sawise kita wis digawe ing Jeneng jeneng Operator, kita bisa nambah Sumber Daya Pihak Katelu.
Tuladha kanggo etc (ndeleng ngisor kanggo rincian):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Conto kanggo 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
Requirements kanggo Operators
CoreOS ngrumusake pola utama sing dipikolehi dening insinyur nalika nggarap Operator. Sanajan kasunyatane kabeh Operator minangka individu (digawe kanggo aplikasi tartamtu kanthi karakteristik lan kabutuhan dhewe), nggawe kudu adhedhasar kerangka kerja sing ngetrapake syarat ing ngisor iki:
- Instalasi kudu rampung liwat siji penyebaran prajurit: kubectl nggawe -f SOME_OPERATOR_URL/deployment.yaml - lan ora mbutuhake tumindak tambahan.
- Nalika nginstal Operator ing Kubernetes, jinis pihak katelu sing anyar kudu digawe (Sumber Pihak Ketiga). Kanggo miwiti aplikasi instance (cluster instance) lan luwih ngatur (nganyari versi, ngowahi ukuran, etc.), pangguna bakal nggunakake jinis iki.
- Yen bisa, sampeyan kudu nggunakake primitif sing dibangun ing Kubernetes, kayata layanan и ReplicaSetsnggunakake kode sing wis diuji lan bisa dingerteni.
- Mbutuhake kompatibilitas mundur saka Operator lan dhukungan kanggo versi lawas saka sumber daya sing digawe pangguna.
- Yen Operator dibusak, aplikasi kasebut kudu terus dienggo tanpa owah-owahan.
- Pangguna kudu bisa nemtokake versi aplikasi sing dikarepake lan ngatur nganyari versi aplikasi. Kurang nganyari piranti lunak minangka sumber umum masalah operasional lan keamanan, mula Operator kudu ngewangi pangguna babagan iki.
- Operator kudu dites nganggo alat kaya Chaos Monkey, sing ngenali kegagalan potensial ing pods, konfigurasi, lan jaringan.
operator etc
Tuladha Implementasi Operator - Operator etcd, ing dina woro-woro konsep iki. Konfigurasi kluster etcd bisa dadi rumit amarga kudu njaga kuorum, kudu ngonfigurasi ulang anggota kluster, nggawe serep, lsp. Contone, skala kluster etcd kanthi manual tegese sampeyan kudu nggawe jeneng DNS kanggo anggota kluster anyar, miwiti entitas etcd anyar, lan menehi tandha kluster babagan anggota anyar (etcdctl anggota nambah). Ing kasus Operator, pangguna mung kudu ngganti ukuran kluster - kabeh bakal kelakon kanthi otomatis.
Lan wiwit etcd uga digawe ing CoreOS, iku cukup logis kanggo ndeleng Operator katon pisanan. Piye cara kerjane? Logika operator etc ditemtokake dening telung komponen:
- Mirsani. Operator ngawasi kahanan kluster nggunakake API Kubernetes.
- Analisis. Nemokake beda antarane status saiki lan sing dikarepake (ditetepake dening konfigurasi pangguna).
- Tumindak. Ngatasi beda sing dideteksi nggunakake API layanan etcd lan/utawa Kubernetes.
Kanggo ngleksanakake logika iki, fungsi wis disiapake ing Operator Nggawe / Numpes (nggawe lan mbusak anggota kluster etcd) lan Ngowahi ukuran (owah-owahan ing jumlah anggota kluster). Kebeneran operasi kasebut dicenthang nggunakake sarana sing digawe kanthi mirip Chaos Monkey saka Netflix, yaiku. mateni polong etcd kanthi acak.
Kanggo operasi lengkap etcd, Operator nyedhiyakake fitur tambahan: Gawe serep (otomatis lan ora katon kanggo pangguna nggawe salinan serep - ing konfigurasi cukup kanggo nemtokake sepira kerepe nggawe lan pira sing disimpen - lan pemugaran data sabanjure) lan upgrade (nganyari instalasi etcd tanpa downtime).
Kepiye cara nggarap 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
Status saiki etcd Operator versi beta, mbutuhake Kubernetes 1.5.3+ lan etcd 3.0+ kanggo mbukak. Kode sumber lan dokumentasi (kalebu pandhuan kanggo nggunakake) kasedhiya ing .
Implementasi conto liyane saka CoreOS wis digawe - , nanging isih ana ing versi alpha (ora kabeh fitur sing direncanakake wis ditindakake).
Status lan prospek
5 sasi wis liwati wiwit pengumuman Operator Kubernetes. Isih ana mung rong implementasi sing kasedhiya ing repositori CoreOS resmi (kanggo etcd lan Prometheus). Loro-lorone durung tekan versi stabil, nanging komitmen diamati saben dina.
Pangembang mbayangake "masa depan sing pangguna nginstal Operator Postgres, Operator Cassandra utawa Operator Redis ing kluster Kubernetes lan nggarap entitas sing bisa diukur saka aplikasi kasebut kanthi gampang kaya nggunakake replika aplikasi web tanpa negara saiki." Pisanan Operator saka pangembang pihak katelu tenan wiwit katon:
- saka UPMC Enterprises;
- saka Data Crunchy (diumumake pungkasan Maret 2017);
- saka penulis sistem panyimpenan data sing disebarake adhedhasar Ceph (Rook ing status alpha);
- saka SAP CCloud.
Ing konferensi piranti lunak gratis Eropa paling gedhe FOSDEM, sing ditindakake ing Februari 2017 ing Brussels, Josh Wood saka CoreOS ngumumake Operator ing (video kasedhiya ing link!), Sing kudu nyumbang kanggo tuwuhing popularitas konsep iki ing komunitas Open Source sing luwih akeh.
PS Matur nuwun kanggo kapentingan ing artikel! Langganan hub kita, supaya ora kantun bahan lan resep anyar ing DevOps lan administrasi sistem GNU/Linux - kita bakal nerbitake kanthi rutin!
Source: www.habr.com