Usar la herramienta de línea de comandos nomos

La herramienta de línea de comandos nomos es una herramienta opcional de Config Sync que puedes usar para obtener el estado de Config Sync y el estado de sincronización de tu fuente de información veraz. La herramienta nomos te ofrece los siguientes comandos:

Comando	Uso
nomos status	Comprobar el estado de Config Sync
nomos vet	Comprobar si hay errores en la fuente de información veraz
nomos hydrate	Ver todas las configuraciones en la fuente de información veraz
nomos bugreport	Crear un informe de errores
nomos migrate	Migrar del objeto ConfigManagement a RootSync
nomos init	Inicializar una fuente de información jerárquica

Requisitos previos

Para poder usar la herramienta nomos para interactuar con un clúster, Config Sync ya debe estar instalado en el clúster de destino. También debes instalar y configurar la herramienta de línea de comandos kubectl. Si interactúas con clústeres de Google Kubernetes Engine, asegúrate de instalar también el gke-gcloud-auth-plugin.

La herramienta nomos permite previsualizar y validar configuraciones de Kustomize y charts de Helm. Antes de poder usar esta función, instala Kustomize y Helm en tu estación de trabajo local. Si tu fuente de información solo contiene configuraciones totalmente renderizadas, Kustomize y Helm son opcionales.

Instalar la herramienta nomos

La herramienta nomos es un archivo binario compilado a partir de código Go y puedes instalarlo localmente, por ejemplo, en una estación de trabajo o en un portátil.

La herramienta nomos no se incluye al instalar Config Sync. Puedes instalar la herramienta nomos instalando Google Cloud CLI. Si usas Cloud Shell, Google Cloud CLI viene preinstalada.

Si no tienes la CLI de Google Cloud, te recomendamos que uses gcloud components install nomos para instalar la herramienta nomos. Si instalas la herramienta nomos con la CLI de Google Cloud, podrás usar gcloud components update para actualizar la herramienta nomos a la versión más reciente.

Para obtener información sobre otras formas de instalar la herramienta nomos, consulta la sección Descargas.

Uso básico

Para usar la sintaxis básica de los comandos, utiliza el argumento --help:

nomos --help

La herramienta nomos lee la clonación local de tu fuente de referencia. Usa la marca --path para especificar la ubicación del nivel superior de la fuente de información veraz. De forma predeterminada, --path se define como . o el directorio actual. Por ejemplo:

nomos vet --path=PATH_TO_SOURCE --source-format unstructured

Comprobar el estado de Config Sync

Puedes monitorizar el estado de Config Sync en todos los clústeres registrados con el comando nomos status. En cada clúster, nomos status informa del hash de la confirmación que se aplicó por última vez al clúster y de los errores que se produjeron al intentar aplicar los cambios recientes.

También puedes usar nomos status para comprobar si los recursos gestionados por Config Sync están listos. nomos status informa del estado de cada recurso individual en la columna STATUS de la sección Managed resources del resultado.

En el siguiente ejemplo se muestran algunas de las diferentes condiciones que puede devolver el comando nomos status:

nomos status

Ejemplo:

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

En este resultado:

• MANAGED_CLUSTER_1 ha sincronizado el cambio más reciente con la fuente de referencia y todos los recursos gestionados tienen el estado Current. El estado Current significa que el estado del recurso coincide con el que quieres.
• MANAGED_CLUSTER_2 aún se está sincronizando.
• MANAGED_CLUSTER_3 tiene un error que ha impedido que se aplique el cambio. En este ejemplo, MANAGED_CLUSTER_3 tiene el error KNV1021 porque le falta una CustomResourceDefinition (CRD) que tienen instalados los demás clústeres.
• MANAGED_CLUSTER_4 no tiene instalado Config Sync.
• MANAGED_CLUSTER_5 se está sincronizando desde dos repositorios de Git. La <root>fuente de información veraz pertenece al administrador del clúster y la bookstorefuente de información veraz puede pertenecer a un equipo de desarrollo de aplicaciones.

Estados de los recursos gestionados

El estado de los recursos gestionados puede ser uno de los siguientes valores:

