一、Pod探针机制
1.1 探针类型对比
|--------------------------|--------------|-----------------------|-----------|
| 探针类型 | 核心作用 | 失败处理 | 适用场景 |
| Liveness Probe 存活探针 | 判定容器是否"活着" | Kubelet重启容器 | 检测死锁、进程假死 |
| Readiness Probe 就绪探针 | 判定容器是否"就绪" | 从Service Endpoint中 移除 | 控制流量分发 |
| Startup Probe 启动探针 | 判定容器是否"启动完成" | 容器被删除并重启 | 启动慢的应用 |
关键区别 ：
1.存活探针失败 → 重启容器
2.就绪探针失败 → 停止转发流量（Pod仍存在）
3.启动探针成功后，才会启用Liveness/Readiness探针
1.2 探针属性配置
bash
yaml
livenessProbe:
initialDelaySeconds: 30 # 初始化延迟（容器启动后多久开始探测）
periodSeconds: 10 # 探测周期，默认10秒
timeoutSeconds: 1 # 探测超时时间，默认1秒
failureThreshold: 3 # 从成功到失败的重试次数
successThreshold: 1 # 从失败到成功的重试次数参数说明：
1.initialDelaySeconds ：数据库等重载应用需合理设置，避免过早探测
2.failureThreshold ：存活探针最小值为1
3.successThreshold ：默认为1
1.3 探针测试案例
存活探针测试
bash
yaml
# exec方式：探测文件存在性
livenessProbe:
exec:
command:
- test
- -f
- /tmp/health现象：删除文件后，探针失败，Pod重启次数增加，容器被重建。
bash
yaml
# httpGet方式：探测HTTP端点
livenessProbe:
httpGet:
path: /healthz
port: 80现象：修改Nginx配置或移除页面文件，触发Pod重启。
就绪探针测试
bash
yaml
readinessProbe:
exec:
command:
- test
- -f
- /tmp/ready现象对比：
|----------|-----------|-----------------------|----------|
| 操作 | Pod状态 | Service Endpoints | 外部访问 |
| 删除文件 | Running | Pod IP被移除 | 失败 |
| 恢复文件 | Running | Pod IP重新加入 | 成功 |
重要结论：就绪探针失败不影响Pod间直接访问，只影响Service流量转发。
二、Pod状态排查
2.1 常用命令
|------------------------------------------|-----------------|
| 命令 | 用途 |
| kubectl run --dry-run=client -o yaml | 生成YAML模板 |
| kubectl get pods | 查看Pod状态 |
| kubectl describe pod <pod-name> | 查看详细信息（含Events） |
| kubectl logs <pod-name> | 查看容器日志 |
| kubectl exec -it <pod-name> -- /bin/sh | 进入容器 |
2.2常见异常状态
|----------------------|-------------------|---------------|
| 状态 | 含义 | 可能原因 |
| Pending | 调度未完成 | 无节点满足资源需求 |
| Succeeded | 所有容器正常终止 | Job任务完成 |
| Failed | 至少一个容器非正常终止 | 容器崩溃、OOM等 |
| Unknown | API Server与节点通信异常 | 网络故障、组件异常 |
| CrashLoopBackOff | 容器反复重启失败 | 探针配置错误、应用启动失败 |
2.3故障处理原则
生产环境故障处理流程 ：
1.首要任务 ：恢复业务（切换灾备、限流）
2.其次任务 ：排查根因
3.严禁越权操作，紧急情况需上报并留痕
三、Deployment控制器
3.1核心概念
Deployment → ReplicaSet → Pod
功能：
1.声明式定义
2.副本管理
3.滚动更新
4.版本回滚
5.扩缩容
3.2YAML结构
bash
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3 # 副本数
selector:
matchLabels: # 必须与template.labels一致
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14
volumes: # 定义在template.spec下
- name: data
emptyDir: {}注意： spec.selector.matchLabels 必须与 template.metadata.labels 一致，用于关联Pod模
板。
3.3滚动更新策略
bash
yaml
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25% # 更新过程中允许超出期望副本数的最大数量
maxUnavailable: 25% # 更新过程中允许不可用的最大副本数策略说明：
|----------------|-------------|-------------|
| 参数 | 作用 | 影响 |
| maxSurge | 允许额外创建的Pod数 | 值越大，更新越快 |
| maxUnavailable | 允许不可用的Pod数 | 值越小，更新越平滑稳定 |
约束 ：两者不能同时为0
1.maxUnavailable 向下取整
2.maxSurge 向上取整
3.4版本回滚操作
bash
bash
# 查看历史版本
kubectl rollout history deployment/nginx-deployment
# 回滚到上一版本
kubectl rollout undo deployment/nginx-deployment
# 回滚到指定版本
kubectl rollout undo deployment/nginx-deployment --to-revision=2
# 暂停/继续更新
kubectl rollout pause deployment/nginx-deployment
kubectl rollout resume deployment/nginx-deployment默认保留10个历史版本
四、架构对比
4.1无状态vs有状态
|----------|------------|-------------|
| 特性 | 无状态服务 | 有状态服务 |
| 控制器 | Deployment | StatefulSet |
| 启动顺序 | 无依赖 | 需特定顺序 |
| 存储需求 | 可共享 | 需独立持久化 |
| 网络标识 | 随机 | 固定 |
| 典型应用 | Web应用、API | 数据库主从、集群 |
4.2单体vs微服务
|-----------|----------|-------------------|
| 特性 | 单体架构 | 微服务架构 |
| 组件数量 | 少 | 多（网关、注册中心、监控、日志等） |
| 部署复杂度 | 简单 | 复杂 |
| 资源利用率 | 可能浪费 | 更灵活（结合k8s容器化编排） |
| 扩展性 | 整体扩展 | 独立扩展 |
关键记忆点：存活探针负责"活着"，就绪探针负责"干活"，启动探针负责"慢启动"