Masalah dengan aplikasi stateful di Kubernetes
Konfigurasi, peluncuran, dan penskalaan lebih lanjut dari aplikasi dan layanan menjadi mudah jika menyangkut kasus yang diklasifikasikan sebagai tanpa kewarganegaraan, yaitu. tanpa menyimpan data. Lebih mudah untuk menjalankan layanan seperti itu di Kubernetes, menggunakan API standarnya, karena semuanya terjadi “di luar kotak”: sesuai dengan konfigurasi standar, tanpa melibatkan hal spesifik atau keajaiban apa pun.
Sederhananya, untuk meluncurkan lima salinan backend lagi di PHP/Ruby/Python dalam sekelompok container, Anda hanya perlu menyiapkan server baru 5 kali dan menyalin sumbernya. Karena kode sumber dan skrip init ada dalam gambar, penskalaan aplikasi tanpa kewarganegaraan menjadi hal yang sangat mendasar. Seperti yang diketahui oleh para penggemar container dan arsitektur layanan mikro, kesulitannya dimulai dari aplikasi berstatus tinggi, yaitu. dengan persistensi data seperti database dan cache (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Hal ini berlaku untuk perangkat lunak yang secara independen mengimplementasikan klaster kuorum (misalnya, Percona XtraDB dan Cassandra), dan perangkat lunak yang memerlukan utilitas manajemen terpisah (seperti Redis, MySQL, PostgreSQL...).
Kesulitan muncul karena kode sumber dan peluncuran layanan saja tidak cukup - Anda perlu melakukan beberapa langkah lagi. Minimal, salin data dan/atau bergabung dengan cluster. Lebih tepatnya, layanan ini memerlukan pemahaman tentang cara menskalakan, memperbarui, dan mengkonfigurasi ulang dengan benar tanpa kehilangan data atau ketidaktersediaan sementara. Mempertimbangkan kebutuhan ini disebut “pengetahuan operasional”.
Operator CoreOS
Untuk "memprogram" pengetahuan operasional, akhir tahun lalu proyek CoreOS “perangkat lunak kelas baru” untuk platform Kubernetes - Operator (dari bahasa Inggris “operasi”, yaitu “operasi”).
Operator yang menggunakan dan memperluas kemampuan inti Kubernetes (termasuk. Set Stateful, lihat perbedaannya di bawah) memungkinkan spesialis DevOps menambahkan pengetahuan operasional ke kode aplikasi.
Tujuan Operator — menyediakan API kepada pengguna yang memungkinkan Anda mengelola beberapa entitas aplikasi stateful dalam cluster Kubernetes, tanpa memikirkan apa yang ada di baliknya (data apa dan apa yang harus dilakukan dengannya, perintah apa yang masih perlu dijalankan untuk memelihara cluster ). Faktanya, Operator dirancang untuk menyederhanakan pekerjaan dengan aplikasi di dalam cluster, mengotomatiskan pelaksanaan tugas operasional yang sebelumnya harus diselesaikan secara manual.
Cara Kerja Operator
ReplikaSet Kubernetes memungkinkan Anda menentukan jumlah pod yang sedang berjalan, dan pengontrol memastikan bahwa jumlahnya tetap terjaga (dengan membuat dan menghapus pod). Operator bekerja dengan cara yang sama, menambahkan sekumpulan pengetahuan operasional ke sumber daya dan pengontrol Kubernetes standar yang memungkinkan Anda melakukan tindakan tambahan untuk mendukung jumlah entitas aplikasi yang diperlukan.
Apa bedanya dengan Set Stateful, dirancang untuk aplikasi yang memerlukan cluster untuk menyediakan sumber daya stateful seperti penyimpanan data atau IP statis? Untuk aplikasi seperti itu, Operator dapat menggunakan Set Stateful (bukannya ReplikaSet) sebagai dasar, penawaran otomatisasi tambahan: melakukan tindakan yang diperlukan jika terjadi kerusakan, membuat cadangan, memperbarui konfigurasi, dll.
Dengan demikian, bagaimana cara kerja semua ini? Operator adalah daemon manajer yang:
- berlangganan API acara di Kubernetes;
- menerima darinya data tentang sistem (tentang sistemnya ReplikaSet, polong, Layanan dan seterusnya.);
- menerima data tentang Sumber Daya Pihak Ketiga (lihat contoh di bawah);
- bereaksi terhadap penampilan/perubahan Sumber Daya Pihak Ketiga (misalnya untuk mengubah ukuran, mengubah versi, dan sebagainya);
- bereaksi terhadap perubahan keadaan sistem (tentangnya ReplikaSet, polong, Layanan dan seterusnya.);
- yang paling penting:
- memanggil API Kubernetes untuk membuat semua yang dibutuhkannya (sekali lagi, miliknya sendiri ReplikaSet, polong, Layanan...),
- melakukan beberapa keajaiban (untuk menyederhanakan, Anda dapat berpikir bahwa Operator masuk ke dalam pod itu sendiri dan memanggil perintah, misalnya, untuk bergabung dengan sebuah cluster atau untuk meningkatkan format data saat memperbarui versi).
Faktanya, seperti yang dapat dilihat dari gambar, sebuah aplikasi terpisah ditambahkan ke Kubernetes (aplikasi biasa Penyebaran с Set Replika), yang disebut Operator. Ia hidup dalam kelompok biasa (biasanya hanya satu) dan, biasanya, hanya bertanggung jawab atas dirinya sendiri Namespace. Aplikasi operator ini mengimplementasikan API-nya - meskipun tidak secara langsung, tetapi melalui Sumber Daya Pihak Ketiga di Kubernetes.
Jadi, setelah kita membuatnya Namespace Operator, kita bisa menambahkannya Sumber Daya Pihak Ketiga.
Contoh untuk dlld (lihat di bawah untuk detailnya):
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
Persyaratan untuk Operator
CoreOS merumuskan pola-pola utama yang diperoleh para insinyur saat bekerja pada Operator. Terlepas dari kenyataan bahwa semua Operator bersifat individual (dibuat untuk aplikasi tertentu dengan karakteristik dan kebutuhannya sendiri), pembuatannya harus didasarkan pada semacam kerangka kerja yang memberlakukan persyaratan berikut:
- Instalasi harus dilakukan melalui satu Penyebaran: kubectl buat -f SOME_OPERATOR_URL/deployment.yaml - dan tidak memerlukan tindakan tambahan.
- Saat memasang Operator di Kubernetes, tipe pihak ketiga baru harus dibuat (Sumber Daya Pihak Ketiga). Untuk meluncurkan instance aplikasi (instans cluster) dan mengelolanya lebih lanjut (memperbarui versi, mengubah ukuran, dll.), pengguna akan menggunakan tipe ini.
- Jika memungkinkan, Anda harus menggunakan primitif yang ada di dalam Kubernetes, seperti Layanan и ReplikaSetuntuk menggunakan kode yang telah teruji dan dapat dimengerti.
- Memerlukan kompatibilitas mundur Operator dan dukungan untuk versi lama sumber daya buatan pengguna.
- Jika Operator dihapus, aplikasi itu sendiri akan terus berfungsi tanpa perubahan.
- Pengguna harus dapat menentukan versi aplikasi yang diinginkan dan mengatur pembaruan versi aplikasi. Kurangnya pembaruan perangkat lunak merupakan sumber umum masalah operasional dan keamanan, sehingga Operator harus membantu pengguna dalam hal ini.
- Operator harus diuji dengan alat seperti Chaos Monkey, yang mengidentifikasi potensi kegagalan pada pod, konfigurasi, dan jaringan.
Operator dll
Contoh Implementasi Operator - Operator dll, pada hari pengumuman konsep ini. Konfigurasi klaster etcd bisa jadi rumit karena kebutuhan untuk mempertahankan kuorum, kebutuhan untuk mengkonfigurasi ulang keanggotaan klaster, membuat cadangan, dll. Misalnya, menskalakan klaster etcd secara manual berarti Anda perlu membuat nama DNS untuk anggota klaster baru, memulai entitas etcd baru, dan memperingatkan klaster tentang anggota baru tersebut (anggota dlldctl menambahkan). Dalam kasus Operator, pengguna hanya perlu mengubah ukuran cluster - segala sesuatunya akan terjadi secara otomatis.
Dan karena etcd juga dibuat di CoreOS, cukup logis untuk melihat Operatornya muncul terlebih dahulu. Bagaimana cara kerjanya? Logika operator dll ditentukan oleh tiga komponen:
- Mengamati. Operator memantau keadaan cluster menggunakan Kubernetes API.
- Analisis. Menemukan perbedaan antara status saat ini dan status yang diinginkan (ditentukan oleh konfigurasi pengguna).
- Tindakan. Menyelesaikan perbedaan yang terdeteksi menggunakan API layanan etcd dan/atau Kubernetes.
Untuk mengimplementasikan logika ini, fungsi telah disiapkan di Operator Buat/Hancurkan (membuat dan menghapus anggota cluster dll) dan Resize (perubahan jumlah anggota cluster). Kebenaran pengoperasiannya diperiksa menggunakan utilitas yang dibuat mirip dengan Chaos Monkey dari Netflix, mis. membunuh pod dll secara acak.
Untuk pengoperasian penuh dll, Operator menyediakan fitur tambahan: backup (pembuatan salinan cadangan secara otomatis dan tidak terlihat oleh pengguna - dalam konfigurasi cukup untuk menentukan seberapa sering membuatnya dan berapa banyak yang akan disimpan - dan pemulihan data selanjutnya dari cadangan tersebut) dan Meningkatkan (memperbarui instalasi dll tanpa downtime).
Seperti apa rasanya bekerja 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 Operator etcd saat ini adalah versi beta, yang memerlukan Kubernetes 1.5.3+ dan etcd 3.0+ untuk dijalankan. Kode sumber dan dokumentasi (termasuk petunjuk penggunaan) tersedia di .
Contoh implementasi lain dari CoreOS telah dibuat - , namun masih dalam versi alfa (belum semua fitur yang direncanakan telah diterapkan).
Status dan prospek
5 bulan telah berlalu sejak pengumuman Operator Kubernetes. Masih ada dua implementasi yang tersedia di repositori resmi CoreOS (untuk etcd dan Prometheus). Keduanya belum mencapai versi stabilnya, namun penerapannya diamati setiap hari.
Para pengembang membayangkan “masa depan di mana pengguna menginstal Operator Postgres, Operator Cassandra, atau Operator Redis di cluster Kubernetes mereka dan bekerja dengan entitas yang dapat diskalakan dari aplikasi-aplikasi ini semudah menerapkan replika aplikasi web tanpa kewarganegaraan saat ini.” Pertama Operator dari pengembang pihak ketiga benar-benar mulai muncul:
- dari Perusahaan UPMC;
- dari Crunchy Data (diumumkan akhir Maret 2017);
- dari penulis sistem penyimpanan data terdistribusi berdasarkan Ceph (Benteng dalam status alfa);
- dari SAP Cloud.
Pada konferensi perangkat lunak bebas terbesar di Eropa FOSDEM, yang berlangsung pada bulan Februari 2017 di Brussels, Josh Wood dari CoreOS mengumumkan Operator di (video tersedia di tautan!), yang seharusnya berkontribusi pada pertumbuhan popularitas konsep ini di komunitas Open Source yang lebih luas.
PS Terima kasih atas minat Anda pada artikel ini! Berlangganan ke hub kami, agar tidak ketinggalan materi dan resep baru tentang DevOps dan administrasi sistem GNU/Linux - kami akan menerbitkannya secara berkala!
Sumber: www.habr.com