Dapr故障（Sidecar/控制平面）时应用行为及模拟方法咨询

一、故障时的预期行为 #

1. Sidecar故障（daprd进程崩溃/不可达） #

• 直接调用Dapr API的逻辑：应用向Sidecar默认端口（3500）发起的请求会失败，常见错误包括连接超时、连接被拒绝。如果应用未做降级处理，这部分依赖Dapr的非关键逻辑会失效，但不涉及Dapr的核心业务流程可正常运行。
• 使用Dapr SDK的场景：默认情况下SDK调用会抛出异常，部分SDK支持配置重试或超时，但如果Sidecar完全不可用，最终仍会失败，需应用层自行处理异常并降级。

2. Control Plane故障（operator/placement/sentry等组件失效） #

• 已运行的Sidecar实例：不受影响，Sidecar会缓存已获取的配置（组件元数据、服务发现条目等），缓存过期前，服务调用、状态操作等依赖Dapr的逻辑可正常执行。仅当需要刷新配置、注册新服务或启用新组件时，才会出现失败。
• 新启动的Sidecar实例：无法从Control Plane拉取配置，会启动失败或进入等待状态，导致新服务实例无法使用Dapr能力，但已运行的服务不受影响。

二、故障场景模拟方法 #

模拟Sidecar故障 #

• 杀死Sidecar进程：
  • K8s环境：进入应用Pod执行kubectl exec <pod-name> -- pkill daprd，直接终止Sidecar进程；若需彻底销毁，可删除Pod（kubectl delete pod <pod-name>），但会连带重启应用容器。
  • 自托管模式：执行pkill daprd关闭本地Sidecar进程，或直接关闭Dapr运行的终端窗口。
• 网络隔离：
  • 本地环境：用iptables -A INPUT -p tcp --dport 3500 -j DROP阻断应用到Sidecar的端口（测试后用iptables -D INPUT -p tcp --dport 3500 -j DROP恢复）。
  • K8s环境：创建NetworkPolicy规则，禁止应用Pod内的容器与Sidecar容器通信。

模拟Control Plane故障 #

• 停止Control Plane组件：
  • K8s环境：删除Control Plane的Deployment资源，命令示例：kubectl delete deployment dapr-operator dapr-placement dapr-sentry dapr-sidecar-injector。
  • 自托管模式：停止所有Dapr系统服务的进程，比如终止dapr-operator、dapr-placement等进程。
• 网络阻断：
  • K8s环境：创建NetworkPolicy规则，禁止Sidecar Pod访问Control Plane组件的服务端口。

三、非关键场景下的高可用适配建议 #

如果你的服务在非关键场景使用Dapr，希望故障时仍能正常运行，可参考以下方案：

• 为Dapr调用添加降级逻辑：捕获Sidecar调用失败的异常，返回默认值或执行备选逻辑（比如跳过非关键的消息通知、使用本地缓存替代Dapr状态存储）。
• 配置SDK超时与重试：合理设置超时时间（避免请求长时间阻塞），限制重试次数（防止加剧系统负载）。
• 接口隔离Dapr依赖：将Dapr相关逻辑封装为独立模块，通过抽象接口调用，当Dapr故障时切换到本地实现类。
• 本地缓存非关键数据：对于非核心状态数据，在应用本地缓存一份，Dapr不可用时直接使用本地数据。

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