kube-score K8S Yaml静态代码分析工具详解

kube-score 是一款专注于 Kubernetes 配置文件的静态代码分析工具，旨在通过自动化检查帮助用户识别资源配置中的潜在问题，并遵循最佳实践以提升集群的安全性、稳定性和性能。以下是其核心功能、使用方法和应用场景的详细解析：

一、核心功能与设计理念

自动化安全检查
kube-score 通过预定义的规则集对 Kubernetes 资源（如 Deployment、Service、Pod）进行扫描，检测以下常见问题：

资源限制缺失：未设置 CPU/内存的 requests 和 limits，可能导致资源争用。
安全配置不当：容器以 root 用户运行、未启用只读文件系统或未配置安全上下文（Security Context）。
网络与存储风险：暴露高危端口（如 22、80）、未正确绑定持久卷（PV/PVC）或使用默认服务账户。

灵活性与扩展性

自定义规则：支持通过 YAML 文件定义自定义检查规则，适应特定场景需求（如强制要求特定标签或注释）。
插件化架构：可通过插件扩展检查范围，例如集成特定云厂商的安全策略。

详尽的报告输出
提供多种格式的报告（如 JSON、CI 兼容格式），明确列出问题描述、严重级别（Critical/Warning/Advise）及修复建议，例如：

kube-score score -o json deployment.yaml  # 输出 JSON 格式报告:cite[2]

二、安装与基本使用

1. 安装方式

二进制文件：从 GitHub Releases 下载预编译版本。

Docker：直接运行官方镜像，适合 CI/CD 环境：

docker run -v $(pwd):/project zegl/kube-score score *.yaml

Homebrew/Krew：macOS/Linux 用户可通过包管理器快速安装。

2. 基本命令

扫描单个文件：
```
kube-score score deployment.yaml
```

扫描目录或通配符：

kube-score score ./manifests/  # 检查目录下所有 YAML 文件:cite[1]

输出详细报告：

kube-score score -d deployment.yaml  # 显示问题详情与修复建议:cite[1]

三、高级功能与集成

1. 自定义规则集

通过创建规则文件（如 custom-rules.yaml），定义特定检查逻辑。例如强制所有 Deployment 设置 livenessProbe：

- name: require-liveness-probedescription: Ensure all Deployments have liveness probes.rule:kind: Deploymentfield: spec.template.spec.containers[*].livenessProbevalue: non-empty

运行命令：

kube-score score -r custom-rules.yaml deployment.yaml:cite[1]

2. CI/CD 集成

在流水线中嵌入 kube-score，阻止不符合标准的配置进入生产环境。例如 GitLab CI 配置：

stages:- securitykube-score-check:stage: securityimage: zegl/kube-scorescript:- kube-score score --exit-one-on-warning ./k8s/*.yaml:cite[2]

3. 忽略特定检查

命令行忽略：

kube-score score --ignore-test=pod-probes deployment.yaml  # 跳过 Pod 探针检查:cite[2]

资源注释忽略：在 YAML 中添加注解临时禁用检查：
```
metadata:annotations:kube-score/ignore: "unset-resources":cite[2]
```

四、典型应用场景

开发阶段：

在提交代码前检查资源配置，避免基础错误（如未设置资源限制）。
结合 Git Hooks 实现本地预检，减少 CI 失败率。

运维与审计：

定期扫描生产环境配置，识别安全漏洞（如特权容器）。
生成合规性报告，满足内部审计或监管要求。

多集群管理：

统一不同集群的配置标准，确保一致性。
对比历史报告，分析配置退化趋势。

五、与其他工具的对比

工具	核心能力	适用场景
kube-score	静态配置检查、自定义规则	预生产环境配置验证
kubeval	验证 YAML 语法与 API 版本兼容性	基础语法校验
Checkov	多云安全策略检查（含 Kubernetes）	安全合规扫描

六、注意事项

版本兼容性：

确保 kube-score 版本与 Kubernetes 集群版本匹配（通过 --kubernetes-version 参数指定）。

规则更新：

定期同步官方规则库，获取新增的安全检查项。

性能优化：

避免在大型集群中全量扫描，可通过标签筛选目标资源。

七、最佳实践

1、核心检查项与优化建议

kube-score 通过预定义规则对 Kubernetes YAML 文件进行扫描，重点关注以下关键领域：

1）资源请求与限制（Resource Requests/Limits）

问题：未设置 CPU/内存的请求和限制，可能导致资源争用或 Pod 被驱逐。

优化：

resources:requests:cpu: "100m"memory: "256Mi"limits:cpu: "500m"memory: "512Mi"

目标：确保 Pod 获得稳定资源分配，避免资源耗尽导致的节点崩溃。

2）健康检查（Liveness/Readiness Probes）

问题：未配置存活探针（Liveness Probe）或就绪探针（Readiness Probe），可能导致流量路由到不健康的 Pod。

优化：

livenessProbe:httpGet:path: /healthzport: 8080initialDelaySeconds: 15
readinessProbe:httpGet:path: /readyport: 8080

目标：提升应用自愈能力，避免服务中断。

3）安全上下文（Security Context）

问题：容器以 root 用户运行或未限制文件系统只读。

优化：

securityContext:runAsNonRoot: truereadOnlyRootFilesystem: truecapabilities:drop: ["ALL"]

目标：减少容器逃逸攻击风险，遵循最小权限原则。

2、高级配置与策略

1）标签与注释管理

问题：资源标签缺失或过于简单，难以实现精细化筛选。

优化：

metadata:labels:app: my-appenv: prodtier: backend

目标：支持高效资源筛选和策略绑定（如网络策略、监控）。

2）Pod 调度策略

问题：未使用反亲和性（Anti-Affinity），导致多个 Pod 集中在同一节点。

优化：

affinity:podAntiAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: appoperator: Invalues: ["my-app"]topologyKey: "kubernetes.io/hostname"

目标：提升应用可用性，避免单点故障511。

3）镜像管理

问题：使用 latest 标签或未指定镜像来源。

优化：

image: harbor.example.com/my-app:v1.2.3@sha256:abc123

目标：避免意外升级，确保镜像来源可信。

3、集成与自动化

1）CI/CD 流水线集成

方法：在 GitLab CI 或 GitHub Actions 中嵌入 kube-score 扫描，阻断不合规配置的部署。

示例（GitHub Actions）：

- name: Run kube-scoreuses: docker://zegl/kube-scorewith:args: score ./k8s/*.yaml --output-format ci --exit-one-on-warning

目标：实现左移安全（Shift Left），在开发阶段发现问题。

2）自定义规则扩展

场景：针对团队规范定义额外检查（如强制使用私有镜像仓库）。
步骤：
- 创建 custom-rules.yaml 文件定义规则。
- 运行扫描时加载自定义规则：kube-score score -r custom-rules.yaml deployment.yaml

目标：适配组织内部合规要求。

4、常见问题与解决方案

问题类型	kube-score 提示	修复方案
未设置资源限制	`Container Resources: CPU limit is not set`	添加 `resources.limits` 和 `resources.requests` 字段58
缺少健康检查	`Container is missing a readinessProbe`	配置 `readinessProbe` 和 `livenessProbe`5
容器以 root 运行	`Container has no configured security context`	设置 `runAsNonRoot: true` 和 `runAsUser`510