骑虎：实施Istio的经验教训

最近，我(和其他几个比我聪明得多的人)有机会用Istio实现了一个“真正的”生产系统，运行在托管的云提供的Kubernetes服务上。

Istio以难于构建和管理而闻名，但我没有读过多少关于试图让它发挥作用的战争故事，所以我想，对于一个试图实现这些东西的“典型”团队来说，真正写下战壕里的情况可能会很有用。我们的目的很大程度上不是要埋葬Istio，而是要赞扬它(它做了很多对“真正的”Kubernetes集群有用/必要的事情-如果不耐烦了就跳到最后)，同时警告那些即将填补漏洞的人，如果你没有准备好会发生什么。

简而言之，我希望在我们开始我们的“旅程”之前能找到一篇这样的文章。

当与其他技术相结合时，我们中没有人是Istio的有经验的实施者。作为研究的一部分，我们中的大多数人都有大约半年的Kubernetes工作经验，并在一次性集群上开发过不止几次Vanilla Istio。

每当我们遇到困惑、不确定或误解的障碍时，我们都会求助于通常的本地/友好/远程升级途径中的专业知识。

“当地”的道路是项目中的人。“友好的”道路是我们知道的社区中的人，他们是Istio专家(在Kubecon和类似的地方进行演讲)。一位这样的专家向我们承认，他们使用Linkerd“直到他们绝对需要Istio做点什么”，这让我们感到惊讶。“遥远”的道路主要是伊斯蒂奥论坛和伊斯蒂奥松弛频道。

每当我们互相伸出援手时，我们都会惊讶地发现，似乎很少有人在做我们正在做的事情。

这已经不是第一次了，因为库伯内斯我在想：我们不可能是世界上唯一想做这件事的人吧？&'；pic.twitter.com/cqFE0EQZj2(英语：http：//www.pic.twitter.com/cqFE0EQZj2/cqFE0EQZj2)

-Ian Miell(@ianmiell)2020年4月6日。

一个监控堆栈，我们实际上可以根据需要进行配置，而不需要只接受“非生产就绪”默认值。

也许我们是白痴，可以从纸袋中配置出一条路来，但它感觉，除了使用101个指南或接受默认设置之外，根本没有那么多现有的技术。

最终，我们让一切都按照我们想要的方式工作，但是我们在这个过程中消耗了大量的开发人员时间，并且在这个过程中不止一次几乎放弃了我们的努力。

我们通过关注博客和文档成功地进行了小型实验，受此鼓舞，我们乐观地尝试着跳过，让所有东西都能同时工作。幸运的是，我们使用完全GitOps的工作流运行了严格的管道，这意味着几乎没有什么“在我的集群上工作”的问题会减慢我们的速度(如果你不这样做，那就这么做吧)。它不一定要非常复杂才会非常有用)。

同样的问题：任何人都有解决方案吗？你：-想要mTLS打开-想要pod2pod通信工作并自动加密(可能主机被选中，因为pod IP不会被放入证书)尝试了许多看起来可能有效的东西，但不要。

-Ian Miell(@ianmiell)2020年4月9日。

监控就是一个很好的例子。如果您只是阅读文献，那么设置监控堆栈是轻而易举的事。在空服务器上运行默认的Istio安装，一切都是免费的。太棒了。然而，我们犯了一个错误，认为这意味着为了我们自己的目的摆弄这个堆栈相对容易。

首先，我们尝试使用严格的mTLS模式(这不是默认模式，原因非常充分)。然后，我们尝试让监控堆栈在单独的名称空间中运行。然后，我们试图通过严格的全球网络策略“全盘拒绝”来实现这一切。这三件事都造成了巨大的困惑，当它不是“只起作用”时，就会耗费数周的工程时间来解决问题。

结论是：当将Istio与其他Kubernetes技术一起使用时，不要低估更改默认值的难度。最好从简单开始，然后努力建立一个更全面的心理模型，为你的未来提供更好的服务。

如果你喜欢这本书，你可能会喜欢我的一本书：以艰难的方式学习打击以艰难的方式学习Git以艰难的方式学习Terraform。

Istio有很多在其他相关上下文中过载的术语。通常使用的术语，如“集群”或“注册表”，根据上下文的不同可能具有非常特定的含义或意义。这并不是Istio独有的疾病，而是文档的密度和必须嵌入到您的理解中的概念的数量，才能流畅地解析它们。

我们花了大量的时间来解读这些文献的段落，就像神学家在为死海古卷争论不休(“但是群集在这里意味着网格”、“不，它意味着进入Kubernetes群集”、“那是虚拟服务，而不是服务”、“无头服务与正常服务完全不同！”)。“。

入口网关描述了在网格边缘运行的负载均衡器，该均衡器接收传入的HTTP/TCP连接。它配置公开的端口、协议等，但与Kubernetes Inress Resources不同的是，它不包括任何流量路由配置。入口流量的流量路由改为使用Istio路由规则进行配置，其方式与内部服务请求完全相同。

我现在可以读到它，并且几乎可以理解它试图实时传达的信息。欺负我吧。现在想象一下，为了让他们帮你弄清楚一些事情，把它发送给一个不是完全精通网络的人，Kubernetes和Istio。就像项目中的某个人对我说的那样：“Istio Docs是很棒的…。如果你已经是一名Istio开发商的话。

顺便说一句，花点时间熟悉一下文档的结构是个好主意，因为尝试和定位自己很快就会变得令人抓狂：‘我之前看到的关于Inress TLS的那篇文章该死的在哪里？是在概念、设置、任务、示例、操作还是参考中？“

在开发Istio时，我们发现在一个版本中做不到的事情开始在另一个版本中工作，而我们正在调试它。

当我们谈到这个问题时，也要认真对待升级：我们做了一个看起来无伤大雅的升级，但有一些东西坏了，让系统停用了一天。所有信息都在那里，但在发布说明中很容易跳过。

伙计们，你付出什么就会得到什么，所以这应该是在一个更大的软件组件(Kubernetes)中运行的这样一组基本的软件组件(Istio)中应该预料到的！

如果您知道您将认真地使用Istio，请尽可能地抽出时间来提高您的调试技能。

不幸的是，文档有点分散，所以我们遇到了一些可能会有帮助的链接：

当你迷失在迷宫中时，很容易忘记Istio能给你带来什么力量和好处。

入口和出口控制、相互TLS(免费)、可观察性快速启动、流量整形…。名单还在继续。它的功能集是无与伦比的，它已经占据了市场份额，而且资金充足。我们不想放弃它，因为所有这些功能一举解决了无数需求。这些要求并不那么切合实际，所以这就是为什么我认为Istio短期内不会消失的原因。

这里真正的教训是，您不能逃避管理所有功能的复杂性，并期望能够随意操作和控制它，而不需要任何艰苦的工作。

相应地为它做预算，并投入必要的时间和精力来从骑老虎中获益。