运维云原生SREAI Agent人工智能【免费下载链接】chaosbladeAn easy to use and powerful chaos engineering experiment toolkit.阿里巴巴开源的一款简单易用、功能强大的混沌实验注入工具项目地址https://gitcode.com/gh_mirrors/ch/chaosblade点击查看免费下载本篇技术指南以 ChaosBlade 项目内置的 K8s 故障演练用例库blade-ai/skills/k8s-chaos-skills中的标准化用例「节点不可调度导致 DaemonSet 未完全调度」为主体完整讲解该混沌实验的故障现象、根因原理、注入与恢复的完整操作链并结合 Kubernetes 调度器行为与仓库内故障验证策略给出可复制、可回滚的实战演练方案。读完本文你将掌握如何通过kubectl cordon与自定义污点组合精确制造 DaemonSet 副本缺口并学会一套从注入、验证、恢复到残留检查的闭环演练方法。一、用例背景DaemonSet 的调度特性与本用例的演练价值DaemonSet 与 Deployment 的核心差异在于调度逻辑DaemonSet按节点调度确保集群中每个或指定一批Node 上都运行一个 Pod 副本而不是按副本数调度。它在生产环境中常用于日志采集Fluentd/Fluent Bit、监控采集Prometheus Node Exporter、网络代理Calico、Cilium等基础组件参见仓库知识库 k8s-knowledge.md 中关于 DaemonSet 的问答。因此验证 DaemonSet 是否完全调度应检查status.desiredNumberScheduled是否等于status.numberReady。本用例正是围绕这一指标设计通过把某个节点置为不可调度状态并附加一个 DaemonSet 无法容忍的自定义污点让 DaemonSet 在该节点上缺一份副本从而制造DESIRED与READY不一致的故障现象。该用例是仓库故障目录 DaemonSet_未完全调度 下唯一的标准用例属于 Workload 层级的故障注入场景与同一目录体系下的 Pod_Pending_节点Taint无对应TolerationTaint 导致 Pod 无法调度在原理上相通、在目标上互补。二、故障现象与基准事实2.1 故障现象注入后应观察到的表现DaemonSet 的 Ready 副本数小于期望副本数部分节点上没有运行 DaemonSet Podkubectl get daemonset显示DESIRED与READY数量不一致。2.2 基准事实用例定义的标准判据根因节点被标记为不可调度cordon且存在 DaemonSet 未容忍的自定义污点导致 DaemonSet 无法在该节点创建 Pod副本数小于期望数必现现象DaemonSetDESIRED与READY不一致节点SchedulingDisabled节点存在自定义污点节点上缺少 DaemonSet Pod。仓库的故障验证策略文档 fault-verification-strategies.md 给出了该场景的推荐验证命令组合get ds -o jsondesiredNumberScheduled ! numberReadyget pods -l部分 Pending可作为用例必现现象的机器可读判据。三、根因原理为什么 cordon 不够还必须加自定义污点这是本用例最关键的技术细节直接决定注入是否生效Kubernetes ≥ 1.12 的 DaemonSet 默认容忍node.kubernetes.io/unschedulable污点。因此仅执行kubectl cordon时DaemonSet 控制器会把该节点仍视为可放置 Pod 的目标Pod 依旧会被调度只是处于 Pending不会产生缺副本的故障必须额外添加一个 DaemonSet 未配置容忍的自定义污点例如chaos-drill/unschedulabletrue:NoSchedule调度器才会因untolerated taint拒绝在该节点创建 Pod相应地恢复时除kubectl uncordon外必须一并移除该自定义污点否则 Pod 仍无法调度故障无法彻底消除。值得注意的是部分基础组件型 DaemonSet如监控采集器本身带有常见节点故障污点的 Toleration见 k8s-knowledge.md 关于 Node 故障驱逐的说明因此选择自定义污点 keychaos-drill/...能有效避开目标 DaemonSet 可能预置的 Toleration确保注入必然生效。四、资源准备演练前需确认以下前提否则结果无法观测确认 DaemonSet 应用 A 已正常运行且所有节点均有副本即演练前DESIRED与READY完全一致确认监控系统可观测 DaemonSet 副本状态例如 Prometheus 对kube_daemonset_status_number_ready/kube_daemonset_status_desired_number_scheduled的采集满足无监控不演练的安全要求。五、演练步骤故障注入严格按以下顺序执行命令均以kubectl原生操作为注入手段选取节点选取一个运行 DaemonSet Pod 的节点即存在 DaemonSet 副本的目标节点标记不可调度kubectl cordon node添加自定义污点DaemonSet 未配置容忍的kubectl taint nodes node chaos-drill/unschedulabletrue:NoSchedule删除该节点上的 DaemonSet Pod观察 Pod 是否被重建kubectl delete pod daemonset-pod-name -n namespace观察 DaemonSet 副本数变化kubectl get daemonset从实现机制看本用例属于仓库 chaosblade-cli.md 中定义的Tier 2 kubectl-Native Injection路径这类注入没有blade_uid也没有自动恢复机制恢复必须由操作者显式执行恢复原语kubectl uncordon、kubectl taint nodes node key-因此注入前明确回滚方案、注入后严格走验证—恢复—恢复验证闭环尤为关键。六、注入验证注入完成后必须逐条确认故障已真实建立kubectl get nodes确认目标节点标记为SchedulingDisabledkubectl describe node node确认自定义污点chaos-drill/unschedulabletrue:NoSchedule存在于Taints列表中kubectl get daemonset确认DESIRED与READY数量不一致确认目标节点上的 DaemonSet Pod 删除后无法被重建处于 Pending 或被拒调度。仓库的 kubectl-recipes.md 提供了与此配套的节点状态检查 recipekubectl describe node node可查看节点 ConditionsReady、DiskPressure、MemoryPressure与 Taints同时可结合kubectl get pods --all-namespaces -o wide --field-selectorspec.nodeNamenode确认该节点上 DaemonSet Pod 缺失。故障验证应遵循先观测再断言、多维度交叉验证原则见 fault-verification-strategies.md 的验证命令设计原则优先使用-o json做程序化断言需要人类可读的 Event 描述时用describe。七、注入恢复演练结束或故障影响超出预期后按相反顺序恢复取消节点不可调度标记kubectl uncordon node移除自定义污点注意命令末尾的-表示删除该 key 的污点kubectl taint nodes node chaos-drill/unschedulabletrue:NoSchedule-等待 DaemonSet Pod 在该节点重建。八、恢复验证恢复 ≠ 简单反向断言。按仓库 fault-verification-strategies.md 的恢复验证原则恢复后必须确认系统回到注入前的基线状态并做残留检查kubectl get nodes确认目标节点恢复为可调度状态SchedulingDisabled消失kubectl describe node node确认自定义污点已从Taints列表中移除kubectl get daemonset确认DESIRED与READY数量一致确认目标节点上 DaemonSet Pod 已正常运行。需要留意的是Pod 重建调度需要时间调度器周期性调度 镜像拉取 容器启动恢复验证应等待恢复窗口一般 5~30s避免在故障效果未完全消除时误判。若恢复后仍观测到异常应检查是否残留了未移除的污点或节点仍处于Unschedulable状态按安全底线若手动清理后残余仍未消除应上报人类操作者。九、注意事项与爆炸半径控制Kubernetes 版本依赖Kubernetes ≥ 1.12 的 DaemonSet 默认容忍node.kubernetes.io/unschedulable污点因此kubectl cordon单独使用不会阻止 DaemonSet Pod 调度——这是本用例能够成立的关键前提低于该版本或自定义调度器环境中需另行验证必须使用自定义污点只有添加 DaemonSet 未配置容忍的污点才能有效阻止 Pod 调度恢复必须移除污点只uncordon而忘记移除自定义污点Pod 将一直无法调度故障残留爆炸半径本用例仅影响被 cordon 的单个目标节点但删除 DaemonSet Pod 前应确认该 DaemonSet 承载的职责日志/监控/网络避免在业务高峰期或对网络类 DaemonSet 演练造成大面积影响。上述约束与仓库 SKILL.md 的安全红线完全一致隔离命名空间或测试集群演练、用精确标签选择器控制影响范围、注入前明确回滚方案确保 30 秒内可恢复、无监控不演练、禁止对 etcd / kube-apiserver 等控制平面注入。执行该用例时所有kubectl命令都应显式指定--kubeconfig 路径Agent 执行模式下禁止依赖默认 kubeconfig并严格按演练步骤 → 注入验证 → 注入恢复 → 恢复验证顺序执行。十、与 ChaosBlade 体系的关系何时用 kubectl 原生注入本用例与 ChaosBlade 常规的blade create k8s实验如 chaosblade-commands.md 中的 Pod/Node 级故障不同DaemonSet 副本缺口由调度层行为导致ChaosBlade 的node-cpu、node-disk等资源型故障无法直接制造该现象。因此本用例走 kubectl 原生注入路径Tier 2其特点是优点精确、可复现、无需 blade agent代价没有blade_uid没有自动回滚恢复完全依赖人工执行uncordon 移除污点恢复验证环节尤其重要参见 chaosblade-cli.md 对 Tier 2 与 Tier 1 差异的说明。理解这一点就能在本用例与 blade 资源型故障之间做出正确选择制造资源压力用blade create k8s制造调度层副本缺口用本用例的 cordon taint 组合。十一、演练报告模板按仓库用例执行规范演练结束后输出结构化报告便于沉淀为团队韧性建设资产演练报告 - 用例Workload DaemonSet 未完全调度 节点不可调度 - 目标[namespace/app-name] - 注入结果成功/失败 观察到的现象DESIRED 与 READY 差异、SchedulingDisabled、污点存在 - 恢复结果成功/失败 是否符合基准事实副本数恢复一致、污点移除、Pod 重建 - 发现的问题与改进建议通过反复执行「cordon 自定义污点 → 删除 Pod → 验证副本缺口 → uncordon 移除污点 → 验证恢复」这一闭环可以系统性训练团队对 DaemonSet 副本缺口类告警的排查与应急能力同时检验监控告警与自愈机制是否完备。赞分享运维云原生SREAI Agent人工智能【免费下载链接】chaosbladeAn easy to use and powerful chaos engineering experiment toolkit.阿里巴巴开源的一款简单易用、功能强大的混沌实验注入工具项目地址https://gitcode.com/gh_mirrors/ch/chaosblade点击查看免费下载相关推荐ChaosBlade K8s 故障演练用例深度解析Volume 挂载超时与 CSI 可用区异常导致 Pod ContainerCreatingChaosBlade K8s 故障演练用例深度解析Volume 挂载超时与 CSI 可用区异常导致 Pod ContainerCreating 导读 本文基于运维云原生SREAI Agent人工智能ChaosBlade 实战ReadinessProbe 配置不一致导致 Service 调用失败的 Kubernetes 故障演练ChaosBlade 实战ReadinessProbe 配置不一致导致 Service 调用失败的 Kubernetes 故障演练 导读 本文围绕 BLAD运维云原生SREAI Agent人工智能ChaosBlade K8s 故障演练用例解读人为误操作导致 Workload 副本被缩容ChaosBlade K8s 故障演练用例解读人为误操作导致 Workload 副本被缩容 导读 本文深度解读 chaosblade 仓库中 k8s cha运维云原生SREAI Agent人工智能上一篇Cartographer 版本发布全流程基于 catkin 工具链的 Release 步骤详解下一篇XUnity.AutoTranslatorUnity游戏自动翻译的完整解决方案指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考