Skalierbarkeitsrichtlinien für Config Controller

Auf dieser Seite finden Sie Empfehlungen, die Ihnen bei der Planung Ihrer Konfigurationsmanagement-Architektur auf Config Controller-Instanzen helfen und die Erstellung und Verwaltung Ihrer Google Cloud Ressourcen innerhalb der Service Level Objectives (SLO) halten.

Diese Seite richtet sich an Administratoren, Architekten und Betreiber, die den Lebenszyklus der zugrunde liegenden technischen Infrastruktur verwalten und die Kapazitäts- und Infrastrukturanforderungen planen. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Namespace-Modus verwenden

Wir empfehlen die Verwendung von Config Connector im Namespace-Modus, da sich damit eine große Anzahl von Ressourcen einfacher verwalten lässt. Sie können jeden Namespace so festlegen, dass er einem einzelnen Namespace entspricht. Das kann bei der Verwaltung von Kontingenten und Konfigurationen hilfreich sein, da Ressourcen Lese- und Schreibkontingente pro Projekt haben. Ab Version 1.119.0 können Sie die Ratenlimits für den Abgleich nach Namespace erhöhen. Wenn Sie die Ratenlimits erhöhen, können Sie die Abgleichung für mehr als 10.000 Ressourcen pro Namespace in einem 10-Minuten-Intervall zulassen. Sowohl Config Connector als auch Config Sync unterstützen den Namespaced-Modus, in dem jeder Namespace einem einzelnen Google Cloud -Projekt zugeordnet werden kann.

Skalierbarkeitsziele

In der folgenden Tabelle sind Werte aufgeführt, die wir regelmäßig testen. Wir wissen, dass Config Connector auch größere Zahlen verarbeiten kann. Wir haben gezeigt,dass 30.000 Ressourcen in einem einzelnen Namespace verwaltet werden können. Dazu sind jedoch einige Anpassungen erforderlich. Weitere Informationen zu diesen Änderungen finden Sie im Abschnitt „Namespaced-Modus“.

Die Skalierbarkeitsziele für Config Controller sind Gruppen von Ressourcen, die von Google getestet wurden und bei denen Config Sync GitOps verwendet wird. Sie können diese Ziele verwenden, um Ihre Konfigurationsmanagement-Architektur zu planen.

Diese Ziele sind keine festen Limits. Das Erweitern der Menge einer Ressourcenart führt nicht zwangsläufig dazu, dass die Config Controller-Instanz nicht mehr verfügbar ist. Aber die Gesamtmenge der anderen Ressourcentypen in derselben Config Controller-Instanz, die Sie bereitstellen können, könnte dadurch verringert werden.

Die Tabellen auf dieser Seite dienen als Referenz und sind nicht vollständig.

Einzelner Namespace

Das folgende Beispiel zeigt eine Config Controller-Instanz mit einem Config Connector-Namespace im Cluster. Config Connector kann die folgende Anzahl von Ressourcen in diesem Namespace erstellen und verwalten:

Ressourcentyp

Vorgeschlagenes Limit

SQLInstance

450

SQLDatabase

2.250

SQLUser

2.500

StorageBucket

5.000

ContainerCluster

50

ContainerNodepool

200

IAMServiceAccount

2.500

IAMPartialPolicy

7.500

Mehrere Namespaces

Das folgende Beispiel zeigt eine Config Controller-Instanz mit 50 Config Connector-Namespaces in einem Cluster. Config Connector kann die folgende Anzahl von Ressourcen in jedem Namespace erstellen und verwalten:

Ressourcentyp

Vorgeschlagenes Limit

SQLInstance

9

SQLDatabase 45
SQLUser 45
StorageBucket 100
ContainerCluster 1
ContainerNodepool 4
IAMServiceAccount 50
IAMPartialPolicy 150

Config Connector-Namespaces

Config Controller verwendet standardmäßig den Namespace-Modus von Config Connector. Die folgende Tabelle zeigt ein Beispiel für die Anzahl der Config Connector-Namespaces, die Sie in einer einzelnen Config Connector-Instanz haben können.

--cluster-ipv4-cidr-block

Anzahl der Knoten

Anzahl der Config Connector-Namespaces

/18

64

600

/19

32

300

/20 (Standard und empfohlen)

16

120

/21

8

60

Skalierbarkeitsziele prüfen

Mit den folgenden Ressourcen können Sie feststellen, ob Sie die Skalierbarkeitsziele erreicht haben.

Google Cloud API-Kontingente

