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

Nota: Anthos Config Management requiere una autorización activa de Anthos. De lo contrario, la descarga fallará con un error 404 File not found.
Para obtener más información, consulta los precios de Anthos.

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 su ruta de acceso completamente calificada.

Uso básico

Los comandos nomos y nomos.exe incluyen subcomandos para inicializar tu repositorio, comprobar errores de sintaxis, obtener el estado de cada clúster inscrito y ver tu repositorio como una serie de CustomResourceDefinitions.

Para la sintaxis del comando básico, usa el argumento --help:

nomos --help

El comando nomos lee desde el clon 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á instalado y configurado de forma adecuada en todos tus clústeres mediante el comando nomos status. Informa los errores que impidan 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 está configurado en managed-cluster-2. Está instalado y se ejecuta de manera correcta en managed-cluster-3.

Además, el motivo por el que managed-cluster-2 no está configurado 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 un archivo de configuración en el repositorio, usa el comando nomos vet para verificar la sintaxis y la validez de los archivos de configuración del 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 inhabilitar 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 el clon local de Git 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 de forma manual. Agrega el comando nomos vet a una línea nueva 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 ejecutes un comando git commit en el clon de tu repositorio, nomos vet se ejecutará de manera automática.

El repositorio en sí no realiza un seguimiento del contenido del directorio .git/ del repositorio. Este contenido no puede confirmarse en 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 clon 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, el git push también falla. 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 todos los archivos de configuración 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, se crea un directorio compiled/ en el directorio de trabajo actual. Dentro de ese directorio, se crea un subdirectorio para cada clúster inscrito, con los archivos de configuración completamente resueltos que el operador aplica al clúster.

Puedes especificar el nombre del directorio de salida si proporcionas una ruta de acceso 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 archivos de configuración del repositorio, las convierte en CustomResourceDefinitions (CRD) del tipo ClusterConfig o NamespaceConfig. El comando nomos view te permite ver las CRD resultantes del estado actual de tu repositorio en formato JSON. Esto puede ser útil antes de confirmar los cambios o para depurar problemas de los archivos de configuración que no son obvios mediante el comando nomos vet.

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

Comprueba si hay errores en los 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 una CRD que los otros clústeres tienen instalada.

De forma predeterminada, el comando nomos status mostrará 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 mostrar la tabla de estado a intervalos regulares.

nomos status --poll 2s

Información acerca del último token sincronizado

nomos status muestra el hash de confirmación de Git más reciente que se aplicó al clúster en la salida en Last Synced Token. Para obtener este valor, consulta el objeto Repo y observa el campo status.sync:

kubectl get repos.configmanagement.gke.io -o yaml
apiVersion: v1
kind: Repo
items:
- status:
    sync:
      lastUpdate: "2019-09-26T10:17:57Z"
      latestToken: f1739af550912034139aca51e382dc50c4036ae0

Esta confirmación representa la confirmación más reciente en el clúster. Sin embargo, no todos los espacios de nombres en el clúster se ven afectados por cada confirmación; para ver la confirmación más reciente en un espacio de nombres específico, consulta el objeto NamespaceConfig en particular y observa el campo status. Por ejemplo:

kubectl get namespaceconfigs.configmanagement.gke.io my-namespace -o yaml
apiVersion: configmanagement.gke.io/v1
kind: NamespaceConfig
status:
  syncState: synced
      lastUpdate: "2019-09-26T08:24:32Z"
      latestToken: 1850bad9419d3baec8af220c15d5e952dbeb3b25

Aunque un espacio de nombres puede verse afectado por una confirmación, es posible que no todos los recursos del espacio de nombres se ven afectados. Para encontrar la confirmación sincronizada más reciente de un recurso específico, consultar este recurso y observar metadata.annotations.configmanagement.gke.io/token. Por ejemplo:

kubectl get clusterrolebindings.rbac.authorization.k8s.io my-role-binding -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    configmanagement.gke.io/token: e56b09554ca8004a2c38185a4ed11364fd6986c4

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 los pods de Anthos Config Management. No contiene información de los recursos sincronizados con Anthos Config Management.

Soluciona problemas

En Linux, es posible que veas el siguiente error cuando ejecutes 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?