Scalabilità manuale

Questa pagina descrive come scalare manualmente il servizio. Fornisce inoltre istruzioni per un caso d'uso comune, ovvero la modifica del conteggio delle istanze in base a una pianificazione utilizzando i job Cloud Scheduler e l'API Cloud Run Admin.

Panoramica

Per impostazione predefinita, Cloud Run esegue automaticamente lo scale out fino a un numero massimo di istanze specificato o predefinito a seconda del traffico e dell'utilizzo della CPU. Tuttavia, per alcuni casi d'uso, potresti voler impostare un numero specifico di istanze utilizzando lo scaling manuale.

La scalabilità manuale ti consente di impostare un numero specifico di istanze, indipendentemente dal traffico o dall'utilizzo e senza richiedere il redeploy. Tutto ciò ti offre la possibilità di scrivere la tua logica di scalabilità utilizzando un sistema esterno. Per un esempio, consulta la sezione Scalabilità basata sulla pianificazione.

Impostazioni minime e massime a livello di revisione e scalabilità manuale

Se imposti il servizio sulla scalabilità manuale, le impostazioni del numero minimo e massimo di istanze a livello di revisione vengono ignorate.

Suddivisioni del traffico per la scalabilità manuale

Il seguente elenco descrive come vengono allocate le istanze quando il traffico viene suddiviso in base allo scaling manuale. Sono inclusi i comportamenti per le revisioni solo con tag di traffico.

• Durante una suddivisione del traffico, a ogni revisione vengono allocate istanze in modo proporzionale, in base alla suddivisione del traffico, in modo simile alla suddivisione del traffico con istanze minime a livello di servizio.

• Se il numero di revisioni che ricevono traffico supera il conteggio manuale delle istanze, alcune revisioni non avranno istanze. Il traffico inviato a queste revisioni riceverà lo stesso errore che si verifica se le revisioni sono disattivate.

• Per tutte le revisioni che ricevono traffico in una suddivisione del traffico, le istanze minime e massime a livello di revisione sono disattivate.

• Se una revisione è attiva solo a causa dei tag di traffico:

  • Se è impostato il numero minimo di istanze a livello di revisione, il numero specificato di istanze verrà avviato, ma non verrà conteggiato ai fini del conteggio totale delle istanze manuali del servizio. La revisione non verrà scalata automaticamente.
  • Se non è impostato il numero minimo di istanze a livello di revisione, la revisione viene scalata orizzontalmente fino a un massimo di un'istanza, in risposta al traffico inviato all'URL del tag.

Comportamento di fatturazione con la scalabilità manuale

Quando utilizzi lo scaling manuale, il comportamento di fatturazione è simile a quello che si verifica quando utilizzi la funzionalità Istanze minime.

ovvero, con la scalabilità manuale e la fatturazione basata sulle istanze, le istanze inattive scalate manualmente vengono fatturate come istanze attive.

Se utilizzi la scalabilità manuale con la fatturazione basata sulle richieste, le istanze inattive scalate manualmente vengono fatturate come istanze minime inattive. Per i dettagli completi della fatturazione, consulta la pagina dei prezzi.

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per eseguire il deployment dei servizi Cloud Run, chiedi all'amministratore di concederti i seguenti ruoli IAM:

• Cloud Run Developer (roles/run.developer) sul servizio Cloud Run
• Utente service account (roles/iam.serviceAccountUser) sull'identità di servizio
• Lettore Artifact Registry (roles/artifactregistry.reader) sul repository Artifact Registry dell'immagine container di cui è stato eseguito il deployment (se applicabile)

Per un elenco di ruoli e autorizzazioni IAM associati a Cloud Run, consulta Ruoli IAM Cloud Run e Autorizzazioni IAM Cloud Run. Se il tuo servizio Cloud Run interagisce con le APIGoogle Cloud , come le librerie client Cloud, consulta la guida alla configurazione dell'identità del servizio. Per ulteriori informazioni sulla concessione dei ruoli, consulta Autorizzazioni di deployment e Gestire l'accesso.

Configura scalabilità

Puoi configurare la modalità di scalabilità utilizzando la console Google Cloud , Google Cloud CLI, il file YAML o l'API quando crei o aggiorni un servizio:

gcloud beta run deploy SERVICE \
    --scaling=INSTANCE_COUNT \
    --image IMAGE_URL

gcloud beta run services update SERVICE \
   --scaling=INSTANCE_COUNT

    curl -H "Content-Type: application/json" \
    -H "Authorization: Bearer ACCESS_TOKEN" \
    -X PATCH \
    -d '{"launchStage":"BETA","scaling":{"manualInstanceCount":MANUAL_INSTANCE_COUNT }}' \
    https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services/SERVICE?update_mask=launchStage,scaling.manualInstanceCount

resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE_NAME"
  location = "REGION"
  launch_stage = "BETA"

  template {
    containers {
      image = "IMAGE_URL"
    }
  }
  scaling {
    scaling_mode = "MANUAL"
    manual_instance_count = "INSTANCE_COUNT"
  }
}

Visualizzare la configurazione della scalabilità per il servizio

Per visualizzare le istanze di configurazione dello scaling per il tuo servizio Cloud Run:

gcloud beta run services describe SERVICE

gcloud run services describe SERVICE --format export > service.yaml