Ihre Google Cloud API-Kontingente können Sie in der Google Cloud Console aufrufen. Wenn einige Kontingente fast ausgeschöpft sind, sollten Sie in Erwägung ziehen, das API-Kontingent nach Google Cloud Projekten aufzuteilen. Weitere Informationen zum Monitoring und zu Benachrichtigungen zu Kontingentmesswerten finden Sie unter Kontingentbenachrichtigungen und ‑monitoring einrichten.

Speicherverwendung durch Config Connector

Sie können die Arbeitsspeichernutzung von Config Connector im GKE-Monitoring-Dashboard ansehen. Wenn die Speichernutzung von Config Connector nahe am Limit liegt, sollten Sie Sharding nach Namespace in Betracht ziehen.

Config Controller skalieren

Wenn Sie die Skalierbarkeitsziele erreicht haben, sollten Sie die Config Controller-Instanzen weiter hochskalieren. In diesem Abschnitt werden verschiedene Methoden zum Hochskalieren Ihrer Config Controller-Instanzen beschrieben.

Sharding nach Namespace

Wenn Sie ein Skalierbarkeitsziel mit einem einzelnen Config Connector-Namespace erreichen, können Sie Config Connector so konfigurieren, dass Ressourcen in Ihren Namespaces verwaltet werden.

Jeder Namespace verwendet eigene Dienstkonten und Operator-Arbeitslasten, sodass Config Connector Ihre Ressourcen im großen Maßstab verwalten kann. Wenn Sie eine Config Connector-Instanz zum Verwalten mehrerer Google Cloud Projekte verwenden, können Sie einen Config Connector-Namespace zum Verwalten jedes Google Cloud Projekts verwenden.

API-Kontingent nach Google Cloud Projekten aufteilen

Wenn Sie aufgrund des Erreichens von Google Cloud API-Kontingenten ein Skalierbarkeitsziel erreichen, können Sie verschiedene IAM-Dienstkonten, die zu verschiedenen Google Cloud -Projekten gehören, an verschiedene Namespaces binden, in denen Config Connector im Namespace-Modus installiert ist. Anschließend können Sie Ihre Ressourcen auf verschiedene Projekte aufteilen.

Sharding nach Config Connector-Instanzen

Wenn Sie ein Skalierbarkeitsziel mit mehreren Config Connector-Namespaces erreichen, können Sie mehr als eine Config Controller-Instanz erstellen und verwenden. Mit mehreren Config Controller-Instanzen können Sie die Verwaltung Ihrer Ressourcenkonfiguration aufteilen, z. B. nach verschiedenen Entwicklungsumgebungen, Anwendungsteams oder GitOps-Verzeichnissen in Ihrer Organisation.

Weitere Überlegungen zur Skalierbarkeit

Google Cloud API-Kontingente

Wenn Sie auf Fehler gestoßen sind, die darauf hinweisen, dass Sie das API-Kontingentlimit überschritten haben, haben Sie möglicherweise zu viele Config Connector-Ressourcen desselben Typs im selben Projekt erstellt. Diese Ressourcen können aufgrund der Abstimmungsstrategie in Config Connector zu viele API-Anfragen an denselben API-Endpunkt generieren.

Zur Behebung dieses Problems können Sie entweder das API-Kontingent nach Google Cloud -Projekt aufteilen oder eine Kontingentanpassung anfordern.

GKE-Einschränkungen

Da Config Controller auf GKE basiert, gibt es Einschränkungen von GKE, die Sie berücksichtigen sollten. In den folgenden Abschnitten werden spezifische Aspekte im Zusammenhang mit Config Controller behandelt. Weitere Informationen zu allgemeinen Limits und Best Practices für große GKE-Cluster finden Sie unter Große GKE-Cluster planen.

Limit für Kubernetes-Dienstkonten

​Die Anzahl der in einem einzelnen GKE-Cluster erstellten Kubernetes-Dienstkonten (KSA) sollte 3.000 nicht überschreiten, da es sonst zu einem gke-metadata-server Pod-Absturz kommen kann.

Wenn Sie einen Config Connector-Namespace hinzufügen, wird auch ein Kubernetes-Dienstkonto erstellt.

Leistungsprobleme der GKE-Steuerungsebene

Die Steuerungsebene des GKE-Clusters kann Leistungsprobleme haben, wenn eine Config Controller-Instanz zu viele Config Connector-Namespaces hat. Die Anzahl der Config Connector-Namespaces sollte auf unter 500 pro Cluster begrenzt werden.

Wenn Sie einen Config Connector-Namespace hinzufügen, wird auch ein Controller-Pod erstellt.

Nächste Schritte