深度比较OSM和Istio

微信扫一扫,分享到朋友圈

深度比较OSM和Istio

尽管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,我们知道这也可能造成混乱。因此,我们进行了比较,以帮助您选择合适的网格。

PS: 本文属于翻译,原文

Node.js v14.13.0(Current)发布

上一篇

乔治·R·R·马丁公布自己最不喜欢的《权力的游戏》场景

下一篇

你也可能喜欢

深度比较OSM和Istio

长按储存图像,分享给朋友