Sincronizar desde varios repositorios

Habilitar el modo de varios repositorios en el Sincronizador de configuración te permite sincronizar configuraciones de varios repositorios con el mismo conjunto de clústeres. Para usar el modo de varios repositorios, debes crear un único repositorio raíz y, de manera opcional, puedes crear repositorios de espacio de nombres. Un repositorio raíz puede sincronizar archivos de configuración con permisos de clúster y con permisos de espacio de nombres y, por lo general, lo administra un administrador. Los repositorios de espacios de nombres contienen archivos de configuración con permiso de espacio de nombres que están sincronizados con un espacio de nombres particular en todos los clústeres. Para obtener más información sobre estos tipos de repositorios, consulta la sección Repositorios en la descripción general de Sincronizador de configuración.

Cada repositorio tiene una sola referencia de Git (una rama de repositorio, una confirmación o una etiqueta, y una tupla de directorio) que puedes administrar por separado. Esta configuración separa el ciclo de vida de la implementación de configuración para los diferentes equipos. También te brinda más autonomía para elegir dónde deseas alojar el repositorio y cómo estructurarlo.

En el siguiente diagrama, se muestra una descripción general de cómo los equipos pueden sincronizar sus clústeres en un solo repositorio raíz (administrado por un administrador) y varios repositorios de espacios de nombres (administrados por los operadores de la aplicación):

Un administrador central que controla varias configuraciones y operadores de apps que controlan sus propias configuraciones de espacios de nombres.

En el diagrama anterior, un administrador central administra la infraestructura centralizada de la organización y aplica políticas en el clúster y en todos los espacios de nombres de la organización. Los operadores de la aplicación, que son responsables de administrar las implementaciones en vivo, aplican configuraciones a las aplicaciones en los espacios de nombres en los que operan.

Antes de comenzar

Completa las siguientes tareas antes de habilitar el modo de varios repositorios:

  • Crear repositorios de Git o tener acceso a estos.
  • Crear un proyecto de Google Cloud o tener acceso a este.
  • Crear un clúster de Google Kubernetes Engine (GKE) que cumpla con los siguientes requisitos o tener acceso a este:
    • Es un clúster estándar. El Sincronizador de configuración no es compatible con los clústeres de Autopilot.
    • Usa una versión de GKE entre 1.18 y 1.21
  • Usa una versión de Sincronizador de configuración de 1.5.3 o posterior.
  • Si usas la versión 1.7 y, luego, instalas el Sincronizador de configuración en un clúster privado, agrega una regla de firewall para permitir el puerto 8676. El webhook de admisión del Sincronizador de configuración usa el puerto 8676 para la prevención de desvíos. A partir de la versión 1.8.0, el puerto cambia a 10250 y se abre de forma predeterminada en clústeres privados.

Limitaciones

Ten en cuenta las siguientes limitaciones cuando uses el modo de varios repositorios:

Configura la sincronización desde el repositorio raíz

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.

En las siguientes secciones, se describen tres métodos diferentes para habilitar el modo de varios repositorios:

  1. Si no instalaste el Sincronizador de configuración, crea una nueva configuración del repositorio de Git raíz.
  2. Si instalaste el Sincronizador de configuración, mueve la configuración del repositorio de Git raíz a RootSync.
  3. Si instalaste Config Sync y necesitas usar los campos spec.git, conserva la configuración del repositorio de Git raíz en el archivo YAML de ConfigManagement.

1. Nueva configuración

