由 Istio 创始人创建的 Tetrate Service Bridge(TSB)是边缘到工作负载的应用连接平台,为企业提供一致、统一的方式,在整个网格管理的环境中连接和保护服务。

在本文的第一部分,我们将解释为什么企业需要一个应用网络平台以及 TSB 为企业解决的问题。在第二部分,我们描述了放大两个具体问题领域的演示。(1) 运行时的自动故障切换,以及(2) 实现跨云和数据中心边界的端到端加密、授权和认证。本内容最初由 Zack Butcher 和 Adam Zwickey 在 Tetrate 最近的网络研讨会 “Tetrate Service Bridge:在任何地方运行的应用程序的连接和安全“上提出。

TSB 概览

如今的企业需要一个基础设施层,允许应用程序在任何环境下、任何计算上进行通信。Tetrate Service Bridge(TSB)是一个提供这一层的应用网络平台。TSB 建立在开源项目 Istio、Envoy 和 Apache SkyWalking 之上,是一个多集群服务网格或多个网格的管理平面。最简单地说,它的工作是利用复杂的分布式系统的复杂性,使应用开发者和运营商简单地实现他们在组织中需要做的事情。

TSB is an end-to-end app networking platform, with Envoy proxy at the edge and app ingress, and as sidecars in the mesh.

随着每个行业都在进行数字化转型,今天的企业正在进行现代化改造和/或迁移到云端,以实现组织的敏捷性。为了更快地交付,企业正在转向使用微服务和云原生架构构建的应用堆栈,而传统的数据中心现在与私有云和公有云共存。通过无缝连接传统和现代工作负载,TSB 使现代化和渐进式迁移变得更快、更安全,而不必担心停机——无论应用在哪里运行,都可以连接、保护、控制和观察。

Use cases include business agility & continuity, reliability and security-- for hybrid workloads, multicluster and mutli-cloud

运维可以建立高可用性和弹性的应用,并实现全局可见性。应用程序开发人员可以使用流量调度和金丝雀部署等网格功能以及 TSB 扩展的运行时功能(如跨集群服务发现)更快、更安全地进行迭代。安全团队成员可以在应用程序本身中实现零信任态势——通过一致的身份、策略和传输中的加密保持跨集群通信的安全性——这意味着应用程序默认是安全的。

财富 500 强公司正在生产中使用 TSB,这些公司在各种用例中都采用了它。FICO 用它来实现其 Kubernetes 环境的 PCI 合规性;Square 提高了几个重要系统的弹性和可用性,并使用服务网格功能来减少他们的基础设施足迹;美国国防部采用 Istio 进行传输中的加密,并促进应用级安全;TSB 编纂了他们的最佳实践。在 TSB 的帮助下,国内一家顶级金融服务公司能够加快向云计算的迁移,以及从传统虚拟机的迁移。一家顶级支付公司能够开始对应用工作负载进行现代化改造——提高弹性和整体安全态势,并减少开发人员实际交付功能的时间。

Tetrate customers, including Square, FICO, and the US Department of Defense, have partnered with Tetrate for security assurances, PCI compliance, and traffic shaping

考虑到这些用例,让我们谈谈 Tetrate Service Bridge 的工作原理。同样,TSB 是一个多集群服务网格的管理平面。你将在你的计算集群中使用 Envoy 作为数据平面,而这些都是由 Istio 控制平面编程的。除了这些开源组件,我们还部署了一个控制平面,它位于集群中,以方便给 Istio 本身进行配置。

 

The TSB management plane sits on top of an Istio and Envoy mesh-managed environment

这一点很重要,因为你希望能够根据你的本地环境,对你所在的本地集群进行专门配置。这些负责传播跨集群的服务发现信息,以促进运行时的故障转移,正如你在下面的演示中所看到的——不将看到当我们在运行时杀死一个 pod 时会发生什么,并观察跨集群故障转移等情况。

