企业官网建设流程全解析

• 云原生
• 运维
• 可观测性

导读

本文以 Litmus 官方 FAQ 文档（mkdocs/docs/experiments/faq/experiments.md）为骨架，系统梳理 Kubernetes 混沌实验落地过程中最常见、也最容易踩坑的 36 个问题：从 pod 级网络故障（丢包、损坏、延迟）的注入机制与内部实现，到目标 Pod/节点的精准圈定方式，再到实验的权限作用域、执行模型、启停恢复与结果解读。读完本文，你将能够理解 Litmus 各类实验的适用场景与底层原理，学会用 kubectl 与 Kube API 编程式地编排、控制混沌实验，并正确解读 ChaosEngine 与 ChaosResult 给出的结果证据。

一、网络类实验：机制、区别与内部实现

网络故障注入是 Litmus 最常用的混沌类型，FAQ 围绕它的提问也最多。这一节集中回答其底层机制与选型问题。

1.1 Node memory hog：为什么 Pod 会先于 kubelet 感知到压力就被 OOM Kill

FAQ 的第一个问题解释了node-memory-hog实验的一个常见现象：目标 Pod 在 kubelet 尚未感知到内存压力时就先发生了 OOM Killed。

原因是该实验按节点总内存容量的一定百分比来消耗内存，helper pod 运行在目标节点上来制造资源压力。因此实验的内存消耗存在硬性上限——永远不会超过该节点可用的总内存，不会把节点内存“吃穿”。但正因为压力被直接施加在节点层面，目标容器（尤其是设置了 limits 的容器）会先触发自身的 OOMKill 机制，把压力“消化”在自己身上，而不是等到 kubelet 的驱逐逻辑介入。这与 Kubernetes 容器内存受 limits 约束时的行为一致：超过 limits 的主进程（通常为 pid 1）会先被 OOM Kill 并由 kubelet 按重启策略拉起。

1.2 网络丢包 vs 网络损坏：是否值得两个都做

pod-network-corruption与pod-network-loss都强制制造网络丢包，FAQ 明确回答：值得，而且两者本质上是模拟“劣化网络”的两种不同方式。二者通常都会引发 TCP 层面的重传（retransmissions），劣化的程度取决于丢包/损坏的百分比（对应NETWORK_PACKET_LOSS_PERCENTAGE等 tunable）。在定时（scheduled）混沌测试中同时覆盖两者，可以更完整地评估应用在不同类型网络劣化下的表现。

1.3 网络丢包与损坏的内部实现：tc netem

FAQ 指出，实验造成的网络劣化不会让 Pod 被 kube-proxy 标记为不健康/不值得转发流量（除非你配置了基于延迟指标的 liveness probe，从而主动重启/崩溃容器）。这保证了混沌注入期间流量仍会流向目标 Pod，从而真实暴露应用在劣化网络下的行为。

从实验文档可以确认其底层实现：实验通过在被测容器内启动一个 traffic control（tc）进程并施加 netem 规则来增加 egress 丢包。换句话说，传入tc netem命令的参数会根据网络故障类型（loss/corruption/latency/duplication 等）而变化——不同实验在 target container 上运行的 netem 参数集是不同的。注入所用镜像可通过LIB_IMAGE指定（默认litmuschaos/go-runner:latest），而使用 Pumba 库时流量控制镜像由TC_IMAGE指定（默认gaiadocker/iproute2）。

FAQ 同时给出了这类实验的典型用途与缓解思路：

• 模拟pod-network 内部故障，或跨可用区/跨区域微服务通信问题；
• 缓解手段通常是让中间件基于 SLO/性能参数切换流量（把访问延迟控制在低水平）；如果没有这类机制，次优选择是确保劣化能被通知/告警系统捕获，让 SRE 有机会介入排查；
• 另一个价值在于评估劣化对端到端用户体验（应用栈末端）的实际影响——这种劣化是可接受的，还是足以把系统破坏到不可接受的程度。

1.4 网络实验的典型探针

FAQ 对“网络实验通常使用哪些探针”的回答与 1.3 节本质一致：探针的作用正是验证实验目的本身——制造网络劣化但又不让 Pod 被 kube-proxy 标记为不健康（除非 liveness probe 主动重启容器）。因此典型的做法是使用持续访问目标服务的httpProbe（连续 curl），在注入前后持续观测访问延迟与成功率，进而量化劣化对下游/依赖微服务的影响。关于探针的完整配置方式，可参考 Litmus 探针概念文档。

