使用Helm部署SealedSecret后Pod启动失败的求助

1. 确认SealedSecret控制器状态 #

SealedSecret需要依赖集群中的控制器解密为普通Secret，先检查控制器是否正常运行：

kubectl get pods -n kube-system | grep sealed-secrets

如果控制器Pod不是Running状态，优先修复控制器（重启或重新部署），这是解密流程的核心前提。

2. 核对命名空间一致性 #

你的SealedSecret指定了namespace: api，必须确保Deployment也部署在同一个api命名空间下。如果Deployment在其他命名空间，要么调整SealedSecret的namespace，要么将Deployment迁移至api命名空间——默认控制器不会跨命名空间处理SealedSecret。

3. 定位解密失败的具体原因 #

通过以下命令查看日志，明确解密失败的根因：

# 查看SealedSecret的事件详情
kubectl describe sealedsecret {{ include "api.fullname" . }} -n api

# 查看控制器运行日志（替换为实际Pod名称）
kubectl logs -n kube-system sealed-secrets-controller-xxxxxx-xxxxx

常见失败原因：

• 加密Secret时使用的公钥与当前控制器持有的私钥不匹配（比如控制器重新部署后密钥丢失）
• SealedSecret中的加密数据格式错误
• 控制器无权限在api命名空间创建Secret

4. 验证配置中的名称匹配 #

确保Deployment引用的Secret名称与SealedSecret的名称完全一致，可通过Helm模板渲染验证：

helm template <你的Chart名称> --set encryptedData.test=demo | grep -A3 -B3 secretKeyRef

确认渲染后的secretKeyRef.name和SealedSecret的metadata.name完全相同，避免模板渲染差异导致名称不匹配。

5. 触发重新解密流程 #

如果控制器正常但未自动处理SealedSecret，可删除现有SealedSecret后重新部署，强制控制器重新处理：

kubectl delete sealedsecret {{ include "api.fullname" . }} -n api
helm upgrade --install <你的Release名称> <Chart路径> -n api

6. 重新生成匹配密钥的SealedSecret #

若为密钥不匹配问题，需用当前控制器的公钥重新加密原始Secret：

1. 获取控制器公钥：

kubeseal --fetch-cert --controller-namespace kube-system --controller-name sealed-secrets-controller > pub-cert.pem

2. 用新公钥加密Secret（替换为实际密钥键值对）：

kubectl create secret generic {{ include "api.fullname" . }} --dry-run=client -o yaml -n api --from-literal=key1=value1 | kubeseal --cert pub-cert.pem -o yaml > new-sealed-secret.yaml

将新生成的SealedSecret内容替换至Helm Chart配置中，重新部署即可。

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