Config Sync verwendet gehostete Komponenten in Google Cloud und Open-Source-Komponenten in Ihrem Google Kubernetes Engine-Cluster, um den Clusterstatus kontinuierlich mit einer zentralen Source of Truth abzugleichen. Wenn Sie wissen, wie diese Komponenten interagieren, können Sie skalierbare GitOps-Workflows entwerfen und Probleme bei der Synchronisierung oder Abstimmung beheben.
Architektur
Das folgende Diagramm zeigt die Architektur von Config Sync, einschließlich der Komponenten und Abhängigkeiten, sowohl in Google Cloud als auch in Ihrem GKE-Cluster:
Der Flottendienst verwaltet die Config Sync-Komponenten in Ihrem Cluster direkt, ohne den Legacy-ConfigManagement-Operator oder das ConfigManagement-Objekt. Sie müssen Config Sync bei Bedarf manuell aktualisieren.
Die Installation von Config Sync umfasst mehrere Schritte. Bei jedem dieser Schritte werden zusätzliche Komponenten in Ihrem Cluster bereitgestellt:
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 namens
resource-group-controller-manager. - Der OpenTelemetry Collector in einem Deployment namens
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)
Beim Erstellen von
RootSync- undRepoSync-Objekten werden die folgenden Komponenten hinzugefügt:- Für jedes
RootSync-Objekt ein Abgleichs-Deployment mit dem Namenroot-reconciler-ROOTSYNC_NAME. Für dasRootSync-Objekt mit dem Namenroot-syncheißt das Abgleichs-Deploymentroot-reconciler. Für jedes
RepoSync-Objekt ein Abgleichs-Deployment mit dem Namenns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH. Für dasRepoSync-Objekt mit dem Namenrepo-syncheißt das Abgleichs-Deploymentns-reconciler-REPOSYNC_NAMESPACE.
- Für jedes
Config Sync-Deployments, -Pods und -Container
In der folgenden Tabelle finden Sie weitere Informationen zu Config Sync-Deployment, -Pods und -Containern:
| Bereitstellungsname | Deployment-Namespace | Beschreibung der Bereitstellung | Anzahl der Replikate | Regulärer Ausdruck für Pod-Name | Anzahl der Container | Containernamen |
|---|---|---|---|---|---|---|
reconciler-manager |
config-management-system |
Der Reconciler Manager wird auf jedem Cluster ausgeführt, für den Config Sync im ConfigManagement-Objekt aktiviert ist. Er ü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 ein Root-Reconciler-Deployment 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 ein Namespace-Reconciler-Deployment erstellt. |
1 | ns-reconciler-.* |
3 - 51 |
reconcilerotel-agentgit-synchelm-syncoci-syncgcenode-askpass-sidecarhydration-controller |
otel-collector |
config-management-monitoring |
Der OpenTelemetry Collector wird auf jedem Cluster ausgeführt, für den Config Sync im ConfigManagement-Objekt aktiviert ist.
Er erfasst Messwerte von den Config Sync-Komponenten, die in 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 auf jedem Cluster ausgeführt, für den Config Sync im ConfigManagement-Objekt aktiviert ist. Er überwacht ResourceGroup-Objekte und aktualisiert sie mit dem aktuellen Abgleichsstatus der einzelnen Objekte 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 auf jedem Cluster ausgeführt, für den die Vermeidung von Abweichungen im ConfigManagement-Objekt aktiviert ist. Er überwacht Kubernetes API-Anfragen und verhindert, dass von Config Sync verwaltete Ressourcen geändert oder gelöscht 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.
Ressourcenanfragen für Bereitstellungen
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 Ressourcenanfragen 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 Ressourcenanfragen für Abgleicher. | |
1 Der Zugangs-Webhook hat zwei Replikate. Wenn Sie den Zugangs-Webhook verwenden und die gesamten Ressourcenanfragen 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 näher erläutert.
Flottendienst und das ConfigSync-Objekt
Der Hub-Flottendienst verwaltet die Config Sync-Komponenten in Ihrem Cluster:
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 Zustand Ihrer Config Sync-Installation zu überwachen.
Reconciler Manager und Reconciler
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, anstatt einen einzelnen monolithischen Reconciler freizugeben, da es die Zuverlässigkeit verbessert, indem es Single Points of Failure reduziert und es ermöglicht, einzelne Reconciler unabhängig voneinander zu skalieren.
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:
Abgleich-Container
Welche Container in den Abgleichs-Pods bereitgestellt werden, hängt von Ihren Konfigurationsoptionen ab. In der folgenden Tabelle finden Sie weitere Informationen zu den einzelnen Abgleichscontainern und der Bedingung, die Config Sync dazu veranlasst, sie zu erstellen:
| Containername | Beschreibung | Bedingung |
|---|---|---|
reconciler |
Übernimmt die Synchronisierung und die Behebung von Abweichungen. | Immer aktiviert. |
otel-agent |
Empfängt Messwerte von den anderen Reconciler-Containern und sendet sie an den OpenTelemetry Collector. | Immer aktiviert. |
git-sync |
Ruft Konfigurationen aus Ihrem Git-Repository in ein lokales Verzeichnis ab, das der Reconciler-Container lesen kann. | Aktiviert, wenn spec.sourceType git ist. |
helm-sync |
Ruft Helm-Diagramme aus Ihrem Diagramm-Repository ab und rendert sie in ein lokales Verzeichnis, das der Abgleichscontainer 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 Abgleichscontainer 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 Abgleichscontainer lesen kann. | Aktiviert, wenn die Quelle eine kustomize.yaml-Datei enthält. |
Wie in der obigen Tabelle gezeigt, können Sie in der Regel mit drei bis fünf Containern pro Abgleich-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.
Abgleicher-Ressourcenanfragen
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 Ressourcenanfragen sind für alle unterstützten Versionen von Config Sync gleich.
In der folgenden Tabelle sind die Ressourcenanfragen für Standard-Cluster 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 Ressourcenanfragen 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 Standardressourcenanfragen 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 Konfigurationen zu rendern. Die gebündelten Helm- und Kustomize-Versionen für Ihre Config Sync-Version finden Sie in den Feldern HELM_VERSION und KUSTOMIZE_VERSION in der Makefile des Config Sync-Open-Source-Repositorys.
Sie können in GitHub zwischen Zweigen wechseln, um die Versionen für verschiedene Config Sync-Releases aufzurufen.
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 einen Überblick über den Synchronisierungsstatus zu erhalten, 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 heißt 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 Selbstheilungsmechanismus, um Konfigurationsabweichungen rückgängig zu machen. Mit der Selbstreparatur überwacht Config Sync verwaltete Objekte kontinuierlich und macht Änderungen, die vom beabsichtigten Zustand 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 spec.override.roleRefs-Felder 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 bootstrappen, ohne manuell etwas 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 zum Verwalten der Konfiguration des ursprünglichen root-sync verwendet werden, da einige seiner Felder vom Fleet-Dienst verwaltet werden. Verwenden Sie Config Connector oder Terraform, um das root-sync-Objekt mit GitOps zu verwalten. 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.
- Ressourcenanfragen für Config Sync-Komponenten