grpc在k8s上为什么无法负载均衡(转载)
在K8S上使用gRPC做负载均衡
作者:William Morgan (Buoyant)
译者:Anthony Han
许多gRPC的新用户会发现Kubernetes的默认负载平衡通常不能与gRPC一起使用。例如,我们来看一下将简单的gRPC Node.js微服务应用程序并部署在Kubernetes上会发生什么:
![](https://ask.qcloudimg.com/http-save/developer-news/pjbvht5pxb.jpeg?imageView2/2/w/1620)
从图中可知,虽然这个voting服务有好几个pod,但是观察CPU的使用情况可知实际上只有一个pod在工作,因为只有一个pod正在接收任何流量。那么为什么会这样呢?
接下去,在本篇博文中我们会介绍为什么会这样。以及如何通过向Linkerd的任何Kubernetes应用程序添加gRPC负载平衡来轻松修复它。
为什么gRPC需要特殊的负载平衡?
首先,让我们理解为什么我们需要为gRPC做一些特别的事情。
gRPC是目前应用程序开发人员日益普遍的选择。与诸如JSON-over-HTTP之类的替代协议相比,gRPC具有一些明显的优势:大大降低了(反)序列化成本,自动类型检查,标准化API以及更小的TCP管理开销。
但是,gRPC会打破标准的连接级负载平衡,包括Kubernetes提供的部分。这是因为gRPC是基于HTTP/2构建的,HTTP/2被设计为单个长连接。所有的请求是能够被多路复用的,同一时刻的多个请求能够使用同一个连接。通常情况下,这是非常有用的,能够减少连接管理的消耗。但是,因此连接级别的负载平衡不会有效。一旦建立连接,就不会再进行平衡操作。如下所示,所有的请求会被指向同一个目的端pod。
![](https://ask.qcloudimg.com/http-save/developer-news/gcrffw1nde.jpeg?imageView2/2/w/1620)
为什么这不会影响HTTP / 1.1
这个问题在HTTP/1.1中却并没有出现,HTTP/1.1也是具有长连接。这是因为HTTP/1.1是有连接循环的特点。因此。对于HTTP/1.1应用连接的负载平衡已经足够,不需要再进行其他额外的操作。
为了搞懂为什么会这样,我们来更深入的探究下HTTP/1.1。与HTTP / 2相比,HTTP / 1.1无法复用请求。在同一时刻同个TCP连接中,只有一个HTTP能够被处理。当客户端发起类似于GET /foo的请求时,它会一直等待到服务端的返回。在发起请求-响应周期时,不能在该连接上发出其他请求。
通常情况下,请求时在并发条件下大量产生的。因此,要拥有并发HTTP / 1.1请求,我们需要建立多个HTTP / 1.1连接,并在所有这些连接中发出请求。此外,长时间的HTTP / 1.1连接通常会在一段时间后过期,并被客户端(服务端)拆除。这两个因素相结合意味着HTTP / 1.1请求通常在多个TCP连接之间循环,因此连接级别平衡起作用。
那么我们如何对gRPC进行负载均衡?
现在回到gRPC。由于我们无法进行连接基本的负载平衡,为了进行gRPC负载均衡,我们需要从连接平衡转向请求平衡。换言之,我们需要建立到每个目标的HTTP / 2连接,并在这些连接之间平衡请求,如下所示:
![](https://ask.qcloudimg.com/http-save/developer-news/nocjk7yeym.jpeg?imageView2/2/w/1620)
用网络术语来说,这意味着我们需要在L5 / L7而不是L3 / L4做出决策,即我们需要了解通过TCP连接发送的协议。
我们如何做到这一点? 有几种选择。第一种,我们的应用程序代码可以自己管理维护自己的目标负载平衡池,并且配置我们的gRPC客户端以使用此负载平衡池。这种方法给了我们最大的控制权,但在像Kubernetes这样的环境中它的实现可能非常复杂,因为这个平衡池在一直变化比如pod发生迁移时。我们的应用程序必须监控Kubernetes API来保证相关的pod数据的同步。
第二种,在Kubernetes中我们可以以headless services形式部署我们的应用。在这种情况下,Kubernetes将在服务的DNS条目中创建多个A记录。如果我们的gRPC客户端足够先进,它可以自动维护这些DNS条目的负载平衡池。但是这种方法将限制我们只能使用某些特定gRPC客户端,并且我们一般也很少只使用headless services服务。
最后,我们可以采用第三种方法:使用轻量级代理。
使用Linkerd在Kubernetes上
进行gRPC负载平衡
Linkerd是Kubernetes的CNCF托管的服务网格项目。与我们的目的最相关的是,Linkerd还可以作为service sidecar,可以应用部署于单个服务中-即使没有集群侧的相关权限。这意味着当我们将Linkerd插入到我们的服务时,它会为每个pod添加一个微小的超快代理,这些代理会监听Kubernetes API并自动执行gRPC负载平衡。我们的模型如下所示:
![](https://ask.qcloudimg.com/http-save/developer-news/nocjk7yeym.jpeg?imageView2/2/w/1620)
使用Linkerd有几个优点。首先,它适用于使用任何语言编写的服务,任何gRPC客户端和任何服务部署模型。因为Linkerd的代理是完全透明的,所以它们会自动检测HTTP / 2和HTTP / 1.x并执行L7负载平衡,并且将其他所有流量作为纯TCP流量传递。这意味着所有流量都会起作用。
其次,Linkerd的负载平衡方式是非常智能灵活的。Linkerd不仅能够监听Kubernetes API来实时更新负载平衡池当pod发生重新迁移时,而且能够根据相关请求的响应速度选择响应速度最快的pod。如果一个pod的响应速度又变慢了,基本只是暂时的,Linkerd还是会将流量从它那移除出去。这能够减少端到端尾部延迟。
最后,Linkerd的Rust-based代理非常快且小巧。他们引入导致的延迟小于1ms,每个pod需要的RSS小于10mb,这意味着对系统性能的影响可以忽略不计。
gRPC负载平衡测试
Linkerd的测试非常容易。只需按照Linkerd入门说明中的步骤操作 - 在机器上安装相关客户端,在群集上安装控制平面,然后“网格化”您的服务(在每个pod中注入了相关代理)。当在拥有Linkerd的情况下运行服务时,并且能够看到每个pod的流量比较均衡,实现了良好的gRPC负载平衡。
让我们再次看看我们的样本voting服务,这次是在安装Linkerd之后:
![](https://ask.qcloudimg.com/http-save/developer-news/mm8d4z41lg.jpeg?imageView2/2/w/1620)
我们可以看到,所有pod的CPU图表都处于活动状态,表明所有pod正在占用流量,而我们无需更改一行代码。gRPC负载平衡好像是魔术一样神奇!
Linkerd还为我们提供了内置的流量级统计表,因此我们甚至不需要再通过CPU图表猜测发生了什么。这是一个Linkerd流量级统计图,显示了每个pod的成功率,请求量和延迟百分位数:
![](https://ask.qcloudimg.com/http-save/developer-news/xuh91rwtia.jpeg?imageView2/2/w/1620)
我们可以看到每个pod大约为5 RPS。我们还可以看到,虽然我们已经解决了负载平衡问题,但我们仍然需要做一些有关此服务成功率的工作(演示应用程序是故意失败的 - 作为读者的练习,看看你是否可以通过使用Linkerd仪表板来解决它!)
结束语
如果您对将gRPC负载平衡添加到Kubernetes服务的简单方法感兴趣,无论使用何种语言编写,使用的是哪种gRPC客户端,使用哪种方式部署它,都可以使用几个简单Linkerd的命令来实现gRPC负载平衡。
Linkerd还有很多其他功能,包括安全性,可靠性,调试和诊断功能,但这些都是未来博客文章的主题。
想了解更多? 我们很乐意让您加入我们快速发展的社区!Linkerd是一个CNCF项目,在GitHub上托管,在Slack,Twitter和邮件列表上拥有一个蓬勃发展的社区。