Auf dieser Seite erhalten Sie eine Einführung in die Architektur von Config Sync. Wenn Sie mehr über die von Config Sync erstellten Komponenten erfahren, können Sie Config Sync besser verstehen und Probleme beheben.
Das folgende Diagramm zeigt die Architektur von Config Sync und den zugehörigen Ressourcen in einem GKE Enterprise Edition-Cluster (Google Kubernetes Engine):
In diesem Diagramm erstellt der Nutzer eine Source of Truth und installiert Config Sync mithilfe des Feature Managers.
Es sind mehrere Schritte zur Installation von Config Sync erforderlich. Mit 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:
- Der ConfigManagement-Operator in einem Deployment mit dem Namen
config-management-operator. - Die benutzerdefinierte
ConfigManagement-Ressourcendefinition (CRD) und das Objekt mit dem Namenconfig-management. - Der Reconciler Manager in einer Bereitstellung 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.
Die meisten dieser Ressourcen und Objekte werden bei der Installation von Config Sync automatisch erstellt und müssen nicht geändert werden.
- Der ConfigManagement-Operator in einem Deployment mit dem Namen
Wenn Sie
RootSync- undRepoSync-Objekte erstellen, werden die folgenden Komponenten hinzugefügt:- Für jeden
RootSynceine Abgleicher-Bereitstellung mit dem Namenroot-reconciler-ROOTSYNC_NAME. - Für jeden
RepoSynceine Abgleicher-Bereitstellung mit dem Namenns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH.
- Für jeden
Config Sync-Deployments, -Pods und -Container
Die folgende Tabelle enthält weitere Informationen zum Deployment, zu den Pods und zu den Containern von Config Sync:
| Bereitstellungsname | Deployment-Namespace | Beschreibung der Bereitstellung | Anzahl der Replikate | Regulärer Ausdruck für Pod-Namen | Anzahl der Container | Containernamen |
|---|---|---|---|---|---|---|
config-management-operator |
config-management-system |
Der ConfigManagement Operator wird auf jedem Cluster mit installiertem Config Sync ausgeführt. Er überwacht das Objekt ConfigManagement und verwaltet Config Sync-Komponenten wie den Reconciler Manager und den OpenTelemetry Collector. |
1 | config-management-operator-.* |
1 | manager |
reconciler-manager |
config-management-system |
Der Reconciler Manager wird auf jedem Cluster mit aktiviertem Config Sync im ConfigManagement-Objekt ausgeführt. Es beobachtet RootSync- und RepoSync-Objekte und verwaltet jeweils eine Abgleicher-Bereitstellung. |
1 | reconciler-manager-.* |
2 | reconciler-managerotel-agent |
root-reconciler |
config-management-system |
Für jedes RootSync-Objekt wird eine Root-Abgleichsbereitstellung 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-Abgleicher-Bereitstellung 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 mit aktiviertem Config Sync im ConfigManagement-Objekt ausgeführt. Sie erfasst Messwerte aus den Config Sync-Komponenten, die unter den Namespaces config-management-system und resource-group-system ausgeführt werden, und exportiert diese Messwerte in Prometheus und Cloud Monitoring. |
1 | otel-collector-.* |
1 | otel-collector |
resource-group-controller-manager |
resource-group-system |
Der ResourceGroup Controller wird auf jedem Cluster mit aktiviertem Config Sync im ConfigManagement-Objekt ausgeführt. Er ü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 | reconciler-managerotel-agent |
admission-webhook |
config-management-system |
Der Config Sync-Zulassungs-Webhook wird auf jedem Cluster ausgeführt, wobei die Drift-Prävention im Objekt ConfigManagement aktiviert ist. Er überwacht Kubernetes API-Anfragen und verhindert das Ändern oder Löschen 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 zum Erstellen dieser Container finden Sie unter Abgleicher-Container.
Schlüsselkomponenten
In den folgenden Abschnitten werden wichtige Config Sync-Komponenten ausführlicher erläutert.
ConfigManagement Operator und Objekt
Der ConfigManagement Operator überwacht das Objekt ConfigManagement und erstellt und verwaltet andere Komponenten, die für Config Sync erforderlich sind:
Da der ConfigManagement Operator einige Komponenten installiert, die Berechtigungen vom Typ cluster-admin erfordern, benötigt der ConfigManagement Operator auch Berechtigungen vom Typ cluster-admin.
Reconciler Manager und Abgleicher
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 jedeRootSync Objekt und einen Namespace-Abgleicher für jedeRepoSync Objekt. Config Sync verwendet dieses Design, anstatt einen einzelnen monolithischen Abgleicher zu nutzen, da es die Zuverlässigkeit verbessert, indem Single Points of Failure reduziert werden und die unabhängige Skalierung einzelner Abgleicher ermöglicht.
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 spezifischen Container in den Abgleich-Pods bereitgestellt werden, hängt von den getroffenen Konfigurationsentscheidungen ab. In der folgenden Tabelle wird erläutert, was die einzelnen Abgleich-Container tun und welche Bedingung Config Sync dazu führt, dass sie erstellt werden:
| Containername | Beschreibung | Bedingung |
|---|---|---|
reconciler |
Führt die Synchronisierung und Behebung von Drifts aus. | Immer aktiviert. |
otel-agent |
Er empfängt Messwerte von den anderen Abgleich-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 Abgleich-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 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 Abgleichscontainer lesen kann. | Aktiviert, wenn spec.sourceType oci ist. |
gcenode-askpass-sidecar |
Speichert Git-Anmeldedaten aus dem GKE-Metadatendienst im Cache zur Verwendung durch den git-sync-Container. |
Aktiviert, wenn spec.sourceType git und spec.git.auth gleich gcenode oder gcpserviceaccount ist. |
hydration-controller |
Verarbeitet das Erstellen von Kustomize-Konfigurationen in einem lokalen Verzeichnis, das der Abgleicher-Container lesen kann. | Wird aktiviert, wenn die Quelle eine kustomize.yaml-Datei enthält. |
Wie in der vorherigen Tabelle gezeigt, können Sie in der Regel eine Containeranzahl von drei bis fünf innerhalb jedes Abgleich-Pods erwarten. 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.
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. Auf diese Weise können Sie den Status des Objekts ResourceGroup 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 Objekt RootSync mit dem Namen root-sync im Namespace config-management-system heißt das entsprechende ResourceGroup-Objekt ebenfalls root-sync im config-management-system-Namespace
Erstellen oder ändern Sie keine ResourceGroup-Objekte, da dies die Ausführung 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 Selbstreparaturmechanismus, um Konfigurationsabweichungen rückgängig zu machen. Bei 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. Auf diese Weise können Sie GitOps auf Ihrem Cluster booten, 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 die Google 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 der Google Cloud API bearbeitet werden. Die nicht verwalteten Felder können mit kubectl oder einem anderen Kubernetes-Client bearbeitet werden. Ein Beispiel, das zeigt, wie Sie die YAML-Datei root-sync exportieren, lokal bearbeiten und noch einmal anwenden, finden Sie unter RootSync-Konfigurationsdatei erstellen und bearbeiten.
Bei manuellen Installationen verwalten Sie Config Sync mit dem kubectl-Befehlszeilentool oder einem anderen Kubernetes-Client.
Zusätzliche RootSync- und RepoSync-Objekte
Zum Erstellen zusätzlicher RootSync- oder RepoSync-Objekte 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 ersten root-sync verwendet werden, da einige seiner Felder vom Flottendienst verwaltet werden. Verwenden Sie Config Connector oder Terraform, um das Objekt root-sync 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
- Sie können Config Sync-Komponenten überwachen oder deren Logs prüfen. Eine Einführung finden Sie unter Monitoring und Logs verwenden.
- Ressourcenanfragen für Config Sync-Komponenten