如何让Cloud Run实例始终保持1个运行？及设置min instance=1、max instance=1后实例计数指标异常问题咨询

Hey there, let's break down your Cloud Run questions step by step—super common scenarios, so I've got you covered!

To ensure exactly one Cloud Run instance stays up continuously, follow these steps:

• Set minimum and maximum instances to 1: This is the core configuration. It locks your service to a single instance, with Cloud Run maintaining at least one pre-warmed instance at all times.
  • Via Console: Go to your Cloud Run service > Edit & deploy new revision > Under "Autoscaling", set "Minimum number of instances" and "Maximum number of instances" both to 1.
  • Via gcloud CLI: Run this command (replace placeholders with your details):

    gcloud run services update YOUR_SERVICE_NAME --min-instances=1 --max-instances=1 --region YOUR_REGION
    

• Optional: Disable CPU throttling (for continuous background tasks): By default, Cloud Run throttles CPU usage when there are no incoming requests (the instance stays alive but uses almost no CPU). If you need the instance to run non-stop (e.g., for cron jobs or background processing), disable this:
  • Add --cpu-throttling=false to the gcloud command above, or toggle the "CPU always allocated" option in the console.
• Confirm regional support: Most Cloud Run regions support minimum instances, but double-check your target region allows this setting (you'll see the option in the console if it's supported).

If you’ve locked min/max instances to 1 but see weird fluctuations (like temporary 0 instances or 2 instances at once), here are the most likely causes and fixes:

• Instance replacement/restarts: Cloud Run automatically restarts instances periodically for OS updates, security patches, or resource rebalancing. It spins up a new instance before terminating the old one, so metrics might briefly show 2 instances. This is normal behavior.
  • Fix: Check your service logs in Cloud Logging for entries like "Instance terminated" or "New instance started" to confirm. No action needed unless restarts happen excessively.
• Health check failures: If your service’s readiness/liveness probes fail (e.g., the endpoint returns a non-200 status), Cloud Run will kill the unhealthy instance and launch a new one. This can cause temporary dips to 0 (while the new instance boots) or spikes to 2.
  • Fix: Verify your health check paths return a 200 OK response, adjust timeout/liveness thresholds to match your service’s startup time, and check logs for probe failure messages.
• Metrics latency: Cloud Monitoring metrics can have a 1-5 minute delay. What you’re seeing might be a stale view of the instance state.
  • Fix: Wait a few minutes and refresh the metrics dashboard, or switch to a finer time granularity (e.g., 1-minute intervals) to see real-time trends.
  • Fix: Confirm the configuration is active with this gcloud command:

    gcloud run services describe YOUR_SERVICE_NAME --region YOUR_REGION
    

    Look for the autoscaling section to ensure minInstanceCount and maxInstanceCount are both set to 1.
• Resource limits hit: If your instance uses more memory/CPU than its allocated limits, it might be terminated abruptly (OOM kills), triggering a restart.
  • Fix: Check logs for "Out of memory" errors, and adjust your service’s memory/CPU allocation if needed.

内容的提问来源于stack exchange，提问作者Alex Chang