4. 资源模型基础：Kubernetes资源模型概述、Pod/Deployment/StatefulSet的资源定义

4.1 Kubernetes 资源模型概述

Kubernetes 资源模型是集群管理的核心抽象层，它将一切基础设施能力与业务负载都定义为 API 对象。每个对象通过 apiVersion、kind、metadata、spec 和 status 五个字段描述其期望状态与当前状态。在 CrashLoop 场景下，理解资源模型是定位故障域、制定恢复策略的前提。

4.2 Pod 资源定义与 CrashLoop 故障域

Pod 是 Kubernetes 中最小的调度和运行单元。在 CrashLoop 场景中，Pod 是故障的直接载体。理解 Pod 的资源定义有助于快速定位容器崩溃的根因。

4.2.1 Pod 核心字段

apiVersion: v1
kind: Pod
metadata:
  name: crashloop-pod-demo
  labels:
    app: demo
spec:
  containers:
  - name: app-container
    image: busybox:1.36
    command: ["/bin/sh"]
    args: ["-c", "exit 1"]   # 模拟 CrashLoop
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
    livenessProbe:
      exec:
        command: ["cat", "/tmp/healthy"]
      initialDelaySeconds: 5
      periodSeconds: 5
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5
  restartPolicy: Always

4.2.2 Pod 生命周期与重启状态

4.3 Deployment 资源定义与无状态故障域

Deployment 管理无状态工作负载，通过 ReplicaSet 控制 Pod 副本数。在 CrashLoop 场景下，Deployment 的故障域是 副本集级别的滚动影响。

4.3.1 Deployment 核心字段

apiVersion: apps/v1
kind: Deployment
metadata:
  name: crashloop-deploy-demo
  labels:
    app: demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
      - name: app
        image: nginx:1.25
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "128Mi"
            cpu: "250m"
          limits:
            memory: "256Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /healthz
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

4.3.2 Deployment 故障域特征

• 副本级故障域： 单个 Pod CrashLoop 不影响其他副本，但 maxUnavailable 策略可能阻塞滚动更新。
• 回滚能力： 通过 kubectl rollout undo 快速恢复至上一版本，是 CrashLoop 恢复的首选手段。
• 故障扩散风险： 如果 CrashLoop 由 ConfigMap/Secret 错误引起，所有新创建的 Pod 都会失败。

4.4 StatefulSet 资源定义与有状态故障域

StatefulSet 用于管理有状态应用，为每个 Pod 提供稳定的网络标识和持久化存储。CrashLoop 在有状态场景下会引发 存储绑定与 Pod 标识的耦合故障。

4.4.1 StatefulSet 核心字段

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: crashloop-statefulset-demo
spec:
  serviceName: "db-headless"
  replicas: 3
  selector:
    matchLabels:
      app: db
  template:
    metadata:
      labels:
        app: db
    spec:
      containers:
      - name: db
        image: postgres:16
        ports:
        - containerPort: 5432
          name: db-port
        env:
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-secret
              key: password
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data
        livenessProbe:
          exec:
            command: ["pg_isready", "-U", "postgres"]
          initialDelaySeconds: 30
          periodSeconds: 10
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi

4.4.2 StatefulSet 故障域特征

4.5 资源模型在 CrashLoop 恢复中的关键作用

• 故障域定位： 通过资源模型的 ownerReferences 链（Pod → ReplicaSet → Deployment）快速定位故障传播路径。
• 恢复策略选择： 无状态（Deployment）优先回滚；有状态（StatefulSet）优先修复存储和网络标识。
• 资源隔离： 利用 resourceQuota 和 limitRange 防止 CrashLoop 耗尽集群资源。
• 声明式修复： 修改 spec 后控制器自动调谐，无需手动操作每个 Pod。