具有IPVS模式的Kube-代理不保持连接。

Question

我有一个k8s集群，它具有ipvs kube模式，还有一个k8s之外的数据库集群。

为了访问DB集群，我创建了服务和端点资源：

---
apiVersion: v1
kind: Service
metadata:
  name: database
spec:
  type: ClusterIP
  ports:
  - protocol: TCP
    port: 3306
    targetPort: 3306

---
apiVersion: v1
kind: Endpoints
metadata:
  name: database
subsets:
- addresses:
  - ip: 192.168.255.9
  - ip: 192.168.189.76
  ports:
  - port: 3306
    protocol: TCP

然后我使用MySQL客户端运行一个pod，并尝试连接到这个服务：

mysql -u root -p password -h database

在网络转储中，我看到成功的TCP握手和成功的MySQL连接。在结荚运行的节点(下称工人节点)上，我看到了下一个已建立的连接：

sudo netstat-nat -n | grep 3306
tcp   10.0.198.178:52642             192.168.189.76:3306            ESTABLISHED

然后，在打开的MySQL会话中，我从pod发送一些测试查询。它们都被发送到同一个节点。这是预期的行为。

然后，我监视在worker节点上建立的连接。大约5分钟后，就会丢失到数据库节点的已建立的连接。

但是在网络转储中，我看到TCP终结包没有从worker节点发送到数据库节点。因此，我在数据库节点上得到了一个泄漏的连接。

ipvs如何决定放弃已建立的连接？如果ipvs删除了一个连接，为什么它不能正确地完成TCP连接？是一个bug，还是我误解了kube中的ipvs模式？

Answer 1

Kubernetes和Kubernetes无助于平衡持久的连接。

库伯奈特长寿命连接的整个概念在这篇文章中有很好的描述。

Kubernetes不负载平衡长寿命的连接，一些Pods可能会收到比其他更多的请求。如果您使用的是HTTP/2、gRPC、RSockets、AMQP或其他任何长期存在的连接(例如数据库连接)，则可能需要考虑客户端负载平衡。

我建议把整件事看一遍，但总的来说，可以用以下几个词来概括：

• Kubernetes服务旨在涵盖web应用程序的大多数常见用途。
• 但是，一旦您开始使用使用持久TCP连接(如数据库、gRPC或WebSockets )的应用程序协议，它们就会崩溃。
• Kubernetes不提供任何内置机制来负载平衡长期存在的TCP连接。
• 相反，您应该为您的应用程序编写代码，以便它能够检索并负载上游客户端的负载平衡。