Instala el Sincronizador de configuración de forma manual con kubectl (no recomendado)

En esta página, se muestra cómo instalar el Sincronizador de configuración mediante los comandos de kubectl.

Precaución: No se recomiendan los métodos de instalación que se usan en esta página porque no son compatibles con la consola de Google Cloud ni con Google Cloud CLI.

Antes de comenzar

En esta sección, se describen los requisitos que debes cumplir antes de instalar el Sincronizador de configuración mediante kubectl.

Prepara el entorno local

Antes de instalar Sincronizador de configuración, asegúrate de haber preparado tu entorno local. Para ello, completa las siguientes tareas:

• Crea una fuente de verdad o asegúrate de tener acceso a ella.

• Instala e inicializa Google Cloud CLI, que proporciona los comandos gcloud, kubectl y nomos que se usan en estas instrucciones. Si usas Cloud Shell, Google Cloud CLI viene preinstalada.

• Google Cloud CLI no instala kubectl de forma predeterminada. Para instalar kubectl, usa el siguiente comando:

  gcloud components install kubectl
  

• Autentícate en Google Cloud con el comando gcloud auth login para que puedas descargar componentes del Sincronizador de configuración.

Prepara tus clústeres

Crea un clúster de Google Kubernetes Engine que cumpla con los requisitos del Sincronizador de configuración o accede a uno.

Prepara los permisos

El Google Cloud usuario que instala Sincronizador de configuración necesita permisos de IAM para crear roles nuevos en tu clúster. Si es necesario, otorga estas funciones con los siguientes comandos:

gcloud container clusters get-credentials CLUSTER_NAME

kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole cluster-admin --user USER_ACCOUNT

Reemplaza lo siguiente:

• CLUSTER_NAME: El nombre del clúster
• USER_ACCOUNT: La dirección de correo electrónico de tu cuenta de Google Cloud

Según cómo hayas configurado Google Cloud CLI en tu sistema local, es posible que debas agregar los campos --project y --zone.

Si necesitas otorgar acceso al Sincronizador de configuración a OCI con gcpserviceaccount como tu tipo de autenticación para crear una vinculación de política, también debes tener el permiso iam.serviceAccounts.setIamPolicy. Para obtener este permiso, otorga el rol de IAM de administrador de cuentas de servicio (roles/iam.serviceAccountAdmin). También puedes obtener este permiso con roles personalizados o con otros roles predefinidos.

Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso.

Inscribe un clúster

Para inscribir un clúster en Sincronizador de configuración, completa los siguientes pasos:

1. Implementa Config Sync
2. Otorga acceso de solo lectura al Sincronizador de configuración a uno de los siguientes elementos:
   • Git
   • OCI
   • Helm
3. Configura Config Sync

Implementa el Sincronizador de configuración

Después de asegurarte de cumplir con todos los requisitos previos, puedes implementar Sincronizador de configuración descargando y aplicando un manifiesto YAML:

1. Descarga la versión más reciente de los manifiestos de Sincronizador de configuración con el siguiente comando. En cambio, si deseas descargar una versión específica, consulta Descargas.

   gcloud storage cp gs://config-management-release/released/latest/config-sync.tar.gz config-sync.tar.gz
   

2. Extrae el archivo:

   tar -xzvf config-sync.tar.gz

3. En el archivo que extrajiste en el paso anterior, sigue las instrucciones del archivo README.md proporcionado para editar la personalización.

4. Para actualizar la instalación del Sincronizador de configuración, aplica el manifiesto renderizado que compilaste siguiendo las instrucciones de README.md:

   kubectl apply -f CONFIG_SYNC_MANIFEST
   

   Reemplaza CONFIG_SYNC_MANIFEST por el nombre del manifiesto renderizado.

5. Reemplaza el comando nomos en todos los clientes con la versión nueva. Este cambio garantiza que el comando nomos siempre pueda obtener el estado de todos los clústeres inscritos y validar los archivos de configuración para ellos.

Si esto falla debido a un problema con el Sincronizador de configuración que no se debe a un error de sintaxis de YAML o JSON, es posible que se cree una instancia del objeto en el clúster, pero que no funcione correctamente. En este caso, puedes usar el comando nomos status para verificar si hay errores en el objeto.

Una instalación válida sin problemas tiene el estado PENDING o SYNCED.

Una instalación no válida tiene un estado de NOT CONFIGURED y enumera uno de los siguientes errores:

• missing git-creds Secret
• git-creds Secret is missing the key specified by secretType

Para solucionar el problema, corrige el error de configuración. Según el tipo de error, es posible que debas volver a aplicar el manifiesto del Sincronizador de configuración al clúster.

Si el problema es que te olvidaste de crear el Secret git-creds, el Sincronizador de configuración detecta el Secret en cuanto lo creas y no es necesario que vuelvas a aplicar la configuración.

Otorga acceso de solo lectura al Sincronizador de configuración

Si almacenas tus archivos de configuración en Git, debes otorgarle al Sincronizador de configuración acceso de solo lectura a Git. Si almacenas tus archivos de configuración como imágenes de OCI, debes otorgar acceso de solo lectura al Sincronizador de configuración a OCI. Si almacenas tus archivos de configuración en Helm, debes otorgar acceso de solo lectura al Sincronizador de configuración a Helm.

Otorga acceso de solo lectura al Sincronizador de configuración a Git

El Sincronizador de configuración necesita acceso de solo lectura a tu repositorio de Git para que pueda leer las configuraciones confirmadas en el repositorio y aplicarlas a tus clústeres.

Si el repositorio no requiere autenticación para el acceso de solo lectura, puedes continuar con la configuración del Sincronizador de configuración y usar none como el tipo de autenticación. Por ejemplo, si puedes explorar el repositorio mediante una interfaz web sin acceder a tu cuenta, o si puedes usar git clone para crear una clonación del repositorio de forma local sin proporcionar credenciales o usar credenciales guardadas, no es necesario que realices la autenticación. En este caso, no necesitas crear un Secret.

Sin embargo, la mayoría de los usuarios deben crear credenciales porque el acceso de lectura a su repositorio está restringido. Si se requieren credenciales, se almacenan en el Secret git-creds en cada clúster inscrito (a menos que uses una cuenta de servicio de Google). El Secret debe llamarse git-creds, ya que este es un valor fijo.

El Sincronizador de configuración admite los siguientes mecanismos de autenticación:

• Par de claves SSH (ssh)
• Archivo cookie (cookiefile)
• Token (token)
• Cuenta de servicio de Google (gcpserviceaccount)
• Cuenta de servicio predeterminada de Compute Engine (gcenode)
• App de GitHub (githubapp)

