云原生运维可观测性【免费下载链接】litmusLitmus helps SREs and developers practice chaos engineering in a Cloud-native way. Chaos experiments are published at the ChaosHub (https://hub.litmuschaos.io). Community notes is at https://hackmd.io/a4Zu_sH4TZGeih-xCimi3Q项目地址https://gitcode.com/gh_mirrors/li/litmus点击查看免费下载导读本文以 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 KillFAQ 的第一个问题解释了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 netemFAQ 指出实验造成的网络劣化不会让 Pod 被 kube-proxy 标记为不健康/不值得转发流量除非你配置了基于延迟指标的 liveness probe从而主动重启/崩溃容器。这保证了混沌注入期间流量仍会流向目标 Pod从而真实暴露应用在劣化网络下的行为。从实验文档可以确认其底层实现实验通过在被测容器内启动一个 traffic controltc进程并施加 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进入目标容器在其中启动md5sumCPU、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 与 BYOCFAQ 明确指出Litmus 为 stress-chaos、network-chaos 等实验提供多个库优先推荐litmus库也是默认值。可选的pumba库更多是展示如何用第三方工具与 Litmus 配合即BYOCBring 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: appnginx 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 都是 CRDKubernetes 默认就为它们暴露了 REST API 端点。你可以用任意语言的通用客户端Go/Python 最常用访问Go 场景下官方还提供了clientset位于 chaos-operator 仓库的pkg/client/clientset/versioned/typed/litmuschaos/v1alpha1。以下是 FAQ 中基于kubectl proxy也可改用 auth token的 CRUD 操作示例可直接复制验证。4.1 创建 ChaosEnginecurl -s http://localhost:8001/apis/litmuschaos.io/v1alpha1/namespaces/default/chaosengines -XPOST -H Content-Type: application/json -dpod-delete-chaosengine-trigger.json4.2 读取 ChaosEngine 状态curl -s http://localhost:8001/apis/litmuschaos.io/v1alpha1/namespaces/default/chaosengines/nginx-chaos | jq .status.engineStatus, .status.experiments[].verdict4.3 更新 ChaosEngine Spec例如停机curl --header Content-Type: application/json-patchjson --request PATCH --data [{op: replace, path: /spec/engineState, value: stop}] http://localhost:8001/apis/litmuschaos.io/v1alpha1/namespaces/default/chaosengines/nginx-chaos4.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/json4.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_PODSenv。6.1 定位 Pod 的两种方式Appinfo在 ChaosEngine 的appinfo段提供目标 Pod 的 labelapplabel、命名空间appns与工作负载类型appkindTARGET_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_PERCFAQ 正文中误写为POD_AFFACTED_PERC以实验文档为准默认值为0对应最少 1 个副本。6.3 如何查看百分比选择命中了哪些 PodFAQ 给出了直接的验证手段从实验日志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 实验通用 tunablesTARGET_NODE单个目标节点名适用于 node-drain、node-taint、node-restart、kubelet-service-kill、docker-service-killTARGET_NODES逗号分隔的多个目标节点名适用于 node-cpu-hog、node-memory-hog、node-io-stressNODE_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.localNETWORK_INTERFACE应设为eth0。7.1 如何检查 NETWORK_INTERFACE 与 SOCKET_PATHNETWORK_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 表以下是网络类实验可调的关键参数变量说明默认/注意NETWORK_PACKET_LOSS_PERCENTAGE网络丢包百分比默认 100TOTAL_CHAOS_DURATION混沌注入时长秒默认 60TARGET_CONTAINER受网络故障影响的容器名仅 containerd/CRI-O 有效未填则作用于 Pod 首个容器DESTINATION_IPS受影响的 IP/CIDR逗号分隔不填则作用于所有 IPDESTINATION_HOSTS受影响的 DNS/FQDN逗号分隔不填则作用于所有 IP 或已定义的 DESTINATION_IPSSOURCE_PORTS/DESTINATION_PORTS受影响的源/目的端口前缀!表示黑名单不填则作用于所有端口PODS_AFFECTED_PERC受影响 Pod 百分比默认 0对应 1 副本LIB混沌库litmus默认/ pumbaSEQUENCE多目标执行顺序parallel默认/ serialRAMP_TIME注入前后等待时长秒无默认完整可复制的 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: 1808.3 Ramp Time 与 Chaos Interval 的区别Ramp TimeRAMP_TIME混沌注入前与后各自等待的时长秒用于让系统进入稳定状态或观察恢复Chaos IntervalCHAOS_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或Clusterpod 级实验通常为 Namespaced集群级影响的实验为 Clusterpermissions用于声明运行实验所需的最小权限并帮助评估实验的爆炸半径blast radius。9.3 混沌资源的作用域与命名空间约束混沌 CRChaosExperiment、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/categoriespods、nodes、aws、azure、gcp、spring-boot、load 等子目录全部实验清单可通过 ChaosHub 查询。十、实验执行模型三个标准 PodFAQ 解释了 ChaosEngine 创建后的标准工作流启动chaos-runnerPod——它是 ChaosEngine 中列出的多个实验的“伞式执行器”chaos-runner 为**每个实验创建一个 PodJob**运行实验业务逻辑并管理这些实验 Pod 的生命周期实验依赖校验、Job 清理、把状态回写进 ChaosEngine 等可选地创建monitor Pod用于导出混沌指标。这三者构成一次实验执行的标准 Pod 集合。此外实验 Job 视所选实验与混沌库的不同还可能派生出从属的helper资源例如 node 级实验的 helper pod。十一、实验运行控制注解、启停、恢复与日志11.1 是否必须给应用标注 chaos 注解应用通常应标注litmuschaos.io/chaostrue以“允许”被混沌选中。这有助于在命名空间中区分标签相近的应用隔离被测应用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-operator11.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 namespaceFAQ 同时注明后续版本仍在推进围绕混沌注入本身生成更多事件。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 namespace12.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被建模为houreveryNthHour/minuteOfTheHour或minuteeveryNthMinute二选一的结构minProperties: 1、maxProperties: 1校验并可与random: true搭配实现随机间隔。具体选哪种取决于需求需要“密度受控的固定次数”选instanceCount需要“稳定的最小间隔节奏”则选minChaosInterval。总结这份 FAQ 覆盖了 Litmus 混沌实验从机制原理tc netem、cgroup 非 exec 注入、OOM 边界到实战配置目标圈定、网络 tunables、RBAC、作用域再到运维控制启停恢复、日志事件、指标度量、结果解读的完整闭环。无论你是刚接触 Litmus 的 SRE还是已经在生产集群上编排混沌流水线的开发者都可以把本文作为实验设计与问题排查的速查手册——每个结论都能在 experiments FAQ 及对应的实验/概念文档中找到出处并在你自己的集群上用 kubectl 直接验证。赞分享云原生运维可观测性【免费下载链接】litmusLitmus helps SREs and developers practice chaos engineering in a Cloud-native way. Chaos experiments are published at the ChaosHub (https://hub.litmuschaos.io). Community notes is at https://hackmd.io/a4Zu_sH4TZGeih-xCimi3Q项目地址https://gitcode.com/gh_mirrors/li/litmus点击查看免费下载相关推荐Litmus pod-delete 混沌实验实战指南Pod 故障注入原理、参数调优与高可用验证Litmus pod delete 混沌实验实战指南Pod 故障注入原理、参数调优与高可用验证 本文以 Litmus 开源混沌工程平台的 pod delete云原生运维可观测性Litmus 混沌工程实战在 Percona XtraDB Cluster 上注入网络故障并用 Grafana 全程监控Litmus 混沌工程实战在 Percona XtraDB Cluster 上注入网络故障并用 Grafana 全程监控 本文以 Litmus 开源仓库中 m云原生运维可观测性Litmus 混沌实验 pod-dns-spoof在 Kubernetes Pod 中注入 DNS 解析欺骗故障Litmus 混沌实验 pod dns spoof在 Kubernetes Pod 中注入 DNS 解析欺骗故障 本指南以 Litmus 开源混沌工程项目中的云原生运维可观测性上一篇CopyTranslator高级定制50个动作命令与全局快捷键绑定动作系统完全详解下一篇jQuery File Upload与SAP后端系统集成探索创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