二、资源压测实验：exec 与非 exec 两种执行模式

FAQ 解释了pod-memory/cpu-hog与pod-memory/cpu-hog-exec的区别，这是理解 Litmus 资源类实验演进的钥匙。

• exec 模式（-exec系列，至 1.13.7 版本）：通过kubectl exec进入目标容器，在其中启动md5sum（CPU）、dd（内存/IO）等进程来消耗资源。注入与终止命令通过 ChaosEngine 中的CHAOS_INJECT_COMMAND与CHAOS_KILL_COMMAND提供。对应实验文档见 pod-memory-hog-exec。

• exec 模式的两个固有局限：注入/终止命令高度依赖目标容器的基础镜像（同一命令未必通用于所有镜像，可能需要手工推导）；对不暴露 shell 的 scratch 镜像则完全无法执行。

• 非 exec 模式（1.13.8 起增强的 stress-chaos 实验）：pod-cpu-hog、pod-memory-hog、pod-io-stress等改为不 exec 的方式注入，利用目标容器的 cgroup 做资源分配，并通过容器 pid namespace 让 stress-ng 进程“看起来”就在目标容器内。stress-ng 进程不经过 exec 也能在目标容器中消耗资源，从而绕开了基础镜像差异问题。

三、混沌库选择：litmus、pumba 与 BYOC

FAQ 明确指出：Litmus 为 stress-chaos、network-chaos 等实验提供多个库，优先推荐litmus库（也是默认值）。可选的pumba库更多是展示如何用第三方工具与 Litmus 配合，即BYOC（Bring Your Own Chaos，自带混沌）思路的体现。

在 pod-network-loss 实验文档中可以看到通过LIBtunable 切换 pumba 库的完整示例：

apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: engine-nginx spec: engineState: "active" annotationCheck: "false" appinfo: appns: "default" applabel: "app=nginx" appkind: "deployment" chaosServiceAccount: pod-network-loss-sa experiments: - name: pod-network-loss spec: components: env: # 混沌库名称：litmus / pumba - name: LIB value: 'pumba' # pumba 库专用的流量控制镜像 - name: TC_IMAGE value: 'gaiadocker/iproute2' - name: TOTAL_CHAOS_DURATION value: '60'

注意：CONTAINER_RUNTIME对 litmus 库支持docker、containerd、crio，而对 pumba 库仅支持 docker。

四、用 Kube API 编程式运行混沌实验

FAQ 给出了不依赖 ChaosCenter 界面、直接用 API 操作混沌资源的完整方案：由于 ChaosExperiment、ChaosEngine、ChaosResult 都是 CRD，Kubernetes 默认就为它们暴露了 REST API 端点。你可以用任意语言的通用客户端（Go/Python 最常用）访问；Go 场景下官方还提供了clientset（位于 chaos-operator 仓库的pkg/client/clientset/versioned/typed/litmuschaos/v1alpha1）。

以下是 FAQ 中基于kubectl proxy（也可改用 auth token）的 CRUD 操作示例，可直接复制验证。

4.1 创建 ChaosEngine

curl -s http://localhost:8001/apis/litmuschaos.io/v1alpha1/namespaces/default/chaosengines -XPOST -H 'Content-Type: application/json' -d@pod-delete-chaosengine-trigger.json

4.2 读取 ChaosEngine 状态

curl -s http://localhost:8001/apis/litmuschaos.io/v1alpha1/namespaces/default/chaosengines/nginx-chaos | jq '.status.engineStatus, .status.experiments[].verdict'

4.3 更新 ChaosEngine Spec（例如停机）

curl --header "Content-Type: application/json-patch+json" --request PATCH --data '[{"op": "replace", "path": "/spec/engineState", "value": "stop"}]' http://localhost:8001/apis/litmuschaos.io/v1alpha1/namespaces/default/chaosengines/nginx-chaos

4.4 删除 ChaosEngine 资源

curl -X DELETE localhost:8001/apis/litmuschaos.io/v1alpha1/namespaces/default/chaosengines/nginx-chaos \ -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ -H "Content-Type: application/json"

4.5 从 ChaosResult 读取实验结论

curl -s http://localhost:8001/apis/litmuschaos.io/v1alpha1/namespaces/default/chaosresults/nginx-chaos-pod-delete | jq '.status.experimentStatus.verdict, .status.experimentStatus.probeSuccessPercentage'

