Instala el Sincronizador de configuración

El Sincronizador de configuración permite que los operadores de clústeres administren los recursos de Kubernetes mediante archivos, conocidos como archivos de configuración, almacenados en repositorios de Git.

En esta página, se muestra cómo habilitar y configurar el Sincronizador de configuración como parte de Anthos Config Management. Sigue estos pasos para instalar y configurar Anthos Config Management en cada clúster que desees administrar.

Importante: Anthos Config Management requiere una autorización activa de Anthos. Para obtener más información, consulta la sección sobre cómo configurar Anthos. Si no usas Anthos, obtén información para instalar el Sincronizador de configuración sin Anthos Config Management.

Antes de comenzar

Antes de instalar el Sincronizador de configuración, asegúrate de haber preparado tu entorno, tus clústeres y tus funciones, y de haber habilitado Anthos Config Management.

Prepara tu entorno local

Completa las siguientes tareas para preparar tu entorno local:

1. Habilita la API de Anthos para tu proyecto:

   Console

   En Google Cloud Console, ve a la página API de Anthos.

   Ir a la página de API de Anthos

   • Haz clic en Habilitar.

   gcloud

   Ejecuta el siguiente comando:

   gcloud services enable anthos.googleapis.com
   

2. Instala y, luego, inicializa el SDK de Cloud, que proporciona los comandos gcloud, gsutil, kubectl y nomos que se usan en estas instrucciones. Si usas Cloud Shell, el SDK de Cloud viene preinstalado.

3. El SDK de Cloud no instala kubectl de forma predeterminada. Para instalar kubectl, usa el siguiente comando:

   gcloud components install kubectl
   

4. Usa el comando gcloud auth login para autenticarte en Google Cloud a fin de descargar los componentes de Anthos Config Management.

Prepara tu clúster

Completa las siguientes tareas para preparar tu clúster:

1. Asegúrate de que tu clúster esté en una plataforma y versión compatibles de Anthos.

2. Registra tu clúster en un entorno de Anthos mediante Connect. El entorno de tu proyecto proporciona una forma unificada de ver y administrar tus clústeres y sus cargas de trabajo como parte de Anthos, incluidos los clústeres fuera de Google Cloud. Los cargos de Anthos solo se aplican a tus clústeres registrados.

Prepara permisos

Según el método de instalación que uses, debes otorgarle al usuario que instala el Sincronizador de configuración diferentes permisos. Para obtener información sobre cómo otorgar funciones de administración de identidades y accesos (IAM), consulta la sección sobre cómo otorgar, cambiar y revocar el acceso a los recursos.

Console

El usuario de Google Cloud que instala el Sincronizador de configuración necesita la función Administrador de GKE Hub (roles/gkehub.admin) para administrar tu clúster mediante la API de Hub.

gcloud

El usuario de Google Cloud que instala el Sincronizador de configuración necesita la función Administrador de GKE Hub (roles/gkehub.admin) para administrar tu clúster mediante la API de Hub.

kubectl

Si usas GKE, el usuario de Google Cloud que instala el Sincronizador de configuración necesita permisos de IAM para crear funciones nuevas en tu clúster.

Por ejemplo:

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 la herramienta de línea de comandos de gcloud en tu sistema local, es posible que debas agregar los campos --project y --zone.

Habilita Anthos Config Management

Si usas Anthos Config Management por primera vez, puedes seguir estos pasos para habilitar la función.

Console

1. En Google Cloud Console, ve a la página Funciones de Anthos.

   Ir a la página Funciones de Anthos

2. En la fila Config Management, haz clic en Habilitar.

3. En la ventana de confirmación, haz clic en Habilitar Config Management.

gcloud

Ejecuta el siguiente comando:

 gcloud alpha container hub config-management enable

Instala el Sincronizador de configuración

En las siguientes secciones, le otorgas acceso al Sincronizador de configuración a tu repositorio. Luego de otorgar el acceso, configura la instalación.

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

El Sincronizador de configuración necesita acceso de solo lectura a tu repositorio de Git para que pueda leer las configuraciones confirmadas en el repositorio y aplicarlas a tus clústeres. Si se requieren credenciales, se almacenan en el secreto git-creds de cada clúster inscrito.

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 configurar secretType como none. 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 git-creds.

