Utiliser l'outil de ligne de commande nomos

L'outil de ligne de commande nomos est un outil facultatif pour Config Sync qui vous permet d'obtenir l'état de Config Sync et l'état de synchronisation de votre source de vérité. L'outil nomos vous fournit les commandes suivantes :

Commande	Usage
nomos status	Vérifier l'état de Config Sync
nomos vet	Rechercher des erreurs dans la source de vérité
nomos hydrate	Afficher toutes les configurations dans la source de vérité
nomos bugreport	Créer un rapport de bug
nomos migrate	Migrer de l'objet ConfigManagement vers RootSync
nomos init	Initialiser une source de vérité hiérarchique

Prérequis

Avant d'utiliser l'outil nomos pour interagir avec un cluster, Config Sync doit déjà être installé sur le cluster cible. Vous devez également installer et configurer l'outil de ligne de commande kubectl. Si vous interagissez avec des clusters Google Kubernetes Engine, veillez également à installer gke-gcloud-auth-plugin.

L'outil nomos permet de prévisualiser et de valider les configurations Kustomize et les charts Helm. Pour pouvoir utiliser cette fonctionnalité, installez Kustomize et Helm sur votre poste de travail local. Si votre source de vérité ne contient que des configurations entièrement générées, Kustomize et Helm sont facultatifs.

Installez l'outil nomos

L'outil nomos est un binaire compilé à partir de code Go. Vous pouvez l'installer localement, par exemple sur un ordinateur portable ou de bureau.

L'outil nomos n'est pas inclus lorsque vous installez Config Sync. Vous pouvez installer l'outil nomos en installant Google Cloud CLI. Si vous utilisez Cloud Shell, Google Cloud CLI est préinstallé.

Si vous ne disposez pas de Google Cloud CLI, nous vous recommandons d'utiliser gcloud components install nomos pour installer l'outil nomos. L'installation de l'outil nomos avec Google Cloud CLI vous permet d'utiliser gcloud components update pour mettre à jour l'outil nomos vers la dernière version.

Pour connaître les autres moyens d'installer l'outil nomos, consultez la section Téléchargements.

Utilisation de base

Pour la syntaxe de commande de base, utilisez l'argument --help :

nomos --help

L'outil nomos lit les données du clone local de votre source de vérité. Utilisez l'indicateur --path pour spécifier l'emplacement du premier niveau de la source de vérité. Par défaut, --path est défini sur ., soit le répertoire actuel. Exemple :

nomos --path=PATH_TO_SOURCE vet

Vérifier l'état de Config Sync

Vous pouvez surveiller l'état de Config Sync sur tous les clusters enregistrés à l'aide de la commande nomos status. Pour chaque cluster, nomos status indique le dernier hachage du commit appliqué au cluster et les erreurs qui se sont produites pendant l'application des modifications récentes.

Vous pouvez également utiliser nomos status pour vérifier si les ressources gérées par Config Sync sont prêtes. nomos status indique l'état de chaque ressource individuelle dans la colonne STATUS de la section Managed resources du résultat.

L'exemple suivant montre certaines des différentes conditions que la commande nomos status peut signaler :

nomos status

Exemple de résultat :

MANAGED_CLUSTER_1
  --------------------
  <root>   [e-mail]: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>   [e-mail]:foo-corp/acme@main
  PENDING  9edf8444

MANAGED_CLUSTER_3
  --------------------
  <root>   [e-mail]: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>   [e-mail]: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  [e-mail]:foo-corp/acme/bookstore@v1
  SYNCED     34d1a8c8
  Managed resources:
   NAMESPACE   NAME                                 STATUS
   gamestore   configmap/store-inventory            Current
   gamestore   webstore.marketplace.com/gameplace   Current

Dans ce résultat :

• MANAGED_CLUSTER_1 a synchronisé la dernière modification apportée à la source de vérité, et toutes les ressources gérées ont l'état Current. Un état Current signifie que l'état de la ressource correspond à l'état souhaité.
• MANAGED_CLUSTER_2 est toujours en cours de synchronisation.
• MANAGED_CLUSTER_3 présente une erreur qui a empêché l'application de la modification. Dans cet exemple, MANAGED_CLUSTER_3 comporte l'erreur KNV1021, car il manque un objet CRD (CustomResourceDefinition) que les autres clusters ont installé.
• MANAGED_CLUSTER_4 ne dispose pas de Config Sync installé.
• MANAGED_CLUSTER_5 est synchronisé à partir de deux dépôts Git. La source de vérité <root> appartient à l'administrateur de cluster et la source de vérité bookstore peut appartenir à une équipe de développement d'applications.

