Instalar Config Sync manualmente con kubectl (no recomendado)

En esta página se explica cómo instalar Config Sync con comandos kubectl.

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

Antes de empezar

En esta sección se describen los requisitos que debes cumplir antes de instalar Config Sync con kubectl.

Preparar el entorno local

Antes de instalar Config Sync, asegúrate de que has preparado tu entorno local completando las siguientes tareas:

• Crear o tener acceso a una fuente de información veraz.

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

• kubectl no está instalado de forma predeterminada en la CLI de Google Cloud. Para instalar kubectl, usa el siguiente comando:

  gcloud components install kubectl
  

• Autentícate en Google Cloud con el comando gcloud auth login para poder descargar componentes de Config Sync.

Preparar los clústeres

Crea un clúster de Google Kubernetes Engine o ten acceso a uno que cumpla los requisitos de Config Sync.

Preparar permisos

El Google Cloud usuario que instala Config Sync necesita permisos de gestión de identidades y accesos para crear nuevos roles en tu clúster. Si es necesario, asigna estos roles con los siguientes comandos:

gcloud container clusters get-credentials CLUSTER_NAME

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

Haz los cambios siguientes:

• CLUSTER_NAME: el nombre de tu clúster
• USER_ACCOUNT: la dirección de correo de tu cuenta Google Cloud

En función de cómo hayas configurado Google Cloud CLI en tu sistema local, puede que tengas que añadir los campos --project y --zone.

Si necesitas conceder acceso a Config Sync a OCI con gcpserviceaccount como tipo de autenticación, para crear un enlace de política, también debes tener el permiso iam.serviceAccounts.setIamPolicy. Para obtener este permiso, asigna el rol de gestión de identidades y accesos Administrador de cuentas de servicio (roles/iam.serviceAccountAdmin). También puedes obtener este permiso con roles personalizados u otros roles predefinidos.

Para obtener más información sobre cómo conceder roles, consulta el artículo sobre cómo gestionar el acceso.

Registrar un clúster

Para registrar un clúster en Config Sync, sigue estos pasos:

1. Implementar Config Sync
2. Concede acceso de solo lectura de Config Sync a una de las siguientes opciones:
   • Git
   • OCI
   • Timón
3. Configurar Config Sync

Desplegar Config Sync

Después de asegurarte de que cumples todos los requisitos previos, puedes implementar Config Sync descargando y aplicando un manifiesto YAML:

1. Descarga la versión más reciente de los manifiestos de Config Sync con el siguiente comando. Para descargar una versión específica, consulta la sección 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 has extraído en el paso anterior, sigue las instrucciones del archivo README.md proporcionado para editar la personalización.

4. Para actualizar la instalación de Config Sync, aplica el manifiesto renderizado que has creado siguiendo las README.md instrucciones:

   kubectl apply -f CONFIG_SYNC_MANIFEST
   

   Sustituye CONFIG_SYNC_MANIFEST por el nombre del archivo de manifiesto renderizado.

5. Sustituye el comando nomos en todos los clientes por la nueva versión. Con este cambio, el comando nomos siempre podrá obtener el estado de todos los clústeres registrados y validar sus configuraciones.

Si se produce un error debido a un problema con Config Sync que no se debe a un error de sintaxis de YAML o JSON, el objeto se puede crear en el clúster, pero es posible que no funcione correctamente. En esta situación, puedes usar el comando nomos status para comprobar 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 el estado NOT CONFIGURED y muestra 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. En función del tipo de error, es posible que tengas que volver a aplicar el manifiesto de Config Sync al clúster.

Si el problema es que has olvidado crear el git-creds secreto, Config Sync lo detectará en cuanto lo crees y no tendrás que volver a aplicar la configuración.

Conceder acceso de solo lectura a Config Sync

Si almacenas tus configuraciones en Git, debes conceder a Config Sync acceso de solo lectura a Git. Si almacenas tus configuraciones como imágenes de OCI, debes conceder a Config Sync acceso de solo lectura a OCI. Si almacenas tus configuraciones en Helm, debes conceder a Config Sync acceso de solo lectura a Helm.

Conceder acceso de solo lectura a Git a Config Sync

Config Sync necesita acceso de solo lectura a tu repositorio de Git para poder leer las configuraciones confirmadas en el repositorio y aplicarlas a tus clústeres.