Sin embargo, la mayoría de los usuarios deben crear credenciales porque el acceso de lectura a su repositorio está restringido. El Sincronizador de configuración admite los siguientes mecanismos de autenticación:

• Par de claves SSH
• cookiefile
• Token
• Cuenta de servicio de Google (solo repositorios de Google Source Repository)

El mecanismo que elijas dependerá de lo que admita tu repositorio. Si todos los mecanismos están disponibles, te recomendamos usar un par de claves SSH. GitHub, Cloud Source Repositories y Bitbucket son compatibles con el uso de un par de claves SSH. Si tu organización aloja tu repositorio y no sabes qué métodos de autenticación se admiten, comunícate con tu administrador.

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. Borra la clave privada del disco local o protégela.

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.

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

   Reemplaza /path/to/COOKIEFILE por la ruta de acceso y el nombre de archivo adecuados.

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 los tokens de acceso personal (PAT) de GitHub 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 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.

   • Bitbucket: Crea una contraseña de la aplicación.

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

   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

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

Cuenta de servicio de Google

Nota: El gcenode secretType solo funciona en GKE en Google Cloud.

Si tu repositorio se encuentra en un repositorio de Cloud Source Repositories, puedes usar secretType: gcenode para otorgar al Sincronizador de configuración acceso a un repositorio en el mismo proyecto que tu clúster administrado.

Requisitos previos

Antes de comenzar, asegúrate de que se cumplan los siguientes requisitos:

• Los permisos de acceso para los nodos del clúster deben incluir cloud-source-repos-ro. De forma predeterminada, la cuenta de servicio predeterminada de Compute Engine [e-mail] tiene acceso source.reader al repositorio del mismo proyecto, pero, si es necesario, puedes agregar la función mediante el siguiente comando:

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

  Reemplaza lo siguiente:

  • PROJECT_ID: El ID del proyecto de tu organización
  • PROJECT_NUMBER: El número de proyecto de tu organización

• Los permisos de acceso para los nodos del clúster deben incluir cloud-source-repos-ro. Puedes agregar este permiso si incluyes cloud-source-repos-ro en la lista --scopes especificada en el momento de la creación del clúster o si usas el permiso cloud-platform en el momento de la creación del clúster:

  gcloud container clusters create example-cluster --scopes=cloud-platform
  

Nota: No puedes modificar los permisos de acceso luego de crear un grupo de nodos. Sin embargo, puedes crear un grupo de nodos nuevo con el permiso de acceso adecuado mientras usas el mismo clúster. El permiso gke-default predeterminado no incluye cloud-source-repos-ro.

Usa Cloud Source Repositories como tu SyncRepo

Una vez que se cumplan estos requisitos previos, configura spec.git.syncRepo para la URL del repositorio deseado en Cloud Source Repositories cuando configures el Sincronizador de configuración.

Para usar un repositorio en Cloud Source Repositories como tu SyncRepo, completa los siguientes pasos:

1. Enumera todos los repositorios:

   gcloud source repos list
   

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

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

3. Agrega la URL como tu syncRepo. Por ejemplo:

   spec.git.syncRepo: https://source.developers.google.com/p/my-project/r/my-repo-csr
   

Usa Cloud Source Repositories con Workload Identity

Si Workload Identity está habilitado en el clúster, se requieren pasos adicionales para usar secretType: gcenode. Después de completar los pasos anteriores y configurar el Sincronizador de configuración (lo cual harás en la siguiente sección), crea una vinculació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.

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

gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-system/importer]" \
  [e-mail]

Reemplaza PROJECT_ID por el ID del proyecto de tu organización.

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

Después de crear la vinculación, agrega una annotation a la cuenta de servicio de Kubernetes del Sincronizador de configuración mediante la dirección de correo electrónico de la cuenta de servicio predeterminada de Compute Engine:

kubectl annotate serviceaccount -n config-management-system importer \
  iam.gke.io/gcp-service-account=[e-mail]

Reemplaza PROJECT_NUMBER con el número de proyecto de tu organización.