El mecanismo que elijas dependerá de lo que admita tu repositorio. Por lo general, recomendamos usar un par de claves SSH. GitHub y Bitbucket son compatibles con un par de claves SSH. Sin embargo, si usas un repositorio en Cloud Source Repositories o Secure Source Manager, te recomendamos que uses una cuenta de servicio de Google, ya que el proceso es más simple. Si tu organización aloja tu repositorio y no sabes qué métodos de autenticación se admiten, comunícate con tu administrador.

Para usar un repositorio en Cloud Source Repositories como el repositorio del Sincronizador de configuración, completa los siguientes pasos para recuperar la URL de Cloud Source Repositories:

1. Enumera todos los repositorios:

   gcloud source repos list
   

2. Copia la URL del repositorio que deseas usar desde el resultado: Por ejemplo:

   REPO_NAME  PROJECT_ID  URL
   my-repo    my-project  https://source.developers.google.com/p/my-project/r/my-repo-csr
   

   Debes usar esta URL cuando configures el Sincronizador de configuración en la siguiente sección. Si configuras el Sincronizador de configuración con la consola deGoogle Cloud , debes agregar la URL en el campo URL. Si configuras el Sincronizador de configuración con Google Cloud CLI, debes agregar la URL al campo syncRepo del archivo de configuración.

Par de claves SSH

Un par de claves SSH consta de dos archivos, una clave pública y una clave privada. Por lo general, la clave pública tiene una extensión .pub.

Advertencia: Protege los archivos que se crean con este comando. Ellos otorgan la capacidad de leer desde tu repositorio.

Para usar un par de claves SSH, completa los siguientes pasos:

1. Crea un par de claves SSH para permitir que el Sincronizador de configuración se autentique en tu repositorio de Git. Este paso es necesario si necesitas autenticarte en el repositorio para clonarlo o leer de él. Omite este paso si un administrador de seguridad te proporciona un par de claves. Puedes usar un solo par de claves para todos los clústeres o un par de claves por clúster, según tus requisitos de seguridad y cumplimiento.

   El siguiente comando crea una clave RSA de 4096 bits. No se recomiendan valores más bajos:

   ssh-keygen -t rsa -b 4096 \
   -C "GIT_REPOSITORY_USERNAME" \
   -N '' \
   -f /path/to/KEYPAIR_FILENAME
   

   Reemplaza lo siguiente:

   • GIT_REPOSITORY_USERNAME: El nombre de usuario que deseas que el Sincronizador de configuración use para autenticarse en el repositorio.
   • /path/to/KEYPAIR_FILENAME: Una ruta de acceso al par de claves.

   Si usas un host del repositorio de Git de terceros, como GitHub, o deseas usar una cuenta de servicio con Cloud Source Repositories, te recomendamos que uses una cuenta distinta.

   Nota: Debes crear la clave SSH sin una frase de contraseña. El Sincronizador de configuración no admite frases de contraseña de claves SSH.

2. Configura el repositorio para que reconozca la clave pública que acabas de crear. Consulta la documentación de tu proveedor de hosting de Git. Se incluyen instrucciones para algunos proveedores de hosting de Git populares para mayor comodidad:

   • Cloud Source Repositories
   • Bitbucket
   • GitHub Recomendamos que crees claves de implementación por separado para proporcionar acceso de solo lectura a un único repositorio de GitHub.
   • GitLab

3. Agrega la clave privada a un Secret nuevo del clúster:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=ssh=/path/to/KEYPAIR_PRIVATE_KEY_FILENAME
   

   Reemplaza /path/to/KEYPAIR_PRIVATE_KEY_FILENAME por el nombre de la clave privada (la que no tiene el sufijo .pub).

4. (Recomendado) Para configurar la verificación de hosts conocidos con la autenticación de SSH, puedes agregar la clave de hosts conocidos al campo data.known_hosts en el secreto git_creds. Para inhabilitar la verificación de known_hosts, puedes quitar el campo known_hosts del secreto. Para agregar la clave de hosts conocidos, ejecuta el siguiente comando:

   kubectl edit secret git-creds \
    --namespace=config-management-system
   

   Luego, en data, agrega la entrada de hosts conocidos:

   known_hosts: KNOWN_HOSTS_KEY
   

5. Borra la clave privada del disco local o protégela.

6. Cuando configures el Sincronizador de configuración y agregues la URL de tu repositorio de Git, usa el protocolo SSH. Si usas un repositorio en Cloud Source Repositories, debes usar el siguiente formato cuando ingreses tu URL:

   ssh://[e-mail]:2022/p/PROJECT_ID/r/REPO_NAME
   

   Reemplaza lo siguiente:

   • EMAIL: Tu Google Cloud nombre de usuario
   • PROJECT_ID: Es el ID del proyecto Google Clouden el que se encuentra el repositorio.
   • REPO_NAME: Es el nombre del repositorio

Archivo cookie

Nota: El uso de credenciales cookiefile solo es compatible con Cloud Source Repositories. Si deseas usar GitHub con la autenticación cookiefile, puedes usar Cloud Source Repositories para duplicar tu repositorio de GitHub.

El proceso de adquisición de un cookiefile depende de la configuración del repositorio. Para ver un ejemplo, consulta la sección sobre cómo generar credenciales estáticas en la documentación de Cloud Source Repositories. Por lo general, las credenciales se almacenan en el archivo .gitcookies en el directorio de tu página principal, o las puede proporcionar un administrador de seguridad.

Para usar un cookiefile, completa los siguientes pasos:

1. Después de crear y obtener el cookiefile, agrégalo a un Secret nuevo en el clúster.

   Si no usas el proxy HTTPS, crea el Secret con el siguiente comando:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/COOKIEFILE
   

   Si necesitas usar un proxy HTTPS, agrégalo al Secret junto con cookiefile mediante la ejecución del siguiente comando:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/COOKIEFILE \
    --from-literal=https_proxy=HTTPS_PROXY_URL
   

   Reemplaza lo siguiente:

   • /path/to/COOKIEFILE: La ruta de acceso y el nombre de archivo adecuados
   • HTTPS_PROXY_URL: La URL del proxy HTTPS que usas cuando te comunicas con el repositorio de Git
   Nota: No recomendamos usar un proxy HTTP por motivos de seguridad.

2. Protege el contenido de cookiefile, si aún lo necesitas usar de forma local. De lo contrario, bórralo.

Token

Si tu organización no permite el uso de claves SSH, se recomienda usar un token. Con el Sincronizador de configuración, puedes usar tokens de acceso personales (PAT) de GitHub, PAT o claves de implementación de GiLab, o la contraseña de la aplicación de Bitbucket como token.

Para crear un Secret con tu token, completa estos pasos:

1. Crea un token mediante GitHub, GitLab, o Bitbucket.

   • GitHub: Crea un PAT. Otorga el permiso repo al token para que pueda leer de repositorios privados. Debido a que vinculas un PAT a una cuenta de GitHub, también te recomendamos crear un usuario de máquina y vincular tu PAT a este usuario.
   • GitLab: Crea un PAT o un token de implementación.
   • Bitbucket: Crea una contraseña de la aplicación.

2. Después de crear y obtener el token, agrégalo a un Secreto nuevo en el clúster.

   Si no usas el proxy HTTPS, crea el Secret con el siguiente comando:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace="config-management-system" \
     --from-literal=username=USERNAME \
     --from-literal=token=TOKEN
   

   Reemplaza lo siguiente:

   • USERNAME: El nombre de usuario que deseas usar
   • TOKEN: El token que creaste en el paso anterior

   Si necesitas usar un proxy HTTPS, agrégalo al Secret junto con username y token mediante la ejecución del siguiente comando:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
     --from-literal=token=TOKEN \
    --from-literal=https_proxy=HTTPS_PROXY_URL
   

   Reemplaza lo siguiente:

   • USERNAME: El nombre de usuario que deseas usar
   • TOKEN: El token que creaste en el paso anterior
   • HTTPS_PROXY_URL: La URL del proxy HTTPS que usas cuando te comunicas con el repositorio de Git
   Nota: No recomendamos usar un proxy HTTP por motivos de seguridad.

3. Protege el token si lo necesitas de forma local. De lo contrario, bórralo.

Cuenta de servicio de Google

Si tu repositorio se encuentra en Cloud Source Repositories o en Secure Source Manager, y tu clúster usa Workload Identity Federation for GKE o Workload Identity Federation for GKE de la flota, puedes otorgar al Sincronizador de configuración acceso a un repositorio en el mismo proyecto que tu clúster administrado con una cuenta de servicio de Google.

1. Si no tienes una cuenta de servicio, crea una cuenta de servicio.

2. Otorga los roles de IAM correctos a la cuenta de servicio para que pueda acceder al repositorio:

   Cloud Source Repositories

   Otorga el rol de IAM de lector de Cloud Source Repositories (roles/source.reader) a la cuenta de servicio de Google. Para obtener más información sobre los roles y permisos de Cloud Source Repositories, consulta Otorga permisos para ver repositorios.

   • Otorga permisos en todo el proyecto si los mismos permisos se aplican a todos los repositorios del proyecto.

     gcloud projects add-iam-policy-binding PROJECT_ID \
       --role=roles/source.reader \
       --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

   • Otorga permisos específicos del repositorio cuando desees que las cuentas de servicio tengan diferentes niveles de acceso para cada repositorio del proyecto.

     gcloud source repos set-iam-policy REPOSITORY POLICY_FILE --project=PROJECT_ID
     

   Secure Source Manager

   Otorga los roles de IAM de Accesor de instancias de Secure Source Manager (roles/securesourcemanager.instanceAccessor) y Lector de repositorios de Secure Source Manager (roles/securesourcemanager.repoReader) a la cuenta de servicio de Google. Para obtener más información sobre los roles y permisos de Secure Source Manager, consulta Administración de roles del repositorio.

   • Otorga permisos en todo el proyecto si los mismos permisos se aplican a todos los repositorios del proyecto.

     gcloud projects add-iam-policy-binding PROJECT_ID \
       --role=roles/securesourcemanager.instanceAccessor \
       --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

     gcloud projects add-iam-policy-binding PROJECT_ID \
       --role=roles/securesourcemanager.repoReader \
       --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

   • Para otorgar permisos específicos del repositorio, puedes usar la interfaz web de Secure Source Manager para el repositorio. Para obtener más información, consulta Cómo otorgar roles a nivel del repositorio a los usuarios.

3. Si configuras Sincronizador de configuración con la consola de Google Cloud , selecciona Workload Identity Federation for GKE como el Tipo de autenticación y, luego, agrega el correo electrónico de tu cuenta de servicio.

   Si configuras el Sincronizador de configuración con Google Cloud CLI, agrega gcpserviceaccount como secretType y, luego, agrega el correo electrónico de tu cuenta de servicio a gcpServiceAccountEmail.

4. Si usas un repositorio en Secure Source Manager, debes usar el siguiente formato cuando configures Sincronizador de configuración y agregues la URL de tu repositorio de Git:

   https://INSTANCE_ID-PROJECT_NUMBER-git.LOCATION.sourcemanager.dev/PROJECT_ID/REPO_NAME.git
   

   Reemplaza lo siguiente:

   • INSTANCE_ID: Es el nombre de tu instancia de Secure Source Manager.
   • PROJECT_ID: Es el ID del proyecto Google Clouden el que se encuentra la instancia.
   • PROJECT_NUMBER: Es el número del proyecto Google Clouden el que se encuentra la instancia.
   • LOCATION: Es la región en la que se encuentra la instancia.
   • REPO_NAME: es el nombre del repositorio,

5. Después Configura el Sincronizador de configuración, crea unVinculación de políticas de IAM entre la cuenta de servicio de Kubernetes y la cuenta de servicio de Google. La cuenta de servicio de Kubernetes no se creará hasta que configures el Sincronizador de configuración por primera vez.

   Si usas clústeres que están registrados en una flota, solo tienes que crear la vinculación de política una vez por flota. Todos los clústeres registrados en una flota comparten el mismo grupo de Workload Identity Federation for GKE. Con el concepto de similitud de la flota, si agregas la política de IAM a tu cuenta de servicio de Kubernetes en un clúster, la cuenta de servicio de Kubernetes del mismo espacio de nombres en otros clústeres en la misma flota también obtiene la misma política de IAM.

   Esta vinculación permite que la cuenta de servicio del Sincronizador de configuración de Kubernetes funcione como la cuenta de servicio de Google:

   gcloud iam service-accounts add-iam-policy-binding \
       GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/iam.workloadIdentityUser \
       --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
       --project=PROJECT_ID
   

Reemplaza lo siguiente:

• PROJECT_ID: el ID del proyecto de la organización.
• FLEET_HOST_PROJECT_ID: Si usas Workload Identity Federation for GKE de GKE, esto es lo mismo que PROJECT_ID. Si usas Workload Identity Federation for GKE de la flota para GKE, este es el ID del proyecto de la flota en la que está registrado tu clúster.
• GSA_NAME: Es la cuenta de servicio personalizada de Google que deseas usar para conectarte a Artifact Registry. La cuenta de servicio debe tener el rol de IAM de lector de Artifact Registry (roles/artifactregistry.reader).
• KSA_NAME: Es la cuenta de servicio de Kubernetes para el conciliador.
  • Para los repositorios raíz, si el nombre RootSync es root-sync, usa root-reconciler. De lo contrario, usa root-reconciler-ROOT_SYNC_NAME. Si instalas el Sincronizador de configuración con la consola de Google Cloud o Google Cloud CLI, el Sincronizador de configuración crea de forma automática un objeto RootSync llamadoroot-sync.
• REPOSITORY: es el nombre del repositorio,
• POLICY_FILE es el archivo JSON o YAML con la política de Identity Access Management.

Nota: Para crear esta vinculación de política se requiere el permiso iam.serviceAccounts.setIamPolicy.

Cuenta de servicio predeterminada de Compute Engine

Si tu repositorio está en Cloud Source Repositories y tu clúster es de GKE con Workload Identity Federation for GKE inhabilitada, puedes usar gcenode como tu tipo de autenticación.

Si configuras Sincronizador de configuración con la consola de Google Cloud , selecciona Google Cloud Repository como el Tipo de autenticación.

Si configuras el Sincronizador de configuración con Google Cloud CLI, agrega gcenode como secretType.

Si seleccionas Google Cloud Repository o gcenode, puedes usar la cuenta de servicio predeterminada de Compute Engine. Debes otorgar el rol de IAM de lector de Cloud Source Repositories (roles/source.reader) a la cuenta de servicio predeterminada de Compute Engine. Para obtener más información sobre los roles y permisos de Cloud Source Repositories, consulta Otorga permisos para ver repositorios.

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/source.reader \
  --member="serviceAccount:[e-mail]"

Reemplaza PROJECT_ID por el ID del proyecto de tu organización y PROJECT_NUMBER por el número del proyecto de tu organización.

App de GitHub

Si tu repositorio está en GitHub, puedes usar githubapp como tu tipo de autenticación.

Para usar una app de GitHub, completa los siguientes pasos:

1. Sigue las instrucciones de GitHub para aprovisionar una app de GitHub y otorgarle permiso para leer tu repositorio.

2. Agrega la configuración de la app de GitHub a un Secret nuevo del clúster:

   Usa el ID de cliente

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=github-app-client-id=CLIENT_ID \
     --from-literal=github-app-installation-id=INSTALLATION_ID \
     --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
     --from-literal=github-app-base-url=BASE_URL
   

   • Reemplaza CLIENT_ID por el ID de cliente de la app de GitHub.
   • Reemplaza INSTALLATION_ID por el ID de instalación de la app de GitHub.
   • Reemplaza /path/to/GITHUB_PRIVATE_KEY por el nombre del archivo que contiene la clave privada.
   • Reemplaza BASE_URL por la URL base del extremo de API de GitHub. Solo es necesario cuando el repositorio no está alojado en www.github.com. De lo contrario, se puede omitir el argumento y se usará https://api.github.com/ de forma predeterminada.

   Cómo usar el ID de aplicación

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=github-app-application-id=APPLICATION_ID \
     --from-literal=github-app-installation-id=INSTALLATION_ID \
     --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
     --from-literal=github-app-base-url=BASE_URL
   

   • Reemplaza APPLICATION_ID por el ID de la aplicación de GitHub App.
   • Reemplaza INSTALLATION_ID por el ID de instalación de la app de GitHub.
   • Reemplaza /path/to/GITHUB_PRIVATE_KEY por el nombre del archivo que contiene la clave privada.
   • Reemplaza BASE_URL por la URL base del extremo de API de GitHub. Solo es necesario cuando el repositorio no está alojado en www.github.com. De lo contrario, se puede omitir el argumento y se usará https://api.github.com/ de forma predeterminada.

3. Borra la clave privada del disco local o protégela.

4. Cuando configures el Sincronizador de configuración y agregues la URL de tu repositorio de Git, usa el tipo de autenticación githubapp.

Otorga acceso de solo lectura al Sincronizador de configuración a OCI

El Sincronizador de configuración necesita acceso de solo lectura a tu imagen de OCI almacenada en Artifact Registry para que pueda leer las configuraciones incluidas en la imagen y aplicarlas a tus clústeres.

Si la imagen no requiere autenticación para el acceso de solo lectura, puedes continuar con la configuración del Sincronizador de configuración y usar none como el tipo de autenticación. Por ejemplo, si tu imagen es pública y cualquier persona puede acceder a ella desde Internet, no necesitas autenticarte.

Sin embargo, la mayoría de los usuarios deben crear credenciales para acceder a imágenes restringidas. El Sincronizador de configuración admite los siguientes mecanismos de autenticación:

• k8sserviceaccountCuenta de servicio de Kubernetes
• Cuenta de servicio de Google (gcpserviceaccount)

• Cuenta de servicio predeterminada de Compute Engine (gcenode)

Cuenta de servicio de Kubernetes

Puedes usar una cuenta de servicio de Kubernetes como tu tipo de autenticación si almacenas tu imagen de OCI en Artifact Registry y tu clúster usa Workload Identity Federation for GKE o Workload Identity Federation for GKE de la flota.

1. Otorga el rol de IAM de lector de Artifact Registry (roles/artifactregistry.reader) a la cuenta de servicio de Kubernetes con el grupo de Workload Identity Federation for GKE. Para obtener más información sobre los roles y permisos de Artifact Registry, consulta Cómo configurar roles y permisos para Artifact Registry.

   • Otorga permisos en todo el proyecto si los mismos permisos se aplican a todos los repositorios del proyecto.

     gcloud projects add-iam-policy-binding PROJECT_ID \
           --role=roles/artifactregistry.reader \
           --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
     

   • Otorga permisos específicos del repositorio cuando desees que las cuentas de servicio tengan diferentes niveles de acceso para cada repositorio del proyecto.

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
        --project=PROJECT_ID
     

   Reemplaza lo siguiente:

   • PROJECT_ID: el ID del proyecto de la organización.
   • FLEET_HOST_PROJECT_ID: Si usas Workload Identity Federation for GKE de GKE, esto es lo mismo que PROJECT_ID. Si usas Workload Identity Federation for GKE de la flota para GKE, este es el ID del proyecto de la flota en la que está registrado tu clúster.
   • KSA_NAME: Es la cuenta de servicio de Kubernetes para el conciliador.
     • Para los repositorios raíz, si el nombre RootSync es root-sync, usa root-reconciler. De lo contrario, usa root-reconciler-ROOT_SYNC_NAME. Si instalas el Sincronizador de configuración con la consola de Google Cloud o Google Cloud CLI, el Sincronizador de configuración crea de forma automática un objeto RootSync llamadoroot-sync.
   • REPOSITORY: Es el ID del repositorio.
   • LOCATION: la ubicación regional o multirregional del repositorio.
   Nota: Para crear esta vinculación de política se requiere el permiso iam.serviceAccounts.setIamPolicy.

Cuenta de servicio predeterminada de Compute Engine

