Configurar Config Controller

En esta página se explica cómo configurar Config Controller.

Config Controller proporciona un plano de control gestionado basado en Kubernetes. Además, las instancias de Config Controller vienen preinstaladas con Policy Controller, Config Sync y Config Connector. Al usar estos componentes, puedes usar las herramientas y los flujos de trabajo de Kubernetes para gestionar recursos y lograr la coherencia mediante un flujo de trabajo de GitOps. Google CloudPara obtener más información, consulte la descripción general de Config Controller.

Si vas a crear una instancia de Config Controller por primera vez, consulta la guía de inicio rápido sobre cómo gestionar recursos con Config Controller.

Limitaciones

  • Como las instancias de Config Controller están totalmente gestionadas, no puedes registrarlas en una flota.

Antes de empezar

Antes de configurar Config Controller, completa los siguientes pasos:

  1. Instala e inicializa la Google CloudCLI, que proporciona la CLI de Google Cloud que se usa en estas instrucciones. Si usas Cloud Shell, Google Cloud CLI ya está instalado.
  2. Como kubectl no está instalado de forma predeterminada en la Google Cloud CLI, instálalo:

    gcloud components install kubectl
    
  3. Define el Google Cloud proyecto en el que quieras alojar Config Controller:

    gcloud config set project PROJECT_ID
    

    Sustituye PROJECT_ID por el Google Cloud proyecto que alojará Config Controller.

  4. Habilita las APIs necesarias:

    gcloud services enable krmapihosting.googleapis.com \
        container.googleapis.com  \
        cloudresourcemanager.googleapis.com \
        serviceusage.googleapis.com
    

Crear una instancia de Config Controller

Puedes crear una instancia de Config Controller respaldada por un clúster estándar o un clúster de Autopilot. Ambos tipos de clústeres son privados.

Selecciona un clúster estándar si quieres más opciones de personalización. Selecciona un clúster de Autopilot si quieres una instalación más rápida, el autoescalado horizontal y vertical de pods, y funciones de seguridad mejoradas, como SO optimizado para contenedores, nodos de GKE blindados, Workload Identity Federation para GKE y Arranque seguro.

La creación de un clúster puede tardar hasta 15 minutos en completarse. Si quieres observar lo que ocurre durante la creación, puedes ver el Explorador de registros en laGoogle Cloud consola.

Ir al Explorador de registros

Si se producen errores durante la creación, consulta Solucionar problemas de Config Controller para obtener información sobre cómo resolver problemas habituales.

Crear un clúster de Autopilot

Para crear una instancia de Config Controller en un clúster de Autopilot, ejecuta el siguiente comando:

gcloud anthos config controller create CONFIG_CONTROLLER_NAME \
    --location=LOCATION \
    --full-management

Haz los cambios siguientes:

  • CONFIG_CONTROLLER_NAME: el nombre que quieras darle a tu instancia de Config Controller.
  • LOCATION: la ubicación en la que quieres crear tu instancia de Config Controller, por ejemplo, us-central. Para ver una lista de las ubicaciones admitidas, consulta Ubicaciones.

Crear un clúster estándar

Para crear una instancia de Config Controller en un clúster Standard, ejecuta el siguiente comando:

gcloud anthos config controller create CONFIG_CONTROLLER_NAME \
    --location=LOCATION

Haz los cambios siguientes:

  • CONFIG_CONTROLLER_NAME: el nombre que quieras darle a tu instancia de Config Controller.
  • LOCATION: la ubicación en la que quieres crear tu instancia de Config Controller, por ejemplo, us-central. Para ver una lista de las ubicaciones admitidas, consulta Ubicaciones.

Puedes definir varios parámetros opcionales al crear una instancia de Config Controller estándar. Para ver la lista completa de opciones, consulta la documentación de gcloud anthos config controller create.

Confirmar la instancia de Config Controller

Para confirmar que tu instancia de Config Controller está configurada, sigue estos pasos:

  1. Para verificar que se han creado las instancias de Config Controller, consulte la lista de instancias de Config Controller:

    gcloud anthos config controller list --location=LOCATION
    

    Debería ver el valor RUNNING en la columna de estado. Si el estado es CREATING, significa que tu instancia de Config Controller aún se está creando y debes seguir esperando. Si ves el icono ERROR, significa que has detectado un problema que no puedes resolver por tu cuenta. Ponte en contacto con el equipo de Asistencia de Google Cloudpara obtener ayuda.

  2. Para comunicarte con el endpoint de Config Controller, obtén las credenciales y la información del endpoint adecuadas:

    gcloud anthos config controller get-credentials CONFIG_CONTROLLER_NAME \
        --location LOCATION
    

Usar tu instancia de Config Controller

Ahora que has creado una instancia de Config Controller, puedes empezar a usar los componentes instalados y completar las siguientes tareas:

  • Usa Config Connector para crear Google Cloud recursos. Si tienes Google Cloud recursos que quieres usar con Config Controller, consulta cómo adquirir un recurso.

  • Usa Policy Controller para aplicar restricciones que cumplan las normativas y los estándares de Kubernetes.

  • Después de configurar Config Sync, en la siguiente sección, sincroniza tu instancia de Config Controller con las configuraciones (incluidas las restricciones de Policy Controller y los recursos de Config Connector) que se almacenan en una fuente de información veraz.

Para ver un ejemplo guiado que te muestre cómo completar estas tareas con Config Controller, consulta Guía de inicio rápido: gestiona recursos con Config Controller.

Configurar la instancia de Config Controller

En las siguientes secciones se explica cómo configurar los componentes de tu instancia de Config Controller.

Configurar Config Connector

No es necesario que gestione ningún ajuste para la instalación de Config Connector. Sin embargo, debes conceder permisos a Config Controller para gestionar los recursos deGoogle Cloud :

  1. Define una variable de entorno para el correo de tu cuenta de servicio:

    export SA_EMAIL="$(kubectl get ConfigConnectorContext -n config-control \
        -o jsonpath='{.items[0].spec.googleServiceAccount}' 2> /dev/null)"
    
  2. Crea el enlace de la política:

    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member "serviceAccount:${SA_EMAIL}" \
        --role "ROLE" \
        --project PROJECT_ID
    

    Haz los cambios siguientes:

    Si la operación anterior falla, comprueba si los controladores están listos:

    kubectl wait pod --all --all-namespaces --for=condition=Ready
    

Una vez que hayas concedido estos permisos, podrás empezar a crear Google Cloud recursos.

Configurar Policy Controller

Es posible que tengas que añadir o actualizar la política de gestión de identidades y accesos para permitir que Policy Controller envíe métricas.

Permite que Policy Controller envíe métricas ejecutando este comando:

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:PROJECT_ID.svc.id.goog[gatekeeper-system/gatekeeper-admin]" \
  --role=roles/monitoring.metricWriter

Sustituye PROJECT_ID por el ID del proyecto del clúster. Google Cloud

Configurar Config Sync

Si quieres que tu instancia de Config Controller se sincronice con las configuraciones almacenadas en una fuente de información fiable, debes configurar Config Sync.

Si quieres usar Config Sync para crear recursos de Config Connector, asegúrate de que también has concedido permiso a Config Controller para gestionar recursos.

