一、Pod 核心技术与实践

1.1 Pod 探针（Probe）

1.1.1 kubelet 检查机制

Kubelet 是 Kubernetes 节点上的代理进程，负责管理节点上所有 Pod 的生命周期，而探针（Probe）是 kubelet 定期执行的「容器健康诊断动作」，用于判断容器的运行状态。

• 执行逻辑：kubelet 按照配置的规则，周期性地向容器发起探测，根据探测结果决定容器的后续动作（重启 / 标记未就绪）。
• 核心价值：避免容器处于「僵死但进程仍在运行」的状态，或避免流量发送到未完成初始化的容器。

1.1.2 探针返回结果

探针执行后会返回三种结果，不同结果对不同探针的影响不同：

表格

结果状态	含义	对 LivenessProbe 的影响	对 ReadinessProbe 的影响
Success	容器通过健康检查	无动作，继续运行	标记为就绪，接收流量
Failure	容器未通过健康检查	触发容器重启	标记为未就绪，从 Service 端点移除
Unknown	探测执行失败（如超时）	无动作，等待下一次探测	无动作，等待下一次探测

1.1.3 探针的类型

K8s 提供三类探针，核心功能差异如下：

1. LivenessProbe（存活探针）：判断容器是否「正在正常运行」，如果失败，kubelet 会重启容器。用于解决容器僵死、进程挂死但 PID 仍存在的问题。
2. ReadinessProbe（就绪探针）：判断容器是否「已就绪并可以接收流量」，如果失败，kubelet 会将容器从 Service 的后端端点中移除，不再转发流量。用于解决容器启动慢、初始化未完成（如加载配置、预热缓存）的场景。
3. StartupProbe（启动探针，K8s 1.16+）：判断容器是否「已启动完成」，如果配置了该探针，Liveness 和 Readiness 探针会在 StartupProbe 成功后才开始执行。用于解决启动极慢的应用，避免探针误杀。

探针支持三种探测方式：

• exec：在容器内执行指定命令，命令退出码为 0 则判定成功。
• httpGet：向容器内的指定路径 / 端口发送 HTTP GET 请求，返回状态码 2xx/3xx 则判定成功。
• tcpSocket：尝试与容器内的指定端口建立 TCP 连接，连接成功则判定成功。

1.1.4 探针核心属性

所有探针都支持以下配置属性，控制探测的行为：

表格

属性	含义	默认值	生产建议
initialDelaySeconds	容器启动后，首次执行探针前的等待时间	0s	启动慢的应用设置≥10s，避免误判
periodSeconds	探针执行的间隔时间	10s	建议 5-10s，平衡负载与故障发现速度
timeoutSeconds	探针执行的超时时间	1s	大于探测动作的实际耗时，避免超时误判
successThreshold	探针失败后，连续多少次成功才判定为健康	1	LivenessProbe 必须为 1；ReadinessProbe 可设为 2-3
failureThreshold	探针成功后，连续多少次失败才判定为不健康	3	核心业务可设为 5，避免网络抖动误杀

---

1.1.5 LivenessProbe 探针案例

1.1.5.1 LivenessProbe + kubelet-exec（命令探测）

适用于无 HTTP 服务的应用，通过执行命令判断存活状态：

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    livenessProbe:
      exec:
        command: ["cat", "/tmp/healthy"] # 退出码0为成功
      initialDelaySeconds: 5
      periodSeconds: 5

说明：当容器内/tmp/healthy文件不存在时，命令执行失败，kubelet 会重启容器。

1.1.5.2 LivenessProbe + kubelet-httpGet（HTTP 探测）

适用于 Web 服务类应用，通过 HTTP 请求判断存活状态：

apiVersion: v1
kind: Pod
metadata:
  name: liveness-http
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    livenessProbe:
      httpGet:
        path: /healthz # 健康检查接口
        port: 80       # 容器端口
        scheme: HTTP   # 支持HTTP/HTTPS
      initialDelaySeconds: 3
      periodSeconds: 3

说明：当 Nginx 返回非 2xx/3xx 状态码时，探针失败，容器会被重启。

