RootSync- und RepoSync-Felder

Diese Seite enthält eine Referenz für RootSync-, RepoSync- und ResourceGroup-Ressourcen.

Sie können Config Sync mit RootSync- und RepoSync-Ressourcen konfigurieren.

RootSync-Objekte konfigurieren Config Sync so, dass die angegebene Quelle beobachtet und Objekte aus dieser Quelle auf den Cluster angewendet werden. RootSyncs können zum Verwalten aller Ressourcen im Cluster mit „cluster-admin“-Berechtigungen verwendet werden.

RepoSync-Objekte konfigurieren Config Sync so, dass die angegebene Quelle beobachtet und Objekte aus dieser Quelle auf einen bestimmten Namespace im Cluster angewendet werden. RepoSync-Objekte werden verwendet, um alle Namespace-bezogenen Ressourcen in diesem Namespace mit benutzerdefinierten benutzerdefinierten Berechtigungen zu verwalten.

Die ResourceGroup-Ressource wird von Config Sync verwendet, um das Inventar der zuvor angewendeten und derzeit verwalteten Objekte beizubehalten. Config Sync erstellt ein ResourceGroup-Objekt für jedes RootSync- und RepoSync-Objekt im Cluster. Dadurch kann Config Sync Objekte, die aus der Quelle entfernt wurden, bereinigen und den Synchronisierungs- und Abgleichsstatus von Objekten zusammenfassen. Sie müssen weder eigene ResourceGroup-Objekte erstellen noch von Config Sync verwaltete Objekte ändern.

Verwendung von RootSync- und RepoSync-Objekten

Wenn Sie Config Sync über die Google Cloud Console oder die Google Cloud CLI installiert haben, erstellt der Hub-Dienst automatisch ein RootSync-Objekt mit dem Namen root-sync. Informationen zum Erstellen zusätzlicher RootSync-Objekte finden Sie unter Root-Repositories in einem Root-Repository steuern.

Wenn Sie Config Sync mit kubectl installiert haben, finden Sie unter Root-Repositories in einem Root-Repository steuern Informationen zum Erstellen von RootSync-Objekten.

Informationen zum Erstellen von RepoSync-Objekten finden Sie unter Namespace-Repositories in einem Root-Repository steuern oder Namespace-Repositories in einem Namespace-Repository steuern.

Neben der Synchronisierung vollständig gerenderter Kubernetes-Objekte können Sie Config Sync auch so konfigurieren, dass ein Repository mit Kustomize-Konfigurationen oder Helm-Diagrammen verwendet wird.

Lebenszyklus von RootSync-, RepoSync- und ResourceGroup-Objekten

Die benutzerdefinierten Ressourcendefinitionen für RootSync, RepoSync und ResourceGroup werden installiert, wenn Sie Config Sync installieren.

Das folgende Diagramm bietet eine Übersicht darüber, wie Config Sync die RootSync-, RepoSync- und ResourceGroup-Ressourcen erstellt:

Diagramm: Aktivierung durch den Operator

Nach der Erstellung steuert der Abgleichsmanager den Lebenszyklus des Root-Abgleichers und die einzelnen Namespace-Abgleichsprozesse:

Diagramm: Abgleichaktivierung

RootSync- und RepoSync-Felder

RootSync- und RepoSync-CRDs verwenden dieselben Felder, mit Ausnahme der folgenden reinen RootSync-Felder:

  • spec.sourceFormat
  • spec.helm.namespace
  • spec.helm.deployNamespace

Konfiguration für das Quellformat

Schlüssel Beschreibung
spec.sourceFormat sourceFormat gibt an, wie das Repository formatiert ist. Optional.
Bei der Validierung dieses Feldes wird zwischen Groß- und Kleinschreibung unterschieden.
  • Bei RootSync-Objekten muss der Wert entweder hierarchy oder unstructured sein. Der Standardwert ist hierarchy, wenn nicht angegeben, aber unstructured empfohlen wird.
Weitere Informationen finden Sie in den Anleitungen für unstrukturiertes und hierarchisches Format.

Konfiguration für den Quelltyp

Schlüssel Beschreibung
spec.sourceType sourceType gibt den Typ der Quelle der Wahrheit an. Muss git, oci oder helm sein. Optional.
Wird auf git festgelegt, wenn keine Angabe erfolgt. Bei der Validierung dieses Feldes wird zwischen Groß- und Kleinschreibung unterschieden.
Je nach Quelltyp kann nur entweder spec.git oder spec.oci angegeben werden.