Si todavía no instalaste el Sincronizador de configuración, completa las siguientes tareas para habilitar el modo de varios repositorios:

  1. Completa las siguientes secciones en Instala el Sincronizador de configuración de forma manual:

    1. Antes de comenzar
    2. Implementa el operador
    3. Otorga al operador acceso de solo lectura a Git
  2. Si usas la versión 1.7 y, luego, instalas el Sincronizador de configuración en un clúster privado, agrega una regla de firewall para permitir el puerto 8676. El webhook de admisión del Sincronizador de configuración usa el puerto 8676 para la prevención de desvíos. A partir de la versión 1.8.0, el puerto cambia a 10250 y se abre de forma predeterminada en clústeres privados.

  3. 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:
      enableMultiRepo: true
    
  4. Aplique los cambios:

    kubectl apply -f config-management.yaml
    
  5. Crea un objeto RootSync:

    # root-sync.yaml
    # If you are using a Config Sync version earlier than 1.7.0,
    # use: apiVersion: configsync.gke.io/v1alpha1
    apiVersion: configsync.gke.io/v1beta1
    kind: RootSync
    metadata:
      name: root-sync
      namespace: config-management-system
    spec:
      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
        # the `noSSLVerify` field is supported in Anthos Config Management version 1.8.2 and later.
        noSSLVerify: ROOT_NO_SSL_VERIFY
    

    Reemplaza lo siguiente:

    • 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. Si no ingresas un protocolo, la URL se trata como una URL HTTPS. Este campo es obligatorio.
    • ROOT_REVISION: Agrega la revisión de Git (etiqueta o hash) que deseas consultar. Este campo es opcional y el valor predeterminado es HEAD.
    • 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.
    • 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 Workload Identity no está habilitado en tu clúster.

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

      Este campo es obligatorio.

    • ROOT_EMAIL: Si agregaste gcpserviceaccount como tu 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 usas un Secret, 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.

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.

  1. Aplica los cambios:

    kubectl apply -f root-sync.yaml
    

2. Mueve la configuración

Si ya instalaste el Sincronizador de configuración, puedes mover las configuraciones del repositorio de Git del objeto ConfigManagement existente a un objeto RootSync.

Si, para configurar el repositorio raíz, se mueve la configuración, completa las siguientes tareas:

  1. Si usas la versión 1.7 e instalaste el Sincronizador de configuración en un clúster privado, agrega una regla de firewall para permitir el puerto 8676. El webhook de admisión del Sincronizador de configuración usa el puerto 8676 para la prevención de desvíos. A partir de la versión 1.8.0, el puerto cambia a 10250 y se abre de forma predeterminada en clústeres privados.
  2. Abre el objeto ConfigManagement.
  3. Haz una copia de los valores en los campos spec.git. Usa estos valores cuando crees el objeto RootSync.
  4. Quita todos los campos spec.git (incluido git:) del objeto ConfigManagement.
  5. En el objeto ConfigManagement, establece el campo spec.enableMultiRepo en true:

    # config-management.yaml
    apiVersion: configmanagement.gke.io/v1
    kind: ConfigManagement
    metadata:
      name: config-management
    spec:
      enableMultiRepo: true
    
  6. Aplique los cambios:

    kubectl apply -f config-management.yaml
    
  7. Con los valores que copiaste del objeto ConfigManagement, crea el objeto RootSync. Por ejemplo:

    # root-sync.yaml
    # If you are using a Config Sync version earlier than 1.7.0,
    # use: apiVersion: configsync.gke.io/v1alpha1
    apiVersion: configsync.gke.io/v1beta1
    kind: RootSync
    metadata:
      name: root-sync
      namespace: config-management-system
    spec:
      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
    

    Reemplaza lo siguiente:

    • 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. Si no ingresas un protocolo, la URL se trata como una URL HTTPS. Este campo es obligatorio.
    • ROOT_REVISION: Agrega la revisión de Git (etiqueta o hash) que deseas consultar. Este campo es opcional y el valor predeterminado es HEAD.
    • 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.
    • 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 Workload Identity no está habilitado en tu clúster.

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

      Este campo es obligatorio.

    • ROOT_EMAIL: Si agregaste gcpserviceaccount como tu 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 usas un Secret, debes agregar la clave pública de Secret al proveedor de Git. Este campo es opcional.

  8. Aplique los cambios:

    kubectl apply -f root-sync.yaml
    

3. Mantén la configuración

Si ya instalaste el Sincronizador de configuración, puedes mantener un repositorio de Git raíz existente configurado en el objeto ConfigManagement. Sin embargo, no se recomienda este método, ya que dejará de estar disponible.