Si almacenas tu gráfico de Helm en Artifact Registry y tu clúster es de GKE con Workload Identity Federation for GKE inhabilitada, puedes usar gcenode como tu tipo de autenticación. El Sincronizador de configuración usa la cuenta de servicio predeterminada de Compute Engine. Debes otorgar a la cuenta de servicio predeterminada de Compute Engine acceso de lectura a Artifact Registry.

1. Otorga permiso de lectura a la cuenta de servicio de Compute Engine para Artifact Registry ejecutando el siguiente comando:

   gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:[e-mail] \
      --role=roles/artifactregistry.reader
   

   Reemplaza PROJECT_ID por el ID del proyecto de tu organización y PROJECT_NUMBER por el número del proyecto de tu organización.

Configura el Sincronizador de configuración para una autoridad certificadora

En el caso de los servidores configurados con certificados de una autoridad certificadora (AC) que aún no es de confianza, el Sincronizador de configuración se puede configurar para usar un certificado de AC para verificar las conexiones HTTPS al servidor. Esto es compatible con los servidores de Git, Helm o OCI. El certificado de CA debe incluir certificados SSL completos (raíz, intermedio y hoja). Si tu servidor ya usa una CA de confianza o no te conectas a través de HTTPS, puedes omitir este paso y dejar caCertSecretRef sin configurar.

RootSync

1. Recupera el certificado de CA que se usó para emitir el certificado de tu servidor de Git y guárdalo en un archivo.

2. En el caso de los objetos RootSync, el Secret debe crearse en el espacio de nombres config-management-system. Por ejemplo:

   kubectl create ns config-management-system && 
   
   kubectl create secret generic ROOT_CA_CERT_SECRET_NAME 
   
    --namespace=config-management-system 
   
    --from-file=cert=/path/to/CA_CERT_FILE
   

3. Cuando configures el Sincronizador de configuración, establece el valor del campo caCertSecretRef.name en el objeto RootSync como ROOT_CA_CERT_SECRET_NAME.

RepoSync

1. Recupera el certificado de CA que se usó para emitir el certificado de tu servidor de Git y guárdalo en un archivo.

2. En el caso de los objetos RepoSync, el Secret debe crearse en el mismo espacio de nombres que el RepoSync. Por ejemplo:

   kubectl create ns REPO_SYNC_NAMESPACE && 
   
   kubectl create secret generic NAMESPACE_CA_CERT_SECRET_NAME 
   
    --namespace=REPO_SYNC_NAMESPACE 
   
    --from-file=cert=/path/to/CA_CERT_FILE
   

3. Cuando configures el objeto RepoSync, establece el valor del campo caCertSecretRef.name en el objeto RepoSync como NAMESPACE_CA_CERT_SECRET_NAME.

Otorga acceso de solo lectura al Sincronizador de configuración a Helm

El Sincronizador de configuración necesita acceso de solo lectura a tu repositorio de Helm para que pueda leer los gráficos de Helm en tu repositorio y, luego, instalarlos en tus clústeres.

Si el repositorio no requiere autenticación para el acceso de solo lectura, puedes continuar con la configuración del Sincronizador de configuración y usar none como el tipo de autenticación. Por ejemplo, si tu repositorio de Helm es público y cualquier persona puede acceder a él desde Internet, no necesitas autenticarte.

Sin embargo, la mayoría de los usuarios deben crear credenciales para acceder a repositorios privados de Helm. El Sincronizador de configuración admite los siguientes mecanismos de autenticación:

• Token (token)
• k8sserviceaccountCuenta de servicio de Kubernetes
• Cuenta de servicio de Google (gcpserviceaccount)
• Cuenta de servicio predeterminada de Compute Engine (gcenode)

Nota: Sincronizador de configuración no admite la configuración de helm como el tipo de fuente con la consola de Google Cloud o Google Cloud CLI. Puedes configurar tu objeto RootSync o RepoSync para que se sincronice desde un repositorio de Helm con la API de Kubernetes, o declararlo en otra fuente de verdad. Consulta Configuración del repositorio de Helm para obtener más información.

Token

Crea un Secret con un nombre de usuario y una contraseña del repositorio de Helm:

kubectl create secret generic SECRET_NAME \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
    --from-literal=password=PASSWORD

Reemplaza lo siguiente:

• SECRET_NAME: el nombre que deseas darle a tu Secret.
• USERNAME: Es el nombre de usuario del repositorio de Helm.
• PASSWORD: Es la contraseña del repositorio de Helm.

Cuando configures el Sincronizador de configuración, usarás el nombre de Secret que elegiste para spec.helm.secretRef.name.

Cuenta de servicio de Kubernetes

Puedes usar una cuenta de servicio de Kubernetes como tu tipo de autenticación si almacenas tu gráfico de Helm en Artifact Registry y tu clúster usa Workload Identity Federation for GKE o Workload Identity Federation for GKE de la flota.

1. Otorga el rol de IAM de lector de Artifact Registry (roles/artifactregistry.reader) a la cuenta de servicio de Kubernetes con el grupo de Workload Identity Federation for GKE. Para obtener más información sobre los roles y permisos de Artifact Registry, consulta Cómo configurar roles y permisos para Artifact Registry.

   • Otorga permisos en todo el proyecto si los mismos permisos se aplican a todos los repositorios del proyecto.

     gcloud projects add-iam-policy-binding PROJECT_ID \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
     

   • Otorga permisos específicos del repositorio cuando desees que las cuentas de servicio tengan diferentes niveles de acceso para cada repositorio del proyecto.

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
        --project=PROJECT_ID
     

   Reemplaza lo siguiente:

   • PROJECT_ID: el ID del proyecto de la organización.
   • FLEET_HOST_PROJECT_ID: Si usas Workload Identity Federation for GKE de GKE, esto es lo mismo que PROJECT_ID. Si usas Workload Identity Federation for GKE de la flota para GKE, este es el ID del proyecto de la flota en la que está registrado tu clúster.
   • KSA_NAME: Es la cuenta de servicio de Kubernetes para el conciliador.
     • Para los repositorios raíz, si el nombre RootSync es root-sync, usa root-reconciler. De lo contrario, usa root-reconciler-ROOT_SYNC_NAME.
   • REPOSITORY: el ID del repositorio.
   • LOCATION: la ubicación regional o multirregional del repositorio.

Nota: Para crear esta vinculación de política se requiere el permiso iam.serviceAccounts.setIamPolicy.

Cuenta de servicio predeterminada de Compute Engine

