Istio的复杂性揭秘

很长一段时间以来，Istio 一直被批评为出了名的复杂和难以使用。作为一个在这个项目上工作了四年多的人，在 Istio发布的前两年我同意这个说法。但是，从Istio 1.3 开始，Istio 社区专注于简化，现在 Istio 更加精简和易于使用，尤其是在Istio 1.6或更新版本中。我亲自观察到改进的简单性和易用性，我们的许多用户都报告了类似的体验。
从本质上讲，今天的 Istio 更加直接，任何因为早期版本更难使用而避免使用 Istio 的人都应该考虑再看看。
由于 Istio 社区非常关注简单性，我很自豪地说，现在有了 Istio，简单的事情变得很容易。让我从三个具体的例子开始：
 
1. 一键安装
在 Istio 的早期，我记得我总是需要在 istio.io 中查找安装说明。这不是一个简单的命令要记住。今天，用户可以使用istioctl install命令轻松安装 Istio ，该命令为他们设置默认配置文件。此外，用户可以指定--profile指示不同的配置文件。很容易记住吧？

Istio 安装大约需要一分钟，只安装了十几个自定义资源定义（CRD）：

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

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

 
服务网格的复杂性
服务网格数据平面是基础架构的关键组件，当您需要处理云原生工作负载以及虚拟机或裸机上的旧工作负载时，它本质上是复杂的。
以安装过程为例，Istio 项目因提供太多选择而受到批评。虽然使用 istioctl 安装 Istio 非常简单，但我们有些用户不想在生产中运行 istioctl，因为它需要更新他们的交付管道，他们必须为此寻求额外的批准。一些常用工具，如Helm已经在他们的组织中得到支持，他们可以更容易地利用这些预先批准的工具。此外，我们的一些用户希望控制平面在他们的集群之外运行，以便可以由不同的团队单独管理，因此外部控制平面是我们提供的另一种安装方法。因为每个公司或团队都有很多不同的用例和要求，我认为最好根据用户的各种要求提供选择和灵活性，而不是仅仅提供一种使用istioctl install.
Istio 也因其网络 API 的复杂性而受到批评。复杂性部分是由于可用的丰富功能同时为南北流量和东西流量提供一致的 API。有趣的是，在过去的几年里，我发现所有这些功能都是用户努力解决各种挑战所要求的。应用层组网比较复杂，从边缘到东西向的流量需要考虑很多场景，例如：

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