Escalonamento manual

Esta página descreve como dimensionar manualmente seu serviço. Ele também fornece instruções para um caso de uso comum, alterando a contagem de instâncias com base em uma programação usando jobs do Cloud Scheduler e a API Cloud Run Admin.

Visão geral

Por padrão, o Cloud Run escalona automaticamente para um número máximo especificado ou padrão de instâncias, dependendo do tráfego e da utilização da CPU. No entanto, em alguns casos de uso, talvez você queira definir um número específico de instâncias usando o escalonamento manual.

O escalonamento manual permite definir uma contagem de instâncias específica, independentemente do tráfego ou da utilização, sem exigir a nova implantação. Tudo isso oferece a opção de escrever sua própria lógica de escalonamento usando um sistema externo. Consulte Como escalonar com base em programações para conferir um exemplo.

Como alternar entre o escalonamento automático e manual

A mudança de modo de escalonamento afeta a contagem de instâncias e as configurações de instâncias mínimas no nível de serviço e máximas, conforme mostrado na tabela a seguir:

Configurações mínimas e máximas no nível da revisão e escalonamento manual

Se você definir o serviço para escalonamento manual, as configurações de instâncias mínimas no nível da revisão e máximas serão ignoradas.

Divisão de tráfego para escalonamento manual

A lista a seguir descreve como as instâncias são alocadas ao dividir o tráfego no escalonamento manual. Isso inclui o comportamento das revisões somente de tags de tráfego.

• Durante uma divisão de tráfego, cada revisão recebe instâncias alocadas proporcionalmente, com base na divisão de tráfego, semelhante à divisão de tráfego com instâncias mínimas no nível de serviço.

• Se o número de revisões que recebem tráfego exceder a contagem de instâncias manuais, algumas das revisões não terão instâncias. O tráfego enviado para essas revisões vai receber o mesmo erro que se as revisões estivessem desativadas.

• Para todas as revisões que recebem tráfego em uma divisão de tráfego, todas as instâncias mínimas e máximas no nível da revisão são desativadas.

• Se uma revisão estiver ativa somente devido a tags de tráfego:

  • Se as instâncias mínimas no nível da revisão estiverem definidas, o número especificado de instâncias será iniciado, mas não vai contar para a contagem total de instâncias manuais do serviço. A revisão não vai ser dimensionada automaticamente.
  • Se as instâncias mínimas no nível da revisão não estiverem definidas, a revisão será escalonada para no máximo uma instância, em resposta ao tráfego enviado para o URL da tag.

Comportamento de faturamento usando o escalonamento manual

Quando você usa o escalonamento manual, o comportamento de faturamento é semelhante ao comportamento quando você usa o recurso de instâncias mínimas.

Ou seja, com o escalonamento manual e o faturamento baseado em instâncias, as instâncias inativas com escalonamento manual são faturadas como instâncias ativas.

Se você usar o escalonamento manual com o faturamento baseado em solicitações, as instâncias inativas dimensionadas manualmente serão faturadas como instâncias mínimas inativas. Para detalhes completos de faturamento, consulte a página de preços.

Funções exigidas

Para receber as permissões necessárias para implantar os serviços do Cloud Run, peça ao administrador para conceder a você os seguintes papéis do IAM:

• Desenvolvedor do Cloud Run (roles/run.developer) no serviço Cloud Run
• Usuário da conta de serviço (roles/iam.serviceAccountUser) na conta de serviço
• Leitor do Artifact Registry (roles/artifactregistry.reader) no repositório do Artifact Registry da imagem de contêiner implantada (se aplicável)

Para uma lista de papéis e permissões do IAM associados ao Cloud Run, consulte Papéis do IAM do Cloud Run e Permissões do IAM do Cloud Run. Se o serviço do Cloud Run interagir com APIsGoogle Cloud , como as bibliotecas de cliente do Cloud, consulte o guia de configuração de identidade de serviço. Para mais informações sobre como conceder papéis, consulte permissões de implantação e gerenciar acesso.

Configurar o escalonamento

É possível configurar o modo de escalonamento usando o console do Google Cloud, a CLI do Google Cloud, o arquivo YAML ou a API ao criar ou atualizar um serviço:

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

Conferir a configuração de escalonamento do serviço

Para conferir as instâncias de configuração de escalonamento do serviço do Cloud Run:

gcloud beta run services describe SERVICE

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

Desativar um serviço

Quando você desativa um serviço, as solicitações que estão sendo processadas podem ser concluídas. No entanto, qualquer outra solicitação para o URL do serviço falhará com um erro Service unavailable ou Service disabled.

As solicitações de revisões de serviço que estão ativas apenas devido a tags de tráfego não são afetadas, porque essas revisões não são desativadas.

Para desativar um serviço, defina o escalonamento como zero. É possível desativar um serviço usando o console do Google Cloud, a CLI do Google Cloud, o arquivo YAML ou a 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

Exemplo de dimensionamento com base na programação

Um caso de uso comum do escalonamento manual é mudar a contagem de instâncias com base em uma programação predefinida. Neste exemplo, usamos o Cloud Scheduler para programar dois trabalhos, cada um deles invoca a API Cloud Run Admin para dimensionar o número de instâncias. O primeiro job define o serviço para escalonar manualmente para 10 instâncias durante o horário comercial (das 9h às 17h, de segunda a sexta). A segunda tarefa define o serviço para dimensionar para zero instâncias durante o horário de funcionamento.

Observe que definir as instâncias como zero, conforme mostrado no exemplo, desativa o serviço, mas não os jobs do Cloud Scheduler. Esses jobs continuam sendo executados e redefinirão (e reativarão) o serviço para 10 instâncias conforme programado.

Neste exemplo, usamos o guia de início rápido do Cloud Run para simplificar, mas você pode usar um serviço de sua preferência.

Para configurar o escalonamento manual com base na programação:

1. Implante o serviço usando o seguinte comando:

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

   Substitua as seguintes variáveis:

   • REGION pela região em que o serviço do Cloud Run foi implantado.
   • SERVICE pelo nome do serviço do Cloud Run.

2. Configure o serviço para escalonamento manual para 10 instâncias usando o seguinte comando:

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

3. Crie um job do Cloud Scheduler que dimensione manualmente as instâncias de serviço para 10 instâncias durante o horário comercial:

   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

   Esse comando cria um job do Cloud Scheduler que faz uma chamada HTTP para a API Cloud Run Admin, definindo o número de instâncias como 10. O exemplo usa a conta de serviço padrão do Compute Engine PROJECT_NUMBER-compute@developer.gserviceaccount.com para os jobs do Cloud Scheduler. É possível usar qualquer conta de serviço que tenha permissões para atualizar os serviços do Cloud Run.

4. Crie um job do Cloud Scheduler que escalone manualmente as instâncias do serviço para zero instâncias durante o horário de inatividade, desativando o serviço:

   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

   Esse comando cria um job do Cloud Scheduler que faz uma chamada HTTP para a API Cloud Run Admin, definindo as instâncias de dimensionamento manual como zero. Isso desativa o serviço, mas não os jobs do Cloud Scheduler, que continuam sendo executados e redefinindo (e reativando) o serviço para 10 instâncias conforme programado.