但是,对于采用服务网格的组织来说,真正的挑战其实是如何将这些运行时的碎片粘合到我的组织中。TSB 的管理平面在组织需要使用服务网格做什么和实现什么之间架起了桥梁。在开源组件的基础上,TSB 提供了一套丰富的跨集群能力。

  • 多租户。在谁可以配置什么的问题上,以及在运行时通过 TSB 对组件进行更改的影响上,都是如此。

  • 流量整形。Istio 在一个集群中的所有功能在集群中和跨集群中都得到了促进,应用网关有助于促进跨集群的负载均衡,促进从传统的基于虚拟机的部署过渡到例如现代 ECS、EC2 或 EKS 部署。

  • 高可用性和弹性。服务网格的所有良好的可用性特征(如重试、断路器),但获得了跨集群的协调,并能在这些集群之间因断路器而进行故障转移。

  • 跨集群的安全策略和访问控制。一致的政策和细粒度的访问控制。

  • 统一遥测和 SLO 管理。全局的、统一的可视性。

  • 跨集群的服务发现。促进跨集群的服务注册和运行时服务发现。

  • 细致的入口和出口控制。围绕着什么可以进入和退出进行细粒度的控制。

  • API 网关是服务网格的一部分。API 网关是网格一个固有部分。不仅仅是在应用边缘或入口网关,而是一直到服务网格中的中间 sidecar。TSB 实现了很多你可能认为是 “面向 API “的功能——如速率限制、授权/认证、令牌验证等。

Demo 第1部分:在运行时自动故障转移的简单发布

应用程序运维如何安全地发布新的应用程序功能并控制跨环境的路由?随着异构基础设施和应用团队的快速发展,我们需要工具来保障安全——如金丝雀和 A/B 测试,但也有运行时功能,如自动故障转移,以及细粒度得转移流量,例如,虚拟机和 Kubernetes,以促进扼杀单体和类似模式。

For safe releases, TSB architecture enables A/B testing, canary rollouts, fast failover, and seamless integration between workloads

在演示中,Adam Zwickey 使用 bookinfo 应用程序(由四个微服务组成的 Istio 示例应用程序)来演示跨两个区域(GKE 集群的东部和西部)的主/主部署,其中全局网格可以执行本地感知路由——保持流量的本地性而不超越区域或集群的边界。Adam 模拟了一次故障切换,这样我们就可以看到区域间的自动和快速故障切换,然后展示了如何将传统(虚拟机)工作负载引入应用。

局部感知的路由和故障转移模拟

我们可以注意到 TSB 中的一些关键逻辑结构:组织(例如,具有共享基础设施的公司)、租户(例如,共享具有特定权限的资源的共同访问的业务单位)和工作空间(一个分区的区域,团队管理他们专属的命名空间)。

Adam 展示了两个没有功能的、没有联系的 bookinfo 应用程序。他应用了一个 YAML 文件,其中包含对入口和路由策略的简明描述,该文件被应用于服务网格,并由管理平面分发到各集群。 我们马上看到,服务仪表板上的指标亮了起来,显示了流经这些地方的流量(以及流量的健康状况)。应用边缘网关解决了应用问题,并参与了遍布三个集群的全局网格。在 Bookinfo 应用程序的主页上查看服务配置,你可以看到我们在网格中的所有服务条目,你会注意到交付给本地集群的管理通道——GKE East。流量被保持在本地。

TSB maps east and west traffic in this demo of regional failover

然后,Adam 模拟了一次失败,展示了如果我们在东部的 details 服务上线了一些不好的配置,导致我们的 pod 暂时中断会发生什么。为了做到这一点,他将部署扩展到零(当我们在命名空间中查看我们的 pod 时,我们可以看到它们没有再处理任何请求)。在刷新时,我们注意到发生了故障转移。

看一下拓扑结构,我们看到东部集群的连接是通过 mTLS 到另一个集群的网关。我们无缝地进行了故障转移——跨区域,以便我们的应用程序可以继续运行,我们可以继续满足我们的 SLA 和 SLO。在这个演示中,我们可以清楚地看到没有用户认为的故障。我们看到一串连续的 200 秒的滚动。

可观察性

Metrics in TSB

