StatefulSets adalah objek Kubernetes yang digunakan untuk secara konsisten menerapkan komponen aplikasi stateful. Pod yang dibuat sebagai bagian dari StatefulSet diberikan pengenal persisten yang mereka simpan bahkan ketika dijadwal ulang.
A StatefulSet dapat men-deploy aplikasi yang perlu mengidentifikasi replika tertentu secara andal, meluncurkan pembaruan dalam urutan yang telah ditentukan sebelumnya, atau mengakses volume penyimpanan secara stabil. Mereka berlaku untuk banyak kasus penggunaan yang berbeda tetapi paling sering digunakan untuk database dan jenis penyimpanan data persisten lainnya.
Dalam artikel ini Anda akan mempelajari apa itu StatefulSet, cara kerjanya, dan kapan Anda harus menggunakannya. Kami juga akan membahas batasannya dan situasi di mana objek Kubernetes lain adalah pilihan yang lebih baik.
Apa Itu StatefulSets?
Membuat Pod sebagai bagian dari StatefulSet menginstruksikan Kubernetes untuk menjadwalkan dan menskalakannya dengan cara yang terjamin. Setiap Pod mendapat alokasi identitas unik yang dipertahankan oleh setiap Pod pengganti.
Nama Pod diberi akhiran dengan indeks ordinal yang menentukan urutannya selama operasi penjadwalan. StatefulSet yang disebut mysql yang berisi tiga replika akan membuat Pods bernama berikut:
mysql-1mysql-2mysql-3
Pods menggunakan nama mereka sebagai nama host mereka sehingga layanan lain yang perlu mengakses replika kedua StatefulSet dengan andal dapat terhubung ke mysql-2. Bahkan jika Pod tertentu yang menjalankan mysql-2 dijadwal ulang nanti, identitasnya akan diteruskan ke penggantinya.
StatefulSets juga memberlakukan bahwa Pod dihapus dalam urutan terbalik dari pembuatannya. Jika StatefulSet diperkecil menjadi satu replika, mysql-3 dijamin akan keluar terlebih dahulu, diikuti oleh mysql-2. Perilaku ini tidak berlaku ketika seluruh StatefulSet dihapus dan dapat dinonaktifkan dengan menyetel field podManagementPolicy StatefulSet ke Parallel.
StatefulSet Use Cases
StatefulSets biasanya digunakan untuk menjalankan aplikasi yang direplikasi di mana setiap Pod memiliki peran yang berbeda. Sebagai contoh, Anda dapat menerapkan database MySQL dengan instance utama dan dua replika hanya-baca. ReplicaSet atau Deployment biasa tidak akan sesuai karena Anda tidak dapat mengidentifikasi Pod yang menjalankan replika utama dengan andal.
StatefulSets mengatasi hal ini dengan menjamin bahwa setiap Pod di ReplicaSet mempertahankan identitasnya. Layanan Anda yang lain dapat dengan andal terhubung ke mysql-1 untuk berinteraksi dengan replika utama. ReplicaSets juga memberlakukan bahwa Pod baru hanya dimulai ketika Pod sebelumnya sedang berjalan. Ini memastikan replika read-only dibuat setelah primer selesai dan siap untuk mengekspos datanya.
Tujuan StatefulSets adalah untuk mengakomodasi replika yang tidak dapat dipertukarkan di dalam Kubernetes. Sementara Pod dalam aplikasi stateless setara satu sama lain, beban kerja stateful memerlukan pendekatan yang disengaja untuk peluncuran, penskalaan, dan penghentian.
StatefulSets terintegrasi dengan volume persisten lokal untuk mendukung penyimpanan persisten yang melekat pada setiap replika. Setiap Pod mendapatkan akses ke volumenya sendiri yang akan secara otomatis disambungkan kembali ketika replika dijadwal ulang ke node lain.
Membuat StatefulSet
Berikut adalah contoh manifes YAML yang mendefinisikan set stateful untuk menjalankan MySQL dengan node utama dan dua replika:
apiVersion: v1 kind: Service metadata: nama: mysql label: aplikasi: mysql spesifikasi: port: – nama: mysql port: 3306 clusterIP: Tidak ada pemilih: aplikasi: mysql — apiVersion: apps/v1 jenis: StatefulSet metadata: nama: mysql spesifikasi: pemilih: matchLabels : app: mysql serviceName: mysql replika: 3 template: metadata: label: app: mysql spec: initContainers: – nama: mysql-init image: mysql:8.0 perintah: – bash – “-c” – | set -ex [[ `hostname` =~ -([0-9]+)$ ]] || exit 1 ordinal=${BASH_REMATCH[1]} echo [mysqld] > /mnt/conf/server-id.cnf # MySQL tidak mengizinkan “0” sebagai `server-id` jadi kita harus menambahkan 1 ke Indeks Pod echo server-id=$((1 + $ordinal)) >> /mnt/conf/server-id.cnf if [[ $ordinal -eq 0 ]]; lalu printf “[mysqld]nlog-bin”> /mnt/conf/primary.cnf else printf “[mysqld]nsuper-read-only” /mnt/conf/replica.cnf fi volumeMounts: – nama: config mountPath: /mnt/conf container: – nama: mysql gambar: mysql:8.0 env: – nama: MYSQL_ALLOW_EMPTY_PASSWORD nilai: “1” port: – nama: mysql containerPort: 3306 volumeMounts: – nama: config mountPath: /etc/mysql/conf. d – nama: data mountPath: /var/lib/mysql subPath: mysql livenessProbe: exec: command: [“mysqladmin”, “ping”] initialDelaySeconds: 30 periodSeconds: 5 timeoutSeconds: 5 readyProbe: exec: command: [“mysql” , “-h”, “127.0.0.1”, “-e”, “SELECT 1”] initialDelaySeconds: 5 periodSeconds: 5 timeoutSeconds: 1 volume: – nama: config emptyDir: {} volumeClaimTemplates: – metadata: nama: spesifikasi data : accessModes: [“ReadWriteOnce”] sumber daya: permintaan: penyimpanan: 1Gi
Ini adalah manifes yang cukup panjang jadi mari kita bongkar apa yang terjadi. Layanan tanpa kepala
dibuat dengan menyetel clusterIP-nya ke Tidak Ada. Ini terkait dengan StatefulSet dan memberikan identitas jaringan untuk Pod-nya. StatefulSet dibuat untuk menampung MySQL Pods. Field replika menentukan bahwa tiga Pod akan dijalankan. Layanan tanpa kepala direferensikan oleh bidang serviceName. Di dalam StatefulSet, wadah init dibuat yang mengisi file di dalam direktori konfigurasi yang dipasang menggunakan volume persisten. Container menjalankan skrip Bash yang menetapkan indeks ordinal dari Pod yang sedang berjalan. Ketika indeks adalah 0, Pod adalah yang pertama dibuat dalam StatefulSet sehingga menjadi node utama MySQL. Pod lainnya dikonfigurasi sebagai replika. File konfigurasi yang sesuai akan ditulis ke dalam volume yang nantinya dapat diakses oleh wadah MySQL. Penampung MySQL dibuat dengan volume konfigurasi yang dipasang ke direktori MySQL yang benar. Ini memastikan instance MySQL terkonfigurasi sebagai primer atau replika, tergantung pada Pod pertama yang dimulai di StatefulSet. Probe Liveness dan kesiapan digunakan untuk mendeteksi saat instance MySQL siap. Ini mencegah Pod berturut-turut di StatefulSet dimulai sampai yang sebelumnya Berjalan, memastikan replika MySQL tidak ada sebelum node utama selesai.
Deployment atau ReplicaSet biasa tidak dapat mengimplementasikan alur kerja ini. Setelah Pod Anda dimulai, Anda dapat meningkatkan atau menurunkan StatefulSet tanpa mengambil risiko penghancuran node utama MySQL. Kubernetes memberikan jaminan bahwa urutan Pod yang dibuat akan dipatuhi.
# Buat MySQL StatefulSet $ kubectl apply -f mysql-statefulset.yaml # Skala hingga 5 Pod – MySQL primer dan 4 replika MySQL $ kubectl scale statefulset mysql — replicas=5Pembaruan Bergulir
StatefulSets mengimplementasikan pembaruan bergulir saat Anda mengubah spesifikasinya. Kontroler StatefulSet akan mengganti setiap Pod dalam urutan terbalik berurutan, menggunakan indeks ordinal yang ditetapkan secara persisten. mysql-3 akan dihapus dan diganti terlebih dahulu, diikuti oleh mysql-2 dan mysql-1. mysql-2 tidak akan diperbarui hingga Pod mysql-3 baru bertransisi ke status Berjalan.
Mekanisme pembaruan bergulir juga mencakup dukungan untuk penerapan bertahap. Menyetel bidang .spec.updateStrategy.rollingUpdate.partition di manifes StatefulSet Anda akan memerintahkan Kubernetes untuk hanya memperbarui Pod dengan indeks ordinal yang lebih besar atau sama dengan partisi yang diberikan.
apiVersion: apps/v1 kind: StatefulSet metadata: name: mysql spec: pemilih: matchLabels: app: mysql serviceName: mysql replicas: 3 updateStrategy: rollingUpdate: partisi: 1 template: … volumeClaimTemplates: …
Dalam contoh ini hanya Pod yang diindeks 1 atau lebih tinggi yang akan ditargetkan oleh operasi pembaruan. Pod pertama di StatefulSet tidak akan menerima spesifikasi baru sampai partisi diturunkan atau dihapus.
Limitations
StatefulSets memiliki beberapa batasan yang harus Anda ketahui sebelum Anda mengadopsinya. Gotcha umum ini dapat membuat Anda tersandung ketika Anda mulai men-deploy aplikasi stateful.
Menghapus StatefulSet tidak menjamin Pod akan dihentikan dalam urutan yang ditunjukkan oleh identitasnya. Menghapus StatefulSet atau mengurangi jumlah replikanya tidak akan menghapus volume terkait. Ini menjaga dari kehilangan data yang tidak disengaja. Menggunakan pembaruan bergulir dapat menciptakan situasi di mana terjadi keadaan rusak yang tidak valid. Ini terjadi saat Anda menyediakan konfigurasi yang tidak pernah bertransisi ke status Running atau Ready karena ada masalah dengan aplikasi Anda. Mengembalikan ke konfigurasi yang baik tidak akan menyelesaikan masalah karena Kubernetes menunggu tanpa batas waktu hingga Pod yang buruk menjadi Ready. Kamu harus menyelesaikan situasi secara manual dengan menghapus Pods yang tertunda atau gagal.
StatefulSets juga menghilangkan mekanisme untuk mengubah ukuran volume yang terhubung ke setiap Pod. Anda harus mengedit secara manual setiap volume persisten dan klaim volume persisten yang sesuai, kemudian menghapus StatefulSet dan menghilangkan Pod-nya. Membuat StatefulSet baru dengan spesifikasi yang telah direvisi akan memungkinkan Kubernetes untuk mendapatkan kembali Pod-Pod yang ditinggalkan dan mengubah ukuran volume.
Ketika Tidak Menggunakan StatefulSet
Anda hanya boleh menggunakan StatefulSet ketika replika individu memiliki statusnya sendiri. StatefulSet tidak diperlukan ketika semua replika memiliki status yang sama, bahkan jika itu persisten.
Dalam situasi ini Anda dapat menggunakan ReplicaSet atau Deployment biasa untuk meluncurkan Pod Anda. Setiap volume yang dipasang akan dibagikan ke semua Pod yang merupakan perilaku yang diharapkan untuk sistem stateless.
A StatefulSet tidak menambah nilai kecuali Anda memerlukan penyimpanan persisten individual atau pengenal replika lengket. Penggunaan StatefulSet yang salah dapat menyebabkan kebingungan dengan menyarankan bahwa Pod adalah stateful ketika mereka benar-benar menjalankan beban kerja stateless.
Summary
StatefulSets memberikan identitas persisten untuk Pod Kubernetes yang direplikasi. Setiap Pod diberi nama dengan indeks ordinal yang dialokasikan secara berurutan. Saat Pod dijadwal ulang, penggantinya mewarisi identitasnya. StatefulSet juga memastikan bahwa Pod dihentikan dengan urutan terbalik saat dibuat.
StatefulSets memungkinkan Kubernetes untuk mengakomodasi aplikasi yang memerlukan penerapan rolling yang anggun, pengidentifikasi jaringan yang stabil, dan akses yang andal ke penyimpanan persisten. Mereka cocok untuk situasi apa pun di mana replika dalam satu set Pod memiliki statusnya sendiri yang perlu dipertahankan.
A StatefulSet tidak perlu digunakan jika replika Anda tidak memiliki status, bahkan jika mereka menyimpan beberapa data persisten. Deployment dan ReplicaSet lebih cocok ketika replika individu tidak perlu diidentifikasi atau diskalakan dalam urutan yang konsisten.
Itulah berita seputar Apa Itu StatefulSet Kubernetes? Kapan Anda Harus Menggunakannya?, semoga bermanfaat. Disadur dari HowToGeek.com.