Merencanakan deployment database Anda di GKE

Halaman ini menjelaskan praktik terbaik untuk menjalankan database dalam container di GKE. Anda dapat menggunakan Deployment untuk membuat serangkaian instance database dalam container yang dikelola Kubernetes. Selanjutnya, Anda akan membuat Service untuk memberikan akses ke database secara terpisah dari Pod tertentu. Layanan tetap tidak berubah meskipun Pod dipindahkan ke node lain.

Untuk mengakses data di instance database, buat resource PersistentVolumeClaim (PVC) dan sediakan untuk workload Anda.

Database mengandalkan disk lokal untuk persistensi. Database yang berjalan sebagai Service di cluster Kubernetes beserta file database-nya berada di PersistentVolumeClaim terikat dengan siklus proses cluster. Jika cluster dihapus, database juga akan dihapus.

Jika Anda membangun atau men-deploy aplikasi stateful yang berjalan di GKE, sebaiknya gunakan salah satu opsi deployment berikut untuk instance database:

  • Database yang terkelola sepenuhnya: Database terkelola, seperti Cloud SQL atau Spanner, memberikan overhead operasional yang lebih rendah dan dioptimalkan untuk infrastruktur Google Cloud. Upaya pemeliharaan dan pengoperasian untuk database terkelola cenderung lebih sedikit dibandingkan database yang Anda deploy langsung di Kubernetes.
  • Aplikasi Kubernetes: Anda dapat menerapkan dan menjalankan instance database (sepertiMySQL atau PostgreSQL) di cluster GKE.

Pertimbangan untuk deployment database di GKE

Setiap opsi sebelumnya memiliki beberapa konsekuensi, mengingat sasaran dan batasan bisnis Anda. Gunakan tabel berikut untuk memutuskan apakah deployment database di GKE adalah pilihan yang tepat ubagi Anda.

Pertimbangan Deskripsi
Independensi database Siklus proses PersistentVolumeClaim terikat dengan cluster GKE yang terkait. Jika Anda tidak ingin siklus proses database bergantung pada cluster GKE tertentu, sebaiknya pisahkan database tersebut sebagai database terkelola atau dalam instance VM.
Penskalaan dengan GKE

Penskalaan vertikal: Anda dapat mengonfigurasi permintaan Pod agar otomatis diskalakan. Namun, Anda harus memastikan aplikasi database dapat menahan gangguan selama skala Pod ditingkatkan menggunakan penskalaan otomatis Pod vertikal.

Penskalaan horizontal: Database Anda mungkin dapat menskalakan operasi baca atau tulis secara horizontal dengan menambahkan replika. Mampu atau tidaknya database Anda dalam mendukung penskalaan horizontal bergantung pada arsitektur satu penulis atau multi-penulis yang dimilikinya. Untuk menggunakan penskalaan horizontal, Anda mungkin harus memperbarui konfigurasi database, selain meningkatkan jumlah replika.
Overhead GKE

Pada cluster Autopilot, Anda hanya ditagih biaya permintaan resource, sedangkan biaya pemesanan resource tidak ditagih.

Pada cluster Standar, GKE mencadangkan resource untuk operasinya sendiri. Database pada cluster Standar tidak otomatis diskalakan sehingga overhead mungkin tinggi untuk Pod kecil.
Jumlah instance database Dalam konteks Kubernetes, setiap instance database berjalan dalam Pod-nya sendiri dan memiliki PersistentVolumeClaim sendiri. Jika memiliki jumlah instance yang sangat banyak, Anda harus mengoperasikan dan mengelola sekumpulan Pod, node, dan klaim volume dalam jumlah besar Sebaiknya gunakan database terkelola.
Pencadangan database di GKE

PersistentVolumeClaim dicakup dalam cluster GKE. Cakupan ini berarti bahwa saat cluster GKE dihapus, klaim volume juga akan dihapus. Semua file database dalam cluster juga akan dihapus. Untuk mencegah hilangnya file database secara tidak sengaja, sebaiknya lakukan replikasi atau pencadangan berkala.

Anda dapat menggunakan Pencadangan untuk GKE untuk mengambil snapshot konfigurasi aplikasi dan data volume pada interval terjadwal. Pencadangan untuk GKE menangani penjadwalan pencadangan volume, pengelolaan siklus proses pencadangan, dan pemulihan cadangan ke cluster.

Perilaku pemulihan khusus Kubernetes Jika gagal di Kubernetes, Pod akan dibuat ulang. Dari perspektif instance database, hal ini berarti bahwa saat Pod dibuat ulang, maka setiap konfigurasi yang tidak persisten dalam database atau pada penyimpanan stabil di luar Pod juga akan dibuat ulang.
Arsitektur database Jika database dikonfigurasi agar dapat menggunakan arsitektur pasif aktif, Anda harus memastikan bahwa hanya satu replika yang dikonfigurasi sebagai Utama. Banyak database relasional memiliki opsi untuk failover aktif-pasif, dengan database sekunder dapat dinaikkan menjadi primer jika database primer mengalami kegagalan.
Migrasi database Jika Anda berencana memigrasikan sistem database yang sudah ada ke GKE, baca Migrasi database: Konsep dan prinsip (Bagian 1) dan Migrasi database: Konsep dan prinsip (Bagian 2).
Pelatihan ulang pengguna Jika Anda beralih dari deployment yang dikelola sendiri atau dikelola penyedia ke deployment database Kubernetes, Anda harus melatih kembali administrator database agar dapat beroperasi di lingkungan baru dengan andal seperti mereka beroperasi di lingkungan saat ini. Developer aplikasi mungkin juga perlu sedikit mempelajari perbedaan.

Tabel sebelumnya menyajikan diskusi terkait beberapa pertimbangan untuk deployment database. Namun, tabel tidak menyertakan semua kemungkinan pertimbangan. Anda juga harus mempertimbangkan pemulihan dari bencana (disaster recovery), penggabungan koneksi, dan pemantauan.

Langkah selanjutnya