Instala de forma manual el Sincronizador de configuración y el controlador de políticas con kubectl

En esta página, se muestra cómo instalar el Sincronizador de configuración y el controlador de políticas mediante comandos kubectl.

Instala el Sincronizador de configuración

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.

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

  • El SDK de Cloud 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 los clústeres

Crea un clúster de GKE que cumpla con los requisitos del Sincronizador de configuración o accede a uno.

Prepara 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 la herramienta de línea de comandos de gcloud 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 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.

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.

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 o HTTP, agrégalo al Secret junto con cookiefile ejecutando el siguiente comando:

    kubectl create ns config-management-system && \
    kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-file=cookie_file=/path/to/COOKIEFILE \
     --from-literal=https_proxy=HTTPS_PROXY_URL \
     --from-literal=http_proxy=HTTP_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 *HTTP_PROXY_URL: La URL del proxy HTTP que usas cuando te comunicas con el repositorio de Git

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

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 la herramienta de línea de comandos de gcloud, 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 varía según si tienes Workload Identity habilitado en tu clúster:

    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 la función 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 la herramienta de línea de comandos de gcloud, 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.

      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/root-reconciler]" \
         GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
      

      Reemplaza lo siguiente:

      • PROJECT_ID: El ID del proyecto de tu organización
      • 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 la herramienta de línea de comandos de gcloud, 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 la función 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 el comportamiento el Sincronizador de configuración, debes crear un archivo de configuración para el CustomResource de ConfigManagement y, luego, aplicarlo mediante el comando kubectl apply:

  1. Crea un archivo 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 if you want to use ClusterSelectors and must be
      # unique among all managed clusters
      clusterName: CLUSTER_NAME
      # Enable multi-repo mode to use additional features
      enableMultiRepo: true
    

    Reemplaza CLUSTER_NAME por el nombre del clúster registrado en el que deseas aplicar esta configuración.

    Para obtener una lista completa de los campos que puedes agregar al campo spec, consulta Campos de ConfigManagement.

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

    kubectl apply -f config-management.yaml
    

    Si ves el siguiente error cuando intentas aplicar el archivo , 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.

    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-management.yaml --context=KUBE_CONFIG
    

    Reemplaza KUBE_CONFIG por el nombre del contexto de Kubernetes que deseas usar. El contexto de Kubernetes se almacena en el archivo kubeconfig.

  3. Crea un archivo root-sync.yaml y copia el siguiente archivo YAML en él.

    Para configurar la sincronización desde el repositorio raíz, debes crear un objeto RootSync que sincronice el repositorio raíz con el clúster. Para obtener más información, consulta Sincronizar desde varios repositorios.

    # root-sync.yaml
    # If you are using a Config Sync version earlier than 1.7,
    # use: apiVersion: configsync.gke.io/v1alpha1
    apiVersion: configsync.gke.io/v1beta1
    kind: RootSync
    metadata:
      name: root-sync
      namespace: config-management-system
    spec:
      sourceFormat: FORMAT
      git:
        repo: REPO
        branch: BRANCH
        dir: "DIRECTORY"
        auth: TYPE
        secretRef:
          name: SECRET_NAME
        # the `noSSLVerify` field is supported in Anthos Config Management version 1.8.2 and later.
        noSSLVerify: SSL_VERIFY
    

    Reemplaza lo siguiente:

    • 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.
    • REPO: Agrega la URL del repositorio de Git que se usará como fuente de información. 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.
    • BRANCH: Agrega la rama del repositorio desde la que se realiza la sincronización. El valor predeterminado es la rama principal (instancia principal).
    • DIRECTORY: la ruta de acceso en el repositorio de Git al directorio raíz que contiene la configuración con la que deseas sincronizar. La opción predeterminada es el directorio raíz del repositorio.
    • TYPE: Agrega uno de los siguientes SecretTypes:

      • none: No usa autenticación
      • ssh: Usa un par de claves SSH
      • cookiefile: Usa un objeto cookiefile
      • token: Usa un token
      • 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 a Git acceso de solo lectura al Sincronizador de configuración.

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

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

  4. Aplica RootSync a tu clúster:

    kubectl apply -f root-sync.yaml
Usa Cloud Source Repositories con Workload Identity

