1. Helm升级后执行Pod容器内的脚本 #

这里有两种实用思路，你可以根据是否允许Pod重启来选择：

方法一：利用Helm post-upgrade 钩子触发脚本（无需重启Pod） #

如果你的Helm升级不会触发Pod重启（比如只更新了ConfigMap、Ingress这类非Pod模板资源），可以通过Helm的post-upgrade钩子创建一个临时Job，让它借助kubectl exec直接在目标Pod里执行脚本。

举个具体的配置例子，在你的Chart的templates目录下新建post-upgrade-exec-job.yaml：

apiVersion: batch/v1
kind: Job
metadata:
  name: {{ .Release.Name }}-post-upgrade-exec
  annotations:
    "helm.sh/hook": post-upgrade
    "helm.sh/hook-weight": "10"
    "helm.sh/hook-delete-policy": hook-succeeded
spec:
  template:
    spec:
      serviceAccountName: {{ .Values.serviceAccount.name }}
      containers:
      - name: kubectl-runner
        image: bitnami/kubectl:latest
        command:
        - /bin/sh
        - -c
        - |
          # 替换成你的业务Pod标签，筛选出目标Pod
          TARGET_POD=$(kubectl get pods -l app={{ .Values.app.name }} -o jsonpath='{.items[0].metadata.name}')
          # 执行容器内的目标脚本
          kubectl exec $TARGET_POD -- /path/to/your/script.sh
      restartPolicy: OnFailure

⚠️ 注意：要给这个Job使用的ServiceAccount配置足够权限，允许它get Pod资源和exec到Pod中。

方法二：Pod滚动更新 + postStart 生命周期钩子（需要重启Pod） #

如果你的Helm升级会修改Pod模板（比如更新镜像版本、环境变量），Kubernetes会自动触发Pod滚动更新。这时直接在Pod定义中添加postStart钩子，新启动的Pod就绪后就会自动执行脚本：

containers:
- name: your-app-container
  image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
  lifecycle:
    postStart:
      exec:
        command: ["/bin/sh", "-c", "/path/to/your/init-script.sh"]

这种方法最简洁，完全依赖Kubernetes原生特性，不需要额外的钩子资源。

2. 更新ConfigMap后无需Sidecar即可触发Pod内代码执行 #

Kubernetes本身没有原生的"postPatch"触发机制，但我们可以通过将ConfigMap变化转化为Pod滚动更新，结合postStart钩子来实现你的需求，全程不需要Sidecar监控文件：

核心方案：用ConfigMap内容哈希触发Pod滚动更新 #

在Deployment的Pod模板中添加一个基于ConfigMap内容的哈希注解，当ConfigMap内容变化时，这个注解值会自动更新，Kubernetes会判定Pod模板被修改，从而触发滚动更新。新Pod启动时，通过postStart执行你需要的代码，逻辑和你提到的postStart生命周期事件完全一致。

具体配置如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-app
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    metadata:
      annotations:
        # 生成ConfigMap内容的哈希值，内容变化时注解自动更新
        configmap-hash: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}
    spec:
      containers:
      - name: your-app-container
        image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
        volumeMounts:
        - name: config-volume
          mountPath: /etc/app/config
        lifecycle:
          postStart:
            exec:
              command: ["/bin/sh", "-c", "/path/to/your/post-config-update-script.sh"]
      volumes:
      - name: config-volume
        configMap:
          name: {{ .Release.Name }}-app-config

这个方案的优势：

• 完全依赖Kubernetes和Helm原生能力，没有额外组件
• 触发逻辑和postStart对齐，符合你想要的生命周期触发思路
• 既保证Pod加载最新的ConfigMap内容，又能自动执行配置生效的脚本

如果你绝对不想触发Pod滚动更新（比如应用支持热加载，但需要执行配套脚本），那目前没有原生方法绕过Sidecar监控——因为Kubernetes不会主动通知Pod内的容器ConfigMap已更新，只能通过文件变化让应用感知，若应用本身不处理，就需要Sidecar监控并触发脚本。但从你的需求来看，滚动更新+postStart是最贴近你要求的方案。

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