1.1.5.3 LivenessProbe + kubelet-tcpSocket（TCP 探测）

适用于 TCP 服务（如 Redis、MySQL），通过建立 TCP 连接判断存活状态：

apiVersion: v1
kind: Pod
metadata:
  name: liveness-tcp
spec:
  containers:
  - name: redis
    image: redis:7
    livenessProbe:
      tcpSocket:
        port: 6379 # 容器端口
      initialDelaySeconds: 5
      periodSeconds: 5

说明：当无法连接到 Redis 的 6379 端口时，探针失败，容器会被重启。

---

1.1.6 ReadinessProbe 探针案例

ReadinessProbe 的配置方式和 LivenessProbe 完全一致，核心区别是失败时不会重启容器，只会标记为未就绪，停止接收流量。

1.1.6.1 ReadinessProbe + kubelet-exec

apiVersion: v1
kind: Pod
metadata:
  name: readiness-exec
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    readinessProbe:
      exec:
        command: ["cat", "/tmp/ready"]
      initialDelaySeconds: 5
      periodSeconds: 5

场景：容器启动后需要加载配置文件，只有当/tmp/ready文件生成后，才允许接收流量。

1.1.6.2 ReadinessProbe + kubelet-httpGet

apiVersion: v1
kind: Pod
metadata:
  name: readiness-http
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    readinessProbe:
      httpGet:
        path: /ready
        port: 80
      initialDelaySeconds: 2
      periodSeconds: 3

场景：Web 服务启动后需要预热缓存，/ready接口只有在缓存加载完成后才返回 200，避免流量打向未就绪的服务。

1.1.6.3 ReadinessProbe + kubelet-tcpSocket

apiVersion: v1
kind: Pod
metadata:
  name: readiness-tcp
spec:
  containers:
  - name: mysql
    image: mysql:8.0
    readinessProbe:
      tcpSocket:
        port: 3306
      initialDelaySeconds: 10
      periodSeconds: 5

场景：MySQL 启动需要时间，只有当 3306 端口可连接时，才允许业务流量连接，避免连接失败。

---

1.2 Pod 基础案例

1.2.1 生成 YAML 文件

通过命令快速生成 Pod 的 YAML 模板，避免手写错误：

# 生成Pod的YAML文件（不实际创建Pod）
kubectl create pod my-nginx --image=nginx:1.25 --dry-run=client -o yaml > my-pod.yaml

1.2.2 创建与管理 Pod

# 通过YAML文件创建Pod
kubectl apply -f my-pod.yaml

# 查看Pod状态
kubectl get pods

# 查看Pod的详细信息（含事件）
kubectl describe pod my-nginx

# 删除Pod
kubectl delete pod my-nginx

二、Pod 常用命令速查

表格

命令	用途	常用参数
kubectl get pods	查看 Pod 列表	-o wide（显示节点、IP）、-n <ns>（指定命名空间）、-w（实时监控）
kubectl describe pod <pod-name>	查看 Pod 详细信息 / 事件	排查 Pod 启动失败、调度失败的核心命令
kubectl logs <pod-name>	查看容器日志	-f（实时跟踪日志）、-p（查看已终止容器的日志）、-c <container>（多容器时指定容器）
kubectl exec -it <pod-name> -- <command>	进入容器执行命令	如kubectl exec -it my-nginx -- /bin/bash进入容器
kubectl port-forward <pod-name> 8080:80	本地端口转发到 Pod	用于本地访问 Pod 内的服务
kubectl delete pod <pod-name>	删除 Pod	--force强制删除（Pod 处于 Terminating 状态时）

---

三、Pod 状态与故障排障

3.1 常用排障命令

1. kubectl describe pod <pod-name>：重点查看Events字段，获取 Pod 调度、创建过程中的错误信息。
2. kubectl logs <pod-name> -p：查看崩溃容器的日志，定位启动失败的原因。
3. kubectl get events --sort-by='.metadata.creationTimestamp'：按时间排序查看集群事件，定位故障时间线。
4. kubectl exec -it <pod-name> -- /bin/sh：进入容器内部，检查配置、网络、文件等问题。

