Auf dieser Seite wird die Architektur von Config Sync vorgestellt, einschließlich der gehosteten Komponenten, die in Google Cloud ausgeführt werden, und der Open-Source-Komponenten, die in Ihrem Google Kubernetes Engine-Cluster ausgeführt werden. Wenn Sie mehr über die Architektur erfahren, können Sie Config Sync besser verstehen und möglicherweise Probleme beheben, die auftreten.
Im folgenden Abschnitt wird die Architektur von Config Sync mit den zugehörigen Komponenten und Abhängigkeiten sowohl in Google Cloud als auch in Ihrem GKE-Cluster dargestellt:
Der Flottendienst verwaltet die Config Sync-Komponenten in Ihrem Cluster direkt, ohne den alten ConfigManagement Operator oder das ConfigManagement-Objekt. Sie müssen Config Sync bei Bedarf manuell aktualisieren.
Die Installation von Config Sync umfasst mehrere Schritte, bei denen jeweils zusätzliche Komponenten in Ihrem Cluster bereitgestellt werden:
Wenn Sie Config Sync in Ihrem Cluster aktivieren, werden die folgenden Komponenten hinzugefügt:
- Die benutzerdefinierte Ressourcendefinition (CRD)
ConfigSync - Ein
ConfigSync-Objekt mit dem Namenconfig-sync. - Der Reconciler Manager in einem Deployment mit dem Namen
reconciler-manager. - Der ResourceGroup-Controller in einem Deployment mit dem Namen
resource-group-controller-manager. - Der OpenTelemetry Collector in einem Deployment mit dem Namen
otel-collector. - Optional: Der Config Sync-Zulassungs-Webhook in einem Deployment mit dem Namen
admission-webhook. Der Config Sync-Zulassungs-Webhook wird nur installiert, wenn Sie die Drift-Prävention aktivieren.
Diese Ressourcen und Objekte werden automatisch erstellt, wenn Sie Config Sync installieren, und sollten nicht direkt geändert werden.
- Die benutzerdefinierte Ressourcendefinition (CRD)
Wenn Sie
RootSync- undRepoSync-Objekte erstellen, werden die folgenden Komponenten hinzugefügt:- Für jedes
RootSync-Objekt eine Abgleichsbereitstellung mit dem Namenroot-reconciler-ROOTSYNC_NAME. Für dasRootSync-Objekt mit dem Namenroot-syncheißt die Abgleichsbereitstellungroot-reconciler. - Für jedes
RepoSync-Objekt eine Abgleichsbereitstellung mit dem Namenns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH. Für dasRepoSync-Objekt mit dem Namenrepo-synclautet der Name der Abgleichs-Bereitstellungns-reconciler.
- Für jedes
Config Sync-Deployments, -Pods und -Container
In der folgenden Tabelle finden Sie weitere Informationen zur Config Sync-Bereitstellung, zu Pods und Containern:
| Bereitstellungsname | Bereitstellungs-Namespace | Beschreibung der Bereitstellung | Anzahl der Replikate | Regulärer Ausdruck für Pod-Name | Anzahl der Container | Container-Namen |
|---|---|---|---|---|---|---|
reconciler-manager |
config-management-system |
Der Reconciler Manager wird auf jedem Cluster mit aktiviertem Config Sync im ConfigManagement-Objekt ausgeführt. Sie überwacht RootSync- und RepoSync-Objekte und verwaltet für jedes eine Abgleichsbereitstellung. |
1 | reconciler-manager-.* |
2 | reconciler-managerotel-agent |
root-reconciler |
config-management-system |
Für jedes RootSync-Objekt wird eine Root-Reconciler-Bereitstellung erstellt. |
1 | root-reconciler-.* |
3 - 51 |
reconcilerotel-agentgit-synchelm-syncoci-syncgcenode-askpass-sidecarhydration-controller |
ns-reconciler |
config-management-system |
Für jedes RepoSync-Objekt wird eine Namespace-Abgleichsbereitstellung erstellt. |
1 | ns-reconciler-.* |
3 - 51 |
reconcilerotel-agentgit-synchelm-syncoci-syncgcenode-askpass-sidecarhydration-controller |
otel-collector |
config-management-monitoring |
Der OpenTelemetry Collector wird in jedem Cluster mit aktiviertem Config Sync im ConfigManagement-Objekt ausgeführt.
Er erfasst Messwerte von den Config Sync-Komponenten, die unter den Namespaces config-management-system und resource-group-system ausgeführt werden, und exportiert diese Messwerte nach Prometheus und Cloud Monitoring. |
1 | otel-collector-.* |
1 | otel-collector |
resource-group-controller-manager |
resource-group-system |
Der ResourceGroup Controller wird in jedem Cluster mit aktiviertem Config Sync im ConfigManagement-Objekt ausgeführt. Sie überwacht ResourceGroup-Objekte und aktualisiert sie mit dem aktuellen Abgleichsstatus jedes Objekts in ihrem Inventar. Für jedes Objekt RootSync und RepoSync wird ein ResourceGroup-Objekt erstellt, um die Liste der vom Abgleicher angewendeten Objekte aus der „Source of Truth“ zu inventarisieren. |
1 | resource-group-controller-manager-.* |
2 | managerotel-agent |
admission-webhook |
config-management-system |
Der Config Sync-Zulassungs-Webhook wird in jedem Cluster mit aktivierter Vermeidung von Abweichungen im ConfigManagement-Objekt ausgeführt. Es überwacht Kubernetes API-Anfragen und verhindert die Änderung oder Löschung von Ressourcen, die von Config Sync verwaltet werden. Der Config Sync-Zulassungs-Webhook ist standardmäßig deaktiviert. |
2 | admission-webhook-.* |
1 | admission-webhook |
1 Weitere Informationen dazu, wann diese Container erstellt werden, finden Sie unter Abgleich-Container.
Anforderungen für Deployment-Ressourcen
In der folgenden Tabelle sind die Kubernetes-Ressourcenanforderungen für Config Sync-Komponenten aufgeführt. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Ressourcenverwaltung für Pods und Container.
Die Ressourcenanforderungen sind für alle unterstützten Versionen von Config Sync gleich.
| Bereitstellungsname | CPU-Anfrage (m) pro Replikat | Speicheranfrage (Mi) pro Replikat |
|---|---|---|
config-management-operator |
100 | 200 |
resource-group-controller-manager |
110 | 300 |
admission-webhook1 |
10 | 100 |
otel-collector |
200 | 400 |
reconciler-manager |
20 | 150 |
reconciler (einer pro RootSync und RepoSync) |
Weitere Informationen finden Sie unter Abgleichsressourcenanfragen. | |
1 Der Zulassungs-Webhook hat zwei Replikate. Wenn Sie den Zugangs-Webhook verwenden und die Gesamtzahl der Ressourcenanforderungen berechnen müssen, verdoppeln Sie den Wert. Der Zulassungs-Webhook ist standardmäßig deaktiviert.
Schlüsselkomponenten
In den folgenden Abschnitten werden wichtige Config Sync-Komponenten genauer beschrieben.
Flottendienst und das ConfigSync-Objekt
In Config Sync Version 1.20.0 und höher verwaltet der Hub Fleet-Dienst die Config Sync-Komponenten in Ihrem Cluster direkt:
Der Flottendienst verwaltet auch das ConfigSync-Objekt in Ihrem Cluster. Der Flottendienst aktualisiert sowohl die Spezifikation des ConfigSync-Objekts basierend auf Ihren Eingaben in die Google Cloud API als auch den Status, um den Status der Config Sync-Komponenten widerzuspiegeln.
Wenn Sie Änderungen an der Konfiguration Ihrer Config Sync-Installation vornehmen möchten, müssen Sie die Google Cloud API verwenden. Sie können jedoch entweder die Google CloudAPI oder die Kubernetes API verwenden, um die Konfiguration und den Status Ihrer Config Sync-Installation zu überwachen.
Reconciler Manager und Abgleichstools
Der Reconciler Manager ist für die Erstellung und Verwaltung der einzelnen Abgleicher verantwortlich, die dafür sorgen, dass Ihre Clusterkonfiguration synchron bleibt.
Der Reconciler Manager erstellt einen Root-Reconciler für jedes RootSync-Objekt und einen Namespace-Reconciler für jedes RepoSync-Objekt. Config Sync verwendet dieses Design anstelle eines einzelnen monolithischen Reconcilers, da es die Zuverlässigkeit verbessert, indem Single Points of Failure reduziert werden, und die einzelnen Reconciler unabhängig voneinander skaliert werden können.
Root- und Namespace-Reconciler rufen automatisch Konfigurationen aus Ihrer „Source of Truth“ ab und wenden sie an, um den gewünschten Status in Ihrem Cluster zu erzwingen.
Die folgenden Diagramme zeigen, wie der Reconciler Manager den Lebenszyklus jeden Root-Reconciler und jeden Namespace-Reconciler steuert:
Abgleicher-Container
Welche Container in den Reconciler-Pods bereitgestellt werden, hängt von den Konfigurationsoptionen ab, die Sie auswählen. In der folgenden Tabelle wird beschrieben, was die einzelnen Reconciler-Container tun und unter welchen Bedingungen Config Sync sie erstellt:
| Containername | Beschreibung | Bedingung |
|---|---|---|
reconciler |
Übernimmt die Synchronisierung und die Korrektur von Abweichungen. | Immer aktiviert. |
otel-agent |
Empfängt Messwerte von den anderen Abgleichscontainern und sendet sie an den OpenTelemetry Collector. | Immer aktiviert. |
git-sync |
Ruft Konfigurationen aus Ihrem Git-Repository in ein lokales Verzeichnis ab, das der Abgleichscontainer lesen kann. | Aktiviert, wenn spec.sourceType git ist. |
helm-sync |
Ruft Helm-Diagramme aus Ihrem Diagramm-Repository ab und rendert sie in einem lokalen Verzeichnis, das der Abgleich-Container lesen kann. | Aktiviert, wenn spec.sourceType helm ist. |
oci-sync |
Ruft OCI-Images mit Ihren Konfigurationen aus Ihrer Container Registry in ein lokales Verzeichnis ab, das der Abgleich-Container lesen kann. | Aktiviert, wenn spec.sourceType oci ist. |
gcenode-askpass-sidecar |
Speichert Git-Anmeldedaten aus dem GKE-Metadatendienst im Cache, damit sie vom git-sync-Container verwendet werden können. |
Aktiviert, wenn spec.sourceType git und spec.git.auth gcenode oder gcpserviceaccount ist. |
hydration-controller |
Verarbeitet das Erstellen von Kustomize-Konfigurationen in einem lokalen Verzeichnis, das der Abgleich-Container lesen kann. | Aktiviert, wenn die Quelle eine kustomize.yaml-Datei enthält. |
Wie in der Tabelle oben zu sehen ist, können Sie in der Regel mit drei bis fünf Containern in jedem Reconciler-Pod rechnen. Die Container reconciler und otel-agent sind immer vorhanden. Durch die Angabe eines Typs für Ihre „Source of Truth“ wird festgelegt, welcher Synchronisierungscontainer hinzugefügt wird. Außerdem werden die Container hydration-controller und gcenode-askpass-sidecar erstellt, wenn Sie die in der Tabelle genannten Konfigurationsänderungen vorgenommen haben.
Abstimmungsanfragen für Ressourcen
Für jedes RootSync- und RepoSync-Objekt erstellt Config Sync eine unabhängige Abgleichsbereitstellung, um die Synchronisierung durchzuführen. Die Abgleichsbereitstellung besteht aus mehreren Containern. Weitere Informationen zu diesen Containern finden Sie unter Abgleich-Container.
Die Ressourcenanforderungen sind für alle unterstützten Versionen von Config Sync gleich.
In der folgenden Tabelle sind die Ressourcenanforderungen für Standardcluster aufgeführt:
| Containername | CPU-Anfrage (m) | Speicheranfrage (Mi) |
|---|---|---|
reconciler |
50 | 200 |
otel-agent |
10 | 100 |
hydration-controller (optional) |
10 | 100 |
git-sync |
10 | 16 |
gcenode-askpass-sidecar (optional) |
10 | 20 |
helm-sync |
75 | 128 |
oci-sync |
25 | 32 |
In der folgenden Tabelle sind die Ressourcenanforderungen für Autopilot-Cluster aufgeführt:
| Containername | CPU-Anfrage und ‑Limit (m) | Speicheranfrage und ‑limit (Mi) |
|---|---|---|
reconciler |
700 | 512 |
otel-agent |
10 | 64 |
hydration-controller (optional) |
200 | 256 |
git-sync |
20 | 32 |
gcenode-askpass-sidecar (optional) |
50 | 64 |
helm-sync |
250 | 384 |
oci-sync |
50 | 64 |
Weitere Informationen zum Überschreiben der standardmäßigen Ressourcenanfragen und ‑limits finden Sie unter Ressourcenanfragen und ‑limits überschreiben.
Gebündelte Helm- und Kustomize-Versionen
Config Sync nutzt die ausführbaren Dateien von Helm und Kustomize, um die Konfigurationen zu rendern. Die folgende Tabelle enthält eine Liste der Config Sync-Versionen, die die Renderingfunktion zusammen mit den gebündelten Helm- und Kustomize-Versionen unterstützen.
| Config Sync-Versionen | Helm-Version | Kustomize-Version |
|---|---|---|
| 1.22.0 | v3.15.3 | v5.3.0 |
| 1.21.0 | v3.15.3 | v5.3.0 |
| 1.20.0 | v3.15.3 | v5.3.0 |
Informationen zum Rendern von Helm über Kustomize finden Sie unter Kubernetes mit Kustomize konfigurieren. Informationen zur Verwendung der Helm API finden Sie unter Helm-Diagramme aus Artifact Registry synchronisieren.
Objekte „ResourceGroup Controller“ und „ResourceGroup“
Die Root- und Namespace-Reconciler erstellen ein ResourceGroup-Inventarobjekt für jedes von Ihnen eingerichtete RootSync- und RepoSync-Objekt. Jedes ResourceGroup-Objekt enthält eine Liste von Objekten, die vom Abgleich für dieses RootSync- oder RepoSync-Objekt aus der „Source of Truth“ mit dem Cluster synchronisiert werden. Der ResourceGroup-Controller überwacht dann alle Objekte im ResourceGroup-Objekt und aktualisiert den Status des ResourceGroup-Objekts mit dem aktuellen Abgleichsstatus der synchronisierten Objekte. So können Sie den Status des ResourceGroup-Objekts prüfen, um sich einen Überblick über den Synchronisierungsstatus zu verschaffen, anstatt den Status jedes einzelnen Objekts selbst abfragen zu müssen.
ResourceGroup-Objekte haben denselben Namen und Namespace wie das entsprechende RootSync- oder RepoSync-Objekt. Beispiel: Für das RootSync-Objekt mit dem Namen root-sync im Namespace config-management-system ist das entsprechende ResourceGroup-Objekt auch root-sync im Namespace config-management-system.
Erstellen oder ändern Sie keine ResourceGroup-Objekte, da dies den Betrieb von Config Sync beeinträchtigen kann.
Zulassungs-Webhook
Der Config Sync-Zulassungs-Webhook wird erstellt, wenn Sie die Drift-Prävention aktivieren. Die Drift-Prävention fängt Änderungsanfragen proaktiv ab und stellt sicher, dass sie mit der „Source of Truth“ übereinstimmen, bevor Änderungen zugelassen werden.
Wenn Sie die Drift-Prävention nicht aktivieren, verwendet Config Sync weiterhin einen Self-Healing-Mechanismus, um Konfigurationsabweichungen rückgängig zu machen. Mit der Selbstreparatur überwacht Config Sync kontinuierlich verwaltete Objekte und macht alle Änderungen, die vom beabsichtigten Status abweichen, automatisch rückgängig.
RootSync- und RepoSync-Objekte
RootSync-Objekte konfigurieren Config Sync so, dass ein Root-Reconciler erstellt wird, der die angegebene „Source of Truth“ überwacht und Objekte aus dieser Quelle auf den Cluster anwendet. Standardmäßig hat der Root-Reconciler für jedes RootSync-Objekt die Berechtigung cluster-admin. Mit dieser Standardberechtigung können Root-Reconciler sowohl clusterbezogene als auch Namespace-bezogene Ressourcen synchronisieren. Bei Bedarf können Sie diese Berechtigungen ändern, indem Sie die Felder spec.override.roleRefs konfigurieren. RootSync-Objekte sind für die Verwendung durch Clusteradministratoren vorgesehen.
RepoSync-Objekte konfigurieren Config Sync, um einen Namespace-Reconciler zu erstellen, der die angegebene Quelle überwacht und Objekte aus dieser Quelle auf einen bestimmten Namespace im Cluster anwendet. Namespace-Reconciler können alle Namespace-bezogenen Ressourcen in diesem Namespace mit benutzerdefinierten Berechtigungen synchronisieren. RepoSync-Objekte sind für die Verwendung durch Namespace-Mandanten vorgesehen.
So verwaltet der Flottendienst RootSync-Objekte
Wenn Sie Config Sync mit der Google Cloud Console, der Google Cloud CLI, Config Connector oder Terraform installieren, wird Config Sync anhand Ihrer Eingaben in die Google Cloud API vom Flottendienst verwaltet.
Wenn Ihre Config Sync-Installation vom Flottendienst verwaltet wird, können Sie optional auch Ihr erstes RootSync-Objekt mit dem Namen root-sync verwalten lassen. So können Sie GitOps auf Ihrem Cluster booten, ohne etwas manuell direkt auf den Cluster anwenden zu müssen. Wenn Sie möchten, dass der Flottendienst Ihr anfängliches RootSync-Objekt nicht verwaltet, können Sie alle RootSync- und RepoSync-Objekte, die Sie möchten, direkt auf den Cluster anwenden.
Das RootSync-Objekt namens root-sync wird basierend auf Ihren Eingaben in dieGoogle Cloud API erstellt, insbesondere der Abschnitt spec.configSync der Config-Management Apply API. Da diese API nur eine Teilmenge der RootSync-Felder bereitstellt, gelten diese Felder in root-sync als verwaltet, während die anderen Felder als nicht verwaltet gelten. Verwaltete Felder können nur mit derGoogle Cloud API bearbeitet werden. Die nicht verwalteten Felder können mit kubectl oder einem anderen Kubernetes-Client bearbeitet werden.
Zusätzliche RootSync- und RepoSync-Objekte
Wenn Sie zusätzliche RootSync- oder RepoSync-Objekte erstellen möchten, können Sie das kubectl-Befehlszeilentool oder einen anderen Kubernetes-Client verwenden. Sie können auch das anfängliche root-sync-Objekt verwenden, um zusätzliche RootSync- oder RepoSync-Objekte mit GitOps zu verwalten. Fügen Sie dazu deren YAML-Manifeste der „Source of Truth“ hinzu, die die root-sync ist für die Synchronisierung von dort konfiguriert. Diese Methode kann nicht verwendet werden, um die Konfiguration der ursprünglichen root-sync zu verwalten, da einige ihrer Felder vom Flottendienst verwaltet werden. Wenn Sie das root-sync-Objekt mit GitOps verwalten möchten, verwenden Sie Config Connector oder Terraform. Weitere Informationen zum Erstellen zusätzlicher RootSync- und RepoSync-Objekte finden Sie unter Synchronisierung von mehr als einer „Source of Truth“ konfigurieren.
Nächste Schritte
- Möglicherweise möchten Sie Config Sync-Komponenten überwachen oder ihre Logs prüfen. Eine Einführung finden Sie unter Monitoring und Logs verwenden.
- Ressourcenanforderungen für Config Sync-Komponenten