Kubernetes 101: Statefulset

Pelajari cara ngatur aplikasi stateful di Kubernetes pake StatefulSet, dan liat contoh konfigurasi sederhana buat MongoDB.

Kubernetes 101: Statefulset
Kubernetes 101: Statefulset - onxp blog

Di ekosistem Kubernetes, StatefulSet itu penting banget buat ngelola aplikasi yang butuh penyimpanan data permanen.

Pendahuluan

Di ekosistem Kubernetes, StatefulSet itu penting banget buat ngelola aplikasi yang butuh penyimpanan data permanen. Beda sama Deployment yang buat aplikasi stateless, StatefulSet ini emang didesain khusus buat aplikasi yang stateful.

Aplikasi-aplikasi ini nyimpen data mereka dari waktu ke waktu, jadi mereka harus inget interaksi atau transaksi sebelumnya, beda sama aplikasi stateless.

StatefulSet itu objek API buat workload yang ngatur deployment dan scaling dari sekumpulan Pod dan ngasih jaminan soal urutan dan keunikan dari Pod-Pod tersebut.

Misalnya, kalo ada StatefulSet dengan tiga replika, bakal ada Pod-Pod dengan nama web-0, web-1, dan web-2 yang dibuat. Kalau web-1 gagal, bakal dibuat lagi dengan nama yang sama, jadi state-nya tetap diinget.

Membandingkan StatefulSet dan Deployment

Kubernetes Deployment itu sumber daya lainnya yang kuat buat ngatur aplikasi stateless. Deployment ngatur Pod-Pod stateless dan bisa diskalain, plus ada fitur kayak rolling updates, rollback, dan scaling. Tapi, kalo Deployment nggak ngasih jaminan soal urutan pembuatan atau penghentian Pod, StatefulSet ngasih jaminan ini.

StatefulSets dan Deployment punya kegunaan yang tergantung jenis aplikasinya. Buat aplikasi stateless di mana instance-nya bisa ditukar-tukar, Deployment itu ideal. Tapi kalo berurusan sama aplikasi stateful di mana tiap instance butuh identitas unik dan stabil, StatefulSet jadi pilihannya.  

Misalnya, lo mau buat database yang direplikasi kayak Cassandra. Di Cassandra cluster, tiap node punya identitas unik dan nyimpen informasi state tertentu. Kalo lo deploy cluster Cassandra pake StatefulSet di Kubernetes, lo bakal dapetin ID jaringan yang stabil, penyimpanan persisten meski Pod-nya di-reschedule, dan deployment serta scaling yang teratur dan mulus.

Attribute StatefulSet Deployment
Tipe Objek Objek Workload API buat ngatur aplikasi stateful Objek API buat workload yang ngatur aplikasi stateless
Identitas Pod Pods punya identitas unik dan stabil Pods nggak punya identitas yang stabil
Scaling Scaling itu teratur dan mulus Scaling nggak ngejamin urutan tertentu
Pod Replacement Kalo Pod gagal, diganti sama Pod baru dengan identitas yang sama Kalo Pod gagal, diganti sama Pod baru dengan identitas yang beda
Update Strategy Dukung OnDelete dan RollingUpdate Dukung RollingUpdate and Recreate
Storage Setiap Pod punya Persistent Volume sendiri Semua Pod berbagi volume yang sama
Use Case Cocok buat aplikasi kayak database, message queue Cocok buat aplikasi stateless kayak web server, front-end interfaces

Kerja dengan StatefulSets

StatefulSets mastiin kalau setiap Pod dibuat dan dihapus pake cara yang teratur dan bisa diprediksi. Urutan pembuatannya ngikutin urutan dari indeks 0 sampai N. Kalo dihapus, urutannya bakal kebalik, dari N ke 0.

Ini penting banget kalo aplikasi lo sensitif sama urutan scaling. Misalnya, kalo lo pake Apache Kafka, platform streaming terdistribusi. Buat Kafka, urutan startup dan shutdown broker itu bisa ngaruh ke keseluruhan kinerja sistem. Kalo pake StatefulSets, penghentian yang teratur dan mulus bikin operasi cluster Kafka jadi lebih lancar.

