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 pueden usar las empresas para optimizar su presencia en la nube a gran escala con Asistencia activa. En el tutorial se muestra cómo crear una canalización de automatización para las recomendaciones de Active Assist que funcione con la cadena de herramientas de GKE Enterprise. Está dirigido a los usuarios que utilizan Config Sync para gestionar sus entornos de GKE Enterprise y Config Connector para gestionar recursos de Google Cloud . Las otras partes de la serie son las siguientes:

• Patrones para usar Active Assist a gran escala
• Usar flujos de procesamiento sin servidor con Active Assist
• Usar la cadena de herramientas de GKE Enterprise con Active Assist (este documento)

El flujo de procesamiento automático que creará en este tutorial le ayudará a conseguir lo siguiente:

• Ampliar el uso de la cartera de Active Assist en tu organización.
• Integrar Active Assist en tu flujo de procesamiento de integración y entrega continuas (CI/CD).
• Controlar la revisión y la activación de las recomendaciones de Asistencia activa mediante elementos como las incidencias y las solicitudes de extracción de GitHub.

En este tutorial también se usa kpt, un kit de herramientas de código abierto desarrollado por Google para ayudarte a gestionar, 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 se usan en este tutorial.

Los componentes se usan de las siguientes formas:

• Un repositorio de GitHub no te repitas (DRY), que se usa para las plantillas de Config Connector que implementas en los proyectos de tu Google Cloud organización.
• Uno o varios repositorios de GitHub específicos de un proyecto o un entorno que contienen archivos de configuración hidratados. Estos repositorios hidratados son para los entornos que gestiona Config Sync. Usan Config Connector para activar y gestionar recursos de Google Cloud en la organización de Google Cloud .
• Un clúster de GKE que usa Config Sync para el control de versiones y la detección de desviaciones. Este clúster también tiene instalado Config Connector. Config Connector permite que el clúster gestione Google Cloud recursos de toda la Google Cloud organización.
• Un activador de Cloud Build que activa una compilación cuando se inserta una plantilla en el repositorio DRY de GitHub.
• Un activador de Cloud Build programado que activa una compilación periódicamente. El trabajo de compilación usa una función de kpt. La función invoca las APIs Recommender de Active Assist para obtener recomendaciones activas. Revisa y analiza las recomendaciones para determinar si es necesario cambiar el tamaño o optimizar losGoogle Cloud recursos que gestiona Config Connector. La función kpt crea un problema de GitHub en el repositorio DRY con los detalles del cambio recomendado si es necesario cambiar el tamaño o optimizar los recursos gestionados por Config Connector. Google Cloud

El flujo de trabajo de esta arquitectura es el siguiente:

1. Los equipos autorizados que tienen acceso al repositorio DRY crean y gestionan plantillas de Config Connector en el repositorio.
2. Un trabajo de Cloud Build se activa cuando se crea o se modifica una plantilla y se registra en la rama main.
3. El trabajo de Cloud Build hidrata las plantillas invocando los setters de kpt. El trabajo envía los archivos de configuración hidratados al repositorio de GitHub hidratado. Secret Manager se usa para almacenar las claves de implementación de GitHub del repositorio privado.
4. Config Sync monitoriza los cambios en el repositorio hidratado y aplica las actualizaciones encontradas en el repositorio al clúster gestionado.
5. Config Connector monitoriza los cambios y activa Google Cloud recursos si es necesario crear o actualizar alguno como resultado de los cambios del modelo de recursos de Kubernetes (KRM) aplicados por Config Sync.
6. Un activador de Cloud Build programado se ejecuta periódicamente para invocar la API Recommender y obtener recomendaciones activas para los proyectos que gestiona Config Connector.
7. La tarea programada de Cloud Build ejecuta una función kpt personalizada para invocar la API Recommender y obtener y analizar las 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 en el repositorio.

Objetivos

• Crea los siguientes repositorios de ejemplo de GitHub:
  • Un repositorio DRY para los KRMs de Config Connector.
  • Un repositorio para almacenar archivos de configuración hidratados generados con setters de kpt.