Disattivazione di un servizio

Quando disabiliti un servizio, le richieste attualmente in fase di elaborazione potranno essere completate. Tuttavia, qualsiasi ulteriore richiesta all'URL del servizio non andrà a buon fine e verrà restituito un errore Service unavailable o Service disabled.

Le richieste di revisione del servizio attive solo a causa dei tag di traffico non sono interessate perché queste revisioni non sono disattivate.

Per disattivare un servizio, imposta la scalabilità su zero. Puoi disattivare un servizio utilizzando la console Google Cloud , Google Cloud CLI, il file YAML o l'API:

gcloud beta run services update SERVICE --scaling=0

    curl -H "Content-Type: application/json" \
    -H "Authorization: Bearer ACCESS_TOKEN" \
    -X PATCH \
    -d '{"launchStage":"BETA","scaling":{"manualInstanceCount":0 }}' \
    https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services/SERVICE?update_mask=launchStage,scaling.manualInstanceCount

resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE_NAME"
  location = "REGION"
  launch_stage = "BETA"

  template {
    containers {
      image = "IMAGE_URL"
    }
  }
  scaling {
    scaling_mode = "MANUAL"
    manual_instance_count = "0"
  }
}

Esempio di scalabilità basata sulla pianificazione

Un caso d'uso comune della scalabilità manuale è la modifica del conteggio delle istanze in base a una pianificazione predefinita. In questo esempio, utilizziamo Cloud Scheduler per pianificare due job, ognuno dei quali richiama l'API Cloud Run Admin per scalare il numero di istanze. Il primo job imposta il servizio in modo che venga scalato manualmente a 10 istanze durante l'orario di lavoro (9:00-17:00, dal lunedì al venerdì). Il secondo job imposta la scalabilità del servizio fino a zero istanze durante le ore non di punta.

Tieni presente che l'impostazione delle istanze su zero, come mostrato nell'esempio, disattiva il servizio, ma non i job Cloud Scheduler. Questi job continuano a essere eseguiti e reimposteranno (e riattiveranno) il servizio su 10 istanze come pianificato.

In questo esempio, utilizziamo la guida rapida di Cloud Run per semplicità, ma puoi utilizzare un servizio a tua scelta.

Per configurare lo scaling manuale basato sulla pianificazione:

1. Esegui il deployment del servizio utilizzando questo comando:

   gcloud beta run deploy SERVICE \
      --image=us-docker.pkg.dev/cloudrun/container/hello \
      --region=REGION \
      --project PROJECT_ID

   Sostituisci le seguenti variabili:

   • REGION con la regione in cui viene eseguito il deployment del servizio Cloud Run.
   • SERVICE con il nome del servizio Cloud Run.

2. Configura il servizio per lo scaling manuale a 10 istanze utilizzando il seguente comando:

   gcloud beta run services update SERVICE \
      --region=REGION \
      --scaling=10

3. Crea un job Cloud Scheduler che aumenti manualmente il numero di istanze del servizio fino a 10 durante l'orario lavorativo:

   gcloud scheduler jobs create http hello-start-instances \
     --location=REGION \
     --schedule="0 9 * * MON-FRI" \
     --time-zone=America/Los_Angeles \
     --uri=https://run.googleapis.com/v2/projects/PROJECT_ID/
     locations/REGION/services/hello?update_mask=launchStage,scaling.manualInstanceCount \
     --headers=Content-Type=application/json,X-HTTP-Method-Override=PATCH \
     --http-method=PUT \
     --message-body='{"launchStage":"BETA","scaling":{"manualInstanceCount":10}}' \
     --oauth-service-account-email=PROJECT_NUMBER-compute@developer.gserviceaccount.com

   Questo comando crea un job Cloud Scheduler che effettua una chiamata HTTP all'API Cloud Run Admin, impostando il numero di istanze su 10. L'esempio utilizza l'account di servizio predefinito di Compute Engine PROJECT_NUMBER-compute@developer.gserviceaccount.com per i job Cloud Scheduler. Puoi utilizzare qualsiasi account di servizio che disponga delle autorizzazioni per aggiornare i servizi Cloud Run.

4. Crea un job Cloud Scheduler che esegue manualmente lo scale delle istanze del servizio a zero istanze durante le ore non lavorative, disabilitando il servizio:

   gcloud scheduler jobs create http hello-stop-instances \
     --location=REGION \
     --schedule="0 17 * * MON-FRI" \
     --time-zone=America/Los_Angeles \
     --uri=https://run.googleapis.com/v2/projects/PROJECT_ID/
     locations/REGION/services/hello?update_mask=launchStage,scaling.manualInstanceCount \
     --headers=Content-Type=application/json,X-HTTP-Method-Override=PATCH \
     --http-method=PUT \
     --message-body='{"launchStage":"BETA","scaling":{"manualInstanceCount":0}}' \
     --oauth-service-account-email=PROJECT_NUMBER-compute@developer.gserviceaccount.com

   Questo comando crea un job Cloud Scheduler che effettua una chiamata HTTP all'API Cloud Run Admin, impostando le istanze di scalabilità manuale su zero. In questo modo il servizio viene disattivato, ma non i job Cloud Scheduler, che continueranno a essere eseguiti e a reimpostare (e riattivare) il servizio su 10 istanze come pianificato.