Configura el Sincronizador de configuración

Google Cloud Console te guía a través del proceso de instalación y automatiza muchos de los pasos. También puedes usar la herramienta de línea de comandos de gcloud o los comandos de kubectl para completar la instalación.

Si usas un clúster de GKE, recomendamos que uses Cloud Console para configurar el Sincronizador de configuración. Si usas un clúster de GKE On-Prem, debes usar los comandos de kubectl para instalar el Sincronizador de configuración porque los registros privados no son compatibles con Cloud Console ni con la herramienta de gcloud.

Importante: No puedes instalar ni configurar Config Connector, el controlador de jerarquía ni varios repositorios en Cloud Console o mediante la herramienta de gcloud. Si deseas usar estas funciones, debes usar los comandos de kubectl para instalar el Sincronizador de configuración.

Para configurar el Sincronizador de configuración, completa los siguientes pasos.

Console

1. En Cloud Console, ve a la página Anthos Config Management.

   Ir a Anthos Config Management

2. Selecciona tus clústeres registrados y haz clic en Configurar.

3. En la sección Autenticación de repositorio de Git para ACM, selecciona una de las siguientes opciones:

   • Ninguno
   • SSH
   • Archivo cookie
   • Token
   • Google Cloud Repository

   Si aún no lo hiciste, otorga acceso de solo lectura al Sincronizador de configuración a Git.

4. Haz clic en Continuar.

5. En la sección Configuración de ACM para tus clústeres, completa los siguientes pasos:

   1. En el campo Versión, selecciona la versión para Anthos Config Management.
   2. Selecciona la casilla de verificación Habilitar el Sincronizador de configuración.
      1. En el campo URL, agrega la URL del repositorio de Git para usarla como fuente de información. Este campo es obligatorio.
      2. En el campo Rama, agrega la rama del repositorio desde la que deseas realizar la sincronización. El valor predeterminado es la rama principal (instancia principal). Este campo es obligatorio.
      3. En el campo Etiqueta/Confirmación, agrega la revisión de Git (etiqueta o hash) que se debe pagar. El predeterminado es HEAD.
      4. En el campo Directorio de políticas, agrega la ruta dentro del repositorio en la parte superior de la jerarquía de políticas que deseas sincronizar. La opción predeterminada es el directorio raíz del repositorio.
      5. En el campo Tiempo de espera de la sincronización, agrega el período en segundos entre las sincronizaciones consecutivas. El tiempo predeterminado es 15 segundos.
      6. En el campo Proxy de Git, ingresa la URL para el proxy HTTPS que se usará durante la comunicación con el repositorio de Git. Este es un campo opcional y, si se deja en blanco, no se usa ningún proxy.
      7. En el campo Formato fuente, elige si el repositorio tiene una jerarquía o si es no estructurada.

6. Haz clic en Listo. Volverás a la página Anthos Config Management. Después de unos minutos, deberías ver Synced en la columna de estado junto a los clústeres que configuraste. Si ves Error, haz clic en la palabra Error para obtener más información.

gcloud

1. 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:
     git:
       syncRepo: REPO
       syncBranch: BRANCH
       secretType: TYPE
       policyDir: "DIRECTORY"
   

   Reemplaza lo siguiente:

   • REPO: La URL del repositorio de Git que se usará como fuente de información. Este campo es obligatorio.
   • BRANCH: La rama del repositorio desde la que se realiza la sincronización. El valor predeterminado es la rama principal (instancia principal). Este campo es obligatorio.

   • TYPE: Uno de los siguientes SecretTypes:

     • none
     • ssh
     • cookiefile
     • token
     • gcenode

   • DIRECTORY: La ruta de acceso en el repositorio de la parte superior de la jerarquía de políticas que se sincronizará. La opción predeterminada es el directorio raíz del repositorio.

     Para obtener una lista completa de los campos que puedes agregar al campo spec, consulta la siguiente sección Configuración del repositorio de Git. No cambies los valores de configuración fuera del campo de especificación.

