QCon全球软件开发大会9折优惠倒计时,了解详情 了解详情
写点什么

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

2021 年 5 月 28 日

使用两年之后,我为什么卸载了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:496571

评论 1 条评论

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

0门槛成为“技术牛人”!星环科技线上分享课“星课堂”开播,快来报名,一探究竟

星环科技

人工智能 数据库 云计算 大数据 直播技术

简简单单才是真,初试 Svelte

LeanCloud

大专学历,CRUD3年进大厂面经分享!鬼知道我是怎么过来的!

程序员小毕

Java spring 程序员 架构 面试

家务活中的python协程

行者AI

协程 python学习

一个诡异的MySQL查询超时问题,居然隐藏着存在了两年的BUG

CoderW

Java MySQL 数据库 程序员 互联网

混搭的美感|靠谱点评

无量靠谱

TcaplusDB君· 行业新闻汇编(4月21日)

TcaplusDB

数据库 nosql 分布式 TcaplusDB

智汇华云 | ArSDN打通软件定义数据中心的“任督二脉”

华云数据

一文搞定 Flink Job 的运行过程

shengjk1

flink flink源码 flink源码分析

华云大咖说 | 华云数据与数科网维携手共建国产云生态

华云数据

GitHub惊现!JVM G1GC的算法+实现,90张图+33段代码,你的面试专属!

Java架构师迁哥

2021年3月券商App行情刷新及交易体验评测报告

博睿数据

恒源云_Gpushare.com | 三步搞定GPU免费云端训练!

恒源云

人工智能 深度学习 gpu CV nlp

2020年12月的面试经历:美团4面+字节4面(均已拿offer),面试真题分享

Java架构师迁哥

聪明人的训练(二十二)

Changing Lin

4月日更

百度C++工程师的那些极限优化(内存篇)

百度Geek说

c++ C# 内存访问

Redis学习01

Hex

Redis 核心技术与实战

浪潮云洲链接入“星火•链网”,走向工业互联网的星辰大海

浪潮云

云计算

肝了15000字性能调优系列专题(JVM、MySQL、Nginx and Tomcat),看不完先收藏

北游学Java

Java MySQL nginx tomcat JVM

新疆重点人员管控平台搭建,可视化大屏

13823153121

低代码与数字化校园应用案例:2周时间构建50+应用,直呼过瘾!

优秀

低代码 数字化校园

恒源云_Gpushare.com | RTX 3090独家训练实录:MMDetectionV2 + ResNeSt

恒源云

人工智能 深度学习 gpu CV nlp

重磅来袭:Spring之RequestBody的使用姿势小结

学Java关注我

Java 编程 架构 技术 程序人生

彻底搞懂ThreadLocal

千珏

Java 源码分析 多线程 ThreadLocal

如何深入的学习C语言

cdhqyj

编程 C语言 计算机 嵌入式

打造创新模型,博睿数据首倡服务可达的数据链DNA

博睿数据

面向软件 IT 专业的高校大学生付费学习现状问卷调研

HQ数字卡

4月日更

软件测试——教育机构课程顾问常见黑话大全

程序员阿沐

程序员 软件测试 教育 机构 教育培训

Redis为什么是单线程?高并发响应快?

Linux服务器开发

redis Linux服务器开发 网络io C++后端开发 单线程

博睿数据携数据链DNA创新理念,闪耀金融科技应用发展研讨会四川站

博睿数据

拒绝假货!LVMH与普拉达、卡地亚联手推出区块链平台AURA

CECBC区块链专委会

数据库运维技术发展与展望

数据库运维技术发展与展望

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