Dieses Dokument enthält Empfehlungen zum Fragmentieren der Config Controller-Nutzung. Fragmentierung ist der Vorgang, bei dem von Config Controller verwaltete Google Cloud-Ressourcen auf mehrere Namespaces, Cluster oder Projekte aufgeteilt werden.
Fragmentierung bietet folgende Vorteile
- Reduziert die Auswirkungen von Änderungen: Wenn ein einzelner Shard nicht mehr funktioniert, sind die anderen Shards nicht betroffen.
- Hilft Ihnen, die Sicherheit zu verwalten: Jeder Shard kann dedizierte IAM- und RBAC-Konfigurationen haben. Böswillige Angreifer, die einen Shard manipulieren, können nicht auf andere Shards zugreifen. Eine fehlerhafte Konfiguration in einem Shard kann sich nicht auf andere Shards auswirken.
- Bessere Skalierbarkeit: Ein einzelner Shard kann Engpässe bei der Skalierbarkeit wie die Anzahl der verwalteten Objekte oder API-Kontingente haben. Wenn Sie mehrere Shards haben, wird die Skalierbarkeit Ihrer Config Controller-Nutzung insgesamt erhöht.
Fragmentierung mit Config Controller verwenden
Es gibt verschiedene Möglichkeiten, die Fragmentierung zu implementieren. Der für Sie am besten geeignete Ansatz hängt von Ihren spezifischen Anforderungen und Anforderungen ab.
Modelle fragmentieren
Es gibt zwei Hauptfragmentierungsmodelle:
- Von Geschäftsfeldern oder Anwendungsteams: Dieses Modell wird in der Regel verwendet, wenn Config Controller von verschiedenen Teams verwendet wird. In diesem Modell hat jedes Team seinen eigenen Shard.
- Nach Umgebung: Dieses Modell wird normalerweise verwendet, wenn Config Controller in verschiedenen Umgebungen verwendet wird. Sie haben beispielsweise einen Shard für die Entwicklungsumgebung, einen Shard für die QA-Umgebung und einen Shard für die Produktionsumgebung.
Notwendigkeit von fragmentierten Verweisen minimieren
Wenn Sie Ihre Config Controller-Nutzung fragmentieren, sollten Sie die Notwendigkeit von fragmentierten Verweisen minimieren. Shard-übergreifende Verweise können Ihre Konfiguration komplexer und schwerer zu verwalten machen. Weitere Informationen finden Sie unter Ressourcenreferenzen zwischen Instanzen.
Fragmentierungsmechanismen
Es gibt drei Hauptmechanismen zur Fragmentierung:
- Über Namespaces: Sie können zusätzliche Namespaces erstellen und Config Connector so konfigurieren, dass Ressourcen in diesen Namespaces verwaltet werden.
- Von Config Controller-Instanzen: Sie können mehrere Config Controller-Instanzen in einem Google Cloud-Projekt erstellen.
- Nach Projekten: Sie können mehrere Config Controller-Instanzen in mehreren Google Cloud-Projekten erstellen. Dieser Mechanismus hilft Ihnen, Probleme mit API-Kontingenten zu vermeiden, wenn bei einem einzelnen Projekt Kontingentengpässe auftreten. Weitere Informationen finden Sie unter Ressourcen auf mehrere Projekte aufteilen.
Vorsichtsmaßnahmen bei der Implementierung der Fragmentierung
Wenn Sie die Fragmentierung für Ihre Config Controller-Nutzung implementieren, gibt es einige potenzielle Probleme, die Sie kennen und beheben sollten.
Instanzübergreifende Ressourcenreferenzen
Eine der Herausforderungen bei der Fragmentierung von Config Controller ist der Umgang mit Ressourcenreferenzen zwischen Instanzen. Ein Plattformteam könnte beispielsweise Projekte in einer Instanz erstellen und dann Anwendungsteams Ressourcen erstellen, die auf diese Projekte in anderen Instanzen verweisen. Dies kann zu Problemen führen wie:
- Erhöhte Komplexität: Durch die Verwaltung von Ressourcenreferenzen über mehrere Cluster hinweg kann Ihre Konfiguration komplexer und schwerer zu verwalten sein.
- Erhöhtes Risiko: Wenn eine Ressource in einem Shard gelöscht wird, kann sie weiterhin von Ressourcen in anderen Shards referenziert werden. Dies kann zu unerwartetem Verhalten und Datenverlust führen.
- Leistungsverschlechterung: Ressourcenreferenzen über mehrere Cluster können die Latenz Ihrer Konfigurationsänderungen erhöhen.
Es gibt verschiedene Möglichkeiten, die Querverweis-Herausforderung zu umgehen:
- Die Fragmentierung ist so, dass keine Referenz über Shards hinweg erforderlich ist. Dies kann durch Fragmentierung nach Umgebungen oder Teams erfolgen.
- Externe Referenzen verwenden Dies bedeutet, dass das Objekt, auf das verwiesen wird, nicht von Config Controller verwaltet wird. Dies kann eine gute Option sein, wenn sich das Objekt nicht häufig ändert.
- Dasselbe Objekt in allen Shards Dies ist eine komplexere Option, kann aber die beste Option sein, wenn sich das Objekt häufig ändert.
Die Objekte sollten dieselbe "Source of Truth" haben, um Abgleichskonflikte zwischen diesen Objekten in verschiedenen Shards zu vermeiden. Sie müssen die Richtlinie zur Konfliktvermeidung für diese Objekte auf
none
festlegen.
Es ist wichtig, die Vor- und Nachteile der einzelnen Ansätze sorgfältig zu erwägen, bevor Sie sich für einen Ansatz entscheiden.
API-Kontingente
Durch Fragmentierung können sich Ihre API-Kontingente erhöhen. Sie sollten sich darüber im Klaren sein und entsprechend planen. Best Practices zum Verwalten von API-Kontingentlimits finden Sie unter API-Kontingentlimits verwalten.