Backup & Disaster Recovery di Kubernetes: Menjaga Data dan Cluster Tetap Aman

Keniscayaan Kegagalan dan Kebutuhan Resiliensi

Meskipun Kubernetes dirancang untuk menjadi resilien—mampu me-restart Pod yang gagal dan menyeimbangkan beban kerja—ia tidak secara otomatis menyediakan proteksi data dan pemulihan bencana (Disaster Recovery/DR) untuk keseluruhan klaster. Resiliensi melindungi dari kegagalan Pod atau Node tunggal, tetapi DR melindungi dari kegagalan yang lebih besar: penghapusan namespace yang tidak disengaja, korupsi data etcd, atau kegagalan cloud region secara total.

Inti dari backup dan DR di Kubernetes adalah memecahkan tantangan dua komponen terpisah:

1. Backup State Klaster (Metadata): Menyimpan semua konfigurasi deklaratif (objek Kubernetes seperti Deployment, Service, ConfigMap, PersistentVolumeClaim) yang mendefinisikan klaster dan aplikasi Anda.

2. Backup Data (Data Volume): Menyimpan data aktual yang digunakan oleh aplikasi stateful Anda (database, queues), yang terletak di Persistent Volumes (PV).

Mengabaikan salah satu komponen ini berarti recovery yang tidak lengkap. Artikel ini akan memandu Anda melalui praktik terbaik dan tool populer, khususnya Velero, untuk mengimplementasikan strategi backup dan DR yang komprehensif.

Tantangan Backup di Lingkungan Kubernetes

Paradigma Kubernetes yang terdistribusi dan ephemeral (berumur pendek) menciptakan tantangan unik dalam backup dibandingkan dengan mesin virtual tradisional:

Volume Persisten yang Terpisah dari Klaster

Aplikasi stateful di K8s menyimpan datanya di Persistent Volume (PV). PV diikat ke cluster melalui Persistent Volume Claim (PVC). Proses backup yang efektif harus:

1. Mengidentifikasi semua PVC yang terkait dengan namespace atau aplikasi yang akan di-backup.

2. Memastikan konsistensi data—data tidak sedang ditulis saat snapshot diambil (quiescing).

3. Membuat snapshot dari storage yang mendasarinya (EBS, Google Persistent Disk, Azure Disk) melalui Container Storage Interface (CSI).

Ketergantungan pada Penyimpanan etcd

etcd adalah basis data klaster Kubernetes yang menyimpan Desired State dari seluruh cluster. Korupnya data etcd adalah skenario kegagalan cluster total. Solusi DR harus mencakup backup reguler dan andal dari etcd, meskipun ini adalah tanggung jawab utama dari penyedia cloud (untuk layanan terkelola seperti GKE, EKS, AKS) atau tim Platform Engineering (untuk cluster self-managed).

Skala dan Kompleksitas Multi-Namespace

Cluster modern sering kali menampung puluhan namespace dan ratusan microservice. Strategi backup harus fleksibel, memungkinkan backup seluruh klaster (full cluster backup), backup per namespace (untuk isolasi), atau backup berbasis label (untuk aplikasi spesifik).

Velero: Solusi Backup dan Migrasi Standar

Velero (sebelumnya Heptio Ark) adalah alat open-source yang dikembangkan oleh VMware yang telah menjadi standar de facto untuk backup dan Disaster Recovery pada klaster Kubernetes. Velero dirancang untuk mengatasi tantangan backup dua komponen (data dan metadata).

Cara Kerja Velero

Velero beroperasi di dalam klaster target dan terdiri dari dua komponen utama:

1. Velero Server: Berjalan sebagai Deployment di namespace Velero, mendengarkan permintaan backup dan restore.

2. CLI Client: Digunakan oleh operator untuk memulai operasi backup dan restore dari luar.

Alur Kerja Backup Velero:

1. Operator menjalankan perintah velero backup create my-backup --include-namespaces prod.

2. Velero Server memanggil API Kubernetes untuk mengambil snapshot dari semua objek yang diminta (metadata) dan menyimpannya sebagai file tarball.

3. Velero menggunakan Volume Snapshotter untuk berinteraksi dengan CSI driver cloud provider untuk membuat snapshot PV yang terikat (associated).

4. Semua file metadata dan snapshot diarahkan ke Storage Object eksternal yang aman (Amazon S3, Google Cloud Storage, Azure Blob Storage).

Fitur Kritis Velero untuk DR

• Resource Filtering: Memungkinkan backup objek berdasarkan namespace, resource type (misalnya, hanya Deployment), atau label.

• Hooks dan Restoration Hooks: Memungkinkan operator menjalankan script custom pre-backup (misalnya, membekukan database) dan post-restore (misalnya, membersihkan cache). Hal ini sangat penting untuk konsistensi data aplikasi.

• Multiple Storage Locations: Mendukung backup ke banyak lokasi penyimpanan objek, vital untuk strategi off-site backup dan geo-redundancy.

Strategi Disaster Recovery (DR) di Kubernetes

Tujuan DR adalah meminimalkan RTO (Recovery Time Objective) dan RPO (Recovery Point Objective).

