无PM2时Kubernetes中Node应用实例编号获取及单Pod调度方案咨询

Great question! When moving from PM2's cluster mode to Kubernetes, replicating that instance ID functionality and ensuring only one pod runs your node-cron scheduler can be done a few different ways depending on your needs. Let's break them down:

Option 1: Use Kubernetes Downward API for Stable Instance Identifiers (StatefulSet Recommended) #

If you're using a StatefulSet, Kubernetes assigns stable, ordinal-based pod names (e.g., my-app-0, my-app-1, my-app-2). You can inject this pod name into your Node.js app via environment variables, then extract the ordinal to decide which pod runs the cron task.

Step 1: Configure the Downward API in your StatefulSet #

Add an environment variable to your pod template that pulls the pod's name:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: my-node-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-node-app
  template:
    metadata:
      labels:
        app: my-node-app
    spec:
      containers:
      - name: app-container
        image: your-node-app-image:latest
        env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name

Step 2: Check the Ordinal in Your Node.js App #

Extract the ordinal from the pod name and only start the cron scheduler on the pod with ordinal 0:

const cron = require('node-cron');
const podName = process.env.POD_NAME;

// Extract the ordinal (last part of the StatefulSet pod name)
const podOrdinal = podName.split('-').pop();

if (podOrdinal === '0') {
  console.log(`Starting cron scheduler on pod ${podName}`);
  // Example cron job that runs every minute
  cron.schedule('* * * * *', () => {
    console.log(`Scheduled task executed at ${new Date().toISOString()} by pod ${podName}`);
  });
} else {
  console.log(`Skipping cron scheduler on pod ${podName} (ordinal: ${podOrdinal})`);
}

Pros: Simple setup, no extra dependencies.
Cons: Only works reliably with StatefulSets (Deployment pod names are random, so you can't get a stable ordinal). If the 0 ordinal pod crashes, the cron task stops until that pod restarts.

Option 2: Distributed Locking (Recommended for High Availability) #

For Deployments or if you want failover support (so another pod takes over if the cron-running pod crashes), use Kubernetes-native distributed locking. The best tool for this is Lease Resources—built into Kubernetes specifically for leader election scenarios.

Step 1: Set Up RBAC Permissions #

First, grant your pod's service account permission to manage Lease resources:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: lease-manager
rules:
- apiGroups: ["coordination.k8s.io"]
  resources: ["leases"]
  verbs: ["get", "list", "create", "update", "delete"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: default
  name: lease-manager-binding
subjects:
- kind: ServiceAccount
  name: default # Use your app's service account if you have one
  namespace: default
roleRef:
  kind: Role
  name: lease-manager
  apiGroup: rbac.authorization.k8s.io

Step 2: Node.js Code to Acquire and Renew the Lock #

Use the official Kubernetes client library to handle lease management:

npm install @kubernetes/client-node node-cron

const k8s = require('@kubernetes/client-node');
const cron = require('node-cron');

// Load Kubernetes config from the pod's internal environment
const kc = new k8s.KubeConfig();
kc.loadFromDefault();
const k8sCoordApi = kc.makeApiClient(k8s.CoordinationV1Api);

const LEASE_NAME = 'node-cron-leader-lock';
const NAMESPACE = process.env.NAMESPACE || 'default';
const POD_NAME = process.env.POD_NAME;
let cronTask = null;

// Acquire or renew the lease lock
async function acquireLock() {
  try {
    const leaseSpec = {
      holderIdentity: POD_NAME,
      leaseDurationSeconds: 60, // Lock expires after 60 seconds if not renewed
      renewTime: new Date().toISOString()
    };

    // Try to get existing lease
    let existingLease;
    try {
      existingLease = await k8sCoordApi.readNamespacedLease(LEASE_NAME, NAMESPACE);
    } catch (err) {
      // Create lease if it doesn't exist
      if (err.response.statusCode === 404) {
        await k8sCoordApi.createNamespacedLease(NAMESPACE, {
          metadata: { name: LEASE_NAME },
          spec: leaseSpec
        });
        return true;
      }
      throw err;
    }

    // Take over lock if current holder is unresponsive or it's us
    const lastRenewed = new Date(existingLease.body.spec.renewTime);
    if (existingLease.body.spec.holderIdentity === POD_NAME || 
        Date.now() - lastRenewed.getTime() > 60000) {
      await k8sCoordApi.replaceNamespacedLease(LEASE_NAME, NAMESPACE, {
        metadata: {
          name: LEASE_NAME,
          resourceVersion: existingLease.body.metadata.resourceVersion
        },
        spec: leaseSpec
      });
      return true;
    }

    return false;
  } catch (err) {
    console.error(`Failed to acquire lock: ${err.message}`);
    return false;
  }
}

// Renew lock every 30 seconds to keep it active
function startLockRenewal() {
  setInterval(async () => {
    if (await acquireLock()) {
      console.log(`Renewed lock for pod ${POD_NAME}`);
    }
  }, 30000);
}

// Start or stop the cron task based on lock status
async function manageCronTask() {
  const hasLock = await acquireLock();
  
  if (hasLock && !cronTask) {
    console.log(`Acquired lock - starting cron scheduler on pod ${POD_NAME}`);
    cronTask = cron.schedule('* * * * *', () => {
      console.log(`Scheduled task executed at ${new Date().toISOString()} by pod ${POD_NAME}`);
    });
    startLockRenewal();
  } else if (!hasLock && cronTask) {
    console.log(`Lost lock - stopping cron scheduler on pod ${POD_NAME}`);
    cronTask.stop();
    cronTask = null;
  } else if (!hasLock) {
    console.log(`Waiting for lock on pod ${POD_NAME}...`);
    // Retry lock acquisition every minute
    setTimeout(manageCronTask, 60000);
  }
}

// Initialize the cron task manager
manageCronTask();

Pros: High availability—if the leader pod crashes, another pod will acquire the lock and take over the cron task. Works with both Deployments and StatefulSets.
Cons: Requires setting up RBAC and using the Kubernetes client library.

Final Recommendations #

• Use Option 1 if you're using StatefulSets and don't need failover support.
• Use Option 2 for Deployments or if you need high availability for your cron tasks.

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