Ambassador 0.52 新特性:会话亲和性、负载均衡控制、gRPC-Web

3个月前

着力于将Ambassador打造成全球最棒的云原生API网关

本文由公众号EAWorld翻译发表,转载需注明出处。

作者:Richard Li

译者:白小白 
原文:https://blog.getambassador.io/session-affinity-load-balancing-controls-grpc-web-and-ambassador-0-52-2b916b396d0c


现时的云原生应用由多种异构的服务或者微服务组成,服务间、服务与客户端之间的通信需要跨越浩繁的通信协议和拓扑结构。Ambassador就是部署在这样不断增长的异构的工作负载环境之下,也因此我们对于这种境况有着直接的认知。

我们着力于将Ambassador打造成全球最棒的云原生API网关。为此,我们很兴奋可以发布Ambassador的0.52版本,并在新版中新增了如下的新能力:

  • 支持gRPC-Web协议。gRPC-Web基于原生的gRPC,其设计主旨服务于浏览器/服务器通信。在此要对 Gert van Dijk 和 Rotem Tamir 的工作表示感谢。
  • 支持先进的负载均衡控制。现在的Ambassador可以原生支持向物理IP地址的流量路由,而非DNS主机名称。
  • 支持会话亲和性(即粘滞会话)。Ambassador可以基于Cookie、HTTP头或者来源IP地址,将来自同一个终端用户的HTTP请求归集到一个特定的Kubernetes Pod里。

由于实施了一些架构迁移的工作,对会话亲和性和先进的负载均衡控制的支持还属于抢先版本状态,稍后将会介绍。

gRPC-Web支持

今时今日的云服务通过大批的通信协议进行暴露。Ambassador几乎支持流行的7层协议的每一层,包括HTTP,HTTP/2,gRPC,WebSocket,以及最新支持的gRPC-Web。并且,即使开发者所使用的协议并不被直接支持,Ambassador也支持原生的TCP路由方式。

gRPC-Web协议面向前端开发者提供了很多的便利:高性能,双向的流式通信以及广泛的类库支持。由于浏览器的限制 ,gRPC-Web并不与gRPC直接兼容。但可以设置服务端代理来解决在gRPC-Web请求和gRPC HTTP/2响应之间的翻译转换问题。

感谢Envoy对于gRPC-Web的支持,Ambassador现在可以通过设置enable_grpc_web: True 注解来支持gRPC-Web。需要注意的是,这是一个全局设定。

先进的负载均衡控制

Ambassador一直提供广泛的路由选项,可以基于主机、HTTP方法、HTTP头,可以采用正则表达式等等。我们知道,对路由施加灵活的细粒度的控制 对适应广泛的使用场景至关重要。但目前Ambassador仅为运维人员提供了有限的控制,来将请求路由到不同的endpoint。过去,Ambassador直接将请求路由到Kubernetes service,由后者将请求分发到不同的Pod。这种方案工作良好,便于推理和测试。对Kubernetes service的Curl请求遵循与Ambassador请求同样的路由路径。

Kubernetes网络

在一个典型的Kubernetes集群中,由kube-proxy路由Kubernetes service请求。稍显困扰的是,kube-proxy并不是典型形态的代理,只是基于iptables规则为service实现虚拟IP的一个进程。这种架构为路由带来了额外的复杂性:不仅引入了少量的延迟,而且iptables并不是为路由设计的,因此负载均衡策略受限于轮询的调度模型。

尽管存在实现的复杂性,这样的方案仍旧为Ambassador使用者提供了压倒性的优势:简便性。服务发现和负载均衡都交给Kubernetes解决,可以很直接的使用类似Curl这样的常规工具进行路由的测试。

Ambassador 0.52的负载均衡