RPO dan RTO

• RPO (Recovery Point Objective): Seberapa banyak data yang boleh hilang. Ditentukan oleh frekuensi backup Anda. (Idealnya: 5-15 menit).

• RTO (Recovery Time Objective): Berapa lama waktu yang dibutuhkan untuk membuat aplikasi kembali online setelah bencana. (Idealnya: 15-60 menit).

DR Skenario 1: Pemulihan dalam Klaster (In-Cluster Restore)

Ini adalah skenario paling sederhana, digunakan ketika namespace atau aplikasi secara tidak sengaja terhapus atau rusak, tetapi Control Plane klaster masih berfungsi.

• Proses: Gunakan velero restore create --from-backup my-backup. Velero akan membaca metadata dari penyimpanan objek, membuat ulang Deployment, Service, dan PVC, serta memulihkan data dari snapshot PV.

• Keuntungan: RTO rendah karena klaster dasar sudah berjalan.

DR Skenario 2: Pemulihan Klaster ke Klaster Baru (Cluster Migration/Rebuild)

Ini adalah skenario bencana sejati, di mana klaster lama tidak dapat dipulihkan (misalnya, korupsi etcd atau kegagalan cloud region).

1. Rebuild Klaster: Klaster Kubernetes baru harus disediakan terlebih dahulu (sering kali di region cloud yang berbeda).

2. Bootstrap Velero: Velero harus diinstal pada klaster baru dengan konfigurasi untuk mengakses lokasi backup lama.

3. Restore Konfigurasi Inti: Lakukan restore penuh menggunakan Velero. Velero akan membuat ulang semua objek K8s (Deployment, Service) dan memicu Provisioning PV baru di klaster baru dari snapshot yang disimpan.

Integrasi GitOps untuk Pemulihan Terjamin

Untuk mencapai RTO yang rendah dalam skenario 2, Platform Engineers mengintegrasikan DR dengan GitOps (ArgoCD/Flux).

• Infrastructure as Code (IaC): Klaster dasar itu sendiri (termasuk Service Mesh, Ingress Controller, dan Monitoring Stack) harus didefinisikan sebagai kode (Terraform/CloudFormation) dan berada di Git.

• Status Klaster Diurus Git: Hanya data aplikasi dan state klaster yang diurus oleh Velero. Konfigurasi platform (base configuration) dapat direplikasi dengan cepat dari Git.

• Pemulihan Tiga Langkah:

  1. Deploy klaster kosong menggunakan IaC.

  2. Deploy tooling (Velero, ArgoCD) menggunakan GitOps.

  3. Lakukan Restore Data Volume menggunakan Velero.

Manajemen State dan Konsistensi Data

Masalah terbesar dalam backup aplikasi stateful adalah memastikan konsistensi data—bahwa semua operasi I/O telah selesai saat snapshot diambil.

Volume Snapshotter (CSI)

Volume Snapshotter K8s menggunakan Container Storage Interface (CSI) untuk berinteraksi dengan API cloud provider. Snapshot berbasis CSI adalah metode backup PV yang disukai karena lebih cepat dan efisien daripada menyalin data (data copy).

Application-Aware Backup

Untuk database (misalnya, PostgreSQL, MySQL), snapshot saja tidak cukup. Anda harus memastikan:

• Quiescing: Menghentikan sementara operasi tulis I/O ke database (atau menyetel mode read-only).

• Hooks Pre-Backup: Velero memungkinkan penggunaan hook pre-backup untuk menjalankan perintah di Pod (misalnya, pg_dump atau flush tables). Ini menjamin bahwa data yang di-snapshot secara fisik adalah data yang konsisten secara logis.

Backup etcd

Jika Anda menjalankan Kubernetes self-managed, backup etcd sangat penting. etcd menyediakan snapshot incremental dan penuh. Backup etcd harus disimpan di lokasi yang terpisah dari cluster dan diuji secara teratur.

Kesimpulan: Strategi Proteksi Dua Pilar

Disaster Recovery di Kubernetes tidak lagi opsional; ini adalah prasyarat untuk workload misi kritis. Strategi yang efektif bergantung pada perlindungan dua pilar secara simultan: metadata klaster dan data persisten.

Dengan menggabungkan kekuatan Velero untuk orkestrasi backup dan restore data dan state, dengan ketangkasan GitOps untuk membangun kembali infrastruktur klaster dengan cepat, organisasi dapat mencapai RPO dan RTO yang dibutuhkan oleh aplikasi modern. Uji coba restore secara teratur (idealnya setiap kuartal) harus menjadi bagian tak terpisahkan dari workflow operasional Anda.

Perintah Kunci DR untuk Platform Engineers

# Membuat Backup penuh klaster dengan Velero
velero backup create full-cluster-backup --include-namespaces * --wait

# Melihat semua backup yang tersedia
velero backup get

# Menggunakan restore hook untuk menjalankan script post-restore
velero restore create restore-app --from-backup latest-prod-backup \
    --restore-only-resources Deployment,Service,PVC \
    --restore-actions RestoreItemAction.name=restore-db-connection-hook