• InProgress: El estado real del recurso aún no ha alcanzado el estado que has especificado en el manifiesto del recurso. Este estado significa que la conciliación de recursos aún no se ha completado. Los recursos recién creados suelen empezar con este estado, aunque algunos recursos, como los ConfigMaps, se Current inmediatamente.

• Failed: Se ha producido un error en el proceso de conciliación del estado real con el estado que quieres o no se ha avanzado lo suficiente.

• Current: El estado real del recurso coincide con el estado que quieres. El proceso de conciliación se considera completado hasta que se produzcan cambios en el estado deseado o en el real.

• Terminating: El recurso se está eliminando.

• NotFound: el recurso no existe en el clúster.

• Unknown: Config Sync no puede determinar el estado del recurso.

Para desactivar la visualización del estado del nivel de recursos, añade --resources=false al comando nomos status.

Información sobre la última confirmación sincronizada

El comando nomos status muestra el hash de la confirmación más reciente que se ha aplicado al clúster en su salida, en status.sync.commit. Para obtener este valor, consulta el objeto RootSync o RepoSync y busca el campo status.sync.

Por ejemplo, para consultar un objeto RootSync, ejecuta el siguiente comando:

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

Ejemplo:

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

Para consultar un objeto RepoSync, ejecuta el siguiente comando:

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

Sustituye NAMESPACE por el espacio de nombres en el que has creado tu fuente de información veraz del espacio de nombres.

Ejemplo:

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

Esta confirmación representa la confirmación más reciente del clúster. Sin embargo, no todos los recursos del clúster se ven afectados por cada confirmación. Para ver la confirmación más reciente de un recurso específico, consulta el recurso en cuestión y busca metadata.annotations.configmanagement.gke.io/token. Por ejemplo:

kubectl get clusterroles CLUSTER_ROLE_NAME -o yaml

Sustituye CLUSTER_ROLE_NAME por el nombre del rol de clúster que quieras consultar.

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

Marcas de estado de nomos

Para personalizar el comando nomos status, añade las siguientes marcas:

Bandera	Descripción
--contexts	Acepta una lista de contextos separados por comas que se usarán en comandos de varios clústeres. De forma predeterminada, se seleccionan todos los contextos. Usa "" si no hay contextos.
-h o --help	Ayuda sobre el comando nomos status.
--name	Acepta una cadena. Usa esta marca para filtrar Root y Repo Sync con el nombre proporcionado. Esta marca se puede usar junto con la marca namespace.
--namespace	Acepta una cadena. Usa la marca namespace para limitar el comando a una fuente de información específica del espacio de nombres. Si no se define, se obtendrán todas las fuentes. Esta marca solo está disponible si has habilitado la sincronización desde más de una fuente de información veraz.
--poll	Usa la marca poll para ejecutar nomos status de forma continua y que vuelva a imprimir la tabla de estado a intervalos regulares. Por ejemplo, 3s. Deja esta marca sin definir para ejecutar nomos status una vez
--resources	Acepta true o false. Si true, nomos status muestra el estado a nivel de recurso de tu fuente de información principal de la raíz o del espacio de nombres al sincronizar desde más de una fuente de información principal. El valor predeterminado es true.
--timeout	Tiempo de espera para conectarse a cada clúster. El valor predeterminado es 3s.

Permisos obligatorios

Si eres el propietario de un proyecto, tienes el rol de cluster-adminRBAC y puedes usar el comando nomos status en cualquier clúster de tu proyecto sin añadir más permisos. Si no tienes el rol cluster-admin, puedes usar nomos status creando el siguiente ClusterRole:

1. Crea un archivo llamado nomos-status-reader.yaml y copia el siguiente ClusterRole en él. Las reglas que necesitas varían en función de si usas objetos RootSync y RepoSync.

   Usar objetos RootSync y 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"]
   

   No usar objetos RootSync y 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. Aplica el archivo nomos-status-reader.yaml:

   kubectl apply -f nomos-status-reader.yaml
   

Comprobar si hay errores en la fuente de información

Antes de confirmar una configuración en la fuente de información veraz, usa el comando nomos vet para comprobar la sintaxis y la validez de las configuraciones de tu fuente de información veraz:

nomos vet --source-format unstructured

