探针(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 与配额配置合理;启动与终止行为符合真实流量模式。
实战补充
把快速入门应用到真实业务时,建议固定一套检查项:资源 requests、就绪探针、日志覆盖、告警阈值、回滚步骤。清单要短小、可重复,并随仓库一起维护,这样每次发布都能快速对齐标准。
排障路径
从现象入手,不要先猜原因。先看事件,再看日志,最后验证流量路径和配置版本是否一致。若访问异常,先确认 readiness 和 endpoints,再逐段排查入口到后端的链路。记录每一步改动,方便回滚和复盘。
小练习
在测试环境做几次常见操作:扩缩容、重启单个 Pod、调整一项配置并验证效果。通过这些小练习,你能更直观地感受到系统收敛速度和异常时的行为。
维护与责任
明确服务归属、值班人和升级窗口,准备常见故障的处理步骤。依赖服务也需要纳入监控和备份计划,确保问题出现时能快速定位和恢复。
交付提醒
发布后用用户视角快速验证一次:访问核心接口、观察延迟和错误率,确认新旧 Pod 的状态稳定。如果涉及存储或网络,顺手核对磁盘用量、DNS 和 endpoints 是否正常。
回滚预案
写下最小可行的回滚步骤,包括需要恢复的配置、镜像版本和校验方式。这样在出现异常时可以迅速还原,而不是现场临时拼步骤。