Utilizzo della catena di strumenti GKE Enterprise con Active Assist

Questo documento fa parte di una serie che illustra i modelli architetturali che che le aziende possono usare per ottimizzare la propria presenza su cloud su larga scala Assistenza. Il tutorial mostra come creare una pipeline di automazione per i consigli di Active Assist che funzioni con la toolchain GKE Enterprise. È rivolto a chi utilizza Config Sync per gestire i propri ambienti GKE Enterprise e Config Connector per gestire le risorse Google Cloud. Le altre parti della serie sono:

La pipeline di automazione creata in questo tutorial può aiutarti a ottenere quanto segue:

  • L'utilizzo su larga scala del portafoglio di Active Assist nelle tue dell'organizzazione.
  • Integrando Active Assist nell'integrazione continua e distribuzione continua (CI/CD).
  • Controllo della revisione e dell'attivazione di Active Assist i suggerimenti usando costrutti come problemi di GitHub e richieste di pull.

Questo tutorial utilizza anche kpt, un toolkit open source sviluppato da Google per aiutarti a gestire, manipolare, personalizzare e applicare i file di dati di configurazione delle risorse Kubernetes.

Architettura

Il seguente diagramma di architettura mostra i componenti utilizzati in questo tutorial.

Componenti utilizzati nell'architettura.

I componenti vengono utilizzati nei seguenti modi:

  • Un GitHub non ripetizione (DRY), che viene utilizzato per i modelli di Config Connector che di cui esegui il deployment in vari progetti nella tua organizzazione Google Cloud.
  • Uno o più repository GitHub specifici di un progetto e mantenere i file di configurazione idratati. Questi repository idratati sono destinati agli ambienti gestiti da Config Sync. Usano Config Connector per attivare e gestire le risorse Google Cloud nell'organizzazione Google Cloud.
  • Un cluster GKE che utilizza Config Sync per la versione il controllo e il rilevamento della deviazione. Questo cluster include anche Config Connector installato. Config Connector consente al cluster di gestire le risorse Google Cloud nell'organizzazione Google Cloud.
  • Un trigger Cloud Build che attiva una build quando un modello viene eseguito push nel repository DRY di GitHub.
  • Un trigger di Cloud Build pianificato che attiva una compilazione periodicamente. Il job di compilazione utilizza una funzione kpt. La funzione richiama le API del motore per suggerimenti Active Assist per recuperare personalizzati. Esaminare e analizzare i consigli per determinare se Le risorse Google Cloud gestite da Config Connector devono ridimensionate o ottimizzate. La funzione kpt crea un problema di GitHub nel file DRY con i dettagli della modifica consigliata se il valore Le risorse Google Cloud gestite dal connettore devono essere ridimensionate ottimizzate.

Il flusso di lavoro per questa architettura è il seguente:

  1. I team autorizzati con accesso al repository DRY creano gestire i modelli di Config Connector nel repository.
  2. Un job Cloud Build viene attivato quando viene creato un modello modificato e registrato nel ramo main.
  3. Il job Cloud Build esegue l'idratazione dei modelli chiamando i settaggi kpt. Il job spinge i file di configurazione idratati nel repository GitHub idratato. Secret Manager viene utilizzato per archiviare le chiavi di deployment di GitHub per il repository privato.
  4. Config Sync monitora le modifiche al repository idratato e applica gli aggiornamenti trovati nel repository al cluster gestito.
  5. Config Connector monitora le modifiche e attiva le risorse Google Cloud se è necessario crearne o aggiornarne a seguito delle modifiche al Kubernetes Resource Model (KRM) applicate da Config Sync.
  6. Un attivatore Cloud Build pianificato viene eseguito periodicamente per invocare l'API Recommender al fine di recuperare i consigli attivi per i progetti gestiti da Config Connector.
  7. Il job Cloud Build pianificato esegue una funzione kpt personalizzata per richiamare l'API Recommender e recuperare e analizzare gli elementi attivi personalizzati.
  8. La funzione kpt crea un problema GitHub che mostra un confronto tra la configurazione corrente della risorsa e la configurazione consigliata per la risorsa. Con questo approccio, i problemi GitHub vengono creati nel repository DRY, il che semplifica il monitoraggio delle modifiche al repository.

Obiettivi

  • Crea i seguenti repository GitHub di esempio:
    • Un repository DRY per i KRM di Config Connector.
    • Un repository per contenere i file di configurazione idratati generati utilizzando kpt setters.
  • Crea un cluster GKE con Config Sync e Config Connector.
  • Crea una funzione kpt di esempio per recuperare Active Assist per i progetti gestiti da Config Connector.
  • Crea un trigger Cloud Build che venga attivato quando un modello viene inviato al ramo main del repository DRY.
  • Crea un job Cloud Build pianificato che viene eseguito periodicamente per recuperare i consigli di Active Assist disponibili per le risorse gestite da Config Connector.
  • Testare la pipeline end-to-end con i suggerimenti stub forniti in il repository GitHub per questo tutorial.

