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:
- 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.
Como
kubectl
no está instalado de forma predeterminada en la Google Cloud CLI, instálalo:gcloud components install kubectl
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.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.
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:
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 esCREATING
, significa que tu instancia de Config Controller aún se está creando y debes seguir esperando. Si ves el iconoERROR
, 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.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 :
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)"
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:
PROJECT_ID
: tu ID de proyectoROLE
: un conjunto de roles predefinidos u roles personalizados que se ajusten a tus necesidades. También puedes usarroles/owner
para entornos que no sean de producción. Para obtener más información sobre los permisos de gestión de identidades y accesos de Config Controller, consulta Permisos de gestión de identidades y accesos de Config Controller.
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:
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.
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ñadeunstructured
para usar un repositorio no estructurado o añadehierarchy
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 eshierarchy
. Te recomendamos que añadasunstructured
, 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 esHEAD
. 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 esmaster
. Te recomendamos que uses el camporevision
para especificar un nombre de rama por simplicidad. Si se especifican tanto el camporevision
como el campobranch
,revision
tiene prioridad sobrebranch
.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ónssh
: usar un par de claves SSHcookiefile
: usa uncookiefile
token
: usar un tokengcpserviceaccount
: 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ñadidogcpserviceaccount
como tuROOT_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 valortrue
a este campo. El valor predeterminado esfalse
.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 llamadacert
. 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ñadeunstructured
para usar un repositorio no estructurado o añadehierarchy
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 eshierarchy
. Te recomendamos que añadasunstructured
, 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 etiquetalatest
, pero puedes extraer imágenes medianteTAG
oDIGEST
. EspecificaTAG
oDIGEST
enPACKAGE_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
- Para tirar por
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óngcenode
: 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ñadidogcpserviceaccount
como tuROOT_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 llamadacert
. 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ñadeunstructured
para usar un repositorio no estructurado o añadehierarchy
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 eshierarchy
. Te recomendamos que añadasunstructured
, 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 contienennamespace: {{ .Release.Namespace }}
en sus plantillas. Este campo es opcional. Si no se especifica ningún valor, se usa el espacio de nombres predeterminadoconfig-management-system
.HELM_INCLUDE_CRDS
: se define comotrue
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 esfalse
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óntoken
: 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ñadidogcpserviceaccount
como tuROOT_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 sitoken
es elROOT_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 llamadacert
. 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.Para crear la configuración de Config Sync, crea un objeto RootSync aplicando el manifiesto:
kubectl apply -f root-sync.yaml
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
- Consulta las prácticas recomendadas para la escalabilidad de Config Controller.
- Desplegar cargas de trabajo personalizadas en clústeres de Config Controller
- Solucionar problemas de Config Controller.
- Obtener asistencia
- Más información sobre cómo sincronizar configuraciones y políticas con Config Sync
- Consulta más información sobre cómo aplicar políticas con Policy Controller.
- Consulta más información sobre los recursos de Config Connector.