云原生深度比较OSM和Istio

Posted 2022-05-26 张志翔 ̮

        尽管ServiceMesh世界中，现在正处于战国时期。直到上个月，Istio依然是最有希望一统天下的王者。

        CNCF于2016年收购Kubernetes之后，谷歌，IBM和开源服务网格Lyft共同开发了Istio，开源边缘和服务代理Lyft开发了Envoy。这三者在一起几乎变得一致，而云原生环境中的大多数其他平台都将Istio作为事实上的服务网格层。

        六年前，来自Google的团队首次在开源GitHub存储库中提交了Kuberenetes，如今，其使用量一直在上升，无论出于何种目的和用途，Kuberenetes都已成为容器编排的行业标准。导致此问题的其中一个因素是云原生计算基金会（CNCF）在2016年收购Kubernetes，这是基金会技术监督委员会（TOC）接受该基金会接受的第一个官方CNCF项目。

        当然，这也是导致Kubernetes与Envoy和Istio成功组合的主要因素之一，而大多数其他云原生平台也将其默认支持。但与此同时，很明显，Istio将面临竞争，因为在许多早期服务网格采用者中还选择了Linkerd，Kuma和HashiCorp Consul Connect等产品。

        鉴于此，以及一些主要的企业供应商尚未选择首选解决方案的事实，服务网格市场似乎缺乏可接受的行业标准，并且随着时间的流逝变得有些分散。

        过去的一个月围绕当前已经分裂的服务网格环境带来了一场风暴。微软宣布，在Google做出令人惊讶的决定将Istio捐赠给新的Open Usage Commons基金会之后，它将向CNCF捐赠其自有的服务网格。尽管有些人指出这可能是围绕多云互操作性标准进行协作的进步，但另一些人则对Kubernetes用户所引起的加深混乱感到震惊，这很可能是这些变化的最直接的后果。

        在Portshift，我们也感到惊讶。因此，我们决定，在等待市场变化的同时，如果最终制定了行业标准，我们将与您分享有关可用于第7层网络保护的当前选项的见解。

什么是服务网格?

        服务网格是一种网络模型，可在您的应用程序体系结构中形成基础结构层（第7层）。下图显示了整个Kubernetes网络的参考架构实现，包括服务网格的位置。

        作为容器应用程序开发的一部分，用户必须结合微服务的集合来创建完整的应用程序。服务网格由数据平面和控制平面组成，该数据平面包含管理网络流量的代理。服务网格支持团队管理的多个微服务的集中通信，而无需分别监视每个单独的服务。

        控制平面组件可实现这种集中化。用户从控制平面配置，控制和管理服务网格，用于生成和部署配置，如下图所示：

        控制平面还跟踪并记录对象之间的交互。

        代理位于体系结构的中心（也在上图中），执行核心任务：

• 服务之间的通信
• 交付服务
• 监视不断变化的服务实例状态
• 在动态服务网格层上分散负载

        这些代理共同构成一个服务网格，有时被称为“ sidecar”，因为它们与每个服务并行执行，而不是在每个服务中执行，最著名的sidecar是Envoy。

        服务网格管理网络中服务到服务的通信，实现Pod之间的通信，通过将Pod（微服务）彼此隔离，跟踪性能指标并帮助用户创建更有效，更可靠的服务请求来防止非法通信。它提供重要的应用程序服务，例如负载平衡，流量管理，路由，运行状况监视和安全功能。这些安全功能包括监视，服务到服务通信（相互TLS）加密，断路器，故障注入以及服务和用户身份验证，以及防止入侵和DDoS攻击的保护。

有关Istio的一些额外信息

        就像我们在本文开头提到的那样，直到最近，几乎所有主要软件供应商都将Istio解决方案或集成的优先级高于其他替代服务网格的解决方案或集成。此外，在活动和贡献方面，Istio开源社区远远超过任何其他社区。

        该解决方案得到Google，IBM和Lyft巨头的支持的事实，意味着即使考虑到Microsoft竞争平台的推出，Istio仍将而且很可能继续成为市场上的领先选择–至少暂且。实际上，2019年CNCF的调查报告称，大多数用户已实施Istio，而进行评估的人正在将Istio视为其首要选择之一。

        Istio已被证明很复杂，这可能是Microsoft OSM最大的特色。同时，到目前为止，这种学习曲线似乎尚未降低。但是，围绕Istio部署有一个非常强大的生态系统，这使得采用Istio优于其他选择。

        IBM的Istio技术主管Lin Sun表示：“我们希望Istio像Kubernetes一样，是微服务的“无聊”基础架构。 “这是我们2020年的首要目标：能够在不对微服务进行多次配置更改的情况下，将服务更快地迁移到服务网格。” Istio广泛采用的障碍是今年早些时候在版本1.5中引入的一项重大架构更改。

        随着Istio v1.5的推出，该解决方案似乎有望克服一个较小的差距，而将单个集中式控制平面作为整体式架构的一部分来解决，这是从其以前的分布式微服务架构中获得的。该功能是由Istiod创造的，在对v1.6发布以及与Envoy开发相关的持续改进寄予厚望的业界接受之前，还有一段路要走。

Microsoft OSM，行业标准和SMI

        Microsoft已发布（以Alpha版本形式）开放服务网格（OSM），它是符合SMI规范的服务网格实现。 OSM提供了标准的服务网格技术功能，例如金丝雀版本，安全通信和应用程序见解，类似于Istio等其他服务网格实现。 OSM实现了服务网格接口（SMI），它是用于在Kubernetes中部署服务网格的一组标准API。

        在Alpha版本中，OSM自动提供流量转移策略，服务内的安全mTLS通信，精细的访问控制策略，应用程序指标，外部证书管理器和Sidecar Envoy代理注入。

        OSM使用Envoy作为Sidecar代理与网状网络中的其他服务进行通信，并且还允许任何服务发现协议反向代理兼容，以便采用高级Envoy功能。当用户创建一个Pod时，OSM会使用一个mutating的Webhook捕获API，然后将其注入Envoy sidecar代理。然后，来自OSM的初始化容器使用iptables来确保所有流量都流经Envoy。

        OSM处理访问控制规则，路由策略，加密通信并收集指标（默认情况下在Grafana和Zipkin中可以看到）。

OSM vs. Istio

结论

        去年，GlobeNewswire的报告已经与专家一起指出了所有这些似乎给用户带来的困惑。回到2019 CNCF调查，看来Istio确实仍然是当前的领先选择。同时，鉴于HashiCorp Consul Connect的广泛实施，迄今为止激烈的竞争，Linkerd提出了所有可能的改变，并且还添加了OSM，更不用说一些新星了。

        在Portshift，我们知道这也可能造成混乱。因此，我们进行了比较，以帮助您选择合适的网格。