1

Istio的复杂性揭秘

 2 years ago
source link: https://www.jdon.com/57393
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Istio的复杂性揭秘
21-10-15 banq

7081a5be5fce4b698658d21f79bb51c9?from=pc

很长一段时间以来,Istio 一直被批评为出了名的复杂和难以使用。作为一个在这个项目上工作了四年多的人,在 Istio发布的前两年我同意这个说法。但是,从Istio 1.3 开始,Istio 社区专注于简化,现在 Istio 更加精简和易于使用,尤其是在Istio 1.6或更新版本中。我亲自观察到改进的简单性和易用性,我们的许多用户都报告了类似的体验。

从本质上讲,今天的 Istio 更加直接,任何因为早期版本更难使用而避免使用 Istio 的人都应该考虑再看看。

由于 Istio 社区非常关注简单性,我很自豪地说,现在有了 Istio,简单的事情变得很容易。让我从三个具体的例子开始:

1. 一键安装

在 Istio 的早期,我记得我总是需要在 istio.io 中查找安装说明。这不是一个简单的命令要记住。今天,用户可以使用istioctl install命令轻松安装 Istio ,该命令为他们设置默认配置文件。此外,用户可以指定--profile指示不同的配置文件。很容易记住吧?

47cba425332c4e00ad8c8f637243d108?from=pc

Istio 安装大约需要一分钟,只安装了十几个自定义资源定义(CRD):

26ba98d9b19842f7a68af8ab79ca047a?from=pc

2. 分析您的 Istio 资源

早在使用 Istio 的时候,我记得在将一个简单的留言板应用程序从 Kubernetes 加载到 Istio 服务网格时,花了几个小时调试我的 Istio 资源出了什么问题。现在不会再发生!istioctl analyze会考虑到集群中的其他 Istio 资源,可以立即告诉我 Istio 资源出了什么问题。

412d97e97cad4e61974eb1f69933dd0b?from=pc

3. 简单的安全策略

我们的大多数用户都在采用服务网格,因为他们的安全或架构团队要求他们保护微服务通信。Istio 使这变得非常简单:网格平台团队只需应用身份验证策略并在具有匹配标签的任何服务上启用双向 TLS。我喜欢这个,因为这意味着服务所有者不需要做任何事情,除了标记他们的部署以要求使用 mTLS 与他们的服务进行所有通信。您可能认为您可以在没有服务网格的情况下自己管理所有这些,但是修改您的应用程序代码并创建一个自行开发的框架来管理证书分发和轮换会困难得多。

5c1bf17d5ef54e369df56a6efc112381?from=pc

服务网格的复杂性

服务网格数据平面是基础架构的关键组件,当您需要处理云原生工作负载以及虚拟机或裸机上的旧工作负载时,它本质上是复杂的。

以安装过程为例,Istio 项目因提供太多选择而受到批评。虽然使用 istioctl 安装 Istio 非常简单,但我们有些用户不想在生产中运行 istioctl,因为它需要更新他们的交付管道,他们必须为此寻求额外的批准。一些常用工具,如Helm已经在他们的组织中得到支持,他们可以更容易地利用这些预先批准的工具。此外,我们的一些用户希望控制平面在他们的集群之外运行,以便可以由不同的团队单独管理,因此外部控制平面是我们提供的另一种安装方法。因为每个公司或团队都有很多不同的用例和要求,我认为最好根据用户的各种要求提供选择和灵活性,而不是仅仅提供一种使用istioctl install.

Istio 也因其网络 API 的复杂性而受到批评。复杂性部分是由于可用的丰富功能同时为南北流量和东西流量提供一致的 API。有趣的是,在过去的几年里,我发现所有这些功能都是用户努力解决各种挑战所要求的。应用层组网比较复杂,从边缘到东西向的流量需要考虑很多场景,例如:

  1. 你的主机名是什么?您是在边缘处终止流量还是使用直通?
  2. 您使用的是什么协议和端口?
  3. 你如何确保你的优势?
  4. 您希望如何将流量路由到您的服务?
  5. 您如何提高服务的弹性?
  6. 您是否需要故障转移策略(可能基于位置)?

Istio 的下一步是什么?

由于有大量用户投入生产,我们希望确保我们的用户成功地在全球范围内大规模运行服务网格。我很高兴与 Solo.io 的 Istio 和Gloo Mesh用户合作,帮助他们大规模采用 Istio,同时将他们的需求也带到上游 Istio。

随着 API 变得更加成熟,我们还将标准化我们的 API,并根据角色明确分离我们的 API。社区正在将这些 API 标准化为自己的自定义资源,以便用户可以轻松地配置遥测或扩展或代理配置,而无需询问平台团队修改全局网格配置。

我们将继续将我们的功能从不太成熟的阶段(实验或 alpha)升级到成熟阶段(beta 或稳定)。与其他所有成功的项目一样,我们希望保持房屋清洁并删除用户不感兴趣的功能。对于长时间停留在实验或 alpha 阶段的功能尤其如此。我们将继续使简单的场景变得简单,但为我们的用户启用复杂的场景。

作者:孙琳

Lin 是 Solo.io 的开源主管。自 2017 年以来,她一直致力于 Istio 服务网格,并在 Istio 技术监督委员会任职。此前,她曾在 Istio 指导委员会任职三年,并在 IBM 担任高级技术人员和发明大师超过 15 年。她是《Istio Explained 》一书的作者,拥有 200 多项专利。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK