Configura el controlador de configuración

En esta página, se muestra cómo configurar el controlador de configuración.

El controlador de configuración proporciona un plano de control administrado, basado en Kubernetes. Además, las instancias de Config Controller vienen preinstaladas con Policy Controller, Sincronizador de configuración y Config Connector. Con estos componentes, puedes usar las herramientas y los flujos de trabajo de Kubernetes para administrar recursos de Google Cloudy lograr coherencia con un flujo de trabajo de GitOps. Para obtener más información, consulta la descripción general de Config Controller.

Si creas una instancia de Config Controller por primera vez, consulta la Guía de inicio rápido: Administra recursos con Config Controller.

Limitaciones

  • Dado que las instancias de Config Controller están completamente administradas, no puedes registrarlas en una flota.

Antes de comenzar

Antes de configurar el controlador de configuración, completa los siguientes pasos:

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

    gcloud components install kubectl
    
  3. Establece el proyecto de Google Cloud en el que deseas alojar Config Controller:

    gcloud config set project PROJECT_ID
    

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

  4. Habilita las APIs que necesites:

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

Crea 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 deseas más opciones de personalización. Selecciona un clúster de Autopilot si deseas una instalación más rápida, el ajuste de escala automático horizontal y vertical de Pods, y funciones de seguridad mejoradas, como Container-Optimized OS, Nodos de GKE protegidos, Workload Identity Federation for GKE y inicio seguro.

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

Ir al Explorador de registros.

Si encuentras errores durante la creación, consulta Soluciona problemas de Config Controller para obtener orientación sobre cómo resolver problemas habituales.

Crea 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

Reemplaza lo siguiente:

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

Crea un clúster estándar

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

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

Reemplaza lo siguiente:

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

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

Confirma tu instancia de Config Controller

Para confirmar que tu instancia de Config Controller esté configurada, completa los siguientes pasos:

  1. Para verificar que se hayan creado tus instancias de Config Controller, consulta la lista de instancias de Config Controller:

    gcloud anthos config controller list --location=LOCATION
    

    Deberías ver un valor de 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 ERROR, significa que tienes un problema que no puedes resolver por tu cuenta. Comunícate con el equipo de asistencia de Google Cloudpara obtener ayuda.

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

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

Usa tu instancia de Config Controller

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

  • Usa Config Connector para crear Google Cloud recursos. Si tienes recursos Google Cloud existentes que deseas usar con el controlador de configuración, obtén más información sobre Adquiere un recurso existente.

  • Usa Policy Controller para aplicar restricciones que garanticen el cumplimiento normativo y los estándares de Kubernetes.

  • Después de configurar el Sincronizador de configuración, en la siguiente sección, sincroniza tu instancia de Policy 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.

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

Configura tu instancia de Config Controller

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

Configura Config Connector

No necesitas administrar ningún parámetro de configuración para la instalación de Config Connector. Sin embargo, debes otorgar permisos al controlador de configuración para administrar los recursos deGoogle Cloud :

  1. Configura una variable de entorno para el correo electrónico 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 la vinculación de políticas:

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

    Reemplaza lo siguiente:

    Si la operación anterior falla, verifica si los controladores están listos.

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

Después de otorgar estos permisos, puedes comenzar a crear recursos Google Cloud.

Configurar Policy Controller

Es posible que debas agregar o actualizar la política de IAM para permitir que Policy Controller envíe métricas.

Ejecuta el siguiente comando para permitir que Policy Controller envíe métricas:

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

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

Configura Sincronizador de configuración

Si deseas que tu instancia de Config Controller se sincronice desde las configuraciones almacenadas en una fuente de información, debes configurar el Sincronizador de configuración.

Si deseas usar el Sincronizador de configuración para crear recursos de Config Connector, asegúrate de también otorgarle permiso al controlador de configuración para administrar recursos.