Para configurar el repositorio raíz manteniendo el repositorio raíz en el objeto ConfigManagement, completa las siguientes tareas:

  1. Si usas la versión 1.7 e instalaste el Sincronizador de configuración en un clúster privado, agrega una regla de firewall para permitir el puerto 8676. El webhook de admisión del Sincronizador de configuración usa el puerto 8676 para la prevención de desvíos. A partir de la versión 1.8.0, el puerto cambia a 10250 y se abre de forma predeterminada en clústeres privados.

  2. En el objeto ConfigManagement, configura los campos spec.enableMultiRepo y spec.enableLegacyFields en true, configuraspec.sourceFormat en unstructured para usar un repositorio no estructurado o hierarchy usa 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.

    # config-management.yaml
    apiVersion: configmanagement.gke.io/v1
    kind: ConfigManagement
    metadata:
      name: config-management
    spec:
      enableMultiRepo: true
      enableLegacyFields: true
      sourceFormat: FORMAT
      git:
        syncRepo: REPO
        syncBranch: BRANCH
        secretType: TYPE
        policyDir: "DIRECTORY"
    # ...other fields...
    
  3. Aplica los cambios:

    kubectl apply -f config-management.yaml
    

Aplicar config-management.yaml con enableMultiRepo: true y enableLegacyFields: true establecidos de forma automática genera el objeto RootSync en el clúster. No cambies la configuración de RootSync que se genera.

Para agregar repositorios de espacios de nombres opcionales, ve a la sección Configura la sincronización desde repositorios de espacios de nombres. Si solo deseas sincronizar desde un único repositorio y seguir usando el flujo de trabajo actual, puedes omitir esa sección.

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>   git@github.com: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 llamado 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 correctamente, verifica el estado de la implementación de root-reconciler:

kubectl get -n config-management-system deployment/root-reconciler

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 del objeto RootSync, consulta la sección Explora los objetos RootSync y RepoSync.

Configura la sincronización desde repositorios de espacios de nombres

Una vez que hayas configurado el repositorio raíz, puedes optar por configurar repositorios de espacios de nombres que los usuarios no administrativos puedan controlar. Los repositorios de espacios de nombres deben ser no estructurados.

Para configurar los repositorios de espacios de nombres, debes asignar permisos y crear un objeto RepoSync que sincronice el repositorio de espacio de nombres con el clúster. Puedes elegir entre dos métodos para configurar repositorios de espacios de nombres:

  • Controla los repositorios de espacio de nombres en el repositorio raíz. Este método centraliza toda la configuración de los repositorios de espacios de nombres en el repositorio raíz, lo que le proporciona a un administrador central el control completo de la configuración.

  • Controla los repositorios de espacios de nombres con la API de Kubernetes. Este método delega el control del repositorio de espacios de nombres a los propietarios de los espacios de nombres.

  • Opcional: Habilita el webhook de admisión en el repositorio del espacio de nombres. Si deseas habilitar el webhook de admisión del Sincronizador de configuración como un paso adicional para realizar la Prevención de desvío, sigue los pasos descritos en Habilita el webhook de admisión para el repositorio de espacio de nombres.

Controla los repositorios de espacio de nombres en el repositorio raíz

En este método, el administrador central administra la configuración de los repositorios de espacios de nombres directamente desde el repositorio raíz. Debido a que el Sincronizador de configuración administra los recursos del repositorio de espacios de nombres, este método evita cualquier cambio local en las definiciones del repositorio de espacios de nombres.

