Kubernetes 难点不在命令，而在配置 YAML 文件：字段太多、版本变化快，还担心一 apply 就把线上环境搞挂，如何解决呢？

一、快速查询配置项的方法

1. 官方文档（最权威）

• Kubernetes API Reference
  这里有 所有资源类型、字段、取值范围。比如 Deployment、Service、Ingress、RBAC 的字段解释都能找到。
• Kubernetes Concepts
  更偏向原理，适合理解配置项的作用。

2. VS Code + Schema 自动补全

• 安装 Red Hat YAML 插件 + Kubernetes 插件。

• 配置 YAML Schema：

  {
    "yaml.schemas": {
      "kubernetes": "/*.yaml"
    }
  }
  

  → 写 YAML 时会自动提示合法字段，并报错不合法的配置。

3. Cheat Sheet / Snippet 插件

• Kubernetes Snippets 插件，输入 kdep 自动展开 Deployment 模板。
• 社区的 kubectl Cheat Sheet 对配置和命令都有速查表。

---

二、验证配置正确性的方法

1. kubectl explain

直接在终端查询字段：

kubectl explain deployment.spec.template.spec.containers.resources

会显示字段的含义、类型和可选项，比查文档快。

2. kubectl apply --dry-run

模拟执行，不会改动资源：

kubectl apply -f my-deploy.yaml --dry-run=client
kubectl apply -f my-deploy.yaml --dry-run=server

• client：仅在本地校验语法。
• server：发给 API Server 校验，但不会真正写入 etcd。

3. kubectl diff

对比新配置与集群现状：

kubectl diff -f my-deploy.yaml

只显示差异，不会应用。非常适合 CI/CD。

4. Linter 工具

• kubeval：基于 Kubernetes OpenAPI schema 校验 YAML。
• kube-score：给出配置健康评分（副本数、资源限制、探针是否合理）。
• datree：可自定义策略，防止危险配置（如 latest 镜像）。

---

三、如何保证“不伤害已有数据和环境稳定性”

1. 优先在非生产环境验证

   • 建一个 kind / minikube 集群，先在本地跑。
   • 或者使用独立的 dev/staging namespace。

2. 使用 GitOps / CI/CD 流程

   • 在合并前自动跑 kubectl apply --dry-run、kubectl diff、kubeval。
   • 确认无误后再在 staging → prod 滚动发布。

3. 滚动更新策略

   • Deployment 默认是 RollingUpdate，不会一次性杀掉所有 Pod。

   • 你也可以显式配置：

     strategy:
       type: RollingUpdate
       rollingUpdate:
         maxUnavailable: 1
         maxSurge: 1
     

4. 保护数据类资源

   • 永远不要直接修改 PVC/StatefulSet 的存储参数。
   • 修改数据库配置前，先用 kubectl scale 把应用缩容到 0，确认数据持久化正常再启动。

5. 强制预演

   • 先 kubectl diff 看差异
   • 再 kubectl apply --dry-run=server 验证
   • 最后才 kubectl apply -f 真正执行

---

✅ 总结：

• 快速查字段 → kubectl explain + 官方 API Reference + VS Code YAML 插件
• 验证正确性 → kubectl apply --dry-run + kubectl diff + kubeval/kube-score
• 保证安全 → staging 环境演练 + GitOps 流程 + 滚动更新策略

---

---

📝 Kubernetes 配置检查与发布安全清单

1. 配置文件检查（YAML 层面）

检查项	说明	工具/命令
YAML 格式正确	确认缩进/语法合法	kubectl apply -f file.yaml --dry-run=client
API 版本正确	避免使用废弃 API（如 extensions/v1beta1 的 Ingress）	kubectl explain <kind> / API Reference
必填字段完整	metadata.name、spec.selector、spec.template 等	VS Code YAML 插件 / kubectl explain
资源命名规范	避免大写、特殊符号，遵循 DNS-1123 规则	文档约束
Label/Annotation 一致	统一使用 app.kubernetes.io/* 约定	手动检查

---

2. 容器与镜像

检查项	说明	工具/命令
镜像固定版本	避免 :latest，必须用具体 tag 或 digest	人工检查
镜像仓库可访问	保证私有仓库有 secret	kubectl get secret
资源限制设置	每个容器必须设置 resources.requests/limits	kube-score
健康检查探针	livenessProbe/readinessProbe 是否配置	kube-score
安全上下文	runAsNonRoot: true，避免特权模式	kube-score / OPA Gatekeeper

---

3. 配置与敏感信息

检查项	说明	工具/命令
ConfigMap/Secret 使用规范	不要把密码写死在 YAML，必须用 Secret	人工检查
Secret base64 合法	解码后确认内容正确	`echo	base64 -d`
环境变量管理	用 envFrom 引用 ConfigMap/Secret，避免重复配置	YAML 规范化

---

4. 存储与数据安全

检查项	说明	工具/命令
PVC 绑定正常	PVC → PV → 存储类是否存在	kubectl get pvc,pv,sc
危险字段修改禁止	不要随意修改 PVC 的 storageClassName 和大小	手动检查
StatefulSet 更新策略	Stateful 应用更新需滚动，避免数据丢失	partition 策略

---

5. 发布前验证

检查项	说明	工具/命令
配置差异对比	查看新旧配置的差异	kubectl diff -f file.yaml
服务端 Dry-run	让 API Server 校验配置合法性	kubectl apply --dry-run=server -f file.yaml
Linter 工具校验	kubeval/kube-score/datree 检查配置健康度	kubeval file.yaml
小规模演练	先在 dev/staging 环境 apply 验证	GitOps / CI/CD

---

6. 发布策略

检查项	说明	工具/命令
Deployment 滚动更新	strategy: RollingUpdate，maxUnavailable=1，maxSurge=1	人工检查
金丝雀/蓝绿发布	对核心服务建议金丝雀流量或蓝绿切换	Argo Rollouts / Flagger
不可中断 Job	Job/CronJob 要设置 backoffLimit，避免无限重试	YAML 检查

---

7. 发布后监控

检查项	说明	工具/命令
Pod 状态正常	READY=1/1，无 CrashLoopBackOff	kubectl get pods -n <ns>
Event 无异常	没有 FailedScheduling / ImagePullBackOff	kubectl get events -A --sort-by=.metadata.creationTimestamp
日志健康	应用日志无报错	kubectl logs
服务可访问	Ingress/Service 正常返回	curl / 测试脚本
自动回滚策略	CI/CD 中启用失败回滚	ArgoCD / Helm rollback

---

✅ 使用建议

1. 开发阶段：在 VS Code 里用 YAML 插件自动校验。
2. CI 阶段：加上 kubectl apply --dry-run=server、kubectl diff、kubeval。
3. 上线阶段：先 staging → 再 prod，务必观察监控。
4. 运维保障：核心数据服务使用 StatefulSet，避免粗暴更新。

---