Si no es necesario autenticarse en tu repositorio para el acceso de solo lectura, puedes seguir configurando Config Sync y usar none como tipo de autenticación. Por ejemplo, si puedes consultar el repositorio mediante una interfaz web sin iniciar sesión o si puedes usar git clone para crear un clon del repositorio localmente sin proporcionar credenciales o usar credenciales guardadas, no necesitas autenticarte. En este caso, no es necesario que crees un secreto.

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

Config Sync admite los siguientes mecanismos de autenticación:

• Par de claves SSH (ssh)
• Cookiefile (cookiefile)
• Token (token)
• Cuenta de servicio de Google (gcpserviceaccount)
• Cuenta de servicio predeterminada de Compute Engine (gcenode)
• Aplicación GitHub (githubapp)

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

Para usar un repositorio de Cloud Source Repositories como repositorio de Config Sync, sigue estos pasos para obtener la URL de Cloud Source Repositories:

1. Mostrar todos los repositorios:

   gcloud source repos list
   

2. En el resultado, copia la URL del repositorio que quieras usar. 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 Config Sync en la sección siguiente. Si configuras Config Sync mediante la consola, añade la URL en el campo URL.Google Cloud Si configuras Config Sync con la CLI de Google Cloud, debes añadir la URL al campo syncRepo de tu 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. La clave pública suele tener la extensión .pub.

Advertencia: Protege los archivos creados con este comando. Permiten leer tu repositorio.

Para usar un par de claves SSH, sigue estos pasos:

1. Crea un par de claves SSH para permitir que Config Sync se autentique en tu repositorio de Git. Este paso es necesario si necesitas autenticarte en el repositorio para clonarlo o leerlo. Sáltate 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, en función de tus requisitos de seguridad y cumplimiento.

   El siguiente comando crea una clave RSA de 4096 bits. No se recomiendan valores inferiores:

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

   Haz los cambios siguientes:

   • GIT_REPOSITORY_USERNAME: el nombre de usuario que quieres que use Config Sync para autenticarse en el repositorio
   • /path/to/KEYPAIR_FILENAME: ruta al par de claves

   Si usas un host de repositorios de Git de terceros, como GitHub, o quieres usar una cuenta de servicio con Cloud Source Repositories, te recomendamos que uses una cuenta independiente.

   Nota: Debes crear la clave SSH sin una contraseña. Config Sync no admite contraseñas de claves SSH.

2. Configura el repositorio para que reconozca la clave pública recién creada. Consulta la documentación de tu proveedor de alojamiento de Git. Para tu comodidad, se incluyen instrucciones para algunos proveedores de alojamiento de Git populares:

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

3. Añade la clave privada a un nuevo secreto en el 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
   

   Sustituye /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 comprobación de hosts conocidos mediante la autenticación SSH, puedes añadir la clave de hosts conocidos al campo data.known_hosts del secreto git_creds. Para inhabilitar la comprobación de known_hosts, puedes quitar el campo known_hosts del secreto. Para añadir la clave de hosts conocidos, ejecuta el siguiente comando:

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

   A continuación, en data, añade la entrada de hosts conocidos:

   known_hosts: KNOWN_HOSTS_KEY
   

5. Elimina la clave privada del disco local o toma medidas para protegerla.

6. Cuando configures Config Sync y añadas la URL de tu repositorio de Git, utiliza el protocolo SSH. Si utilizas un repositorio en Cloud Source Repositories, debes usar el siguiente formato al introducir la URL:

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

   Haz los cambios siguientes:

   • EMAIL: tu Google Cloud nombredeusuario
   • PROJECT_ID: ID del proyecto Google Cloud en el que se encuentra el repositorio
   • REPO_NAME: el nombre del repositorio

Cookiefile

Nota: Las credenciales de cookiefile solo se pueden usar con Cloud Source Repositories. Si quieres usar GitHub con la autenticación cookiefile, puedes usar Cloud Source Repositories para replicar tu repositorio de GitHub.

El proceso para adquirir un cookiefile depende de la configuración de tu repositorio. Por ejemplo, consulta el artículo sobre cómo generar credenciales estáticas en la documentación de Cloud Source Repositories. Normalmente, las credenciales se almacenan en el archivo .gitcookies de tu directorio principal. También es posible que las ofrezca un administrador de seguridad.

Para usar un cookiefile, sigue estos pasos:

1. Después de crear y obtener el cookiefile, añádelo a un nuevo secreto en el clúster.

   Si no usas un proxy HTTPS, crea el secreto 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, añádelo al secreto junto con cookiefile ejecutando 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 \
    --from-literal=https_proxy=HTTPS_PROXY_URL
   

   Haz los cambios siguientes:

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

2. Si aún necesitas el contenido de cookiefile de forma local, protégelo. De lo contrario, elimínalo.

Token

Si tu organización no permite usar claves SSH, puedes utilizar un token. Con Config Sync, puedes usar como token los tokens de acceso personal (PATs) de GitHub, los PATs o las claves de implementación de GitLab, o la contraseña de aplicación de Bitbucket.

Para crear un secreto a partir de un token, sigue estos pasos:

1. Crea un token con GitHub, GitLab o Bitbucket:

   • GitHub: crea un token de acceso personal. Concede al token el permiso repo para que pueda leer desde repositorios privados. Como el token de acceso personal se vincula a una cuenta de GitHub, te recomendamos que crees un usuario de máquina y vincules tu token de acceso personal a él.
   • GitLab crea un token de acceso personal o crea un token de implementación.
   • Bitbucket: crea una contraseña de aplicación.

2. Después de crear y obtener el token, añádelo a un nuevo secreto en el clúster.

   Si no usas un proxy HTTPS, crea el secreto 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
   

   Haz los cambios siguientes:

   • USERNAME: el nombre de usuario que quieras usar.
   • TOKEN: el token que has creado en el paso anterior.

   Si necesitas usar un proxy HTTPS, añádelo al secreto junto con username y token ejecutando 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 \
    --from-literal=https_proxy=HTTPS_PROXY_URL
   

   Haz los cambios siguientes:

   • USERNAME: el nombre de usuario que quieras usar.
   • TOKEN: el token que has creado en el paso anterior.
   • HTTPS_PROXY_URL: la URL del proxy HTTPS que usas al comunicarte con el repositorio de Git.
   Nota: No recomendamos usar un proxy HTTP por motivos de seguridad.

3. Si aún necesitas el token de forma local, protégelo. De lo contrario, elimínalo.

Cuenta de servicio de Google

Si tu repositorio está en Cloud Source Repositories o en Secure Source Manager y tu clúster usa Federación de identidades de carga de trabajo de GKE para GKE o Federación de identidades de carga de trabajo de la flota para GKE, puedes concederle a Config Sync acceso a un repositorio que esté en el mismo proyecto que tu clúster gestionado mediante una cuenta de servicio de Google.

1. Si aún no tienes una cuenta de servicio, crea una.

2. Concede los roles de gestión de identidades y accesos correctos a la cuenta de servicio para que pueda acceder al repositorio:

   Cloud Source Repositories

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

   • Concede 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"
     

   • Concede permisos específicos de repositorio cuando quieras que las cuentas de servicio tengan diferentes niveles de acceso para cada repositorio de tu proyecto.

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

   Secure Source Manager

   Concede los roles de IAM 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 Gestión de roles de repositorio.

   • Concede 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 conceder permisos específicos de un repositorio, puedes usar la interfaz web de Secure Source Manager del repositorio. Para obtener más información, consulta Conceder roles a nivel de repositorio a los usuarios.

3. Si configuras Config Sync mediante la Google Cloud consola, selecciona Federación de identidades de cargas de trabajo para GKE como Tipo de autenticación y, a continuación, añade el correo de tu cuenta de servicio.

   Si configuras Config Sync con la CLI de Google Cloud, añade gcpserviceaccount como secretType y, a continuación, añade la dirección de correo de tu cuenta de servicio a gcpServiceAccountEmail.

4. Si usas un repositorio en Secure Source Manager, debes usar el siguiente formato al configurar Config Sync y añadir la URL de tu repositorio de Git:

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

   Haz los cambios siguientes:

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

5. Después de configurar Config Sync, crea un enlace de política de gestión de identidades y accesos entre la cuenta de servicio de Kubernetes y la cuenta de servicio de Google. La cuenta de servicio de Kubernetes no se crea hasta que configuras Config Sync por primera vez.

   Si usas clústeres registrados en una flota, solo tienes que crear el enlace de la 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 igualdad de la flota, si añades la política de gestión de identidades y accesos 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 de la misma flota también obtendrá la misma política de gestión de identidades y accesos.

   Este enlace permite que la cuenta de servicio de Kubernetes de Config Sync actúe 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
   

