技能介绍

要解决的问题

一份 deployment.yaml 在 kubectl apply 之后才暴露问题，代价通常很高：镜像没有设置 imagePullPolicy，滚动更新被一个不合理的 maxSurge 卡住，resources 完全缺失导致 Pod 被 OOMKilled，或者 securityContext 空着让容器以 root 身份跑起来。这些都不是语法错误，kubectl apply --dry-run=server 照样通过，CI 里的 YAML lint 也看不出来。结果就是风险一路拖到生产环境，等发现时已经影响发布节奏。

技能如何工作

这个技能把 kube-score 作为流水线里一个前置的静态检查环节。它的输入对象很明确：要么是手写的 Kubernetes manifests，要么是 Helm 渲染之后的产物。因为检查发生在模板渲染完成之后、真正提交部署之前，模板里通过条件分支生成的字段同样能被覆盖到。

核心能力包括：

扫描 YAML 中的可靠性隐患，例如探针缺失、副本数为 1、没有配置资源请求与限制、就绪探针和存活探针职责混用。
检查安全默认值过弱的情况，比如未设置 securityContext、缺少 runAsNonRoot、automountServiceAccountToken 未关闭。
对照 kube-score 的规则集对清单打分，并按严重程度输出问题，让 reviewer 直接看到哪里需要改，而不是通读整份 YAML。

典型流程是：准备 kube-score 与待检查的清单，指向 YAML 文件或 Helm 渲染输出，执行评分，然后按报告中的条目逐项修正。

适用边界与注意点

先说边界。kube-score 做的是静态规则匹配，它不会真正把 Pod 跑起来，因此无法验证应用的运行时行为、网络连通性或服务发现是否正确。它也替代不了 OPA Gatekeeper、Kyverno 这类在集群侧做实时拦截的准入控制，两者更合理的位置是互补。

另外，上游技能包本身没有自动提取到可靠的安装与使用说明。如果打算把它放进敏感的发布流程，建议先完整阅读上游文档（https://kube-score.com/）和原始仓库，确认规则集版本与你们集群的 Kubernetes 版本匹配，再决定是否把它设为强制卡点。规则本身可配置，默认配置未必贴合内部合规要求，按需裁剪比直接全开更实际。