Para usar este método, completa las siguientes tareas:

  1. En el repositorio raíz, declara una configuración namespace:

    # ROOT_REPO/namespaces/NAMESPACE/namespace.yaml
    apiVersion: v1
    kind: Namespace
    metadata:
      name: NAMESPACE
    

    Reemplaza NAMESPACE por un nombre para el espacio de nombres.

  2. En el repositorio raíz, crea un objeto RepoSync en el mismo espacio de nombres:

    # ROOT_REPO/namespaces/NAMESPACE/repo-sync.yaml
     # If you are using a Config Sync version earlier than 1.8.0,
     # use: apiVersion: configsync.gke.io/v1alpha1
    apiVersion: configsync.gke.io/v1beta1
    kind: RepoSync
    metadata:
      name: repo-sync
      namespace: NAMESPACE
    spec:
      # Since this is for a namespace repository, the format should be unstructured
      sourceFormat: unstructured
      git:
       repo: NAMESPACE_REPOSITORY
       revision: NAMESPACE_REVISION
       branch: NAMESPACE_BRANCH
       dir: "NAMESPACE_DIRECTORY"
       auth: NAMESPACE_AUTH_TYPE
       gcpServiceAccountEmail: NAMESPACE_EMAIL
       secretRef:
         name: NAMESPACE_SECRET_NAME
       # the `noSSLVerify` field is supported in Anthos Config Management version 1.8.2 and later.
       noSSLVerify: NAMESPACE_NO_SSL_VERIFY
    

    Reemplaza lo siguiente:

    • NAMESPACE: Agrega el nombre de tu espacio de nombres.
    • NAMESPACE_REPOSITORY: agrega la URL del repositorio de Git para usarlo como repositorio de espacio de nombres. Puedes ingresar las URL con el protocolo HTTPS o SSH. Por ejemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa el protocolo HTTPS. Si no ingresas un protocolo, la URL se trata como una URL HTTPS. Este campo es obligatorio.
    • NAMESPACE_REVISION: Agrega la revisión de Git (etiqueta o hash) que deseas consultar. Este campo es opcional y el valor predeterminado es HEAD.
    • NAMESPACE_BRANCH: Agrega la rama del repositorio desde la que se realiza la sincronización. Este campo es opcional y el valor predeterminado es master.
    • NAMESPACE_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.
    • NAMESPACE_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 Workload Identity no está habilitado en tu clúster.

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

      Este campo es obligatorio.

    • NAMESPACE_EMAIL: Si agregaste gcpserviceaccount como tu 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

    • NAMESPACE_SECRET_NAME: Agrega el nombre que deseas darle a tu objeto Secret. Este campo es opcional.

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

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

    Puede haber, como máximo, un objeto RepoSync por espacio de nombres. Para aplicar esta restricción, el objeto name debe ser repo-sync. Todas las configuraciones que se encuentran en el directorio al que hace referencia RepoSync deben estar en el mismo espacio de nombres que el recurso RepoSync.

  3. En el repositorio raíz, declara una configuración RoleBinding que otorgue a la cuenta de servicio ns-reconciler-NAMESPACE permiso para administrar recursos en el espacio de nombres. El Sincronizador de configuración crea de forma automática la cuenta de servicio ns-reconciler-NAMESPACE cuando la configuración RepoSync se sincroniza con el clúster.

    Para declarar RoleBinding, crea el siguiente manifiesto:

    # ROOT_REPO/namespaces/NAMESPACE/sync-rolebinding.yaml
     kind: RoleBinding
     apiVersion: rbac.authorization.k8s.io/v1
     metadata:
       name: syncs-repo
       namespace: NAMESPACE
     subjects:
     - kind: ServiceAccount
       name: ns-reconciler-NAMESPACE
       namespace: config-management-system
     roleRef:
       kind: ClusterRole
       name: RECONCILER_ROLE
       apiGroup: rbac.authorization.k8s.io
    

    Reemplaza lo siguiente:

    • NAMESPACE: Agrega el nombre de tu espacio de nombres.
    • RECONCILER_ROLE: como administrador central, puedes configurar RECONCILER_ROLE para que se apliquen los tipos de configuración que se pueden sincronizar desde el repositorio de espacios de nombres. Puedes elegir una de las siguientes funciones:

      • Una ClusterRole predeterminada:

        • admin
        • edit

        Para obtener más información, consulta Funciones orientadas al usuario.

      • Un ClusterRole o Role definido por el usuario declarado en el repositorio raíz. Esta función admite permisos detallados.

  4. Confirme los cambios en el repositorio raíz:

     git add .
     git commit -m 'Setting up new namespace repository.'
     git push
    
  5. Si es necesario, crea un Secret según tu método de autenticación preferido. Si usaste none como el tipo de autenticación, puedes omitir este paso.

    El Secret debe cumplir con los siguientes requisitos:

    • Crea el Secret en el mismo espacio de nombres que RepoSync.
    • El nombre del Secret debe coincidir con el nombre de spec.git.secretRef que definiste en repo-sync.yaml.
    • Debes agregar la clave pública del Secret al proveedor de Git.
  6. Para verificar la configuración, usa kubectl get en uno de los objetos del repositorio de espacios de nombres. Por ejemplo:

    kubectl get rolebindings -n NAMESPACE
    

Controla los repositorios de espacios de nombres mediante la API de Kubernetes

En este método, el administrador central solo declara el espacio de nombres en el repositorio raíz y delega la declaración del archivo RepoSync al operador de la aplicación.

Tareas del administrador central

