Dapr Sidecar 注入器在测试集群报 “bad certificate“ 错误怎么恢复？-育师

Dapr Sidecar 注入器在测试集群报 "bad certificate" 错误怎么恢复？

【免费下载链接】daprDapr is a portable runtime for building distributed applications across cloud and edge, combining event-driven architecture with workflow orchestration.项目地址: https://gitcode.com/GitHub_Trending/da/dapr

在 Dapr 的 Kubernetes 测试集群（minikube 或自建的 E2E 测试环境）里跑端到端测试时，如果你曾经“直接删掉测试命名空间、再重装 Dapr 控制面”，sidecar 注入器（sidecar injector）就会失效，报出bad certificate错误。这篇文章讲清楚这个错误的触发条件，以及怎么用文档给出的命令把它恢复到可用状态。

适用前提：你在本地按 Dapr 的 E2E 测试流程部署过控制面（sentry、injector、daprd 等），并准备在当前集群上重新构建、部署和运行 E2E 测试。恢复过程从 Dapr 源码仓库的工作目录执行，命令连接的是当前 kubeconfig 指向的测试集群。

什么情况下会出现 "bad certificate"

文档给出的成因是一条明确的顺序问题：

在删除 dapr 测试命名空间之前，必须先执行helm uninstall。如果你在没有执行helm uninstall的情况下直接删掉 dapr 测试命名空间，随后又重新安装了 dapr 控制面，dapr sidecar 注入器将无法工作并报bad certificate。

换句话说，这个错误通常出现在下面这条操作链上：

直接make delete-test-namespace（或kubectl delete namespace）删掉了测试命名空间；
但没有先跑helm uninstall卸载 Dapr 控制面；
之后又重装了控制面。

结果是命名空间里残留了旧的发布/证书状态，重装后的 sidecar 注入器无法正常工作。

恢复前的检查

在执行恢复命令前，先确认环境，避免删错命名空间：

当前终端能访问目标测试集群（kubectl指向正确的 context）。
环境变量DAPR_NAMESPACE已正确设置（通常是你部署 Dapr 时用的命名空间，如dapr-tests）。文档特别强调：执行卸载前务必确认DAPR_NAMESPACE已正确设置。

如果走一键恢复（见下节第 3 步make e2e-build-deploy-run），还需要按 tests/docs/running-e2e-test.md “Prerequisites” 一节设置好DAPR_REGISTRY、DAPR_TAG等 E2E 测试环境变量，因为它会重新构建并推送镜像。

恢复步骤

下面这条路径来自文档 Option 1（从干净状态构建、部署并运行测试），它正是处理该问题的推荐顺序：先helm uninstall，再删命名空间，最后完整重建部署。

副作用提示：下面第 1、2 步会卸载当前命名空间下的 Dapr 及相关发布、删除测试命名空间，属于破坏性操作，执行前确认DAPR_NAMESPACE无误且集群确实是你的测试集群。

卸载 Dapr 控制面及相关发布（dapr、dapr-kafka、dapr-redis、dapr-postgres）：
```
helm uninstall dapr dapr-kafka dapr-redis dapr-postgres -n $DAPR_NAMESPACE
```
如果之前只部署过dapr本身，执行helm uninstall dapr -n $DAPR_NAMESPACE即可。文档明确说“你可以用helm uninstall命令来恢复”。
删除测试命名空间（在helm uninstall之后）：
```
make delete-test-namespace
```
注意顺序：文档强调必须先helm uninstall再删命名空间，反过来正是导致bad certificate的操作。
从构建、部署到运行测试一步到位：
```
make e2e-build-deploy-run
```
该目标在 tests/dapr_tests.mk 中定义为：
```
e2e-build-deploy-run: init-build-deploy setup-test-components build-e2e-app-all push-e2e-app-all test-e2e-all
```
也就是重建命名空间、初始化第三方依赖、构建并推送镜像、部署控制面，然后运行 E2E 测试。如果你只想逐步执行、加快迭代，可按文档 Option 2 分别跑make create-test-namespace、make setup-helm-init、make setup-test-env-redis/setup-test-env-kafka/setup-test-env-postgres、make build-linux、make docker-build、make docker-push、make docker-deploy-k8s，最后make test-e2e-all。

验证恢复是否成功

部署阶段是第一个硬性检查点。make docker-deploy-k8s底层执行的是（见 Makefile 第 299–307 行）：

helm upgrade --install \ dapr --namespace=$(DAPR_NAMESPACE) --wait --timeout 5m0s \ --set global.tag=... --set global.registry=$(DAPR_REGISTRY) ...

其中--wait --timeout 5m0s会让helm upgrade --install阻塞，直到控制面资源就绪才继续，或在 5 分钟超时前失败。这一步正常返回，说明控制面（含 sidecar 注入器相关资源）已按新发布重新拉起。

接着e2e-build-deploy-run会进入test-e2e-all，把 E2E 测试跑起来；sidecar 注入恢复后，测试应用部署时的 sidecar 注入才会正常进行。若你只想单独验证测试，可在完成部署后运行make test-e2e-all。

避免再次踩坑

文档给出的预防规则就是顺序约束：任何要删除 dapr 测试命名空间的操作，前面都要先执行helm uninstall。文档 “Cleanup local environment” 一节给出的清理顺序正是这个原则的体现：

# Uninstall dapr, dapr-kafka, dapr-redis, dapr-postgres, then remove dapr-zipkin helm uninstall dapr -n $DAPR_NAMESPACE || true helm uninstall dapr-kafka -n $DAPR_NAMESPACE || true helm uninstall dapr-redis -n $DAPR_NAMESPACE || true helm uninstall dapr-postgres -n $DAPR_NAMESPACE || true kubectl delete deployment dapr-zipkin -n $DAPR_NAMESPACE || true # Remove the test namespace make delete-test-namespace

把helm uninstall放在make delete-test-namespace之前，就能避免重装控制面后 sidecar 注入器报bad certificate。更多完整的 E2E 部署与清理流程见 tests/docs/running-e2e-test.md。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考