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

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

作者：Richard Li

译者：白小白

原文：http://t.cn/E6cZoyG

现时的云原生应用由多种异构的服务或者微服务组成，服务间、服务与客户端之间的通信需要跨越浩繁的通信协议和拓扑结构。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

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

会话亲和性

除了默认的round_robin策略，Ambassador 0.52还可以基于ringhash策略支持会话亲和性（即“粘滞会话”）。在此过程中需要为路由指定客户端的唯一标识。可以支持任意的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求助。