nomos-Befehlszeilentool verwenden
Das nomos
-Befehlszeilentool ist ein optionales Tool für Config Sync, mit dem Sie den Status von Config Sync und den Synchronisierungsstatus Ihrer Source of Truth abrufen können. Das nomos
-Tool bietet folgende Befehle:
Befehl | Nutzung |
---|---|
nomos status |
Config Sync-Status prüfen |
nomos vet |
Die „Source of Truth“ auf Fehler prüfen |
nomos hydrate |
Alle Konfigurationen in der „Source of Truth“ ansehen |
nomos bugreport |
Fehlerbericht erstellen |
nomos migrate |
Vom ConfigManagement-Objekt zu RootSync migrieren |
nomos init |
Hierarchische „Source of Truth“ initialisieren |
Vorbereitung
Bevor Sie mit dem nomos
-Tool mit einem Cluster interagieren können, muss Config Sync bereits auf dem Zielcluster installiert sein. Außerdem müssen Sie das kubectl
-Befehlszeilentool installieren und konfigurieren.
Wenn Sie mit Google Kubernetes Engine-Clustern interagieren, müssen Sie auch den gke-gcloud-auth-plugin
installieren.
Das nomos
-Tool unterstützt die Vorschau auf und Validierung von Kustomize-Konfigurationen und Helm-Diagrammen. Bevor Sie dieses Feature verwenden können, installieren Sie Kustomize und Helm auf Ihrer lokalen Workstation. Wenn Ihre Source of Truth nur vollständig gerenderte Konfigurationen enthält, sind Kustomize und Helm optional.
Installieren Sie das nomos
-Tool.
Das nomos
-Tool ist eine aus Go-Code kompilierte Binärdatei, die Sie lokal installieren können, z. B. auf einer Workstation oder einem Laptop.
Das nomos
-Tool ist bei der Installation von Config Sync nicht enthalten. Sie können den Befehl nomos
installieren. Installieren Sie dazu die Google Cloud CLI. Wenn Sie Cloud Shell verwenden, ist die Google Cloud CLI vorinstalliert.
Wenn Sie die Google Cloud CLI nicht zur Verfügung haben, empfehlen wir gcloud components install nomos
zur Installation des nomos
-Tools. Wenn Sie das nomos
-Tool mit der Google Cloud CLI installieren, können Sie das nomos
-Tool mithilfe von gcloud components update
auf die neueste Version aktualisieren.
Weitere Informationen zur Installation des nomos
-Tools finden Sie unter Downloads.
Grundlegende Verwendung
Mit dem Argument --help
können Sie die grundlegende Befehlssyntax aufrufen:
nomos --help
Das nomos
-Tool liest aus dem lokalen Klon Ihrer „Source of Truth“. Verwenden Sie das Flag --path
, um die Position der obersten Ebene der „Source of Truth“ anzugeben. Standardmäßig ist --path
auf .
oder das aktuelle Verzeichnis festgelegt. Beispiel:
nomos --path=PATH_TO_SOURCE vet
Config Sync-Status prüfen
Mit dem Befehl nomos status
können Sie den Status von Config Sync in allen registrierten Clustern überwachen. Für jeden Cluster meldet nomos status
den Hash des Commits, der zuletzt auf den Cluster angewendet wurde, sowie alle Fehler, die beim Anwenden der letzten Änderungen aufgetreten sind.
Sie können auch mit nomos status
prüfen, ob die von Config Sync verwalteten Ressourcen bereit sind. nomos status
meldet den Status für jede einzelne Ressource in der Spalte STATUS
des Abschnitts Managed resources
der Ausgabe.
Das folgende Beispiel zeigt einige der verschiedenen Bedingungen, die der Befehl nomos status
melden kann:
nomos status
Beispielausgabe:
MANAGED_CLUSTER_1
--------------------
<root> git@github.com:foo-corp/acme@main
SYNCED f52a11e4
Managed resources:
NAMESPACE NAME STATUS
k8snoexternalservices.constraints.gatekeeper.sh/no-internet-services Current
namespace/hello Current
MANAGED_CLUSTER_2
--------------------
<root> git@github.com:foo-corp/acme@main
PENDING 9edf8444
MANAGED_CLUSTER_3
--------------------
<root> git@github.com:foo-corp/acme@main
ERROR f52a11e4
Error: KNV1021: No CustomResourceDefinition is defined for the resource in the cluster.
MANGED_CLUSTER_4
--------------------
NOT INSTALLED
MANAGED_CLUSTER_5
--------------------
<root> git@github.com:foo-corp/acme/admin@main
SYNCED f52a11e4
Managed resources:
NAMESPACE NAME STATUS
namespace/gamestore Current
namespace/monitoring Current
gamestore reposync.configsync.gke.io/repo-sync Current
gamestore rolebinding.rbac.authorization.k8s.io/gamestore-admin Current
gamestore rolebinding.rbac.authorization.k8s.io/gamestore-webstore-admin Current
monitoring deployment.apps/prometheus-operator Current
monitoring prometheus.monitoring.coreos.com/acm Current
monitoring service/prometheus-acm Current
monitoring service/prometheus-operator Current
monitoring serviceaccount/prometheus-acm Current
monitoring serviceaccount/prometheus-operator Current
monitoring servicemonitor.monitoring.coreos.com/acm-service Current
--------------------
bookstore git@github.com:foo-corp/acme/bookstore@v1
SYNCED 34d1a8c8
Managed resources:
NAMESPACE NAME STATUS
gamestore configmap/store-inventory Current
gamestore webstore.marketplace.com/gameplace Current
In dieser Ausgabe gilt:
MANAGED_CLUSTER_1
hat die letzte Änderung an der „Source of Truth“ synchronisiert und alle verwalteten Ressourcen haben den StatusCurrent
. Der StatusCurrent
bedeutet, dass der Status der Ressource mit dem gewünschten Status übereinstimmt.MANAGED_CLUSTER_2
wird noch synchronisiert.MANAGED_CLUSTER_3
hat einen Fehler, der verhindert hat, dass die Änderung angewendet wurde. In diesem Beispiel weistMANAGED_CLUSTER_3
den Fehler KNV1021 auf, da eine CRD (CustomResourceDefinition) fehlt, die auf den anderen Clustern installiert ist.- In
MANAGED_CLUSTER_4
ist Config Sync nicht installiert. MANAGED_CLUSTER_5
synchronisiert gerade aus zwei Git-Repositories. Die<root>
-Datenquelle gehört dem Clusteradministrator und die Datenquellebookstore
gehört möglicherweise einem Anwendungsentwicklungsteam.
Status verwalteter Ressourcen
Der Status Ihrer verwalteten Ressourcen kann einer der folgenden Werte sein:
InProgress
: Der tatsächliche Status der Ressource hat noch nicht den Status erreicht, den Sie im Ressourcenmanifest angegeben haben. Dies bedeutet, dass der Ressourcenabgleich noch nicht abgeschlossen ist. Neu erstellte Ressourcen beginnen in der Regel mit diesem Status, einige Ressourcen wie ConfigMaps haben jedoch sofort den StatusCurrent
.Failed
: Bei dem Prozess, bei dem der tatsächliche Status mit dem gewünschten Status abgeglichen wird, ist ein Fehler aufgetreten oder er ist nicht ausreichend vorangeschritten.Current
: Der tatsächliche Status der Ressource entspricht dem gewünschten Status. Der Abgleichsprozess gilt so lange als abgeschlossen, bis Änderungen am gewünschten oder tatsächlichen Status vorgenommen werden.Terminating
: Die Ressource wird gerade gelöscht.NotFound
: Die Ressource ist nicht im Cluster vorhanden.Unknown
: Config Sync kann den Status der Ressource nicht ermitteln.
Wenn Sie das Anzeigen des Status der Ressourcenebene deaktivieren möchten, fügen Sie dem Befehl nomos status
das Flag --resources=false
hinzu.
Letzte synchronisierte Commits
Mit dem Befehl nomos status
wird in der Ausgabe unter status.sync.commit
der zuletzt auf den Cluster angewendete Commit-Hash angezeigt. Fragen Sie das RootSync
oder RepoSync
-Objekt ab und sehen Sie sich das Feld status.sync
an, um diesen Wert zu erhalten:
Führen Sie beispielsweise den folgenden Befehl aus, um ein RootSync
-Objekt abzufragen:
kubectl get rootsyncs.configsync.gke.io -n config-management-system root-sync -o yaml
Beispielausgabe:
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
status:
sync:
commit: f1739af550912034139aca51e382dc50c4036ae0
lastUpdate: "2021-04-20T00:25:01Z"
Führen Sie den folgenden Befehl aus, um ein RepoSync
-Objekt abzufragen:
kubectl get reposync.configsync.gke.io -n NAMESPACE repo-sync -o yaml
Ersetzen Sie NAMESPACE
durch den Namespace, in dem Sie die Namespace-Source of Truth erstellt haben.
Beispielausgabe:
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
status:
sync:
commit: ed95b50dd918cf65d8908f7561cb8d8d1f179c2f
lastUpdate: "2021-04-20T00:25:20Z"
Dieser Commit stellt den letzten Commit für den Cluster dar. Allerdings ist nicht jede Ressource im Cluster von jedem Commit betroffen. Fragen Sie die spezifische Ressource ab und sehen Sie sich metadata.annotations.configmanagement.gke.io/token
an, um den neuesten Commit für eine spezifische Ressource aufzurufen. Beispiel:
kubectl get clusterroles CLUSTER_ROLE_NAME -o yaml
Ersetzen Sie CLUSTER_ROLE_NAME
durch den Namen der Clusterrolle, die Sie abfragen möchten.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
annotations:
configmanagement.gke.io/token: ed95b50dd918cf65d8908f7561cb8d8d1f179c2f
nomos-Status-Flags
Fügen Sie die folgenden Flags hinzu, um den Befehl nomos status
anzupassen:
Flag | Beschreibung |
---|---|
--contexts |
Akzeptiert eine durch Kommas getrennte Liste von Kontexten, die in Multi-Cluster-Befehlen verwendet werden sollen. Die Standardeinstellung ist alle Kontexte. Verwenden Sie "" für keine Kontexte. |
-h oder --help |
Hilfe zum Befehl nomos status . |
--namespace |
Akzeptiert einen String. Verwenden Sie das Flag namespace , um den Befehl auf eine bestimmte Namespace-Source of Truth zu beschränken. Lassen Sie die Richtlinie nicht konfiguriert, um alle Quellen abzurufen. Dieses Flag ist nur verfügbar, wenn Sie die Synchronisierung aus mehr als einer „Source of Truth“ aktiviert haben. |
--poll |
Mit dem Flag poll können Sie nomos status kontinuierlich ausführen und die Statustabelle in regelmäßigen Abständen noch einmal ausgeben lassen. Beispiel: 3s . Dieses Flag nicht festlegen, um nomos status einmal auszuführen. |
--resources |
Akzeptiert true oder false . Bei true zeigt nomos status bei der Synchronisierung von mehr als einer „Source of Truth“ den Status auf Ressourcenebene für die Root- oder Namespace-Source of Truth an.
Der Standardwert ist true . |
--timeout |
Zeitlimit für das Herstellen einer Verbindung zu jedem Cluster. Der Standardwert ist 3s . |
--name |
Akzeptiert einen String. Verwenden Sie dieses Flag, um Root- und Repository-Synchronisierung mit dem angegebenen Namen zu filtern. Dieses Flag kann zusammen mit dem Flag namespace verwendet werden. |
Erforderliche Berechtigungen
Wenn Sie Projektinhaber sind, haben Sie die RBAC-Rolle cluster-admin
und können den Befehl nomos status
für alle Cluster in Ihrem Projekt verwenden, ohne weitere Berechtigungen hinzuzufügen. Wenn Sie die Rolle cluster-admin
nicht haben, können Sie nomos status
verwenden. Erstellen Sie dazu die folgende ClusterRole:
Erstellen Sie eine Datei namens
nomos-status-reader.yaml
und kopieren Sie die folgende ClusterRole hinein: Welche Regeln Sie benötigen, hängt davon ab, ob Sie RootSync- und RepoSync-Objekte verwenden.RootSync- und RepoSync-Objekte verwenden
# nomos-status-reader.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: nomos-status-reader rules: - apiGroups: ["configsync.gke.io"] resources: ["reposyncs", "rootsyncs"] verbs: ["get"] - nonResourceURLs: ["/"] verbs: ["get"]
Keine RootSync- und RepoSync-Objekte verwenden
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: nomos-status-reader rules: - apiGroups: ["configmanagement.gke.io"] resources: ["configmanagements", "repos"] verbs: ["get", "list"] - nonResourceURLs: ["/"] verbs: ["get"]
Wenden Sie die Datei
nomos-status-reader.yaml
an:kubectl apply -f nomos-status-reader.yaml
Die „Source of Truth“ auf Fehler prüfen
Bevor Sie eine Konfiguration als „Source of Truth“ per Commit speichern, prüfen Sie mit dem Befehl nomos vet
die Syntax und Gültigkeit der Konfigurationen in der „Source of Truth“:
nomos vet
Wenn Syntaxfehler gefunden werden, wird der Befehl nomos vet
mit einem Status ungleich Null beendet und Fehlermeldungen werden in STDERR
protokolliert.
Nomos vet-Flags
Fügen Sie die folgenden Flags hinzu, um den Befehl nomos vet
anzupassen:
Flag | Beschreibung |
---|---|
--clusters |
Akzeptiert eine durch Kommas getrennte Liste von Clusternamen zur Verwendung in Multi-Cluster-Befehlen. Standardmäßig sind alle Cluster eingestellt. Verwenden Sie "" , wenn keine Cluster eingestellt sein sollen. |
-h oder --help |
Hilfe zum Befehl nomos vet . |
--namespace |
Akzeptiert einen String. Wenn festgelegt, wird die „Source of Truth“ als Namespace-Source of Truth mit dem angegebenen Namen validiert. Legt automatisch --source-format=unstructured fest. |
--no-api-server-check |
Akzeptiert einen booleschen Wert. Bei true wird die Kommunikation mit dem API-Server für die Erkennung deaktiviert. Weitere Informationen zu diesem Flag finden Sie im Abschnitt Serverseitige Validierung. |
--path |
Akzeptiert einen String. Der Pfad zum Stammverzeichnis Ihrer Config Sync-Datenquelle. Die Standardeinstellung ist „. “. |
--source-format |
Akzeptiert hierarchy oder unstructured . Wenn hierarchy oder nicht festgelegt, wird die „Source of Truth“ als hierarchische „Source of Truth“ validiert. Bei unstructured wird die „Source of Truth“ als unstrukturierte Datenquelle validiert.
Dieses Flag ist erforderlich, wenn Sie eine unstrukturierte „Source of Truth“ verwenden. |
--keep-output |
Akzeptiert einen booleschen Wert. Bei true wird die gerenderte Ausgabe an dem Ort gespeichert, den Sie mit dem Flag --output angeben können. |
--output |
Akzeptiert einen String. Der Pfad zur gerenderten Ausgabe. Die Standardeinstellung ist das Verzeichnis compiled . Wenn --keep-output auf false gesetzt ist, wird dieses Flag ignoriert. |
--format |
Akzeptiert yaml oder json . Das Format der Ausgabe. Der Standardwert ist yaml . |
Serverseitige Validierung
Wenn der Befehl nomos vet
nicht feststellen kann, ob der Typ einen Namespace hat, stellt das nomos
-Tool eine Verbindung zum API-Server her. Da das nomos
-Tool die Kubernetes-Kerntypen und Config Sync-CRDs standardmäßig versteht, wird nur dann versucht, eine Verbindung zum API-Server herzustellen, wenn Antwortvorlagen vorhanden sind, die keine entsprechende deklarierte CRD haben. In diesem Fall gibt der Befehl nomos
vet
error KNV1021 zurück, wenn auf dem API-Server nicht die CRD angewendet wurde. Übergeben Sie das Flag --no-api-
server-check
, um diese Prüfung zu deaktivieren und Fehler aufgrund fehlender CRDs zu unterdrücken.
Caching von API-Servermetadaten
Anstatt API-Serverprüfungen zu unterdrücken, können Sie die Daten auf dem API-Server für den Befehl nomos vet
im Cache speichern. Wenn Sie Ihre api-resources
im Cache speichern möchten, führen Sie folgende Schritte aus:
- Stellen Sie eine Verbindung zu einem Cluster her, der alle CRDs enthält, die Sie als „Source of Truth“ benötigen. Für den Cluster muss Config Sync nicht aktiviert werden.
- Rufen Sie „policyDir“ mit Ihrer „Source of Truth“ auf. Dies ist dasselbe Verzeichnis, das in Ihrer ConfigManagement- oder RootSync-Ressource angegeben ist.
- Führen Sie den folgenden Befehl aus:
kubectl api-resources > api-resources.txt
. Dieser Befehl erstellt eine Datei mit dem Namen „api-resources.txt”, die die genaue Ausgabe von kubectl api-resources enthält.
Ab sofort werden diese Typdefinitionen bei Ausführungen von nomos vet
innerhalb der „Source of Truth“ erkannt. Wenn die Datei api-resources.txt
entfernt oder umbenannt wird, kann nomos vet
die Datei nicht finden. nomos vet
versucht weiterhin, eine Verbindung zum Cluster herzustellen, wenn es Manifeste für Typen findet, die nicht in api-resources.txt deklariert sind (es sei denn, --no-api-server-check
wird übergeben).
Die Datei api-resources.txt
wirkt sich nur auf die Funktionsweise des nomos
-Tools aus. Sie ändert das Verhalten von Config Sync in keiner Weise.
Die Datei api-resources.txt kann zusätzliche Einträge für Typen enthalten, die nicht an der zu validierenden „Source of Truth“ liegen. nomos vet
importiert die Definitionen, hat aber keine Auswirkungen.
api-resources.txt aktualisieren
Nachdem Sie alle gewünschten CRDs im Cluster abgelegt haben, führen Sie den folgenden Befehl aus:
kubectl api-resources > api-resources.txt
Spaltentitel in "api-resources" stimmen nicht überein
Kubernetes Version 1.20 und höher ersetzt die Spalte namens APIGROUP
durch APIVERSION
. Bei Nomos-Version 1.16.1 und niedriger führt die Verwendung von api-resources.txt
zu einem Fehler:
[1] KNV1064: unable to find APIGROUP column. Re-run "kubectl api-resources > api-resources.txt" in the root policy directory
Sie können dieses Problem beheben, indem Sie APIVERSION
in api-resources.txt
manuell durch APIGROUP
ersetzen.
Automatische Überprüfung auf Syntaxfehler beim Commit
Wenn Sie einen Commit für eine Datei mit JSON- oder YAML-Fehlern durchführen, übernimmt Config Sync die Änderung nicht. Mit clientseitigen oder serverseitigen Hooks lässt sich jedoch verhindern, dass solche Fehler in die Source of Truth gelangen.
nomos vet
in einem Pre-Commit-Hook verwenden
Sie können einen Pre-Commit-Hook konfigurieren, der den Befehl nomos vet
ausführt, um nach Syntaxfehlern zu suchen, wenn Sie eine Änderung am lokalen Git-Klon Ihres Repositorys festschreiben.
Wenn ein Pre-Commit-Hook mit einem Status ungleich Null beendet wird, schlägt der git commit
-Vorgang fehl.
Wenn Sie den Befehl nomos vet
als Pre-Commit-Hook ausführen möchten, bearbeiten Sie die Datei .git/hooks/pre-commit
in Ihrer „Source of Truth“ (beachten Sie, dass .git
mit einem .
-Zeichen beginnt). Möglicherweise müssen Sie die Datei manuell erstellen. Fügen Sie den Befehl nomos vet
zu einer neuen Zeile im Skript hinzu. Das Argument --path
ist optional.
nomos vet --path=/path/to/repo
Achten Sie darauf, dass die Datei pre-commit
ausführbar ist:
chmod +x .git/hooks/pre-commit
Wenn Sie jetzt einen git commit
-Befehl im Klon der Source of Truth ausführen, wird nomos vet
automatisch ausgeführt.
Der Inhalt des Verzeichnisses .git/
wird nicht von der „Source of Truth“ selbst erfasst und kann nicht am selben Ort als „Source of Truth“ festgeschrieben werden. Sie können in der Source of Truth ein Verzeichnis für Git-Hooks erstellen. Personen, die diese verwenden, können die Hooks an die entsprechende Stelle in ihrem lokalen Klon kopieren.
nomos vet
in einem serverseitigen Hook verwenden
Git bietet einen Mechanismus, um während eines git push
-Vorgangs Prüfungen auf dem Server auszuführen, statt auf dem Client. Wenn die Prüfung fehlschlägt, schlägt auch git push
fehl. Diese serverseitigen Hooks können vom Client nicht umgangen werden. Die Methode zum Konfigurieren serverseitiger Hooks hängt davon ab, wie Ihr Git-Server gehostet wird. Weitere Informationen finden Sie unter einem der folgenden Links oder in der Dokumentation zu Ihrem Git-Hostingdienst.
Alle Konfigurationen in der „Source of Truth“ ansehen
Mit dem Befehl nomos hydrate
können Sie den kombinierten Inhalt der „Source of Truth“ für jeden registrierten Cluster aufrufen.
Wenn Sie nomos hydrate
ohne Optionen ausführen, wird im aktuellen Arbeitsverzeichnis ein Verzeichnis compiled/
erstellt. Innerhalb dieses Verzeichnisses wird für jeden registrierten Cluster ein Unterverzeichnis mit den vollständig aufgelösten Konfigurationen erstellt, die der Operator auf den Cluster anwenden würde.
Mit diesem Befehl kann unter Verwendung des Inhalts im Verzeichnis compiled/
auch eine hierarchische Source of Truth in eine oder mehrere unstrukturierte Quellen der Wahrheit konvertiert werden.
Flags für „nomos hydrate“
Fügen Sie die folgenden Flags hinzu, um den Befehl nomos hydrate
anzupassen:
Flag | Beschreibung |
---|---|
--clusters |
Akzeptiert eine durch Kommas getrennte Liste von Clusternamen. Mit diesem Flag können Sie die Ausgabe auf einen einzelnen Cluster oder eine Liste von Clustern beschränken. Standardmäßig sind alle Cluster eingestellt. Verwenden Sie "" , wenn keine Cluster eingestellt sein sollen. |
--flat |
Falls aktiviert, wird die gesamte Ausgabe in einer einzelnen Datei ausgegeben. Mit diesem Flag können Sie das Verhalten von nomos view emulieren. |
-h oder --help |
Hilfe zum Befehl nomos hydrate . |
--format |
Akzeptiert yaml oder json . Das Format der Ausgabe. Der Standardwert ist yaml . |
--no-api-server-check |
Akzeptiert einen booleschen Wert. Bei true wird die Kommunikation mit dem API-Server für die Erkennung deaktiviert. Weitere Informationen zu diesem Flag finden Sie im Abschnitt Serverseitige Validierung. |
--output |
Akzeptiert einen String. Der Speicherort, in den die hydrierte Konfiguration geschrieben werden soll. Der Standardwert ist das Verzeichnis compiled .
Wenn --flat nicht aktiviert ist, wird jedes Ressourcenmanifest als separate Datei geschrieben.
Wenn --flat aktiviert ist, wird in eine einzelne Datei geschrieben, die alle Ressourcenmanifeste enthält.
|
--path |
Akzeptiert einen String. Der Pfad zum Stammverzeichnis Ihrer Config Sync-Datenquelle. Die Standardeinstellung ist „. “. |
--source-format |
Akzeptiert hierarchy oder unstructured . Wenn hierarchy oder nicht festgelegt, wird die „Source of Truth“ als hierarchische „Source of Truth“ validiert. Bei unstructured wird die „Source of Truth“ als unstrukturierte Datenquelle validiert.
Dieses Flag ist erforderlich, wenn Sie eine unstrukturierte „Source of Truth“ verwenden. |
Fehlerbericht erstellen
Wenn Sie ein Problem mit Config Sync haben, für das Sie die Unterstützung des Google Cloud-Supports benötigen, können Sie mit dem Befehl nomos bugreport
wertvolle Debugging-Informationen für den Support bereitstellen. Sie können diesen Befehl für eine Single Source of Truth und mehrere Repositories verwenden.
nomos bugreport
Dieser Befehl generiert eine zeitgestempelte Zip-Datei mit Informationen zum Kubernetes-Cluster, der in Ihrem kubectl
-Kontext festgelegt ist. Die Datei enthält auch Logs aus den Config Sync-Pods. Sie enthält keine Informationen aus den mit Config Sync synchronisierten Ressourcen. Weitere Informationen zum Inhalt der ZIP-Datei finden Sie in der Referenz zum nomos-Fehlerbericht.
Beschränkungen
Der Befehl nomos bugreport
schlägt fehl und erstellt eine unvollständige ZIP-Datei, wenn eine einzelne Datei 1 GiB überschreitet. Dies geschieht häufig durch große Protokolldateien.
In der folgenden Tabelle finden Sie die häufigsten Ursachen für große Logdateien und wie Sie diese beheben können:
Ursache | Empfohlene Maßnahmen |
---|---|
Höhere Logausführlichkeit | Logausführlichkeit mit log level overrides reduzieren |
Sehr große Objekte | Verwaltung des großen Objekts aufheben oder Größe verringern |
Viele Objekte | Repository in mehrere Repositories aufteilen |
Controller-Kämpfe | Klappe die Kämpfe |
Von einem ConfigManagement-Objekt zu einem RootSync-Objekt migrieren
Sie können den Befehl nomos migrate
ausführen, um von Ihrem ConfigManagement-Objekt zu einem RootSync-Objekt zu migrieren, um die APIs RootSync
und RepoSync
zu aktivieren. Der Befehl ist ab nomos
-Toolversion 1.10.0 verfügbar.
nomos migrate
unterstützt den Probelauf für die Vorschau des Migrationsprozesses.
nomos migrate
ändert das ConfigManagement-Objekt direkt im Cluster.
Damit über nomos migrate
vorgenommene Änderungen nicht rückgängig gemacht werden, darf das ConfigManagement-Objekt nicht in die „Source of Truth“ eingecheckt sein.
nomos migrate --contexts=KUBECONFIG_CONTEXTS --dry-run
Wenn das Probelaufergebnis gut aussieht, können Sie Ihr ConfigManagement-Objekt mit nomos migrate
migrieren:
nomos migrate --contexts=KUBECONFIG_CONTEXTS
Die Ausgabe sieht in etwa so aus:
--------------------
Enabling the multi-repo mode on cluster "my_managed_cluster-1" ...
- A RootSync object is generated and saved in "/tmp/nomos-migrate/my_managed_cluster-1/root-sync.yaml".
- The original ConfigManagement object is saved in "/tmp/nomos-migrate/my_managed_cluster-1/cm-original.yaml".
- The ConfigManagement object is updated and saved in "/tmp/nomos-migrate/my_managed_cluster-1/cm-multi.yaml".
- Resources for the multi-repo mode have been saved in a temp folder. If the migration process is terminated, it can be recovered manually by running the following commands:
kubectl apply -f /tmp/nomos-migrate/my_managed_cluster-1/cm-multi.yaml && \
kubectl wait --for condition=established crd rootsyncs.configsync.gke.io && \
kubectl apply -f /tmp/nomos-migrate/my_managed_cluster-1/root-sync.yaml.
- Updating the ConfigManagement object ....
- Waiting for the RootSync CRD to be established ....
- The RootSync CRD has been established.
- Creating the RootSync object ....
- Waiting for the reconciler-manager Pod to be ready ....
- Haven't detected running Pods with the label selector "app=reconciler-manager".
- Haven't detected running Pods with the label selector "app=reconciler-manager".
- Haven't detected running Pods with the label selector "app=reconciler-manager".
- The reconciler-manager Pod is running.
- Waiting for the root-reconciler Pod to be ready ....
- Haven't detected running Pods with the label selector "configsync.gke.io/reconciler=root-reconciler".
- Haven't detected running Pods with the label selector "configsync.gke.io/reconciler=root-reconciler".
- Haven't detected running Pods with the label selector "configsync.gke.io/reconciler=root-reconciler".
- The root-reconciler Pod is running.
- The migration process is done. Please check the sync status with `nomos status`.
Finished migration on all the contexts. Please check the sync status with `nomos status`.
Rollback zur vorherigen Konfiguration
Wenn Sie nach der Migration mit nomos migrate
ein Rollback machen müssen, wenden Sie das ursprüngliche ConfigManagement-Objekt an. nomos migrate
speichert das ursprüngliche ConfigManagement-Objekt in einer Datei und gibt den Namen im Terminal aus.
Der Name der Datei hat das Format /tmp/nomos-migrate/CURRENT_CONTEXT/cm-original.yaml
.
Wenn Sie ein Rollback zur vorherigen Konfiguration machen möchten, kopieren Sie den Dateipfad für cm-original.yaml
und wenden die Datei auf Ihren Cluster an:
kubectl apply -f CM_ORIGINAL_PATH
Flags für „nomos migrate“
Fügen Sie die folgenden Flags hinzu, um den Befehl nomos migrate
anzupassen:
Flag | Beschreibung |
---|---|
--connect-timeout |
Akzeptiert eine Dauer. Zeitlimit für das Herstellen einer Verbindung zu jedem Cluster.
Standardeinstellung ist 3s . |
--contexts |
Akzeptiert eine durch Kommas getrennte Liste von Kontexten, die in Multi-Cluster-Befehlen verwendet werden können. Die Standardeinstellung ist der aktuelle Kontext. Verwenden Sie "all" für alle Kontexte. |
--dry-run |
Akzeptiert einen booleschen Wert. Bei true wird nur die Migrationsausgabe angezeigt. |
-h oder --help |
Hilfe zum Befehl nomos migrate . |
--wait-timeout |
Akzeptiert eine Dauer. Zeitlimit für die Wartezeit, bis die Bedingungen von Kubernetes-Ressourcen erfüllt sind. Die Standardeinstellung ist 10m . |
Hierarchische „Source of Truth“ initialisieren
Sie können Ihre Informationsquelle beliebig organisieren, wenn Sie eine unstrukturierte Source of Truth verwenden.
Wenn Sie eine hierarchische Source of Truth verwenden, müssen Sie den Befehl nomos init
ausführen, um ein hierarchisches Verzeichnis zu initialisieren:
nomos init
Dadurch wird die grundlegende Verzeichnisstruktur einer hierarchischen Source of Truth erstellt, einschließlich der Verzeichnisse system/
, cluster/
und namespaces/
.
Flags für „nomos init“
Fügen Sie die folgenden Flags hinzu, um nomos init
anzupassen:
Flag | Beschreibung |
---|---|
--force |
In Verzeichnis schreiben, auch wenn es nicht leer ist, wodurch in Konflikt stehende Dateien überschrieben werden |
-h oder --help |
Hilfe zum Befehl nomos init . |
--path |
Akzeptiert einen String. Das Stammverzeichnis, das Sie als „Source of Truth“ verwenden möchten. Der Standardwert ist "." . |
Fehlerbehebung
Unter Linux wird möglicherweise der folgende Fehler angezeigt, wenn ein nomos
-Befehl ausgeführt wird:
failed to create client configs: while getting config path: failed to get current user: user: Current not implemented on linux/amd64
Erstellen Sie eine USER
-Umgebungsvariable, um dieses Problem zu beheben:
export USER=$(whoami)