kube-proxy的可伸缩性

Question

我在试用kubernetes集群时遇到了一个可伸缩性问题。为了简化我的测试机器中的拓扑结构，使用NodePort类型向外部公开单个服务。承载节点和主节点的裸机是具有24个cpu和32G RAM的RHEL 7;我还没有专门的负载平衡器，或者像基础设施这样的云提供商。服务定义的片段如下所示

    "spec": {       
         "ports": [{
             "port": 10443,             
             "targetPort": 10443,               
             "protocol": "TCP",                                
             "nodePort": 30443
    } ],
   "type": "NodePort",

通过这种方式，应用程序可以通过https://[node_machine]:30443/[a_service]

访问

此服务仅由一个Pod支持。理想情况下，我希望在同一节点上部署多个服务(但使用不同的NodePort)，并且并发运行。

一切都运行得很好，直到很明显，对于类似的工作负载，增加部署的服务数量(因此也增加了后端pod)会降低应用程序的性能。令人惊讶的是，当分解服务加载时间时，我注意到"连接时间"有明显的下降，这似乎表明"网络"层的某个地方出现了减速。请注意，负载还没有高到足以驱动节点上的大部分CPU。我阅读了文档中的缺点，但不确定我遇到的是否正是文档中描述的kube-proxy/Service的限制。

问题是:

1. 关于如何使其更具可扩展性有任何建议吗?也就是说，能够在不影响应用程序性能的情况下支持更多的服务/pod ?NodePort类型是为我们的服务设置"公共"地址的最简单的方法，但是如果所有的服务和pod都以这种方式设置，是否会对可伸缩性或性能有任何限制?

2. 如果我们将类型更改为LoadBalancer，会有任何差异吗?"类型":"loadbalance"

3. 此外，是否有一个专用的LoadBalancer或反向代理来提高可扩展性，例如HAProxy或类似的，路由流量从外部到后端pod(或服务)的好处?我注意到有一些工作是为Nginx darkaro/kubernetes-reverseproxy做的——不幸的是文档似乎不完整，没有具体的例子。在其他一些线程中，人们讨论了Vulcan——它是kubernetes推荐的LB工具吗?

非常感谢您的推荐和帮助!

Answer 1

你好，我是kubernetes的新手，但我有类似的问题和担忧。将尝试回答其中的一些问题或将您重定向到用户指南的相关部分。

如果你将Kubernetes部署在非云服务提供商上，例如vagrant/local等，那么一些功能目前还没有提供或由平台自动提供。

其中之一是'LoadBalancer'类型的服务。公共IP到服务的自动配置和分配(充当lb)目前只发生在像Google Container引擎这样的平台上。

见这里和这里的问题。

官方文档说明

在支持外部负载平衡器的云提供商上，设置类型字段"LoadBalancer"将为您的服务。

目前正在开发和记录一个替代方案，请参阅此处使用HAProxy。

也许在不久的将来，kubernetes最终会在所有可用的平台上支持这种功能，所以要经常检查他们的更新功能。

你所说的性能下降很可能是由于PublicIP(从1.0版本起的NodePort)功能正在工作。这意味着通过使用NodePort服务类型，kubernetes在集群的所有节点上为这种服务分配一个端口。然后，kube-proxy会拦截对该端口的实际服务等的调用。

在这里可以找到一个使用HaProxy试图解决相同问题的例子。

希望对你有帮助。

Answer 2

我也面临同样的问题。内部kube-proxy似乎不打算充当外部负载平衡器。更具体地说，我们希望在kube-proxy上设置一些超时或重新尝试等。

我找到了一篇描述类似问题的文章。他建议看看vulcan，因为它内部使用了etcd，这个项目的方向可能是在未来为k8提供功能齐全的LB。