El administrador central completa las siguientes tareas:

  1. En el repositorio raíz, declara una configuración namespace:

    # ROOT_REPO/namespaces/NAMESPACE/namespace.yaml
     apiVersion: v1
     kind: Namespace
     metadata:
       name: NAMESPACE
    

    Reemplaza NAMESPACE por un nombre para el espacio de nombres.

  2. En el repositorio raíz, declara una configuración RoleBinding para otorgar permisos a los operadores de la aplicación. Usa la Prevención de elevación del RBAC para asegurarte de que el operador de la aplicación no pueda aplicar una vinculación de función con permisos que no otorga esta vinculación de función.

    Para declarar RoleBinding, crea el siguiente manifiesto:

    # ROOT_REPO/namespaces/NAMESPACE/operator-rolebinding.yaml
     kind: RoleBinding
     # Add RBAC escalation prevention
     apiVersion: rbac.authorization.k8s.io/v1
     metadata:
       name: operator
       namespace: NAMESPACE
     subjects:
     - kind: User
       name: USERNAME
       apiGroup: rbac.authorization.k8s.io
     roleRef:
       kind: ClusterRole
       name: OPERATOR_ROLE
       apiGroup: rbac.authorization.k8s.io
    

    Reemplaza lo siguiente:

    • NAMESPACE: Agrega el espacio de nombres que creaste al repositorio raíz.
    • USERNAME: Agrega el nombre de usuario del operador de la aplicación.
    • OPERATOR_ROLE: Como administrador central, puedes configurar OPERATOR_ROLE para aplicar de forma forzosa los tipos de configuraciones que se pueden sincronizar desde el repositorio de espacios de nombres. Puedes elegir una de las siguientes funciones:

      • Una ClusterRole predeterminada:

        • admin
        • edit

        Para obtener más información, consulta Funciones orientadas al usuario.

      • Una ClusterRole o una Role definida por el usuario que se declara en el repositorio raíz. Esta función admite permisos detallados.

  3. Confirme los cambios en el repositorio raíz:

     git add .
     git commit -m 'Setting up new namespace repository.'
     git push
    

Tareas del operador de la aplicación