Costi

In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi basata sull'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

Una volta completate le attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la pagina Pulizia.

Prima di iniziare

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

    Go to project selector

  2. Select or create a Google Cloud project.

  3. Prendi nota dell'ID progetto Google Cloud. Userai questo ID nella sezione successiva quando configuri l'ambiente. Questo progetto è a cui si fa riferimento in come progetto build.

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

    Enable the APIs

    Per questo tutorial utilizzerai le credenziali dell'applicazione predefinite. Se viene chiesto di creare le credenziali nella pagina Aggiungi credenziali progetto, fai clic su Annulla.

  5. Make sure that billing is enabled for your Google Cloud project.

Configurazione dell'ambiente

In questo tutorial, esegui tutti i comandi in Cloud Shell.

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

    Activate Cloud Shell

  2. Imposta le variabili per l'ID e il numero di progetto dell'attuale build Progetto 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)')

    Sostituisci PROJECT_ID con l'ID progetto che hai annotato nella sezione precedente.

  3. Imposta le variabili per la regione di deployment:

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

  4. Clona il repository che contiene il codice per l'app di esempio utilizzata in questo tutorial:

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

  5. Vai alla directory del progetto:

    cd activeassist-anthos-toolchain

Crea la pipeline

In questa sezione, creerai i componenti per creare una pipeline o un blocco note personalizzato. I suggerimenti di Active Assist vengono generati in base a modelli di utilizzo e metriche di sistema. Ogni categoria di suggerimenti può utilizzare un parametro diversa finestra di tempo predefinita per analizzare i dati e le metriche di utilizzo in base ai suggerimenti che vengono generati. Per testare la pipeline end-to-end, il repository che hai clonato in un passaggio precedente fornisce esempi i suggerimenti (stub) che utilizzi per eseguire la pipeline end-to-end.

In alternativa, se esegui la pipeline in un progetto di esempio con risorse e consigli esistenti, puoi apportare le modifiche necessarie al codice di esempio ed eseguire la pipeline.

Configura repository GitHub privati di esempio

Nelle sezioni seguenti, configurerai i repository GitHub di esempio per questo tutorial.

Configura un repository GitHub DRY privato

  1. Crea un repository GitHub privato per il repository DRY. Prendi nota del nome assegnato al repository.

  2. In Cloud Shell, crea una variabile di ambiente per il tuo GitHub nome utente e il nome del repository DRY:

    export REPO_OWNER=YOUR_GITHUB_USERNAME
export DRY_REPO_NAME=YOUR_PRIVATE_DRY_REPO

    Sostituisci quanto segue:

    • YOUR_GITHUB_USERNAME: il tuo nome utente GitHub.
    • YOUR_PRIVATE_DRY_REPO: il nome del repository DRY.

  3. Crea un token di accesso personale (PAT) per creare problemi in questo repository Git. La pipeline crea problemi GitHub se sono presenti consigli di Active Assist che devono essere esaminati. Per Per saperne di più sulla creazione di PAT in GitHub, consulta la documentazione GitHub.

    Quando imposti un ambito per questo token, seleziona Controllo completo dei repository privati.

  4. In Cloud Shell, crea una variabile di ambiente per il token PAT che hai generato:

    export GITHUB_TOKEN=YOUR_PERSONAL_ACCESS_TOKEN

    Sostituisci YOUR_PERSONAL_ACCESS_TOKEN con il tuo token.

Configurare un repository GitHub privato idratato

  1. Crea un repository GitHub privato per il repository idratato. Prendi nota del nome assegnato al repository.

  2. In Cloud Shell, imposta una variabile di ambiente per il repository idratato:

    export HYDRATED_REPO_NAME=YOUR_PRIVATE_HYDRATED_REPO
export HYDRATED_REPO='git@github.com:$REPO_OWNER/$HYDRATED_REPO_NAME.git'

    Sostituisci YOUR_PRIVATE_HYDRATED_REPO con il nome del repository idratato.

  3. Crea una coppia di chiavi di deployment:

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

    Una chiave di deployment ti consente di eseguire il deployment nel tuo repository GitHub privato quando esegui un job Cloud Build per eseguire l'hydration dei file di configurazione.

  4. Stampa la chiave generata:

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

  5. Aggiungi la chiave di deployment al repository GitHub privato. Assicurati di selezionare Consenti accesso in scrittura quando aggiungi la chiave di deployment. Per scoprire come aggiungere eseguire il deployment delle chiavi nei repository GitHub, consulta la documentazione di GitHub per Gestione delle chiavi di deployment.