Ngapus StatefulSets

Ngapus StatefulSet itu agak ribet karena sifatnya yang stateful. Kalo lo ngapus StatefulSet, Pod-Pod yang terkait nggak bakal otomatis kehapus. Pod-Pod itu bakal tetap ada meski StatefulSet-nya dihapus, jadi state-nya tetap aman. Kalo lo cuma mau ngapus tanpa ngotak-ngatik Pod, lo bisa pake perintah kubectl delete statefulsets <nama-statefulset> --cascade=false.

Tapi kalo lo mau ngapus StatefulSet beserta Pod-Pod-nya, pake perintah kubectl delete statefulsets <nama-statefulset>. Sebelom ngapus apa pun di sistem yang stateful, mending pikirin backup data dulu karena ini penting.

Kerja dengan Volume di StatefulSet

Kerja dengan Volume di StatefulSet - onxp blog

Di Kubernetes, volume itu tempat penyimpanan data buat container di dalam Pod. StatefulSets pake volume dengan cara yang unik buat aplikasi yang butuh nyimpen data.

Pas lo bikin StatefulSet, biasanya lo bakal nentuin volumeClaimTemplate. Template ini dipake buat bikin Persistent Volume (PV) baru secara dinamis buat tiap Pod yang dibuat sama StatefulSet. Ini dilakuin pake cara yang bisa diprediksi dan diulang, jadi PV yang sama bakal nempel lagi ke Pod kalau Pod-nya di-reschedule.

VolumeClaimTemplate ngasih spesifikasi PVC (Persistent Volume Claim) yang mencakup storage class, access modes, dan ukuran storage. Pas sebuah Pod dibuat di bawah StatefulSet, PVC baru bakal dibuat dari spesifikasi ini dan terhubung ke PV yang kompatibel. Ini mastiin setiap Pod punya penyimpanan sendiri-sendiri, jadi data bakal tetap aman meski Pod dihapus atau dipindah ke node lain.

Contohnya, bayangin lo lagi jalanin StatefulSet buat MongoDB replica set. Setiap instance MongoDB (Pod) yang dibuat sama StatefulSet bakal punya PV sendiri.

Pas instance MongoDB nulis data, datanya disimpan di PV-nya sendiri, dan meskipun Pod-nya gagal atau di-reschedule, Pod baru bakal punya PV yang sama, jadi state dari instance MongoDB tetap aman.

Volume di Deployment

Nggak kayak StatefulSets, Deployment ngatur volume pake cara yang beda. Pas lo bikin Deployment dan nentuin volume, setiap replika (Pod) dari Deployment itu bakal pake PVC yang sama.

PVC ini nunjuk ke satu PV, jadi semua replika baca atau nulis di PV yang sama. Ini karena Deployment emang didesain buat aplikasi stateless di mana setiap replika biasanya bisa ditukar-tukar dan nggak butuh penyimpanan unik.

Bayangin lo punya Deployment buat aplikasi stateless, kayak web server yang nyajiin konten statis. Web server ini baca konten statis dari volume. Kalau lo nentuin volume di spesifikasi Deployment, semua instance web server (Pod) yang dibuat sama Deployment bakal baca konten statis dari volume yang sama.

Perbandingan

Ini perbedaan utama antara ngatur volume di StatefulSets dan Deployment:

  • Di StatefulSet, setiap Pod dapet Persistent Volume (PV) yang unik, jadi bisa ngejaga state-nya meski di-reschedule atau restart. Ini cocok banget buat aplikasi stateful kayak database yang perlu nyimpen data sepanjang siklus hidup Pod.
  • Di Deployment, semua Pod pake volume yang sama. Model berbagi ini oke buat aplikasi stateless di mana data nggak perlu dipertahankan antar Pod.

Kesimpulannya, cara penggunaan volume di Kubernetes tergantung pada jenis aplikasi lo. Ngerti perbedaan antara cara StatefulSet dan Deployment ngatur volume itu penting pas lo mau ngebangun aplikasi di Kubernetes.