Si se encuentran errores de sintaxis, el comando nomos vet se cierra con un estado distinto de cero y registra mensajes de error en STDERR.

nomos vet flags

Para personalizar el comando nomos vet, añade las siguientes marcas:

Bandera	Descripción
--api-server-timeout	Acepta una cadena de duración. Define el tiempo de espera del lado del cliente para comunicarse con el servidor de la API de Kubernetes. El valor predeterminado es 15s.
--clusters	Acepta una lista de nombres de clústeres separados por comas para usarla en comandos de varios clústeres. De forma predeterminada, se seleccionan todos los clústeres. Usa "" si no quieres que haya clústeres.
--format	Acepta yaml o json. El formato de la salida. El valor predeterminado es yaml.
-h o --help	Ayuda sobre el comando nomos vet.
--keep-output	Acepta un valor booleano. Si true, el resultado renderizado se guarda en la ubicación que puedes especificar con la marca --output.
--namespace	Acepta una cadena. Si se define, valida la fuente de información veraz como una fuente de información veraz de espacio de nombres con el nombre proporcionado. Define automáticamente --source-format=unstructured.
--no-api-server-check	Acepta un valor booleano. Si true, inhabilita la comunicación con el servidor de la API de Kubernetes para la detección. Para obtener más información sobre esta marca, consulta la sección Validación del lado del servidor.
--output	Acepta una cadena. Ruta a la salida renderizada. El valor predeterminado es el directorio compiled. Si --keep-output tiene el valor false, esta marca se ignora.
--path	Acepta una cadena. Ruta al directorio raíz de tu fuente de información veraz de Config Sync. El valor predeterminado es ".".
--source-format	Acepta hierarchy o unstructured. Si se le asigna el valor hierarchy o no se establece, valida la fuente de información como una fuente de información jerárquica. Si unstructured, valida la fuente de información veraz como una fuente de información veraz no estructurada. Esta marca es obligatoria si usas una fuente de información no estructurada.
--threshold	Acepta un número entero de forma opcional. Define el número máximo de objetos permitidos por repositorio. Si se supera, se produce un error. Omite la marca o usa --threshold=0 para inhabilitar la validación del número máximo de objetos. Proporciona la marca sin un valor para usar el valor predeterminado 1000 o usa --threshold=N para definir un límite específico.

Validación del lado del servidor

Si el comando nomos vet no puede determinar si el tipo tiene un espacio de nombres, la herramienta nomos se conecta al servidor de la API del contexto kubectl actual. Como la herramienta nomos entiende de forma predeterminada los tipos principales de Kubernetes y los CRDs de Config Sync, solo intenta conectarse al servidor de la API si los CRs no tienen un CRD declarado correspondiente. En este caso, si el servidor de la API no tiene aplicada la CRD, el comando nomos vet devuelve el error KNV1021. Para inhabilitar esta comprobación y suprimir los errores de CRDs que faltan, usa la marca --no-api-server-check.

Almacenar en caché los metadatos del servidor de la API

En lugar de suprimir las comprobaciones del servidor de la API, puede almacenar en caché los datos en el servidor de la API para el comando nomos vet. Para almacenar en caché tu api-resources, sigue estos pasos:

1. Conéctate a un clúster que tenga todos los CRDs que necesites para tu fuente de información veraz. No es necesario que el clúster tenga habilitado Config Sync.
2. Ve a policyDir de tu fuente de información veraz. Es el mismo directorio especificado en tu recurso ConfigManagement o RootSync.
3. Ejecuta el siguiente comando: kubectl api-resources > api-resources.txt Este comando crea un archivo llamado api-resources.txt que contiene el resultado exacto de kubectl api-resources.

A partir de ahora, las ejecuciones de nomos vet en la fuente de información veraz tendrán en cuenta esas definiciones de tipo. Si se elimina o se cambia el nombre del archivo api-resources.txt, nomos vet no podrá encontrarlo. nomos vet seguirá intentando conectarse al clúster si encuentra manifiestos de tipos no declarados en api-resources.txt (a menos que se pase --no-api-server-check).

El archivo api-resources.txt solo afecta al funcionamiento de la herramienta nomos. No modifica el comportamiento de Config Sync de ninguna forma.