Carica le chiavi GitHub in Secret Manager

  1. In Cloud Shell, crea un secret per archiviare la chiave privata coppia di chiavi per il deployment:

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

  2. Crea un secret per archiviare il PAT:

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

Crea un cluster GKE

In questa sezione creerai un cluster GKE con Config Connector creare un'identità e configurare Config Connector. Inoltre, configuri Config Sync. Puoi utilizzare Config Sync per creare una configurazione comune in tutta la tua infrastruttura, inclusi i criteri personalizzati, e applicarla sia on-premise che nel cloud. Config Sync valuta le modifiche e le applica a tutti i cluster Kubernetes in modo che lo stato desiderato venga sempre applicato ai cluster.

  1. In Cloud Shell, crea un nuovo cluster GKE con Componente aggiuntivo Config Connector attivato:

    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 le seguenti sezioni della guida Installazione con il componente aggiuntivo GKE per creare un'identità e configurare Config Connector.

    1. Creazione di un'identità
    2. Configurare Config Connector

  3. Installa Config Sync nel cluster GKE che hai creato. Quando configuri Config Sync, devi eseguire queste operazioni:

    1. Utilizza un token a concedere a Config Sync l'accesso di sola lettura a Git. Usa il token GitHub che creato durante la configurazione di un repository DRY GitHub privato. Il token è disponibile tramite la variabile di ambiente $GITHUB_TOKEN.
    2. Configura Config Sync utilizzando gcloud. Imposta le seguenti impostazioni:
      1. sourceFormat: hierarchy
      2. syncRepo: https://github.com/YOUR_GITHUB_USERNAME/YOUR_PRIVATE_HYDRATED_REPO
      3. syncBranch: main
      4. secretType: token
      5. policyDir: non compilare questa opzione

Crea un trigger di Cloud Build per il push al repository con hydration

Nelle sezioni seguenti, creerai un trigger Cloud Build che viene attivato quando i modelli vengono sottoposti a push nel ramo principale del tuo repository YOUR_PRIVATE_DRY_REPO. Questo trigger esegue i passaggi che idratano il KRM config-as-data modelli nel YOUR_PRIVATE_DRY_REPO ed esegue il push dei file di configurazione idratati sul tuo YOUR_PRIVATE_HYDRATED_REPO repository Git.

Connetti Cloud Build ai tuoi repository GitHub

In questa sezione, colleghi i repository GitHub YOUR_PRIVATE_DRY_REPO e YOUR_PRIVATE_HYDRATED_REPO a Cloud Build.

  1. Vai alla pagina del Marketplace di GitHub per l'app Cloud Build.

    Vai alla pagina dell'app Cloud Build

  2. Fai clic su Configura con Google Cloud Build.

  3. Se richiesto, accedi a GitHub.

  4. Seleziona Seleziona solo i repository.

    Utilizza il menu a discesa Seleziona repository per abilitare l'accesso ai tuoi YOUR_PRIVATE_DRY_REPO e YOUR_PRIVATE_HYDRATED_REPO tramite l'app Cloud Build.

  5. Fai clic su Installa.

  6. Accedi a Google Cloud. Viene visualizzata la pagina Autorizzazione e ti viene chiesto di autorizzare l'app Google Cloud Build a connettersi a Google Cloud.

  7. Fai clic su Autorizza Google Cloud Build di GoogleCloudBuild. Si aprirà la console Google Cloud.

  8. Selezionare il tuo progetto Google Cloud.

  9. Seleziona la casella di controllo per il consenso e fai clic su Avanti.

  10. Fai clic su Installa.

  11. Accedi a Google Cloud. Viene visualizzata la pagina Autorizzazione e ti viene chiesto di autorizzare l'app Google Cloud Build a connettersi a Google Cloud.

  12. Fai clic su Autorizza Google Cloud Build di GoogleCloudBuild. Si aprirà la console Google Cloud.

  13. Selezionare il tuo progetto Google Cloud.

  14. Seleziona la casella di controllo per il consenso e fai clic su Avanti.

  15. Nella pagina Seleziona repository visualizzata, seleziona il seguente GitHub repository:

    • YOUR_PRIVATE_DRY_REPO
    • YOUR_PRIVATE_HYDRATED_REPO

  16. Fai clic su Connetti e poi su Fine.

