0

我有一个带有ipvskube-proxy 模式的 k8s 集群和一个 k8s 之外的数据库集群。

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

---
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 连接。在 pod 正在运行的节点（以下称为工作节点）上，我看到了下一个已建立的连接：

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

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

然后我监视工作节点上已建立的连接。大约 5 分钟后，与数据库节点的已建立连接丢失。

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

如何ipvs决定放弃已建立的连接？如果ipvs断开连接，为什么它不能正确完成 TCP 连接？这是一个错误还是我误解了ipvskube-proxy 中的模式？

4

1 回答 1

1

Kube-proxy 和 Kubernetes 无助于平衡持久连接。

这篇文章很好地描述了 Kubernetes 中长寿命连接的整个概念：

Kubernetes 不会对长期连接进行负载平衡，并且某些 Pod 可能会收到比其他 Pod 更多的请求。如果您使用 HTTP/2、gRPC、RSockets、AMQP 或任何其他长期连接（例如数据库连接），您可能需要考虑客户端负载平衡。

我建议通过整个事情，但总的来说可以总结为：

  • Kubernetes 服务旨在涵盖 Web 应用程序的最常见用途。

  • 但是，一旦您开始使用使用持久 TCP 连接的应用程序协议，例如数据库、gRPC 或 WebSocket，它们就会分崩离析。

  • Kubernetes 不提供任何内置机制来负载平衡长期 TCP 连接。

  • 相反，您应该对应用程序进行编码，以便它可以在上游客户端检索和负载平衡。

于 2020-12-04T10:17:30.417 回答