3.2 常见故障归类与解决

表格

状态	故障原因	排查方向
Pending	Pod 未被调度到节点，或调度后无法启动	1. 节点资源不足（CPU / 内存）；2. 节点污点与 Pod 容忍度不匹配；3. PVC 未绑定（存储问题）
CrashLoopBackOff	容器反复启动后退出	1. 镜像错误 / 启动命令错误；2. 应用崩溃；3. LivenessProbe 失败；4. OOM（内存超出限制）
ImagePullBackOff / ErrImagePull	镜像拉取失败	1. 镜像名 / 标签错误；2. 私有仓库未配置 Secret；3. 节点无法访问镜像仓库
ContainerCreating	容器创建过程中卡住	1. 网络插件故障；2. 存储挂载失败；3. 镜像拉取超时
NotReady	Pod 未就绪，无法接收流量	1. ReadinessProbe 失败；2. 节点资源不足；3. 容器启动未完成

---

二、Deployment 资源对象详解

一、概述

Deployment 是 Kubernetes 中管理无状态应用的核心控制器，通过管理 ReplicaSet（副本集）实现 Pod 的声明式部署与生命周期管理，核心能力包括：

• 副本管理：确保指定数量的 Pod 副本正常运行
• 扩缩容：调整 Pod 副本数应对流量变化
• 滚动更新：无停机更新应用版本
• 版本回滚：更新失败时快速回退到历史版本
• 版本保留：保留历史更新记录，支持审计与回滚

适用场景：Web 服务、API 服务等无状态应用（无本地存储、任意副本可被替换）。

---

二、Deployment YAML 文件详解

Deployment 的 YAML 结构分为以下核心部分：

apiVersion: apps/v1       # API版本，Deployment属于apps/v1组
kind: Deployment          # 资源类型
metadata:
  name: nginx-deploy      # Deployment名称
  namespace: default      # 命名空间
  labels:
    app: nginx
spec:
  replicas: 3             # Pod副本数
  selector:               # 匹配Pod的标签，必须和template.metadata.labels一致
    matchLabels:
      app: nginx
  strategy:               # 更新策略配置
    type: RollingUpdate   # 可选RollingUpdate（默认）/Recreate
    rollingUpdate:
      maxSurge: 25%       # 更新时最多超出期望副本数的比例/数量
      maxUnavailable: 25% # 更新时最多不可用的副本比例/数量
  revisionHistoryLimit: 10 # 保留的历史版本数，默认10
  minReadySeconds: 5      # Pod就绪后等待多久视为可用，避免瞬态就绪
  template:               # Pod模板，定义Deployment管理的Pod
    metadata:
      labels:
        app: nginx        # 必须和spec.selector.matchLabels一致
    spec:
      containers:
      - name: nginx
        image: nginx:1.25 # 应用镜像
        ports:
        - containerPort: 80
        livenessProbe:    # 探针配置（同Pod探针）
          httpGet:
            path: /
            port: 80
        readinessProbe:
          httpGet:
            path: /
            port: 80

三、企业应用案例

3.1 环境准备

在企业中部署 Deployment 前，需完成以下准备：

1.命名空间隔离：创建独立命名空间，避免资源冲突：

kubectl create namespace prod

2.私有镜像仓库配置：若使用私有镜像，配置 ImagePullSecret：

kubectl create secret docker-registry regcred --docker-server=<仓库地址> --docker-username=<用户> --docker-password=<密码>

• 并在 Deployment 的 spec.template.spec 中添加imagePullSecrets: [{name: regcred}]。

3.资源限制配置：为 Pod 设置 requests 和 limits，避免节点资源被耗尽：

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

4.探针配置：配置 Liveness 和 Readiness 探针，保障应用可用性。

3.2 扩缩容操作

Deployment 支持手动扩缩容，两种方式：

1.命令行方式

# 扩展副本数到5
kubectl scale deployment nginx-deploy --replicas=5 -n prod