五、Kubernetes 已有高可用机制，为什么还需要 CPU/IO/网络混沌？

FAQ 直面了这个经典质疑：ReplicaSet/Deployment 确实能在容器被杀、Pod 被删、OOM 时保证服务可用（httpProbe 的连续 curl 不应失败），但有一类问题绕开了这些可用性机制——典型的即“Noisy Neighbour（吵闹邻居）”问题：

• 磁盘/IO 压力：对共享磁盘持续做重 I/O，会劣化其他使用同一存储的微服务的读写（现代 K8s 存储方案从存储池中划出虚拟卷，天然共享底层）；同时节点 scratch 空间被耗尽后，新容器无法被调度，Kubernetes 最终会施加disk-pressure之类的驱逐污点，导致整节点 Pod 大规模迁移。
• CPU 压力：向目标容器注入一个“流氓进程”，会**饿死主微服务进程（通常是 pid 1）**在 limits 内可用的资源，造成应用流量变慢；不加约束的滥用甚至会让节点资源耗尽、触发所有 Pod 被驱逐。

这些场景正是 CPU、IO、网络类混沌实验的存在意义——它们考验的是资源争抢与性能劣化，而非单纯的进程级故障。

六、目标圈定：如何精确选择受影响的 Pod 与节点

FAQ 专门回答了“按 label 选择却只命中一个 Pod”的常见困惑：默认确实只选一个 Pod。需要多选时，用PODS_AFFECTED_PERC（或TARGET_PODS）env。

6.1 定位 Pod 的两种方式

• Appinfo：在 ChaosEngine 的appinfo段提供目标 Pod 的 label（applabel）、命名空间（appns）与工作负载类型（appkind）；
• TARGET_PODS：以逗号分隔列出目标 Pod 名称，如pod1,pod2。若未提供，实验会基于appLabels随机选择目标 Pod。详见 Pod 实验通用 tunables。

6.2 PODS_AFFECTED_PERC 的随机性

FAQ 确认：PODS_AFFECTED_PERC会从匹配的 Pod 集合中随机选择受影响子集。细节差异很重要：

• pod-delete实验在每一轮迭代都会重新随机选择 Pod；
• 其余支持迭代的实验（如网络类）则只随机选择一次，后续迭代复用同一组 Pod。

注意该 env 的正确拼写为PODS_AFFECTED_PERC（FAQ 正文中误写为POD_AFFACTED_PERC，以实验文档为准），默认值为0（对应最少 1 个副本）。

6.3 如何查看百分比选择命中了哪些 Pod

FAQ 给出了直接的验证手段：从实验日志（experiment logs）或 ChaosResult 内部查看被选中的目标 Pod 列表。

6.4 appkind 可以是 Pod 吗？

FAQ 明确：appkind不直接支持pod，合法取值包括deployment、statefulset、replicaset、daemonset、rollout、deploymentconfig（这与 ChaosSchedule CRD schema 中appinfo.appkind的正则校验^(^$|deployment|statefulset|daemonset|deploymentconfig|rollout)$一致）。但有两种绕过方式：

• 在spec.appinfo.applabel与spec.appinfo.appns提供 label 与命名空间，将spec.appinfo.appkind留空；
• 在TARGET_PODSenv 提供 Pod 名称，将spec.appinfo置为 nil。

注意：无论哪种方式，ChaosEngine 的annotationCheck都必须设为false。

6.5 节点级混沌的目标圈定

节点实验（node-cpu-hog、node-memory-hog、node-io-stress、node-drain、node-taint、node-restart 等）使用另一组 env，详见 Node 实验通用 tunables：

• TARGET_NODE：单个目标节点名（适用于 node-drain、node-taint、node-restart、kubelet-service-kill、docker-service-kill）；
• TARGET_NODES：逗号分隔的多个目标节点名（适用于 node-cpu-hog、node-memory-hog、node-io-stress）；
• NODE_LABEL：目标节点的 label。

七、网络实验场景配置答疑

FAQ 用一个具体场景回答了配置问题：Pod A 通过 Service B 访问 Pod B，希望只在 Pod A 与 Service B 之间注入延迟，此时spec.appInfo、DESTINATION_IPS/HOSTS、TARGET_PODS各填什么？

