【问题标题】：How Kubernetes TCP Probe handle the fact that TCP handshake is manage by the OS?Kubernetes TCP Probe 如何处理 TCP 握手由操作系统管理的事实？
【发布时间】：2021-07-10 16:50:19
【问题描述】：

文档说，我对如何使用 Kubernetes 处理 TCP 探测有点困惑：

第三种活动探测使用 TCP 套接字。有了这个配置，kubelet 将尝试打开一个套接字到您的指定端口上的容器。如果它可以建立连接，则容器被认为是健康的，如果它不能被认为是失败。

但据我所知，套接字客户端在服务器对套接字执行accept 之前已连接。这个 TCP 握手是由操作系统管理的……那么 Kubernetes 是如何“知道”套接字的状态的呢？

为了提供一点上下文，我正在尝试在我的应用程序 (C++) 中编写一个单元测试，但我不知道 K8s 如何处理这个问题，但在 k8s 中它确实可以按预期工作（我的意思是，如果我不这样做接受连接，它将把我的容器声明为不活动）。

感谢您的时间和考虑！

编辑 1

抱歉@Steffen Ullrich，这需要我一些时间，但这里有一个代码示例：https://github.com/quentingodeau/k8s-probe

然后我得到的痕迹：

$ kubectl logs -f $(kubectl get pods | egrep -o 'sample-deployment-[^ ]*')
[2021-07-10 18:46:22.837] [info] Server acccept the client...
[2021-07-10 18:46:23.838] [info] Server acccept the client...
[2021-07-10 18:46:24.840] [info] Server acccept the client...
[2021-07-10 18:46:25.837] [info] Server acccept the client...
[2021-07-10 18:46:26.836] [info] Server acccept the client...
[2021-07-10 18:46:27.839] [info] Server acccept the client...
[2021-07-10 18:46:28.840] [info] Server acccept the client...
[2021-07-10 18:46:29.836] [info] Server acccept the client...
[2021-07-10 18:46:30.843] [info] Server acccept the client...
[2021-07-10 18:46:31.028] [info] Send SIGUSR1
[2021-07-10 18:46:31.836] [info] Server acccept the client...
[2021-07-10 18:46:31.836] [info] Start to not procssing incoming connection
[2021-07-10 18:46:35.855] [info] End of application (signal=15)

编辑 2

https://github.com/kubernetes/kubernetes/issues/103632

【问题讨论】：

标签： sockets kubernetes

【解决方案1】：

但据我所知，套接字客户端在服务器对套接字执行接受之前已连接

虽然在调用accept 之前可能会在操作系统中建立连接，但它只有在调用套接字上的listen 之后才建立。如果应用程序没有运行（无法启动、崩溃），那么就没有监听套接字，因此任何与它的连接都会失败。如果由于应用程序未能及时处理新连接而导致侦听队列已满，则连接也会失败。

这种廉价的探测在许多情况下就足够了，但它肯定不能处理所有情况，例如确保应用程序正确响应并在预期时间内响应。如果需要进行此类检查，则需要进行更精细的探测，甚至可能需要进行特定于应用程序的探测。

【讨论】：

谢谢，但事实上我认为 k8s 比这更精确。我有一个应用程序： * 创建一个服务器套接字（挂起队列设置为一个） * 然后应用程序通过执行等待：while(signal != SIGUSR1) { accept(s); } * 当接收到 SIGUSR1 时应用程序执行 while(signal != SIGTERM) { sleep(200ms); } 我看到 k8s 正在杀死（SIGTERM）我发送 SIGUSR1 后的申请...
@Quentin：我怀疑 k8s 做的比我描述的要多。我不确定您仅根据此简短评论所看到的内容。请为您的测试程序提供完整的代码，包括运行的输出，该输出用时间戳显示正在发生的事情。理想情况下还提供一个并行 tcpdump 来显示由探测引起的网络流量。
我直接编辑帖子无法回复超过字数限制^^
@Quentin：谢谢。根据您的输出，在停止接受连接和被杀死之间有 4 秒的时间。看起来每秒钟之前都发生了连接。这意味着在 4 秒内尝试了至少 3 个连接而没有在应用程序内部被接受。鉴于您的侦听队列很小，因此会发生这种情况，我在回答中描述的是：“如果 侦听队列已满，因为应用程序无法及时处理新连接，那么连接也会失败。”
好的，这部分我明白，但我不明白的是 kubernetes 描述了它的 TCP 探测 If it can establish a connection, the container is considered healthy, if it can't it is considered a failure.。在我的理解中，这意味着它将打开一个连接并关闭它。那么它如何达到最大挂起队列呢？（也在我的代码中，这个队列设置为 1，所以在更糟糕的情况下，我会得到 3 秒延迟，不是吗？）