首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >从服务混乱到服务网格

从服务混乱到服务网格

作者头像
CNCF
发布2020-02-20 17:18:29
1K0
发布2020-02-20 17:18:29
举报
文章被收录于专栏:CNCFCNCF

嘉宾文章作者:Rob Richardson(@rob_rich),技术布道者,MemSQL;KavyaPearlman(@KavyaPearlman),全球网络安全策略师,Wallarm

我们正在见证微服务和云原生技术的崛起。然而,微服务架构的一大挑战是管理服务之间的网络通信的开销。许多公司成功地使用Kubernetes等工具进行部署,但它们在路由、监控和安全方面仍面临着运行时挑战。在生产环境中,只有勇敢的技术人员才能处理数十个、数百个甚至数千个服务的通信问题。这就是服务网格来清理混乱的地方。

从单体到混乱的微服务

从历史上看,部署是困难的。为了避免这个问题,我们将软件的所有部分打包到一个大型部署包中——一个单体,并且很少部署它。这个包通过最小化我们需要部署的内容的频率和数量来减少部署负担。但这个庞大的包是复杂的。它包含了每一个功能块和所有相关的块。单体是脆弱的,考虑到部署的痛苦,我们需要小心地维护生产环境。

为了解决这个问题,我们转向了微服务——可以独立且频繁地部署的小而简单的功能片段。微服务架构涉及构建针对特定任务或业务目标的小模块。它们通常易于构建和替换,并且通常通过web请求或事件队列与其他服务通信。微服务是组装成大型系统的小型模块组件。

图:单体与微服务架构比较

微服务架构提出了一个新的挑战:内部组件有web地址。内部方法调用不再受进程边界的保护,而是一个网络请求。如图所示,这创建了一个非常混乱的网络架构。是什么阻止外部通信流直接调用内部组件?这种混乱的解决方案是:服务网格。

服务网格是什么

服务网格回答了这样一个问题:“我如何在服务之间观察、控制或保护通信?”服务网格拦截进出容器的流量,无论是在容器之间,还是外部资源。因为它拦截所有集群网络流量,所以它可以监视和验证连接,映射出服务之间的通信。它还可以理解服务健康状况、拦截故障或注入混乱工程。

服务网格是用于监视和控制微服务集合的管理层。服务网格扩展但不替换它所控制的服务。正如Zach Butcher所说,“如果它没有一个控制平面,它就不是一个服务网格。”

另一个类似的术语是API网关。服务网格通常将每个容器包装在一个网络代理中,向每个微服务添加一个边车容器。相比之下,API网关是一个更简单的结构。单个添加位于集群的边缘,用于验证入站流量,但不监视容器之间的流量。

它是如何工作的?

Istio是一个开源服务网格。让我们以它为例,看看典型的服务网格是如何工作的。在图的顶部,我们看到服务A和服务B。灰色的盒子是pod的边界,我们在每个pod中看到两个容器:服务和一个边车容器。在这种情况下,Istio使用了Envoy,一种开源的边缘和服务代理。在图的底部是Istio控制平面。Linkerd是另一个开源服务网格,其网络架构几乎相同。Linkerd使用不同的边车代理,控制平面有不同的部件,但是方法是相同的。

服务网格架构示例

没有服务网格,服务A将直接调用服务B。有了服务网格,服务A将接触到代理,在这种情况下是一个Envoy代理。代理调用Istio控制平面。Istio验证是否允许A与B进行通信。Istio返回与B的代理进行通信所需的详细信息。如果配置为安全通信,则A的代理通过相互加密的TLS隧道连接到B的代理。B的代理到达控制平面验证连接,然后将请求转发给服务B。在这个场景中,所有的网络连接都是通过TLS进行的,只有一个例外。服务和代理之间的通信可能不加密(取决于服务)。这是可以的,因为它在pod的网络边界内。任何在pod之间移动的通信现在都是加密的。

何时选择服务网格

拦截所有集群流量的好处在于,一个服务网格可以做一些非常有趣的事情来验证和路由流量。一般来说,我们选择服务网格时,我们希望解决这些问题之一:

  • 观察集群中的流量:发现、映射、日志
  • 控制集群中的流量:访问策略,版本间的流量分割
  • 网络资源之间的安全传输:容器之间的https

选择服务网格最常见的原因是为了保护容器之间的通信。服务网格为每个pod添加一个边车代理容器。现在很容易对边车代理之间的通信进行加密,以确保监视者看不到集群网络通信。在深入研究安全性时,这是一个很好的特性。

使用服务网格的另一个常见原因是确保只有经过授权的资源才能调用每个服务。因为所有的流量都通过边车代理,所以我们可以根据批准的网络策略来验证流量。例如,只有主管门户容器可以调用公司财务报告容器。

因为服务网格位于所有微服务通信之间,所以记录这些交互非常简单。从这些数据中,我们可以查看服务健康状况的仪表板,并推断出服务如何通信的网络图。这个网络图不是开发人员认为会发生的事情,而是实际发生的事情。例如,我们可以发现结账过程并没有调用税务计算服务,而是使用了开发人员忘记删除的硬编码调试值。或者,我们可以发现一个新的影子IT仪表板已经安装,并意外地调用运送服务。也许我们需要调整访问策略或增加服务能力来进行补偿。

