Usar la cadena de herramientas de GKE Enterprise con Active Assist

---

Este documento forma parte de una serie en la que se analizan los patrones de arquitectura que las empresas pueden usar para optimizar su huella en la nube a gran escala con Active Assist. En el instructivo, se muestra cómo compilar una canalización de automatización para recomendaciones de Active Assist que funcionan con la cadena de herramientas de GKE Enterprise. Está dirigido a personas que usan el Sincronizador de configuración para administrar sus entornos de GKE Enterprise y Config Connector para administrar los recursos de Google Cloud. Las otras partes de la serie son las siguientes:

• Patrones para usar Active Assist a gran escala
• Usa canalizaciones sin servidores con Active Assist
• Usa la cadena de herramientas de GKE Enterprise con Active Assist (este documento)

La canalización de automatización que compilarás en este instructivo puede ayudarte a lograr lo siguiente:

• Escalar el uso de la cartera de Active Assist en tu organización
• Hacer que Active Assist sea parte de la canalización de integración continua y entrega continua (canalización de CI/CD).
• Controlar la revisión y la activación de las recomendaciones de Active Assist mediante construcciones como los problemas de GitHub y las solicitudes de extracción

En este instructivo, también se usa kpt, un kit de herramientas de código abierto que desarrolló Google para ayudarte a administrar, manipular, personalizar y aplicar archivos de datos de configuración de recursos de Kubernetes.

Arquitectura

En el siguiente diagrama de arquitectura, se muestran los componentes que usas en este instructivo.

Los componentes se usan de las siguientes maneras:

• Un repositorio de GitHub no te repitas (DRY), que se usa para las plantillas de Config Connector que implementas en los proyectos de la organización de Google Cloud.
• Uno o más repositorios de GitHub específicos para un proyecto o entorno y conservar archivos de configuración hidratados. Estos repositorios hidratados son para los entornos que administra el Sincronizador de configuración. Usa Config Connector para activar y administrar los recursos de Google Cloud en la organización de Google Cloud.
• Un clúster de GKE que usa el Sincronizador de configuración para el control de versiones y la detección de desvío. Este clúster también tiene instalado Config Connector. Config Connector permite que el clúster administre recursos de Google Cloud en toda la organización de Google Cloud.
• Un activador de Cloud Build que activa una compilación cuando se envía una plantilla al repositorio de DRY de GitHub
• Un activador de Cloud Build programado que activa una compilación de forma periódica. El trabajo de compilación usa una función kpt. La función invoca las API del recomendador de Active Assist para recuperar recomendaciones activas. Revisa y analiza las recomendaciones para determinar si se deben cambiar el tamaño o la optimización de los recursos de Google Cloud que administra Config Connector. La función kpt crea un problema de GitHub en el repositorio de DRY con los detalles del cambio recomendado si los recursos de Google Cloud administrados por Config Connector se deben optimizar o cambiar de tamaño.

El flujo de trabajo de esta arquitectura es el siguiente:

1. Los equipos autorizados con acceso al repositorio de DRY crean y administran las plantillas de Config Connector en el repositorio.
2. Un trabajo de Cloud Build se activa cuando se crea o modifica una plantilla y se verifica en la rama main.
3. El trabajo de Cloud Build hidrata las plantillas mediante la invocación de métodos kpt. El trabajo envía los archivos de configuración hidratados al repositorio de GitHub hidratado. Secret Manager se usa a fin de almacenar claves de implementación de GitHub para el repositorio privado.
4. El Sincronizador de configuración supervisa los cambios en el repositorio híbrido y aplica las actualizaciones del repositorio al clúster administrado.
5. Config Connector supervisa los cambios y activa los recursos de Google Cloud si es necesario crear o actualizar recursos como resultado de los cambios del modelo de recursos de Kubernetes (KRM) que aplica el Sincronizador de configuración.
6. Un activador de Cloud Build programado se ejecuta de forma periódica con el fin de invocar la API de recomendador a fin de recuperar recomendaciones activas para los proyectos que administra Config Connector.
7. El trabajo programado de Cloud Build ejecuta una función kpt personalizada para invocar la API de recomendador y recuperar y analizar recomendaciones activas.
8. La función kpt crea un problema de GitHub que muestra una comparación de la configuración de recursos actual y la configuración recomendada para el recurso. Con este enfoque, los problemas de GitHub se crean en el repositorio DRY, lo que facilita el seguimiento de los cambios del repositorio.