El operador de la aplicación completa las siguientes tareas:

  1. Declara una configuración RoleBinding que otorga el permiso ns-reconciler-NAMESPACE de la cuenta de servicio aprovisionado de forma automática para administrar los recursos en el espacio de nombres. El Sincronizador de configuración crea de forma automática la cuenta de servicio ns-reconciler-NAMESPACE cuando la configuración RepoSync se sincroniza con el clúster.

    Para declarar RoleBinding, crea el siguiente manifiesto:

    # sync-rolebinding.yaml
    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: syncs-repo
      namespace: NAMESPACE
    subjects:
    - kind: ServiceAccount
      name: ns-reconciler-NAMESPACE
      namespace: config-management-system
    roleRef:
      kind: ClusterRole
      name: RECONCILER_ROLE
      apiGroup: rbac.authorization.k8s.io
    

    Reemplaza lo siguiente:

    • NAMESPACE: Agrega el espacio de nombres que creaste al repositorio raíz.
    • RECONCILER_ROLE: Como operador de la aplicación, puedes configurar RECONCILER_ROLE para aplicar los tipos de configuración que se pueden sincronizar desde el repositorio de espacios de nombres. Solo puedes restringir aún más el conjunto de permisos que te otorgó el administrador central. Como resultado, esta función no puede ser más permisiva que la OPERATOR_ROLE que el administrador central declaró en la sección anterior.
  2. Aplica la configuración de RoleBinding:

    kubectl apply -f sync-rolebinding.yaml
    
  3. Si es necesario, crea un Secret según tu método de autenticación preferido. Si usaste none como el tipo de autenticación, puedes omitir este paso.

    El Secret debe cumplir con los siguientes requisitos:

    • Crea el Secret en el mismo espacio de nombres que RepoSync.
    • El nombre del Secret debe coincidir con el nombre de spec.git.secretRef que definiste en root-sync.yaml.
    • Debes agregar la clave pública del Secret al proveedor de Git.
  4. Declara una configuración de RepoSync:

    # repo-sync.yaml
    # If you are using a Config Sync version earlier than 1.8.0,
    # use: apiVersion: configsync.gke.io/v1alpha1
    apiVersion: configsync.gke.io/v1beta1
    kind: RepoSync
    metadata:
      name: repo-sync
      namespace: NAMESPACE
    spec:
      # Since this is for a namespace repository, the format should be unstructured
      sourceFormat: unstructured
      git:
       repo: NAMESPACE_REPOSITORY
       revision: NAMESPACE_REVISION
       branch: NAMESPACE_BRANCH
       dir: "NAMESPACE_DIRECTORY"
       auth: NAMESPACE_AUTH_TYPE
       gcpServiceAccountEmail: NAMESPACE_EMAIL
       secretRef:
         name: NAMESPACE_SECRET_NAME
       # the `noSSLVerify` field is supported in Anthos Config Management version 1.8.2 and later.
       noSSLVerify: REPO_SSL_VERIFY
    

    Reemplaza lo siguiente:

    • NAMESPACE_REPOSITORY: agrega la URL del repositorio de Git para usarlo como repositorio de espacio de nombres. Puedes ingresar las URL con el protocolo HTTPS o SSH. Por ejemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa el protocolo HTTPS. Si no ingresas un protocolo, la URL se trata como una URL HTTPS. Este campo es obligatorio.
    • NAMESPACE_REVISION: Agrega la revisión de Git (etiqueta o hash) que deseas consultar. Este campo es opcional y el valor predeterminado es HEAD.
    • NAMESPACE_BRANCH: Agrega la rama del repositorio desde la que se realiza la sincronización. Este campo es opcional y el valor predeterminado es master.
    • NAMESPACE_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.
    • NAMESPACE_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 Workload Identity no está habilitado en tu clúster.

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

      Este campo es obligatorio.

    • NAMESPACE_EMAIL: Si agregaste gcpserviceaccount como tu 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

    • NAMESPACE_SECRET_NAME: Agrega el nombre que deseas darle a tu objeto Secret. Este campo es opcional.

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

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

    Puede haber, como máximo, un objeto RepoSync por espacio de nombres. Para hacer esto, el name del objeto debe ser repo-sync. Todas las configuraciones que se encuentran en el directorio al que hace referencia RepoSync deben estar en el mismo espacio de nombres que el recurso RepoSync.

  5. Aplica la configuración de RepoSync:

    kubectl apply -f repo-sync.yaml
    
  6. Para verificar la configuración, usa kubectl get en uno de los objetos del repositorio de espacios de nombres. Por ejemplo:

    kubectl get rolebindings -n NAMESPACE
    

Verifica el estado de sincronización del repositorio de espacio de nombres

Puedes usar el comando nomos status para inspeccionar el estado de sincronización del repositorio de espacio de nombres:

nomos status

Deberías ver un resultado similar al siguiente:

my_managed_cluster-1
  --------------------
  <root>   git@github.com:foo-corp/acme/admin@main
  SYNCED   f52a11e4
  --------------------
  bookstore  git@github.com:foo-corp/acme/bookstore@v1
  SYNCED     34d1a8c8

En este resultado de ejemplo, el repositorio del espacio de nombres se configura para el espacio de nombres llamado bookstore.

Verifica la instalación de RepoSync

Cuando creas un objeto RepoSync, el Sincronizador de configuración crea un conciliador llamado ns-reconciler-NAMESPACE, en el que NAMESPACE es el espacio de nombres en el que creaste el objeto RepoSync.

Para verificar que el objeto RepoSync funcione correctamente, verifica el estado de la implementación de ns-reconciler-NAMESPACE:

kubectl get -n config-management-system deployment/ns-reconciler-NAMESPACE

Reemplaza NAMESPACE por el espacio de nombres en el que creaste el repositorio de espacio de nombres.

Para conocer más formas de explorar el estado del objeto RepoSync, consulta la sección Explora los objetos RootSync y RepoSync.

Evita el desvío de la configuración

El Sincronizador de configuración reduce el riesgo de “operaciones en la sombra” mediante la detección de desvío. Cuando los cambios sin verificar se envían a clústeres activos, el Sincronizador de configuración detecta y soluciona cualquier desvío de la fuente de información en Git. Además, a partir de la versión 1.7.0, el modo de varios repositorios del Sincronizador de configuración proporciona un webhook de admisión que impide que los cambios conflictivos se envíen a los clústeres activos. Esto proporciona mejores comentarios de los usuarios cuando se intentan realizar cambios manuales, en lugar de permitirlos y solucionarlos de forma silenciosa.