看看 bookinfo 的三个部署版本,我们可以得到一个有趣的应用程序的视图,并且可以非常容易地看到这些子集的比较。例如,我们可以看到,虽然服务总体上表现得很好,但我们注意到这里有几个尖峰,响应时间高于平均水平。在版本 3 中,我们可以看到响应时间是 729 毫秒(与个位数相比),我们可以进一步深入研究,看看所有可点击的 RED 指标,看到我们可以在 GKE West,版本 3 中提取出一个问题。如果我选择该集群并查看存在问题的实际实例,我就可以开始深入研究并找到问题所在。这是一个相当快速和简单的方法,可以得到相当细化的信息,并看到与应用程序的行为最相关的指标。TSB 使用 Apache SkyWalking 来实现高性能的可观察性功能。

引入 VM

接下来,Adam 回到应用中,展示了如何在我们的网格中引入一个传统的工作负载 sidecar,只是通过应用一些非常简单的 Kubernetes YAML,也就是 Istio 自定义资源(CR)。

Adam 在这里真正做的是应用工作负载条目,这是一个 Istio 配置,告诉 Mesh 虚拟机的位置。在这一点上,没有任何连接,也没有运行 sidecar。这表明 TSB 在 Tetrate CLI 中有一个辅助命令,为你处理启动问题。因此,你安装了 sidecar,并用 tctl 命令将虚拟机引入网格,只需要几分钟就可以看到它被下载到代理,并像你期望的那样与网格中的任何其他 pod 一起运行。刷新后,我们看到我们的混合工作负载在东部和西部,在拓扑视图中,我们看到图标是半虚拟机,半 Kubernetes。

因此,回顾一下,我们已经看到了我们如何路由流量,连接和负载均衡,整合传统的,以及无缝的故障。

演示第2部分:应用工作负载安全策略

TSB enforces end-to-end encryption and provides consistent authn and authz across clouds and data centers

安全是 TSB 的一个主要用例,所以我们要研究如何促进端到端加密、认证和授权,以及不仅在我们的数据中心,而且在我们的云足迹中的共同政策。由于平台团队必须努力保持系统的安全,而应用团队需要使用每个云供应商的最佳产品来运输他们的东西,因此我们如何持续保持我们的安全态势成为一个非常严峻的挑战。Istio 有很多惊人的工具,可以帮助实现一致的身份,并在传输过程中执行加密。

在 Adam 演示的最后部分,他展示了一些我们可以应用于安全的策略,以及像安全架构师这样的用户如何非常容易地为部署到全局服务网格或可能的工作区的所有应用程序和服务设置一个默认的基线策略。我们可以设置流量配置、入口、断路器和超时,或者要求严格的认证,即网状结构内的所有连接都需要有客户证书。我们还可以制定服务对服务的授权策略,这不仅要看客户证书,还要看其中编码的身份。这确实使我们走向一种默认安全的态势,即所有的服务都有某种强大的授权和认证与之相联系。

 

总结

我们已经介绍了 TSB 的基本用例和功能,以及它是如何被财富 500 强企业用于 PCI 合规性、零信任安全、弹性和可靠性的生产中。在演示中,我们看到在短短几分钟内,实际上只有几行配置或策略,我们就能建立一个相当强大的架构,其中的应用程序是高可用的,在不同的集群和区域中是主/主的。在可能的情况下,我们优化了路由,使其保持在集群中,或有最少的跳数,以使其最有效率。但是,如果我们有事情出错,我们能够跨集群故障。我们已经以一种系统和安全的方式引入了一个传统的虚拟机,我们可能会开始对其进行现代化。最后,我们已经看到如何建立一个基线安全策略。

Tetrate Service Bridge 1.3 现在已经推出。进一步探索它或联系 Tetrate 了解详情。

Zack Butcher 是 Tetrate 工程师。他是 Istio 的贡献者,也是其指导委员会的成员,并且是 Istio Up and Running(O’Reilly:2019)的共同作者。

Adam Zwickey 是 Tetrate 的解决方案工程负责人。他曾在 VMware 的现代应用平台业务部门担任现场负责人。过去近十年来,他的工作重点是帮助全球 2000 强企业实现基础设施平台的现代化,并采用云原生应用架构。

Tevah Platt 是 Tetrate 的内容创作者,她写过关于服务网格和开源 Istio、Envoy 和 SkyWalking 项目的文章。