Haz los cambios siguientes:

• PROJECT_ID: el ID del proyecto de la organización.
• FLEET_HOST_PROJECT_ID: si usas GKE Workload Identity Federation for GKE, es lo mismo que PROJECT_ID. Si usas la federación de identidades de carga de trabajo de flota para GKE, este es el ID del proyecto de la flota en la que está registrado tu clúster.
• GSA_NAME: la cuenta de servicio de Google personalizada que quieres usar para conectarte a Artifact Registry. La cuenta de servicio debe tener el rol de gestión de identidades y accesos Lector de Artifact Registry (roles/artifactregistry.reader).
• KSA_NAME: la cuenta de servicio de Kubernetes del reconciliador.
  • En el caso de los repositorios raíz, si el nombre de RootSync es root-sync, usa root-reconciler. De lo contrario, usa root-reconciler-ROOT_SYNC_NAME. Si instalas Config Sync mediante la consola o la CLI de Google Cloud, Config Sync crea automáticamente un objeto RootSync llamado root-sync. Google Cloud
• REPOSITORY: el nombre del repositorio.
• POLICY_FILE: el archivo JSON o YAML con la política de gestión de identidades y accesos.

Nota: Para crear esta vinculación de política, se necesita 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 inhabilitado, puedes usar gcenode como tipo de autenticación.

Si configuras Config Sync mediante la Google Cloud consola, selecciona Repositorio de Google Cloud como Tipo de autenticación.

Si configuras Config Sync con la CLI de Google Cloud, añade gcenode como secretType.

Si seleccionas Repositorio de Google Cloud o gcenode, podrás usar la cuenta de servicio predeterminada de Compute Engine. Debes conceder el rol de gestión de identidades y accesos 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 Conceder permisos para ver repositorios.

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

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

Aplicación de GitHub

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

Para usar una aplicación de GitHub, sigue estos pasos:

1. Sigue las instrucciones de GitHub para aprovisionar una aplicación de GitHub y darle permiso para leer tu repositorio.

2. Añade la configuración de la aplicación de GitHub a un nuevo secreto en el clúster:

   Usar 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
   

   • Sustituye CLIENT_ID por el ID de cliente de la aplicación de GitHub.
   • Sustituye INSTALLATION_ID por el ID de instalación de la aplicación GitHub.
   • Sustituye /path/to/GITHUB_PRIVATE_KEY por el nombre del archivo que contiene la clave privada.
   • Sustituye BASE_URL por la URL base del endpoint de la 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.

   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
   

   • Sustituye APPLICATION_ID por el ID de la aplicación de GitHub.
   • Sustituye INSTALLATION_ID por el ID de instalación de la aplicación GitHub.
   • Sustituye /path/to/GITHUB_PRIVATE_KEY por el nombre del archivo que contiene la clave privada.
   • Sustituye BASE_URL por la URL base del endpoint de la 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. Elimina la clave privada del disco local o toma medidas para protegerla.

4. Cuando configures Config Sync y añadas la URL de tu repositorio de Git, usa el tipo de autenticación githubapp.

Conceder acceso de solo lectura de Config Sync a OCI

Config Sync necesita acceso de solo lectura a la imagen OCI almacenada en Artifact Registry para poder leer las configuraciones incluidas en la imagen y aplicarlas a tus clústeres.

Si no es necesario autenticarse en tu imagen para el acceso de solo lectura, puedes seguir configurando Config Sync y usar none como tipo de autenticación. Por ejemplo, si tu imagen es pública y cualquier usuario de Internet puede acceder a ella, no es necesario que te autentiques.

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

• Cuenta de servicio de Kubernetes (k8sserviceaccount)
• 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 tipo de autenticación si almacenas tu imagen OCI en Artifact Registry y tu clúster usa Workload Identity Federation para GKE o Workload Identity Federation para GKE de una flota.