Scaling StatefulSets

Scaling StatefulSet itu penting banget buat ngatur beban atau kapasitas aplikasi lo. Ini maksudnya nambah atau ngurangin jumlah replika Pod di StatefulSet. Yang perlu lo ingat, proses scaling ini ngikutin urutan yang dijamin sama StatefulSet.

Misalnya, lo punya database terdistribusi yang mereplikasi data ke semua instansinya. Pas scaling down, lo pengen instansi database dengan salinan data terbaru tetap jalan selama mungkin. Di situasi ini, StatefulSet bakal pastiin Pod dengan indeks tertinggi yang dihapus duluan, jadi integritas data tetap terjaga.

Contoh Manifes StatefulSets

Yuk bikin manifest StatefulSet sederhana yang nge-deploy layanan MongoDB basic, terus ONXP jelasin detailnya.

---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mongo
spec:
  serviceName: "mongo"
  replicas: 3
  selector:
    matchLabels:
      app: mongo
  template:
    metadata:
      labels:
        app: mongo
    spec:
      containers:
      - name: mongo
        image: mongo
        ports:
        - containerPort: 27017
        volumeMounts:
        - name: mongo-persistent-storage
          mountPath: /data/db
  volumeClaimTemplates:
  - metadata:
      name: mongo-persistent-storage
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

Penjelasan Manifest:

  • apiVersion: apps/v1: Nentuin versi API yang dipake. apps/v1 itu grup API dan versinya buat resource StatefulSet.
  • kind: StatefulSet: Nentuin kalo kita bikin objek StatefulSet.
  • metadata: name: mongo: Nentuin nama StatefulSet-nya.
  • spec: serviceName: "mongo": Nama headless service yang ngatur domain jaringan buat StatefulSet.
  • replicas: 3: Jumlah Pod yang diinginkan. Di sini, kita pengen tiga Pod.
  • selector: matchLabels: app: mongo: Buat nyocokin StatefulSet sama Pod-Pod yang dikelolanya. Pod dengan label app: mongo dikelola sama StatefulSet ini.
  • template: Bagian ini buat template Pod yang dipake StatefulSet buat bikin Pod baru.
  • metadata: labels: app: mongo: Label yang diterapin ke Pod yang dibuat dari template ini.
  • spec: Nentuin spesifikasi buat Pod

containers: Array yang ngedefine container-container yang bakal jalan di Pod.

  • name: mongo: Nama container.

image: mongo: Image Docker yang dipake buat container.

ports: containerPort: 27017: Nentuin port yang diekspos oleh container.

volumeMounts: Nentuin di mana volume di-mount di dalam container.

name: mongo-persistent-storage: Nama volume yang di-mount.

mountPath: /data/db: Path di dalam container tempat volume di-mount.

  • volumeClaimTemplates: Nentuin spesifikasi PVC (Persistent Volume Claim) yang bakal dipake buat bikin PV untuk tiap Pod.

metadata: name: mongo-persistent-storage: Nama PVC yang bakal dibuat dari template ini.

spec: Nentuin spesifikasi buat PVC.

accessModes: [“ReadWriteOnce”]: Mode akses buat volume. 'ReadWriteOnce' artinya volume bisa di-mount sebagai read-write oleh satu node.

resources: requests: storage: 1Gi: Nentuin kebutuhan resource storage volume. Di sini, kita minta volume sebesar 1Gi (GibiByte).

File YAML ini bikin StatefulSet pake tiga replika, masing-masing jalanin instance MongoDB. Setiap Pod dapet volume penyimpanan sendiri sebesar 1Gi, yang di-mount di /data/db dalam container.

Setiap Pod yang dibuat sama StatefulSet bakal punya nama unik dan bisa ditebak dengan format 'mongo-N' (N itu nomor), jadi mereka bisa dikenali secara unik di dalam jaringan.

Jangan lupa buat belajar Kubernetes Storage!

Baca di sini

Read more