Panduan sharding Config Controller

Dokumen ini memberikan rekomendasi tentang cara melakukan sharding pada penggunaan Config Controller Anda. Sharding adalah proses pemisahan resource Google Cloud yang dikelola Config Controller di beberapa namespace, cluster, atau project.

Sharding memberikan manfaat berikut:

  • Mengurangi dampak perubahan: Jika satu shard berhenti berfungsi, shard lainnya tidak akan terpengaruh.
  • Membantu Anda mengelola keamanan: Setiap shard dapat memiliki konfigurasi IAM dan RBAC khusus. Penyerang berbahaya yang membahayakan satu shard tidak dapat mengakses shard lainnya. Konfigurasi yang salah di satu shard tidak dapat memengaruhi shard lainnya.
  • Skalabilitas yang lebih baik: Satu shard dapat memiliki bottleneck skalabilitas seperti jumlah objek terkelola, atau kuota API. Memiliki beberapa shard akan meningkatkan skalabilitas keseluruhan penggunaan Config Controller Anda.

Menggunakan sharding dengan Config Controller

Ada beberapa cara untuk menerapkan sharding. Pendekatan terbaik untuk Anda akan bergantung pada kebutuhan dan persyaratan spesifik Anda.

Model sharding

Ada dua model sharding utama:

  • Menurut lini bisnis atau tim aplikasi: Model ini biasanya digunakan saat Pengontrol Konfigurasi digunakan oleh tim yang berbeda. Dalam model ini, setiap tim memiliki shard-nya sendiri.
  • Menurut lingkungan: Model ini biasanya digunakan saat Pengontrol Konfigurasi digunakan di lingkungan yang berbeda. Misalnya, Anda mungkin memiliki shard untuk lingkungan pengembangan, shard untuk lingkungan QA, dan shard untuk lingkungan produksi.

Meminimalkan kebutuhan referensi lintas-shard

Saat melakukan sharding penggunaan Pengontrol Konfigurasi, Anda harus meminimalkan kebutuhan referensi lintas-shard. Referensi lintas shard dapat membuat konfigurasi Anda lebih kompleks dan sulit dikelola. Lihat Referensi resource di seluruh instance untuk mengetahui detail selengkapnya.

Mekanisme sharding

Ada tiga mekanisme sharding utama:

Perhatian saat menerapkan sharding

Saat menerapkan sharding untuk penggunaan Pengontrol Konfigurasi, ada beberapa potensi masalah yang harus Anda ketahui dan rencanakan untuk dimitigasi.

Referensi resource di seluruh instance

Salah satu tantangan sharding Config Controller adalah menangani referensi resource di seluruh instance. Misalnya, tim platform dapat membuat Project dalam satu instance, lalu tim aplikasi dapat membuat resource yang merujuk ke Project tersebut di instance lain. Hal ini dapat menimbulkan masalah seperti:

  • Peningkatan kompleksitas: Mengelola referensi resource di seluruh cluster dapat membuat konfigurasi Anda lebih kompleks dan sulit dikelola.
  • Peningkatan risiko: Jika dihapus di satu shard, resource masih dapat direferensikan oleh resource di shard lain. Hal ini dapat menyebabkan perilaku yang tidak terduga dan kehilangan data.
  • Degradasi performa: Referensi resource di seluruh cluster dapat meningkatkan latensi perubahan konfigurasi Anda.

Ada beberapa cara untuk mengatasi masalah referensi silang:

  • Sharding dengan cara yang tidak memerlukan referensi di seluruh shard. Hal ini dapat dilakukan dengan melakukan sharding berdasarkan lingkungan atau tim.
  • Menggunakan referensi eksternal. Artinya, objek yang direferensikan sebenarnya tidak dikelola oleh Pengontrol Konfigurasi. Ini bisa menjadi opsi yang baik jika objek tidak sering berubah.
  • Memiliki objek yang sama di semua shard. Ini adalah opsi yang lebih kompleks, tetapi dapat menjadi opsi terbaik jika objek sering berubah. Objek harus memiliki sumber tepercaya yang sama untuk menghindari pertentangan rekonsiliasi antara objek ini di shard yang berbeda. Anda harus menetapkan kebijakan pencegahan konflik ke none untuk objek ini.

Anda harus mempertimbangkan dengan cermat kelebihan dan kekurangan dari setiap pendekatan sebelum memilih salah satunya.

Kuota API

Sharding dapat meningkatkan kuota API Anda. Anda harus menyadari hal ini dan membuat perencanaan yang sesuai. Lihat Mengelola batas kuota API untuk mengetahui praktik terbaik dalam mengelola batas kuota API.

Langkah berikutnya