États des ressources gérées

L'état de vos ressources gérées peut être l'une des valeurs suivantes :

• InProgress : l'état réel de la ressource n'a pas encore atteint l'état que vous avez spécifié dans le fichier manifeste de la ressource. Cet état signifie que le rapprochement des ressources n'est pas encore terminé. Les ressources nouvellement créées commencent généralement par cet état, même si certaines ressources telles que les ConfigMaps sont immédiatement à l'état Current.

• Failed : le processus de rapprochement de l'état réel avec l'état souhaité a rencontré une erreur ou la progression est insuffisante.

• Current : l'état réel de la ressource correspond à l'état souhaité. Le processus de rapprochement est considéré comme étant terminé tant que des modifications n'ont pas été apportées à l'état souhaité ou réel.

• Terminating : la ressource est en cours de suppression.

• NotFound : la ressource n'existe pas dans le cluster.

• Unknown : Config Sync ne parvient pas à déterminer l'état de la ressource.

Pour désactiver l'affichage de l'état au niveau des ressources, ajoutez --resources=false à la commande nomos status.

À propos du dernier commit synchronisé

La commande nomos status affiche le dernier hachage de commit appliqué au cluster dans sa sortie sous status.sync.commit. Pour obtenir cette valeur, interrogez l'objet RootSync ou RepoSync et examinez le champ status.sync.

Par exemple, pour interroger un objet RootSync, exécutez la commande suivante :

kubectl get rootsyncs.configsync.gke.io -n config-management-system root-sync -o yaml

Exemple de résultat :

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
status:
  sync:
    commit: f1739af550912034139aca51e382dc50c4036ae0
    lastUpdate: "2021-04-20T00:25:01Z"

Pour interroger un objet RepoSync, exécutez la commande suivante :

kubectl get reposync.configsync.gke.io -n NAMESPACE repo-sync -o yaml

Remplacez NAMESPACE par l'espace de noms dans lequel vous avez créé votre source de vérité d'espace de noms.

Exemple de résultat :

apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
status:
  sync:
    commit: ed95b50dd918cf65d8908f7561cb8d8d1f179c2f
    lastUpdate: "2021-04-20T00:25:20Z"

Ce commit représente le dernier commit sur le cluster. Cependant, toutes les ressources du cluster ne sont pas affectées par chaque commit. Pour afficher le commit le plus récent d'une ressource spécifique, interrogez la ressource spécifique et vérifiez metadata.annotations.configmanagement.gke.io/token. Exemple :

kubectl get clusterroles CLUSTER_ROLE_NAME -o yaml

Remplacez CLUSTER_ROLE_NAME par le nom du rôle de cluster que vous souhaitez interroger.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    configmanagement.gke.io/token: ed95b50dd918cf65d8908f7561cb8d8d1f179c2f

Indicateurs d'état nomos

Pour personnaliser la commande nomos status, ajoutez les options suivantes :

Drapeau	Description
--contexts	Accepte une liste de contextes séparés par une virgule à utiliser dans les commandes multicluster. Valeur par défaut pour tous les contextes. Utilisez "" pour aucun contexte.
-h ou --help	Aide pour la commande nomos status.
--namespace	Accepte une chaîne. Utilisez l'indicateur namespace pour limiter la commande à une source de vérité d'espace de noms spécifique. Laissez la valeur non définie pour obtenir toutes les sources. Cette option n'est disponible que si vous avez activé la synchronisation à partir de plusieurs sources de vérité.
--poll	Utilisez l'option poll pour exécuter nomos status en continu et obtenir un tableau d'état actualisé à intervalles réguliers. Par exemple : 3s Laissez cette option non définie pour exécuter nomos status une fois.
--resources	Accepte true ou false. Si la valeur est true, nomos status indique l'état au niveau des ressources de votre source de vérité d'espace de noms ou racine lors de la synchronisation à partir de plusieurs sources de vérité. La valeur par défaut est true.
--timeout	Délai d'expiration de la connexion à chaque cluster. La valeur par défaut est 3s.
--name	Accepte une chaîne. Utilisez cette option pour filtrer la synchronisation racine et du dépôt avec le nom fourni. Cette option peut être utilisée avec l'option namespace.

