共计 2308 个字符，预计需要花费 6 分钟才能阅读完成。

错误配置引发的血案

最近帮同事排查一个生产环境故障时，发现某个 Deployment 的 spec.replicas 被误设为字符串 "3"（本应是数字 3）。结果控制器完全无视这个配置，导致服务始终无法扩容。更隐蔽的问题是：这个 YAML 居然能通过kubectl apply 提交成功——因为 K8s 的开放 API 模式会宽容处理类型错误。

另一个经典案例是有人忘记在 StatefulSet 中配置 volumeClaimTemplates，却奇怪为什么 Pod 总是启动失败。这两个案例暴露出新手常犯的致命错误： 不理解 spec 的强规则约束。

核心资源 Spec 规则解剖

1. Deployment 的黄金三要素

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 3           # 必须为整数，控制器根据该值创建对应数量的 Pod
  selector:             # 必须与 template.labels 匹配，否则报错
    matchLabels:
      app: nginx
  template:             # Pod 模板是唯一不可省略的部分
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

2. StatefulSet 的特殊规则

apiVersion: apps/v1
kind: StatefulSet
spec:
  serviceName: "nginx"  # 必须提前存在对应的 Headless Service
  volumeClaimTemplates: # 有状态应用必须声明存储卷模板
  - metadata:
      name: www
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 1Gi

3. 对比表

关键场景 YAML 示例

场景 1：带资源限制的 Pod

apiVersion: v1
kind: Pod
metadata:
  name: limited-pod
spec:
  containers:
  - name: busybox
    image: busybox
    resources:
      limits:
        cpu: "1"       # 最多使用 1 核 CPU
        memory: 500Mi   # 内存硬限制
      requests:
        cpu: "0.5"      # 至少需要 0.5 核
        memory: 100Mi   # 启动最低内存

场景 2：配置健康检查

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: web
        livenessProbe:  # 存活检查
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 15
        readinessProbe: # 就绪检查
          exec:
            command: ["cat", "/tmp/ready"]

场景 3：使用 ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: game-config
data:
  game.properties: |
    enemy.types=aliens,monsters
---
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: game
        envFrom:
        - configMapRef:
            name: game-config

kubectl 高阶技巧

1. 命令执行逻辑

当你运行 kubectl apply -f deploy.yaml 时：
1. 客户端将 YAML 转换为 JSON
2. 向 API Server 发起 POST 请求
3. 资源对象被持久化到 etcd
4. 相应控制器检测到变化并开始协调

2. 必备技能

# 1. 动态修改资源
kubectl patch deployment/nginx -p '{"spec":{"replicas":5}}'

# 2. 智能诊断
kubectl describe pods | grep -A 10 Events

# 3. 安全删除
kubectl delete pod --grace-period=60 my-pod

生产环境避坑指南

1. 永远设置资源限制：避免某个 Pod 吃光节点资源
2. 配置 Pod 反亲和性：关键服务不要全部署在同一个节点
3. 使用 PDB（PodDisruptionBudget）：防止维护时服务中断
4. 定期检查 finalizers：对象卡在删除状态时检查是否有残留 finalizer
5. 慎用 cluster-admin 权限：遵循最小权限原则

控制器工作原理

当你在 YAML 中定义 spec.replicas: 3 时：
1. Deployment 控制器检测到期望状态(3 个 Pod)
2. 比较当前实际运行的 Pod 数量
3. 通过 ReplicaSet 创建 / 删除 Pod
4. 持续循环检查（默认每秒一次）

动手实验

任务：创建一个被严格限制资源的 Pod
要求：
– 最多使用 0.5 核 CPU 和 200MB 内存
– 最低保证 0.1 核 CPU 和 50MB 内存
– 当内存超过 150MB 时自动重启容器

提示模板：

apiVersion: v1
kind: Pod
spec:
  containers:
  - name: stress
    image: polinux/stress
    resources:
      # 在此添加限制
    # 在此添加内存检查

通过本文的实践，相信你已经掌握了从 Spec 规则到 Command 执行的核心技能。建议在测试集群中反复练习这些案例，直到能快速定位和解决配置问题。记住：Kubernetes 的强规则约束是保障系统稳定的基石，理解它们才能游刃有余。