Usa el comando nomos

El comando nomos (nomos.exe en Windows) es una herramienta opcional de línea de comandos que puedes instalar localmente, como en una estación de trabajo o computadora portátil. Puedes usar el comando nomos para interactuar con el operador de administración de configuración, verificar la sintaxis de las configuraciones antes de enviarlas al repositorio y depurar problemas con Anthos Config Management, el clúster o el repositorio.

Requisitos

Antes de que puedas usar el comando nomos a fin de interactuar con un clúster, el operador ya debe estar instalado en el clúster de destino y el comando kubectl debe estar configurado para autenticarse en el clúster de destino. Consulta Instalación de Anthos Config Management para obtener más información.

Instala el comando nomos

El comando nomos es un objeto binario compilado a partir del código de Go. Es opcional y no se incluye en una instalación predeterminada de Anthos Config Management.

Para descargar el comando nomos de cada versión de Anthos Config Management, consulta Descargas.

Pasos adicionales para clientes de macOS y Linux

Después de descargar el objeto binario, configúralo para que sea ejecutable:

chmod +x /path/to/nomos

Puedes mover el comando a una ubicación en la que tu sistema busque objetos binarios, como /usr/local/bin, o puedes ejecutar el comando mediante el uso de su ruta completamente calificada.

Uso básico

Los comandos nomos y nomos.exe incluyen subcomandos para inicializar tu repositorio, comprobar la existencia de errores de sintaxis, conseguir el estado de cada grupo inscrito y ver tu repositorio como una serie de CustomResourceDefinitions.

Para la sintaxis de comandos básicos, usa el argumento --help:

nomos --help

El comando nomos lee de la clonación local de tu repositorio. Usa la marca --path para especificar la ubicación del nivel superior del repositorio. De forma predeterminada, --path está configurado como . o el directorio actual.

nomos --path=path/to/your/repo status

Comprueba el estado de la instalación

Puedes verificar si Anthos Config Management está correctamente instalado y configurado en todos tus clústeres mediante el comando nomos status. Informa de cualquier error que impida la ejecución de Anthos Config Management. Por ejemplo:

nomos status
Context             Status           Last Synced Token
-------             ------           -----------------
managed-cluster-1   NOT INSTALLED
managed-cluster-2   NOT CONFIGURED
managed-cluster-3   SYNCED           f52a11e4

Config Management Errors:
managed-cluster-2   missing git-creds Secret

En este resultado, Anthos Config Management no está instalado en managed-cluster-1. Está instalado pero no configurado en managed-cluster-2. Está instalado y en ejecución correcta en managed-cluster-3.

Además, la razón por la que managed-cluster-2 no se configuró es que el secreto git-creds no está presente.

Inicializa un nuevo repositorio

Para inicializar un nuevo repositorio de Anthos Config Management, crea un directorio vacío, cámbialo, inicializa un nuevo repositorio de Git y, luego, ejecuta el comando nomos init:

mkdir my-repo
cd my-repo
git init
nomos init

Esto crea la estructura de directorio básica de tu repositorio, incluidos los directorios system/, cluster/ y namespaces/.

Comprueba si hay errores en el repositorio

Antes de confirmar una configuración para el repositorio, use el comando nomos vet a fin de verificar la sintaxis y la validez de las configuraciones en tu repositorio:

nomos vet

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

Si nomos vet no puede determinar si el tipo tiene espacios de nombres, nomos se conecta al servidor de API. Dado que nomos comprende los tipos principales de Kubernetes y los CRD de Anthos Config Management, solo intenta conectarse al servidor de API si hay CR que no tengan un CRD declarado correspondiente. En este caso, si el servidor de API no tiene el CRD aplicado, nomos vet muestra un error. Para deshabilitar esta comprobación y suprimir los errores de CRD faltantes, pasa la marca --no-api-server-check.

Comprueba de forma automática si hay errores de sintaxis durante la confirmación

Si confirmas un archivo con errores JSON o YAML, Anthos Config Management no aplica el cambio. Sin embargo, puedes evitar que este tipo de errores ingresen al repositorio si usas los hooks del cliente o del servidor.

Usa nomos vet en un hook de confirmación previa de Git

Puedes configurar un hook de confirmación previa que ejecute nomos vet para verificar si hay errores de sintaxis cuando confirmas un cambio en la clonación de Git local de tu repositorio. Si un hook de confirmación previa sale con un estado distinto de cero, la operación git commit fallará.