Autorisations requises

Si vous êtes propriétaire d'un projet, vous disposez du rôle RBAC cluster-admin et vous pouvez utiliser la commande nomos status pour tous les clusters de votre projet sans ajouter d'autorisations. Si vous ne disposez pas du rôle cluster-admin, vous pouvez utiliser nomos status en créant le ClusterRole suivant :

1. Créez un fichier nommé nomos-status-reader.yaml et copiez-y le ClusterRole suivant : Les règles dont vous avez besoin varient selon que vous utilisez des objets RootSync et RepoSync.

   Utiliser des objets RootSync et RepoSync

   # 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"]
   

   Ne pas utiliser les objets RootSync et RepoSync

   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"]
   

2. Appliquez le fichier nomos-status-reader.yaml :

   kubectl apply -f nomos-status-reader.yaml
   

Rechercher les erreurs dans la source de vérité

Avant de procéder au commit d'une configuration vers la source de vérité, utilisez la commande nomos vet pour vérifier la syntaxe et la validité des configurations dans votre source de vérité:

nomos vet

Si des erreurs de syntaxe sont détectées, la commande nomos vet se termine avec un état différent de zéro et consigne des messages d'erreur dans STDERR.

Options nomos vet

Pour personnaliser la commande nomos vet, ajoutez les options suivantes :

Drapeau	Description
--clusters	Accepte une liste de noms de clusters, séparés par des virgules, à utiliser dans les commandes multicluster. Valeur par défaut sur tous les clusters. Utilisez "" pour aucun cluster.
-h ou --help	Aide pour la commande nomos vet.
--namespace	Accepte une chaîne. Si ce champ est défini, il valide la source de vérité en tant que source de vérité d'espace de noms avec le nom fourni. Définit automatiquement --source-format=unstructured.
--no-api-server-check	Accepte une valeur booléenne. Si la valeur est true, désactive la communication avec le serveur d'API pour la découverte. Pour en savoir plus sur cet indicateur, consultez la section Validation côté serveur.
--path	Accepte une chaîne. Chemin d'accès au répertoire racine de votre source de vérité Config Sync. La valeur par défaut est ".".
--source-format	Accepte hierarchy ou unstructured. Si la valeur est hierarchy ou n'est pas définie, valide la source de vérité en tant que source de vérité hiérarchique. Si la valeur est unstructured, valide la source de vérité en tant que source de vérité non structurée. Cette option est obligatoire si vous utilisez une source de vérité non structurée.
--keep-output	Accepte une valeur booléenne. Si la valeur est true, le résultat de rendu est enregistré à l'emplacement que vous pouvez spécifier avec l'option --output.
--output	Accepte une chaîne. Chemin d'accès au résultat de rendu. Il s'agit par défaut du répertoire compiled. Si --keep-output est défini sur false, cette option est ignorée.
--format	Accepte yaml ou json. Format du résultat. La valeur par défaut est yaml.

Validation côté serveur

Si la commande nomos vet ne parvient pas à déterminer si le type est associé à un espace de noms, l'outil nomos se connecte au serveur d'API. Étant donné que l'outil nomos comprend par défaut les types Kubernetes de base et les objets CRD Config Sync, il ne tente de se connecter au serveur d'API que s'il existe des RS sans objet CRD déclaré correspondant. Dans ce cas, si le serveur d'API n'a pas l'objet CRD appliqué, la commande nomos vet renvoie l'erreur KNV1021. Pour désactiver cette vérification et supprimer les erreurs liées à des objets CRD manquants, transmettez l'option --no-api- server-check.

Mettre en cache des métadonnées du serveur d'API

Au lieu de supprimer les vérifications du serveur d'API, vous pouvez mettre en cache les données du serveur d'API pour la commande nomos vet. Pour mettre en cache votre api-resources, procédez comme suit :