Konfiguration für das Git-Repository

Schlüssel Beschreibung
spec.git.auth Die Art des Secrets, das für den Zugriff auf das Git-Repository konfiguriert ist. Es muss sein: ssh, cookiefile, gcenode, gcpserviceaccount, token oder none. Bei der Validierung dieses Feldes wird zwischen Groß- und Kleinschreibung unterschieden. Erforderlich.
spec.git.gcpServiceAccountEmail Das Google Cloud-Dienstkonto, das zum Annotationen des Kubernetes-Dienstkontos des RootSync- oder RepoSync-Controllers verwendet wird. Dieses Feld wird nur verwendet, wenn spec.git.auth den Wert gcpserviceaccount hat.
spec.git.branch Zweig des Repositorys, von dem aus synchronisiert werden soll. Standardeinstellung: master.
spec.git.dir Absoluter Pfad im Git-Repository zu dem Stammverzeichnis mit der Konfiguration, die Sie synchronisieren möchten. Standardeinstellung: Stammverzeichnis (/) des Repositorys.
spec.git.period Der Zeitraum zwischen aufeinanderfolgenden Synchronisierungen. Standardeinstellung: 15s.
spec.git.repo Die Git-Repository-URL, von der aus synchronisiert werden soll. Erforderlich.
spec.git.revision Die Git-Revision (Tag, Commit oder Hash) zum Auschecken. Standardeinstellung: HEAD.
spec.git.secretRef.name Der Name des Secrets, das zum Herstellen einer Verbindung zur Git-„Source of Truth“ verwendet wird.
spec.git.noSSLVerify1 noSSLVerify gibt an, ob die SSL-Zertifikatsüberprüfung aktiviert oder deaktiviert werden soll. Standardeinstellung: false.
Wenn noSSLVerify auf "true" gesetzt ist, wird Git angewiesen, die SSL-Zertifikatsprüfung zu überspringen.
Dieses Feld wird in Config Management Version 1.8.2 und höher unterstützt.
spec.git.caCertSecretRef.name1 Der Name des Secrets, das das Zertifikat der Zertifizierungsstelle enthält. Ist dieses Feld angegeben, muss der Git-Server ein von dieser Zertifizierungsstelle ausgestelltes Zertifikat verwenden. Das CA-Zertifikat muss im Secret unter einem Schlüssel namens "cert“ gespeichert werden.

Proxykonfiguration für das Git-Repository

Wenn Sie gemäß den Sicherheitsrichtlinien Ihrer Organisation Traffic über einen HTTP(S)-Proxy weiterleiten müssen, können Sie Config Sync für die Kommunikation mit Ihrem Git-Host über den URI des Proxys konfigurieren.

Schlüssel Beschreibung
spec.git.proxy Die Proxy-URL mit Schema zum Konfigurieren des Zugriffs auf das Git-Repository mithilfe eines Proxys. Beispiel: https://proxy.internal.business.co:443.
Der Git-Proxy akzeptiert https, http und nicht formatierte URLs, http wird jedoch aus Sicherheitsgründen nicht empfohlen.
Wenn Sie http oder eine URL ohne Formatierung verwenden, achten Sie darauf, dass die Kommunikation zwischen Ihrem Proxyserver und Git-Host sicher ist.
Dieses Feld wirkt sich nur aus, wenn spec.git.auth den Wert cookiefile, none oder token hat.

Konfiguration für das OCI-Image

Config Sync erfordert, dass die OCI-Ebene in einem der Formate tar oder tar+gzip komprimiert ist.

Andere Formate (z. B. tar+bz2) werden von Config Sync nicht erkannt. Der Wechsel von einem gültigen REPO-Konto zu einem OCI-Image mit einem nicht unterstützten Format führt dazu, dass verwaltete Ressourcen ohne Fehlermeldung gelöscht werden.