Además, este webhook de admisión evita que los metadatos y las anotaciones del Sincronizador de configuración se modifiquen de forma manual, lo que generaría errores en la configuración de los conciliadores o el webhook de admisión.

Habilita el webhook de admisión en repositorios de espacios de nombres

El webhook de admisión que rechaza los cambios conflictivos para que no se envíen a los clústeres en vivo solo se instala cuando el Sincronizador de configuración está configurado en el modo de varios repositorios. De forma predeterminada, el webhook solo protege el repositorio raíz. Los repositorios de espacio de nombres no están protegidos por el webhook, ya que el conciliador del Sincronizador de configuración de cada repositorio de espacio de nombres no tiene permiso para leer o actualizar los objetos ValidtingWebhookConfiguration a nivel de clúster.

Esta falta de permiso da como resultado un error en los registros de los conciliadores de espacio de nombres, que es similar al siguiente:

  Failed to update admission webhook: KNV2013: applying changes to admission webhook: Insufficient permission. To fix, make sure the reconciler has sufficient permissions.: validatingwebhookconfigurations.admissionregistration.k8s.io "admission-webhook.configsync.gke.io" is forbidden: User "system:serviceaccount:config-management-system:ns-reconciler-NAMESPACE" cannot update resource "validatingwebhookconfigurations" in API group "admissionregistration.k8s.io" at the cluster scope

Este error se puede ignorar si no se necesita la protección de webhook para el repositorio del espacio de nombres. Sin embargo, si quieres agregar esta protección, completa los siguientes pasos a fin de otorgar este permiso al conciliador para cada repositorio de espacio de nombres.

Para usar este método, completa las siguientes tareas:

  1. En el repositorio raíz, declara una nueva configuración de ClusterRole que se usará para otorgar permiso al webhook de admisión de configuración del Sincronizador de configuración. Este ClusterRole solo se debe definir una vez por clúster:

    # ROOT_REPO/cluster-roles/webhook-role.yaml
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: admission-webhook-role
    rules:
    - apiGroups: ["admissionregistration.k8s.io"]
      resources: ["validatingwebhookconfigurations"]
      resourceNames: ["admission-webhook.configsync.gke.io"]
      verbs: ["get", "update"]
    
  2. Para cada repositorio de espacio de nombres en el que se debe otorgar el permiso de webhook de admisión, declara una configuración ClusterRoleBinding para otorgar el acceso:

    # ROOT_REPO/NAMESPACE/sync-webhook-rolebinding.yaml
    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: syncs-webhook
    subjects:
    - kind: ServiceAccount
      name: ns-reconciler-NAMESPACE
      namespace: config-management-system
    roleRef:
      kind: ClusterRole
      name: admission-webhook-role
      apiGroup: rbac.authorization.k8s.io
    

    Reemplaza NAMESPACE por un nombre para el espacio de nombres.

  3. Confirme los cambios en el repositorio raíz:

    git add .
    git commit -m 'Providing namespace repository the permission to update the admission webhook.'
    git push
    
    
  4. Para verificar, usa kubectl a fin de asegurarte de que se hayan creado ClusterRole y ClusterRoleBinding:

    kubectl get clusterrole admission-webhook-role
    kubectl get clusterrolebindings syncs-webhook
    

Detener y reanudar la sincronización

Si deseas obtener más información sobre cómo detener la sincronización desde varios repositorios, consulta Detén y reanuda la sincronización desde varios repositorios.

Quita los repositorios raíz y de espacios de nombres

Quita un repositorio de espacio de nombres

Selecciona la pestaña Método del repositorio raíz o Método de la API de Kubernetes para ver las instrucciones relevantes.

Método del repositorio raíz

Si usaste el método Control de repositorios de espacios de nombres en el repositorio raíz, un administrador central puede seguir los dos pasos siguientes para quitar un repositorio de espacios de nombres:

  1. Para administrar o borrar los recursos administrados por el objeto RepoSync, sigue las instrucciones para solucionar problemas.

  2. Quita el objeto RepoSync del repositorio de Git.

Método de la API de Kubernetes

Si usaste el método Controla repositorios de espacios de nombres con la API de Kubernetes, los operadores de aplicaciones pueden seguir estos dos pasos para quitar un repositorio de espacio de nombres:

  1. Para administrar o borrar los recursos administrados por el objeto RepoSync, sigue las instrucciones para solucionar problemas.

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

    kubectl delete -f repo-sync.yaml
    