使用服务网格的另一个重要原因是在同一软件的不同版本之间划分流量。我们可以选择运行A/B测试来试验新特性,并了解客户参与和财务影响。或者我们可能有一个测试版的渠道,在这个渠道中,热心的客户可以在新功能发布之前试用它们。或者,我们可以通过只向新版本发送一定比例的流量来使用灰度部署。随着我们获得信心,我们可以增加流量,直到旧版本不被使用。在测试场景中,服务网格可以将错误注入到流量中,从而允许我们测试服务弹性。在生产中,服务网格可以充当断路器,帮助服务在故障时更容易地恢复。

何时不选择服务网格

很容易过于急切地追求服务网格,而不了解它对集群的潜在影响。也许软件需求包括“容器之间的安全通信”。没有适当的业务需求,这会使事情变得更加混乱。

将服务网格集群与没有服务网格的集群进行比较。在常规集群中,有N个容器在工作。添加一个服务网格,我们有相同的N个容器和N个边车代理。在一个常规集群中,我们让Kubernetes控制平面容器。添加一个服务网格,我们就有了服务网格的控制平面容器。我们还增加了TLS加密的开销。添加一个服务网格可以使集群中的容器数量增加一倍。增加这么多额外的计算肯定会增加成本。

我们需要保护容器之间的通信吗?如果我们在集群中运行不受信任的工作负载、非常敏感或业务关键的工作负载,或者我们正在运行一个多租户集群,那么这一点非常重要。但是,如果我们只运行第一方的工作负载,我们可以将整个集群视为一个干净的房间,保护集群周边,从而节省大量的硬件开销。

简而言之,不使用服务网格如果你是:

  • 不运行高敏感服务(PKI、PCI)
  • 不运行不受信任的工作负载
  • 不运行多租户工作负载

看一看Istio

Istio是一个开源服务网格,与Linkerd非常相似。Istio将一个边车代理容器注入到每个pod中,以便管理进出容器的通信。容器的应用程序不需要更改为支持服务网格网络路由。

虽然Istio设置的细节超出了本文的范围,但是Istio设置非常简单。要将Istio安装到Kubernetes中,首先安装所有的CRD(Custom Resource Definition,自定义资源定义),然后通过istioctl命令行实用程序启动Istio控制平面。最后,将标签istio-injection=enabled添加到要管理的每个名称空间。结果,当pod被调度时,Istio代理边车被自动注入。Istio配置文件启用和禁用控制平面的某些部分,以满足你对安全性、自定义和易学性的需求。例如,我们可以启动TLS以获得最大的安全性,或者关闭TLS以获得观察和控制,而不需要额外的加密计算。

Istio用VirtualService替代了k8s的服务,这种结构允许指定更细粒度的路由规则,比如检查入站数据头的身份或在多个目标之间分割流量。(见图)Istio还用网关替换了k8s的入口,因此即使是入站流量也可以安全地在服务之间路由。一个完美的深入安全的用例是在Istio网关上终止HTTPS,并使用Istio的mTLS来确保从那时起所有的流量都是加密的。

来源:https://istio.io/docs/concepts/traffic-management/。

一个示例虚拟服务将75%路由到v1,25%路由到v2。

API网关代替服务网格

如果我们在集群中只运行受信任的第一方工作负载,我们可以使用API网关(如Kong)采取另一种方法。服务网格的主要假设是我们不信任集群,因此必须保护每个容器。我们可以将整个集群视为受信任的,并将重点放在保护集群边界上。

要消毒入站流量,可以选择更轻量级的API网关或Web应用程序防火墙(WAF)。为了确保容器的健康,需要关注可信的构建链。只使用来自可信注册表的基本容器,并在构建每个容器时使用构建时漏洞扫描。在容器构建过程中,捕获容器中安装的所有软件名称和版本的审计—-包括操作系统包和软件库。每当发现新的漏洞时,将已安装的软件列表与漏洞数据库进行比较。如果容器包含任何脆弱的包,则重新构建容器,并部署新的安全版本。

通过关注集群边界并保护构建管道,我们可以认为集群是一个洁净的房间,集群中的所有内容都是安全的。现在我们不需要分别保护每个正在运行的容器。使用这种替代方法,我们可以选择为独特的业务单元或风险容忍度构建单独的Kubernetes集群,将敏感的工作负载从更随意的业务关注点分割到单独的集群中。

收拾残局

过快地追求服务也有不利的一面。我们必须认识到服务网格所需额外资源的成本。如果你有这些业务需求,你需要一个服务网:

  • 如果运行高度敏感的服务(PKI, PCI)
  • 如果运行不可信的工作负载
  • 如果运行多租户工作负载

在Kubernetes集群中,为观察、控制或保护流量而触及服务网格。因为服务网格拦截进出每个容器的流量,所以它是监视和控制流量的好方法。无论你是希望使用互TLS来保护流量,还是授权服务间通信或监视服务之间的流量,服务网格都是清理混乱的最佳选择。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-02-17,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 CNCF 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
容器服务
腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档