1. Concede el rol de gestión de identidades y accesos Lector de Artifact Registry (roles/artifactregistry.reader) a la cuenta de servicio de Kubernetes con el grupo de federación de Workload Identity para GKE. Para obtener más información sobre los roles y permisos de Artifact Registry, consulta Configurar roles y permisos de Artifact Registry.

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

   • Concede permisos específicos de repositorio cuando quieras que las cuentas de servicio tengan diferentes niveles de acceso para cada repositorio de tu 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
     

   Haz los cambios siguientes:

   • PROJECT_ID: el ID del proyecto de la organización.
   • FLEET_HOST_PROJECT_ID: si usas GKE Workload Identity Federation for GKE, es lo mismo que PROJECT_ID. Si usas la federación de identidades de carga de trabajo de flota para GKE, este es el ID del proyecto de la flota en la que está registrado tu clúster.
   • KSA_NAME: la cuenta de servicio de Kubernetes del reconciliador.
     • En el caso de los repositorios raíz, si el nombre de RootSync es root-sync, usa root-reconciler. De lo contrario, usa root-reconciler-ROOT_SYNC_NAME. Si instalas Config Sync mediante la consola o la CLI de Google Cloud, Config Sync crea automáticamente un objeto RootSync llamado root-sync. Google Cloud
   • REPOSITORY: el ID del repositorio.
   • LOCATION: la ubicación regional o multirregional del repositorio.
   Nota: Para crear esta vinculación de política, se necesita 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 inhabilitado, puedes usar gcenode como tipo de autenticación. Config Sync usa la cuenta de servicio predeterminada de Compute Engine. Debes conceder acceso de lectura a Artifact Registry a tu cuenta de servicio predeterminada de Compute Engine.

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

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

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

Configurar Config Sync para una autoridad de certificación

En el caso de los servidores configurados con certificados de una autoridad de certificación (CA) que aún no sea de confianza, Config Sync se puede configurar para que use un certificado de CA con el fin de verificar las conexiones HTTPS al servidor. Esta opción se admite en servidores Git, Helm u OCI. El certificado de la AC debe incluir certificados SSL completos (raíz, intermedio y hoja). Si tu servidor ya usa una autoridad de certificación de confianza o no te conectas a través de HTTPS, puedes saltarte este paso y dejar caCertSecretRef sin definir.

RootSync

1. Obtén el certificado de la AC que se usó para emitir el certificado de tu servidor Git y guárdalo en un archivo.

2. En el caso de los objetos RootSync, el secreto 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 Config Sync, define el valor del campo caCertSecretRef.name en el objeto RootSync como ROOT_CA_CERT_SECRET_NAME.

RepoSync

1. Obtén el certificado de la AC que se usó para emitir el certificado de tu servidor Git y guárdalo en un archivo.

2. En el caso de los objetos RepoSync, el secreto 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 RepoSync, asigna el valor NAMESPACE_CA_CERT_SECRET_NAME al campo caCertSecretRef.name del objeto RepoSync.

Conceder acceso de solo lectura de Config Sync a Helm

Config Sync necesita acceso de solo lectura a tu repositorio de Helm para poder leer los gráficos de Helm de tu repositorio e instalarlos en tus clústeres.

Si no es necesario autenticarse en tu repositorio para el acceso de solo lectura, puedes configurar Config Sync y usar none como tipo de autenticación. Por ejemplo, si tu repositorio de Helm es público y cualquier usuario de Internet puede acceder a él, no tienes que autenticarte.

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

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

Nota: Config Sync no admite la configuración de helm como tipo de origen con la consola de Google Cloud ni con la CLI de Google Cloud. Puedes configurar tu objeto RootSync o RepoSync para que se sincronice desde un repositorio de Helm mediante la API de Kubernetes o declararlo en otra fuente de información veraz. Para obtener más información, consulta la configuración del repositorio de Helm.

Token

Crea un secreto con el nombre de usuario y la contraseña del repositorio de Helm:

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

Haz los cambios siguientes:

• SECRET_NAME: el nombre que quieras dar al secreto.
• USERNAME: nombre de usuario del repositorio de Helm.
• PASSWORD: contraseña del repositorio de Helm.

Cuando configures Config Sync (Configurar Config Sync), usarás el nombre de secreto que hayas elegido para spec.helm.secretRef.name.

Cuenta de servicio de Kubernetes

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