Schlüssel Beschreibung
spec.oci.auth Die Authentifizierungsart, die für den Zugriff auf das OCI-Image konfiguriert ist. Muss gcenode, gcpserviceaccount oder none sein. Bei der Validierung dieses Feldes wird zwischen Groß- und Kleinschreibung unterschieden. Erforderlich.
spec.oci.gcpServiceAccountEmail Das Google Cloud-Dienstkonto, das zum Annotationen des Kubernetes-Dienstkontos des RootSync- oder RepoSync-Controllers verwendet wird. Dieses Feld wird nur verwendet, wenn spec.oci.auth den Wert gcpserviceaccount hat.
spec.oci.dir Absoluter Pfad im OCI-Image zu dem Stammverzeichnis mit der Konfiguration, die Sie synchronisieren möchten. Standardeinstellung: Stammverzeichnis (/) des Images.
spec.oci.period Der Zeitraum zwischen aufeinanderfolgenden Synchronisierungen. Standardeinstellung: 15s.
spec.oci.image Die OCI-Image-URL, von der aus synchronisiert werden soll. Erforderlich.

Konfiguration für das Helm-Repository

Schlüssel Beschreibung
spec.helm.auth Der Authentifizierungstyp, der für den Zugriff auf das Helm-Repository konfiguriert ist. Muss token, gcenode, gcpserviceaccount oder none sein. Bei der Validierung dieses Feldes wird zwischen Groß- und Kleinschreibung unterschieden. Erforderlich.
spec.helm.gcpServiceAccountEmail Das Google Cloud-Dienstkonto, das zum Annotationen des Kubernetes-Dienstkontos des RootSync- oder RepoSync-Controllers verwendet wird. Dieses Feld wird nur verwendet, wenn spec.helm.auth den Wert gcpserviceaccount hat.
spec.helm.secretRef.name Der Name des Secrets, mit dem auf das Helm-Repository zugegriffen wird. Dieses Feld wird nur verwendet, wenn spec.helm.auth den Wert token hat.
spec.helm.repo Die Helm-Repository-URL, von der aus synchronisiert werden soll. Erforderlich.
spec.helm.chart Der Name des Helm-Diagramms. Erforderlich.
spec.helm.version

Die Versionsnummer des Helm-Diagramms. Standardeinstellung: die neueste Version.

In Config Sync-Versionen vor 1.16.0 ist das Versionsfeld verfügbar, aber nur statische Versionen werden unterstützt und Diagramme werden nicht noch einmal abgerufen. In Config Sync Version 1.16.0 und höher kann das Versionsfeld als statischer Wert, als Versionsbereich, aus dem Config Sync das aktuelle Datum abruft, angegeben werden. Wenn Sie das Feld leer lassen, wird angegeben, dass Config Sync das neueste Diagramm gemäß semver erstellt. Wenn dieser Bereich als Bereich angegeben oder leer gelassen wird, um den aktuellen Wert anzugeben, wird das Diagramm von Config Sync standardmäßig alle 1 Stunde neu abgerufen. In Config Sync Version 1.16.1 und höher kann der Re-Abruf-Zeitraum mit dem Feld spec.helm.period konfiguriert werden. Wenn die Version als literaler String „latest“ angegeben ist, wird das Diagramm genau wie bei Versionsbereichen oder leeren Versionen gemäß spec.helm.period noch einmal abgerufen.

Die Syntax für Versionsbereiche ist identisch mit der Syntax für Versionsbereiche, die von der Helm-Befehlszeile unterstützt wird.

Wenn Sie die Version als Bereich angeben oder den Wert leer lassen, kann dies bei großen Diagrammen mit vielen Versionen zu einer hohen CPU-Auslastung führen. Mit spec.override können Sie die CPU-Anfrage für den helm-sync-Container erhöhen, wie im folgenden Beispiel gezeigt:


    spec:
      override:
        resources:
        - containerName: helm-sync
          cpuRequest: "200m"
spec.helm.period

In Config Sync Version 1.16.1 und höher ist spec.helm.period die Zeit, die Config Sync wartet, bevor das Diagramm noch einmal abgerufen wird.

Der Standardwert beträgt 1 Stunde. Das Feld akzeptiert Stringwerte wie „30s“ oder „5m“. Weitere Informationen finden Sie in der Go-Dokumentation zu gültigen Eingaben.