Crea un trigger di Cloud Build per il repository DRY

  1. In Cloud Shell, esegui questo comando:

    envsubst < cloudbuild.template.yaml > cloudbuild.yaml

    Il comando genera un file cloudbuild.yaml.

  2. Crea l'attivatore:

    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. Concedi all'account di servizio Cloud Build l'autorizzazione ad accedere 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 trigger Cloud Build pianificato per i suggerimenti Active Assist

Nelle sezioni seguenti creerai un trigger Cloud Build pianificato che viene eseguita periodicamente. Questo attivatore recupera Active Assist usando una funzione kpt e determina se sono presenti per le risorse YOUR_PRIVATE_HYDRATED_REPO repository Git. La funzione kpt crea anche un problema su GitHub YOUR_PRIVATE_HYDRATED_REPO repository attivo se esistono suggerimenti attivi per la configurazione delle risorse che devono essere esaminati e attivati.

Genera un'immagine Cloud Build

In questa sezione, generi un Cloud Build un'immagine che contiene kpt, gh, e i componenti Nodo.

  1. In Cloud Shell, crea ed esegui il push di un'immagine Docker in 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 trigger di Cloud Build per il tuo repository idratato

  1. In Cloud Shell, crea il file di configurazione necessario per configurare l'attivatore Cloud Build pianificato:

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

  2. Crea l'trigger di 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. Ottieni l'ID di questo trigger:

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

Crea un job Cloud Scheduler per richiamare il trigger

  1. In Cloud Shell, crea un account di servizio:

    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

    I job Cloud Scheduler utilizzano questo account di servizio per eseguire il serviziorecommender-parser.

  2. Concedi all'account di servizio le autorizzazioni per invocare un job 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 job Cloud Scheduler per richiamare il trigger creato nel passaggio precedente:

    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" \

    Seleziona Y se viene visualizzato il seguente messaggio:

    There is no App Engine app in the project.

    Se ti viene chiesto di scegliere la regione in cui vuoi collocare l'applicazione App Engine, seleziona la regione us-central.

Esegui il commit dei file di configurazione di Cloud Build ed eseguine il push su GitHub

Esegui il push dei due file di configurazione di Cloud Build che hai creato nel YOUR_PRIVATE_DRY_REPO repository:

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

È possibile che ti venga chiesto di inserire le credenziali di GitHub quando esegui il push nel tuo repository privato.

Esamina il risultato del job Cloud Build

Quando esegui il commit e il push delle modifiche repository YOUR_PRIVATE_DRY_REPO, Il job Cloud Build viene attivato. Se il job Cloud Build viene eseguito vengono create diverse risorse. In questa sezione verifichi se le risorse vengono create al termine del job Cloud Build.

  1. In Cloud Shell, nel cluster sample-ops, conferma di hanno uno spazio dei nomi denominato activeassist-kcc:

    kubectl get ns | grep activeassist-kcc

  2. Config Connector esegue il deployment di un'istanza Compute Engine di esempio in esecuzione nel tuo progetto PROJECT_ID.

    Verifica che l'istanza Compute Engine sia nel progetto:

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

    Il tipo MACHINE_TYPE per questa macchina è n1-standard-1.

Eseguire test end-to-end

Per consentirti di testare la pipeline end-to-end, il repository che hai clonato per questo tutorial fornisce consigli di esempio (stub). Questi stub vengono utilizzati per eseguire una pipeline end-to-end. Lo stub imita un payload del consiglio di assistenza attiva e contiene un consiglio per modificare il tipo di macchina dell'istanza Compute Engine di cui è stato eseguito il deployment dal tipo di istanza n1-standard-1 al tipo di istanza g1-small.

In questa sezione, richiamerai il trigger di Cloud Build pianificato manualmente per eseguire il job che utilizza una funzione kpt per recuperare Suggerimenti di Active Assist. Verifica inoltre che nel tuo repository YOUR_PRIVATE_DRY_REPO sia stato creato un problema GitHub.

  1. Apri la pagina Trigger di compilazione nella console Google Cloud.

    Apri la pagina Trigger di build

  2. Seleziona l'attivatore ActiveAssistScheduledRecommendations.

  3. Per testare manualmente l'attivatore, fai clic su Esegui nella voce corrispondente nell'elenco dei trigger.

    L'attivatore crea un problema GitHub nel YOUR_PRIVATE_DRY_REPO repository. Il problema è simile al seguente:

    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

    Nel problema di esempio, l'output della funzione kpt mostra che l'attuale Tipo MACHINE_TYPE per Compute Engine è di tipo n1-standard-1. Il consiglio per l'assistenza attiva è di cambiarlo in un tipo g1-small.

    I revisori del controllo delle versioni nella tua azienda possono esaminare GitHub automatizzato risolvere i problemi e intervenire in modo appropriato per la tua azienda.

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

  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.

Passaggi successivi