1. Concede el rol de gestión de identidades y accesos Lector de Artifact Registry (roles/artifactregistry.reader) a la cuenta de servicio de Kubernetes con el grupo de federación de Workload Identity para GKE. Para obtener más información sobre los roles y permisos de Artifact Registry, consulta Configurar roles y permisos de Artifact Registry.

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

   • Concede permisos específicos de repositorio cuando quieras que las cuentas de servicio tengan diferentes niveles de acceso para cada repositorio de tu 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
     

   Haz los cambios siguientes:

   • PROJECT_ID: el ID del proyecto de la organización.
   • FLEET_HOST_PROJECT_ID: si usas GKE Workload Identity Federation for GKE, es lo mismo que PROJECT_ID. Si usas la federación de identidades de carga de trabajo de flota para GKE, este es el ID del proyecto de la flota en la que está registrado tu clúster.
   • KSA_NAME: la cuenta de servicio de Kubernetes del reconciliador.
     • En el caso de los repositorios raíz, si el nombre de 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 necesita 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 inhabilitado, puedes usar gcenode como tipo de autenticación. Config Sync usa la cuenta de servicio predeterminada de Compute Engine. Debes conceder acceso de lectura a Artifact Registry a tu cuenta de servicio predeterminada de Compute Engine. Es posible que tengas que conceder el storage-ro ámbito de acceso para conceder permiso de solo lectura para extraer imágenes.

1. Concede a la cuenta de servicio de Compute Engine permiso de lectura en Artifact Registry:

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

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

Configurar Config Sync

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

1. Si usas el webhook de admisión de Config Sync (está inhabilitado de forma predeterminada) y vas a instalar Config Sync en un clúster privado, añade una regla de cortafuegos para permitir el puerto 10250. El webhook de admisión de Config Sync usa el puerto 10250 para evitar las desviaciones.