• spec.appInfo：填入Pod A的命名空间（appns）与标签（applabel），实验会据此选中 Pod A（并按PODS_AFFECTED_PERC在[1:total_replicas]范围内随机挑选）；若要精确指定，则在TARGET_PODS中填写 Pod A 的名称（逗号分隔列表）；
• DESTINATION_IPS/DESTINATION_HOSTS：填入Service B的细节（其 IP 或 FQDN，如nginx.default.svc.cluster.local）；
• NETWORK_INTERFACE：应设为eth0。

7.1 如何检查 NETWORK_INTERFACE 与 SOCKET_PATH

NETWORK_INTERFACE是 Pod/容器内需要被限速的网卡名。exec 进目标 Pod 后查看可用网卡即可确认，根据 Pod 内安装的工具可尝试ip link、iwconfig、ifconfig之一。

SOCKET_PATH默认取 containerd socket 路径（/run/containerd/containerd.sock）；若集群使用 docker、crio 或其他 socket 路径，需要显式指定——它是实验与集群容器运行时通信所必需的。配套地，CONTAINER_RUNTIMEenv 需设置为实际的运行时，支持docker、containerd、crio。需要指出的是，不同文档中CONTAINER_RUNTIME的默认值表述有差异（pod-network-loss 文档 tunables 表默认 containerd、运行时示例节默认 docker），实际配置时以你的集群运行时为准显式指定最稳妥。

7.2 网络实验核心 tunables 速查

结合 pod-network-loss 实验文档 的 tunables 表，以下是网络类实验可调的关键参数：

完整可复制的 YAML 示例（丢包、指定 IP/Host、端口黑白名单、网卡、运行时 socket、pumba 库等）均可在 pod-network-loss 实验文档 中找到。

八、时间、度量与恢复能力评估

8.1 提取混沌开始与结束时间

FAQ 推荐使用Chaos exporter 指标来获取混沌的起止时间；同时这些事件也可以连同时间戳在ChaosEngine 的事件中可视化。

8.2 如何评估应用的 MTTR（平均恢复时间）

MTTR 可以通过 ChaosEngine 中的statusCheck Timeout来验证——它定义了应用状态检查的超时上界。默认值为180 秒，可在 ChaosEngine 中覆盖。具体字段为.spec.experiments[].spec.components.statusCheckTimeouts，包含delay与timeout两个值（默认delay: 2s、timeout: 180s），其语义、类型与示例见 ChaosEngine 实验组件规范：

experiments: - name: pod-delete spec: components: statusCheckTimeouts: delay: 2 timeout: 180

8.3 Ramp Time 与 Chaos Interval 的区别

• Ramp Time（RAMP_TIME）：混沌注入前与后各自等待的时长（秒），用于让系统进入稳定状态或观察恢复；
• Chaos Interval（CHAOS_INTERVAL）：相邻两次混沌迭代之间的间隔（秒）。

两者的作用对象完全不同：一个面向注入的“前后缓冲”，一个面向“迭代节奏”。

8.4 混沌指标与使用数据

• 混沌指标：Litmus 提供一组基础 Prometheus 指标，可在monitor pod上查询，包括混沌实验总数、通过/失败数以及 ChaosEngine 中每个实验的独立状态；
• 使用统计：默认会采集 chaos-operator 的安装次数与单个实验的运行次数（用于评估用户采纳度与混沌趋势）。如需关闭，在 chaos-operator deployment 上设置：

env: - name: ANALYTICS value: 'FALSE'

九、权限、作用域与实验资源

9.1 运行混沌实验需要哪些权限

默认情况下，Litmus operator 使用绑定了 ClusterRole 的litmusserviceaccount 来跨命名空间 watch ChaosEngine 资源；而实验本身则绑定到开发者创建的chaosServiceAccount，它只携带执行该实验所需的最小权限。以pod-network-loss为例，其最小 RBAC 在实验文档中给出了完整 ServiceAccount + Role + RoleBinding 示例，覆盖 pods（增删改查、exec）、events、configmaps、pods/log、工作负载（deployments/statefulsets/replicasets/daemonsets/rollouts/deploymentconfigs/replicationcontrollers）、jobs 以及 litmuschaos.io 三件套（chaosengines/chaosexperiments/chaosresults）。若实验通过 chaos-center 的 litmus workflow 调度执行，则通常复用预装的 litmus-admin RBAC。

9.2 spec.definition.scope 与 permissions 的作用

FAQ 明确指出：ChaosExperiment 中的spec.definition.scope与.spec.definition.permissions主要起说明/展示作用——供外部工具识别并校验运行该实验所需的权限。它本身不决定实验能在何处、以何种方式运行；如有需要（连同 CRD 校验一起）可以移除这些字段后保存 manifest。

