Instala el Sincronizador de configuración de forma manual con kubectl

En esta página, se muestra cómo instalar el Sincronizador de configuración mediante los comandos de kubectl. El operador del Administración de configuración 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.

Si configuras el Sincronizador de configuración con los comandos kubectl que se describen en esta página, más adelante puedes realizar cambios en la configuración con Google Cloud Console o Google Cloud CLI. Sin embargo, cuando realizas cambios de configuración mediante la consola de Google Cloud o la CLI de gcloud, no puedes volver a usar los comandos kubectl para los cambios de configuración.

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:

  • Crea un repositorio de Git que pueda contener los archivos de configuración con los que se sincroniza el Sincronizador de configuración, o bien accede a un repositorio con estas características.

  • Instala e inicializa Google Cloud CLI, que proporciona los comandos gcloud, gsutil, 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 GKE que cumpla con los requisitos del Sincronizador de configuración o accede 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.

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

    gsutil 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, consulta Solución de problemas.

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
  • cookiefile
  • Token
  • Cuenta de servicio de Google (solo Cloud Source Repositories)

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.

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.

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.

  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:

  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.

  5. 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://EMAIL@source.developers.google.com: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: El nombre del repositorio.

Archivo cookie

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

  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.

  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

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

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

  1. Recupera tu 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 Google Cloud Console, 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.

  2. Cuando configures el Sincronizador de configuración, selecciona el tipo de autenticación adecuado. El tipo de autenticación que debes elegir difiere según el tipo de clúster que tengas y la forma en que habilitaste Workload Identity.

    • Workload Identity habilitada: Usa este método si tienes habilitada Workload Identity de GKE o si usas Workload Identity de la flota. Si usas Workload Identity de la flota, puedes usar este método de autenticación para clústeres de GKE y que no son de GKE.

    • Workload Identity no está habilitado: Solo puedes usar el método para los clústeres de GKE.

    Workload Identity habilitado.

    1. Si es necesario, crea una cuenta de servicio. Asegúrate de que la cuenta de servicio tenga acceso de lectura a Cloud Source Repositories. Para ello, otórgale el rol source.reader.

    2. Si configuras el Sincronizador de configuración con Google Cloud Console, selecciona Workload Identity 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.

    3. 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. 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 \
   --role roles/iam.workloadIdentityUser \
   --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
   GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

      Reemplaza lo siguiente:

      • PROJECT_ID: si usas Workload Identity de GKE, agrega el ID del proyecto de tu organización.

        Si usas Workload Identity de la flota, puedes usar dos ID de proyectos diferentes. En serviceAccount:PROJECT_ID, agrega el ID del proyecto de la flota a la que está registrado tu clúster. En GSA_NAME@PROJECT_ID, agrega un ID del proyecto a cualquier proyecto que tenga acceso de lectura al repositorio en Cloud Source Repositories.

      • KSA_NAME: Es la cuenta de servicio de Kubernetes para el conciliador. Para los repositorios raíz, si el nombre de RootSync es root-sync, KSA_NAME es root-reconciler. De lo contrario, es root-reconciler-ROOT_SYNC_NAME.

        Para los repositorios de espacio de nombres, si el nombre de RepoSync es repo-sync, KSA_NAME es ns-reconciler-NAMESPACE. De lo contrario, es ns-reconciler-NAMESPACE-REPO_SYNC_NAME.

      • GSA_NAME: Es la cuenta de servicio de Google personalizada que deseas usar para conectarte a Cloud Source Repositories. Asegúrate de que la cuenta de servicio de Google que selecciones tenga la función source.reader.

    Workload Identity no habilitado

    Si configuras el Sincronizador de configuración con Google Cloud Console, 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. De forma predeterminada, la cuenta de servicio predeterminada de Compute Engine PROJECT_ID-compute@developer.gserviceaccount.com tiene acceso source.reader al repositorio del mismo proyecto. Sin embargo, si Cloud Source Repositories se encuentra en un proyecto diferente del proyecto de tu clúster, debes otorgar a la cuenta de servicio de Compute Engine predeterminada del proyecto del clúster, source.reader en el proyecto de Cloud Source Repositories.

    Puedes agregar el rol source.reader con el siguiente comando:

    gcloud projects add-iam-policy-binding PROJECT_ID \
  --member serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
  --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

    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.

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 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. A partir de la versión 1.10.0, el webhook de admisión del Sincronizador de configuración está inhabilitado de forma predeterminada.

  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
  # The `preventDrift` field is supported in Anthos Config Management version 1.10.0 and later.
  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. 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_NAME
  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_SYNC_NAME: Agrega el nombre de tu objeto RootSync. Para las versiones anteriores a la 1.11.0, debe ser root-sync. Para la versión 1.11.0 o una posterior, especifica el nombre que prefieras.
    • 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) 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 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 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.

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

Para la versión del Sincronizador de configuración anterior a la 1.11.0:

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

Para el Sincronizador de configuración versión 1.11.0 y posteriores:

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

A fin de actualizar el Sincronizador de configuración, 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. En las versiones de 1.9.0 y posteriores, el operador de la Administración de la configuración se instala en el espacio de nombres config-management-system, en lugar del espacio de nombres kube-system. Si actualizas de una versión anterior a la 1.9.0 a una versión 1.9.0 o posterior, debes borrar el operador de Config Management anterior del espacio de nombres kube-system:

    kubectl delete -n kube-system serviceaccounts config-management-operator
kubectl delete -n kube-system deployments config-management-operator

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

Desinstalar el Sincronizador de configuración

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

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

    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

  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.

Si deseas desinstalar Anthos Config Management por completo, consulta Quita el operador de Config Management.

¿Qué sigue?