2. Espera a que los CRDs 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
   

   Haz los cambios siguientes:

   • ROOT_SYNC_NAME: añade el nombre de tu objeto RootSync.
   • ROOT_FORMAT: añade unstructured para usar un repositorio no estructurado o añade hierarchy para usar un repositorio jerárquico. En estos valores se distingue entre mayúsculas y minúsculas. Este campo es opcional y su valor predeterminado es hierarchy. Te recomendamos que añadas unstructured, ya que este formato te permite organizar tus configuraciones de la forma que te resulte más cómoda.
   • ROOT_REPOSITORY: añade la URL del repositorio de Git que quieras usar como repositorio raíz. Puede introducir URLs 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: añade la revisión de Git (etiqueta o hash) o la rama desde la que se sincronizarán los datos. Este campo es opcional y su valor predeterminado es HEAD. Cuando se usa un hash, debe ser un hash completo y no una forma abreviada.
   • ROOT_BRANCH: añade la rama del repositorio desde la que se hace la sincronización. Este campo es opcional y su valor predeterminado es master. Te recomendamos que uses el campo revision para especificar un nombre de rama por simplicidad. Si se especifican tanto el campo revision como el campo branch, revision tiene prioridad sobre branch.
   • ROOT_DIRECTORY: añade la ruta del repositorio de Git al directorio raíz que contiene la configuración que quieres sincronizar. Este campo es opcional y el valor predeterminado es el directorio raíz (/) del repositorio.

   • ROOT_AUTH_TYPE: añade uno de los siguientes tipos de autenticación:

     • none: no usar autenticación
     • ssh: usar un par de claves SSH
     • cookiefile: usa un cookiefile
     • token: usar 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 Workload Identity Federation para GKE no está habilitado en tu clúster.

     Para obtener más información sobre estos tipos de autenticación, consulta el artículo Conceder acceso de solo lectura a Git a Config Sync.

     Este campo es obligatorio.

   • ROOT_EMAIL: si has añadido gcpserviceaccount como tu ROOT_AUTH_TYPE, añade la dirección de correo de tu cuenta de servicio de Google. Por ejemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

   • ROOT_SECRET_NAME: añade el nombre del secreto. Si se define este campo, debes añadir la clave pública del secreto al proveedor de Git. Este campo es opcional.

   • ROOT_NO_SSL_VERIFY: para inhabilitar la verificación del certificado SSL, asigna el valor true a este campo. El valor predeterminado es false.

   • ROOT_CA_CERT_SECRET_NAME: añade el nombre de tu secreto. Si se define este campo, tu proveedor de Git debe usar un certificado emitido por esta autoridad de certificación (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 Secret para el certificado de la AC, consulta Configurar la autoridad de certificación.

   Para obtener una explicación de los campos y una lista completa de los que puede añadir al campo spec, consulte Campos de RootSync.

   Este archivo de manifiesto 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
   

   Haz los cambios siguientes:

   • ROOT_SYNC_NAME: añade el nombre de tu objeto RootSync.
   • ROOT_FORMAT: añade unstructured para usar un repositorio no estructurado o añade hierarchy para usar un repositorio jerárquico. En estos valores se distingue entre mayúsculas y minúsculas. Este campo es opcional y su valor predeterminado es hierarchy. Te recomendamos que añadas unstructured, ya que este formato te permite organizar tus configuraciones de la forma que te resulte más cómoda.
   • ROOT_IMAGE: URL de la imagen OCI que se va a usar 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 con TAG o DIGEST. Especifica TAG o DIGEST en PACKAGE_NAME:
     • Para tirar por TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • Para tirar por DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST

   Precaución: Config Sync requiere que la capa de OCI esté comprimida en tar o tar+gzip. Config Sync no reconocerá otros formatos (por ejemplo, tar+bz2). Si cambias de un REPO válido a una imagen OCI con un formato no admitido, los recursos gestionados se eliminarán sin que se produzca ningún error.

   • ROOT_DIRECTORY: añade la ruta del repositorio al directorio raíz que contiene la configuración que quieres sincronizar. Este campo es opcional y el valor predeterminado es el directorio raíz (/) del repositorio.

   • ROOT_AUTH_TYPE: añade uno de los siguientes tipos de autenticación:

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

     Este campo es obligatorio.

   • ROOT_EMAIL: si has añadido gcpserviceaccount como tu ROOT_AUTH_TYPE, añade la dirección de correo de tu cuenta de servicio de Google. Por ejemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

   • ROOT_CA_CERT_SECRET_NAME: añade el nombre de tu secreto. Si se define este campo, tu proveedor de OCI debe usar un certificado emitido por esta autoridad de certificación (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 Secret para el certificado de la AC, consulta Configurar la autoridad de certificación.

   Para obtener una explicación de los campos y una lista completa de los que puede añadir al campo spec, consulte Campos de RootSync.

   Este manifiesto crea un objeto RootSync que usa una imagen OCI como origen.

   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
   

   Haz los cambios siguientes:

   • ROOT_SYNC_NAME: añade el nombre de tu objeto RootSync.
   • ROOT_FORMAT: añade unstructured para usar un repositorio no estructurado o añade hierarchy para usar un repositorio jerárquico. En estos valores se distingue entre mayúsculas y minúsculas. Este campo es opcional y su valor predeterminado es hierarchy. Te recomendamos que añadas unstructured, ya que este formato te permite organizar tus configuraciones de la forma que te resulte más cómoda.
   • ROOT_HELM_REPOSITORY: la URL del repositorio de Helm que se va a usar como repositorio raíz. Puede introducir URLs 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: añade el nombre de tu gráfico de Helm. Este campo es obligatorio.
   • HELM_CHART_VERSION: 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: el nombre de la versión de Helm. Este campo es opcional.
   • HELM_RELEASE_NAMESPACE: el espacio de nombres de destino de una versión. Solo define 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 define como true si quieres que la plantilla de Helm también genere un 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 que se usarán en lugar de los valores predeterminados que acompañan al gráfico de Helm. Este campo debe tener el mismo formato que el archivo values.yaml del gráfico de Helm. Este campo es opcional.

   • ROOT_AUTH_TYPE: añade uno de los siguientes tipos de autenticación:

     • none: no usar 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 de Artifact Registry. Selecciona esta opción solo si Workload Identity Federation para GKE no está habilitado en tu clúster.
     • gcpserviceaccount: usa una cuenta de servicio de Google para acceder a una imagen.

     Este campo es obligatorio.

   • ROOT_EMAIL: si has añadido gcpserviceaccount como tu ROOT_AUTH_TYPE, añade la dirección de correo de tu cuenta de servicio de Google. Por ejemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

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

   • ROOT_CA_CERT_SECRET_NAME: añade el nombre de tu secreto. Si se define este campo, tu proveedor de Helm debe usar un certificado emitido por esta autoridad de certificación (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 Secret para el certificado de la AC, consulta Configurar la autoridad de certificación.

   Para obtener una explicación de los campos y una lista completa de los que puede añadir al campo spec, consulte Campos de RootSync.

   Este manifiesto crea un objeto RootSync que usa Helm como origen.

4. Aplica los cambios:

   kubectl apply -f root-sync.yaml
   

Verificar 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ía ver un resultado similar al siguiente ejemplo:

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

Verificar la instalación de RootSync

Cuando creas un objeto RootSync, Config Sync crea un reconciliador con el prefijo root-reconciler. Un reconciliador es un pod que se implementa como un Deployment. Sincroniza manifiestos de un repositorio de Git con un clúster.

Para comprobar que el objeto RootSync funciona correctamente, consulta el estado de la implementación de root-reconciler:

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

Sustituye ROOT_SYNC_NAME por el nombre de RootSync.

Debería ver un resultado similar al siguiente ejemplo:

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

Para ver otras formas de consultar el estado de tu objeto RootSync, consulta Monitorizar objetos RootSync y RepoSync.

Una vez que hayas terminado de configurar tu repositorio raíz, puedes configurar la sincronización desde varios repositorios. Estos repositorios son útiles si quieres que un repositorio que contenga configuraciones con ámbito de espacio de nombres se sincronice con un espacio de nombres concreto en todos los clústeres.

Actualizar Config Sync

Los pasos para actualizar Config Sync dependen de la versión a la que quieras actualizar y de la versión desde la que quieras hacerlo. A partir de la versión 1.20.0, Config Sync se proporciona como una instalación independiente sin el operador ConfigManagement. Si vas a actualizar de una versión anterior a la 1.20.0 a la versión 1.20.0 o una posterior, primero debes desinstalar el operador ConfigManagement antes de actualizar.

Si vas a actualizar desde una versión no compatible, debes hacerlo paso a paso, con incrementos de no más de tres versiones secundarias a la vez. Por ejemplo, si la versión actual de Config Sync es 1.14.0, primero actualiza a la versión 1.17.0 y, después, a la versión 1.20.0.

Desinstalar el operador ConfigManagement

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

Para comprobar si Gestión de configuración está instalado en tu clúster, ejecuta el siguiente comando:

kubectl get configmanagement

Si la salida no está vacía, Config Management está instalado en el clúster. Para desinstalar Config Management, sigue estos pasos, pero deja Config Sync instalado en el clúster. Te recomendamos que uses nomos CLI para desinstalar el operador ConfigManagement, ya que tiene una interfaz más completa y una gestión de errores más sólida. Solo debes usar la secuencia de comandos shell si no tienes acceso a la 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 el contexto de kubectl actual:

   nomos migrate --remove-configmanagement
   

script de shell

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

 #!/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

Instalar la nueva versión de Config Sync

Para actualizar Config Sync, sigue estos pasos en cada clúster registrado:

1. Descarga los comandos del manifiesto y nomos de Config Sync para la nueva versión.

2. Extrae el archivo:

   tar -xzvf config-sync.tar.gz

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

   Nota: Es necesario editar el archivo kustomization.yaml para algunos ajustes, como configurar un nombre de clúster para usarlo con un ClusterSelector o incluir el archivo admission-webhook.yaml para usarlo con la prevención de desviaciones
   .

4. Para actualizar la instalación de Config Sync, aplica el manifiesto renderizado que has creado siguiendo las README.md instrucciones:

   kubectl apply -f CONFIG_SYNC_MANIFEST
   

   Sustituye CONFIG_SYNC_MANIFEST por el nombre del archivo de manifiesto renderizado.

5. Sustituye el comando nomos en todos los clientes por la nueva versión. Con este cambio, el comando nomos siempre podrá obtener el estado de todos los clústeres registrados y validar sus configuraciones.

Desinstalar Config Sync

Precaución: Si se elimina un objeto RootSync o RepoSync, no se limpiarán las anotaciones ni las etiquetas de Config Sync, y el webhook de admisión de Config Sync denegará las solicitudes que intenten eliminar estos recursos si Config Sync sigue habilitado en el clúster. La solución alternativa consiste en dejar de gestionar o eliminar estos recursos gestionados antes de eliminar el objeto RootSync o RepoSync correspondiente.

Para desinstalar Config Sync, sigue estos pasos:

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

   1. Si has habilitado el webhook y quieres conservar tus recursos, desactiva la prevención de la deriva para los recursos abandonados. Si no has habilitado el webhook, no tienes que hacer nada más para conservar tus recursos.

   2. Elimina el objeto RootSync ejecutando el siguiente comando:

      kubectl delete -f root-sync.yaml
      

2. Elimina los repositorios.

3. Con los manifiestos que has usado para instalar Config Sync, también puedes desinstalarlo.

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

Nota: Al inhabilitar esta función, no se verán afectadas las configuraciones que Config Sync haya aplicado anteriormente a tus clústeres.

Siguientes pasos

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