在Ambassador 0.52版本中,我们引入了一套新的负载均衡控制机制。相关的控制选项是可选的,所以如果不做任何设置的变动,将以原本行之有效的方式来实施负载均衡控制。如果设置了AMBASSADOR_ENABLE_ENDPOINTS环境变量,将会启用新的控制机制:

  • Ambassador会监视所有Kubernetes endpoint的状态变更,而不仅仅关注Kubernetes service本身。
  • 有了这些状态信息,Ambassador可以基于设置来使用不同的负载均衡算法,绕过Kube-proxy将请求直接路由到Kubernetes endpoint。

以下的示例映射表展现了我们如何添加load_balancer注解:

apiVersion: ambassador/v1
kind: Mapping
name: qotm_mapping
prefix: /qotm/
service: qotm
load_balancer:
  policy: round_robin

需要注意的是,可以在Ambassador模块中添加注解,来使默认的负载均衡策略全局有效。

会话亲和性

除了默认的round_robin策略,Ambassador 0.52还可以基于ring_hash策略支持会话亲和性(即“粘滞会话”)。在此过程中需要为路由指定客户端的唯一标识。可以支持任意的HTTP头,Cookie或者实际的来源IP地址。

抢先版本

我们在0.52中将先进的负载均衡控制机制作为抢先版本发布,以进行更广泛的测试并收集反馈。我们尤其感兴趣的是,在不同的工作负载和Kubernetes集群环境下,启用这一特性有怎样的效果。我们希望 endpoint数多于service数,这样就可以对Kubernetes的API服务器产生持续增长的工作负载。我们热切的期待你的反馈,无论是积极的或者是负面的都可以,只要是关于这一特性的。

Ambassador 0.52版本的其他改变

在新版的Ambassador中,我们还提供了对大量的用户反馈Bug的修复,并提供了诸多的加强。

  • Ambassador现在支持HTTP/1.1请求和gRPC后端服务之间的桥接。
  • 在使用HTTP API的时候,为extauth过滤器添加了一个tracing header。(在使用gRPC API的时候,已经添加了这样的tracing header)
  • 允许extauth建立原本不存在的header(#1313)。
  • 可以使用Lua过滤器,在映射中嵌入简单的脚本。鸣谢Liam Costello的贡献。
  • 启动性能改进。
  • 使用C YAML解析器代替Python实现以改进解析性能(#1294,#1318)
  • 加入xff_num_trusted_hops设置。如果用户使用了如CloudFlare这样的CDN服务,并且依赖X-Forwarded-For header来应对流量限速的使用场景,提供这样的设置将十分重要。

更新的核心设置文档覆盖了上面提到的新的选项(如Lua,gRPC HTTP/1.1 桥接等)。

即将到来的0.60中的重大变更

Ambassador 0.60将默认在8080端口侦听明文HTTP请求(取代原来的80端口),在8443端口侦听HTTPS请求(取代原来的443端口),以便在没有Root权限的情况下简化Ambassador的运行。如果你的现存服务依赖上述默认端口,需要修改相关的配置文件,Ambassador 0.52会在诊断服务中提出警报。

安装Ambassador 0.52

可以通过下面的Docker标签获得Ambassador 0.52版本:quay.io/datawire/ambassador:0.52.0 。通过标签更新现有的部署清单,kubectl会将0.52版本安装到集群中。

也可以通过Helm安装:

helm install stable/ambassador

升级到Ambassador 0.52

Ambassador的更新依赖Kubernetes的部署。在更新Ambassador之前,需要将Kubernetes部署清单指向 quay.io/datawire/ambassador:0.52.0 然后基于更新后的清单运行kubectl。Kubernetes会以滚动更新的方式将Ambassador更新到0.52版本。

后续

如果你在更新过程中遇到任何问题,可以发issue或者加入我们的Slack求助。

提交Issue的地址:https://github.com/datawire/ambassador/ 
加入Slack的地址:http://d6e.co/slack

如果Ambassador工作良好,我们也很乐于得到这样的消息。可以在文末或者在我们的推特账号@getambassadorio留言。


关于EAWorld:微服务,DevOps,数据治理,移动架构原创技术分享,长按二维码关注

COMMENTS

需要 后方可回复
如果没有账号可以 一个帐号。