No pasa nada si hay entradas adicionales en el archivo api-resources.txt que correspondan a tipos que no estén en la fuente de información veraz que se está validando. nomos vet importa las definiciones, pero no hace nada con ellas.

Advertencia: Los tipos personalizados de una fuente de información veraz deben tener un espacio de nombres o no tenerlo. El comando nomos vet no admite tipos que tengan un ámbito de espacio de nombres en algunos clústeres y un ámbito de clúster en otros.

Actualizar api-resources.txt

Una vez que te hayas asegurado de que todas las CRDs que quieras están en el clúster, ejecuta el siguiente comando:

kubectl api-resources > api-resources.txt

Precaución: No edite api-resources.txt directamente, ya que es fácil darle un formato incorrecto y provocar errores.

Comprobar automáticamente si hay errores de sintaxis al confirmar

Si confirmas un archivo con errores de JSON o YAML, Config Sync no aplicará el cambio. Sin embargo, puedes evitar que se produzcan estos tipos de errores en la fuente de información veraz usando los hooks del lado del cliente o del lado del servidor.

Usar nomos vet en un hook pre-commit

Puedes configurar un hook pre-commit que ejecute el comando nomos vet para comprobar si hay errores de sintaxis cuando confirmes un cambio en la copia local de Git de tu repositorio. Si un hook pre-commit se cierra con un estado distinto de cero, la operación git commit falla.

Nota: Los hooks pre-commit se ejecutan en el cliente, no en el servidor. Deben añadirse manualmente a cada cliente y el usuario puede omitirlas o inhabilitarlas en cualquier momento.

Para ejecutar el comando nomos vet como un hook pre-commit, edita el archivo .git/hooks/pre-commit en tu fuente de información fiable (ten en cuenta que .git empieza por el carácter .). Puede que tengas que crear el archivo manualmente. Añade el comando nomos vet a una línea nueva de la secuencia de comandos. El argumento --path es opcional. Asigna el argumento --source-format al formato de origen del repositorio.

nomos vet --path=/path/to/repo --source-format unstructured

Asegúrate de que el archivo pre-commit sea ejecutable:

chmod +x .git/hooks/pre-commit

Ahora, cuando ejecutes un comando git commit en el clon de tu fuente de información, nomos vet se ejecutará automáticamente.

El contenido del directorio .git/ no se monitoriza por la fuente de información veraz y no se puede confirmar en la fuente de información veraz en la misma ubicación. Puedes crear un directorio en la fuente de información principal para los hooks de Git, y los usuarios que utilicen la fuente de información principal podrán copiar los hooks en el lugar adecuado de su clon local.

Usar nomos vet en un hook del lado del servidor

Git proporciona un mecanismo para ejecutar comprobaciones en el servidor, en lugar de en el cliente, durante una operación git push. Si no se supera la comprobación, tampoco se supera la git push. El cliente no puede omitir estos ganchos del lado del servidor. El método para configurar los hooks del lado del servidor depende de cómo se aloje tu servidor Git. Consulta uno de los siguientes enlaces para obtener más información o consulta la documentación de tu servicio de alojamiento de Git.

• GitHub
• Cloud Source Repositories
• Bitbucket
• GitLab
• Servidor Git autohospedado

Aplicar el número máximo de objetos que se pueden sincronizar

Config Sync almacena una referencia a cada objeto que sincroniza en un objeto de inventario ResourceGroup, junto con el estado actual del objeto. Como Kubernetes tiene un límite de tamaño en bytes para los objetos de recursos, esto limita el número máximo de objetos que Config Sync puede sincronizar con un solo RootSync o RepoSync.

De forma predeterminada, el límite de tamaño de etcd del lado del servidor es de 1,5 MiB. Para obtener más información, consulta la documentación de etcd. Si se aplica un objeto cuyo tamaño supera este límite, se producirá uno de los siguientes errores, en función del tamaño del objeto:

• etcdserver: request is too large
• rpc error: code = ResourceExhausted desc = trying to send message larger than max
• Request entity too large: limit is 3145728

Para evitar que los objetos ResourceGroup superen el límite de tamaño de Kubernetes, puedes usar nomos vet --threshold para validar el número de objetos de tu repositorio de origen.

