Instalar el Sincronizador de configuración
Con el Sincronizador de configuración, puedes administrar recursos de Kubernetes mediante archivos, llamados archivos de configuración, que se almacenan en una fuente de confianza. El Sincronizador de configuración admite repositorios de Git, imágenes de OCI y gráficos de Helm como fuentes de información. En esta página, se muestra cómo habilitar y configurar el Sincronizador de configuración para que se sincronice desde tu repositorio raíz. El Sincronizador de configuración está disponible si usas Anthos o Google Kubernetes Engine (GKE).
Cuando instalas el Sincronizador de configuración con Google Cloud Console o Google Cloud CLI, las API de RootSync
y RepoSync
están habilitadas de forma predeterminada. Este operador te proporciona funciones adicionales, como la sincronización de varios repositorios y la sincronización de configuraciones de Kustomize y Helm.
Antes de comenzar
Antes de instalar el Sincronizador de configuración, prepara tu entorno, tus clústeres y tus roles, y habilita Anthos Config Management.
Prepara el entorno local
Completa las siguientes tareas para preparar tu entorno local:
- Crea una fuente de información o asegúrate de tener acceso a ella. Aquí es donde agregas los parámetros de configuración que se sincronizan con el Sincronizador de configuración. Para obtener más información sobre cómo establecer la configuración y la fuente de información, consulta una de las siguientes guías:
- Instala e inicializa Google Cloud CLI, que proporciona los comandos
gcloud
ynomos
. Si usas Cloud Shell, Google Cloud CLI viene preinstalada.
Requisitos del clúster
Crea un clúster que cumpla con los siguientes requisitos o asegúrate de tener acceso a él:
- Está en una plataforma y versión compatibles de Anthos o es un clúster de Google Kubernetes Engine (GKE).
Si usas clústeres de Autopilot en Anthos Config Management, Autopilot ajusta los requisitos de los recursos del contenedor para cumplir con las siguientes reglas:
- Los límites de recursos se establecen igual a las solicitudes de recursos.
- Las CPU virtuales de pod están disponibles en incrementos de 0.25 CPU virtuales (se redondean).
- El valor mínimo es 250 millicores de CPU (mCPU).
- La proporción de memoria (en GiB) con respecto a la CPU virtual debe estar dentro del rango de 1 a 6.5 CPU virtuales.
Debido a estas reglas, para los clústeres de Autopilot, el Sincronizador de configuración realiza las siguientes acciones:
- ignora las anulaciones del límite de recursos.
- solo aplica anulaciones cuando existe una o más solicitudes de recursos superiores al resultado ajustado correspondiente que se declara en la anotación, o cuando hay una o más solicitudes de recursos inferiores a la entrada correspondiente declarada en la anotación.
(Opcional) tiene Workload Identity habilitado si usas clústeres de GKE. Workload Identity es la forma recomendada de acceder a los servicios de Google Cloud desde aplicaciones que se ejecutan dentro de GKE debido a sus propiedades de seguridad y capacidad de administración mejoradas. Si habilitaste Workload Identity y deseas habilitar Cloud Monitoring para el Sincronizador de configuración, debes otorgar los permisos de escritura de métricas correctos.
Si deseas usar un clúster de GKE privado, configura Cloud NAT para permitir la salida desde nodos de GKE privados. Para obtener más detalles, consulta Ejemplo de configuración de GKE. Como alternativa, puedes habilitar el Acceso privado a Google para conectarte al conjunto de direcciones IP externas que usan los servicios y las API de Google.
Si deseas usar una cuenta de servicio de Google cuando otorgas acceso a Sincronizador de configuración a tu repositorio de Git, debes incluir el permiso de solo lectura en acceso. alcances de los nodos en el clúster para Cloud Source Repositories.
Puedes agregar el permiso de solo lectura si incluyes
cloud-source-repos-ro
en la lista--scopes
especificada en el momento de la creación del clúster o si usas el permisocloud-platform
en el momento de la creación del clúster. Por ejemplo:gcloud container clusters create CLUSTER_NAME --scopes=cloud-platform
Si tienes requisitos estrictos de firewall de VPC que bloquean el tráfico innecesario, debes crear reglas de firewall para permitir el siguiente tráfico en clústeres públicos de GKE:
TCP: Permite la entrada y salida en los puertos 53 y 443.
UDP: Permite la salida al puerto 53
Si no incluyes estas reglas, el Sincronizador de configuración no se sincroniza correctamente y
nomos status
informa el siguiente error:Error: KNV2004: unable to sync repo Error in the git-sync container
Puedes omitir estos pasos si usas un clúster de GKE privado.
Prepara tu clúster
Después de crear un clúster adecuado, completa los siguientes pasos:
Si usas Anthos Config Management por primera vez, habilita Anthos Config Management.
Otorga las funciones de IAM necesarias al usuario que registra el clúster.
Si planeas usar Google Cloud CLI para configurar el Sincronizador de configuración o usar clústeres fuera de Google Cloud, asegúrate de que tus clústeres de GKE o los clústeres fuera de Google Cloud estén registrados en una flota ahora. Si planeas usar la consola de Google Cloud, puedes registrar clústeres de GKE cuando configuras el Sincronizador de configuración.
Instalar el Sincronizador de configuración
En las siguientes secciones, le otorgas acceso al Sincronizador de configuración a una de las siguientes fuentes de información:
Después de otorgar el acceso, puedes configurar el Sincronizador de configuración.
Otorga acceso 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:
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.
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:
- Cloud Source Repositories
- Bitbucket
- GitHub: Recomendamos que crees claves de implementación por separado para proporcionar acceso de solo lectura a un único repositorio de GitHub.
- GitLab
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
).Borra la clave privada del disco local o protégela.
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 CloudPROJECT_ID
: El ID del proyecto de Google Cloud en el que se encuentra el repositorioREPO_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:
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 adecuadosHTTPS_PROXY_URL
: La URL del proxy HTTPS que usas cuando te comunicas con el repositorio de Git
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:
Crea un token mediante GitHub, GitLab, o Bitbucket.
- GitHub: Crea un PAT. Otorga el permiso
repo
al token para que pueda leer de repositorios privados. Debido a que vinculas un PAT a una cuenta de GitHub, también te recomendamos crear un usuario de máquina y vincular tu PAT a este usuario. - GitLab: Crea un PAT o un token de implementación.
- Bitbucket: Crea una contraseña de la aplicación.
- GitHub: Crea un PAT. Otorga el permiso
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 usarTOKEN
: El token que creaste en el paso anterior
Si necesitas usar un proxy HTTPS, agrégalo al Secret junto con
username
ytoken
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 usarTOKEN
: El token que creaste en el paso anteriorHTTPS_PROXY_URL
: La URL del proxy HTTPS que usas cuando te comunicas con el repositorio de Git
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:
Recupera tu URL de Cloud Source Repositories:
Enumera todos los repositorios:
gcloud source repos list
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 la consola de Google Cloud, 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.
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.
El Sincronizador de configuración usa Workload Identity de la flota de forma predeterminada si el clúster está registrado en una flota. Asegúrate de que Workload Identity esté habilitado en los clústeres registrados. Para obtener más información, consulta Registra un clúster. Si tu clúster está en un proyecto diferente del proyecto host de la flota, debes vincular la cuenta de servicio de Google con la cuenta de servicio de Kubernetes en el proyecto host de la flota.
Workload Identity no está habilitado: Solo puedes usar el método para los clústeres de GKE.
Workload Identity habilitado.
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
.Si configuras el Sincronizador de configuración con la consola de Google Cloud, 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
comosecretType
y, luego, agrega el correo electrónico de tu cuenta de servicio agcpServiceAccountEmail
.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. EnGSA_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 esroot-sync
,KSA_NAME
esroot-reconciler
. De lo contrario, esroot-reconciler-ROOT_SYNC_NAME
.Para los repositorios de espacio de nombres, si el nombre de RepoSync es
repo-sync
,KSA_NAME
esns-reconciler-NAMESPACE
. De lo contrario, esns-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ónsource.reader
.
Workload Identity no habilitado
Si configuras el Sincronizador de configuración con la consola de Google Cloud, selecciona Google Cloud Repository como el Tipo de autenticación.
Si configuras el Sincronizador de configuración con Google Cloud CLI, agrega
gcenode
comosecretType
.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 EnginePROJECT_ID-compute@developer.gserviceaccount.com
tiene accesosource.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ónPROJECT_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 incluyecloud-source-repos-ro
.
Otorga acceso de solo lectura al Sincronizador de configuración a la OCI
El Sincronizador de configuración necesita acceso de solo lectura a tu imagen de OCI almacenada en Artifact Registry para que pueda leer la configuración incluida en la imagen y aplicarla a tus clústeres.
Si la imagen 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 tu imagen es pública y cualquier persona puede acceder a ella desde Internet, no necesitas autenticarte.
Sin embargo, la mayoría de los usuarios deben crear credenciales para acceder a imágenes restringidas.
Para las imágenes con acceso de lectura restringido, puedes usar una cuenta de servicio de Google a fin de usar gcenode
o gcpserviceaccount
como el tipo de autenticación.
gcenode
Si tu clúster es de GKE y Workload Identity no está habilitado, puedes usar gcenode
como tu tipo de autenticación.
El Sincronizador de configuración usa la cuenta de servicio predeterminada de Compute Engine.
Debes otorgar a Artifact Registry acceso a tu lector de cuentas de servicio predeterminadas de Compute Engine.
Guarda el número de proyecto en una variable de entorno mediante la ejecución del siguiente comando:
export PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID \ --format=json | jq -r .projectNumber)
Reemplaza
PROJECT_ID
por el ID del proyecto.Otorga el permiso de lectura de la cuenta de servicio de Compute Engine a Artifact Registry mediante la ejecución del siguiente comando:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \ --role=roles/artifactregistry.reader
gcpserviceaccount
Si tu clúster usa Workload Identity de GKE o Workload Identity de la flota, puedes usar gcpserviceaccount
como tu tipo de autenticación.
Si aún no tienes una cuenta de servicio, crea una y otórgale la función de IAM de lector de registro de artefactos (
roles/artifactregistry.reader
).Para crear una vinculación de políticas de IAM entra la cuenta de servicio de Kubernetes y la cuenta de servicio de Google, ejecutando el siguiente comando:
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, este es el ID del proyecto de tu organización. Si usas Workload Identity de la flota, puedes usar dos ID de proyectos diferentes. ParaserviceAccount:PROJECT_ID
, agrega el ID del proyecto de la flota en el que está registrado tu clúster. ParaGSA_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
RootSync
esroot-sync
, agregaroot-reconciler
. De lo contrario, agregaroot-reconciler-ROOT_SYNC_NAME
. - Para los repositorios de espacios de nombres, si el nombre de
RepoSync
esrepo-sync
, agregans-reconciler-NAMESPACE
. De lo contrario, agregans-reconciler-NAMESPACE-REPO_SYNC_NAME
.
- Para los repositorios raíz, si el nombre
GSA_NAME
: Es la cuenta de servicio personalizada de Google que quieres usar para conectarte a Artifact Registry. La cuenta de servicio debe tener la función de IAM de lector de Artifact Registry (roles/artifactregistry.reader
).
Otorga acceso de solo lectura al Sincronizador de configuración a Helm
El Sincronizador de configuración necesita acceso de solo lectura a tu repositorio de Helm para poder leer los gráficos de Helm en tu repositorio e instalarlos en tus clústeres.
Si tu 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 tu tipo de autenticación. Por ejemplo, si tu repositorio de Helm es público y cualquier persona en Internet puede acceder a él, no necesitas autenticarte.
Sin embargo, la mayoría de los usuarios deben crear credenciales para acceder a los repositorios privados de Helm. El Sincronizador de configuración admite los siguientes mecanismos de autenticación:
token
gcenode
gcpserviceaccount
token
Cree un Secret con un nombre de usuario y una contraseña del repositorio de Helm:
kubectl create secret generic SECRET_NAME \
--namespace=config-management-system \
--from-literal=username=USERNAME \
--from-literal=password=PASSWORD
Reemplaza lo siguiente:
SECRET_NAME
: Es el nombre que deseas asignar al Secret.USERNAME
: Es el nombre de usuario del repositorio de Helm.PASSWORD
: Es la contraseña del repositorio de Helm.
Cuando configures el operador de Config Management,
usarás el nombre secreto que elegiste para spec.helm.secretRef.name
.
gcenode
Si tu clúster es de GKE y Workload Identity no está habilitado, puedes usar gcenode
como tu tipo de autenticación.
El Sincronizador de configuración usa la cuenta de servicio predeterminada de Compute Engine.
Debes otorgar a Artifact Registry acceso a tu lector de cuentas de servicio predeterminadas de Compute Engine. Es posible que debas otorgar el permiso de acceso storage-ro
para otorgar permiso de solo lectura a fin de extraer imágenes.
Guarda el número de proyecto en una variable de entorno:
export PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format='value(projectNumber)')
Reemplaza
PROJECT_ID
por el ID del proyecto.Otorga a la cuenta de servicio de Compute Engine permiso de lectura para Artifact Registry:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \ --role=roles/artifactregistry.reader
gcpserviceaccount
Si almacenas tu gráfico de Helm en Artifact Registry y tu clúster usa
GKE Workload Identity
o Fleet Workload Identity,
puedes usar gcpserviceaccount
como tu tipo de autenticación.
Si aún no tienes una cuenta de servicio, crea una y otórgale la función de IAM de lector de registro de artefactos (
roles/artifactregistry.reader
). Para obtener más información sobre las funciones y los permisos de Artifact Registry, consulta Configura funciones y permisos para Artifact Registry.Para crear una vinculación de políticas de IAM entra la cuenta de servicio de Kubernetes y la cuenta de servicio de Google, ejecutando el siguiente comando:
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, este es el ID del proyecto de tu organización. Si usas Workload Identity de la flota, puedes usar dos ID de proyectos diferentes. ParaserviceAccount:PROJECT_ID
, agrega el ID del proyecto de la flota en el que está registrado tu clúster. ParaGSA_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
RootSync
esroot-sync
, agregaroot-reconciler
. De lo contrario, agregaroot-reconciler-ROOT_SYNC_NAME
. - Para los repositorios de espacios de nombres, si el nombre de
RepoSync
esrepo-sync
, agregans-reconciler-NAMESPACE
. De lo contrario, agregans-reconciler-NAMESPACE-REPO_SYNC_NAME
.
- Para los repositorios raíz, si el nombre
GSA_NAME
: Es la cuenta de servicio personalizada de Google que quieres usar para conectarte a Artifact Registry. La cuenta de servicio debe tener la función de IAM de lector de Artifact Registry (roles/artifactregistry.reader
).
Configura Sincronizador de configuración
En esta sección, definirás la configuración de tu repositorio raíz. Si sincronizas un repositorio de Git, puedes usar la consola de Google Cloud para guiarte en el proceso de instalación y automatizar algunos pasos.
Cuando instalas el Sincronizador de configuración con Google Cloud Console o Google Cloud CLI, el Sincronizador de configuración crea automáticamente un objeto RootSync llamado root-sync
. Puedes usar comandos kubectl
para modificar root-sync
y agregar configuraciones adicionales del Sincronizador de configuración. Para obtener más información, consulta Cómo configurar el Sincronizador de configuración con comandos kubectl
.
Consola
Registra tus clústeres
Para usar Config Management, primero debes registrar tus clústeres. Cuando registras tus clústeres, estos pueden compartir un conjunto común de opciones de configuración y políticas.
Para registrar tus clústeres, completa las siguientes tareas:
-
En la consola de Google Cloud:
Si usas Google Kubernetes Engine, ve a la página Configuración de GKE, en la sección Configuración y política.
Si usas Anthos, ve a la página Configuración de Anthos en la sección Configuración y política.
- Haz clic en add Instalar el Sincronizador de configuración.
- En la página Selecciona clústeres registrados para Config Management, ubica la tabla Clústeres no registrados de este proyecto y busca el clúster que deseas registrar.
Haz clic en Registrar junto al clúster que deseas registrar.
Una vez que el clúster se registra de forma correcta, aparece en la tabla Selecciona clústeres registrados para Config Management.
Instala Sincronizador de configuración
Una vez que hayas registrado tus clústeres, puedes continuar con la instalación y configuración de Config Sync.
Para configurar el Sincronizador de configuración, completa los siguientes pasos.
En la página Selecciona clústeres registrados para la administración de configuración, selecciona los clústeres que deseas configurar y haz clic en Next.
Si deseas instalar el controlador de políticas, deja seleccionada la casilla de verificación Habilitar controlador de políticas y haz clic en Siguiente.
En la lista desplegable Repositorio, selecciona Usar la muestra de Google o Personalizado.
Muestra de Google
Selecciona Usar la muestra de Google para usar el repositorio de muestra de Google. Este repositorio incluye paquetes del controlador de políticas.
Para seleccionar esta opción, debes instalar el controlador de políticas, instalar la biblioteca de plantillas de restricciones del controlador de políticas y habilitar las restricciones referenciales. Estas opciones del controlador de políticas están habilitadas de forma predeterminada.
Personalizado
Selecciona Personalizado para usar tu propio repositorio de Git y, luego, configura los siguientes campos:
En el campo URL, agrega la URL del repositorio de Git para usarla como fuente de verdad. Ingresa las URL con el protocolo HTTPS o SSH. Por ejemplo,
https://github.com/GoogleCloudPlatform/anthos-config-management-samples
Si planeas usar SSH como tu Tipo de autenticación, ingresa la URL con el protocolo SSH.Haz clic en Show advanced options.
En la lista desplegable Tipo de autenticación, selecciona una de las siguientes opciones:
- Ninguna: No usa autenticación.
- SSH: Usa un par de claves SSH.
- Cookiefile: Usa un
cookiefile
. - Token: Usa un token.
- Google Cloud Repository: Usa una cuenta de servicio de Google para acceder a un Cloud Source Repositories. Selecciona esta opción solo si Workload Identity no está habilitado en tu clúster.
- Workload Identity: Usa una cuenta de servicio de Google para acceder a un repositorio de Cloud Source Repositories. Solo puedes seleccionar Workload Identity cuando usas clústeres de GKE con Workload Identity habilitado. No se admite la integración con Fleet Workload Identity para otros clústeres de Anthos.
Cuando seleccionas Workload Identity, debes agregar la dirección de correo electrónico de la cuenta de servicio de Google. Por ejemplo:
acm@PROJECT_ID.iam.gserviceaccount.com
. Si seleccionas este tipo de autenticación, también debes crear una vinculación de política de IAM después de que termines de configurar el Sincronizador de configuración. Para obtener más información, consulta la pestaña Cuenta de servicio de Google de laOtorga acceso de solo lectura al Sincronizador de configuración a Git.
Sigue las instrucciones de la consola de Google Cloud para otorgar acceso de solo lectura al Sincronizador de configuración a Git y haz clic en Continuar.
En el campo Rama, agrega la rama del repositorio desde la que deseas realizar la sincronización. El valor predeterminado es la rama principal.
Opcional: En el campo Etiqueta/Confirmación, agrega la revisión de Git (etiqueta o hash) que se debe pagar. El predeterminado es
HEAD
.Opcional: En el campo Configuration directory, agrega la ruta del directorio desde el que deseas sincronizar en relación con la raíz del repositorio de Git. Se incluyen todos los subdirectorios del directorio que especificas y se sincronizan con el clúster. El valor predeterminado es el directorio raíz del repositorio.
Opcional: En el campo Tiempo de espera de la sincronización, agrega el período en segundos entre las sincronizaciones consecutivas. El tiempo predeterminado es 15 segundos.
Opcional: En el campo Proxy de Git, ingresa la URL para el proxy HTTPS que se usará durante la comunicación con el repositorio de Git. Este es un campo opcional y, si se deja en blanco, no se usa ningún proxy. El proxy solo se admite cuando se usa un tipo de autorización de
cookiefile
,none
otoken
.La URL del proxy HTTPS se muestra como texto sin formato en el recurso RootSync que crea el Sincronizador de configuración. Si la URL contiene información sensible, como un nombre de usuario o contraseña, y necesitas ocultarla, puedes dejar el proxy de Git vacío y agregar la URL para HTTPS. proxy en el mismo secreto que se usa para la credencial de Git. El almacenamiento en el secreto en el secreto es compatible cuando el tipo de autorización es
cookiefile
otoken
.Opcional: DesdeFormato de origen Elige una de las siguientes listas desplegables:no estructurado ojerarquía. El valor predeterminado es no estructurado, y te recomendamos que selecciones no estructurado, ya que este formato te permite organizar las configuraciones de la manera más conveniente.
Opcional: En la lista desplegable Versión de Config Management, selecciona la versión de Anthos Config Management que deseas usar. El valor predeterminado es la versión actual.
Para finalizar la instalación, haz clic en Complete. Volverás a la página Anthos Config Management.
gcloud
Antes de continuar, asegúrate de registrar tus clústeres en una flota.
- Para preparar la configuración, crea un nuevo manifiesto
apply-spec.yaml
o usa un manifiesto existente. El uso de un manifiesto existente te permite configurar tu clúster con la misma configuración que usa otro clúster.
Crear manifiesto nuevo
Para configurar el Sincronizador de configuración con la configuración nueva del clúster, crea un archivo llamado apply-spec.yaml
y copia el siguiente archivo YAML en él.
Puedes configurar todos los campos spec.configSync
opcionales que necesitas cuando creas tu manifiesto y, luego, usar comandos de kubectl
para la configuración.
También puedes configurar el campo spec.configSync.enabled
como true
y omitir los campos opcionales. Luego, puedes usar comandos kubectl
para crear objetos RootSync adicionales o RepoSyncs que puedes administrar completamente con comandos kubectl
más adelante.
# apply-spec.yaml
applySpecVersion: 1
spec:
configSync:
# Set to true to install and enable Config Sync
enabled: true
# If you don't have a source of truth yet, omit the
# following fields. You can configure them later.
sourceType: SOURCE_TYPE
sourceFormat: FORMAT
syncRepo: REPO
syncBranch: BRANCH
secretType: SECRET_TYPE
gcpServiceAccountEmail: EMAIL
policyDir: DIRECTORY
preventDrift: PREVENT_DRIFT
Reemplaza lo siguiente:
SOURCE_TYPE
: Agregagit
para sincronizar desde un repositorio de Git,oci
para sincronizar desde una imagen OCI ohelm
para sincronizar desde un gráfico de Helm. Si no se especifica un valor, el valor predeterminado esgit
.FORMAT
: agregaunstructured
para usar un repositorio no estructurado o agregahierarchy
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 eshierarchy
. Te recomendamos que agreguesunstructured
, ya que este formato te permite organizar la configuración de la manera que te resulte más conveniente.REPO
: Agrega la URL de la fuente de confianza. Las URLs de repositorio de Git y Helm usan el protocolo HTTPS o SSH. Por ejemplo,https://github.com/GoogleCloudPlatform/anthos-config-management-samples
. Si planeas usar SSH como tusecretType
, ingresa tu URL con el protocolo SSH. Este campo es obligatorio y, si no ingresas un protocolo, la URL se trata como una URL HTTPS.Las URLs de OCI usan el siguiente formato:
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 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
- Para extraer antes del
BRANCH
: La rama del repositorio desde la que se realiza la sincronización. Este campo es opcional y el valor predeterminado esmaster
.SECRET_TYPE
: Uno de los siguientessecretTypes
:git
none
: No usa autenticaciónssh
: Usa un par de claves SSHcookiefile
: Usa un objetocookiefile
token
: Usa un tokengcpserviceaccount
: Usa una cuenta de servicio de Google para acceder a Cloud Source Repositories. Si seleccionas este tipo de autenticación, debes crear una vinculación de política de IAM después de que termines de configurar el Sincronizador de configuración. Para obtener más detalles, consulta la pestaña Cuenta de servicio de Google de la sección Otorga acceso de solo lectura al Sincronizador de configuración a Git.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.
OCI
none
: No usa autenticacióngcenode
: Usa la cuenta de servicio predeterminada de Compute Engine para acceder a una imagen en Artifact Registry. Selecciona esta opción solo si Workload Identity no está habilitada en el clúster.gcpserviceaccount
: Usa una cuenta de servicio de Google para acceder a una imagen.
helm
token
: Usa un tokengcenode
: Usa la cuenta de servicio predeterminada de Compute Engine para acceder a una imagen en Artifact Registry. Selecciona esta opción solo si Workload Identity no está habilitada en el clúster.gcpserviceaccount
: Usa una cuenta de servicio de Google para acceder a una imagen.
EMAIL
: Si agregastegcpserviceaccount
comosecretType
, agrega la dirección de correo electrónico de la cuenta de servicio de Google. Por ejemplo,acm@PROJECT_ID.iam.gserviceaccount.com
DIRECTORY
: ruta del directorio desde el que se realiza la sincronización en relación con la raíz del repositorio de Git. Se incluyen todos los subdirectorios del directorio que especificas y se sincronizan con el clúster. El valor predeterminado es el directorio raíz del repositorio.PREVENT_DRIFT
: Si se configura comotrue
, 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 esfalse
. El Sincronizador de configuración siempre soluciona los desvíos, sin importar el valor de este campo.
Para obtener una lista completa de los campos que puedes agregar al campo spec
, consulta Campos de gcloud.
Usar el manifiesto existente
Para configurar tu clúster con la misma configuración que usa otro clúster, recupera la configuración de un clúster registrado:
gcloud alpha container fleet config-management fetch-for-apply \
--membership=MEMBERSHIP_NAME \
--project=PROJECT_ID \
> CONFIG_YAML_PATH
Reemplaza lo siguiente:
MEMBERSHIP_NAME
: El nombre de la membresía del clúster registrado que tiene la configuración del Sincronizador de configuración que deseas usarPROJECT_ID
: El ID de tu proyectoCONFIG_YAML_PATH
: Es la ruta de acceso al archivoapply-spec.yaml
que contiene la configuración recuperada del clúster.
2. Aplica el archivo apply-spec.yaml
. Si usas un manifiesto existente, debes aplicar el archivo al clúster que deseas establecer con la configuración que recuperaste en el comando anterior:
gcloud beta container fleet config-management apply \
--membership=MEMBERSHIP_NAME \
--config=CONFIG_YAML_PATH \
--project=PROJECT_ID
Reemplaza lo siguiente:
MEMBERSHIP_NAME
: Es el nombre de la membresía que elegiste cuando registraste el clúster. Puedes encontrar el nombre congcloud container fleet memberships list
.CONFIG_YAML_PATH
: La ruta de acceso a tu archivoapply-spec.yaml
.PROJECT_ID
: el ID de tu proyecto
Una vez que hayas terminado de configurar tu repositorio raíz, puedes optar por configurar la sincronización de varios repositorios, incluidos otros repositorios raíz y repositorios de espacios de nombres. Los repositorios de espacio de nombres 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 entre clústeres.
Verifique la instalación
Después de instalar y configurar el Sincronizador de configuración, puedes verificar que la instalación se haya completado correctamente.
Consola
Completa los siguientes pasos:
-
En la consola de Google Cloud:
Si usas Google Kubernetes Engine, ve a la página Configuración de GKE, en la sección Configuración y política.
Si usas Anthos, ve a la página Configuración de Anthos en la sección Configuración y política.
- En la tabla del clúster, consulta la columna Estado de sincronización de la configuración. Si la instalación se realiza correctamente, tendrá el estado Sincronizada.
gcloud
Ejecuta el siguiente comando:
gcloud beta container fleet config-management status \
--project=PROJECT_ID
Reemplaza PROJECT_ID
por el ID del proyecto.
Si la instalación se realiza correctamente, tendrá el estado SYNCED
. Si ves un error después de ejecutar el comando anterior, asegúrate de haber creado el Secret git-creds
. Si creaste el Secret, vuelve a ejecutar el siguiente comando:
gcloud beta container fleet config-management apply
También puedes usar el comando nomos status
para verificar si el Sincronizador de configuración se instaló correctamente. 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.
Actualiza el Sincronizador de configuración
El Sincronizador de configuración se actualiza cada vez que actualizas Anthos Config Management. Para obtener más información, consulta Actualiza Anthos Config Management.
Solicitudes de recursos
Resumen del total de solicitudes de recursos
En las siguientes tablas, se enumera la cantidad combinada de solicitudes de recursos para cada versión compatible del Sincronizador de configuración, según las funciones que uses.
1.15
Atributo | CPU (m) | Memoria (Mi) |
---|---|---|
Sincronizador de configuración | 330 m + 80 m * (cantidad de objetos RootSync y RepoSync)1 | 850 Mi + 600 Mi * (cantidad de objetos RootSync y RepoSync) |
Sincronizador de configuración con el webhook de admisión habilitado | 350 m + 80 m * (cantidad de objetos RootSync y RepoSync)1 | 1,050 Mi + 600 Mi * (cantidad de objetos RootSync y RepoSync) |
Controlador de jerarquía | 200 m | 322 km |
1 Si los tipos de origen RootSync y RepoSync se configuran como helm
, la solicitud de CPU es de 120 m * (cantidad de objetos RootSync y RepoSync).
1.14
Atributo | CPU (m) | Memoria (Mi) |
---|---|---|
Sincronizador de configuración | 330 m + 80 m * (cantidad de objetos RootSync y RepoSync)1 | 850 Mi + 600 Mi * (cantidad de objetos RootSync y RepoSync) |
Sincronizador de configuración con el webhook de admisión habilitado | 350 m + 80 m * (cantidad de objetos RootSync y RepoSync)1 | 1,050 Mi + 600 Mi * (cantidad de objetos RootSync y RepoSync) |
Controlador de jerarquía | 200 m | 322 km |
1 Si los tipos de origen RootSync y RepoSync se configuran como helm
, la solicitud de CPU es de 120 m * (cantidad de objetos RootSync y RepoSync).
1.13
Atributo | CPU (m) | Memoria (Mi) |
---|---|---|
Sincronizador de configuración | 330 m + 80 m * (cantidad de objetos RootSync y RepoSync) | 850 Mi + 600 Mi * (cantidad de objetos RootSync y RepoSync) |
Sincronizador de configuración con el webhook de admisión habilitado | 350 m + 80 m * (cantidad de objetos RootSync y RepoSync) | 1,050 Mi + 600 Mi * (cantidad de objetos RootSync y RepoSync) |
Controlador de jerarquía | 200 m | 322 km |
Solicitudes detalladas de recursos
En la siguiente tabla, se enumeran los requisitos de los recursos de Kubernetes para los componentes del Sincronizador de configuración. Si deseas obtener más información, consulta Administra los recursos para contenedores en la documentación de Kubernetes.
1.15
Nombre de la implementación | Solicitud de CPU (m) por réplica | Solicitud de memoria (Mi) por réplica | Repositorios únicos o múltiples |
---|---|---|---|
git-importer |
450 | 400 | Single |
monitor |
Predeterminada1 | Predeterminado | Single |
resource-group-controller-manager |
110 | 300 | Varios |
admission-webhook2 |
10 | 100 | Varios |
otel-collector |
200 | 400 | Varios |
reconciler-manager |
20 | 150 | Varios |
reconciler (uno por RootSync y RepoSync) |
80 o el valor predeterminado3 | 600 o más | Varios |
hnc-controller-manager |
100 | 150 | Controlador de jerarquía |
gke-hc-controller-manager |
100 | 50 | Controlador de jerarquía |
1 La solicitud de recurso predeterminada usa una solicitud de CPU de 10 millicores de CPU (mCPU) y una solicitud de memoria de 10 mi.
2 El webhook de admisión tiene dos réplicas, por lo que, cuando calculas el total de solicitudes de recursos, debes duplicar el valor si usas el webhook de admisión. El webhook de admisión está inhabilitado de forma predeterminada.
3 Si el tipo de fuente RootSync y RepoSync se establece en helm
, la solicitud de CPU es de 120 m * (cantidad de objetos RootSync y RepoSync).
1.14
Nombre de la implementación | Solicitud de CPU (m) por réplica | Solicitud de memoria (Mi) por réplica | Repositorios únicos o múltiples |
---|---|---|---|
git-importer |
450 | 400 | Single |
monitor |
Predeterminada1 | Predeterminado | Single |
resource-group-controller-manager |
110 | 300 | Varios |
admission-webhook2 |
10 | 100 | Varios |
otel-collector |
200 | 400 | Varios |
reconciler-manager |
20 | 150 | Varios |
reconciler (uno por RootSync y RepoSync) |
80 o el valor predeterminado3 | 600 o más | Varios |
hnc-controller-manager |
100 | 150 | Controlador de jerarquía |
gke-hc-controller-manager |
100 | 50 | Controlador de jerarquía |
1 La solicitud de recurso predeterminada usa una solicitud de CPU de 10 millicores de CPU (mCPU) y una solicitud de memoria de 10 mi.
2 El webhook de admisión tiene dos réplicas, por lo que, cuando calculas el total de solicitudes de recursos, debes duplicar el valor si usas el webhook de admisión. El webhook de admisión está inhabilitado de forma predeterminada.
3 Si el tipo de fuente RootSync y RepoSync se establece en helm
, la solicitud de CPU es de 120 m * (cantidad de objetos RootSync y RepoSync).
1.13
Nombre de la implementación | Solicitud de CPU (m) por réplica | Solicitud de memoria (Mi) por réplica | Repositorios únicos o múltiples |
---|---|---|---|
git-importer |
450 | 400 | Single |
monitor |
Predeterminada1 | Predeterminado | Single |
resource-group-controller-manager |
110 | 300 | Varios |
admission-webhook2 |
10 | 100 | Varios |
otel-collector |
200 | 400 | Varios |
reconciler-manager |
20 | 150 | Varios |
reconciler (uno por RootSync y RepoSync) |
80 y el valor predeterminado | 600 o más | Varios |
hnc-controller-manager |
100 | 150 | Controlador de jerarquía |
gke-hc-controller-manager |
100 | 50 | Controlador de jerarquía |
1 La solicitud de recurso predeterminada usa una solicitud de CPU de 10 millicores de CPU (mCPU) y una solicitud de memoria de 10 mi.
2 El webhook de admisión tiene dos réplicas, por lo que, cuando calculas el total de solicitudes de recursos, debes duplicar el valor si usas el webhook de admisión. El webhook de admisión está inhabilitado de forma predeterminada.
¿Qué sigue?
- Obtén más información sobre los comandos de
gcloud
para configurar el del Sincronizador de configuración con Anthos Config Management. - Descubre cómo configurar la sincronización desde varios repositorios.
- Usa el comando
nomos
. - Obtén más información para solucionar problemas del Sincronizador de configuración.
- Obtén más información para desinstalar el Sincronizador de configuración.
- Revisa los permisos predeterminados del Sincronizador de configuración.