• Crea un clúster de GKE con Config Sync y Config Connector.
• Crea una función de kpt de ejemplo para obtener recomendaciones de Active Assist para proyectos gestionados por Config Connector.
• Crea un activador de Cloud Build que se active cuando se inserte una plantilla en la rama main del repositorio DRY.
• Crea una tarea de Cloud Build programada que se ejecute periódicamente para obtener las recomendaciones de Active Assist disponibles para los recursos que gestiona Config Connector.
• Prueba la canalización de extremo a extremo con las recomendaciones de stub proporcionadas en el repositorio de GitHub de este tutorial.

Costes

En este documento, se utilizan 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 costes basada en el uso previsto, utiliza la calculadora de precios.

Los usuarios nuevos Google Cloud pueden disfrutar de una prueba gratuita.

Cuando termines las tareas que se describen en este documento, puedes evitar que se te siga facturando eliminando los recursos que has creado. Para obtener más información, consulta la sección Limpiar.

Antes de empezar

1. In the Google Cloud console, go to the project selector page.

   Go to project selector

2. Select or create a Google Cloud project.

   Roles required to select or create a project

   • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
   • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.
   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.
3. Anota el Google Cloud ID del proyecto. Usarás este ID en la siguiente sección, cuando configures tu entorno. A lo largo del tutorial, se hará referencia a este proyecto como el proyecto build.

4. Enable the Cloud Build, Firestore, App Engine, Pub/Sub, Cloud Run, Cloud Scheduler, and Cloud Source Repositories APIs.

   Roles required to enable APIs

   To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

   Enable the APIs

   En este tutorial, se usan las credenciales de aplicación predeterminadas. Si se te pide que crees credenciales en la página Añadir credenciales a tu proyecto, haz clic en Cancelar.

5. Verify that billing is enabled for your Google Cloud project.

Configurar un entorno

En este tutorial, ejecutarás todos los comandos en Cloud Shell.

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

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

   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)')
   

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

3. Define las variables de 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 aplicación de ejemplo que se usa en este tutorial:

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

5. Ve al directorio del proyecto:

   cd activeassist-anthos-toolchain
   

Crear el flujo de procesamiento

En esta sección, crearás los componentes para crear la pipeline. Las recomendaciones de Active Assist se generan a partir de patrones de uso y métricas del sistema. Cada categoría de recomendación puede usar un periodo predeterminado diferente para analizar los datos de uso y las métricas en función de las recomendaciones que se generen. Para probar la canalización completa, el repositorio que clonó en un paso anterior proporciona recomendaciones de ejemplo (stubs) que puede usar para ejecutar la canalización completa.

También puedes ejecutar la canalización en un proyecto de ejemplo que tenga recursos y recomendaciones, hacer los cambios oportunos en el código de ejemplo y, a continuación, ejecutar la canalización.

Configurar repositorios privados de GitHub de ejemplo

En las siguientes secciones, configurará los repositorios de ejemplo de GitHub para este tutorial.

Configurar un repositorio de GitHub DRY privado

1. Crea un repositorio privado de GitHub para el repositorio DRY. Anota el nombre que le asignes al repositorio.

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

   export REPO_OWNER=YOUR_GITHUB_USERNAME
   export DRY_REPO_NAME=YOUR_PRIVATE_DRY_REPO
   

   Haz los cambios siguientes:

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

3. Crea un token de acceso personal (PAT) para crear incidencias en este repositorio. La canalización crea incidencias de GitHub si hay recomendaciones de Active Assist que deben revisarse. Para obtener más información sobre cómo crear PATs en GitHub, consulta la documentación de GitHub.

   Cuando definas un ámbito para este token, selecciona Control total de repositorios privados.

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

   export GITHUB_TOKEN=YOUR_PERSONAL_ACCESS_TOKEN
   

   Sustituye YOUR_PERSONAL_ACCESS_TOKEN por tu propio token.

Configurar un repositorio de GitHub privado hidratado