Objetivos

• Crea los siguientes repositorios de muestra de GitHub:
  • Un repositorio de DRY para KRM de Config Connector.
  • Un repositorio para contener archivos de configuración hidratados generados con métodos kpt.
• Crear un clúster de GKE con Sincronizador de configuración y Config Connector.
• Crea una función kpt de muestra a fin de recuperar las recomendaciones de Active Assist para los proyectos administrados por Config Connector.
• Crea un activador de Cloud Build que se active cuando se envíe una plantilla a la rama main del repositorio de DRY.
• Crea un trabajo programado de Cloud Build que se ejecute periódicamente a fin de recuperar recomendaciones de Active Assist disponibles para los recursos que administra Config Connector.
• Prueba la canalización de extremo a extremo con las recomendaciones de stub que se proporcionan en el repositorio de GitHub para este instructivo.

Costos

En este documento, usarás los siguientes componentes facturables de Google Cloud:

• Cloud Build
• Cloud Run
• Firestore
• Pub/Sub
• Container Registry
• Cloud Scheduler
• Google Kubernetes Engine (GKE) Enterprise Edition

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios. Es posible que los usuarios nuevos de Google Cloud califiquen para obtener una prueba gratuita.

Cuando finalices las tareas que se describen en este documento, puedes borrar los recursos que creaste para evitar que continúe la facturación. Para obtener más información, consulta Cómo realizar una limpieza.

Antes de comenzar

1. En la consola de Google Cloud, ve a la página del selector de proyectos.

   Ir al selector de proyectos

2. Selecciona o crea un proyecto de Google Cloud.

   Nota: Si no planeas conservar los recursos que creaste durante este procedimiento, crea un proyecto en lugar de seleccionar uno existente. Cuando termines, puedes borrar el proyecto y quitar todos los recursos asociados con él.
3. Anota el ID del proyecto de Google Cloud. Usarás este ID en la siguiente sección cuando configures tu entorno. En este instructivo, se denomina al proyecto build.

4. Habilita las API de Cloud Build, Firestore, App Engine, Pub/Sub, Cloud Run, Cloud Scheduler y Cloud Source Repositories.

   Habilita las API

   Usarás las credenciales de la aplicación predeterminada para este instructivo. Si se te solicita que crees credenciales en la página Agregar credenciales a tu proyecto, haz clic en Cancelar.

5. Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.

Configura tu entorno

En este instructivo, ejecutas todos los comandos en Cloud Shell.

1. En la consola de Google Cloud, activa Cloud Shell.

   Activar Cloud Shell

2. Configura las variables para el ID del proyecto y el número del proyecto build de Google Cloud actual:

   export RECO_MGR_PROJECT=PROJECT_ID
   gcloud config set project $RECO_MGR_PROJECT
   export RECO_MGR_PROJECT_NUMBER=$(gcloud projects describe $RECO_MGR_PROJECT --format='value(projectNumber)')
   

   Reemplaza PROJECT_ID por el ID del proyecto que anotaste en la sección anterior.

3. Establece las variables para la región de implementación:

   export REGION=us-central1
   export ZONE=us-central1-a
   

4. Clona el repositorio que contiene el código de la app de ejemplo que se usa en este instructivo:

   git clone https://github.com/GoogleCloudPlatform/activeassist-anthos-toolchain.git
   

5. Ve al directorio del proyecto:

   cd activeassist-anthos-toolchain
   

Compila la canalización

En esta sección, crearás los componentes para compilar la canalización. Las recomendaciones de Active Assist se generan en función de los patrones de uso y las métricas del sistema. Cada categoría de recomendación puede usar un período predeterminado diferente para analizar los datos de uso y las métricas según las recomendaciones que se generen. Para probar la canalización de extremo a extremo, el repositorio que clonaste en un paso anterior proporciona recomendaciones de muestra (stubs) que usas para ejecutar la canalización de extremo a extremo.