Wenn die Diagrammversion ein Bereich ist, das Literal-Tag „latest“ verwendet oder leer bleibt, um anzugeben, dass Config Sync die neueste Version abrufen soll, wird das Diagramm gemäß spec.helm.period noch einmal abgerufen. Wenn die Diagrammversion als einzelne statische Version angegeben ist, wird das Diagramm nicht noch einmal abgerufen.
spec.helm.releaseName Der Name des Helm-Release.
spec.helm.namespace Dies schließt sich mit spec.helm.deployNamespace gegenseitig aus.
namespace legt den Ziel-Namespace für einen Release fest. Dieses Feld wird nur für RootSync-Objekte verwendet. Er legt den Namespace nur für Ressourcen fest, die in ihren Vorlagen namespace: {{ .Release.Namespace }} enthalten. Der in spec.helm.namespace angegebene Wert wird nur als der Wert von Release.Namespace verwendet, der in Ihren Helm-Vorlagen deklariert ist. Für Ressourcen, deren Vorlagen nicht namespace: {{ .Release.Namespace }} enthalten, wird der Namespace default verwendet. Standardeinstellung: default
spec.helm.deployNamespace Dies schließt sich mit spec.helm.namespace gegenseitig aus.
deployNamespace gibt an, in welchem Namespace das Diagramm bereitgestellt werden soll. Wenn Sie dieses Feld festlegen, wird die kpt set-namespace-Funktion verwendet. Dies bewirkt, dass Config Sync die namespace-Ressourcenfelder im Diagramm ersetzt, einschließlich metadata.namespace von Namespace-bezogenen Ressourcen, metadata.name von Namespace-Objekten und Namespace-Verweise in einigen speziellen Ressourcentypen.
Wenn deployNamespace nicht festgelegt ist, werden Ressourcen, für die metadata.namespace nicht festgelegt ist, im Standard-Namespace bereitgestellt.
spec.helm.values

Anstelle der Standardwerte des Diagramms zu verwendende Werte Formatieren Sie die Werte auf die gleiche Weise mit der Datei default values.yaml. Beispiel:


values:
  foo:
    bar: val1
  quz:
  - val2
  - val3

Wenn auch valuesFileRefs angegeben ist, überschreiben Felder aus values Felder von valuesFileRefs.

Weitere Informationen finden Sie im Beispielmanifest für Helm.
spec.helm.includeCRDs Gibt an, ob die Helm-Vorlage CustomResourceDefinitions generieren soll. Standardeinstellung: false.
spec.helm.valuesFileRefs

Eine Liste von Referenzen auf Objekte im Cluster, die Werte darstellen, die anstelle der Standardwerte im Diagramm verwendet werden sollen. Es werden nur ConfigMaps unterstützt. Die ConfigMap muss unveränderlich sein und sich im selben Namespace wie RootSync oder RepoSync befinden.

ConfigMaps sind unveränderlich. Wenn Sie die „valuesFile“ nach der Synchronisierung ändern möchten, müssen Sie eine ConfigMap mit einem anderen Namen erstellen und die RootSync- oder RepoSync-spec.valuesFileRefs.name aktualisieren.

Wenn Dateien mit mehreren Werten angegeben sind, überschreiben doppelte Schlüssel in späteren Dateien den Wert aus früheren Dateien. Dies entspricht der Übergabe mehrerer Wertedateien an die Helm-Befehlszeile. Wenn auch spec.helm.values angegeben ist, überschreiben Felder aus values Felder von valuesFileRefs.

Jeder Eintrag in der Liste muss Folgendes enthalten:

  • name (erforderlich): der Name des ConfigMap-Objekts
  • dataKey (optional): Der Datenschlüssel im Objekt, aus dem die Werte gelesen werden sollen. Standard: values.yaml

Dieses Feld wird in Config Management 1.16.0 und höher unterstützt.

Ein Beispiel für das Ändern von Werten finden Sie unter /anthos-config-management/docs/how-to/sync-helm-charts-from-artifact-registry#valuesfilerefs.

Konfiguration zum Überschreiben der Ressourcenanfragen und -limits eines Root- oder Namespace-Abgleichers

Sie können die Container git-sync, oci-sync, helm-sync, hydration-controller und reconciler überschreiben. Das teilweise Überschreiben ist zulässig: Wenn kein Überschreibungswert für eine Ressourcenanfrage oder ein Limit angegeben ist, wird der Standardressourcenwert für die Anfrage oder das Limit verwendet.