# 查看扩缩容状态
kubectl get deployment nginx-deploy -n prod

2.修改 YAML 方式：修改spec.replicas字段后执行kubectl apply -f deploy.yaml。

扩缩容原理：Deployment 通过控制 ReplicaSet 的副本数，实现 Pod 的增减，新增的 Pod 会自动配置 Service 标签，接收流量。

3.3 滚动更新

滚动更新是 Deployment 默认的更新策略，核心是逐步替换旧版本 Pod，同时保证服务不中断。

更新方式：

1.命令行更新镜像：

# 更新nginx镜像版本为1.26
kubectl set image deployment/nginx-deploy nginx=nginx:1.26 -n prod

2.修改 YAML 文件更新：修改spec.template.spec.containers[0].image字段后kubectl apply。

滚动更新流程：

1. 创建新的 ReplicaSet（版本 v2），副本数从 0 开始增加
2. 新 ReplicaSet 的 Pod 就绪后，旧 ReplicaSet（版本 v1）的副本数逐步减少
3. 过程中始终保证可用副本数≥期望副本数 *(1-maxUnavailable)，总副本数≤期望副本数 *(1+maxSurge)
4. 更新完成后，旧 ReplicaSet 的副本数降为 0，仅保留历史版本记录

查看更新状态：

# 查看更新进度
kubectl rollout status deployment/nginx-deploy -n prod

# 查看更新历史
kubectl rollout history deployment/nginx-deploy -n prod

3.4 版本回滚

当更新失败（如新版本应用异常）时，可快速回滚到历史版本：

1.回滚到上一个版本：

kubectl rollout undo deployment/nginx-deploy -n prod

2.

# 先查看历史版本号（REVISION列）
kubectl rollout history deployment/nginx-deploy -n prod
# 回滚到版本2
kubectl rollout undo deployment/nginx-deploy --to-revision=2 -n prod

原理：Deployment 会保留历史 ReplicaSet，回滚时将旧 ReplicaSet 的副本数恢复，同时减少新 ReplicaSet 的副本数，实现快速回退。

四、自定义更新策略

4.1 策略类型

Deployment 支持两种更新策略，核心差异如下：

表格

策略类型	说明	适用场景
RollingUpdate（默认）	逐步创建新 Pod、删除旧 Pod，服务不中断	绝大多数无状态 Web 应用
Recreate	先删除所有旧 Pod，再创建新 Pod，服务短暂中断	不支持多版本同时运行的应用（如需要独占资源的应用）

4.2 策略设置方式

在 Deployment 的spec.strategy字段中配置：

1.RollingUpdate 自定义配置：

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # 最多额外创建1个Pod（也可写百分比，如25%）
      maxUnavailable: 0   # 更新过程中无Pod不可用（保证服务高可用）

2.Recreate 策略配置：

spec:
  strategy:
    type: Recreate

4.3 配置案例

案例 1：高可用滚动更新（零 downtime）

适用于核心业务，保证更新过程中无服务中断：

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

效果：更新时最多创建 1 个额外 Pod，无旧 Pod 被删除，直到新 Pod 就绪，始终保持 3 个可用副本。

案例 2：单实例应用的 Recreate 更新

适用于单实例、不支持多版本同时运行的应用：

spec:
  replicas: 1
  strategy:
    type: Recreate

效果：更新时先删除旧 Pod，再创建新 Pod，会有短暂服务中断，但避免了多实例冲突的问题。

学习笔记总结

1. Pod 探针是保障容器可用性的关键：Liveness 解决 “死不死”，Readiness 解决 “能不能用”，合理配置可大幅提升服务稳定性。
2. Deployment 是无状态应用的最佳实践：通过声明式配置实现自动化的部署、更新与回滚，避免手动管理 Pod 的复杂度。
3. 更新策略需结合业务场景选择：核心业务用 RollingUpdate + 高可用配置，特殊场景用 Recreate 策略。
4. 排障核心是看事件与日志：kubectl describe和kubectl logs是定位 Pod/Deployment 故障的核心工具。