Chaos Mesh 容器运行时配置问题排查与解决方案

在 Kubernetes 集群中使用 Chaos Mesh 进行混沌工程测试时，容器运行时配置是一个常见的问题来源。本文将通过一个典型案例，深入分析当 Chaos Mesh 的 chaos-daemon 组件错误使用 Docker 运行时（实际环境为 containerd）时的故障现象、排查思路和解决方案。

问题现象

用户在使用 Chaos Mesh 2.6.3 版本时遇到网络混沌实验（networkchaos）失败的情况，错误信息显示为"expected docker://..."。尽管集群节点实际使用的是 containerd 运行时（版本为 1.7.11-k3s2），且已通过 Helm 参数显式指定了 containerd 运行时配置，但 chaos-daemon 仍然尝试使用 Docker 运行时。

具体表现为：

1. 通过 ps 命令检查 chaos-daemon 进程，发现其运行时参数仍为 --runtime docker
2. 网络混沌实验无法正确注入，出现"unable to flush ip sets"等错误
3. 即使重新安装 Chaos Mesh，运行时配置似乎仍然"残留"

根本原因分析

经过深入排查，这个问题主要由以下几个因素共同导致：

1. Helm 值持久化问题：即使卸载后重新安装，某些 Helm 值可能被保留或缓存，导致运行时配置未按预期更新。

2. 容器运行时检测机制：Chaos Mesh 在某些情况下可能自动检测容器运行时，如果检测逻辑与预期不符，可能导致配置覆盖。

3. 内核模块依赖：网络混沌实验依赖 sch_netem 内核模块，虽然用户确认已安装，但模块加载状态或版本兼容性可能影响实验执行。

4. cgroup 命名空间问题：当 chaos-daemon 使用错误的运行时配置时，其进程的 cgroup 命名空间可能出现异常（如空组件），导致资源访问权限问题。

解决方案

1. 彻底清理 Helm 安装

在执行重新安装前，需要确保完全清理之前的安装：

helm uninstall chaos-mesh -n chaos-mesh
kubectl delete ns chaos-mesh
# 清理可能残留的CRD
kubectl delete crd $(kubectl get crd | grep "chaos-mesh.org" | awk '{print $1}')

2. 明确指定运行时参数

对于 containerd 环境，安装时必须明确指定运行时参数：

helm install chaos-mesh chaos-mesh/chaos-mesh \
  -n chaos-mesh \
  --version 2.6.3 \
  --set chaosDaemon.runtime=containerd \
  --set chaosDaemon.socketPath=/run/k3s/containerd/containerd.sock

3. 验证运行时配置

安装后，应立即验证配置是否生效：

# 检查chaos-daemon的启动参数
kubectl exec -n chaos-mesh <chaos-daemon-pod> -- ps aux

# 检查Helm实际应用的values
helm get values chaos-mesh -n chaos-mesh -a

4. 内核模块预加载

确保所有节点已正确加载所需内核模块：

# 检查模块是否加载
lsmod | grep sch_netem

# 若未加载，则手动加载
modprobe sch_netem

经验总结

1. 配置验证很重要：在安装混沌工程工具前，应明确了解集群的容器运行时环境，并通过多种方式验证配置是否按预期生效。

2. 清理要彻底：Chaos Mesh 作为系统级工具，其组件可能涉及多个层次（CRD、webhook、daemonset等），卸载时需要确保完全清理。

3. 环境依赖检查：网络混沌实验依赖于特定的内核功能和模块，在问题排查时应将其纳入考虑范围。

4. 版本兼容性：不同版本的 Chaos Mesh 对容器运行时的支持可能有所差异，建议查阅对应版本的官方文档确认兼容性矩阵。

通过系统性地排查和验证，最终用户成功将 chaos-daemon 切换为正确的 containerd 运行时，网络混沌实验得以正常执行。这个案例提醒我们，在复杂的云原生环境中，工具配置的精确性和环境的一致性检查至关重要。