Para configurar el Sincronizador de configuración, 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 privados no tienen acceso saliente 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 parámetros de configuración.

    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
    

    Reemplaza lo siguiente:

    • ROOT_SYNC_NAME: Agrega el nombre de tu objeto RootSync.
    • 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) o la rama desde la que se realizará la sincronización. Este campo es opcional y el valor predeterminado es HEAD. Cuando uses un hash, este debe ser completo y no una forma abreviada.
    • 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. Para simplificar el proceso, te recomendamos que uses el campo revision para especificar un nombre de rama. Si se especifican los campos revision y branch, revision tiene prioridad sobre branch.
    • 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 la Workload Identity Federation for GKE no está habilitada 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.

      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 este campo está configurado, 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.

    • ROOT_CA_CERT_SECRET_NAME: agrega el nombre del secreto. Si este campo está configurado, tu proveedor de Git debe usar un certificado emitido por esta autoridad certificadora (AC). 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 secreto para el certificado de la AC, consulta Cómo configurar la AC.

    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.

    Mediante este manifiesto, se 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
    

    Reemplaza lo siguiente:

    • ROOT_SYNC_NAME: Agrega el nombre de tu objeto RootSync.
    • 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_IMAGE: URL de la imagen de OCI que se usa 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 el PACKAGE_NAME:
      • Para extraer antes del TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
      • Para extraer antes del DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
    • ROOT_DIRECTORY: agrega la ruta de acceso en el repositorio 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
      • gcenode: Usa la cuenta de servicio predeterminada de Compute Engine para acceder a una imagen en Artifact Registry. Selecciona esta opción solo si la Workload Identity Federation for GKE no está habilitada en tu clúster.
      • gcpserviceaccount: Usa una cuenta de servicio de Google para acceder a una imagen.

      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_CA_CERT_SECRET_NAME: agrega el nombre del secreto. Si este campo está configurado, tu proveedor de OCI debe usar un certificado emitido por esta autoridad certificadora (AC). 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 secreto para el certificado de la AC, consulta Cómo configurar la AC.

    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.

    Mediante este manifiesto, se crea un objeto RootSync que usa una imagen de OCI como fuente.

    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
    

    Reemplaza lo siguiente:

    • ROOT_SYNC_NAME: Agrega el nombre de tu objeto RootSync.
    • 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_HELM_REPOSITORY: Es la URL del repositorio de Helm que se usará 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.
    • HELM_CHART_NAME: Agrega el nombre de tu diagrama de Helm. Este campo es obligatorio.
    • HELM_CHART_VERSION: Es 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: Es el nombre de la versión de Helm. Este campo es opcional.
    • HELM_RELEASE_NAMESPACE: Es el espacio de nombres de destino para una versión. Solo establece 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 establece en true si deseas que la plantilla de Helm también genere una CustomResourceDefinition. Este campo es opcional. Si no se especifica ningún valor, el valor predeterminado es false y no se generará una CRD.
    • VALUE: valores para usar en lugar de valores predeterminados que acompañan al gráfico de Helm Dale formato a este campo de la misma manera que al archivo values.yaml del gráfico de Helm. Este campo es opcional.
    • ROOT_AUTH_TYPE: Agrega uno de los siguientes tipos de autenticación:

      • none: No usa 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 en Artifact Registry. Selecciona esta opción solo si la Workload Identity Federation for GKE no está habilitada en tu clúster.
      • gcpserviceaccount: Usa una cuenta de servicio de Google para acceder a una imagen.

      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 de tu secreto si token es el ROOT_AUTH_TYPE. Este campo es opcional.

    • ROOT_CA_CERT_SECRET_NAME: agrega el nombre del secreto. Si este campo está configurado, tu proveedor de Helm debe usar un certificado emitido por esta autoridad certificadora (AC). 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 secreto para el certificado de la AC, consulta Cómo configurar la AC.

    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.

    Mediante este manifiesto, se crea un objeto RootSync que usa Helm como fuente.

  3. Para crear la configuración del Sincronizador de configuración, aplica el manifiesto y crea un objeto RootSync:

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

    kubectl describe rootsync ROOT_SYNC_NAME -n config-management-system
    

Actualiza el controlador de configuración

Dado que Config Controller es un servicio administrado, Google lo actualiza de manera automática. Para obtener detalles sobre las funciones nuevas y saber qué versiones del Sincronizador de configuración, Policy Controller y Config Connector usa el controlador de configuración, consulta las notas de la versión de Config Controller.

Borra tu instancia de Config Controller

Si decides dejar de usar una instancia de Config Controller, limpia todos los recursos de Config Connector que se crearon antes de borrar el clúster de Config Controller.

Si borras la instancia de Config Controller sin borrar primero los recursos aprovisionados, los recursos permanecen en un estado de abandono. Los recursos aún existen en Google Cloud (y generan cargos de facturación), pero no se administran desde una configuración declarativa.

Después de borrar todos tus recursos, borra el clúster de Config Controller:

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

Consideraciones de producción

Cuando se dirige a la producción, primero debes revisar las consideraciones de alta disponibilidad para el controlador de configuración.

¿Qué sigue?