Como alternativa, si ejecutas la canalización en un proyecto de muestra que tiene recursos y recomendaciones existentes, puedes realizar los cambios adecuados en el código de muestra y, luego, ejecutar la canalización.

Configura repositorios de GitHub privados de muestra

En las siguientes secciones, configurarás los repositorios de GitHub de muestra para este instructivo.

Configura un repositorio privado de GitHub para DRY

1. Crea un repositorio privado de GitHub para el repositorio de DRY. Toma nota del nombre que le asignas al repositorio.

2. En Cloud Shell, crea una variable de entorno para tu nombre de usuario de GitHub y el nombre del repositorio de DRY:

   export REPO_OWNER=YOUR_GITHUB_USERNAME
   export DRY_REPO_NAME=YOUR_PRIVATE_DRY_REPO
   

   Reemplaza lo siguiente:

   • YOUR_GITHUB_USERNAME: es tu nombre de usuario de GitHub
   • YOUR_PRIVATE_DRY_REPO es el nombre de tu repositorio de DRY.

3. Crea un token de acceso personal (PAT) para crear problemas en este repositorio. La canalización crea problemas de GitHub si hay recomendaciones de Active Assist que se deben revisar. Si deseas obtener más información para crear PAT en GitHub, consulta la documentación de GitHub.

   Cuando configures un alcance para este token, selecciona Control total de los repositorios privados.

4. En Cloud Shell, crea una variable de entorno para el PAT que generaste:

   export GITHUB_TOKEN=YOUR_PERSONAL_ACCESS_TOKEN
   

   Reemplaza YOUR_PERSONAL_ACCESS_TOKEN por tu propio token.

Configura un repositorio hidratado y privado de GitHub

1. Crea un repositorio privado de GitHub para el repositorio hidratado. Toma nota del nombre que le asignas al repositorio.

2. En Cloud Shell, configura una variable de entorno para el repositorio hidratado:

   export HYDRATED_REPO_NAME=YOUR_PRIVATE_HYDRATED_REPO
   export HYDRATED_REPO='[e-mail]:$REPO_OWNER/$HYDRATED_REPO_NAME.git'
   

   Reemplaza YOUR_PRIVATE_HYDRATED_REPO por el nombre de tu repositorio hidratado.

3. Crea un par de claves de implementación:

   ssh-keygen -t rsa -b 4096 \
   -C 'active-assist-robot' \
   -N '' \
   -f $(pwd)/active-assist-robot
   

   Una clave de implementación te permite implementar en tu repositorio privado de GitHub cuando ejecutas un trabajo de Cloud Build para hidratar los archivos de configuración.

4. Imprime la clave generada:

   cat $(pwd)/active-assist-robot.pub
   

5. Agrega la clave de implementación al repositorio privado de GitHub. Asegúrate de seleccionar Permitir acceso de escritura cuando agregues la clave de implementación. Si deseas obtener información para agregar claves de implementación a los repositorios de GitHub, consulta la documentación de GitHub a fin de administrar claves de implementación.

Sube claves de GitHub a Secret Manager

1. En Cloud Shell, crea un secreto para almacenar la clave privada del par de claves de implementación:

   gcloud secrets create github-ssh-key \
     --data-file=$(pwd)/active-assist-robot
   

2. Crea un secreto para almacenar el PAT:

   echo $GITHUB_TOKEN | gcloud secrets create github-pat --data-file=-
   

Crea un clúster de GKE

En esta sección, crearás un clúster de GKE con el complemento de Config Connector, crearás una identidad y configurarás Config Connector. También debes configurar el Sincronizador de configuración. Puedes usar el Sincronizador de configuración para crear una configuración común en toda tu infraestructura, incluidas las políticas personalizadas, y aplicarla en entornos locales y en la nube. El Sincronizador de configuración evalúa los cambios y los implementa en todos los clústeres de Kubernetes para que el estado deseado siempre se refleje en tus clústeres.

1. En Cloud Shell, crea un clúster de GKE nuevo con el complemento de Config Connector habilitado:

   gcloud container clusters create sample-ops \
     --machine-type n1-standard-4 \
     --zone $ZONE \
     --release-channel regular \
     --addons ConfigConnector \
     --workload-pool=$RECO_MGR_PROJECT.svc.id.goog \
     --enable-stackdriver-kubernetes \
     --enable-ip-alias
   

