Masalah dengan aplikasi stateful dalam Kubernetes
Konfigurasi, pelancaran dan penskalaan lanjut aplikasi dan perkhidmatan adalah mudah apabila melibatkan kes yang diklasifikasikan sebagai tanpa kewarganegaraan, i.e. tanpa menyimpan data. Adalah mudah untuk menjalankan perkhidmatan sedemikian dalam Kubernetes, menggunakan API standardnya, kerana segala-galanya berlaku "di luar kotak": mengikut konfigurasi standard, tanpa melibatkan sebarang spesifik atau sihir.
Ringkasnya, untuk melancarkan lima lagi salinan bahagian belakang dalam PHP/Ruby/Python dalam kelompok bekas, anda hanya perlu menyediakan pelayan baharu 5 kali dan menyalin sumber. Memandangkan kedua-dua kod sumber dan skrip init berada dalam imej, penskalaan aplikasi tanpa negara menjadi asas sepenuhnya. Seperti yang diketahui oleh peminat kontena dan seni bina perkhidmatan mikro, kesukaran bermula dengan aplikasi stateful, iaitu dengan kegigihan data seperti pangkalan data dan cache (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Ini terpakai kepada kedua-dua perisian yang melaksanakan kelompok kuorum secara bebas (contohnya, Percona XtraDB dan Cassandra), dan perisian yang memerlukan utiliti pengurusan berasingan (seperti Redis, MySQL, PostgreSQL...).
Kesukaran timbul kerana kod sumber dan pelancaran perkhidmatan tidak lagi mencukupi - anda perlu melakukan beberapa langkah lagi. Sekurang-kurangnya, salin data dan/atau sertai kluster. Lebih tepat lagi, perkhidmatan ini memerlukan pemahaman tentang cara menskala, mengemas kini dan mengkonfigurasi semula dengan betul tanpa kehilangan data atau ketidaksediaan sementara. Mengambil kira keperluan ini dipanggil "pengetahuan operasi".
Pengendali CoreOS
Untuk "memprogram" pengetahuan operasi, akhir tahun lepas projek CoreOS βsebuah kelas perisian baharuβ untuk platform Kubernetes - Operator (dari bahasa Inggeris βoperationβ, iaitu βoperationβ).
Operator yang menggunakan dan memperluaskan keupayaan teras Kubernetes (termasuk. StatefulSets, lihat perbezaan di bawah) membenarkan pakar DevOps menambah pengetahuan operasi pada kod aplikasi.
Tujuan Operator β menyediakan pengguna dengan API yang membolehkan anda mengurus berbilang entiti aplikasi stateful dalam gugusan Kubernetes, tanpa memikirkan apa yang ada di bawah hud (data apa dan apa yang perlu dilakukan dengannya, apakah arahan yang masih perlu dilaksanakan untuk mengekalkan gugusan ). Malah, Operator direka bentuk untuk memudahkan kerja dengan aplikasi dalam kelompok sebanyak mungkin, mengautomasikan pelaksanaan tugas operasi yang sebelum ini perlu diselesaikan secara manual.
Cara Pengendali Berfungsi
ReplicaSets Kubernetes membenarkan anda untuk menentukan bilangan pod berjalan yang diingini, dan pengawal memastikan bahawa nombornya dikekalkan (dengan mencipta dan memadam pod). Pengendali berfungsi dengan cara yang sama, menambahkan set pengetahuan operasi pada sumber dan pengawal Kubernetes standard yang membolehkan anda melakukan tindakan tambahan untuk menyokong bilangan entiti aplikasi yang diperlukan.
Bagaimana ini berbeza daripada StatefulSets, direka untuk aplikasi yang memerlukan kluster untuk menyediakan mereka dengan sumber berstatus seperti storan data atau IP statik? Untuk aplikasi sedemikian, Operator boleh menggunakan StatefulSets (sebaliknya ReplicaSets) sebagai asas, menawarkan automasi tambahan: lakukan tindakan yang perlu sekiranya berlaku ranap sistem, buat sandaran, kemas kini konfigurasi, dsb.
Oleh itu, bagaimana semua ini berfungsi? Pengendali ialah daemon pengurus yang:
- melanggan API acara dalam Kubernetes;
- menerima daripadanya data tentang sistem (tentangnya ReplicaSets, buah, Perkhidmatan dan sebagainya.);
- menerima data tentang Sumber Pihak Ketiga (lihat contoh di bawah);
- bertindak balas terhadap penampilan/perubahan Sumber Pihak Ketiga (contohnya, untuk menukar saiz, menukar versi, dan sebagainya);
- bertindak balas terhadap perubahan dalam keadaan sistem (tentangnya ReplicaSets, buah, Perkhidmatan dan sebagainya.);
- yang paling penting:
- memanggil API Kubernetes untuk mencipta semua yang diperlukannya (sekali lagi, miliknya ReplicaSets, buah, Perkhidmatan...),
- melakukan beberapa keajaiban (untuk memudahkan, anda boleh berfikir bahawa Operator pergi ke pod sendiri dan memanggil arahan, contohnya, untuk menyertai kluster atau untuk menaik taraf format data semasa mengemas kini versi).
Malah, seperti yang dapat dilihat dari gambar, aplikasi berasingan hanya ditambahkan pada Kubernetes (aplikasi biasa Deployment Ρ ReplicaSet), yang dipanggil Operator. Ia tinggal dalam pod biasa (biasanya hanya satu) dan, sebagai peraturan, hanya bertanggungjawab untuknya Ruang nama. Aplikasi pengendali ini melaksanakan APInya - walaupun tidak secara langsung, tetapi melalui Sumber Pihak Ketiga dalam Kubernetes.
Oleh itu, selepas kami mencipta dalam Ruang nama Operator, kita boleh menambahnya Sumber Pihak Ketiga.
Contoh untuk etcd (lihat di bawah untuk butiran):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Contoh untuk 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
Keperluan untuk Operator
CoreOS merumuskan corak utama yang diperoleh oleh jurutera semasa bekerja pada Operator. Walaupun fakta bahawa semua Pengendali adalah individu (dicipta untuk aplikasi tertentu dengan ciri dan keperluannya sendiri), penciptaan mereka mestilah berdasarkan sejenis rangka kerja yang mengenakan keperluan berikut:
- Pemasangan mesti dilakukan melalui satu Deployment: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - dan tidak memerlukan tindakan tambahan.
- Apabila memasang Operator dalam Kubernetes, jenis pihak ketiga yang baharu mesti dibuat (Sumber Pihak Ketiga). Untuk melancarkan tika aplikasi (contoh kelompok) dan mengurusnya selanjutnya (mengemas kini versi, mengubah saiz, dll.), pengguna akan menggunakan jenis ini.
- Apabila boleh, anda harus menggunakan primitif yang terbina dalam Kubernetes, seperti Perkhidmatan ΠΈ ReplicaSetsuntuk menggunakan kod yang telah diuji dengan baik dan boleh difahami.
- Memerlukan keserasian belakang Operator dan sokongan untuk versi lama sumber yang dicipta pengguna.
- Jika Operator dialih keluar, aplikasi itu sendiri harus terus berfungsi tanpa perubahan.
- Pengguna harus dapat menentukan versi aplikasi yang dikehendaki dan mengatur kemas kini versi aplikasi. Kekurangan kemas kini perisian adalah punca biasa masalah operasi dan keselamatan, jadi Operator mesti membantu pengguna dalam perkara ini.
- Operator harus diuji dengan alat seperti Chaos Monkey, yang mengenal pasti potensi kegagalan dalam pod, konfigurasi dan rangkaian.
etcd Operator
Contoh Pelaksanaan Operator - Pengendali dsb, pada hari pengumuman konsep ini. Konfigurasi kluster etcd boleh menjadi rumit kerana keperluan untuk mengekalkan kuorum, keperluan untuk mengkonfigurasi semula keahlian kluster, membuat sandaran, dsb. Contohnya, menskala kluster etcd secara manual bermakna anda perlu mencipta nama DNS untuk ahli kluster baharu, memulakan entiti etcd baharu dan memaklumkan kluster tentang ahli baharu (tambah ahli etcdctl). Dalam kes Operator, pengguna hanya perlu menukar saiz kelompok - segala-galanya akan berlaku secara automatik.
Dan kerana etcd juga dicipta dalam CoreOS, agak logik untuk melihat Operatornya muncul dahulu. Bagaimana dia bekerja? Logik operator dsb ditentukan oleh tiga komponen:
- Memerhati. Operator memantau keadaan kluster menggunakan API Kubernetes.
- Analisis. Mencari perbezaan antara status semasa dan yang dikehendaki (ditakrifkan oleh konfigurasi pengguna).
- Tindakan. Menyelesaikan perbezaan yang dikesan menggunakan API perkhidmatan etcd dan/atau Kubernetes.
Untuk melaksanakan logik ini, fungsi telah disediakan dalam Operator Cipta/Hancurkan (membuat dan memadam ahli kluster etcd) dan Saiz semula (perubahan bilangan ahli kluster). Ketepatan operasinya telah disemak menggunakan utiliti yang dibuat dalam rupa Chaos Monkey daripada Netflix, i.e. membunuh pod etcd secara rawak.
Untuk operasi penuh etcd, Operator menyediakan ciri tambahan: Backup (automatik dan tidak dapat dilihat oleh pengguna membuat salinan sandaran - dalam konfigurasi ia cukup untuk menentukan berapa kerap dibuat dan berapa banyak untuk disimpan - dan pemulihan data berikutnya daripadanya) dan Naik taraf (mengemas kini pemasangan etcd tanpa downtime).
Apakah rupa kerja dengan 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 semasa Operator etcd ialah versi beta, memerlukan Kubernetes 1.5.3+ dan etcd 3.0+ untuk dijalankan. Kod sumber dan dokumentasi (termasuk arahan penggunaan) boleh didapati di .
Satu lagi contoh pelaksanaan daripada CoreOS telah dibuat - , tetapi ia masih dalam versi alfa (tidak semua ciri yang dirancang telah dilaksanakan).
Status dan prospek
5 bulan telah berlalu sejak pengumuman Pengendali Kubernetes. Masih terdapat hanya dua pelaksanaan yang tersedia dalam repositori CoreOS rasmi (untuk etcd dan Prometheus). Kedua-duanya belum mencapai versi stabil mereka, tetapi komit diperhatikan setiap hari.
Pembangun membayangkan "masa depan di mana pengguna memasang Operator Postgres, Operator Cassandra atau Operator Redis pada kelompok Kubernetes mereka dan bekerja dengan entiti berskala aplikasi ini semudah menggunakan replika aplikasi web tanpa negara seperti hari ini." Pertama Operator daripada pembangun pihak ketiga benar-benar mula muncul:
- daripada UPMC Enterprises;
- daripada Crunchy Data (diumumkan lewat Mac 2017);
- daripada pengarang sistem storan data teragih berdasarkan Ceph (Rook berada dalam status alfa);
- daripada SAP CCloud.
Pada persidangan perisian percuma Eropah terbesar FOSDEM, yang berlangsung pada Februari 2017 di Brussels, Josh Wood daripada CoreOS mengumumkan Operator di (video boleh didapati di pautan!), yang sepatutnya menyumbang kepada pertumbuhan populariti konsep ini dalam komuniti Sumber Terbuka yang lebih luas.
PS Terima kasih kerana berminat dengan artikel itu! Langgan hab kami, supaya tidak terlepas bahan dan resipi baharu pada DevOps dan pentadbiran sistem GNU/Linux - kami akan menerbitkannya dengan kerap!
Sumber: www.habr.com