Kubernetes readinessProbe tcpSocket探测成本及低延迟配置咨询

一、TCP Socket 探测的成本情况 #

其实TCP探针在K8s的几种探针类型里算是轻量级选手，成本非常低，主要可以从这几个维度来看：

• 网络开销：每次探测就是完成一次TCP三次握手然后断开，整个过程只有几个小数据包，对集群网络带宽的消耗几乎可以忽略。除非你有上万个Pod同时以1秒间隔探测，才可能产生一点点可观测的流量，但绝大多数场景下完全不用在意。
• 目标Pod资源消耗：对被探测的Pod来说，只是处理一个TCP连接请求，没有数据传输，应用进程几乎不需要额外的CPU或内存开销——除非你的应用对每个新连接都有很重的初始化逻辑（这属于应用自身设计问题，和探针无关）。
• Kubelet侧开销：节点上的kubelet负责执行探针，TCP探测的逻辑极其简单，不需要解析HTTP请求、处理响应内容这些操作，所以对kubelet的CPU和内存占用远低于HTTP探针，完全不会成为节点的性能瓶颈。

二、设置最小1秒探测延迟的配置方法 #

你说的“探测延迟”应该指的是探针的探测间隔（periodSeconds），要把它设为1秒的最小值，直接在Pod的readinessProbe配置里调整参数即可。K8s没有强制限制这个参数的最小值，1秒是完全合法的配置，不过要结合实际场景评估：更频繁的探测能更快发现服务就绪状态变化，但也会带来刚才提到的微小成本提升。

下面是完整的配置示例，你可以直接参考修改：

apiVersion: v1
kind: Pod
metadata:
  name: your-target-pod
spec:
  containers:
  - name: your-app-container
    image: your-app-image:tag
    ports:
    - containerPort: 8080  # 你的应用监听端口
    readinessProbe:
      tcpSocket:
        port: 8080  # 要监控的目标端口
      initialDelaySeconds: 5  # 容器启动后多久开始第一次探测，根据你的应用启动时间调整，别设太小
      periodSeconds: 1  # 核心参数：设置为1秒，即每秒探测一次
      timeoutSeconds: 1  # 探测超时时间，建议同步设小，避免不必要的等待
      failureThreshold: 2  # 连续失败2次就标记Pod未就绪，按需调整
      successThreshold: 1  # 成功1次就恢复就绪状态

额外注意事项：

• initialDelaySeconds一定要根据你的应用启动时间合理设置，如果设得太小，应用还没完成初始化就被探针反复探测，会导致Pod长时间处于未就绪状态，影响服务上线。
• 如果你的集群有大量Pod都配置了1秒间隔的TCP探针，可以偶尔监控下kubelet的CPU使用率和节点网络流量，确保没有异常波动（一般来说完全没问题，但极端场景下可以留个心眼）。

内容的提问来源于stack exchange，提问作者JRomio