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:
Nach der Erstellung steuert der Abgleichsmanager den Lebenszyklus des Root-Abgleichers und die einzelnen Namespace-Abgleichsprozesse:
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.
|
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.noSSLVerify 1 |
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.name 1 |
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 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: resources: - containerName: helm-sync cpuRequest: "200m" |
spec.helm.period |
In Config Sync Version 1.16.1 und höher ist 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.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 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- 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 Jeder Eintrag in der Liste muss Folgendes enthalten:
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.resources 1 |
Die Liste der Überschreibungen für Containerressourcen und -limits. Optional. Jedes Element in der Liste enthält drei Felder:
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:
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.gitSyncDepth 1 |
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.statusMode 1 |
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.reconcileTimeout 1 |
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.apiServerTimeout 1 | 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.enableShellInRendering 1 |
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:
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
- Weitere Informationen zur Überwachung Ihrer RootSync- und RepoSync-Objekte.