Esta página se ha traducido con Cloud Translation API.

Instalar Config Sync

Con Config Sync, puedes gestionar recursos de Kubernetes con archivos de configuración almacenados en una fuente de información veraz. Config Sync admite repositorios de Git, imágenes OCI y gráficos de Helm como fuente de información veraz. En esta página se explica cómo habilitar y configurar Config Sync para que se sincronice desde tu repositorio raíz. Config Sync está disponible con Google Kubernetes Engine.

Cuando instalas Config Sync mediante la consola Google Cloud o la CLI de Google Cloud, las APIs RootSync y RepoSync se habilitan de forma predeterminada. De esta forma, podrás disfrutar de funciones adicionales, como la sincronización desde varios repositorios y la sincronización de configuraciones de Kustomize y Helm.

Antes de empezar

Antes de instalar Config Sync, prepara tu entorno, asegúrate de que cumples los requisitos del clúster y asigna los roles de usuario adecuados.

Preparar el entorno local

Prepara tu entorno local completando las siguientes tareas:

Crea una fuente de información veraz o asegúrate de tener acceso a ella. Aquí es donde se añaden las configuraciones que sincroniza Config Sync. Para obtener más información sobre cómo configurar tus configuraciones y tu fuente de información veraz, consulta una de las siguientes guías:
Instala e inicializa Google Cloud CLI, que proporciona los comandos gcloud y nomos. Si usas Cloud Shell, Google Cloud CLI viene preinstalada. Si ya has instalado la CLI de Google Cloud, obtén la versión más reciente ejecutando gcloud components update.
Habilita la API de GKE.

Habilitar la API de GKE

Revisar los requisitos de los clústeres

Antes de instalar Config Sync en tu clúster, consulta las recomendaciones y los requisitos de configuración del clúster.

Preparar el clúster

Una vez que hayas creado un clúster adecuado, sigue estos pasos:

Concede los roles de gestión de identidades y accesos necesarios al usuario que registre el clúster.
Si tienes previsto usar la CLI de Google Cloud para configurar Config Sync o usar clústeres fuera de Google Cloud, asegúrate de que tus clústeres de GKE o tus clústeres fuera de Google Cloud estén registrados en una flota. Si tienes previsto usar la consola Google Cloud , puedes registrar clústeres de GKE cuando configures Config Sync.

Instalar Config Sync

En las siguientes secciones, se explica cómo conceder acceso a Config Sync a una de las siguientes fuentes de información veraz:

Repositorio de Git
Imagen de OCI
Gráfico de Helm

Una vez que hayas concedido acceso, puedes configurar Config Sync.

Conceder acceso a Git

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:

Mostrar todos los repositorios:
```
gcloud source repos list
```
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.

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

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

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

