共享代码多平台部署：如何在App Engine/K8s使用gcloud runtime config？

Great question! I’ve handled this exact scenario before, and there are reliable ways to pull values from Google Cloud Runtime Config into both App Engine and Kubernetes—avoiding the hassle of duplicating environment variables across multiple config files. Here’s how to do it for each platform:

App Engine #

You have two main approaches here, depending on whether you want values injected at deploy time or fetched dynamically at runtime:

1. Inject Variables at Deploy Time #

Use the gcloud CLI to pull Runtime Config values and pass them as environment variables during deployment. This way, you don’t need to hardcode anything in app.yaml:

gcloud app deploy \
  --set-env-vars API_KEY=$(gcloud runtime-config configs variables get-value api-key --config-name my-app-config) \
  --set-env-vars ANOTHER_KEY=$(gcloud runtime-config configs variables get-value another-key --config-name my-app-config)

This pulls the latest values from your Runtime Config every time you deploy, keeping your app.yaml clean and in sync with your centralized config.

2. Fetch Values Dynamically at Runtime #

If you need to grab config values while your app is running (e.g., for dynamic updates without redeploying), use the Google Cloud Runtime Config Client Library. Here’s a quick Node.js example (since you’re using Firebase Functions, this will feel familiar):

const { RuntimeConfigServiceClient } = require('@google-cloud/runtime-config');

const client = new RuntimeConfigServiceClient();
const CONFIG_NAME = 'my-app-config';
const PROJECT_ID = process.env.GOOGLE_CLOUD_PROJECT;

async function getRuntimeConfigVar(varName) {
  const variablePath = `projects/${PROJECT_ID}/configs/${CONFIG_NAME}/variables/${varName}`;
  const [variable] = await client.getVariable({ name: variablePath });
  return variable.text; // For binary values, use variable.value instead
}

// Usage in your app
const apiKey = await getRuntimeConfigVar('api-key');

Important: Make sure your App Engine service account has the roles/runtimeconfig.configViewer IAM role to access the Runtime Config resources.

Kubernetes #

Kubernetes offers a few flexible options to integrate with Runtime Config, depending on your workflow:

1. Sync to ConfigMaps/Secrets (Deploy Time) #

Pull values from Runtime Config and populate Kubernetes ConfigMaps or Secrets before deploying your workload. This is straightforward for most use cases:

# Pull values from Runtime Config
API_KEY=$(gcloud runtime-config configs variables get-value api-key --config-name my-app-config)
DB_PASSWORD=$(gcloud runtime-config configs variables get-value db-password --config-name my-app-config)

# Create a ConfigMap for non-sensitive values
kubectl create configmap app-config \
  --from-literal=api-key=$API_KEY

# Create a Secret for sensitive values
kubectl create secret generic app-secrets \
  --from-literal=db-password=$DB_PASSWORD

Then reference these in your Deployment manifest:

spec:
  containers:
  - name: my-app
    env:
      # From ConfigMap
      - name: API_KEY
        valueFrom:
          configMapKeyRef:
            name: app-config
            key: api-key
      # From Secret
      - name: DB_PASSWORD
        valueFrom:
          secretKeyRef:
            name: app-secrets
            key: db-password

2. Dynamic Runtime Fetch (Similar to Firebase Functions) #

Just like App Engine, you can use the Google Cloud Client Library to fetch Runtime Config values directly in your app code. This works well if you need to refresh configs without redeploying pods.

Ensure your Kubernetes service account (the one your pods run as) has the roles/runtimeconfig.configViewer role assigned. You can bind this role using:

kubectl create rolebinding runtime-config-viewer \
  --clusterrole=roles/runtimeconfig.configViewer \
  --serviceaccount=default:default \
  --namespace=your-namespace

3. Automated Sync with Config Connector #

For more advanced setups (e.g., automatic sync when Runtime Config values change), use the Google Cloud Config Connector. This lets you define Runtime Config variables as Kubernetes resources, which are kept in sync automatically. It’s a bit heavier, but ideal for teams managing multiple K8s clusters or needing strict config consistency.

Best Practices #

• Separate Environments: Use distinct Runtime Config names for dev, staging, and production (e.g., my-app-config-dev, my-app-config-prod) to avoid cross-environment mix-ups.
• Sensitive Data: Store secrets in Runtime Config with encryption, and use Kubernetes Secrets (not ConfigMaps) for sensitive values in K8s to keep them secure.
• IAM Restrictions: Limit access to your Runtime Configs by assigning the minimal necessary IAM roles (only configViewer for most apps) to reduce attack surface.

内容的提问来源于stack exchange，提问作者Thijs Koerselman