1. Connectez-vous à un cluster contenant tous les CRD dont vous avez besoin pour votre source de vérité. Config Sync ne doit pas être activé sur le cluster.
2. Accédez au policyDir de votre source de vérité. Il s'agit du même répertoire spécifié dans votre ressource ConfigManagement ou RootSync.
3. Exécutez la commande suivante : kubectl api-resources > api-resources.txt Cette commande crée un fichier nommé api-resources.txt qui contient le résultat exact de kubectl api-resources.

Désormais, les exécutions de nomos vet dans la source de vérité connaissent ces définitions de type. Si le fichier api-resources.txt est supprimé ou renommé, nomos vet ne peut pas trouver le fichier. nomos vet tente tout de même de se connecter au cluster s'il trouve des fichiers manifestes pour des types non déclarés dans api-resources.txt (sauf si --no-api-server-check est transmis).

Le fichier api-resources.txt n'affecte que le fonctionnement de l'outil nomos. Il ne modifie en aucun cas le comportement de Config Sync.

Il peut y avoir des entrées supplémentaires dans le fichier api-resources.txt pour les types qui ne figurent pas dans la source de vérité en cours de validation. nomos vet importe les définitions, mais ne fait rien avec elles.

Attention : Dans une source de vérité, les types personnalisés doivent être soit liés à un espace de noms ou non liés à un espace de noms. La commande nomos vet n'accepte pas les types qui s'appliquent à un espace de noms dans certains clusters et à un cluster dans d'autres.

Mettre à jour api-resources.txt

Après vous être assuré que tous les objets CRD souhaités sont dans le cluster, exécutez la commande suivante :

kubectl api-resources > api-resources.txt

Attention : Évitez de modifier directement api-resources.txt, car il est facile de faire des erreurs de formatage et de provoquer des erreurs.

Erreur de correspondance des titres de colonnes dans api-resources

Kubernetes 1.20 et versions ultérieures remplacent la colonne nommée APIGROUP par APIVERSION. Pour les versions 1.16.1 et antérieures de nomos, l'utilisation de api-resources.txt génère une erreur :

[1] KNV1064: unable to find APIGROUP column. Re-run "kubectl api-resources > api-resources.txt" in the root policy directory

Pour résoudre ce problème, remplacez manuellement APIVERSION dans api-resources.txt par APIGROUP.

Rechercher automatiquement des erreurs de syntaxe lors du commit

Si vous procédez au commit d'un fichier contenant des erreurs JSON ou YAML, Config Sync n'applique pas la modification. Toutefois, vous pouvez protéger la source de données grâce à des hooks côté client ou côté serveur.

Utiliser la commande nomos vet dans un hook de pré-commit

Vous pouvez configurer un hook de pré-commit qui exécute la commande nomos vet pour rechercher les erreurs de syntaxe lorsque vous procédez au commit d'une modification dans le clone Git local de votre dépôt. Si l'exécution d'un hook de pré-commit se termine avec un état différent de zéro, l'opération git commit échoue.

Remarque : Les hooks de pré-commit sont exécutés sur le client, et non sur le serveur. Ils doivent être ajoutés manuellement sur chaque client. L'utilisateur peut les ignorer ou les désactiver à tout moment.

Pour exécuter la commande nomos vet en tant que hook de pré-commit, modifiez le fichier .git/hooks/pre-commit dans votre source de vérité. Notez que le caractère . est placé au début du nom du répertoire .git. Vous devrez peut-être créer le fichier manuellement. Ajoutez la commande nomos vet sur une nouvelle ligne du script. L'argument --path est facultatif.

nomos vet --path=/path/to/repo

Vérifiez que le fichier pre-commit est exécutable :

chmod +x .git/hooks/pre-commit

Désormais, lorsque vous exécutez une commande git commit dans le clone de votre source de vérité, nomos vet s'exécute automatiquement.

Le contenu du répertoire .git/ ne fait pas l'objet d'un suivi par la source de vérité elle-même et ne peut pas être validé vers la source de vérité située dans le même emplacement. Vous pouvez créer un répertoire dans la source de vérité pour les hooks Git, et les utilisateurs de cette source peuvent copier les hooks à l'emplacement approprié dans leur clone local.