De forma predeterminada, cuando usas el comando nomos vet, no se aplica el umbral. Si se incluye la marca --threshold, el comando vet generará un error si el número de objetos del repositorio de origen supera el umbral.

El inventario de ResourceGroup contiene tanto referencias de objetos como el estado actual de los objetos. Puede crecer mucho si los objetos no se sincronizan o no se reconcilian. Para no superar el límite de tamaño de los objetos de Kubernetes, elige un umbral que deje suficiente capacidad para registrar los errores de los objetos. El valor predeterminado de 1000 debería funcionar en casi todos los casos, pero puede aumentar o reducir el umbral según sea necesario.

Este umbral solo se valida con el comando nomos vet, no con Config Sync. Para aplicar el umbral, usa el comando nomos vet --threshold en una comprobación previa a la confirmación de un repositorio de origen o un hook pre-commit de Git.

Ver todas las configuraciones en la fuente de información veraz

Puedes usar el comando nomos hydrate para ver el contenido combinado de tu fuente de información veraz en cada clúster registrado.

Si ejecutas nomos hydrate sin opciones, se crea un directorio compiled/ en el directorio de trabajo actual. En ese directorio, se crea un subdirectorio para cada clúster registrado, con las configuraciones totalmente resueltas que el operador aplicaría al clúster.

Este comando también puede convertir una fuente de referencia jerárquica en una o varias fuentes de referencia no estructuradas mediante el contenido del directorio compiled/.

nomos hydrate flags

Para personalizar el comando nomos hydrate, añade las siguientes marcas:

Bandera	Descripción
--api-server-timeout	Acepta una cadena de duración. Define el tiempo de espera del lado del cliente para comunicarse con el servidor de la API de Kubernetes. El valor predeterminado es 15s.
--clusters	Acepta una lista de nombres de clústeres separados por comas. Usa esta marca para limitar la salida a un solo clúster o a una lista de clústeres. De forma predeterminada, se seleccionan todos los clústeres. Usa "" si no quieres que haya clústeres.
--flat	Si está habilitada, imprime toda la salida en un solo archivo. Usa esta marca si quieres emular el comportamiento de nomos view.
--format	Acepta un valor yaml o json. El formato de la salida. El valor predeterminado es yaml.
-h o --help	Ayuda sobre el comando nomos hydrate.
--no-api-server-check	Acepta un valor booleano. Si true, inhabilita la comunicación con el servidor de la API para el descubrimiento. Para obtener más información sobre esta marca, consulta la sección Validación del lado del servidor.
--output	Acepta una cadena. Ubicación en la que se escribirá la configuración hidratada. El valor predeterminado es el directorio compiled. Si --flat no está habilitado, escribe cada manifiesto de recursos como un archivo independiente. Si --flat está habilitado, escribe un solo archivo que contiene todos los manifiestos de recursos.
--path	Acepta una cadena. Ruta al directorio raíz de tu fuente de información veraz de Config Sync. El valor predeterminado es ".".
--source-format	Acepta hierarchy o unstructured. Si se le asigna el valor hierarchy o no se establece, valida la fuente de información como una fuente de información jerárquica. Si unstructured, valida la fuente de información veraz como una fuente de información veraz no estructurada. Esta marca es obligatoria si usas una fuente de información no estructurada.

Crear un informe de errores

Si tienes un problema con Config Sync que requiere la ayuda del Google Cloud equipo de Asistencia, puedes proporcionarle información valiosa para depurar el problema mediante el comando nomos bugreport. Puede usar este comando para una única fuente de información veraz y varios repositorios.

nomos bugreport

Este comando genera un archivo ZIP con marca de tiempo que contiene información sobre el clúster de Kubernetes definido en tu contexto de kubectl. El archivo también contiene registros de los pods de Config Sync. No contiene información de los recursos sincronizados con Config Sync. Para obtener más información sobre el contenido del archivo ZIP, consulta la referencia de informes de errores de Nomos.

Limitaciones

El comando nomos bugreport falla y genera un archivo ZIP incompleto si algún archivo individual supera 1 GiB. Esto suele ocurrir debido a que los archivos de registro son grandes.