2. Completa las siguientes secciones en la guía Instala con el complemento de GKE para crear una identidad y configurar Config Connector.

   1. Crea una identidad
   2. Configuración de Config Connector

3. Instala el Sincronizador de configuración en el clúster de GKE que creaste. Cuando configuras el Sincronizador de configuración, debes hacer lo siguiente:

   1. Usa un token para otorgar acceso de solo lectura al Sincronizador de configuración a Git. Usa el token de GitHub que creaste cuando configuraste un repositorio privado de GitHub DRY. El token está disponible a través de la variable de entorno $GITHUB_TOKEN.
   2. Configura el Sincronizador de configuración mediante gcloud. Establece la siguiente configuración:
      1. sourceFormat: hierarchy
      2. syncRepo: https://github.com/YOUR_GITHUB_USERNAME/YOUR_PRIVATE_HYDRATED_REPO
      3. syncBranch: main
      4. secretType: token
      5. policyDir: No completes esta opción.

Crea un activador de Cloud Build para enviar al repositorio hidratado

En las siguientes secciones, crearás un activador de Cloud Build que se activa cuando las plantillas se envían a la rama principal del repositorio YOUR_PRIVATE_DRY_REPO. Este activador ejecuta los pasos que hidratan las plantillas de configuración de KRM en el repositorio YOUR_PRIVATE_DRY_REPO y envían los archivos de configuración hidratados a tu repositorio YOUR_PRIVATE_HYDRATED_REPO.

Conecta Cloud Build a tu repositorio de GitHub.

En esta sección, conectarás los repositorios de GitHub YOUR_PRIVATE_DRY_REPO y YOUR_PRIVATE_HYDRATED_REPO a Cloud Build.

1. Ve a la página GitHub Marketplace de la app de Cloud Build.

   Ir a la página de la app de Cloud Build

2. Haz clic en Configurar con Google Cloud Build (Setup with Google Cloud Build).

3. Si se te solicita, accede a GitHub.

4. Selecciona Only select repositories.

   Usa el menú desplegable Seleccionar repositorios para habilitar el acceso a tus repositorios YOUR_PRIVATE_DRY_REPO y YOUR_PRIVATE_HYDRATED_REPO a través de la app de Cloud Build.

5. Haga clic en Install.

6. Accede a Google Cloud. Se mostrará la página de autorización, en la que se te pide que autorices a la app de Google Cloud Build para que se conecte a Google Cloud.

7. Haz clic en Autorizar Google Cloud Build a través de GoogleCloudBuild. Se te redireccionará a la consola de Google Cloud.

8. Selecciona tu proyecto de Google Cloud.

9. Marca la casilla de verificación de consentimiento y haz clic en Siguiente.

10. Haga clic en Install.

11. Accede a Google Cloud. Se mostrará la página de autorización, en la que se te pide que autorices a la app de Google Cloud Build para que se conecte a Google Cloud.

12. Haz clic en Autorizar Google Cloud Build a través de GoogleCloudBuild. Se te redireccionará a la consola de Google Cloud.

13. Selecciona tu proyecto de Google Cloud.

14. Marca la casilla de verificación de consentimiento y haz clic en Siguiente.

15. En la página Seleccionar repositorio que aparece, selecciona los siguientes repositorios de GitHub:

    • YOUR_PRIVATE_DRY_REPO
    • YOUR_PRIVATE_HYDRATED_REPO

16. Haz clic en Conectar y, luego, en Listo.

Crea un activador de Cloud Build para el repositorio de DRY

1. En Cloud Shell, ejecute el siguiente comando:

   envsubst < cloudbuild.template.yaml > cloudbuild.yaml
   

   El comando genera un archivo cloudbuild.yaml.

2. Crea el activador:

   gcloud beta builds triggers create github \
     --name ActiveAssistDemo \
     --repo-name=$DRY_REPO_NAME \
     --repo-owner=$REPO_OWNER \
     --branch-pattern="main" \
     --build-config=cloudbuild.yaml
   

