写点什么

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

评论 1 条评论

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

进阶面试皆宜!阿里强推Java程序员进阶笔记,差距不止一点点

程序员小毕

Java spring 程序员 分布式 微服务

完美!啃透P9大佬这份完整版的《并发编程宝典》成功年前拿下心仪已久的阿里offer

Java成神之路

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

mongodb 源码实现系列 - Mongodb write写(增、删、改)模块设计与实现

杨亚洲(专注mongodb及高性能中间件)

MySQL 数据库 mongodb 架构 分布式数据库mongodb

2021最新分享:阿里内部总监手码的“Redis学习手册”风靡全网

比伯

Java 编程 程序员 架构 面试

音视频之opengl渲染图片

赖猫

音视频

币管家量化交易软件开发|币管家量化交易APP系统开发

开發I852946OIIO

系统开发

Alluxio 助力 Kubernetes,加速云端深度学习

阿里巴巴云原生

人工智能 大数据 容器 云原生 k8s

OCE等你加入

滴滴云

云计算 私有云 滴滴夜莺 Obsuite

数据库定时备份linux篇

xiezhr

数据库 Linux Shell 数据备份 3月日更

【LeetCode】分割回文串 II Java题解

HQ数字卡

算法 LeetCode 28天写作

Python 中文编码

依旧廖凯

Python 28天挑战 3月日更

职场里,对数据库要有敬畏之心!

Simon

MySQL 数据库

2021最新版!阿里P8大佬纯手打“JDK源码笔记” 带你飙向实战

Java成神之路

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

收藏!这些 IDE 使用技巧,你都知道吗

阿里巴巴云原生

Java ide 云原生 API 调度

平安智慧社区建设方案,平安小区的系统功能

13530558032

半个多月时间4面阿里,已经成功拿下offer,分享一下个人面经

Java架构之路

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

不吹不黑聊中台

小谢同学

云计算 中台 企业架构

Linux内核 设备树操作常用API

赖猫

Linux Linux内核

Linux/Centos Epoll 原理解析

赖猫

Linux 高并发 epoll

如何招聘一名产品经理

马踏飞机747

互联网 产品经理 招聘 职场成长

Java程序员福利!2021年最新17套完整版一线大厂面试真题

Java架构追梦

Java 架构 面试 金三银四 大厂面试真题

5年时间,以一个三本学历从实习生升到P7,鬼知道我经历了什么!

Java王路飞

Java 程序员 架构 分布式 算法

字节内部开发手册!堪称最全的JAVA开发手册(基础+框架+分布式微服务+调优)

Java成神之路

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

JAVA已经呈饱和趋势了吗?

cdhqyj

Java 程序员 工作 IT

WebRTC 音视频同步原理与实现

阿里云视频云

阿里云 音视频 WebRTC 流媒体

区块链电子合同应用落地--区块链电子合同签约

13530558032

什么原因才是阻碍Linux桌面发展的罪魁祸首

读字节

Linux 程序人生 国产化 redhat

智能炒币机器人软件开发|智能炒币机器人APP系统开发

开發I852946OIIO

系统开发

LDAP身份认证管理最佳实践

龙归科技

服务器 ldap 客户端

Kafka 架构中 ZooKeeper 以怎样的形式存在?

码农架构

Java 消息中间件

分布式事务与解决方案

一个大红包

28天挑战 3月日更

Leader修炼指“北”:管理路上的大小Boss

Leader修炼指“北”:管理路上的大小Boss

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