Si Workload Identity está habilitado en el clúster y usaste una cuenta de servicio de Google como tipo de autenticación, debes completar pasos adicionales.

Después de completar los pasos anteriores, crea una vinculación de política 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 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]" \
    PROJECT_NUMBER-compute@developer.gserviceaccount.com

Reemplaza lo siguiente:

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

Después de crear la vinculación, agrega una annotation a la cuenta de servicio del Sincronizador de configuración Kubernetes 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=PROJECT_NUMBER-compute@developer.gserviceaccount.com

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

Verifica la instalación del Sincronizador de configuración

Puedes usar el comando nomos status para verificar si el operador está instalado de forma correcta. 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 operador se implementa de forma correcta, se ejecuta en un Pod cuyo nombre comienza con config-management-operator. En Anthos Config Management versión 1.9.0 o posterior, este Pod está en el espacio de nombres config-management-system; en versiones anteriores, está en el espacio de nombres kube-system. La inicialización del Pod puede llevar unos minutos.

Para verificar que el Pod se ejecute en Anthos Config Management versión 1.9.0 o posterior, sigue estos pasos:

kubectl -n config-management-system get pods -l k8s-app=config-management-operator

Para verificar que el pod se ejecute en versiones anteriores a la 1.9.0, haz lo siguiente:

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

Si el Pod está en ejecución, la respuesta del comando es similar (pero no idéntica) a la siguiente:

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 config-management-system

El resultado del comando es similar al siguiente:

config-management-system Active 1m

Si los comandos no muestran una salida similar al que se muestra aquí, 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 secreto 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 página Soluciona problemas.

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.

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

Desinstalar el Sincronizador de configuración

Para desinstalar el Sincronizador de configuración, edita la configuración de Anthos Config Management en el archivo config-management.yaml, quita la sección git y aplícala al clúster.

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

Instalar Policy Controller

En las siguientes instrucciones, se muestra cómo instalar el Controlador de políticas.

De forma predeterminada, el controlador de políticas instala una biblioteca de plantillas de restricciones para tipos de políticas comunes. Para omitir la instalación de las plantillas de restricciones, quita el comentario de la línea que comienza con templateLibraryInstalled en el manifiesto.

  1. Configura el valor de enabled dentro del objeto spec.policyController como true en el archivo de configuración de Anthos Config Management:

    # config-management.yaml
    
    apiVersion: configmanagement.gke.io/v1
    kind: ConfigManagement
    metadata:
      name: config-management
    spec:
      # Set to true to install and enable Policy Controller
      policyController:
        enabled: true
        # Uncomment to prevent the template library from being installed
        # templateLibraryInstalled: false
        # Uncomment to enable support for referential constraints
        # referentialRulesEnabled: true
        # Uncomment to disable audit, adjust value to set audit interval
        # auditIntervalSeconds: 0
        # Uncomment to log all denies and dryrun failures
        # logDeniesEnabled: true
        # Uncomment to exempt namespaces
        # exemptableNamespaces: ["namespace-name"]
      # ...other fields...
    

    La compatibilidad para restricciones referenciales está inhabilitada según la configuración predeterminada. Antes de habilitarlo, asegúrate de comprender las advertencias sobre la coherencia eventual.

  2. Aplica la configuración mediante kubectl apply.

    kubectl apply -f config-management.yaml
    

Verifica el Controlador de políticas

Si el controlador de políticas se instala de forma adecuada, su Pod se encontrará en ejecución. Es posible que el Pod se reinicie varias veces antes de que esté disponible.

Dado que el pod del controlador de políticas se ejecuta en el espacio de nombres gatekeeper-system, puedes ejecutar el siguiente comando para ver su estado:

kubectl get pods -n gatekeeper-system

Deberías ver un resultado similar al siguiente:

NAME                              READY   STATUS    RESTARTS   AGE
gatekeeper-controller-manager-0   1/1     Running   1          53s

Desinstala el controlador de políticas

Para desinstalar el controlador de políticas, edita la configuración de Anthos Config Management en el archivo config-management.yaml y configura policyController.enabled como false. Después de que Anthos Config Management quita el finalizador policycontroller.configmanagement.gke.io, se completa la desinstalación.

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