Bei Autopilot-Clustern ignoriert Config Sync Überschreibungen von Ressourcenlimits. Überschreibungen von Ressourcenanfragen werden nur angewendet, wenn eine oder mehrere Ressourcenanfragen höher sind als die entsprechende in der Annotation deklarierte Ausgabe oder eine oder mehrere Ressourcenanfragen, die niedriger sind als die entsprechende Eingabe in der Annotation. Weitere Informationen finden Sie unter Clusteranforderungen für Config Sync.

Schlüssel Beschreibung
spec.override.resources1 Die Liste der Überschreibungen für Containerressourcen und -limits. Optional.
Jedes Element in der Liste enthält drei Felder:
  • containerName: Dieses Feld kann entweder git-sync, oci-sync, helm-sync, hydration-controller oder reconciler sein.
  • cpuRequest (optional)
  • cpuLimit (optional)
  • memoryRequest (optional)
  • memoryLimit (optional)

Wenn kein Überschreibungswert für eine Ressourcenanfrage oder -grenze angegeben ist, wird der Standardressourcenwert für die Anfrage oder das Limit verwendet.

Konfiguration zum Überschreiben der Logebene eines Containers im Root- oder Namespace-Abgleich

Wenn kein Wert für die Überschreibung auf Protokollebene festgelegt ist, wird die Protokollebene als Standardwert konfiguriert. Die Standard-Logebene für alle Container in einem RootSync- oder RepoSync-Abgleich ist 0, mit Ausnahme des Git-Sync-Containers, bei dem der Standardwert 5 ist. Der zulässige Überschreibungswert auf Logebene liegt zwischen 0 und einschließlich 10.

Schlüssel Beschreibung
spec.override.logLevels Die Liste der Werte für die Überschreibung der Containerlogebene. Optional.
Jeder Eintrag in der Liste enthält zwei Felder:
  • containerName: Dieses Feld kann entweder git-sync, oci-sync, helm-sync, hydration-controller oder reconciler sein.
  • logLevel

Wenn für die Logebene eines Containers kein Überschreibungswert angegeben ist, wird der Standardwert der Logebene verwendet.

Konfiguration für die Anzahl der abzurufenden Git-Commits

Schlüssel Beschreibung
spec.override.gitSyncDepth1 Mit gitSyncDepth können Sie die Anzahl der abzurufenden Git-Commits überschreiben.
Darf nicht kleiner als 0 sein.
Config Sync führt einen vollständigen Klon aus, wenn das Feld 0 ist, und einen "oberflächlichen" Klon, wenn das Feld größer als 0 ist.
Wenn dieses Feld nicht angegeben ist, wird es von Config Sync automatisch konfiguriert.

Konfiguration zum Erfassen des Status auf Ressourcenebene

Schlüssel Beschreibung
spec.override.statusMode1 Mit statusMode können Sie die Erfassung des Status auf Ressourcenebene aktivieren oder deaktivieren.
Der Standardwert ist enabled.
Legen Sie für dieses Feld disabled fest, wenn Sie die Erfassung des Status auf Ressourcenebene deaktivieren möchten.

Konfiguration zum Überschreiben der Abgleichzeitüberschreitung

Schlüssel Beschreibung
spec.override.reconcileTimeout1 Mit reconcileTimeout können Sie den Schwellenwert für die Wartezeit bis zum Abgleich der Ressourcen in einer Apply-Gruppen überschreiben, bevor der Vorgang abgebrochen wird. Alle Ressourcen in einem Commit können sich je nach Abhängigkeiten in mehreren Apply-Gruppen befinden.
Das Standardzeitlimit ist 5m.
Verwenden Sie einen String, um diesen Feldwert anzugeben, z. B. 30s, 5m.

Konfiguration zum Überschreiben des Zeitlimits für Anfragen an den API-Server

Schlüssel Beschreibung
spec.override.apiServerTimeout1 Mit apiServerTimeout können Sie das Zeitlimit für Anfragen an den API-Server überschreiben. Das Standardzeitlimit ist 5s in Config Management-Versionen vor 1.16.0 und 15s in Config Management-Versionen ab 1.16.0.
Verwenden Sie einen String, um diesen Feldwert anzugeben, z. B. 30s oder 5m.

Konfiguration für den Shell-Zugriff im Renderingprozess