Para ejecutar el comando nomos vet como un hook de confirmación previa, edita el archivo .git/hooks/pre-commit en tu repositorio (ten en cuenta que .git comienza con un carácter .). Es posible que debas crear el archivo manualmente. Agrega el comando nomos vet a una nueva línea en la secuencia de comandos. El argumento --path es opcional.

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

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

chmod +x .git/hooks/pre-commit

Ahora, cuando ejecutas un comando git commit en la clonación de tu repositorio, nomos vet se ejecuta automáticamente.

El repositorio en sí no realiza un seguimiento del contenido del directorio .git/ del repositorio. El contenido no puede confirmarse para el repositorio en la misma ubicación. Puedes crear un directorio en el repositorio para los hooks de Git, y las personas que usan el repositorio pueden copiar los hooks en el lugar apropiado en su clonación local.

Usa nomos vet en un hook 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 la verificación falla, git push también fallará. El cliente no puede pasar por alto estos hooks del servidor. El método para configurar los hooks del servidor depende de cómo esté alojado tu servidor de Git. Consulta uno de los siguientes vínculos para obtener más información o consulta la documentación de tu servicio de hosting de Git.

Visualiza el resultado de todas las configuraciones en el repositorio

Puedes usar el comando nomos hydrate para ver el contenido combinado de tu repositorio en cada clúster inscrito.

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

Puedes especificar el nombre del directorio de salida si proporcionas una ruta de directorio como argumento del comando:

nomos hydrate [/path/to/directory]

Para limitar la salida a un solo clúster o a una lista de clústeres, usa la marca --clusters y proporciona una lista de nombres de clúster separados por comas.

Para emular el comportamiento de nomos view y guardar la configuración efectiva en un solo archivo, usa la marca --flat.

Para obtener más información, usa la marca --help.

nomos hydrate --flat

nomos view

Cuando Anthos Config Management importa configuraciones del repositorio, las convierte a CustomResourceDefinitions (CRD) del tipo ClusterConfig o NamespaceConfig. El comando nomos view te permite ver los CRD resultantes del estado actual de tu repositorio en formato JSON. Esto puede ser útil antes de confirmar el cambio, o para depurar problemas con configuraciones que no son obvias mediante el comando nomos vet.

nomos view --path=/path/to/your/repo

Verifica si hay errores en tus clústeres

Cada vez que envías una confirmación de Git al repositorio, el operador detecta el cambio y aplica las nuevas configuraciones a todos los clústeres inscritos. Puedes supervisar el estado de Anthos Config Management en todos los clústeres inscritos mediante el comando nomos status. Para cada clúster, informa el hash de la confirmación de Git que se aplicó por última vez al clúster, así como cualquier error que haya ocurrido cuando intentaste aplicar cualquier cambio reciente. Por ejemplo:

nomos status
Context                 Status      Last Synced Token
-------                 ------      -----------------
managed-cluster-1       SYNCED      f52a11e4
managed-cluster-2       PENDING     9edf8444
managed-cluster-3       ERROR       9edf8444
managed-cluster-4       NOT INSTALLED
managed-cluster-5       SYNCED      f52a11e4

Config Management Errors:
managed-cluster-3       KNV1021: No CustomResourceDefinition is defined for the resource in the cluster.

Puedes ver que dos de los clústeres sincronizaron el cambio más reciente, un clúster todavía se está sincronizando y un clúster tiene un error que impidió que se aplicara el cambio. En este caso, parece que a managed-cluster-3 le falta un CRD que los otros clústeres tienen instalado.

De forma predeterminada, el comando nomos status imprimirá el estado de cada clúster y luego saldrá. Sin embargo, puedes usar la marca poll para ejecutar el comando de forma continua y hacer que vuelva a imprimir la tabla de estado a intervalos regulares.

nomos status --poll 2s

Crea un informe de errores

Si tienes un problema con Anthos Config Management que requiera la ayuda de la asistencia de Google Cloud, puedes proporcionarles información valiosa de depuración mediante el comando nomos bugreport.

nomos bugreport

Este comando genera un archivo zip con marca de tiempo que contiene información sobre el conjunto de clústeres de Kubernetes en tu contexto kubectl.

El archivo contiene registros de pods de Anthos Config Management. No contiene información de los recursos sincronizados con Anthos Config Management.

Soluciona problemas

En Linux, puedes ver el siguiente error cuando ejecutas un comando nomos:

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

Crea una variable de entorno USER para solucionar este problema:

export USER=$(whoami)

¿Qué sigue?