2. Aplica el archivo config-management.yaml:

    gcloud alpha container hub config-management apply \
        --membership=CLUSTER_NAME \
        --config=CONFIG_YAML_PATH \
        --project=PROJECT_ID
   

   Reemplaza lo siguiente:

   • CLUSTER_NAME: El nombre del clúster registrado en el que deseas aplicar esta configuración
   • CONFIG_YAML_PATH: La ruta de acceso a tu archivo config-management.yaml
   • PROJECT_ID: El ID de tu proyecto

kubectl

Cuando instalas el Sincronizador de configuración con kubectl, debes implementar el operador antes de configurarlo. El operador es un controlador que administra el Sincronizador de configuración en un clúster de Kubernetes.

Implementa el operador

Nota: Las instrucciones para instalar, implementar y desinstalar el operador no se aplican a los clústeres de usuario de GKE On-Prem. El operador se implementa automáticamente en GKE On-Prem y no puede quitarse.

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 operador CustomResourceDefinition (CRD) con el siguiente comando. En cambio, si deseas descargar una versión específica, consulta Descargas.

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

2. Aplica la CRD:

   kubectl apply -f config-management-operator.yaml

Si este comando falla, consulta la sección sobre solución de problemas.

Configura Anthos Config Management

Para configurar el comportamiento de Anthos Config Management, crea un archivo de configuración para el CustomResource de Config Management y, luego, aplícalo con el comando kubectl apply:

1. 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:
     # clusterName is required and must be unique among all managed clusters
     clusterName: CLUSTER_NAME
     git:
       syncRepo: REPO
       syncBranch: BRANCH
       secretType: TYPE
       policyDir: "DIRECTORY"
   

   Reemplaza lo siguiente:

   • CLUSTER_NAME: El nombre del clúster registrado en el que deseas aplicar esta configuración
   • REPO: La URL del repositorio de Git que se usará como fuente de información. Este campo es obligatorio.
   • BRANCH: La rama del repositorio desde la que se realiza la sincronización. El valor predeterminado es la rama principal (instancia principal). Este campo es obligatorio.

   • TYPE: Uno de los siguientes SecretTypes:

     • none
     • ssh
     • cookiefile
     • token
     • gcenode

   • DIRECTORY: La ruta de acceso en el repositorio de la parte superior de la jerarquía de políticas que se sincronizará. La opción predeterminada es el directorio raíz del repositorio.

   Nota: Si deseas almacenar config-management.yaml en tu repositorio de Git, debes configurar policyDir en un subdirectorio y colocar todos tus archivos de configuración dentro de ese subdirectorio. No coloques el archivo config-management.yaml en el subdirectorio policyDir.

   Para obtener una lista completa de los campos que puedes agregar al campo spec, consulta la siguiente sección Configuración del repositorio de Git. No cambies los valores de configuración fuera del campo de especificación.

2. Aplica la configuración con el comando kubectl apply:

   kubectl apply -f config-management.yaml
   

   Es posible que debas crear archivos de configuración separados para cada clúster o tipo de clúster. Puedes especificar el clúster mediante la opción --context:

   kubectl apply -f config-management1.yaml --context=CLUSTER_NAME
   

   Reemplaza CLUSTER_NAME por el nombre del clúster que deseas usar.

Revisa la instalación

Después de instalar y configurar el Sincronizador de configuración, puedes verificar que la instalación se haya completado correctamente.

Console

1. En Cloud Console, ve a la página Anthos Config Management.

   Ir a Anthos Config Management

2. Consulta la columna Estado. Si la instalación se realiza correctamente, tendrá el estado Synced.

Para obtener una vista detallada del estado del clúster, sigue estos pasos:

• Selecciona el clúster que deseas explorar. Aparecerá la página Detalles del clúster. En esta página, puedes ver los detalles de tu clúster y los detalles de la instalación del Sincronizador de configuración.

gcloud

Ejecuta el siguiente comando:

gcloud alpha container hub config-management status
    --project=PROJECT_ID

Reemplaza PROJECT_ID por el ID del proyecto.

Si la instalación se realiza correctamente, tendrá el estado SYNCED. Si ves un error después de ejecutar el comando anterior, asegúrate de haber creado el Secret git-creds. Si creaste el Secret, vuelve a ejecutar el siguiente comando:

gcloud alpha container hub config-management apply

kubectl

Para comprobar si el Sincronizador de configuración se instaló correctamente, puedes usar el comando nomos status. Una instalación válida sin problemas tiene el estado PENDING o SYNCED. Una instalación no válida o incompleta tiene el estado NOT INSTALLED o NOT CONFIGURED. La salida también incluye cualquier error informado.

Cuando el Sincronizador de configuración se implementa de forma correcta, se ejecuta en un Pod cuyo nombre comienza con config-management-operator en el espacio de nombres kube-system. La inicialización del Pod puede llevar unos minutos.

Verifica que el Pod se esté ejecutando.

kubectl -n kube-system get pods | grep config-management

Si el Pod se está ejecutando, la respuesta del comando es similar al siguiente ejemplo:

config-management-operator-6f988f5fdd-4r7tr 1/1 Running 0 26s

También puedes verificar que el espacio de nombres config-management-system exista:

kubectl get ns | grep 'config-management-system'

El resultado del comando es similar al siguiente ejemplo:

config-management-system Active 1m

Si los comandos no muestran un resultado similar al ejemplo anterior, consulta los registros para ver qué salió mal:

kubectl -n kube-system logs -l k8s-app=config-management-operator

También puedes usar kubectl get events para verificar si el Sincronizador de configuración creó algún evento.

kubectl get events -n kube-system

Es posible tener una configuración no válida que no se detecte de inmediato, como un Secret git-creds no especificado o no válido. Para ver los pasos de solución de problemas, consulta Objeto ConfigManagement válido, pero incorrecto en la sección sobre solución de problemas de esta página.

Actualiza las versiones de Anthos Config Management

En esta sección, se proporcionan instrucciones generales para actualizar a una nueva versión. Antes de realizar la actualización, consulta las notas de la versión para obtener instrucciones específicas.

Console

1. En Cloud Console, ve a la página Anthos Config Management.

   Ir a Anthos Config Management

2. Selecciona los clústeres que deseas actualizar.

3. Haz clic en Configurar.

4. Haz clic en Configuración de ACM para tus clústeres.

5. En el menú desplegable Versión, selecciona la versión a la que deseas actualizar.

6. Haz clic en Listo.

kubectl

Nota: No omitas versiones secundarias cuando realices la actualización con kubectl.

Ejecuta estos comandos para cada clúster inscrito:

1. Descarga el manifiesto de Anthos Config Management y los comandos de nomos para la versión nueva.

2. Aplica el manifiesto de Anthos Config Management:

   kubectl apply -f config-management-operator.yaml
   

   Este comando actualiza la imagen de Anthos Config Management. Kubernetes recupera la versión nueva y reinicia el Pod de Anthos Config Management mediante la versión nueva. Cuando se inicia Anthos Config Management, 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 o nomos.exe 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 de un clúster

Sigue estas instrucciones para desinstalar el Sincronizador de configuración de un clúster. Debes seguir estos pasos para cada clúster que ya no quieras administrar con el Sincronizador de configuración.

Notas sobre la desinstalación del Sincronizador de configuración

• El operador es una parte integral de GKE On-Prem. Se instala de forma automática y no se puede desinstalar desde un clúster de usuario de GKE On-Prem. Las instrucciones para la instalación, implementación y desinstalación de operadores solo se aplican a los clústeres de GKE.
• Desinstalar el Sincronizador de configuración no afecta la configuración del repositorio ni quita los archivos de configuración de los clústeres.
• Para poder desinstalar el Sincronizador de configuración de un clúster, el operador debe estar en ejecución.

Console

Precaución: No puedes inhabilitar el Sincronizador de configuración en Cloud Console. Si necesitas inhabilitar el Sincronizador de configuración, puedes usar la herramienta de gcloud. Sin embargo, puedes inhabilitar Anthos Config Management en Cloud Console. Si inhabilitas Anthos Config Management, se borrarán todas las configuraciones del Sincronizador de configuración de Google Cloud. Si luego decides volver a habilitar Anthos Config Management, debes volver a crear la configuración para cada clúster.

Para inhabilitar Anthos Config Management, completa los siguientes pasos:

1. En Google Cloud Console, ve a la página Funciones de Anthos.

   Ir a Funciones de Anthos

2. En la fila Config Management de la tabla Funciones, haz clic en Detalles. Aparecerá la página Resumen de estado.

3. Haz clic en Inhabilitar Config Management. Aparecerá una página de confirmación.

4. En la página de confirmación, haz clic en Inhabilitar Config Management.

gcloud

Ejecuta el siguiente comando:

gcloud alpha container hub config-management delete \
    --project=PROJECT_ID \
    --membership=CLUSTER_NAME

Reemplaza lo siguiente:

• CLUSTER_NAME: Es el nombre del clúster registrado del que deseas quitar esta configuración
• PROJECT_ID: El ID de tu proyecto

Nota: Borrar una configuración del Sincronizador de configuración borra la configuración de Google Cloud, pero no de tu clúster. Los informes de estado no cambian.

Para borrar todas las configuraciones y estados del Sincronizador de configuración, ejecuta el siguiente comando:

gcloud alpha container hub config-management disable \
    --project=PROJECT_ID

Reemplaza PROJECT_ID con el ID del proyecto.

kubectl

1. Borra el objeto ConfigManagement del clúster:

   kubectl delete configmanagement --all
   

   Sucederá lo siguiente:

   • Se borrarán del clúster todos los ClusterRoles y ClusterRoleBindings que creó el Sincronizador de configuración.
   • Se borrarán todas las opciones de configuración del controlador de admisión que instaló el Sincronizador de configuración.
   • Se borrarán los contenidos del espacio de nombres config-management-system, a excepción del Secret git-creds. El Sincronizador de configuración no puede funcionar sin el espacio de nombres config-management-system. Se quitarán las CustomResourceDefinitions (CRD) que el Sincronizador de configuración creó o modificó de los clústeres en los que se crearon o modificaron. La CRD necesaria para ejecutar el Sincronizador de configuración todavía existe porque, desde el punto de vista de Kubernetes, el usuario que instalaba el Sincronizador de configuración lo agregó. En el siguiente paso, se explica cómo quitar estos componentes.

2. En este punto, el operador aún existe en el clúster, pero no hace nada. Si estás utilizando GKE On-Prem, no puedes quitar el operador manualmente.

   Si usas GKE y decides que ya no deseas usar el Sincronizador de configuración, puedes desinstalarlo mediante los siguientes pasos:

   1. Verifica que el espacio de nombres config-management-system esté vacío después de borrar el objeto ConfigManagement en el paso anterior. Espera hasta que el comando kubectl -n config-management-system get all muestre No resources found..

   2. Borra el espacio de nombres config-management-system:

      kubectl delete ns config-management-system
      

   3. Borra la CustomResourceDefinition de ConfigManagement:

      kubectl delete crd configmanagements.configmanagement.gke.io
      

   4. Borra todos los objetos del Sincronizador de configuración del espacio de nombres kube-system:

      kubectl -n kube-system delete all -l k8s-app=config-management-operator
      

Soluciona problemas

En las siguientes secciones, encontrarás ayuda para solucionar problemas de instalación de Sincronizador de configuración.

Usa registros de auditoría

Los registros de auditoría pueden ser una herramienta de depuración útil.

Si instalaste el Sincronizador de configuración con Cloud Console o la herramienta de línea de comandos de gcloud, completa los siguientes pasos para usar los registros de auditoría a fin de investigar el Sincronizador de configuración.

Console

1. Habilita los registros de auditoría de las API de GKE Connect/Hub.

   1. En Cloud Console, ve a la página de Registros de auditoría de IAM.

      Ir a la página Registros de auditoría

   2. En la tabla, selecciona la casilla de verificación API de GKE Connect/Hub.

   3. Selecciona las siguientes casillas de verificación:

      • Lectura de administración
      • Lectura de datos
      • Escritura de datos

   4. Haz clic en Guardar.

2. Ir a la página Explorador de registros.

   Ir a la página Explorador de registros

3. En el cuadro de texto Compilador de consultas, agrega los siguientes filtros:

   resource.type="audited_resource" resource.labels.service="gkehub.googleapis.com"
   

