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

En esta página, se muestra cómo instalar el Sincronizador de configuración mediante los comandos de kubectl. El operador de ConfigManagement es un controlador que administra el Sincronizador de configuración en un clúster de Kubernetes. Sigue estos pasos para instalar y configurar el operador en cada clúster que desees administrar mediante el Sincronizador de configuración.

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

Antes de comenzar

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

Prepara el entorno local

Antes de instalar el operador, asegúrate de haber preparado tu entorno local. Para ello, completa las siguientes tareas:

• Crear una fuente de verdad o tener acceso a ella

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

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

  gcloud components install kubectl
  

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

Prepara tus clústeres

Crea un clúster de Google Kubernetes Engine (GKE) de edición empresarial que cumpla con los requisitos del Sincronizador de configuración o ten acceso a uno.

Prepara los permisos

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

gcloud container clusters get-credentials CLUSTER_NAME

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

Reemplaza lo siguiente:

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

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

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

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

Inscribe un clúster

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

1. Implementa el operador
2. Otorga al operador acceso de solo lectura a una de las siguientes opciones:
   • Git
   • OCI
   • Helm
3. Configura el operador

Implementa el operador

Después de asegurarte de cumplir con todos los requisitos previos, puedes implementar el operador mediante la descarga y aplicación de un manifiesto YAML.

1. Descarga la última versión del manifiesto del operador mediante el siguiente comando. En cambio, si deseas descargar una versión específica, consulta Descargas.

   gcloud storage cp gs://config-management-release/released/latest/config-management-operator.yaml config-management-operator.yaml
   

2. Aplica los manifiestos:

   kubectl apply -f config-management-operator.yaml

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

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

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

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

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

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

Otorga al operador acceso de solo lectura

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

Otorga al operador acceso de solo lectura a Git

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

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

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

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

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

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

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

1. Enumera todos los repositorios:

   gcloud source repos list
   

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

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

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

Par de claves SSH

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

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

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

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

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

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

   Reemplaza lo siguiente:

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

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

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

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

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

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

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

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

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

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

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

   known_hosts: KNOWN_HOSTS_KEY
   

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

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

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

   Reemplaza lo siguiente:

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

Archivo cookie

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

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

Para usar un cookiefile, completa los siguientes pasos:

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

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

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

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

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

   Reemplaza lo siguiente:

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

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

Token

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

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

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

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

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

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

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

   Reemplaza lo siguiente:

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

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

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

   Reemplaza lo siguiente:

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

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

Cuenta de servicio de Google

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

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

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

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

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

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

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

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

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

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

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

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

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

Reemplaza lo siguiente:

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

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

Cuenta de servicio predeterminada de Compute Engine

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

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

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

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

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

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

Otorga al operador acceso de solo lectura a OCI

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

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

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

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

• Cuenta de servicio predeterminada de Compute Engine (gcenode)

Cuenta de servicio de Kubernetes

Si almacenas tu imagen de OCI en Artifact Registry y tu clúster usa Workload Identity Federation for GKE de GKE o Workload Identity Federation for GKE de la flota, puedes usar k8sserviceaccount como tu tipo de autenticación en la versión 1.17.2 y versiones posteriores. Se recomienda esta opción en lugar de gcpserviceaccount debido a su proceso de configuración simplificado.

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

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

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

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

   Reemplaza lo siguiente:

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

Cuenta de servicio de Google

Si almacenas tu imagen de OCI en Artifact Registry y tu clúster usa Workload Identity Federation for GKE o Workload Identity Federation for GKE de la flota, puedes usar gcpserviceaccount como tu tipo de autenticación. A partir de la versión 1.17.2, se recomienda usar k8sserviceaccount. Esta opción elimina los pasos adicionales para crear una cuenta de servicio de Google y la vinculación de políticas de IAM asociada.

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

2. Otorga el rol de IAM de lector de Artifact Registry (roles/artifactregistry.reader) a la cuenta de servicio de Google. Para obtener más información sobre los roles y permisos de Artifact Registry, consulta Configura roles y permisos para Artifact Registry.

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

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

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

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
        --project=PROJECT_ID
     

3. Para crear una vinculación de políticas de IAM entra la cuenta de servicio de Kubernetes y la cuenta de servicio de Google, ejecutando el siguiente comando:

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

Reemplaza lo siguiente:

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

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

Cuenta de servicio predeterminada de Compute Engine

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

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

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

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

Configura el operador para una autoridad certificadora

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

RootSync

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

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

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

3. Cuando configures el operador, establece el valor del campo caCertSecretRef.name en el objeto RootSync como ROOT_CA_CERT_SECRET_NAME.

RepoSync

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

2. En el caso de los objetos RepoSync, el Secret debe crearse en el mismo espacio de nombres que 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, establece el valor del campo caCertSecretRef.name en el objeto RepoSync en NAMESPACE_CA_CERT_SECRET_NAME.

Otorga al operador acceso de solo lectura a Helm

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

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

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

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

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

Token

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

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

Reemplaza lo siguiente:

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

Cuando configures el operador de ConfigManagement, usarás el nombre de Secret que elegiste para spec.helm.secretRef.name.

Cuenta de servicio de Kubernetes