Si almacenas tu gráfico de Helm en Artifact Registry y tu clúster es de GKE con Workload Identity Federation for GKE inhabilitada, puedes usar gcenode como tu tipo de autenticación. El Sincronizador de configuración usa la cuenta de servicio predeterminada de Compute Engine. Debes otorgar a la cuenta de servicio predeterminada de Compute Engine acceso de lectura a Artifact Registry. Es posible que debas otorgar el alcance de acceso storage-ro para otorgar permiso de solo lectura para extraer imágenes.

1. Otorga permiso de lectura a la cuenta de servicio de Compute Engine para Artifact Registry:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:[e-mail] \
       --role=roles/artifactregistry.reader
   

   Reemplaza PROJECT_ID por el ID del proyecto de tu organización y PROJECT_NUMBER por el número del proyecto de tu organización.

Configura Sincronizador de configuración

Para configurar la sincronización desde el repositorio raíz, debes crear un objeto RootSync que sincronice el repositorio raíz con el clúster. Solo puedes crear un repositorio raíz por clúster, y el repositorio raíz puede ser un repositorio no estructurado o un repositorio jerárquico.

1. Si usas el webhook de admisión del Sincronizador de configuración (el webhook de admisión está inhabilitado de forma predeterminada) y, luego, instalas el Sincronizador de configuración en un clúster privado, agrega una regla de firewall para permitir el puerto 10250. El webhook de admisión del Sincronizador de configuración usa el puerto 10250 para la prevención de desvíos.

2. Espera a que las CRD de RootSync y RepoSync estén disponibles:

   until kubectl get customresourcedefinitions rootsyncs.configsync.gke.io reposyncs.configsync.gke.io; do date; sleep 1; echo ""; done
   

