InfoQ 编辑部出品——2021年度技术盘点与展望 了解详情
写点什么

使用两年之后,我为什么卸载了 Istio?

  • 2021 年 5 月 28 日
  • 本文字数:3122 字

    阅读完需:约 10 分钟

使用两年之后,我为什么卸载了Istio?

在生产中使用了 Istio 近两年之后,我们要和它说再见了。


服务网络大战正在肆虐。现在我把票投给了 Linkerd。


服务网格提供了微服务之间的流量监控,包括服务通信的映射和在它们之间生成的 HTTP 状态码。通过添加服务网格,你可以在服务间添加 mTLS,或者换句话说,可以在服务间添加加密的 HTTP 通信。


在我看来,这两个工具几乎对所有人都很有用。许多服务网格都提供了诸如流量分割、重试、超时等高级功能。我很少相信这些功能是有用的,或者我认为这不应该是由 Sidecar 代理来处理的功能。它们经常被错误地用来尝试解决一个本该以其他方式解决的问题。


但另一方面服务网格很难。如果你要使用任何一种服务网格,都需要一个艰苦的过程才能学到一些知识:


  • 服务网格目前只能可靠地支持 HTTP 通信


我有使用 Istio 和 Linkerd 的经验,它们都声称支持许多协议。我发现这很不可靠。Istio 对某些数据库协议的支持在不同版本之间存在中断。Linkerd 中断了 ampq 通信。在这两个平台上使用 HTTPS 经常会抛出一些奇怪的错误。我的印象是,编写一个透明的网络代理是极其困难的。在这一点上,我只相信一个带有 HTTP 通信的服务网格,无论如何,这是我想要的,因为那是 Kubernetes 服务之间通信的流量。


  • 在 Sidecar 代理运行之前,应用程序容器的网络调用都将失败


这一点尤为糟糕,这也是我认为服务网格尚不适用于所有人的主要原因。应用程序容器可能会在 Sidecar 代理之前启动,在这种情况下,它将无法完成需要由 Sidecar 代理来配置处理的网络请求。


可以借用 Kubernetes 的故事来制作 Sidecar(你可以标记 Pod 中某个容器中为自旋向上的 Sidecar)。它原本计划在 1.20 版本中发布,但现在为了支持尽可能多的用例而推迟了。


无论如何,总有一些技巧可以解决这个问题,但这意味着成功实现一个服务网格对开发人员来说不再是透明的,因为他们需要修改一些代码或部署。


  • 初始化容器和 CronJob 不能使用服务网格


为什么呢?服务网格代理容器永远不会退出。如果它永不退出,那么初始化容器和 CronJob 就永远不会真正“完成”。对容器来说,你的应用程序容器将永远不会启动,对 CronJob 来说,你的 CronJob 将超时并被标记为失败。


可能有一些解决方法,但我从未发现有任何建议是非常实用的。


我已经成功地在生产和预发集群中使用了服务网格,但有两个限制条件,只让 Sidecar 代理监控 HTTP 通信;将 mTLS 设置为可选(如果某个 Pod 不在网格上,它仍然可以与网格上的另一个 Pod 通信)。


我不在审查集群上使用服务网格。把审查应用程序放到服务网格中有太多的问题需要解决了。


为什么我卸载了 Istio?


简而言之,因为操作复杂。学习 Istio 的时间与我第一次学习 Kubernetes 的时候差不多长。


通过配 Helm 来部署 Istio 需要花费数周的时间(相比之下,我几乎总能在一天之内完成一个新 Helm 的配置)。


Istio 重度依赖 CRD。我尽量避免使用 CRD,因为它们会造成供应商锁定。他们的 CRD,比如,必不可少的 Gateway、VirtualService、DestinationRule 都要花费一些时间来理解,而且我阅读它们文档的次数比我能接受的要多得多。


Istio 用起来很吓人。我经历过一个巨大的单点故障,当开发人员误命名了包含 TLS 密钥的 Kubernetes 密钥时,每个网关都中断了,整个集群都垮了。这是一个 bug,如果 Istio 无法找到密钥,它将无法配置并停止所有服务。这调试起来非常困难。日志中没有任何内容可以指出到底出了什么问题。Istio 很少在其他方面完全失效,通常与它将配置传递给 Envoy 代理的方式有关。他们称之为“碎玻璃配置”(“Break Glass Configuration”)。