Utiliser la commande nomos vet dans un hook côté serveur

Git fournit un mécanisme permettant d'effectuer des vérifications sur le serveur plutôt que sur le client lors d'une opération git push. En cas d'échec de la vérification, l'opération git push échoue également. Ces hooks côté serveur ne peuvent pas être ignorés par le client. La méthode de configuration des hooks côté serveur dépend de la manière dont votre serveur Git est hébergé. Pour en savoir plus, consultez l'un des liens ci-dessous ou la documentation de votre service d'hébergement Git.

• GitHub
• Cloud Source Repositories
• Bitbucket
• GitLab
• Serveur Git auto-hébergé

Afficher toutes les configurations de la source de vérité

Vous pouvez utiliser la commande nomos hydrate pour afficher le contenu combiné de votre source de vérité sur chaque cluster enregistré.

Si vous exécutez nomos hydrate sans aucune option, un répertoire compiled/ est créé dans le répertoire de travail actuel. Dans ce répertoire, un sous-répertoire est créé pour chaque cluster enregistré, avec les configurations entièrement résolues que l'opérateur est censé appliquer au cluster.

Cette commande peut également convertir une source de vérité hiérarchique en une ou plusieurs sources de vérité non structurées, en utilisant le contenu du répertoire compiled/.

Indicateurs nomos hydrate

Pour personnaliser la commande nomos hydrate, ajoutez les options suivantes :

Drapeau	Description
--clusters	Accepte une liste de noms de clusters séparés par une virgule. Utilisez cette option pour limiter le résultat à un seul cluster ou à une liste de clusters. Valeur par défaut sur tous les clusters. Utilisez "" pour aucun cluster.
--flat	Si cette option est activée, imprimez tous les résultats dans un seul fichier. Utilisez cette option si vous souhaitez émuler le comportement de nomos view.
-h ou --help	Aide pour la commande nomos hydrate.
--format	Accepte yaml ou json. Format du résultat. La valeur par défaut est yaml.
--no-api-server-check	Accepte une valeur booléenne. Si la valeur est true, désactive la communication avec le serveur d'API pour la découverte. Pour en savoir plus sur cet indicateur, consultez la section Validation côté serveur.
--output	Accepte une chaîne. Emplacement dans lequel écrire la configuration hydratée. Il s'agit par défaut du répertoire compiled. Si --flat n'est pas activé, écrit chaque fichier manifeste de ressources en tant que fichier séparé. Si --flat est activé, écrit un seul fichier contenant tous les fichiers manifestes des ressources.
--path	Accepte une chaîne. Chemin d'accès au répertoire racine de votre source de vérité Config Sync. La valeur par défaut est ".".
--source-format	Accepte hierarchy ou unstructured. Si la valeur est hierarchy ou n'est pas définie, valide la source de vérité en tant que source de vérité hiérarchique. Si la valeur est unstructured, valide la source de vérité en tant que source de vérité non structurée. Cette option est obligatoire si vous utilisez une source de vérité non structurée.

Créer un rapport de bug

Si vous rencontrez un problème avec Config Sync qui nécessite l'aide de l'assistance Google Cloud, vous pouvez leur fournir des informations de débogage précieuses à l'aide de la commande nomos bugreport. Vous pouvez utiliser cette commande pour une source de vérité unique et plusieurs dépôts.

nomos bugreport

Cette commande génère un fichier ZIP horodaté contenant des informations sur le cluster Kubernetes défini dans votre contexte kubectl. Le fichier contient également des journaux issus des pods Config Sync. Il ne contient pas d'informations provenant des ressources synchronisées avec Config Sync. Pour en savoir plus sur le contenu du fichier ZIP, consultez la documentation de référence sur nomos bugreport.

Limites

La commande nomos bugreport échoue et génère un fichier ZIP incomplet si l'un des fichiers individuels dépasse 1 Gio. Cette situation est souvent due à des fichiers journaux volumineux.

Le tableau suivant répertorie les causes les plus courantes de fichiers journaux volumineux et explique comment les résoudre:

Cause	Action recommandée
Augmentation de la verbosité des journaux	Réduisez la verbosité du journal grâce aux remplacements de niveau de journalisation.
Objets très volumineux	Annuler la gestion de l'objet volumineux ou réduire sa taille
Nombreux objets	Diviser votre dépôt en plusieurs dépôts
Conflits de contrôleurs	Résoudre le conflit