Schlüssel Beschreibung
spec.override.enableShellInRendering1 enableShellInRendering gibt an, ob der Shell-Zugriff im Renderingprozess aktiviert oder deaktiviert wird. Kustomize-Remotebasisdaten erfordern Shell-Zugriff. Wenn Sie dieses Feld auf true setzen, wird der Shell-Zugriff im Renderingprozess aktiviert und das Abrufen von Remote-Basisdaten aus öffentlichen Repositories wird unterstützt.
Der Standardwert ist false.

Status der Objekte

Schlüssel Beschreibung
status.observedGeneration Die Generation (metadata.generation) der Spezifikation einer RootSync- oder RepoSync-Ressource, die zuletzt von Config Sync beobachtet und bearbeitet wurde. Dieser Wert kann mit metadata.generation verglichen werden, einer Ganzzahl, die bei einer Spezifikationsmutation vom API-Server aktualisiert wird.
status.reconciler Name des Abgleichvorgangs, der der Synchronisierungsressource entspricht.
status.source.gitStatus.repo Die Git-Repository-URL, die abgerufen wird.
status.source.gitStatus.revision Abzurufende Git-Revision (Tag, Commit oder Hash).
status.source.gitStatus.branch Git-Zweig des abgerufenen Repositorys.
status.source.gitStatus.dir Absoluter Pfad im Git-Repository zum Stammverzeichnis, das die Konfiguration enthält, mit der Sie synchronisieren.
status.source.ociStatus.image Die abgerufene OCI-Image-URL.
status.source.ociStatus.dir Absoluter Pfad im OCI-Image zum Stammverzeichnis, das die Konfiguration enthält, mit der Sie synchronisieren.
status.source.helmStatus.repo Die abgerufene Helm-Repository-URL.
status.source.helmStatus.version Die abgerufene Version des Helm-Diagramms.
status.source.helmStatus.chart Der Name des abgerufenen Helm-Diagramms.
status.source.commit Der Hash des letzten Commits oder Digests, der von der Quell-URL abgerufen wurde.
status.source.errors Eine Liste aller Fehler, die beim Lesen aus dem Repository aufgetreten sind.
status.rendering.gitStatus.repo Die Git-Repository-URL, die gerendert wird.
status.rendering.gitStatus.revision Die Git-Revision (Tag, Commit oder Hash), die gerendert wird.
status.rendering.gitStatus.branch Der Git-Zweig des Repositorys, das gerendert wird.
status.rendering.gitStatus.dir Der absolute Pfad im Git-Repository zum Stammverzeichnis, das die Konfiguration enthält, die Sie rendern.
status.rendering.ociStatus.image Die OCI-Image-URL, die gerendert wird.
status.rendering.ociStatus.dir Absoluter Pfad im OCI-Image zum Stammverzeichnis, das die Konfiguration enthält, die Sie rendern.
status.rendering.helmStatus.repo Die Helm-Repository-URL, die gerendert wird.
status.rendering.helmStatus.version Die Version des Helm-Diagramms, das gerendert wird.
status.rendering.helmStatus.chart Der Name des gerenderten Helm-Diagramms.
status.rendering.commit Hash des letzten gerenderten Commits oder Digests. Dieser Wert wird auch dann aktualisiert, wenn ein Commit oder Digest aufgrund eines Fehlers nur teilweise synchronisiert wird.
status.rendering.errors Eine Liste aller Fehler, die beim Rendern der Ressourcen aus der durch status.rendering.commit angegebenen Änderung aufgetreten sind.
status.sync.gitStatus.repo Git-Repository-URL, die synchronisiert wird.
status.sync.gitStatus.revision Die Git-Revision (Tag, Commit oder Hash), die gerendert wird.
status.sync.gitStatus.branch Der Git-Zweig des Repositorys, das synchronisiert wird.
status.sync.gitStatus.dir Absoluter Pfad im Git-Repository zum Stammverzeichnis, das die Konfiguration enthält, mit der Sie synchronisieren.
status.sync.ociStatus.image Die OCI-Image-URL, die synchronisiert wird.
status.sync.ociStatus.dir Absoluter Pfad im OCI-Image zum Stammverzeichnis, das die Konfiguration enthält, mit der Sie synchronisieren.
status.sync.helmStatus.repo Die zu synchronisierende Helm-Repository-URL.
status.sync.helmStatus.version Die Version des Helm-Diagramms, das synchronisiert wird.
status.sync.helmStatus.chart Der Name des Helmdiagramms, das synchronisiert wird.
status.sync.commit Der Hash des letzten Commits oder Digests, der mit dem Cluster synchronisiert wurde. Dieser Wert wird auch dann aktualisiert, wenn ein Commit oder Digest aufgrund eines Fehlers nur teilweise synchronisiert wird.
status.sync.errors Eine Liste aller Fehler, die beim Anwenden der Ressourcen aus der durch status.sync.commit angegebenen Änderung aufgetreten sind.
status.conditions Die neuesten verfügbaren Beobachtungen zum aktuellen Status von RootSync.