3. Otorga permiso a la cuenta de servicio de Cloud Build para acceder a Secret Manager:

   gcloud secrets add-iam-policy-binding github-ssh-key  \
     --member="serviceAccount:${RECO_MGR_PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
     --role="roles/secretmanager.secretAccessor"
   
   gcloud secrets add-iam-policy-binding github-pat  \
     --member="serviceAccount:${RECO_MGR_PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
     --role="roles/secretmanager.secretAccessor"
   

Crea un activador de Cloud Build programado para recomendaciones de Active Assist

Nota: Usa stubs para probar la canalización en este instructivo. Cuando uses la canalización para tus proyectos de Google Cloud, asegúrate de otorgar a la cuenta de servicio de Cloud Build los permisos que necesita para recuperar recomendaciones de Active Assist.

En las siguientes secciones, crearás un activador de Cloud Build programado que se ejecute de forma periódica. Este activador recupera recomendaciones de Active Assist mediante una función kpt y determina si hay recomendaciones activas para los recursos de tu repositorio YOUR_PRIVATE_HYDRATED_REPO. La función kpt también crea un problema de GitHub en tu repositorio YOUR_PRIVATE_HYDRATED_REPO si hay recomendaciones activas para la configuración de recursos que se deben revisar y activar.

Generar una imagen de Cloud Build

En esta sección, debes generar una imagen de Cloud Build que tenga componentes kpt, gh y Nodo.

1. En Cloud Shell, compila y envía una imagen de Docker a Container Registry:

   gcloud auth configure-docker
   
   docker build -t gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1 ./recommender-kpt-function
   
   docker push gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1
   

Crea un activador de Cloud Build para tu repositorio hidratado

1. En Cloud Shell, crea el archivo de configuración necesario para configurar el activador de Cloud Build programado:

    envsubst < cloudbuild-scheduled-recommendations.template.yaml > cloudbuild-scheduled-recommendations.yaml
   

2. Cree el activador de Cloud Build:

   gcloud beta builds triggers create github \
     --name ActiveAssistScheduledRecommendations \
     --repo-name=YOUR_PRIVATE_HYDRATED_REPO \
     --repo-owner=$REPO_OWNER \
     --branch-pattern="main" \
     --build-config=cloudbuild-scheduled-recommendations.yaml
   

3. Obtén el ID de este activador:

   export TRIGGER_ID=`gcloud beta builds triggers describe \
     ActiveAssistScheduledRecommendations \
     --format="value(id)"`
   

Crea un trabajo de Cloud Scheduler para invocar el activador

1. En Cloud Shell, crea una cuenta de servicio:

   gcloud iam service-accounts create build-invoker \
      --description "Service Account used by Cloud Scheduler to invoke the sample scheduled Cloud Build job" \
      --display-name "recommender-scheduler-sa" \
      --project $RECO_MGR_PROJECT
   

   Los trabajos de Cloud Scheduler usan esta cuenta de servicio para ejecutar el servicio recommender-parser.

2. Otorga a la cuenta de servicio los permisos para invocar un trabajo de Cloud Build:

   gcloud projects add-iam-policy-binding $RECO_MGR_PROJECT \
     --member serviceAccount:build-invoker@$RECO_MGR_PROJECT.iam.gserviceaccount.com \
     --role roles/cloudbuild.builds.editor \
     --project $RECO_MGR_PROJECT
   
    gcloud projects add-iam-policy-binding $RECO_MGR_PROJECT \
      --member serviceAccount:build-invoker@$RECO_MGR_PROJECT.iam.gserviceaccount.com \
      --role roles/serviceusage.serviceUsageConsumer \
      --project $RECO_MGR_PROJECT
   

3. Crea un trabajo de Cloud Scheduler para invocar el activador que creaste en el paso anterior:

   gcloud scheduler jobs create http scheduled-build \
      --project $RECO_MGR_PROJECT \
      --time-zone "America/Los_Angeles" \
      --schedule="0 */3 * * *" \
      --uri="https://cloudbuild.googleapis.com/v1/projects/${RECO_MGR_PROJECT}/triggers/${TRIGGER_ID}:run" \
      --description="Scheduler job to invoke Cloud Build" \
      --oauth-service-account-email="build-invoker@$RECO_MGR_PROJECT.iam.gserviceaccount.com" \
      --headers="Content-Type=application/json" \
      --http-method="POST" \
   

   Selecciona Y si ves el mensaje siguiente:

   There is no App Engine app in the project.

   Si se te solicita que elijas la región en la que deseas que se ubique tu aplicación de App Engine, selecciona la región us-central.

