核心是编排系统原生探针机制实现自动化闭环：Startup Probe保障慢启动应用不被误杀，Liveness Probe失败触发自动重启防僵死，Readiness Probe失败则剔除流量但不重启容器，三类探针协同覆盖启动、运行、就绪全阶段。
服务编排实现容器运行状态的自动化健康巡检，核心是把“检查逻辑”嵌入调度系统，让平台能自己判断、决策、动作，而不是靠人盯着日志或执行命令。
健康巡检不是额外加个监控工具，而是编排系统原生支持的能力。主流方案（Kubernetes、Docker Swarm、Nomad）都通过探针（Probe）机制，在容器生命周期中主动介入，完成从探测到响应的闭环。
容器健康状态由三类探针协同定义
每种探针解决不同阶段的问题，配置后由编排系统自动执行：
Startup Probe（启动探针）
专为慢启动应用设计，比如数据库初始化、Java 应用加载大量类、Spring Boot 启动耗时超 30 秒。
它会先阻塞 liveness 和 readiness 检查，直到自身成功一次，再放行后续探针。
✅ 避免因启动未完成就被误杀或误导流。Liveness Probe（存活探针）
判断容器是否“活着且能恢复”，本质是防僵死。
比如进程卡在死锁、goroutine 全阻塞、HTTP 服务无响应但进程没退出。
❌ 失败 → 编排系统直接重启该容器（Pod / Task），不等人工干预。Readiness Probe（就绪探针）
判断容器是否“准备好收流量”，决定是否纳入服务发现。
比如依赖的 Redis 还没连上、配置中心未拉取、本地缓存未预热完成。
❌ 失败 → 立即从 Service 的 Endpoint 列表中剔除，新请求不再转发，但容器本身不重启。
示例（Kubernetes Deployment 片段）：
livenessProbe: httpGet: { path: "/healthz", port: 8080 } initialDelaySeconds: 45 periodSeconds: 10 timeoutSeconds: 3 failureThreshold: 3 readinessProbe: httpGet: { path: "/ready", port: 8080 } initialDelaySeconds: 5 periodSeconds: 5 timeoutSeconds: 2 startupProbe: httpGet: { path: "/startup", port: 8080 } periodSeconds: 10 failureThreshold: 30 # 给足时间，最多等 5 分钟
巡检动作完全自动化，无需脚本轮询
编排系统内建调度器会按配置周期执行探针，并实时更新实例状态：
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- Kubernetes 中，kubelet 负责执行探针，结果同步给 kube-proxy（控制流量）和 controller-manager（触发重启）；
- Docker Swarm 中，manager 节点监听 healthcheck 状态，自动从 ingress 网络中移除 unhealthy 服务副本；
- 所有平台都会将健康状态暴露在 API 和 CLI 中（如
kubectl get pods显示READY列，docker ps显示STATUS列含healthy）。
你不需要写定时任务、不用部署单独的巡检 Agent，只要声明好探针，系统就持续运行。
探针类型灵活适配不同服务场景
不必强求 HTTP 接口，根据服务特性选最轻量、最真实的检测方式：
HTTP GET：适合 Web 服务、API 服务
→ 检查/health返回 200，可进一步验证响应体含"status":"up"TCP Socket：适合无 HTTP 层的服务，如 MySQL、Redis、gRPC Server
→ 只需端口能连通，不关心业务逻辑，开销最低Exec 命令：适合容器内有诊断工具的场景
→ 如pg_isready -U appuser -d mydb检查 PostgreSQL 是否接受连接
→ 或curl -sf http://localhost:8080/actuator/health | grep '"status":"UP"'
关键原则：检测路径要真实反映服务可用性，避免只检查进程存在（ps aux | grep java 这类无效检测）。
配置要点防止误判和雪崩
健康检查不是越敏感越好，需平衡及时性与稳定性：
-
initialDelaySeconds/startPeriod要大于应用真实启动耗时，否则刚起来就被杀； -
timeoutSeconds必须小于periodSeconds，否则探测堆积； -
failureThreshold建议设为 3–5，容忍短暂抖动（如 GC 暂停、网络延迟）； - HTTP 探针避免调用重逻辑接口（如
/api/orders?limit=10000），应专用轻量 endpoint； - 数据库类服务建议在 readiness 中检查连接池可用性，而非仅 TCP 连通。
不复杂但容易忽略。
