4. Deployment 资源模型:Kubernetes Deployment YAML 结构解析与关键字段
Deployment 是 Kubernetes 中最常用的工作负载资源,它负责声明式地管理 Pod 副本、滚动更新、回滚以及自愈能力。在服务目录平台中,水位巡检的核心数据源正是 Deployment 的 YAML 定义及其运行时状态。理解 Deployment 的资源模型,是设计巡检指标、判定水位健康度的前提。
4.1 Deployment YAML 顶层结构
一个标准的 Deployment YAML 遵循 Kubernetes API 约定,包含以下四个顶层键:
| 顶层字段 | 类型 | 说明 |
|---|---|---|
apiVersion |
string | 固定为 apps/v1(稳定版本) |
kind |
string | 固定为 Deployment |
metadata |
ObjectMeta | 名称、命名空间、标签、注解等元数据 |
spec |
DeploymentSpec | 期望状态,包含 Pod 模板、副本数、策略等 |
水位巡检主要关注 spec 下的字段,以及 status 中反映实际运行状态的字段。
4.2 关键字段深度解析
以下字段直接决定 Deployment 的容量、稳定性与资源消耗,是巡检指标的计算来源。
4.2.1 replicas —— 副本数与期望水位
spec.replicas 定义了期望运行的 Pod 副本数量。它是水位巡检中最基础的指标:
- 期望副本数:YAML 中声明的值,代表业务期望的并发容量。
- 实际就绪副本数:
status.readyReplicas,代表当前真正可用的 Pod 数量。 - 水位偏差:当
readyReplicas < replicas时,表示集群资源不足或 Pod 启动失败,属于高优先级告警。
巡检要点: 服务目录平台应定期比对
spec.replicas 与 status.readyReplicas,当偏差持续超过 10% 且超过 5 分钟时,触发“副本水位不足”事件。
4.2.2 resources —— 资源配额与利用率
spec.template.spec.containers[].resources 定义了每个容器的 CPU 和内存请求(requests)与限制(limits)。这是水位巡检中判断资源是否超卖或浪费的核心依据。
| 子字段 | 含义 | 巡检关注点 |
|---|---|---|
requests.cpu |
调度时保证的最小 CPU 核数 | 是否设置过低导致节点过载? |
requests.memory |
调度时保证的最小内存量 | 是否设置过高导致资源碎片? |
limits.cpu |
CPU 使用上限(burst 上限) | 是否未设置导致无限制抢占? |
limits.memory |
内存使用上限(OOM 阈值) | 是否接近实际使用量导致 OOM? |
常见陷阱: 许多团队只设置
requests 而不设置 limits,或设置 limits 远大于 requests。这会导致节点资源被过度承诺,在流量高峰时引发 CPU 节流或 OOM Kill。水位巡检应标记 limits/requests > 3 的 Deployment 为“资源水位异常”。
4.2.3 livenessProbe / readinessProbe —— 健康探针与自愈水位
探针决定了 Kubernetes 何时认为 Pod 不健康并触发重启或摘流。水位巡检需要检查探针的配置完整性:
- livenessProbe:存活探针。如果失败,kubelet 会重启容器。缺失此探针可能导致“僵尸 Pod”长期占用资源。
- readinessProbe:就绪探针。如果失败,Pod 会从 Service 端点中移除。缺失此探针可能导致流量打到未就绪的 Pod,造成请求超时。
- startupProbe:启动探针(v1.16+)。用于慢启动容器,防止 livenessProbe 在启动期间误杀。
巡检建议: 服务目录平台应将“未配置 livenessProbe 或 readinessProbe”的 Deployment 标记为“探针水位缺失”,并建议至少配置 HTTP GET 或 TCP Socket 探针,initialDelaySeconds 建议设置为 10-30 秒。
4.2.4 其他关键字段
| 字段路径 | 作用 | 水位巡检关联 |
|---|---|---|
spec.strategy.rollingUpdate.maxSurge |
滚动更新时最多可超出期望副本数的 Pod 数量 | 设置过大可能导致更新期间资源洪峰 |
spec.strategy.rollingUpdate.maxUnavailable |
滚动更新时最多允许不可用的 Pod 数量 | 设置过小可能导致更新阻塞 |
spec.template.spec.terminationGracePeriodSeconds |
优雅关闭等待时间 | 设置过短可能导致请求中断 |
spec.template.spec.nodeSelector / affinity |
节点调度约束 | 约束过严可能导致 Pod 无法调度,副本水位下降 |
4.3 Deployment 资源模型与水位巡检的映射关系
下图展示了 Deployment YAML 中的关键字段如何映射到服务目录平台的水位巡检维度:
4.4 完整 Deployment YAML 示例(带水位巡检注释)
apiVersion: apps/v1
kind: Deployment
metadata:
name: order-service
namespace: production
labels:
app: order
service-catalog: "true" # 服务目录平台标签
spec:
replicas: 3 # 【副本水位】期望 3 副本
selector:
matchLabels:
app: order
strategy:
rollingUpdate:
maxSurge: 1 # 【配置水位】更新时最多超 1 个 Pod
maxUnavailable: 0 # 【配置水位】更新时不允许中断
template:
metadata:
labels:
app: order
spec:
containers:
- name: order-container
image: registry.example.com/order:v2.1
resources:
requests:
cpu: "500m" # 【资源水位】请求 0.5 核
memory: "512Mi" # 【资源水位】请求 512MB
limits:
cpu: "1000m" # 【资源水位】限制 1 核
memory: "1Gi" # 【资源水位】限制 1GB
livenessProbe: # 【健康水位】存活探针
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 15
periodSeconds: 10
readinessProbe: # 【健康水位】就绪探针
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
terminationGracePeriodSeconds: 30 # 【配置水位】优雅关闭 30s
4.5 水位巡检字段速查表
服务目录平台在巡检 Deployment 时,应至少采集以下字段并计算对应水位指标:
| 巡检维度 | YAML 字段 | status 字段 | 水位判定规则 |
|---|---|---|---|
| 副本水位 | spec.replicas |
status.readyReplicas |
readyReplicas < replicas → 副本不足 |
| 资源水位 | resources.requests / limits |
实际使用量(Metrics Server) | limits/requests > 3 或 实际使用/requests < 0.2 → 资源浪费 |
| 健康水位 | livenessProbe / readinessProbe |
探针历史失败次数 | 缺失探针或失败率 > 5% → 健康水位低 |
| 配置水位 | strategy / terminationGracePeriodSeconds / affinity |
调度事件 | 未设置优雅关闭或调度约束过严 → 配置水位异常 |
落地建议: 在服务目录平台的 Deployment 详情页,将上述四个水位维度以仪表盘形式展示,每个维度使用红/黄/绿三色标识健康度。当任一维度为红色时,自动生成巡检工单并关联到对应 Deployment 的 YAML 字段,帮助运维人员快速定位根因。