Migrer depuis un objet ConfigManagement vers un objet RootSync

Vous pouvez exécuter la commande nomos migrate pour migrer votre objet ConfigManagement vers un objet RootSync afin d'activer les API RootSync et RepoSync. Cette commande est disponible dans la version 1.10.0 de l'outil nomos et ses versions ultérieures.

nomos migrate est compatible avec la simulation pour la prévisualisation du processus de migration.

nomos migrate modifie directement votre objet ConfigManagement sur le cluster. Pour éviter l'annulation des modifications effectuées via nomos migrate, assurez-vous que l'objet ConfigManagement n'est pas enregistré dans votre source de vérité.

Remarque : La transmission de l'option --contexts spécifie les contextes à migrer. Cela n'est nécessaire que si vous souhaitez migrer des clusters au-delà du contexte actuel.

nomos migrate --contexts=KUBECONFIG_CONTEXTS --dry-run

Si le résultat de la simulation vous semble correct, vous pouvez migrer votre objet ConfigManagement à l'aide de nomos migrate :

nomos migrate --contexts=KUBECONFIG_CONTEXTS

Le résultat ressemble à ce qui suit :

--------------------
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`.

Remarque : nomos migrate enregistre l'objet ConfigManagement d'origine, l'objet ConfigManagement mis à jour et l'objet RootSync converti dans un répertoire temporaire. Si nomos migrate échoue ou s'arrête de manière inattendue, vous pouvez récupérer la migration manuellement en exécutant les commandes fournies dans le résultat nomos migrate.

Procéder au rollback vers la configuration précédente

Si vous devez effectuer un rollback après avoir effectué la migration avec nomos migrate, appliquez l'objet ConfigManagement d'origine. nomos migrate enregistre l'objet ConfigManagement d'origine dans un fichier et imprime le nom sur le terminal. Le nom du fichier est au format /tmp/nomos-migrate/CURRENT_CONTEXT/cm-original.yaml.

Pour revenir à la configuration précédente, copiez le chemin d'accès au fichier pour cm-original.yaml et appliquez le fichier à votre cluster:

kubectl apply -f CM_ORIGINAL_PATH

Indicateurs nomos migrate

Pour personnaliser la commande nomos migrate, ajoutez les options suivantes :

Drapeau	Description
--connect-timeout	Accepte une durée. Délai d'expiration de la connexion à chaque cluster. Valeur par défaut : 3s
--contexts	Accepte une liste de contextes séparés par une virgule à utiliser dans les environnements multicluster. Valeur par défaut : contexte actuel. Utilisez "all" pour tous les contextes.
--dry-run	Accepte une valeur booléenne. Si la valeur est true, affiche uniquement le résultat de la migration.
-h ou --help	Aide pour la commande nomos migrate.
--wait-timeout	Accepte une durée. Délai pour l'attente des conditions des ressources Kubernetes. La valeur par défaut est 10m.

Initialiser une source de vérité hiérarchique

Vous pouvez organiser votre source de vérité arbitrairement si vous utilisez une source de vérité non structurée. Si vous utilisez une source de vérité hiérarchique, vous devez exécuter la commande nomos init pour initialiser un répertoire hiérarchique:

nomos init

Cela crée la structure de répertoires de base d'une source de vérité hiérarchique, y compris les répertoires system/, cluster/ et namespaces/.

Indicateurs nomos init

Pour personnaliser nomos init, ajoutez les options suivantes :

Option	Description
--force	Écrit dans le répertoire même s'il n'est pas vide, écrasant les fichiers en conflit
-h ou --help	Aide pour la commande nomos init.
--path	Accepte une chaîne. Répertoire racine à utiliser pour votre source de vérité. La valeur par défaut est ".".

Dépannage

Sous Linux, l'erreur suivante peut se produire lors de l'exécution d'une commande nomos :

failed to create client configs: while getting config path: failed to get current user: user: Current not implemented on linux/amd64

Pour résoudre ce problème, créez une variable d'environnement USER :

export USER=$(whoami)

Étapes suivantes

• Premiers pas avec Config Sync