Panduan sharding Config Controller

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

Sharding memberikan manfaat berikut:

  • Mengurangi dampak perubahan: Jika satu shard berhenti berfungsi, shard lain tidak akan terpengaruh.
  • Membantu Anda mengelola keamanan: Setiap shard dapat memiliki konfigurasi IAM dan RBAC khusus. Penyerang berbahaya yang membahayakan satu partisi tidak dapat mengakses partisi lain. Kesalahan konfigurasi di satu shard tidak dapat memengaruhi shard lainnya.
  • Skalabilitas yang lebih baik: Satu shard dapat memiliki hambatan 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 berbeda 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 Config Controller digunakan oleh tim yang berbeda. Dalam model ini, setiap tim memiliki shard-nya sendiri.
  • Menurut lingkungan: Model ini biasanya digunakan saat Config Controller digunakan di lingkungan yang berbeda. Misalnya, Anda dapat memiliki shard untuk lingkungan pengembangan, shard untuk lingkungan QA, dan shard untuk lingkungan produksi.

Meminimalkan kebutuhan akan referensi lintas shard

Saat membagi penggunaan Config Controller, Anda harus meminimalkan kebutuhan akan referensi lintas partisi. Referensi lintas partisi dapat membuat konfigurasi Anda menjadi lebih rumit dan sulit dikelola. Lihat Referensi resource di seluruh instance untuk mengetahui detail selengkapnya.

Mekanisme sharding

Ada tiga mekanisme sharding utama:

Peringatan saat menerapkan sharding

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

Referensi resource di seluruh instance

Salah satu tantangan dalam membagi Config Controller adalah menangani referensi resource di seluruh instance. Misalnya, tim platform dapat membuat Project di 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 menjadi lebih kompleks dan sulit dikelola.
  • Peningkatan risiko: Jika resource dihapus di satu shard, resource tersebut masih dapat dirujuk oleh resource di shard lain. Hal ini dapat menyebabkan perilaku yang tidak terduga dan kehilangan data.
  • Penurunan performa: Referensi resource di seluruh cluster dapat meningkatkan latensi perubahan konfigurasi Anda.

Ada beberapa cara untuk mengatasi tantangan referensi silang:

  • Sharding dengan cara yang tidak memerlukan referensi di seluruh shard. Hal ini dapat dilakukan dengan membagi berdasarkan lingkungan atau tim.
  • Menggunakan referensi eksternal. Artinya, objek yang sedang dirujuk sebenarnya tidak dikelola oleh Config Controller. Opsi ini bisa menjadi opsi yang baik jika objek tidak sering berubah.
  • Memiliki objek yang sama yang tersedia di semua shard. Ini adalah opsi yang lebih rumit, tetapi bisa menjadi opsi terbaik jika objek sering berubah. Objek harus berbagi sumber tepercaya yang sama untuk menghindari konflik rekonsiliasi antara objek ini di shard yang berbeda. Anda harus menyetel kebijakan pencegahan konflik ke none untuk objek ini.

Penting untuk mempertimbangkan dengan cermat kelebihan dan kekurangan setiap pendekatan sebelum memilih salah satunya.

Kuota API

Sharding dapat meningkatkan kuota API Anda. Anda harus menyadarinya dan membuat rencana yang sesuai. Lihat Mengelola batas kuota API untuk mengetahui praktik terbaik dalam mengelola batas kuota API.

Langkah berikutnya