从作用域规范文档看，scope取值为Namespaced或Cluster（pod 级实验通常为 Namespaced，集群级影响的实验为 Cluster）；permissions用于声明运行实验所需的最小权限，并帮助评估实验的爆炸半径（blast radius）。

9.3 混沌资源的作用域与命名空间约束

混沌 CR（ChaosExperiment、ChaosEngine、ChaosResult）本身是命名空间级资源，且应安装在目标应用所在的同一命名空间。FAQ 特别确认：ChaosEngine 与 ChaosExperiment 必须共存于同一命名空间（通常即被测应用 AUT 的命名空间）。

绝大多数实验可用映射到命名空间级 Role 的 serviceaccount 执行；但部分基础设施级（infra）实验会对跨命名空间的应用做健康检查，因此需要将 serviceaccount 映射到 ClusterRole。

9.4 Litmus 支持哪些类型的混沌实验

FAQ 将 Kubernetes 混沌实验分为两大类：

• 应用级 / Pod 级实验：如 pod-delete、container-kill、pod-cpu-hog、pod-network-loss 等；
• 平台级 / 基础设施级实验：如 node-drain、disk-loss、node-cpu-hog 等——这类实验的爆炸半径更大，通常影响集群上部署的多个应用。

Litmus 还按应用类型对实验分类，相应实验会携带应用特定的健康检查。当前仓库中的完整实验分类目录见 mkdocs/docs/experiments/categories（pods、nodes、aws、azure、gcp、spring-boot、load 等子目录），全部实验清单可通过 ChaosHub 查询。

十、实验执行模型：三个标准 Pod

FAQ 解释了 ChaosEngine 创建后的标准工作流：

1. 启动chaos-runnerPod——它是 ChaosEngine 中列出的多个实验的“伞式执行器”；
2. chaos-runner 为**每个实验创建一个 Pod（Job）**运行实验业务逻辑，并管理这些实验 Pod 的生命周期（实验依赖校验、Job 清理、把状态回写进 ChaosEngine 等）；
3. 可选地创建monitor Pod用于导出混沌指标。

这三者构成一次实验执行的标准 Pod 集合。此外，实验 Job 视所选实验与混沌库的不同，还可能派生出从属的helper资源（例如 node 级实验的 helper pod）。

十一、实验运行控制：注解、启停、恢复与日志

11.1 是否必须给应用标注 chaos 注解

应用通常应标注litmuschaos.io/chaos="true"以“允许”被混沌选中。这有助于在命名空间中区分标签相近的应用，隔离被测应用（AUT）并缩小爆炸半径，也便于通过 cron 等做自动化执行。但在以下场景可以关闭该检查：应用部署规格不容修改；或实验本身爆炸半径大、标注单个应用没有意义（如 infra 混沌）。关闭方式即 ChaosEngine 的.spec.annotationCheck: false。

11.2 自定义注解作为混沌过滤器

Litmus 支持自定义注解 key 作为过滤器（value 为 true/false）。做法是在ChaosOperator Deployment中添加名为CUSTOM_ANNOTATION的环境变量。FAQ 给出的参考 manifest 如下：

apiVersion: apps/v1 kind: Deployment metadata: name: chaos-operator-ce namespace: litmus spec: replicas: 1 selector: matchLabels: name: chaos-operator template: metadata: labels: name: chaos-operator spec: serviceAccountName: litmus containers: - name: chaos-operator # 'latest' tag 对应最新发布的镜像 image: litmuschaos/chaos-operator:latest command: - chaos-operator imagePullPolicy: Always env: - name: CUSTOM_ANNOTATION value: "mayadata.io/chaos" - name: CHAOS_RUNNER_IMAGE value: "litmuschaos/chaos-runner:latest" - name: WATCH_NAMESPACE value: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: OPERATOR_NAME value: "chaos-operator"

11.3 停止/中止正在运行的实验

将 ChaosEngine 的.spec.engineState置为stop即可中止运行中的实验，并一次性删除与该 engine/experiment 关联的所有混沌资源；删除 ChaosEngine 资源本身也有同样效果：

kubectl patch chaosengine <chaosengine-name> -n <namespace> --type merge --patch '{"spec":{"engineState":"stop"}}'

关于engineState的取值语义（active/stop）与engineStatus状态回写机制，参见 ChaosEngine 状态规范。

11.4 停止后能否恢复

