Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
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.
Menurut instance Config Controller: Anda dapat membuat beberapa
instance Config Controller dalam satu project Google Cloud .
Menurut project: Anda dapat membuat beberapa instance Config Controller di beberapa project Google Cloud . Mekanisme ini membantu mengatasi masalah kuota API jika Anda
mengalami bottleneck kuota dengan satu project. Lihat
Memisahkan resource ke dalam beberapa project
untuk mengetahui detail selengkapnya.
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.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-01 UTC."],[],[],null,["# Config Controller sharding guidelines\n\nThis document provides recommendations on how to shard your\nConfig Controller usage. Sharding is the process of splitting\nConfig Controller-managed Google Cloud resources across multiple namespaces,\nclusters, or projects.\n\nSharding brings the following benefits:\n\n- **Reduces the impact of changes**: If a single shard stops functioning, the other shards are not impacted.\n- **Helps you manage security**: Each shard can have dedicated IAM and RBAC configurations. Malicious attackers who compromise one shard cannot access other shards. Misconfiguration in one shard cannot affect other shards.\n- **Better scalability**: A single shard can have scalability bottlenecks such as the number of managed objects, or API quotas. Having multiple shards increases the overall scalability of your Config Controller usage.\n\nUse sharding with Config Controller\n-----------------------------------\n\nThere are a few different ways to implement sharding. The best approach for you\nwill depend on your specific needs and requirements.\n\n### Sharding models\n\nThere are two main sharding models:\n\n- **By business lines or application teams**: This model is typically used when Config Controller is used by different teams. In this model, each team has their own shard.\n- **By environment**: This model is typically used when Config Controller is used in different environments. For example, you might have a shard for your development environment, a shard for your QA environment, and a shard for your production environment.\n\n### Minimize the need for cross-shard references\n\nWhen you shard your Config Controller usage, you should minimize the\nneed for cross-shard references. Cross-shard references can make your\nconfiguration more complex and difficult to manage. See\n[Resource references across instances](#resource-references-across-instances)\nfor more details.\n\n### Sharding mechanisms\n\nThere are three main sharding mechanisms:\n\n- **By namespaces** : You can create additional namespaces and [configure Config Connector to manage resources in those namespaces](/config-connector/docs/how-to/advanced-install#project-namespace).\n- **By Config Controller instances**: You can create multiple Config Controller instances in one Google Cloud project.\n- **By projects** : You can create multiple Config Controller instances in multiple Google Cloud projects. This mechanism helps address API quota issues if you are hitting quota bottlenecks with one single project. See [Split your resources into multiple projects](/config-connector/docs/best-practices#quota-split) for more details.\n\nCaveats when implementing sharding\n----------------------------------\n\nWhen implementing sharding for your Config Controller usage, there are some\npotential issues you should be aware of and plan to mitigate.\n\n### Resource references across instances\n\nOne of the challenges of sharding Config Controller is dealing with resource\nreferences across instances. For example, a platform team might create Projects\nin one instance, and then app teams might create resources that refer to those\nProjects in other instances. This can create problems such as:\n\n- **Increased complexity**: Managing resource references across clusters can make your configuration more complex and difficult to manage.\n- **Increased risk**: If a resource is deleted in one shard, it can still be referenced by resources in other shards. This can lead to unexpected behavior and data loss.\n- **Performance degradation**: Resource references across clusters can increase the latency of your configuration changes.\n\nThere are a few ways to work around the cross-reference challenge:\n\n- Sharding in a way that no reference across shards is needed. This could be done by sharding by environments or by teams.\n- Using external references. This means that the object that is being referenced is not actually managed by Config Controller. This can be a good option if the object isn't changing frequently.\n- Having the same object available in all shards. This is a more complex option, but it can be the best option if the object changes frequently. The objects should share the same source of truth to avoid reconciliation fights between these objects in different shards. You need to set the [conflict prevention policy](/config-connector/docs/concepts/managing-conflicts#modifying_conflict_prevention) to `none` for these objects.\n\nIt is important to carefully consider the advantages and disadvantages of each approach\nbefore choosing one.\n\n### API Quotas\n\nSharding could increase your API quotas. You should be aware of this and plan\naccordingly. See\n[Manage API quota limits](/config-connector/docs/best-practices#quota-limits)\nfor best practices on managing API quota limits.\n\nWhat's next\n-----------\n\n- Learn more about [Config Controller scalability](/kubernetes-engine/enterprise/config-controller/docs/scalability)"]]