1 Wenn Sie nach der Installation mit der Google Cloud Console oder der Google Cloud CLI eine RootSync-Konfigurationsdatei erstellt haben, können Sie dieses Feld überschreiben. Eine vollständige Liste finden Sie unter Bearbeitbare Felder.

ResourceGroup-Felder

Spezifikationen und Statusfelder

Schlüssel Beschreibung
spec.resources Die Liste der Kennungen (Gruppe, Art, Namespace, Name) für Ressourcen, die aus dem Git-Repository auf den Cluster angewendet werden, der in einer RepoSync-CR oder einer RootSync-CR angegeben ist. Optional.
Jedes Element in der Liste enthält vier Felder: group, kind, namespace und name.

Statusfelder

Schlüssel Beschreibung
status.observedGeneration Die Generation (metadata.generation) der Spezifikation einer RootSync- oder RepoSync-Ressource, die zuletzt vom ResourceGroup-Controller beobachtet und bearbeitet wurde. Dieser Wert kann mit metadata.generation verglichen werden, einer Ganzzahl, die bei einer Spezifikationsmutation vom API-Server aktualisiert wird.
status.conditions Die zuletzt beobachteten Bedingungen für die aktuelle ResourceGroup. Die Bedingungen haben zwei verschiedene Typen: Reconciling und Stalled. Wenn die Bedingung des Typs Reconciling „true“ ist, bedeutet dies, dass die aktuelle ResourceGroup abgeglichen wird. Wenn die Bedingung des Typs Stalled „true“ ist, bedeutet dies, dass der Abgleich angehalten wurde. Wenn beide "false" sind, wird die aktuelle ResourceGroup abgeglichen und der Status ist auf dem neuesten Stand.
status.resourceStatuses Die Liste der Status für Ressourcen, die in ".spec.resources" enthalten sind. Jedes Element enthält die ID (Gruppe, Art, Namespace oder Name) und den Status einer Ressource. Der Status ist einer der folgenden: InProgress, Current, Failed, Terminating, NotFound oder Unknown.

Verwaltete und nicht verwaltete Root-Synchronisierungsfelder

Es gibt zwei Möglichkeiten, Config Sync zu installieren:

Bei den meisten Installationen wird Config Sync vom Hub-Dienst verwaltet, basierend auf Ihren Eingaben in die Google Cloud API, insbesondere im Abschnitt spec.configSync der config-management apply API.

Bei GKE Enterprise auf VMware wird Config Sync vom Nutzer mit kubectl oder einem anderen Kubernetes-Client verwaltet.

Wenn Ihre Config Sync-Installation vom Hub-Dienst verwaltet wird, kann Ihre anfängliche RootSync optional auch vom Hub-Dienst verwaltet werden. So können Sie GitOps auf Ihrem Cluster mithilfe der Config-management Apply API und des von Ihnen bevorzugten Google Cloud-Clients wie Google Cloud Console, Google Cloud CLI, Config Connector, Terraform usw. starten. Diese erste verwaltete RootSync-Anfrage wird root-sync genannt.

Diese root-sync wird anhand Ihrer Eingaben in die Google Cloud API erstellt, insbesondere der Konfiguration der Anwendung der Spezifikation für Config Sync. Da diese API nur einen Teil der RootSync-Felder verfügbar macht, gelten diese Felder in der root-sync als verwaltet, während die anderen Felder als nicht verwaltet gelten. Die verwalteten 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.

Unter RootSync-Konfigurationsdatei erstellen und bearbeiten wird beispielsweise beschrieben, wie Sie die YAML-Datei root-sync exportieren, lokal bearbeiten und noch einmal anwenden.

