如何从Pod更新Kubernetes ConfigMap？跨Pod数据存储替代PV方案咨询

首先明确：截至当前Kubernetes版本，ConfigMap仍保持只读设计，无法直接从Pod内部写入或修改其数据，你看到的2018年的Issue结论至今依然有效。以下是几个无需Persistent Volume的可行方案：

方案1：通过Kubernetes API更新ConfigMap #

虽然不能直接挂载写入，但可以在Pod内调用Kubernetes API修改ConfigMap，前提是给Pod的ServiceAccount分配对应权限。

步骤： #

1. 创建具备ConfigMap修改权限的ServiceAccount、Role和RoleBinding：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: cronjob-updater
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: configmap-editor
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "patch", "update"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cronjob-configmap-binding
subjects:
- kind: ServiceAccount
  name: cronjob-updater
roleRef:
  kind: Role
  name: configmap-editor
  apiGroup: rbac.authorization.k8s.io

2. 在CronJob的Pod模板中指定该ServiceAccount，并添加更新逻辑：

apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-processor
spec:
  schedule: "0 0 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: cronjob-updater
          containers:
          - name: processor
            image: your-image:latest
            command: ["sh", "-c"]
            args:
            - |
              # 处理记录的业务逻辑
              CURRENT_TIMESTAMP=$(date +%Y-%m-%dT%H:%M:%S)
              # 更新ConfigMap中的时间戳
              kubectl patch configmap timestamp-store -p '{"data":{"last-run":"'$CURRENT_TIMESTAMP'"}}'
          restartPolicy: OnFailure

3. 提前创建用于存储时间戳的ConfigMap：

apiVersion: v1
kind: ConfigMap
metadata:
  name: timestamp-store
data:
  last-run: "2024-01-01T00:00:00"

优缺点： #

• 优点：无需额外部署组件，复用Kubernetes原生资源
• 缺点：需配置RBAC权限，Pod内要预装kubectl或调用REST API，逻辑稍繁琐

方案2：部署轻量级键值存储（如Redis） #

部署一个单实例、无持久化的Redis作为临时数据存储，专门存放这类小体积的共享数据（比如时间戳）。

步骤： #

1. 部署无持久化的Redis：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tiny-redis
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis
  template:
    spec:
      containers:
      - name: redis
        image: redis:alpine
        ports:
        - containerPort: 6379
        command: ["redis-server", "--save", "", "--appendonly", "no"] # 禁用持久化
---
apiVersion: v1
kind: Service
metadata:
  name: redis-service
spec:
  selector:
    app: redis
  ports:
  - port: 6379

2. 在CronJob的Pod中通过Redis CLI读写时间戳：

apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-processor
spec:
  schedule: "0 0 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: processor
            image: your-image:latest
            command: ["sh", "-c"]
            args:
            - |
              # 若镜像未预装Redis CLI则安装
              apk add --no-cache redis-cli
              # 读取上次的时间戳（可选）
              LAST_TIMESTAMP=$(redis-cli -h redis-service GET last-run)
              # 处理记录的业务逻辑
              CURRENT_TIMESTAMP=$(date +%Y-%m-%dT%H:%M:%S)
              # 写入新的时间戳
              redis-cli -h redis-service SET last-run "$CURRENT_TIMESTAMP"
          restartPolicy: OnFailure

优缺点： #

• 优点：操作简单，适合存储各类小体积共享数据，无需复杂权限配置
• 缺点：需额外部署轻量级服务，若Redis Pod重启会丢失数据（但你的每日执行场景下，丢失影响极小）

方案3：利用Job的Annotation存储元数据 #

如果仅需存储简单时间戳，可在Job执行完成后，通过修改Job的Annotation记录时间戳，后续Pod查询前一天的Job即可获取该值。

示例脚本逻辑： #

# 获取当前Job的名称
JOB_NAME=$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)/$(hostname | cut -d'-' -f1-3)
CURRENT_TIMESTAMP=$(date +%Y-%m-%dT%H:%M:%S)
# 给当前Job添加时间戳注解
kubectl annotate job $JOB_NAME last-run=$CURRENT_TIMESTAMP --overwrite

后续Pod可通过以下命令获取最新时间戳：

kubectl get jobs -l cronjob=daily-processor --sort-by=.metadata.creationTimestamp -o jsonpath='{.items[-1].metadata.annotations.last-run}'

优缺点： #

• 优点：完全复用Kubernetes原生资源，无需额外组件
• 缺点：依赖Job生命周期，若Job被清理则数据丢失，仅适合短期存储

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