3. Guarda uno de los siguientes manifiestos como root-sync.yaml. Usa la versión del manifiesto que corresponda al tipo de fuente de tus configuraciones.

   Git

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: git
     sourceFormat: ROOT_FORMAT
     git:
       repo: ROOT_REPOSITORY
       revision: ROOT_REVISION
       branch: ROOT_BRANCH
       dir: ROOT_DIRECTORY
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
       secretRef:
         name: ROOT_SECRET_NAME
       noSSLVerify: ROOT_NO_SSL_VERIFY
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   Reemplaza lo siguiente:

   • ROOT_SYNC_NAME: Agrega el nombre de tu objeto RootSync.
   • ROOT_FORMAT: agrega unstructured para usar un repositorio no estructurado o agrega hierarchy a fin de usar un repositorio jerárquico. Estos valores distinguen entre mayúsculas y minúsculas. Este campo es opcional y el valor predeterminado es hierarchy. Te recomendamos que agregues unstructured, ya que este formato te permite organizar la configuración de la manera que te resulte más conveniente.
   • ROOT_REPOSITORY: agrega la URL del repositorio de Git para usarlo como repositorio raíz. Puedes ingresar las URL con el protocolo HTTPS o SSH. Por ejemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa el protocolo HTTPS. Este campo es obligatorio.
   • ROOT_REVISION: Agrega la revisión de Git (etiqueta o hash) o la rama desde la que se realizará la sincronización. Este campo es opcional y el valor predeterminado es HEAD. Cuando se usa un hash, debe ser un hash completo, no una forma abreviada.
   • ROOT_BRANCH: Agrega la rama del repositorio desde la que se realiza la sincronización. Este campo es opcional y el valor predeterminado es master. Recomendamos usar el campo revision para especificar un nombre de rama para simplificar el proceso. Si se especifican el campo revision y el campo branch, revision tiene prioridad sobre branch.
   • ROOT_DIRECTORY: agrega la ruta de acceso en el repositorio de Git al directorio raíz que contiene la configuración con la que deseas sincronizar. Este campo es opcional y el predeterminado es el directorio raíz (/) del repositorio.

   • ROOT_AUTH_TYPE: Agrega uno de los siguientes tipos de autenticación:

     • none: No usa autenticación
     • ssh: Usa un par de claves SSH
     • cookiefile: Usa un objeto cookiefile
     • token: Usa un token
     • gcpserviceaccount: Usa una cuenta de servicio de Google para acceder a Cloud Source Repositories.
     • gcenode: Usa una cuenta de servicio de Google para acceder a Cloud Source Repositories. Selecciona esta opción solo si la Workload Identity Federation for GKE no está habilitada en tu clúster.

     Para obtener más información sobre estos tipos de autenticación, consulta Otorga a Git acceso de solo lectura al Sincronizador de configuración.

     Este campo es obligatorio.

   • ROOT_EMAIL: Si agregaste gcpserviceaccount como tu ROOT_AUTH_TYPE, agrega la dirección de correo electrónico de la cuenta de servicio de Google. Por ejemplo, acm@PROJECT_ID.iam.gserviceaccount.com

   • ROOT_SECRET_NAME: agrega el nombre del secreto. Si se configura este campo, debes agregar la clave pública del Secret al proveedor de Git. Este campo es opcional.

   • ROOT_NO_SSL_VERIFY: Para inhabilitar la verificación del certificado SSL, establece este campo en true. El valor predeterminado es false.

   • ROOT_CA_CERT_SECRET_NAME: agrega el nombre del secreto. Si se configura este campo, tu proveedor de Git debe usar un certificado emitido por esta autoridad certificadora (CA). El secreto debe contener el certificado de la AC en una clave llamada cert. Este campo es opcional.

     Para obtener más información sobre cómo configurar el objeto secreto para el certificado de la AC, consulta Cómo configurar la AC.

   Para obtener una explicación de los campos y una lista completa de los campos que puedes agregar al campo spec, consulta Campos de RootSync.

   Mediante este manifiesto, se crea un objeto RootSync que usa Git como fuente.

   OCI

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: oci
     sourceFormat: ROOT_FORMAT
     oci:
       image: ROOT_IMAGE
       dir: ROOT_DIRECTORY
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   Reemplaza lo siguiente:

   • ROOT_SYNC_NAME: Agrega el nombre de tu objeto RootSync.
   • ROOT_FORMAT: agrega unstructured para usar un repositorio no estructurado o agrega hierarchy a fin de usar un repositorio jerárquico. Estos valores distinguen entre mayúsculas y minúsculas. Este campo es opcional y el valor predeterminado es hierarchy. Te recomendamos que agregues unstructured, ya que este formato te permite organizar la configuración de la manera que te resulte más conveniente.
   • ROOT_IMAGE: URL de la imagen de OCI que se usa como repositorio raíz, por ejemplo, LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. De forma predeterminada, la imagen se extrae de la etiqueta latest, pero puedes extraer imágenes mediante TAG o DIGEST. Especifica TAG o DIGEST en el PACKAGE_NAME:
     • Para extraer antes del TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • Para extraer antes del DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST

   Precaución: El Sincronizador de configuración requiere que la capa OCI esté comprimida en tar o tar+gzip. El Sincronizador de configuración no reconocerá otros formatos (por ejemplo, tar+bz2). Si cambias de un REPO válido a una imagen de OCI con un formato no compatible, los recursos administrados se reducirán sin errores.

   • ROOT_DIRECTORY: agrega la ruta de acceso en el repositorio al directorio raíz que contiene la configuración con la que deseas sincronizar. Este campo es opcional y el predeterminado es el directorio raíz (/) del repositorio.

   • ROOT_AUTH_TYPE: Agrega uno de los siguientes tipos de autenticación:

     • none: No usa autenticación
     • gcenode: Usa la cuenta de servicio predeterminada de Compute Engine para acceder a una imagen en Artifact Registry. Selecciona esta opción solo si la Workload Identity Federation for GKE no está habilitada en tu clúster.
     • gcpserviceaccount: Usa una cuenta de servicio de Google para acceder a una imagen.

     Este campo es obligatorio.

   • ROOT_EMAIL: Si agregaste gcpserviceaccount como tu ROOT_AUTH_TYPE, agrega la dirección de correo electrónico de la cuenta de servicio de Google. Por ejemplo, acm@PROJECT_ID.iam.gserviceaccount.com

   • ROOT_CA_CERT_SECRET_NAME: agrega el nombre del secreto. Si se configura este campo, tu proveedor de OCI debe usar un certificado emitido por esta autoridad certificadora (CA). El secreto debe contener el certificado de la AC en una clave llamada cert. Este campo es opcional.

   Para obtener más información sobre cómo configurar el objeto secreto para el certificado de la AC, consulta Cómo configurar la AC.

   Para obtener una explicación de los campos y una lista completa de los campos que puedes agregar al campo spec, consulta Campos de RootSync.

   Mediante este manifiesto, se crea un objeto RootSync que usa una imagen de OCI como fuente.

   Helm

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: helm
     sourceFormat: ROOT_FORMAT
     helm:
       repo: ROOT_HELM_REPOSITORY
       chart: HELM_CHART_NAME
       version: HELM_CHART_VERSION
       releaseName: HELM_RELEASE_NAME
       namespace: HELM_RELEASE_NAMESPACE
       values:
         foo:
           bar: VALUE_1
         baz:
         - qux: VALUE_2
           xyz: VALUE_3
       includeCRDs: HELM_INCLUDE_CRDS
       auth: ROOT_AUTH_TYPE
         gcpServiceAccountEmail: ROOT_EMAIL
         secretRef:
           name: ROOT_SECRET_NAME
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   Reemplaza lo siguiente:

   • ROOT_SYNC_NAME: Agrega el nombre de tu objeto RootSync.
   • ROOT_FORMAT: agrega unstructured para usar un repositorio no estructurado o agrega hierarchy a fin de usar un repositorio jerárquico. Estos valores distinguen entre mayúsculas y minúsculas. Este campo es opcional y el valor predeterminado es hierarchy. Te recomendamos que agregues unstructured, ya que este formato te permite organizar la configuración de la manera que te resulte más conveniente.
   • ROOT_HELM_REPOSITORY: Es la URL del repositorio de Helm que se usará como repositorio raíz. Puedes ingresar las URL con el protocolo HTTPS o SSH. Por ejemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa el protocolo HTTPS. Este campo es obligatorio.
   • HELM_CHART_NAME: Agrega el nombre de tu gráfico de Helm. Este campo es obligatorio.
   • HELM_CHART_VERSION: Es la versión del gráfico. Este campo es opcional. Si no se especifica ningún valor, se usa la versión más reciente.
   • HELM_RELEASE_NAME: Es el nombre de la versión de Helm. Este campo es opcional.
   • HELM_RELEASE_NAMESPACE: Es el espacio de nombres de destino para una versión. Solo establece un espacio de nombres para los recursos que contienen namespace: {{ .Release.Namespace }} en sus plantillas. Este campo es opcional. Si no se especifica ningún valor, se usa el espacio de nombres predeterminado config-management-system.
   • HELM_INCLUDE_CRDS: Se establece en true si deseas que la plantilla de Helm también genere una CustomResourceDefinition. Este campo es opcional. Si no se especifica ningún valor, el valor predeterminado es false y no se generará ningún CRD.
   • VALUE: valores para usar en lugar de valores predeterminados que acompañan al gráfico de Helm Formatea este campo de la misma manera que el archivo values.yaml de la tabla de Helm. Este campo es opcional.

   • ROOT_AUTH_TYPE: Agrega uno de los siguientes tipos de autenticación:

     • none: No usa autenticación
     • token: Usa un nombre de usuario y una contraseña para acceder a un repositorio de Helm privado.
     • gcenode: Usa la cuenta de servicio predeterminada de Compute Engine para acceder a una imagen en Artifact Registry. Selecciona esta opción solo si la Workload Identity Federation for GKE no está habilitada en tu clúster.
     • gcpserviceaccount: Usa una cuenta de servicio de Google para acceder a una imagen.

     Este campo es obligatorio.

   • ROOT_EMAIL: Si agregaste gcpserviceaccount como tu ROOT_AUTH_TYPE, agrega la dirección de correo electrónico de la cuenta de servicio de Google. Por ejemplo, acm@PROJECT_ID.iam.gserviceaccount.com

   • ROOT_SECRET_NAME: Agrega el nombre de tu secreto si token es el ROOT_AUTH_TYPE. Este campo es opcional.

   • ROOT_CA_CERT_SECRET_NAME: agrega el nombre del secreto. Si se configura este campo, tu proveedor de Helm debe usar un certificado emitido por esta autoridad certificadora (CA). El secreto debe contener el certificado de la AC en una clave llamada cert. Este campo es opcional.

   Para obtener más información sobre cómo configurar el objeto secreto para el certificado de la AC, consulta Cómo configurar la AC.

   Para obtener una explicación de los campos y una lista completa de los campos que puedes agregar al campo spec, consulta Campos de RootSync.

   Mediante este manifiesto, se crea un objeto RootSync que usa Helm como fuente.

4. Aplica los cambios:

   kubectl apply -f root-sync.yaml
   

Verifica el estado de sincronización del repositorio raíz

Puedes usar el comando nomos status para inspeccionar el estado de sincronización del repositorio raíz:

nomos status

Deberías ver un resultado similar al siguiente:

my_managed_cluster-1
  --------------------
  <root>   [e-mail]:foo-corp/acme/admin@main
  SYNCED   f52a11e4

Verifica la instalación de RootSync

Cuando creas un objeto RootSync, el Sincronizador de configuración crea un conciliador con el prefijo root-reconciler. Un conciliador es un Pod que se implementa como una implementación. Sincroniza los manifiestos de un repositorio de Git a un clúster.