可以。把engineState重新置为active会让实验重新执行；另一种方式是重新 apply ChaosEngine YAML，这会删除所有陈旧混沌资源并重启 engine 生命周期。但注意：保存中间状态并从断点恢复（执行剩余迭代）目前尚不支持：

kubectl patch chaosengine <chaosengine-name> -n <namespace> --type merge --patch '{"spec":{"engineState":"active"}}'

11.5 优雅完成后如何重启 ChaosEngine

先查看.spec.engineState：若为stop，说明 engine 已优雅完成或被强制中止。此时重新 apply ChaosEngine YAML 即可重启——它会清除与该 engine 关联的所有陈旧混沌资源并重启其生命周期。

11.6 混沌期间的事件生成

chaos-operator 会生成 Kubernetes 事件来标识混沌资源在实验过程中的创建/移除，可通过以下命令查看：

kubectl describe chaosengine <chaosengine-name> -n <namespace>

FAQ 同时注明：后续版本仍在推进围绕混沌注入本身生成更多事件。

11.7 如何获取混沌日志

FAQ 给出了三个层级的日志入口：

# chaos-operator 日志：查看 engine 创建时混沌资源的成功启动/移除、AUT 识别等 kubectl logs -f <chaos-operator-(hash)-(hash)> -n <chaos_namespace> # chaos-runner 日志：查看单个/一组混沌实验的生命周期管理 kubectl logs -f <chaosengine_name>-runner -n <chaos_namespace> # experiment pod 日志：查看混沌注入细节与应用健康检查等 kubectl logs -f <experiment_name_(hash)_(hash)> -n <chaos_namespace>

十二、结果解读与快速上手

12.1 如何查看并解读实验结果

实验结论取自ChaosResult 自定义资源的verdict属性：

• Pass：被测应用对注入的混沌具有韧性；
• Fail：应用韧性不足，提示需要重新审视部署合理性或排查应用缺陷/问题。

kubectl describe chaosresult <chaosengine-name>-<chaos-experiment> -n <namespace>

实验状态还可以通过ChaosEngine 的status属性查看：

kubectl describe chaosengine <chaosengine-name> -n <namespace>

12.2 如何快速开始运行第一个实验

Litmus 的入门门槛很低，典型流程为：安装 chaos-operator → 从 ChaosHub 安装混沌实验 CR → 给应用打上 chaos 注解 → 创建 ChaosEngine CR 将应用实例与目标实验关联。仓库根目录的 SETUP.md 与 mkdocs/docs/experiments/faq/install.md 提供了更完整的安装与起步指引，mkdocs/docs/experiments/faq/ci-cd.md 则覆盖了 CI/CD 集成场景。

附：minChaosInterval 与 instanceCount 如何选择

FAQ 的最后一条问答澄清了 ChaosSchedule 调度参数的关系：minChaosInterval与instanceCount理想情况下只应二选一；若同时指定，minChaosInterval优先。

• minChaosInterval：两个 ChaosEngine 启动之间的最小间隔；
• instanceCount：在（开始与结束）时间范围内要启动的 ChaosEngine 精确数量。

从 ChaosScheduler FAQ 可知，repeat型调度需要配置startTime、endTime、minChaosInterval、includedHours、includedDays，其行为类似功能更强的 cronjob（可控制起止时间）。时间间隔按"2m"、"10m"、"2h"这类格式书写（对应分钟/小时）。在 ChaosSchedule CRD 定义 中，minChaosInterval被建模为hour（everyNthHour/minuteOfTheHour）或minute（everyNthMinute）二选一的结构（minProperties: 1、maxProperties: 1校验），并可与random: true搭配实现随机间隔。具体选哪种取决于需求：需要“密度受控的固定次数”选instanceCount，需要“稳定的最小间隔节奏”则选minChaosInterval。

总结

这份 FAQ 覆盖了 Litmus 混沌实验从机制原理（tc netem、cgroup 非 exec 注入、OOM 边界）到实战配置（目标圈定、网络 tunables、RBAC、作用域）再到运维控制（启停恢复、日志事件、指标度量、结果解读）的完整闭环。无论你是刚接触 Litmus 的 SRE，还是已经在生产集群上编排混沌流水线的开发者，都可以把本文作为实验设计与问题排查的速查手册——每个结论都能在 experiments FAQ 及对应的实验/概念文档中找到出处，并在你自己的集群上用 kubectl 直接验证。

• 云原生
• 运维
• 可观测性