1. Crea un repositorio privado de GitHub para el repositorio hidratado. Anota el nombre que le asignes al repositorio.

2. En Cloud Shell, define 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'
   

   Sustituye 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 desplegar en tu repositorio privado de GitHub cuando ejecutas una tarea de Cloud Build para hidratar archivos de configuración.

4. Imprime la clave generada:

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

5. Añade la clave de implementación al repositorio privado de GitHub. Asegúrate de seleccionar Permitir acceso de escritura cuando añadas la clave de implementación. Para saber cómo añadir claves de implementación a repositorios de GitHub, consulta la documentación de GitHub sobre gestión de claves de implementación.

Subir 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=-
   

Crear un clúster de GKE

En esta sección, creará un clúster de GKE con el complemento Config Connector, creará una identidad y configurará Config Connector. También puedes configurar Config Sync. Puedes usar Config Sync para crear una configuración común que abarque toda tu infraestructura, incluidas tus políticas personalizadas, y aplicarla tanto en la nube como en tus entornos on-premise. Config Sync analiza los cambios y los implementa en todos los clústeres de Kubernetes para que siempre tengan el estado que quieras.

1. En Cloud Shell, crea un clúster de GKE con el complemento 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 de la guía Instalar con el complemento de GKE para crear una identidad y configurar Config Connector.

   1. Crear una identidad
   2. Configurar Config Connector

3. Instala Config Sync en el clúster de GKE que has creado. Cuando configures Config Sync, debes hacer lo siguiente:

   1. Usa un token para conceder acceso de solo lectura a Git a Config Sync. Usa el token de GitHub que creaste al configurar un repositorio de GitHub privado de DRY. El token está disponible a través de la variable de entorno $GITHUB_TOKEN.
   2. Configura Config Sync con gcloud. Define los siguientes ajustes:
      1. sourceFormat: hierarchy
      2. syncRepo: https://github.com/YOUR_GITHUB_USERNAME/YOUR_PRIVATE_HYDRATED_REPO
      3. syncBranch main
      4. secretType: token
      5. policyDir no rellene esta opción.

Crea un activador de Cloud Build para insertar en el repositorio hidratado

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

Conectar Cloud Build a tus repositorios de GitHub

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

1. Ve a la página de GitHub Marketplace de la aplicación Cloud Build.

   Ir a la página de la aplicación Cloud Build

2. Haz clic en Configurar con Google Cloud Build.

3. Si se te solicita, inicia sesión en GitHub.

4. Selecciona Solo repositorios seleccionados.

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

5. Haz clic en Instalar.

6. Inicia sesión en Google Cloud. Se muestra la página Autorización y se te pide que autorices a la aplicación Google Cloud Build para que se conecte a Google Cloud.

7. Haz clic en Autorizar Google Cloud Build por GoogleCloudBuild. Se te redirigirá a la consola de Google Cloud .

8. Selecciona tu proyecto de Google Cloud .

9. Selecciona la casilla de consentimiento y haz clic en Siguiente.

10. Haz clic en Instalar.

11. Inicia sesión en Google Cloud. Se muestra la página Autorización y se te pide que autorices a la aplicación Google Cloud Build para que se conecte a Google Cloud.

12. Haz clic en Autorizar Google Cloud Build por GoogleCloudBuild. Se te redirigirá a la consola de Google Cloud .

13. Selecciona tu proyecto de Google Cloud .

14. Selecciona la casilla 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, a continuación, en Hecho.

Crea un activador de Cloud Build para el repositorio DRY

1. En Cloud Shell, ejecuta 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. Concede 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"
   

Crear un activador de Cloud Build programado para las recomendaciones de Active Assist

Nota: En este tutorial, usarás stubs para probar la canalización. Cuando uses la pipeline para tus proyectos de Google Cloud , asegúrate de dar a la cuenta de servicio de Cloud Build los permisos que necesita para obtener recomendaciones de Active Assist.