En la siguiente tabla se incluyen las causas más habituales de los archivos de registro de gran tamaño y cómo puede resolverlas:

Causa	Acción recomendada
Mayor nivel de detalle de los registros	Reducir la verbosidad de los registros con anulaciones del nivel de registro
Objetos muy grandes	Dejar de gestionar el objeto grande o reducir su tamaño
Muchos objetos	Dividir un repositorio en varios
Peleas con mando	Resuelve la pelea

Migrar de un objeto ConfigManagement a un objeto RootSync

Puedes ejecutar el comando nomos migrate para migrar de tu objeto ConfigManagement a un objeto RootSync y habilitar las APIs RootSync y RepoSync.

nomos migrate admite la ejecución de prueba para previsualizar el proceso de migración.

nomos migrate modifica directamente el objeto ConfigManagement en el clúster. Para evitar que se reviertan los cambios realizados a través de nomos migrate, asegúrate de que el objeto ConfigManagement no se haya registrado en tu fuente de información veraz.

Nota: Si se incluye la marca --contexts, se especifican los contextos que se van a migrar. Esto solo es necesario si quieres migrar clústeres más allá del contexto actual.

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

Si el resultado de la prueba en seco es correcto, puedes migrar el objeto ConfigManagement con nomos migrate:

nomos migrate --contexts=KUBECONFIG_CONTEXTS

El resultado debería ser similar al siguiente:

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

Nota: nomos migrate guarda el objeto ConfigManagement original, el objeto ConfigManagement actualizado y el objeto RootSync convertido en un directorio temporal. Si nomos migrate falla o se termina de forma inesperada, puedes recuperar la migración manualmente ejecutando los comandos que se proporcionan en el resultado de nomos migrate.

Restaurar la configuración anterior

Si necesitas restaurar la versión anterior después de realizar la migración con nomos migrate, aplica el objeto ConfigManagement original. nomos migrate guarda el objeto ConfigManagement original en un archivo e imprime el nombre en la terminal. El nombre del archivo tiene el formato /tmp/nomos-migrate/CURRENT_CONTEXT/cm-original.yaml.

Para volver a la configuración anterior, copia la ruta del archivo de cm-original.yaml y aplícalo a tu clúster:

kubectl apply -f CM_ORIGINAL_PATH

nomos migrate flags

Para personalizar el comando nomos migrate, añade las siguientes marcas:

Bandera	Descripción
--connect-timeout	Acepta una duración. Duración del tiempo de espera para conectarse a cada clúster. El valor predeterminado es 3s.
--contexts	Acepta una lista de contextos separados por comas para usarla en entornos multiclúster. El valor predeterminado es el contexto actual. Usa "all" en todos los contextos.
--dry-run	Acepta un valor booleano. Si true, solo imprime la salida de la migración.
-h o --help	Ayuda sobre el comando nomos migrate.
--remove-configmanagement	Acepta un valor booleano. Si true, migra a Config Sync de OSS quitando el operador ConfigManagement y el CRD ConfigManagement.
--wait-timeout	Acepta una duración. Duración del tiempo de espera para que se cumplan las condiciones de los recursos de Kubernetes. El valor predeterminado es 10m.

Inicializar una fuente de información veraz jerárquica

Puedes organizar tu fuente de información de forma arbitraria si usas una fuente de información no estructurada. Si usas una fuente de referencia jerárquica, debes ejecutar el comando nomos init para inicializar un directorio jerárquico:

nomos init

De esta forma, se crea la estructura de directorios básica de una fuente de información jerárquica, incluidos los directorios system/, cluster/ y namespaces/.

Marcas de nomos init

Para personalizar nomos init, añade las siguientes marcas:

Bandera	Descripción
--force	Escribir en el directorio aunque no esté vacío y sobrescribir los archivos en conflicto
-h o --help	Ayuda sobre el comando nomos init.
--path	Acepta una cadena. El directorio raíz que se va a usar como fuente de información principal. El valor predeterminado es ".".

Solución de problemas

En Linux, es posible que veas el siguiente error al ejecutar un comando nomos:

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

Para solucionar este problema, crea una variable de entorno USER:

export USER=$(whoami)

Siguientes pasos

• Empezar a usar Config Sync