Belajar Velero - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Setelah memahami sejarah dan alasan Velero ada di episode 1, sekarang kita membuka kap mesinnya: bagaimana Velero bekerja. Episodes selanjutnya (3-22) akan terus merujuk ke arsitektur ini, jadi pahami baik-baik sebelum mengetik perintah velero install.

Konsep terpenting yang harus kalian internalisasi: Velero bukan satu binary besar yang melakukan semuanya, melainkan sistem terpisah — server di dalam cluster, CLI di luar cluster, CRD sebagai "kontrak" penyimpanan state, dan plugin sebagai jembatan ke penyedia eksternal. Analoginya seperti perusahaan logistik: ada gudang (object storage), ada petugas gudang (server), ada surat perintah (CRD), dan ada armada truk (plugin).

#Arsitektur Utama

#Velero Server

Velero server adalah deployment bernama velero di namespace velero yang menjalankan binary velero server. Server ini adalah controller: ia terus memantau CRD (Backup, Restore, Schedule, dan lain-lain), lalu mengeksekusinya. Ketika kalian membuat objek Backup, server-lah yang mengambil manifest resource dari API server dan mengunggahnya ke object storage.

kubectl get deploy velero -n velero
kubectl get pods -n velero

#Velero CLI

velero CLI adalah binary yang berjalan di laptop/CI kalian. Ia tidak mengerjakan backup sendiri — ia hanya menerjemahkan perintah kalian menjadi objek CRD di cluster, lalu server yang bekerja. Ini pola client-server yang sama dengan kubectl dan API server Kubernetes.

velero client config set namespace=velero
velero version

#Komponen Inti

#CRD: Kontrak Penyimpanan State

Velero mendefinisikan sejumlah Custom Resource Definition (CRD) yang menjadi "database" operasionalnya. Yang paling sering kalian temui:

• Backup (backups.velero.io): satu operasi backup.
• Restore (restores.velero.io): satu operasi restore.
• Schedule (schedules.velero.io): backup terjadwal.
• BackupStorageLocation (backupstoragelocations.velero.io): lokasi object storage.
• VolumeSnapshotLocation (volumesnapshotlocations.velero.io): lokasi snapshot cloud.
• DownloadRequest: izin CLI mengunduh log/artefak.

Karena semuanya objek Kubernetes biasa, kalian bisa melihatnya dengan kubectl:

Lihat CRD Velero

kubectl get crd | grep velero.io
kubectl get backup -n velero
kubectl get backupstoragelocations -n velero

#BackupStorageLocation (BSL)

BSL menentukan ke mana manifest backup dan file data disimpan: bucket, prefix, region, dan endpoint. Satu cluster bisa punya beberapa BSL (misalnya untuk environment berbeda atau aturan compliance). Inilah yang membuat backup Velero "portable" — BSL hanya menunjuk ke bucket, bukan ke cluster tertentu.

#VolumeSnapshotLocation (VSL)

VSL menentukan di mana snapshot volume cloud dibuat: region dan parameter spesifik provider (misal KMS key untuk EBS). VSL hanya relevan untuk backup volume via cloud snapshot; backup file-level (restic/kopia) tidak memakai VSL karena data langsung ditulis ke BSL. Kita bandingkan keduanya di episode 8.

#Plugin

Velero memakai sistem plugin agar tidak menulis kode spesifik vendor ke dalam inti. Jenisnya:

• Object Store plugin: koneksi ke object storage (AWS S3, Azure Blob, GCS, MinIO).
• Volume Snapshotter plugin: membuat snapshot cloud (EBS, Azure Disk, GCP PD).
• Backup/Restore Item Action plugin: mengubah resource selama backup/restore.
• Node-agent (restic/kopia): backup file-level untuk volume tanpa snapshot cloud.

Plugin ditambahkan saat install atau belakangan dengan velero plugin add (kita bahas lengkap di episode 18).

#Alur Satu Backup

Untuk memperjelas siapa melakukan apa, ikuti alur velero backup create my-backup:

1. CLI membuat objek Backup di API server.
2. Server melihat objek baru, lalu menjalankan backup: mengambil manifest resource sesuai scope.
3. Volume snapshotter plugin membuat snapshot cloud (jika --snapshot-volumes) atau node-agent melakukan file-level backup (jika restic/kopia).
4. Object store plugin mengunggah semua data ke bucket yang ditunjuk BSL.
5. Status backup diperbarui ke Completed — kalian melihatnya lewat velero backup get.

#Namespace velero

Seluruh komponen server tinggal di namespace velero: deployment velero, DaemonSet node-agent (untuk restic/kopia), Secret credential, dan semua CRD instance. Kebijakan keamanan untuk membatasi siapa yang bisa mengakses namespace ini kita bahas di episode 13.

Seluruh komponen di namespace velero

kubectl get all -n velero
kubectl get ds node-agent -n velero

#Penutup

Inti yang harus dibawa pulang:

• Velero = server (controller di cluster) + CLI (client di laptop) + CRD (state) + plugin (jembatan ke penyedia).
• BSL menentukan tempat penyimpanan; VSL menentukan tempat snapshot cloud.
• Semua operasi adalah objek Kubernetes: velero backup create hanya membuat CRD Backup.
• Plugin object store, snapshotter, dan node-agent menangani integrasi vendor.
• Status hidup di CRD di cluster; restore butuh cluster baru + BSL yang sama.

Di episode 3 selanjutnya kita akan menginstall Velero — lewat velero install maupun Helm chart — dan mengonfigurasi BackupStorageLocation pertama ke MinIO/AWS S3, termasuk VSL dan opsi insecure skip TLS untuk endpoint lokal. Di sinilah seri ini mulai praktik nyata.