最后,也是最重要的一点是,Istio 不推荐使用 Helm 部署,而是推荐使用他们的 istioctl 命令行实用程序……然而,他们在更高的版本中重新引入了 Helm 的部署。我不喜欢用一堆不同的方法在集群上部署 40 多个支持工具,所以当他们弃用 Helm 时,我非常失望,我使用的其他工具都支持 Helm。当我发现这只是暂时的时候,我更加沮丧。这意味着我必须离开后再回来升级到最新的 Istio 版本。


当初我为什么会选择 Istio ?


当 Kubernetes 刚出现时,它还有其他 3 个主要竞争对手:Mesos、 Nomad 和 Swarm。很快,Kubernetes 就赢得这场战争。


我从未遇到过使用 Mesos 的人,这可能是因为它没有得到大公司的支持,尽管我听说过 Mesos 对容器编排有着巨大的影响。


我见过的唯一使用 Swarm 的人,是因为 Swarm 比 Kubernetes“更简单”才使用的。我知道这不会长久的。它的“简单”实际上是缺乏功能。如果你只使用 Kubernetes 特性中的一小部分,Kubernetes 也很简单。


Nomad 现在还很活跃,如果你需要将流程直接编排到服务器上,那么这就是你的选择。如果你只需要容器编排,我强烈推荐你使用 Kubernetes。


不管怎样,当 Istio 问世时,情况看起来非常熟悉。唯一的竞争对手是 Linkerd(我想在我的心目中这是一个 Swarm 类型的竞争对手),而 Istio 就像 Kubernetes 一样,是谷歌的“孩子”。所以我选择了 Istio。


然后,服务网络大战开始了。首先出现的是 AWS 的 AppMesh,然后是 Traefik 的 Maesh,再然后是 Azure 的 Open Service Mesh(这可能是对 Istio 不加入 CNCF 争议的一种讽刺),以及 Nginx 的服务网格。还有一些其他的,大多数都是使用 Envoy 代理来创建他们的服务网格,如 Kuma 和 Consul Connect。


这看来根本没有明显的赢家。


现在该用什么?


在比较了所有的服务网格之后,我最终选择了 Linkerd,也就是最初的那个。其他的要么想偷偷进入供应商锁定,要么只是没有按照我想要的方式工作(比如 Maesh,它向节点添加是代理而不是 Pod)。


我喜欢 Linkerd 的原因在于:


它支持使用 Helm 进行部署(实际上,我在所有部署中都使用了 Helm 的修改版本,并且我使用了一些自定义的代码来避免外部手动配置)。它相当简单。你只需要一个 CRD,Helm 图也很易学。它们的仪表盘很顺滑。Istio 使用 Grafana/Promethus 和 Kiali。Linkerd 也支持 Grafana/Prometheus,但它还有一个专用的定制仪表盘,很易于使用。它们用 Rust (v2)编写了自己的代理。起初我对此感到很困惑,因为 Envoy 如此受欢迎,但后来我意识到 Linkerd 可以快速发展。Envoy 现在是一个庞然大物,必须对许多供应商保持中立,但是 Linkerd 可以对自己的代理做任何想做的事情,从而使开发速度更快。而且,它是用 Rust 写的!很酷,对吧?它们加入了 CNCF。而 Isito 没有…Linkerd 第一步做对了。Istio 试图尝试一系列不同的部署,你必须管理它们,但现在它们已经转移到单一部署上了。Linkerd 是第一个这样做的。它确实有其他部署,但都不是“核心”的。它们增加特性后,你只需要关注核心部署就可以让你的服务网格工作了。


Linkerd 有什么不足之处吗? 其实只有一件小事。我想这更像是一种营销手段。他们声称这是一个服务网络,你可以在 5 分钟内安装并使用它,一切都能准备好。但是,正如上文所述,服务网格并不是简单地准备就绪就行了。Linkerd 也存在每个服务网格都有的问题:缺少原生 Sidecar 和不可靠的非 HTTP 协议处理。


小结


也许有一天,你使用哪个服务网格只是一个小问题,就像很多人甚至不知道他们在 Kubernetes 上使用的是什么覆盖网络一样。每个服务网格都在采用 SMI(服务网格接口),因此从长远来看,我认为服务网格将会成为 Kubernetes 中的原生资源,而采用开放标准就是朝这个方向迈出的第一步。