Si almacenas tu gráfico de Helm en Artifact Registry y tu clúster usa GKE Workload Identity Federation for GKE o Workload Identity Federation for GKE para la flota de GKE, puedes usar k8sserviceaccount como tu tipo de autenticación en la versión 1.17.2 y versiones posteriores. Se recomienda esta opción en lugar de gcpserviceaccount debido a su proceso de configuración simplificado.

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

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

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

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

   Reemplaza lo siguiente:

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

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

Cuenta de servicio de Google

Si almacenas tu gráfico de Helm en Artifact Registry y tu clúster usa GKE Workload Identity Federation for GKE o GKE Workload Identity Federation for GKE para la flota de GKE, puedes usar gcpserviceaccount como tu tipo de autenticación. A partir de la versión 1.17.2, se recomienda usar k8sserviceaccount. Esta opción elimina los pasos adicionales para crear una cuenta de servicio de Google y la vinculación de políticas de IAM asociada.

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

2. Otorga el rol de IAM de lector de Artifact Registry (roles/artifactregistry.reader) a la cuenta de servicio de Google. Para obtener más información sobre los roles y permisos de Artifact Registry, consulta Configura roles y permisos para Artifact Registry.

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

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

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

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
        --project=PROJECT_ID
     

3. Para crear una vinculación de políticas de IAM entra la cuenta de servicio de Kubernetes y la cuenta de servicio de Google, ejecutando el siguiente comando:

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

Reemplaza lo siguiente:

• PROJECT_ID: El ID del proyecto de la organización.
• FLEET_HOST_PROJECT_ID: Si usas Workload Identity Federation for GKE de GKE, esto es lo mismo que PROJECT_ID. Si usas Workload Identity Federation for GKE de la flota para GKE, este es el ID del proyecto de la flota en la que está registrado tu clúster.
• GSA_NAME: La cuenta de servicio personalizada de Google que deseas usar para conectarte a Artifact Registry. La cuenta de servicio debe tener el rol de IAM de lector de Artifact Registry (roles/artifactregistry.reader).
• KSA_NAME: Es la cuenta de servicio de Kubernetes para el conciliador.
  • Para los repositorios raíz, si el nombre RootSync es root-sync, usa root-reconciler. De lo contrario, usa root-reconciler-ROOT_SYNC_NAME.
• REPOSITORY: el ID del repositorio.
• LOCATION: la ubicación regional o multirregional del repositorio.

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

Cuenta de servicio predeterminada de Compute Engine

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

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

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

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

Configura el operador

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

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

2. Crea un archivo llamado config-management.yaml y copia el siguiente archivo YAML en él:

   # config-management.yaml
   apiVersion: configmanagement.gke.io/v1
   kind: ConfigManagement
   metadata:
     name: config-management
   spec:
     # The `enableMultiRepo` field is set to true to enable RootSync and RepoSync APIs.
     enableMultiRepo: true
     preventDrift: PREVENT_DRIFT
   

   Reemplaza lo siguiente:

   • PREVENT_DRIFT: Si se configura como true, habilita el webhook de admisión del Sincronizador de configuración para evitar los desvíos mediante el rechazo de cambios conflictivos que se envían a clústeres activos. La configuración predeterminada es false. El Sincronizador de configuración siempre soluciona los desvíos, sin importar el valor de este campo.

3. Aplique los cambios:

   kubectl apply -f config-management.yaml
   

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

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

5. Guarda uno de los siguientes manifiestos como root-sync.yaml. Usa la versión del manifiesto que corresponda al tipo de fuente de tus parámetros de configuración.

   Git

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

   Reemplaza lo siguiente:

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

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

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

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

     Este campo es obligatorio.

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

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

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

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

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

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

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

   OCI

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

   Reemplaza lo siguiente:

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

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

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

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

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

     Este campo es obligatorio.

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

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

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

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

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

   Helm

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

   Reemplaza lo siguiente:

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

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

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

     Este campo es obligatorio.

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

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

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

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

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

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

6. Aplica los cambios:

   kubectl apply -f root-sync.yaml
   

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

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

nomos status

Deberías ver un resultado similar al siguiente:

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

Verifica la instalación de RootSync

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

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

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

Reemplaza ROOT_SYNC_NAME por el nombre de RootSync.

Deberías ver un resultado similar al siguiente:

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

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

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

Actualiza el Sincronizador de configuración

Nota: Si actualizas desde una versión anterior a 1.10.0, se eliminarán todos los recursos webhook de admisión de Sincronizador de configuración.

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

A fin de actualizar el Sincronizador de configuración, ejecuta estos comandos para cada clúster inscrito:

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

2. Aplica el manifiesto del Sincronizador de configuración:

   kubectl apply -f config-management-operator.yaml
   

   Este comando actualiza la imagen del operador de ConfigManagement. Kubernetes recupera la versión nueva y reinicia el Pod del Sincronizador de configuración con la versión nueva. Cuando se inicia el Sincronizador de configuración, se ejecuta un bucle de conciliación que aplica el conjunto de manifiestos agrupados en la imagen nueva. Esto actualiza y reinicia cada pod componente.

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

Desinstala el Sincronizador de configuración

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

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

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

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

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

      kubectl delete -f root-sync.yaml
      

2. Quita los repositorios.

3. Quita el campo spec.enableMultiRepo del archivo config-management.yaml.

4. Aplica el archivo config-management.yaml al clúster.

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

Si deseas desinstalar completamente el Sincronizador de configuración, consulta Quita el operador de ConfigManagement.

¿Qué sigue?

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