探针(Probe)
让 Kubernetes 知道应用何时可用或需要重启。
探针决定 Pod 是否接流量，以及进程是否需要重启。
三类探针
- readiness：是否可接流量
- liveness：是否需要重启
- startup：启动期保护
示例
readinessProbe:
httpGet:
path: /readyz
port: 8080
periodSeconds: 5
livenessProbe:
httpGet:
path: /livez
port: 8080
periodSeconds: 10
常见坑
- 用 liveness 当“流量开关”
- timeout 太小导致误判
实操要点
- 先做快速盘点：
kubectl get nodes、kubectl get pods -A、kubectl get events -A。 - 对比“期望状态”和“实际状态”，
kubectl describe往往能解释漂移或失败原因。 - 名称、Label、Selector 要一致，避免 Service 或控制器找不到 Pod。
快速检查清单
- 资源定义与业务意图一致。
- Namespace、权限、镜像与环境匹配。
- 上线前具备健康探针与可观测日志。
探针 的工作负载视角
无论是 Pod、探针还是 Namespace，它们都在帮助工作负载变得可预测。探针 负责把业务意图映射成可运行的单元，并保障生命周期、调度与隔离的稳定性。理解这一层后，后续排障会更有方向。
标签、选择器与归属关系
标签是资源的索引，选择器是控制器和 Service 发现目标的方式。建议统一使用 app、component、env 等标签键。归属关系决定资源的重建逻辑，没有清晰标签和 ownerReferences，排障和清理都会变得困难。
调度与资源请求
调度器依赖 requests 来分配资源。缺少 requests 会导致调度不公平，容易过载。小服务可以先给保守请求，再基于监控调整。Namespace 层面的 ResourceQuota 和 LimitRange 则是约束规则的载体。
启动、就绪与终止
探针应该反映“可用性”，而不是仅仅“进程活着”。readiness 控制流量入口，liveness 需要更宽松避免重启风暴。终止阶段也很关键，设置合理的 terminationGracePeriodSeconds，并处理 SIGTERM，让服务能优雅退出。
隔离与安全基础
Namespace 只负责组织资源，真正的隔离需要配合 RBAC、NetworkPolicy 和安全上下文。像 runAsNonRoot、readOnlyRootFilesystem、capabilities 限制都能显著降低风险。需要提升权限时要说明理由并最小化范围。
资源隔离与噪声邻居
CPU 限额过低会导致节流，内存限额过低会触发 OOM。延迟敏感服务建议设置合理 requests 并留出余量，批处理作业则通过 limits 保护核心业务。
配置与密钥管理
ConfigMap 和 Secret 应作为工作负载契约的一部分。要明确配置变更是触发滚动更新还是热加载，并用 RBAC 控制访问范围。跨环境推广时要保持配置版本一致。
排障流程
推荐固定排障路径：先 describe 看事件，再看日志，必要时进入容器确认探针或依赖是否可用。Namespace 或配额问题时，检查 ResourceQuota 与 LimitRange 能快速定位原因。
kubectl get pods -n demo
kubectl describe pod demo-app -n demo
kubectl logs demo-app -n demo --tail=200
kubectl exec -it demo-app -n demo -- sh
可观测信号
事件说明调度失败或拉取失败，日志解释业务行为，指标显示趋势与瓶颈。三者结合能减少盲目猜测，提高排障效率。
稳定性检查清单
确认每个工作负载有标签、requests 和探针；Service 能找到 Pod；Namespace 的 RBAC 与配额配置合理；启动与终止行为符合真实流量模式。
收个尾：探针写得“聪明”，经常意味着更容易误杀
探针的目标很简单：别让坏实例接流量，别让卡死的进程一直霸着资源。
但很多线上事故其实是探针写得太激进：服务启动慢一点、依赖抖一下，readiness 反复失败导致 endpoints 抖；liveness 更夸张，直接把服务重启风暴打出来。
我的经验是：
- readiness 先保守一点，让它反映“真的能接请求”
- liveness 慎用，除非你非常确定“假死比重启更糟”
- 启动慢的服务优先考虑 startupProbe，避免刚启动就被误杀