En las siguientes secciones, creará un activador de Cloud Build programado que se ejecutará periódicamente. Este activador obtiene recomendaciones de Active Assist mediante una función de kpt y determina si hay alguna recomendación activa para los recursos de tu repositorio YOUR_PRIVATE_HYDRATED_REPO. La función kpt también crea un problema de GitHub en tu YOUR_PRIVATE_HYDRATED_REPO repositorio si hay recomendaciones activas para la configuración de recursos que deben revisarse y ponerse en práctica.

Generar una imagen de Cloud Build

En esta sección, generarás una imagen de Cloud Build que tenga componentes de kpt, gh y Node.

1. En Cloud Shell, crea y envía una imagen 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. Crea 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 una tarea 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
   

   Las tareas de Cloud Scheduler usan esta cuenta de servicio para ejecutar el servicio recommender-parser.

2. Concede 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 una tarea de Cloud Scheduler para invocar el activador que has creado 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 siguiente mensaje:

   There is no App Engine app in the project.

   Si se te pide que elijas la región en la que quieres ubicar tu aplicación de App Engine, selecciona la región us-central.

Confirma e inserta los archivos de configuración de Cloud Build en GitHub

Transfiere los dos archivos de configuración de Cloud Build que has creado 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 pida que introduzcas tus credenciales de GitHub cuando envíes contenido a tu repositorio privado.

Revisar el resultado del trabajo de Cloud Build

Cuando confirmas y envías los cambios a tu repositorio YOUR_PRIVATE_DRY_REPO, se activa el trabajo de Cloud Build. Si el trabajo de Cloud Build se ejecuta correctamente, se crearán varios recursos. En esta sección, verificará si los recursos se han creado una vez que se haya completado el trabajo de Cloud Build.

1. En Cloud Shell, en tu clúster sample-ops, comprueba que tienes un espacio de nombres llamado activeassist-kcc:

   kubectl get ns | grep activeassist-kcc
   

2. Config Connector implementa una instancia de Compute Engine de ejemplo en ejecución en tu 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 de esta máquina es n1-standard-1.

Ejecutar pruebas integrales

Para que puedas probar la canalización completa, el repositorio que has clonado para este tutorial proporciona recomendaciones de ejemplo (stubs). Estos stubs se usan para ejecutar la pipeline 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 ha implementado del tipo de instancia n1-standard-1 al tipo de instancia g1-small.

En esta sección, invocarás manualmente el activador de Cloud Build programado para ejecutar el trabajo que usa una función de kpt para obtener recomendaciones de Active Assist. También puedes verificar que se ha 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 .

   Abre la página Activadores de compilación.

2. Selecciona el activador ActiveAssistScheduledRecommendations.

3. Para probar el activador manualmente, haz clic en Ejecutar en la entrada del activador de la lista de activadores.

   El activador crea un problema de GitHub en tu YOUR_PRIVATE_DRY_REPO repositorio. El problema es similar al siguiente:

   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 ejemplo, el resultado de la función kpt muestra que el MACHINE_TYPEtipon1-standard-1 actual de la instancia de Compute Engine es n1-standard-1. La recomendación de Asistencia activa es cambiarlo a un tipo g1-small.

   Los revisores del control de versiones de tu empresa pueden revisar los problemas automatizados de GitHub y tomar las medidas oportunas para tu empresa.

Limpieza

Para evitar que los recursos utilizados en este tutorial se cobren en tu cuenta de Google Cloud, elimina el proyecto que contiene los recursos o conserva el proyecto y elimina los recursos.

Precaución: Eliminar un proyecto tiene los siguientes efectos:
• Se elimina todo el contenido del proyecto. Si has usado un proyecto que ya existía para las tareas de este documento, cuando lo elimines, también se eliminará cualquier otro trabajo que hayas realizado en él.
• Se pierden los IDs de proyecto personalizados. Cuando creaste este proyecto, es posible que hayas creado un ID de proyecto personalizado que quieras usar en el futuro. Para conservar las URLs que usan el ID del proyecto, como una URL appspot.com, elimina los recursos seleccionados dentro del proyecto en lugar de eliminar todo el proyecto.
1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Siguientes pasos

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