Para configurar Config Sync, crea y edita un objeto RootSync:

  1. Para sincronizar desde un repositorio externo (por ejemplo, GitHub), configura Cloud NAT con GKE. Debes hacerlo porque los nodos de clúster privado no tienen acceso de salida a Internet.

  2. Guarda uno de los siguientes manifiestos como root-sync.yaml. Usa la versión del manifiesto que corresponda al tipo de fuente de tus configuraciones.

    Git

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

    Haz los cambios siguientes:

    • ROOT_SYNC_NAME: añade el nombre de tu objeto RootSync.
    • ROOT_FORMAT: añade unstructured para usar un repositorio no estructurado o añade hierarchy para usar un repositorio jerárquico. En estos valores se distingue entre mayúsculas y minúsculas. Este campo es opcional y su valor predeterminado es hierarchy. Te recomendamos que añadas unstructured, ya que este formato te permite organizar tus configuraciones de la forma que te resulte más cómoda.
    • ROOT_REPOSITORY: añade la URL del repositorio de Git que quieras usar como repositorio raíz. Puede introducir URLs 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: añade la revisión de Git (etiqueta o hash) o la rama desde la que se sincronizarán los datos. Este campo es opcional y su valor predeterminado es HEAD. Cuando se usa un hash, debe ser un hash completo y no una forma abreviada.
    • ROOT_BRANCH: añade la rama del repositorio desde la que se hace la sincronización. Este campo es opcional y su valor predeterminado es master. Te recomendamos que uses el campo revision para especificar un nombre de rama por simplicidad. Si se especifican tanto el campo revision como el campo branch, revision tiene prioridad sobre branch.
    • ROOT_DIRECTORY: añade la ruta del repositorio de Git al directorio raíz que contiene la configuración que quieres sincronizar. Este campo es opcional y el valor predeterminado es el directorio raíz (/) del repositorio.
    • ROOT_AUTH_TYPE: añade uno de los siguientes tipos de autenticación:

      • none: no usar autenticación
      • ssh: usar un par de claves SSH
      • cookiefile: usa un cookiefile
      • token: usar 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 Federation para GKE no está habilitado en tu clúster.

      Para obtener más información sobre estos tipos de autenticación, consulta el artículo Conceder acceso de solo lectura a Git a Config Sync.

      Este campo es obligatorio.

    • ROOT_EMAIL: Si has añadido gcpserviceaccount como tu ROOT_AUTH_TYPE, añade la dirección de correo de tu cuenta de servicio de Google. Por ejemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

    • ROOT_SECRET_NAME: añade el nombre del secreto. Si se define este campo, debes añadir la clave pública del secreto al proveedor de Git. Este campo es opcional.

    • ROOT_NO_SSL_VERIFY: para inhabilitar la verificación del certificado SSL, asigna el valor true a este campo. El valor predeterminado es false.

    • ROOT_CA_CERT_SECRET_NAME: añade el nombre de tu secreto. Si se define este campo, tu proveedor de Git debe usar un certificado emitido por esta autoridad de certificación (CA). El secreto debe contener el certificado de la AC en una clave llamada cert. Este campo es opcional.

      Para obtener más información sobre cómo configurar el objeto Secret para el certificado de la AC, consulta Configurar la autoridad de certificación.

    Para obtener una explicación de los campos y una lista completa de los que puede añadir al campo spec, consulte Campos de RootSync.

    Este manifiesto crea un objeto RootSync que usa Git como fuente.

    OCI

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

    Haz los cambios siguientes:

    • ROOT_SYNC_NAME: añade el nombre de tu objeto RootSync.
    • ROOT_FORMAT: añade unstructured para usar un repositorio no estructurado o añade hierarchy para usar un repositorio jerárquico. En estos valores se distingue entre mayúsculas y minúsculas. Este campo es opcional y su valor predeterminado es hierarchy. Te recomendamos que añadas unstructured, ya que este formato te permite organizar tus configuraciones de la forma que te resulte más cómoda.
    • ROOT_IMAGE: URL de la imagen OCI que se va a usar como repositorio raíz. Por ejemplo, LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. De forma predeterminada, la imagen se extrae de la etiqueta latest, pero puedes extraer imágenes mediante TAG o DIGEST. Especifica TAG o DIGEST en PACKAGE_NAME:
      • Para tirar por TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
      • Para tirar por DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
    • ROOT_DIRECTORY: añade la ruta del repositorio al directorio raíz que contiene la configuración que quieres sincronizar. Este campo es opcional y el valor predeterminado es el directorio raíz (/) del repositorio.
    • ROOT_AUTH_TYPE: añade uno de los siguientes tipos de autenticación:

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

      Este campo es obligatorio.

    • ROOT_EMAIL: Si has añadido gcpserviceaccount como tu ROOT_AUTH_TYPE, añade la dirección de correo de tu cuenta de servicio de Google. Por ejemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

    • ROOT_CA_CERT_SECRET_NAME: añade el nombre de tu secreto. Si se define este campo, tu proveedor de OCI debe usar un certificado emitido por esta autoridad de certificación (CA). El secreto debe contener el certificado de la AC en una clave llamada cert. Este campo es opcional.

    Para obtener más información sobre cómo configurar el objeto Secret para el certificado de la AC, consulta Configurar la autoridad de certificación.

    Para obtener una explicación de los campos y una lista completa de los que puede añadir al campo spec, consulte Campos de RootSync.

    Este manifiesto crea un objeto RootSync que usa una imagen OCI como origen.

    Helm

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

    Haz los cambios siguientes:

    • ROOT_SYNC_NAME: añade el nombre de tu objeto RootSync.
    • ROOT_FORMAT: añade unstructured para usar un repositorio no estructurado o añade hierarchy para usar un repositorio jerárquico. En estos valores se distingue entre mayúsculas y minúsculas. Este campo es opcional y su valor predeterminado es hierarchy. Te recomendamos que añadas unstructured, ya que este formato te permite organizar tus configuraciones de la forma que te resulte más cómoda.
    • ROOT_HELM_REPOSITORY: la URL del repositorio de Helm que se va a usar como repositorio raíz. Puede introducir URLs con el protocolo HTTPS o SSH. Por ejemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa el protocolo HTTPS. Este campo es obligatorio.
    • HELM_CHART_NAME: añade el nombre de tu gráfico de Helm. Este campo es obligatorio.
    • HELM_CHART_VERSION: la versión del gráfico. Este campo es opcional. Si no se especifica ningún valor, se usa la versión más reciente.
    • HELM_RELEASE_NAME: el nombre de la versión de Helm. Este campo es opcional.
    • HELM_RELEASE_NAMESPACE: el espacio de nombres de destino de una versión. Solo define un espacio de nombres para los recursos que contienen namespace: {{ .Release.Namespace }} en sus plantillas. Este campo es opcional. Si no se especifica ningún valor, se usa el espacio de nombres predeterminado config-management-system.
    • HELM_INCLUDE_CRDS: se define como true si quieres que la plantilla de Helm también genere un CustomResourceDefinition. Este campo es opcional. Si no se especifica ningún valor, el valor predeterminado es false y no se generará ningún CRD.
    • VALUE: valores que se usarán en lugar de los valores predeterminados que acompañan al gráfico de Helm. Este campo debe tener el mismo formato que el archivo values.yaml del gráfico de Helm. Este campo es opcional.
    • ROOT_AUTH_TYPE: añade uno de los siguientes tipos de autenticación:

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

      Este campo es obligatorio.

    • ROOT_EMAIL: Si has añadido gcpserviceaccount como tu ROOT_AUTH_TYPE, añade la dirección de correo de tu cuenta de servicio de Google. Por ejemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

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

    • ROOT_CA_CERT_SECRET_NAME: añade el nombre de tu secreto. Si se define este campo, tu proveedor de Helm debe usar un certificado emitido por esta autoridad de certificación (CA). El secreto debe contener el certificado de la AC en una clave llamada cert. Este campo es opcional.

    Para obtener más información sobre cómo configurar el objeto Secret para el certificado de la AC, consulta Configurar la autoridad de certificación.

    Para obtener una explicación de los campos y una lista completa de los que puede añadir al campo spec, consulte Campos de RootSync.

    Este manifiesto crea un objeto RootSync que usa Helm como origen.

  3. Para crear la configuración de Config Sync, crea un objeto RootSync aplicando el manifiesto:

    kubectl apply -f root-sync.yaml
    
  4. Para verificar que los cambios se hayan aplicado, consulta el objeto RootSync:

    kubectl describe rootsync ROOT_SYNC_NAME -n config-management-system
    

Actualizar Config Controller

Como Config Controller es un servicio gestionado, Google lo actualiza automáticamente. Para obtener información sobre las nuevas funciones y las versiones de Config Sync, Policy Controller y Config Connector que usa Config Controller, consulta las notas de la versión de Config Controller.

Eliminar tu instancia de Config Controller

Si decides dejar de usar una instancia de Config Controller, limpia todos los recursos de Config Connector creados antes de eliminar el propio clúster de Config Controller.

Si eliminas tu instancia de Config Controller sin eliminar primero los recursos aprovisionados, estos quedarán en un estado abandonado. Los recursos siguen existiendo en Google Cloud (y se aplican cargos de facturación), pero no se gestionan desde la configuración declarativa.

Una vez que se hayan eliminado todos los recursos, elimina el clúster de Config Controller:

gcloud anthos config controller delete \
    --location=LOCATION CONFIG_CONTROLLER_NAME

Consideraciones sobre la producción

Antes de pasar a producción, debes consultar las consideraciones sobre la alta disponibilidad de Config Controller.

Siguientes pasos