4. Haz clic en Run Query.

5. En la sección Resultados de consultas, selecciona entradas para obtener más información sobre los eventos.

CPU insuficiente

La salida de kubectl get events podría incluir un evento con el tipo FailedScheduling. El evento se ve como en el siguiente ejemplo:

LAST SEEN   TYPE      REASON              OBJECT                                       MESSAGE
9s          Warning   FailedScheduling    pod/config-management-operator-74594dc8f6    0/1 nodes are available: 1 Insufficient cpu.

Para corregir este error, elige una de las siguientes opciones:

• agregar un nodo a un grupo de nodos de GKE existente, o
• crear un grupo de nodos con nodos más grandes

Error: intenta otorgar privilegios adicionales

Si ves el siguiente error cuando intentas aplicar el archivo config-management-operator.yaml, es posible que tengas menos permisos de los que se requieren para la instalación:

Error from server (Forbidden): error when creating "config-management-operator.yaml": clusterroles.rbac.authorization.k8s.io "config-management-operator" is forbidden: attempt to grant extra privileges: [...] ruleResolutionErrors=[]

A fin de asegurarte de que tienes los permisos necesarios, consulta la sección sobre cómo preparar los permisos.

Objeto ConfigManagement válido pero incorrecto

Si la instalación 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 ConfigManagement.

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.

Campos config-management.yaml

En las siguientes secciones, se explican los diferentes campos que puedes configurar en el archivo config-management.yaml.

Configuración del repositorio de Git

Clave	Descripción
spec.git.syncRepo	La URL del repositorio de Git que se usará como fuente de información. Obligatorio.
spec.git.syncBranch	La rama del repositorio desde la que se realiza la sincronización. Valor predeterminado: master.
spec.git.policyDir	La ruta de acceso dentro del repositorio de Git que representa el nivel superior del repositorio que se sincronizará. Opción predeterminada: el directorio raíz del repositorio.
spec.git.syncWait	Período en segundos entre sincronizaciones consecutivas. Valor predeterminado: 15.
spec.git.syncRev	Revisión de Git (etiqueta o hash) que puedes consultar. Opción predeterminada: HEAD.
spec.git.secretType	El tipo de secreto configurado para acceder al repositorio de Git: Es uno de los siguientes: ssh, cookiefile, token, gcenode o none. Obligatorio.
spec.sourceFormat	Cuando se establece en unstructured, configura un repositorio no jerárquico. Valor predeterminado: hierarchy.

Configuración del proxy para el repositorio de Git

Si las políticas de seguridad de tu organización requieren que enrutes el tráfico a través de un proxy HTTP(S), puedes usar el URI del proxy para configurar el Sincronizador de configuración a fin de que se comunique con tu host de Git.

Clave	Descripción
spec.git.proxy.httpProxy	Define una variable de entorno HTTP_PROXY que se usa para acceder al repositorio de Git.
spec.git.proxy.httpsProxy	Define una variable de entorno HTTPS_PROXY que se usa para acceder al repositorio de Git.

Si se especifican los campos httpProxy y httpsProxy, se ignora httpProxy.

Configuración del comportamiento del objeto ConfigManagement

Clave	Descripción
spec.clusterName	El nombre definido por el usuario para el clúster que ClusterSelectors usa a fin de agrupar clústeres. Es único dentro de la instalación del Sincronizador de configuración. No puedes configurar este campo en Cloud Console.

Configuración para integraciones

Estos campos permiten la integración con el conector de configuración y el controlador de políticas.

Clave	Descripción
spec.configConnector.enabled	Si es true, se instala Config Connector. La configuración predeterminada es false.
spec.policyController.enabled	Si es true, se habilita Policy Controller. La configuración predeterminada es false.
spec.policyController.templateLibraryInstalled	Si es true, se instala la biblioteca de plantillas de restricciones. La configuración predeterminada es true.

¿Qué sigue?

• Obtén más información sobre los comandos de gcloud para configurar el del Sincronizador de configuración con Anthos Config Management.
• Obtén más información para crear archivos de configuración.
• Usa el comando nomos.