Confirma y envía los archivos de configuración de Cloud Build a GitHub

Envía los dos archivos de configuración de Cloud Build que creaste a tu repositorio YOUR_PRIVATE_DRY_REPO:

git remote add dry https://github.com/$REPO_OWNER/$DRY_REPO_NAME.git

git add cloudbuild.yaml
git add cloudbuild-scheduled-recommendations.yaml
git commit -m "Added cloudbuild configuration YAMLs"
git push dry main

Es posible que se te solicite ingresar tus credenciales de GitHub cuando envíes a tu repositorio privado.

Revisa el resultado del trabajo de Cloud Build

Cuando confirmas y envías cambios a tu repositorio YOUR_PRIVATE_DRY_REPO, se activa el trabajo de Cloud Build. Si el trabajo de Cloud Build se ejecuta de forma correcta, se crean varios recursos. En esta sección, debes verificar si los recursos se crean después de que se complete el trabajo de Cloud Build.

1. En Cloud Shell, en el clúster sample-ops, valida que tengas un espacio de nombres llamado activeassist-kcc:

   kubectl get ns | grep activeassist-kcc
   

2. Config Connector implementa una instancia de Compute Engine de muestra en ejecución en el proyecto PROJECT_ID.

   Valida que la instancia de Compute Engine esté en el proyecto:

    gcloud compute instances list | grep \
    computeinstance-sample-cloudmachine
   

   El tipo MACHINE_TYPE para esta máquina es n1-standard-1.

Ejecuta pruebas de extremo a extremo

A fin de permitirte probar la canalización de extremo a extremo, el repositorio que clonaste para este instructivo proporciona recomendaciones de muestra (stubs). Usa estos stubs para ejecutar la canalización de extremo a extremo. El stub imita una carga útil de recomendación de Active Assist y tiene una recomendación para cambiar el tipo de máquina de la instancia de Compute Engine que se implementó del tipo de instancia n1-standard-1 al tipo de instancia g1-small.

En esta sección, invocarás el activador de Cloud Build programado de forma manual para ejecutar el trabajo que usa una función kpt a fin de recuperar recomendaciones de Active Assist. También verificas que se haya creado un problema de GitHub en tu repositorio YOUR_PRIVATE_DRY_REPO.

1. Abre la página Activadores de compilación en la consola de Google Cloud.

   Abrir la página Activadores de compilación

2. Selecciona el activador ActiveAssistScheduledRecommendations.

3. Para probar el activador de forma manual, haz clic en Ejecutar en la entrada de tu activador en la lista.

   El activador crea un problema de GitHub en tu repositorio YOUR_PRIVATE_DRY_REPO. El problema es similar a este:

   gcloud auth configure-docker
   
   docker build -t gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1 ./recommender-kpt-function
   
   docker push gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1
   

   En el problema de muestra, el resultado de la función kpt muestra que el tipo MACHINE_TYPE actual para la instancia de Compute Engine es del tipo n1-standard-1. La recomendación de Active Assist es cambiarla a un tipo g1-small.

   Los revisores de control de versiones de tu empresa pueden revisar los problemas automatizados de GitHub y tomar medidas según corresponda para tu empresa.

Limpia

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.

Precaución: Borrar un proyecto tiene estas consecuencias:
• Se borra todo en el proyecto. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
• Se pierden los ID personalizados de proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URL que utilizan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto en lugar de borrar todo el proyecto.
1. En la consola de Google Cloud, ve a la página Administrar recursos.

   Ir a Administrar recursos

2. En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
3. En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.

¿Qué sigue?

• Obtén más información sobre las tecnologías sin servidores de Google Cloud.
• Obtén más información para integrar las recomendaciones de Policy Intelligence en una canalización de infraestructura como código (IaC).