做校园文化的网站,室内设计动态效果图制作,新网站如何做网站优化,做海淘网站赚钱吗Ambassador是由Datawire开源的一个API网关项目#xff0c;主要在Kubernetes的容器编排框架中使用。Ambassador本质上是一个通过配置边缘/API来管理Envoy数据面板的控制面板。而Envoy则是一个基于第7层协议的网络代理和通信总线#xff0c;它是一个由Lyft开源的云原生服务主要在Kubernetes的容器编排框架中使用。Ambassador本质上是一个通过配置边缘/API来管理Envoy数据面板的控制面板。而Envoy则是一个基于第7层协议的网络代理和通信总线它是一个由Lyft开源的云原生服务主要用于处理入口边缘以及内部服务之间的网络通信。今天Envoy正迅速成为现代网络事实上的代理几乎所有的公共云供应商以及eBay、Pinterest和Groupon等大型互联网公司都提供对这种代理服务的支持。本文首先介绍了Ambassador的由来然后详细介绍了它的发展过程并讨论了开发人员在构建这个控制面板时遇到的技术挑战和经验教训该面板用于在Kubernetes集群里管理微服务应用的入口流量入口边缘。本文要点
Ambassador是由Datawire开源的一个API网关主要在Kubernetes容器编排框架中使用。Ambassador本质上是一个通过配置边缘/API来管理Envoy代理数据面板的控制面板。Envoy是一个处理边缘入口和内部服务之间网络通信的L7代理和通信总线。本文介绍了Ambassador的由来然后详细介绍了它的发展过程并讨论了开发人员在构建这个控制面板时遇到的技术挑战和经验教训该面板用于管理部署到Kubernetes集群中的基于微服务的应用程序中的入口流量。将Ambassador迁移到Envoyv2配置和ADS(聚合发现服务) API是一个漫长而艰难的过程需要大量的架构和设计讨论以及大量的编码但是社区的早期反馈是积极的。
Ambassador是由Datawire开源的一个API网关项目主要在Kubernetes的容器编排框架中使用。Ambassador本质上是一个通过配置边缘/API来管理Envoy数据面板的控制面板。而Envoy则是一个基于第7层协议的网络代理和通信总线它是一个由Lyft开源的云原生服务主要用于处理入口边缘以及内部服务之间的网络通信。今天Envoy正迅速成为现代网络事实上的代理几乎所有的公有云供应商以及eBay、Pinterest和Groupon等大型互联网公司都提供对这种代理服务的支持。
本文首先介绍了Ambassador的由来然后详细介绍了它的发展过程并讨论了开发人员在构建这个控制面板时遇到的技术挑战和经验教训该面板主要用于在Kubernetes集群里管理微服务应用的入口流量。
云原生新兴组合: Kubernetes与Envoy
像DevOps和微服务一样云原生也开始变得耳熟能详并在整个IT行业中不断获得关注。据Gartner报道2018年全球公共云服务收入预计在1750亿美元左右而明年仍将有超过15%的增长。目前的公有云市场完全由几家大公司垄断而这几家公司也几乎把持了所有的关键技术这让开源即服务的商业前景变得很不明朗。在这样的背景下Linux基金会于2015年成立了CNCF云原生计算基金会)旨在讨论和托管全栈云原生环境中的开源组件。
CNCF吸取了Open Stack社区的经验教训在早期项目发展中相对保守和严格它甚至为项目提供了发展概要并要求项目有实际的应用案例或者项目本身是基于已流行项目如Kubernetes的扩展。Google提供的Kubernetes容器编排框架以及Lyft提供的边缘路由器Envoy代理是CNCF早期的两个主要项目。虽然平台即服务(Platform-as-a-ServicePaaS)架构复杂且各不相同 但Kubernetes和Envoy一直是其核心组成。
许多PaaS供应商甚至最终用户的技术团队都将针对网络第7层元数据的编排容器和通信路由视为云原生系统的数据面板比如HTTP URI、Headers以及MongoDB协议元数据。因此更多的初创公司则把重心放在如何创建一个有效的\u0026quot;控制面板\u0026quot;上例如帮助终端用户实现与数据面板的交互配置数据面板的自定义参数观察数据面板中的监测或日志等。
Kubernetes控制面板一般都采用了类似REST的API(又称\u0026quot;Kubernetes API\u0026quot;)像‘kubectl‘这样的CLI工具都是对此类API的二次封装。首版Envoy的控制面板主要使用了JSON的配置方式还有一些可以选择性更新的松耦合API。随后这些API又变成了Envoy v2 API的一部分新版Envoy同时提供了一系列基于gRPC的协议缓冲类型API。最初Kubernetes的kubectl工具并没有提供一种类似Envoy的实现这给后来使用Kubernetes的团队制造了不少麻烦。当然很多关于实现Envoy V2控制面板的初创公司也因此出现。
服务网格 VS API网关
谈到网络中的控制面板自然就少不了新兴的服务网格技术。诸如lstio、Linkerd和Conser connect之类的服务网格主要在微服务系统中管理服务之间的通信也就是所谓的“东-西”方向通信。lstio本身是一个非常有效的控制面板它通过Envoy代理来管理网格之间的数据面板L7网络流量Rust语言编写的Linkerd实现了自己的代理而Conser Connect则使用了自定义代理最近也提供了对Envoy代理的支持。Istio架构上半部分为Envoy代理的数据面板下半部分为控制面板(图片来自Istio文档)服务网格需要事先假定用户对网格通信的双方具有高度的所有权和可控制度。例如同一个公司的不同工程部门的两个服务或者是一个可信任网络边界内的第三方应用程序服务(可能跨越多个数据中心或虚拟专有云)。在这里运维团队通常会设置一些符合常理的通信缺省值而服务团队则在此基础上配置各自服务间的路由。在这种情况下你不可能完全信任每个服务因此要实施如速率限制和断路等保护以此来调查和改变所检测到的不良行为但是服务网格根本不可能实现这类保护因为边缘或入口(“南-北”)流量来自外界网络超出了其控制范畴。集群入口流量通常来自不可控的外部网络任何来自我们信任的网络之外的通信都可能来自一个心怀不轨的的第三方他的动机可能就是网络罪犯或破坏移动应用程序中的客户端库因此我们必须对边缘/API网关部署适当的防御措施。在这里运维团队将指定一些系统默认值并根据外部事件实时调整这些值。你可能希望能够实现速率限制、全局配置和指定API负载例如后端服务或数据集过载以及DDoS保护实现等(基于时间或区域的保护)。另外服务开发团队的一些任务也需要访问为新API配置路由的边缘通过流量跟踪或金丝雀发布来测试和发布新服务。
顺便说一句为了进一步讨论API网关的角色Christian Posta最近发表了一篇有趣的博文“API网关正在经历身份危机”。本文作者也写过一些文章介绍了API网关在云/容器迁移或数字转换过程中的角色以及如何实现将API网关与现代持续交付模型的集成。
虽然乍一看服务网格和边缘/API网关非常相似但他们还是存在着一些细微的差异而这些差异也影响了边缘控制面板的设计。
边缘控制面板设计
控制面板很大程度上由它所要控制的范围以及所使用的人群决定。我的同事Rafael Schloming之前在旧金山QCon会议上谈到过这个问题他在会上讨论了针对集中化或去中心化的控制实现以及服务目前处于的开发/运营周期(原型、关键任务等)是如何影响控制面板实施的。
如上文所述以边缘代理的控制面板为例集中化运营或SRE网站可靠性工程师团队可能希望为所有的入口流量指定合理的全局默认值和安全措施。然而在第一线工作的产品开发团队则希望能够进行更细化的控制并且希望能够在本地更改全局设置。
Ambassador社区一开始就将开发人员以及应用工程师作为主要目标人群。因此他们主要关注的是基于去中心化配置的控制面板。Ambassador一开始就按照Kubernetes标准设计因此我们最好也能够参照Kubernetes的服务规范来配置边缘例如使用YAML文件通过kubectl加载。
Ambassador的配置方式有Kubernetes Ingress对象、自定义的Kubernetes注解以及自定义资源定义(CRDs)。我们最终选择了Kubernetes注解因为它很简洁也容易上手。理论上Ingress对象是一个更好的选择但Ingress规范一直处于测试阶段除了管理入口流量的\u0026quot;最基本\u0026quot;功能之外其他功能还没怎么达成共识。
如下是一个Ambassador的注解示例它在Kubernetes服务上实现了一个简单的终端到服务的路由:
kind: ServiceapiVersion: v1metadata: name: my-service annotations: getambassador.io/config: | --- apiVersion: ambassador/v0 kind: Mapping name: my_service_mapping prefix: /my-service/ service: my-servicespec: selector: app: MyApp ports: - protocol: TCP port: 80 targetPort: 9376
如果你以前配置过边缘代理、反向代理或API网关那相信你不会对getambassador.io/config中的配置感到陌生其主要功能就是将发送到终端前缀的流量映射到名为my-service的Kubernetes服务上。由于本文主要关注Ambassador的设计和实现因此我们不会涵盖可以配置的所有功能比如路由、金丝雀发布和速率限制等。虽然Ambassador主要是面向开发人员的角色但它也实现了很多针对运营商的扩展并且也可以集中配置身份验证、TLS/SNI、追踪和服务网格集成等。
接下来让我们再回到Ambassador并看一下它在过去两年中的演变。
Ambassador \u0026lt; v0.40Envoy v1 APIs,模板以及热重启
Ambassador本身是部署在容器中的Kubernetes服务并使用Kubernetes Services注解作为其核心配置模型。这种方法使应用程序开发人员可以将路由管理作为Kubernetes服务定义的一部分(也称作\u0026quot;GitOps\u0026quot;方法)。将简单的Ambassador注解转换为有效的Envoy v1配置并不是一项简单的任务毕竟Ambassador与Envoy的配置在设计上并不相同。因此在进行配置转换的时候我们本着聚合和简化操作的目的更改了很多Ambassador内部的逻辑。
具体来讲Kubernetes用户可按照如下步骤完成对Ambassador的配置:
Kubernetes API异步通知Ambassador的更改。Ambassador将配置转换为抽象的中间代码(IR)。从IR中生成一个Envoy配置文件。使用Ambassador验证Envoy配置文件。如果配置文件有效Ambassador将使用Envoy的热重新启动机制来部署新的配置并保持连接。流量将会在新启动的Envoy进程中传输。
这个初始实现有很多好处首先机制简单其次Ambassador同Envoy之间的配置转换是可靠的最后Ambassador与基于文件的热重启的整合也是可靠的。
但是这一版本的Ambassador仍有很多需要改善的地方。首先尽管热重启对于大多数用例有效但是它还不够快而且一些用户(特别是那些部署大型应用程序的用户)发现它限制了更改配置的频率最后热重启有时也会中断连接尤其是像websocket或gRPC流这类的长期连接。
更重要的是尽管初版Ambassador到Envoy的中间代码(IR)允许快速原型设计但由于功能还太初级很难做出实质性的改变。虽然这是从一开始就存在的问题但随着Envoy升级到Envoy v2 API这变成了一个关键问题。正如Matt Klein在他的博文“通用数据面板API“中所描述的那样v2 API为Ambassador提供了很多好处诸如访问新特性、解决上面提到的连接中断问题但遗憾的是现有的IR实现仍然没有本质的提高。
Ambassador \u0026gt; v0.40 Envoy v2 API(ADS)、中间代码、KAT测试
在与Ambassador社区协商后Ambassador首席工程师Flynn带领的Datawire团队在2018年对Ambassador内部进行了重构。重构主要有两个关键目标。首先能够集成Envoy v2的配置格式这将支持诸如服务器名称指示、基于标签的速率限制和改进的身份验证等特性。其次能够对Envoy配置进行更强大的语义验证毕竟它的复杂性越来越高特别是在大规模应用程序部署的时候。
Datawire团队首先按照多遍编译器的思路调整了Ambassador的内部结构。添加了类层次结构以便可以更好的反映Ambassador配置资源、中间代码和Envoy配置资源之间的分离。而Datawire以外的社区也重新设计了Ambassador的核心部分。
之所以采取这些方法是处于如下几个方面的考虑首先Envoy代理仍是一个快速发展的项目我们不能每次都因为Envoy配置的微小变化就对Ambassador进行重新设计。而且我们也希望能够实现配置文件的语义验证。
随着对Envoy v2整合工作的深入Datawire团队很快又发现了一个测试上的问题那就是随着Ambassador开始支持越来越多的特征它在处理不太常见但又正确的特征组合时出现了非常多的错误。这促使他们创建一个新的测试要求而这意味着需要对Ambassador的测试套件进行重新编写以便能够自动测试大部分的特性组合而不是依靠人工来编写每个测试用例。此外这套测试套件需要快速以便最大限度地提高工程效率。
因此在对Ambassador重构的同时Datawire团队创建了新的Kubernetes验收测试(KAT)框架。KAT是一个可扩展的测试框架它的主要功能如下:
将一组服务(连同Ambassador)部署到Kubernetes集群对分离出来的API运行一系列验证查询对这些查询结果执行一组断言测试
KAT是为性能而设计的——它提前将测试设置打包然后在步骤3中使用高性能HTTP客户机异步查询。KAT中的流量驱动程序使用了另一个开源工具Telepresence这也让调试诊断变的更加容易。
随着KAT测试框架的到位Datawire团队又遇到了一些关于Envoy v2配置和热重启的问题他们开始考虑转换到Envoy的ADS聚合发现服务API。这样完全消除了配置更改时重启的限制也避免了高负载或长时间连接下的中断问题。Datawire团队最终决定使用GO编写的Envoy控制面板连接到ADS。但是也增加了Ambassador代码库对GO的依赖。
使用新的测试框架新的中间代码生成有效的Envoy v2配置以及ADSAmbassador 0.50的主要体系结构更改已经完成。现在用户使用含有Ambassador注解的Kubernetes清单的步骤如下:就在发布之前Datawire团队又碰到了一个问题Azure Kubernetes服务AKS不能正确检测到Ambassador注解的更改。通过与AKS工程团队的高效合作他们很快找到了问题点——Kubernetes API服务器中的代理链丢掉了很多访问请求对此最好的缓解措施是使用支持调用API服务器的FQDN。不幸的是这需要AKS中的mutating webhook而官方的Kubernetes Python客户端并没有实现这个特性。因此我们使用了Kubernetes Golang客户端这也是基于Go的第二个依赖项。
总结
正如Matt Klein在EnvoyCon开幕式上所提到的随着目前Envoy代理在云原生技术领域的流行不知道Envoy的人群反而成了少数。我们知道谷歌的Istio已经在Kubernetes用户中提高了Envoy的知名度现在主要的云供应商都在关注Envoy例如在AWS app网格和Azure Service Fabric网格。在EnvoyCon上我们还听说了一些大公司如eBay、Pinterest和Groupon都在使用Envoy作为他们的主要边缘代理还有一些其他基于Envoy的边缘代理控制面板如Istio Gateway、Solo.io Gloo和HeptioContour等。Envoy已经成为云原生通信的通用数据面板当然它在控制面板领域内仍有许多工作。
在本文中我们讨论了Datawire团队和Ambassador开源社区如何成功地将Envoy v2配置和ADS API应用到Ambassador边缘控制面板。在构建Ambassador 0.50的过程中我们学到了很多东西
Kubenetes和Envoy是功能非常强大的框架但它们也在不断成长中——很多时候都没有最新的文档交付维护人员只能通过阅读源码来学习。Kubernets/Envoy生态系统中支持最好的类库都是用Go编写的。虽然我们喜欢Python但是我们不得不采用Go这样我们就不必自己维护太多的组件。有时候重新设计测试工具也能促进软件开发。通常重新设计测试工具的真正成本只是将旧的测试移植到新的工具实现。为边缘代理设计和实现一个有效的控制面板是很困难的来自Kubernetes、Envoy和Ambassador开源社区的反馈非常有用。
将Ambassador迁移到Envoy v2配置和ADS API是一个漫长而艰难的过程需要大量架构和设计上的讨论当然也少不了大量的编码但早期反馈的结果是积极的。Ambassador 0.50已经发布你可以试用一下并在Slack频道或Twitter上分享一下你的意见。
关于作者
丹尼尔·布莱恩特公司技术变革的领导者自由职业顾问Datawire是其客户之一。他目前的工作是实现公司内部开发的敏捷性引入更好的需求收集和规划技术关注敏捷开发中架构的相关性促进持续集成和交付等。Daniel目前的技术专长集中在\u0026quot;DevOps\u0026quot;工具化、云/容器平台和微服务实现。他同时是伦敦Java社区(LJC)的领导者并参与了很多开源项目。他还为InfoQ、DZone和Voxxed等知名技术网站的撰稿并定期在QCon、JavaOne和Devoxx等国际会议上发表演讲。
查看英文原文https://www.infoq.com/articles/ambassador-api-gateway-kubernetes