Quita el repositorio raíz

Un administrador central puede quitar el repositorio raíz mediante los siguientes dos pasos:

  1. Para dejar de administrar o borrar los recursos administrados por el objeto RootSync, sigue las instrucciones para solucionar problemas.

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

     kubectl delete -f root-sync.yaml
    

Explora los objetos RootSync y RepoSync

En las siguientes secciones, se muestran diferentes formas de explorar los objetos RootSync y RepoSync.

Cómo ver registros

Para obtener más información sobre posibles errores, puedes ver los registros de los objetos RootSync y RepoSync.

Para ver los registros del conciliador de RootSync, ejecuta el siguiente comando:

kubectl logs -n config-management-system deployment/root-reconciler CONTAINER_NAME

Reemplaza CONTAINER_NAME por git-sync, reconciler o otel-agent. El contenedor git-sync extrae los archivos de configuración de un repositorio de Git a un directorio local del que puede leer el contenedor del conciliador. El contenedor reconciler aplica esos archivos de configuración al clúster. El contenedor otel-agent es un agente de OpenTelemetry para recuperar y exportar métricas del Sincronizador de configuración.

Para ver los registros del conciliador de RepoSync, ejecuta el siguiente comando:

kubectl logs -n config-management-system deployment/ns-reconciler-NAMESPACE CONTAINER_NAME

Reemplaza lo siguiente:

  • NAMESPACE: el espacio de nombres en el que creaste el repositorio del espacio de nombres.
  • CONTAINER_NAME: puede ser git-sync, reconciler o otel-agent

Visualiza las confirmaciones sincronizadas

Puedes comprobar qué confirmación se sincroniza con el clúster.

Para ver los detalles de RootSync, ejecuta el siguiente comando:

kubectl get rootsync root-sync -n config-management-system

Para ver los detalles de RepoSync, ejecuta el siguiente comando:

kubectl get reposync repo-sync -n config-management-system

Deberías ver un resultado similar al siguiente:

NAME        SOURCECOMMIT                               SYNCCOMMIT
root-sync   66882815f0ef5517df27e864fb1315e97756ab72   66882815f0ef5517df27e864fb1315e97756ab72

El valor en la columna SOURCECOMMIT es la confirmación del repositorio de Git que se debe sincronizar con el clúster. El valor en la columna SYNCCOMMIT es la confirmación que se implementa actualmente en el clúster. Si los dos valores de las columnas SOURCECOMMIT y SYNCCOMMIT son los mismos, la confirmación esperada se implementó en el clúster.

Visualiza los detalles del objeto

Para ver los detalles de los objetos RootSync y RepoSync, usa kubectl describe. Este comando puede brindarte más información sobre posibles errores.

Para ver los detalles del objeto RootSync, ejecuta el siguiente comando:

kubectl describe rootsync root-sync -n config-management-system

Para ver los detalles del objeto RepoSync, ejecuta el siguiente comando:

kubectl describe reposync repo-sync -n config-management-system

Visualiza si un recurso está listo

Para saber si los recursos sincronizados con el clúster están listos, consulta el estado de conciliación. Por ejemplo, este comando puede mostrarte si una implementación sincronizada está lista para entregar el tráfico.

Para un repositorio de Git sincronizado con el clúster, el estado de conciliación de todos los recursos se agrega en un recurso llamado ResourceGroup. Para cada objeto RootSync o RepoSync, se genera un ResourceGroup a fin de capturar el conjunto de recursos aplicados al clúster y los estados agregados.

Para ver el estado de conciliación del objeto RootSync, ejecuta el siguiente comando:

kubectl get resourcegroup.kpt.dev root-sync -n config-management-system -o yaml

Para ver el estado de conciliación del objeto RepoSync, ejecuta el siguiente comando:

kubectl get resourcegroup.kpt.dev repo-sync -n NAMESPACE -o yaml

En el resultado, verás todos los estados de los recursos de ResourceGroup. Por ejemplo, el siguiente resultado muestra que una implementación llamada nginx-deployment está lista:

resourceStatuses:
- group: apps
  kind: Deployment
  name: nginx-deployment
  namespace: default
  status: Current

¿Qué sigue?