(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
```
Elimina la clave privada del disco local o toma medidas para protegerla.
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://EMAIL@source.developers.google.com: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

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:

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

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

Si aún no tienes una cuenta de servicio, crea una.
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 de 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 gestión de identidades y accesos 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.
Si configura Config Sync mediante la Google Cloud consola, seleccione Federación de identidades de cargas de trabajo para GKE como Tipo de autenticación y, a continuación, añada el correo de su 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.
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.
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.

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:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

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:

Sigue las instrucciones de GitHub para aprovisionar una aplicación de GitHub y darle permiso para leer tu repositorio.
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.
Elimina la clave privada del disco local o toma medidas para protegerla.
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.

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 identidades de carga de trabajo 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.

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:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
   --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.

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)

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: la 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.

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 identidades de carga de trabajo 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.

Cuenta de servicio predeterminada de Compute Engine

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:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
    --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

En esta sección, se configuran los ajustes del repositorio raíz. Si vas a sincronizar con un repositorio de Git, puedes usar la consola para que te guíe en el proceso de instalación y automatizar algunos pasos. Google Cloud

Cuando 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 Puedes usar comandos kubectl para modificar root-sync y añadir configuraciones de Config Sync. Para obtener más información, consulta Configurar Config Sync con comandos de kubectl.

Consola

Instalar Config Sync

Para instalar Config Sync, todos los clústeres deben estar registrados en una flota. Cuando instalas Config Sync en la consola, al seleccionar clústeres individuales, estos se registran automáticamente en tu flota. Google Cloud

En la Google Cloud consola, ve a la página Configuración de la sección Funciones.

Ve a Configuración

Haz clic en Instalar Config Sync.
Selecciona la versión de Config Sync que quieras usar.
En Opciones de instalación, selecciona una de las siguientes opciones:
- Instalar Config Sync en toda la flota (opción recomendada): Config Sync se instalará en todos los clústeres de la flota.
- Instalar Config Sync en clústeres individuales: todos los clústeres seleccionados se registrarán automáticamente en una flota. Config Sync se instalará en todos los clústeres de la flota.
Si vas a instalar Config Sync en clústeres concretos, en la tabla Available clusters (Clústeres disponibles), selecciona los clústeres en los que quieras instalar Config Sync.
Haz clic en Instalar Config Sync. En la pestaña Configuración, al cabo de unos minutos, debería aparecer el valor Habilitado en la columna Estado de los clústeres de tu flota.

Desplegar un paquete

Una vez que hayas registrado tus clústeres en una flota e instalado Config Sync, puedes configurar Config Sync para desplegar un paquete en un clúster desde una fuente de información veraz. Puedes desplegar el mismo paquete en varios clústeres o desplegar diferentes paquetes en distintos clústeres. Puedes editar un paquete después de implementarlo, excepto algunos ajustes, como el nombre del paquete y el tipo de sincronización. Para obtener más información, consulta Gestionar paquetes.

Para implementar un paquete, sigue estos pasos:

En la Google Cloud consola, ve al panel de control Config Sync.

Ir al panel de control de Config Sync
Haz clic en Desplegar paquete.
En la tabla Seleccionar clústeres para la implementación de paquetes, seleccione el clúster en el que quiera implementar un paquete y, a continuación, haga clic en Continuar.
Seleccione Paquete alojado en Git o Paquete alojado en OCI como tipo de fuente y, a continuación, haga clic en Continuar.
En la sección Package details (Detalles del paquete), introduce un Package name (Nombre del paquete), que identifica el objeto RootSync o RepoSync.
En el campo Tipo de sincronización, elige Sincronización con ámbito de clúster o Sincronización con ámbito de espacio de nombres como tipo de sincronización.

La sincronización con ámbito de clúster crea un objeto RootSync, mientras que la sincronización con ámbito de espacio de nombres crea un objeto RepoSync. Para obtener más información sobre estos objetos, consulta el artículo Arquitectura de Config Sync.
En la sección Origen, haz lo siguiente:
- En el caso de las fuentes alojadas en un repositorio de Git, introduce los siguientes campos:
  1. Introduce la URL del repositorio de Git que estés usando como fuente de información principal en el campo URL del repositorio.
  2. Opcional: Actualiza el campo Revisión para comprobar si no estás usando el valor predeterminado HEAD.
  3. Opcional: Actualiza el campo Ruta si no quieres sincronizar desde el repositorio raíz.
  4. Opcional: Actualiza el campo Rama si no usas la rama main predeterminada.
- En el caso de las fuentes alojadas en una imagen de OCI, introduce los siguientes campos:
  1. Introduce la URL de la imagen OCI que estés usando como fuente de información principal en el campo Imagen.
  2. Introduce la ruta del directorio desde el que se va a sincronizar, relativa al directorio raíz, en el campo Directorio.
(Opcional): Despliega la sección Configuración avanzada para completar lo siguiente:
1. Selecciona un Tipo de autenticación. Config Sync necesita acceso de solo lectura a tu fuente de información veraz para leer los archivos de configuración de la fuente y aplicarlos a tus clústeres. A menos que tu fuente no requiera autenticación, como un repositorio público, asegúrate de conceder a Config Sync acceso de solo lectura a tu repositorio de Git, imagen OCI o gráfico de Helm (solo en la CLI de gcloud). Elige el mismo tipo de autenticación que configuraste al instalar Config Sync:
  
  Nota: En el caso de OCI, solo puedes seleccionar Workload Identity para la autenticación.
  - Ninguna: no se usa ninguna autenticación.
  - SSH autentica mediante un par de claves SSH.
  - Cookiefile: autentica mediante un cookiefile.
  - Token: autentícate con un token de acceso o una contraseña.
  - Repositorio de Google Cloud: usa una cuenta de servicio de Google para acceder a un repositorio de Cloud Source Repositories. Selecciona esta opción solo si la federación de identidades de carga de trabajo para GKE no está habilitada en tu clúster.
  - Workload Identity: usa una cuenta de servicio de Google para acceder a un repositorio de Cloud Source Repositories.
2. Introduce un número en segundos para definir el Tiempo de espera de sincronización, que determina cuánto tiempo espera Config Sync entre los intentos de extraer datos de la fuente de información veraz.
3. Introduce una URL de proxy de Git para el proxy HTTPS que se usará al comunicarse con la fuente de información principal.
4. Elige Jerarquía para cambiar el Formato de origen.
  
  En la mayoría de los casos, se recomienda usar el valor predeterminado Sin estructura, ya que te permite organizar tu fuente de información como quieras.
Haz clic en Desplegar paquete.

Se te redirigirá a la página Paquetes de Config Sync. Al cabo de unos minutos, debería ver el estado Sincronizado en la columna Estado de sincronización del clúster que ha configurado.

gcloud

Antes de continuar, asegúrate de haber registrado tus clústeres en una flota.

Habilita la función de flota ConfigManagement:

gcloud beta container fleet config-management enable

Prepara la configuración creando un apply-spec.yaml manifiesto o usando uno que ya tengas. Si usas un manifiesto, puedes configurar tu clúster con los mismos ajustes que otro clúster.
Crear un manifiesto
Para configurar Config Sync con nuevos ajustes para tu clúster, crea un archivo llamado apply-spec.yaml y copia el siguiente archivo YAML en él.

Puedes definir todos los campos spec.configSync opcionales que necesites al crear el manifiesto y, más adelante, usar los comandos kubectl para la configuración. También puedes definir el campo spec.configSync.enabled como true y omitir los campos opcionales. Después, puede usar comandos kubectl para crear objetos RootSync adicionales o RepoSyncs que podrá gestionar por completo con comandos kubectl más adelante.
```
# apply-spec.yaml

applySpecVersion: 1
spec:
  configSync:
    enabled: true
    # If you don't have a source of truth yet, omit the
    # following fields. You can configure them later.
    sourceType: SOURCE_TYPE
    sourceFormat: FORMAT
    syncRepo: REPO
    syncRev: REVISION
    syncBranch: BRANCH
    secretType: SECRET_TYPE
    gcpServiceAccountEmail: EMAIL
    metricsGcpServiceAccountEmail: METRICS_EMAIL
    policyDir: DIRECTORY
    preventDrift: PREVENT_DRIFT
```
Haz los cambios siguientes:
- SOURCE_TYPE: añade git para sincronizar desde un repositorio de Git, oci para sincronizar desde una imagen OCI o helm para sincronizar desde un gráfico de Helm. Si no se especifica ningún valor, se usa git de forma predeterminada.
- 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.
- REPO: añade la URL de la fuente de información veraz. Las URLs de los repositorios de Git y Helm usan el protocolo HTTPS o SSH. Por ejemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples. Si tienes previsto usar SSH como secretType, introduce tu URL con el protocolo SSH. Este campo es obligatorio y, si no introduces ningún protocolo, la URL se tratará como una URL HTTPS.
  
  Las URLs de OCI tienen el siguiente formato: 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 OCI esté comprimida en formato tar o tar+gzip. Config Sync no reconocerá otros formatos (por ejemplo, tar+bz2). Si se cambia 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.
- REVISION: la revisión de Git (etiqueta o hash) o el nombre de la rama desde la que se sincronizará. Cuando se utilice un hash, debe ser un hash completo, no una forma abreviada.
- SECRET_TYPE: una de las siguientes secretTypes:
  git
  
  none: no se usa ninguna autenticación.
  
  ssh: usa un par de claves SSH.
  
  cookiefile: usa un cookiefile.
  
  token: usa un token.
  
  gcpserviceaccount: usa una cuenta de servicio de Google para acceder a un repositorio de Cloud Source Repositories o Secure Source Manager. Si selecciona este tipo de autenticación, deberá crear un enlace de política de IAM después de terminar de configurar Config Sync. Para obtener más información, consulta la pestaña Cuenta de servicio de Google de la sección Conceder acceso de solo lectura a Git a Config Sync.
  
  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.
  
  githubapp: usa una aplicación de GitHub para autenticarte en un repositorio de GitHub.
  
  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.
  
  oci
  
  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.
  
  Helm
  
  token: usa un token.
  
  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.
- EMAIL: si has añadido gcpserviceaccount como tu secretType, añade la dirección de correo de tu cuenta de servicio de Google. Por ejemplo, acm@PROJECT_ID.iam.gserviceaccount.com.
- METRICS_EMAIL: el correo electrónico de la Google Cloud cuenta de servicio (GSA) que se usa para exportar métricas de Config Sync a Cloud Monitoring. La cuenta de servicio de Google debe tener el rol de gestión de identidades y accesos Editor de métricas de monitorización (roles/monitoring.metricWriter). La cuenta de servicio de Kubernetes default del espacio de nombres config-management-monitoring debe estar vinculada a la cuenta de servicio de Google.
- DIRECTORY: la ruta del directorio desde el que se va a sincronizar, relativa a la raíz del repositorio de Git. Todos los subdirectorios del directorio que especifique se incluirán y se sincronizarán con el clúster. El valor predeterminado es el directorio raíz del repositorio.
- PREVENT_DRIFT: si se define como true, habilita el webhook de admisión de Config Sync para evitar las desviaciones rechazando los cambios conflictivos que se envían a los clústeres activos. El valor predeterminado es false. Config Sync siempre corrige las desviaciones, independientemente del valor de este campo.
Para ver una lista completa de los campos que puedes añadir al campo spec, consulta gcloud fields.

Nota: Si aún no tienes preparada una fuente de información veraz, puedes habilitar Config Sync sin configurar ningún ajuste. Para ello, asigna el valor true a spec.configSync.enabled y omite todos los demás campos spec.configSync. Cuando hayas preparado el repositorio, edita el archivo apply-spec.yaml para añadir los ajustes de configuración.
Usar manifiesto actual
Para configurar tu clúster con los mismos ajustes que otro clúster, obtén los ajustes de un clúster registrado:
```
gcloud alpha container fleet config-management fetch-for-apply \
    --membership=MEMBERSHIP_NAME \
    --project=PROJECT_ID \
    > CONFIG_YAML_PATH
```
Haz los cambios siguientes:
- MEMBERSHIP_NAME: el nombre de miembro del clúster registrado que tiene la configuración de Config Sync que quieres usar
- PROJECT_ID: tu ID de proyecto
- CONFIG_YAML_PATH: la ruta al archivo apply-spec.yaml, que contiene los ajustes obtenidos del clúster.
Aplica el archivo apply-spec.yaml. Si usas un manifiesto, debes aplicar el archivo al clúster que quieras configurar con los ajustes que has obtenido en el comando anterior:
```
gcloud beta container fleet config-management apply \
    --membership=MEMBERSHIP_NAME \
    --config=CONFIG_YAML_PATH \
    --project=PROJECT_ID
```
Haz los cambios siguientes:
- MEMBERSHIP_NAME: el nombre de la pertenencia a la flota que elegiste al registrar tu clúster. Puedes encontrar el nombre con gcloud container fleet memberships list.
- CONFIG_YAML_PATH: la ruta a tu archivo apply-spec.yaml.
- PROJECT_ID: tu ID de proyecto.

Terraform

Para cada clúster en el que quieras configurar Config Sync, aplica un bloque de recursos google_gkehub_feature_membership que contenga bloques configmanagement y config_sync, como en el siguiente ejemplo:

git

data "google_project" "default" {}

resource "google_container_cluster" "default" {
  name     = "gke-autopilot-basic"
  location = "us-central1"

  fleet {
    project = data.google_project.default.project_id
  }

  enable_autopilot = true
}

resource "google_gke_hub_feature" "configmanagement_feature" {
  name     = "configmanagement"
  location = "global"
}

resource "google_gke_hub_feature_membership" "configmanagement_feature_member" {
  location = "global"

  feature             = google_gke_hub_feature.configmanagement_feature.name
  membership          = google_container_cluster.default.fleet[0].membership_id
  membership_location = google_container_cluster.default.fleet[0].membership_location

  configmanagement {
    config_sync {
      # The field `enabled` was introduced in Terraform version 5.41.0, and
      # needs to be set to `true` explicitly to install Config Sync.
      enabled = true
      git {
        sync_repo   = "REPO"
        sync_branch = "BRANCH"
        policy_dir  = "DIRECTORY"
        secret_type = "SECRET"
      }
    }
  }
}

Haz los cambios siguientes:

REPO: la URL del repositorio de Git que contiene los archivos de configuración.
BRANCH: la rama del repositorio, por ejemplo, main.
DIRECTORY: la ruta del repositorio de Git que representa el nivel superior del repositorio que quieres sincronizar.
SECRET: el tipo de autenticación secreta.

oci

data "google_project" "default" {}

resource "google_container_cluster" "default" {
  name     = "gke-autopilot-basic"
  location = "us-central1"

  fleet {
    project = data.google_project.default.project_id
  }

  enable_autopilot = true
}

resource "google_gke_hub_feature" "configmanagement_feature" {
  name     = "configmanagement"
  location = "global"
}

resource "google_gke_hub_feature_membership" "configmanagement_feature_member" {
  location = "global"

  feature             = google_gke_hub_feature.configmanagement_feature.name
  membership          = google_container_cluster.default.fleet[0].membership_id
  membership_location = google_container_cluster.default.fleet[0].membership_location

  configmanagement {
    config_sync {
      # The field `enabled` was introduced in Terraform version 5.41.0, and
      # needs to be set to `true` explicitly to install Config Sync.
      enabled = true
      oci {
        sync_repo   = "REPO"
        policy_dir  = "DIRECTORY"
        secret_type = "SECRET"
      }
    }
  }
}

Haz los cambios siguientes:

REPO: la URL del repositorio de imágenes de OCI que contiene los archivos de configuración.
DIRECTORY: la ruta absoluta del directorio que contiene los recursos que quieres sincronizar. Para usar el directorio raíz, deje este campo en blanco.
SECRET: el tipo de autenticación secreta.

Repite este proceso con cada clúster que quieras sincronizar.

Para obtener más información sobre cómo usar Terraform, consulta Compatibilidad de Terraform con Config Sync.

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

Configurar valores predeterminados a nivel de flota

Puedes habilitar y configurar Config Sync como valor predeterminado a nivel de flota para tus clústeres. Esto significa que cada nuevo clúster de GKE en Google Cloud creado en la flota tendrá habilitado Config Sync con los ajustes que especifiques. Puedes consultar más información sobre la configuración predeterminada de la flota en Gestionar funciones a nivel de flota.

Si solo usas la Google Cloud consola, puedes habilitar Config Sync de forma predeterminada en tus clústeres y definir la versión de Config Sync para tu flota. Si usas la CLI de gcloud o Terraform, puedes habilitar Config Sync de forma predeterminada en tus clústeres, definir la versión de Config Sync de tu flota y configurar la conexión a tu repositorio de Git o de imágenes OCI.

Para configurar los valores predeterminados a nivel de flota de Config Sync, sigue estos pasos:

gcloud

Ejecuta el comando enable de la función y pasa el apply-spec.yaml archivo de configuración que creaste cuando configuraste Config Sync en un clúster concreto:

gcloud beta container fleet config-management enable \
    --fleet-default-member-config=apply-spec.yaml

Puedes usar este comando para actualizar la configuración predeterminada de tu flota en cualquier momento. Si actualizas la configuración predeterminada de tu flota, debes volver a sincronizar los clústeres con la configuración predeterminada.

Consola

En la Google Cloud consola, ve a la página Gestor de funciones.

Ir a Gestor de funciones
En el panel Config Sync (Sincronización de configuración), haga clic en Configure (Configurar).
Revisa la configuración a nivel de flota. Todos los clústeres que crees en la flota heredarán estos ajustes.
Opcional: Para cambiar los ajustes predeterminados, haz clic en Personalizar ajustes de la flota. En el cuadro de diálogo que aparece, haz lo siguiente:
1. Selecciona la versión de Config Sync que quieras usar.
2. Haz clic en Guardar cambios.
Haz clic en Configurar.
En el cuadro de diálogo de confirmación Configurar ajustes de la flota, haz clic en Confirmar. Si no has habilitado Config Sync anteriormente, al hacer clic en Confirm (Confirmar), también se habilitará la API anthosconfigmanagement.googleapis.com.

Terraform

Para habilitar Config Sync en una flota, consulta el siguiente ejemplo:

git

resource "google_gke_hub_feature" "default" {
  name     = "configmanagement"
  location = "global"

  fleet_default_member_config {
    configmanagement {
      config_sync {
        # The field `enabled` was introduced in Terraform version 5.41.0, and
        # needs to be set to `true` explicitly to install Config Sync.
        enabled = true
        git {
          sync_repo   = "REPO"
          sync_branch = "BRANCH"
          policy_dir  = "DIRECTORY"
          secret_type = "SECRET"
        }
      }
    }
  }
}

Haz los cambios siguientes:

REPO: la URL del repositorio de Git que contiene los archivos de configuración.
BRANCH: la rama del repositorio, por ejemplo, main.
DIRECTORY: la ruta del repositorio de Git que representa el nivel superior del repositorio que quieres sincronizar.
SECRET: el tipo de autenticación secreta.

oci

resource "google_gke_hub_feature" "configmanagement_feature_member" {
  name     = "configmanagement"
  location = "global"

  fleet_default_member_config {
    configmanagement {
      config_sync {
        # The field `enabled` was introduced in Terraform version 5.41.0, and
        # needs to be set to `true` explicitly to install Config Sync.
        enabled = true
        oci {
          sync_repo   = "REPO"
          policy_dir  = "DIRECTORY"
          secret_type = "SECRET"
        }
      }
    }
  }
}

Haz los cambios siguientes:

REPO: la URL del repositorio de imágenes de OCI que contiene los archivos de configuración.
DIRECTORY: la ruta absoluta del directorio que contiene los recursos que quieres sincronizar. Para usar el directorio raíz, deje este campo en blanco.
SECRET: el tipo de autenticación secreta.

Para obtener más información sobre cómo usar Terraform, consulta Compatibilidad de Terraform con Config Sync.

Para actualizar los clústeres que ya tienes para que usen la configuración predeterminada de Config Sync, puedes usar la Google Cloud consola o la CLI de gcloud para sincronizar los clústeres de la flota que elijas con los valores predeterminados de la flota. También puede configurar manualmente cada clúster con los mismos ajustes mediante Terraform. Para ello, siga las instrucciones para configurar Config Sync. Si anteriormente usabas Terraform para especificar los valores predeterminados de la flota, usa los mismos bloques configmanagement y config_sync que usaste para definir los valores predeterminados y configurar los clústeres que elijas.

Para sincronizar la configuración predeterminada de Config Sync en toda tu flota, sigue estos pasos:

gcloud

Sincroniza una suscripción con la configuración predeterminada de la flota:
```
gcloud beta container fleet config-management apply \
    --origin=FLEET \
    --membership=MEMBERSHIP_NAME
```
Sustituye MEMBERSHIP_NAME por el nombre de la pertenencia a la flota del clúster que quieras sincronizar con la configuración predeterminada de la flota.
Confirma que las configuraciones de tu suscripción se han sincronizado con la configuración predeterminada de la flota:
```
gcloud beta container fleet config-management status
```
El resultado de este comando debe mostrarse como Yes para el estado Synced_to_Fleet_Default de la suscripción que has sincronizado.

consola

Ve a Gestor de funciones:

Ve a Gestor de funciones: Config Sync
En la tabla de clústeres, selecciona los clústeres que quieras sincronizar con los ajustes de la flota.
Haz clic en Sincronizar con la configuración común.

Para inhabilitar los ajustes predeterminados de Config Sync en toda tu flota, sigue estos pasos:

Para inhabilitar la configuración predeterminada de la flota, ejecuta el siguiente comando:
```
gcloud beta container fleet config-management disable --fleet-default-member-config
```
Confirma que la configuración predeterminada de la flota esté inhabilitada:
```
gcloud beta container fleet config-management status
```

La configuración predeterminada de Config Sync se aplica a los clústeres que selecciones. Aunque la consola Google Cloud solo muestra un subconjunto de ajustes, como la versión de Config Sync, todos los ajustes a nivel de flota se sincronizan con los clústeres. Por ejemplo, si configuras Config Sync para que se sincronice con un repositorio de Git mediante Terraform o la CLI de gcloud, ese ajuste se sincronizará con tus clústeres, pero no se mostrará en la consola de Google Cloud .

Verificar la instalación

Una vez que hayas instalado y configurado Config Sync, puedes verificar que la instalación se haya completado correctamente.

Consola

Este agente debe seguir estos pasos:

En la Google Cloud consola, ve a la página Configuración de la sección Funciones.

Ve a Configuración

En la pestaña Paquetes, consulte la columna Estado de sincronización de la tabla de clústeres. Si Config Sync se ha instalado correctamente, su estado será Instalado. Una fuente de información configurada correctamente tiene el estado Sincronizado.

gcloud

Ejecuta el siguiente comando:

gcloud beta container fleet config-management status \
    --project=PROJECT_ID

Sustituye PROJECT_ID por el ID de tu proyecto.

Si la instalación se ha realizado correctamente, el estado será SYNCED y se mostrará la versión de Config Sync instalada.

Si aparece un error después de ejecutar el comando anterior, asegúrate de haber creado el git-creds secreto. Si has creado el secreto, prueba a volver a ejecutar el siguiente comando:

gcloud beta container fleet config-management apply

También puedes usar el comando nomos status para comprobar si Config Sync se ha instalado correctamente. Una instalación válida sin problemas tiene el estado PENDING o SYNCED. Una instalación no válida o incompleta tiene el estado NOT INSTALLED O NOT CONFIGURED. La salida también incluye los errores que se hayan notificado.

Solicitudes de recursos

En la siguiente sección se enumeran las solicitudes de recursos de Config Sync.

En la siguiente tabla se enumeran los requisitos de recursos de Kubernetes para los componentes de Config Sync. Para obtener más información, consulta el artículo Gestión de recursos para contenedores de la documentación de Kubernetes.

No se crean todos los componentes que se indican. Los siguientes casos provocan que se programe cada componente:

config-management-operator se instala cuando Config Sync está habilitado.
reconciler-manager se instala cuando Config Sync está habilitado.
admission-webhook se instala cuando se habilita prevención de deriva.
Se instala un reconciler para cada RootSync y RepoSync.
otel-collector se instala cuando Config Sync está habilitado.

Para obtener más información sobre estos componentes, consulta el artículo Arquitectura de Config Sync.

Las solicitudes de recursos son las mismas para todas las versiones compatibles de Config Sync.

Nombre de la implementación	Solicitud de CPU (m) por réplica	Solicitud de memoria (Mi) por réplica
`config-management-operator`	100	200
`resource-group-controller-manager`	110	300
`admission-webhook¹`	10	100
`otel-collector`	200	400
`reconciler-manager`	20	150
`reconciler` (uno por cada RootSync y RepoSync)	Consulta más información sobre la implementación del reconciliador.

¹ El webhook de admisión tiene dos réplicas, por lo que, al calcular las solicitudes de recursos totales, debe duplicar el valor si utiliza el webhook de admisión. El webhook de admisión está inhabilitado de forma predeterminada.

Despliegue de reconciliador

Por cada objeto RootSync y RepoSync, Config Sync crea una implementación de reconciliador independiente para gestionar la sincronización. El despliegue del reconciliador consta de varios contenedores. Para obtener más información sobre estos contenedores, consulta Contenedores de reconciliación.

Clústeres estándar

Las solicitudes de recursos son las mismas para todas las versiones compatibles de Config Sync.

Nombre del contenedor	Solicitud de CPU (m)	Solicitud de memoria (Mi)
`reconciler`	50	200
`otel-agent`	10	100
`hydration-controller` (Opcional)	10	100
`git-sync`	10	16
`gcenode-askpass-sidecar` (Opcional)	10	20
`helm-sync`	75	128
`oci-sync`	25	32

Clústeres de Autopilot

Las solicitudes de recursos son las mismas para todas las versiones compatibles de Config Sync.

Nombre del contenedor	Solicitud y límite de CPU (m)	Solicitud y límite de memoria (Mi)
`reconciler`	700	512
`otel-agent`	10	64
`hydration-controller` (Opcional)	200	256
`git-sync`	20	32
`gcenode-askpass-sidecar` (Opcional)	50	64
`helm-sync`	250	384
`oci-sync`	50	64

Para saber cómo anular las solicitudes y los límites de recursos predeterminados, consulta la sección sobre anulaciones de recursos.

Versiones empaquetadas de Helm y Kustomize

Config Sync aprovecha los ejecutables de Helm y Kustomize para renderizar las configuraciones de forma interna. En la siguiente tabla se muestra una lista de las versiones de Config Sync que admiten la función de renderización, junto con las versiones de Helm y Kustomize incluidas.

Versiones de Config Sync	Versión de Helm	Versión de Kustomize
1.22.0	v3.15.3	v5.3.0
1.21.0	v3.15.3	v5.3.0
1.20.0	v3.15.3	v5.3.0

Para obtener información sobre cómo renderizar Helm a través de Kustomize, consulta Configurar Kubernetes con Kustomize. Para obtener información sobre cómo usar la API de Helm, consulta Sincronizar gráficos de Helm desde Artifact Registry.

Siguientes pasos

Consulta cómo actualizar Config Sync.
Consulta más información sobre los comandos de gcloud para configurar Config Sync.
Descubre cómo configurar la sincronización desde varios repositorios.
Usa el comando nomos.
Consulta la introducción a la solución de problemas de Config Sync.
Consulta cómo desinstalar Config Sync.
Consulta los permisos de sincronización de configuración predeterminados.

Instalar Config Sync Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Antes de empezar

Preparar el entorno local

Revisar los requisitos de los clústeres

Preparar el clúster

Instalar Config Sync

Conceder acceso a Git

Par de claves SSH

Cookiefile

Token

Cuenta de servicio de Google

Cloud Source Repositories

Secure Source Manager

Cuenta de servicio predeterminada de Compute Engine

Aplicación de GitHub

Usar el ID de cliente

Usar el ID de aplicación

Conceder acceso de solo lectura de Config Sync a OCI

Cuenta de servicio de Kubernetes

Cuenta de servicio predeterminada de Compute Engine

Conceder acceso de solo lectura de Config Sync a Helm

Token

Cuenta de servicio de Kubernetes

Cuenta de servicio predeterminada de Compute Engine

Configurar Config Sync

Consola

Instalar Config Sync

Desplegar un paquete

gcloud

Crear un manifiesto

git

oci

Helm

Usar manifiesto actual

Terraform

git

oci

Configurar valores predeterminados a nivel de flota

gcloud

Consola

Terraform

git

oci

gcloud

consola

Verificar la instalación

Consola

gcloud

Solicitudes de recursos

Despliegue de reconciliador

Clústeres estándar

Clústeres de Autopilot

Versiones empaquetadas de Helm y Kustomize

Siguientes pasos

Instalar Config Sync