Para verificar que el objeto RootSync funcione de forma correcta, verifica el estado del Deployment del conciliador raíz:

kubectl get -n config-management-system deployment \
    -l configsync.gke.io/sync-name=ROOT_SYNC_NAME

Reemplaza ROOT_SYNC_NAME por el nombre de RootSync.

Deberías ver un resultado similar al siguiente:

NAME              READY   UP-TO-DATE   AVAILABLE   AGE
root-reconciler   1/1     1            1           3h42m

Para conocer más formas de explorar el estado de tu objeto RootSync, consulta Supervisa los objetos RootSync y RepoSync.

Una vez que hayas terminado de configurar tu repositorio raíz, puedes optar por configurar la sincronización desde varios repositorios. Estos repositorios son útiles si deseas un repositorio que contenga archivos de configuración con alcance de espacio de nombres sincronizados con un espacio de nombres en particular en todos los clústeres.

Actualiza el Sincronizador de configuración

Los pasos para actualizar el Sincronizador de configuración dependen de las versiones desde las que actualizas y a las que actualizas. A partir de la versión 1.20.0, el Sincronizador de configuración se proporciona como una instalación independiente sin el operador de ConfigManagement. Si actualizas de una versión anterior a la 1.20.0 a la versión 1.20.0 o posterior, primero debes desinstalar el operador de ConfigManagement antes de actualizar.

Si actualizas desde una versión no compatible, debes realizar una actualización paso a paso con incrementos de no más de tres versiones secundarias a la vez. Por ejemplo, si la versión actual del Sincronizador de configuración es 1.14.0, primero actualiza a la versión 1.17.0 y, luego, a la versión 1.20.0.

Desinstala el operador de ConfigManagement

Si actualizas de una versión anterior a la 1.20.0 a la versión 1.20.0 o posterior, primero debes desinstalar el operador de ConfigManagement antes de actualizar.

Para verificar si Config Management está instalado en tu clúster, ejecuta el siguiente comando:

kubectl get configmanagement

Si el resultado no está vacío, Config Management está instalado en el clúster. Para desinstalar Config Management, completa los siguientes pasos, pero deja instalado Sincronizador de configuración en el clúster. Te recomendamos que uses nomos CLI para desinstalar el operador de ConfigManagement, ya que tiene una interfaz más completa y un manejo de errores más sólido. Solo debes usar la secuencia de comandos de shell si no tienes acceso a nomos CLI.

Precaución: Asegúrate de que Hierarchy Controller esté inhabilitado antes de continuar.

nomos (recomendado)

1. Asegúrate de que la CLI de nomos tenga la versión más reciente.

2. Ejecuta el siguiente comando para actualizar el clúster en tu contexto actual de kubectl:

   nomos migrate --remove-configmanagement
   

secuencia de comandos de shell

Copia la siguiente secuencia de comandos de shell en un archivo y, luego, ejecútala para actualizar el clúster en tu contexto actual de kubectl.

 #!/bin/bash

 set -euox pipefail

 hnc_enabled="$(kubectl get configmanagements.configmanagement.gke.io config-management -o=jsonpath="{.spec.hierarchyController.enabled}" --ignore-not-found)"

 if [[ "${hnc_enabled}" == "true" ]]; then
   echo "Hierarchy Controller is enabled on the ConfigManagement object. It must be disabled before migrating."
   echo "This can be done by unsetting the spec.hierarchyController field on ConfigManagement."
   exit 1
 fi

 kubectl delete deployment -n config-management-system config-management-operator --ignore-not-found --cascade=foreground

 if kubectl get configmanagement config-management &> /dev/null ; then
   kubectl patch configmanagement config-management --type="merge" -p '{"metadata":{"finalizers":[]}}'
   kubectl delete configmanagement config-management --cascade=orphan --ignore-not-found
 fi

 kubectl delete clusterrolebinding config-management-operator --ignore-not-found
 kubectl delete clusterrole config-management-operator --ignore-not-found
 kubectl delete serviceaccount -n config-management-system config-management-operator --ignore-not-found
 kubectl delete customresourcedefinition configmanagements.configmanagement.gke.io --ignore-not-found

Instala la nueva versión del Sincronizador de configuración

Para actualizar el Sincronizador de configuración, completa los siguientes pasos para cada clúster inscrito:

1. Descarga el manifiesto del Sincronizador de configuración y los comandos nomos para la versión nueva.

2. Extrae el archivo:

   tar -xzvf config-sync.tar.gz

3. En el archivo que extrajiste en el paso anterior, sigue las instrucciones del archivo README.md proporcionado para editar la personalización.

   Nota: Se requiere editar el kustomization.yaml para algunos parámetros de configuración, por ejemplo, establecer un nombre de clúster para usarlo con un ClusterSelector o incluir el archivo admission-webhook.yaml para usarlo con la prevención de desvíos.

4. Para actualizar la instalación del Sincronizador de configuración, aplica el manifiesto renderizado que compilaste siguiendo las instrucciones de README.md:

   kubectl apply -f CONFIG_SYNC_MANIFEST
   

   Reemplaza CONFIG_SYNC_MANIFEST por el nombre del manifiesto renderizado.

5. Reemplaza el comando nomos en todos los clientes con la versión nueva. Este cambio garantiza que el comando nomos siempre pueda obtener el estado de todos los clústeres inscritos y validar los archivos de configuración para ellos.

Desinstala el Sincronizador de configuración

Precaución: Borrar un objeto RootSync o RepoSync no borra las anotaciones y etiquetas del Sincronizador de configuración, y el webhook de admisión del Sincronizador de configuración rechazaría las solicitudes de eliminación de estos recursos si el Sincronizador de configuración aún está habilitado en el clúster. La solución alternativa es dejar de administrar o borrar estos recursos administrados antes de borrar el objeto RootSync o RepoSync correspondiente.

Para desinstalar el Sincronizador de configuración, completa los siguientes pasos:

1. Un administrador central debe quitar el repositorio raíz:

   1. Si habilitaste el webhook y quieres conservar tus recursos, inhabilita la prevención de desvíos para recursos abandonados. Si no habilitaste el webhook, no tienes que realizar ningún paso adicional para conservar tus recursos.

   2. Borra el objeto RootSync mediante la ejecución del siguiente comando:

      kubectl delete -f root-sync.yaml
      

2. Quita los repositorios.

3. Con los manifiestos que usaste para instalar el Sincronizador de configuración, también puedes desinstalarlo.

      kubectl delete -f CONFIG_SYNC_MANIFEST --ignore-not-found
   

Nota: La inhabilitación de esta función no afecta ninguna configuración que el Sincronizador de configuración haya aplicado antes a tus clústeres.

¿Qué sigue?

• Descubre cómo configurar la sincronización desde varios repositorios.