Kubernetes多副本部署下如何仅让Leader Pod执行数据库查询？

Got it, let's sort this out so only your leader pod runs those database queries while the other replicas stay on standby. Since you're already using the leader-elector sidecar (mako), we can leverage its built-in functionality to make this work. Here are a few practical approaches:

1. Update your app to listen for leader status (Recommended) #

The leader-elector sidecar exposes a simple HTTP endpoint that tells you if the current pod is the leader. Your db-queries container can check this endpoint to decide whether to start its database polling logic or stay idle.

• How to implement:
  • Modify your db-queries application code to periodically hit http://localhost:4040/leader (this is the default port for the leader elector sidecar).
    • If the request returns a 200 OK response: the pod is the leader—start running your database query tasks.
    • If it returns 404 Not Found: the pod is a follower—enter a standby state (e.g., sleep in a loop, or wait for the status to change).
  • Since both containers are in the same pod, they share the network namespace, so localhost will work perfectly here.

2. Use a startup script to control the main container (No code changes needed) #

If you can't modify the db-queries app code, you can wrap its startup process in a script that checks the leader status first.

• Step 1: Create a startup script
  Save this as startup.sh in your db-queries image (or mount it via a ConfigMap):

  #!/bin/bash
  # Wait a few seconds for the leader elector sidecar to initialize
  sleep 5
  
  while true; do
    # Check if we're the leader
    curl -s -o /dev/null -w "%{http_code}" http://localhost:4040/leader | grep -q 200
    if [ $? -eq 0 ]; then
      echo "This pod is the leader—starting database query service..."
      exec /path/to/your/main/app/executable # Replace with your app's actual start command
      exit 0
    else
      echo "Not the leader—waiting 30 seconds to recheck..."
      sleep 30
    fi
  done
  

• Step 2: Update your Deployment manifest
  Modify the db-queries container to use this script as its entry point:

  containers:
  - name: db-queries
    image: our-registry:5000/db-queries
    imagePullPolicy: Always
    command: ["/bin/bash", "-c"]
    args: ["/path/to/startup.sh"] # Update this to where you saved the script
    ports:
    - containerPort: 8090
    volumeMounts:
    - readOnly: true
      mountPath: /path/to/config
      name: config-files
  

  Note: When the leader status changes, the old leader's app will exit, and the script will loop back to waiting—this works smoothly with the default Always restart policy.

3. Tweak your leader-elector sidecar configuration #

Your current sidecar args are minimal—adding a few parameters can make the election more robust:

- name: mako
  image: gcr.io/google_containers/leader-elector:0.4
  imagePullPolicy: Always
  args:
  - --election=sample
  - --http=0.0.0.0:4040 # Explicitly set the listening port to avoid ambiguity
  - --namespace=default # Tie the election to your namespace to prevent cross-namespace conflicts

Also, double-check that your leader-election-test ServiceAccount has the necessary RBAC permissions to create/update the election resources (usually ConfigMaps or Endpoints). Without proper permissions, the leader election will fail entirely.

内容的提问来源于stack exchange，提问作者Sachith Muhandiram