timeoutSeconds控制单次探针请求的超时时间（秒），超时即判失败：liveness失败触发重启，readiness失败导致流量摘除，startup失败则阻断其他探针；需与periodSeconds、failureThreshold等协同配置，典型值为2–5秒，避免过短引发误判。

Pod 探针超时时间由 timeoutSeconds 字段控制，它定义单次探测请求等待响应的最长时间（单位：秒）。超时不是“总等待时间”，而是每次发起探测（HTTP、TCP 或 exec）后，kubelet 等待结果返回的上限。一旦超时，该次探测即判为失败。

关键字段说明

timeoutSeconds 必须配合其他探针参数使用，单独设置无效。它影响的是单次探测行为，常见于以下三种探针：

• Liveness Probe：超时失败 → kubelet 杀死容器并重启
• Readiness Probe：超时失败 → Pod 从 Service Endpoint 中摘除，不再接收流量
• Startup Probe：超时失败 → 阻止 liveness/readiness 启动，避免应用未就绪就被误杀

如何正确配置 timeoutSeconds

不能孤立设定，需与 initialDelaySeconds、periodSeconds 和 failureThreshold 协同计算实际容忍窗口。例如：

• 若 timeoutSeconds: 2、periodSeconds: 10、failureThreshold: 3，则连续三次探测都必须在 2 秒内返回，否则第 3 次失败后触发动作
• 启动慢的服务（如 Java 应用），建议将 timeoutSeconds 设为 3–5 秒，避免因 GC 或类加载延迟导致误判
• 高并发场景下，健康接口可能偶发延迟，timeoutSeconds 不宜低于 2 秒，否则易引发雪崩式重启

典型配置示例（HTTP 方式）

以下片段嵌入容器定义中即可生效：

Kubernetes RBAC Audit

审计 Kubernetes 集群 RBAC 配置，识别过度宽松的角色、通配符权限、危险的 ClusterRoleBinding 及服务账号滥用

下载

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 60
  periodSeconds: 10
  timeoutSeconds: 3
  failureThreshold: 3
readinessProbe:
  httpGet:
    path: /readyz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 2

注意：/healthz 和 /readyz 是隔离的专用端点，不走业务逻辑，确保探测轻量且稳定。

避坑要点

生产环境常见错误包括：

• 把 timeoutSeconds 设为 1 秒——多数服务在压测或冷启动时无法稳定达标
• 未配 startupProbe 却对慢启动服务设短 initialDelaySeconds，导致容器刚启动就被 liveness 杀掉
• HTTP 探针返回 429（限流）仍判定为 success，应结合 httpGet.httpHeaders 或后端逻辑区分状态码语义
• TCP 探针仅检测端口通断，无法反映应用真实就绪状态，建议优先用 HTTP 或 gRPC 探针