使用Kubernetes List清单部署两个DaemonSet时第二个未生效的问题咨询

把多个DaemonSet打包在同一个List清单里部署的方式，是Kubernetes官方原生支持的合法用法，不存在方法本身的错误。你遇到第二个DaemonSet完全不出现在集群的问题，基本都是部署时的YAML解析、资源识别、日志静默跳过类的常见踩坑，具体原因和排查方向如下：

最常见的根因 #

• YAML缩进错位导致数组元素直接被丢弃
  List的items数组对缩进对齐要求非常严格，如果你写第二个DaemonSet配置时，spec字段和上级metadata字段缩进不匹配（比如你示例里占位符位置的缩进和第一个DaemonSet的块没对齐），YAML解析器会直接把第二个DaemonSet判定为无效语法块。
  这里有个非常容易踩的机制：kubectl apply部署List文件时，遇到单个item语法无效根本不会中断整个部署流程，只会在输出日志里打一行warning就跳过无效块，很多人部署的时候只看最后成功的提示，没翻前面的warning，就会误以为第二个资源压根没被提交。
• 资源GVK不被集群识别导致静默跳过
  如果你写第二个DaemonSet时，把apiVersion写成了集群不支持的弃用版本（比如早就淘汰的extensions/v1beta1），kubectl在扫items数组时，会直接跳过所有匹配不到集群已知API组的资源，全程不会报致命错误，那行跳过提示字特别小，非常容易被忽略。
  顺便澄清个常见误解：List资源自己metadata下的namespace、name字段，只对List这个对象本身生效，根本不会给items里的子资源自动注入默认命名空间，不存在因为List的命名空间配置错导致第二个DaemonSet被创建到别的命名空间的问题——毕竟你两个DaemonSet自己都写了固定的test-ns命名空间。
• 部署命令参数误配置
  如果部署的时候加了带过滤的参数（比如kubectl apply -f xxx.yaml --selector app=daemonset1，或者开了--prune修剪模式），匹配规则刚好只命中第一个DaemonSet，就会直接跳过不满足条件的第二个DaemonSet，根本不往集群提交。

快速排查步骤 #

• 跑一遍带服务端预检的部署，把完整日志拉出来看：执行kubectl apply -f <你的List文件> -n test-ns --dry-run=server，重点找输出里提到DaemonSet2的跳过、语法错误、API版本不兼容提示
• 把第二个DaemonSet的配置块单独从List里拆出来，存成独立yaml文件单独apply，验证单独提交时能不能正常创建，定位是不是配置本身的语法问题
• 检查集群有没有配准入Webhook规则，比如对DaemonSet的创建前缀、节点选择器有强制要求，拦截时是不是用了静默拒绝的策略

提醒：完全没必要为了这个问题把两个DaemonSet拆成独立文件部署，List批量部署多资源本身就是kubectl官方推荐的部署方式，本身没有架构层面的缺陷。

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