Istio 尚未加入 CNCF,尽管 Chris DiBona 在 Kubernetes Podcast 上做了解释,但我还是不太喜欢这个举动。Linkerd 加入了 CNCF。如果它能保持一贯的简洁,短时间内,我不打算在离开它。一旦 Kubernetes 获得了某种原生的 Sidecar 解决方案,我会非常高兴。


延伸阅读:


https://medium.com/polymatic-systems/service-mesh-wars-goodbye-istio-b047d9e533c7


2021 年 5 月 28 日 17:496960

评论 1 条评论

发布
用户头像
翻译问题太多了。。。看了原版文章才懂
2021 年 06 月 06 日 00:10
回复
没有更多了
发现更多内容

CEG挖矿系统APP开发|CEG挖矿软件开发

系统开发

大作业一

黄立

软件测试所需要掌握的技能

测试人生路

软件测试

3D 可视化突发公共卫生事件 ,防护效率高达90%

一只数据鲸鱼

疫情 物联网 数据可视化 数据监测 3D可视化

第八课性能优化作业-判断合并链表

Geek_michael

极客大学架构师训练营

区块链食品溯源系统开发,农产品溯源小程序搭建

13530558032

LeetCode题解:剑指 Offer 40. 最小的k个数,sort,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

智慧平安小区整体解决方案,智慧社区管控系统开发

13530558032

ModelArts黑科技揭秘|弹性训练,让训练资源张弛有度

华为云开发者社区

学习 华为云

浅谈如何做客户端性能测试

行者AI

性能测试

工具词典:精力管理

lidaobing

精力管理 张遇升 28天写作

圣诞狂欢,保险师APP赋能精细、个性化的运营服务

DT极客

窝家恶补三月,字节跳动三面,终于喜提offer!分享面试感受

Java架构之路

Java 程序员 架构 面试 编程语言

程序员开发指南!1-3年的Android开发工程师看过来,经典好文

欢喜学安卓

android 程序员 面试 移动开发

ZooX首发双向电动无人车,会成为自动驾驶出行的主流吗?

脑极体

甲方日常 75

句子

工作 随笔杂谈 日常

劫持Chrome浏览器“获利”8000万元 | 法庭上的CTO(13)

赵新龙

CTO 法庭上的CTO

(经验分享)作为一名普通本科计算机专业学生,我大学四年到底走了多少弯路

Java鱼仔

Java 程序员 面试 大学生

阿里“云钉一体”加速整合 低代码开发平台“钉钉宜搭”发布

人称T客

这份阿里P8级别内部疯传的“Linux私房菜”让你一次吃个饱

Java架构之路

Java 程序员 架构 面试 编程语言

Java程序员晋升之路:“Java高级核心知识全面解析”

Java架构之路

Java 程序员 架构 面试 编程语言

为新基建按下加速键:从openEuler看中国操作系统的产业生态未来

脑极体

业务架构设计迭代演进思路

程序员架构进阶

架构 中台 业务架构

大佬带你看源码!阿里内部Android笔记火爆IT圈,3面直接拿到offer

欢喜学安卓

android 程序员 面试 移动开发

阿里P8大牛手把手教你!高级Android晋升之View渲染机制,先收藏了

欢喜学安卓

android 程序员 面试 移动开发

创建493个测试账户,被公司索赔527万 | 法庭上的 CTO(14)

赵新龙

CTO 法庭上的CTO

如何通过一个SDK轻松搞定人脸识别,拯救初入职场的程序猿

华为云开发者社区

人脸识别 智能 识别

Alibaba面试官:“这该死的程序员,知识竟如此渊博!”

Java架构之路

Java 程序员 架构 面试 编程语言

字节面试坎坷之路,第一次二面凉了!捞起来之后一面就凉了;我太难了呀!

Java架构之路

Java 程序员 架构 面试 编程语言

腾讯大牛亲自带你学:Java安全weblogic T3协议漏洞!

比伯

Java 编程 架构 面试 计算机

这个问题值得讨论吗?

Alan

沟通 团队文化 七日更 28天写作

ShadowRealm 与微前端沙箱

ShadowRealm 与微前端沙箱

使用两年之后,我为什么卸载了Istio?-InfoQ