Zum Erstellen zusätzlicher RootSyncs oder RepoSyncs können Sie kubectl oder einen anderen Kubernetes-Client verwenden. Sie können auch die anfängliche root-sync verwenden, um zusätzliche RootSyncs und Repositorys mit GitOps zu verwalten. Dazu fügen Sie deren YAML-Manifeste der „Source of Truth“ hinzu, von der die root-sync für die Synchronisierung konfiguriert ist. Mit dieser Methode kann die Konfiguration der anfänglichen root-sync nicht verwaltet werden, da einige der Felder vom Hub-Dienst verwaltet werden. Verwenden Sie Config Connector oder Terraform, um root-sync mit GitOps zu verwalten.

Die folgenden Felder der RootSync-Funktion root-sync werden nicht vom Hub-Dienst verwaltet und können mit jedem Kubernetes-Client bearbeitet werden:

Schlüssel Beschreibung
spec.git.noSSLVerify noSSLVerify gibt an, ob die SSL-Zertifikatüberprüfung aktiviert oder deaktiviert ist. Standardeinstellung: false
Wenn noSSLVerify auf true gesetzt ist, wird Git angewiesen, die SSL-Zertifikatsprüfung zu überspringen.
spec.git.caCertSecretRef.name Der Name des Secrets, das das Zertifikat der Zertifizierungsstelle enthält. Wenn dieses Feld angegeben ist, muss der Git-Server ein von dieser Zertifizierungsstelle ausgestelltes Zertifikat verwenden. Das CA-Zertifikat muss im Secret unter einem Schlüssel mit dem Namen „cert“ gespeichert sein.
spec.override.resources Die Liste der Containerressourcenanfragen und Überschreibungen von Limits. Optional.
Jedes Element in der Liste enthält drei Felder:
  • containerName: Dieses Feld kann entweder git-sync, oci-sync, hydration-controller oder reconciler sein.
  • cpuRequest (optional)
  • cpuLimit (optional)
  • memoryRequest (optional)
  • memoryLimit (optional)

Wenn für eine Ressourcenanfrage oder ein Limit kein Überschreibungswert angegeben ist, wird der Standardressourcenwert für die Anfrage oder das Limit verwendet.
spec.override.gitSyncDepth Mit gitSyncDepth können Sie die Anzahl der abzurufenden Git-Commits überschreiben.
Darf nicht kleiner als 0 sein.
Config Sync führt einen vollständigen Klon aus, wenn dieses Feld 0 ist, und einen flachen Klon, wenn dieses Feld größer als 0 ist.
Wenn dieses Feld nicht angegeben ist, wird es von Config Sync automatisch konfiguriert.
spec.override.statusMode Mit statusMode können Sie die Erfassung des Status auf Ressourcenebene aktivieren oder deaktivieren.
Der Standardwert ist enabled.
Wenn Sie die Erfassung des Status auf Ressourcenebene deaktivieren möchten, legen Sie dieses Feld auf disabled fest.
spec.override.reconcileTimeout Mit reconcileTimeout können Sie den Grenzwert überschreiben, der angibt, wie lange auf den Abgleich von Ressourcen in einer Anwendungsgruppe gewartet werden soll, bevor sie aufgegeben werden. Alle Ressourcen in einem Commit können sich basierend auf den Abhängigkeiten in mehreren Anwendungsgruppen befinden.
Das Standardzeitlimit ist 5m.
Verwenden Sie einen String, um diesen Feldwert anzugeben, z. B. 30s oder 5m.
spec.override.enableShellInRendering enableShellInRendering gibt an, ob der Shell-Zugriff im Renderingprozess aktiviert oder deaktiviert ist. Kustomize-Remotebases erfordern Shell-Zugriff. Wenn Sie dieses Feld auf true setzen, wird der Shell-Zugriff im Renderingprozess aktiviert und das Abrufen von Remotebasen aus öffentlichen Repositories wird unterstützt.
Der Standardwert ist false.

Beispiel-CRs

In den folgenden Abschnitten finden Sie Beispiele für RootSync- und Reposync-CRs.

RootSync-CR

Das folgende Beispiel zeigt ein RootSync-Objekt.

# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    branch: init
    dir: config-sync-quickstart/multirepo/root
    auth: none
    period: 30s

RepoSync-CR

Das folgende Beispiel zeigt ein RepoSync-Objekt.

# repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: repo-sync
  namespace: gamestore
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    branch: init
    dir: config-sync-quickstart/multirepo/root
    auth: none
    period: 30s

Nächste Schritte