资源对象的共同结构#

Kubernetes 几乎所有能力都通过 API Resource 表达：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  namespace: production
  labels:
    app: order-service
spec:
  replicas: 3
status: {}

用户通常只维护 spec，控制器观察 status 并执行 Reconciliation Loop：

API Server、etcd 与 Controller#

kubectl apply 或 Helm 并不会直接启动容器。请求首先进入 kube-apiserver，经过 认证、授权、准入和数据校验后，资源状态保存到 etcd。Controller 通过 API 观察 资源变化并创建或更新下游对象。

etcd 保存的是 Kubernetes 控制面状态，不是业务数据库。API Server 是资源访问 入口，etcd 是状态存储，Controller 则负责让现实逐渐符合声明，三者职责不能混淆。

从 PodSpec 到 Container#

Pod 创建时通常还没有绑定 Node。kube-scheduler 根据资源请求、节点状态、亲和 与反亲和、Taint 和 Toleration 等约束选择节点。节点上的 kubelet 获取 PodSpec， 再通过 CRI 调用 containerd 等运行时拉取镜像并启动容器。

Pod 会经历 Pending、Running、Succeeded、Failed 或 Unknown 等阶段， 但它不是虚拟机式的永久身份。Pod 可以被删除、重建或迁移，名称和 IP 也可能 改变。业务不能依赖某个 Pod 长期存在，这一前提贯穿服务发现、自愈和滚动更新。

Deployment、ReplicaSet 与 Pod#

Deployment 是无状态服务最常用的资源，但它并不直接管理 Pod，而是通过 ReplicaSet 维护副本数量：

Deployment 中的 template 是 Pod Template。镜像、标签、资源限制或探针等 模板内容发生变化时，Deployment 会创建新的 ReplicaSet，并逐步替换旧 Pod。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: order-service
  template:
    metadata:
      labels:
        app: order-service
        version: v1
    spec:
      containers:
        - name: order-service
          image: registry.example.com/order-service:1.4.2
          ports:
            - containerPort: 8080

Deployment 依靠 Label 与 Selector 关联 Pod，而不是依赖 Pod 名称。Label 用于 分类和选择；Annotation 用于保存说明、外部系统参数等不参与 Selector 的元数据。

资源之间还可以通过 OwnerReference 表达所有权。Deployment、ReplicaSet 与 Pod 形成所有权链，便于级联删除和垃圾回收。Finalizer 则阻止资源在必要清理完成前 被彻底删除，这些机制也是后续理解 CRD 与 Operator 的基础。

Volume 与持久化边界#

容器可写层和 Pod 都是临时的。Volume 为 Pod 内容器提供存储挂载，其中 emptyDir 与 Pod 同生命周期，适合缓存和容器间临时共享，不适合长期数据。

持久存储通过 PV 和 PVC 解耦工作负载与底层磁盘：

PVC 描述工作负载需要什么存储，PV 表示实际持久存储资源，StorageClass 还可以 支持动态供应。对于数据库等有状态服务，持久卷只能保存数据，备份、复制、恢复和 一致性仍需要应用或托管服务自身保证。

requests 与 limits#

resources:
  requests:
    cpu: 500m
    memory: 512Mi
  limits:
    cpu: '1'
    memory: 1Gi

• requests 是调度和资源保障的主要依据；
• limits 约束容器最多可以使用的资源；
• CPU 超限通常导致 Throttling；
• Memory 超限可能导致 OOMKilled。

requests 过低会让节点过度承诺，导致运行时资源争抢；过高则造成 Pod 难以调度 和资源浪费。limits 也不应机械设置，需要结合应用内存模型、并发和负载测试确定。

三类 Probe 解决不同问题#

startupProbe:
  httpGet:
    path: /health/startup
    port: 8080
  failureThreshold: 30
  periodSeconds: 5

readinessProbe:
  httpGet:
    path: /health/ready
    port: 8080
  periodSeconds: 5

livenessProbe:
  httpGet:
    path: /health/live
    port: 8080
  periodSeconds: 10

Running 只说明容器进程已经启动，不等于 Ready。大型 Java 应用可能仍在 加载配置、建立连接或预热缓存。Readiness Probe 能防止流量过早进入，Startup Probe 则避免慢启动应用被 Liveness Probe 反复杀死。

探针设计必须克制。Liveness 不应依赖偶发抖动的外部服务，否则下游故障可能引发 整个集群大规模重启；Readiness 可以更敏感，但也要防止短暂波动导致所有实例 同时摘流。

滚动更新依赖 Readiness#

Deployment 默认采用 RollingUpdate。假设副本数为 3：

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

maxSurge: 1 允许更新期间临时增加一个 Pod，maxUnavailable: 0 要求始终保留 三个可用副本。只有新 Pod 通过 Readiness Probe 后，控制器才会逐步移除旧 Pod：

V1 V1 V1
V1 V1 V1 + V2
V1 V1 V2
V1 V2 V2
V2 V2 V2

Deployment 会为 Pod Template 变化记录 Revision，可以回滚到旧模板。但回滚镜像 和 Pod 配置并不会自动撤销数据库 Schema、消息格式或外部状态变化，因此发布设计 还必须保证上下游兼容。

Pod 随时可能被替换#

Rolling Update、Node Drain、自动伸缩和节点维护都会正常终止 Pod。应用收到 SIGTERM 后，应该停止接收新请求、完成进行中的工作、关闭连接并刷新必要数据。

spec:
  terminationGracePeriodSeconds: 30
  containers:
    - name: order-service
      lifecycle:
        preStop:
          exec:
            command: ['sh', '-c', 'sleep 5']

preStop 可以为摘流或清理提供准备时间，terminationGracePeriodSeconds 定义 优雅退出期限；超时后进程可能被强制终止。具体时长应覆盖业务请求和关闭流程， 而不是照搬固定数值。