介绍 istiod:简化控制平面

Istiod 将 Istio 控制平面组件合并为一个二进制文件。

Mar 19, 2020 | By Craig Box - Google

当服务需要由不同的团队交付,或者单独部署及扩展的价值高于编排的成本时,微服务是一种很好的模式。我们定期与在现实世界中运行 Istio 的客户和团队进行交流,他们告诉我们,对于 Istio 控制平面而言,情况并非如此。因此,在 Istio 1.5 中,我们更改了 Istio 的打包方式,将控制平面功能合并为一个被称为 istiod 的二进制文件。

Istio 控制平面的历史

Istio 实现了一种已在 Google 和 IBM 使用多年的模式,该模式后来被称为“服务网格”。通过代理服务器将客户端和服务端进程配对,它们可以充当应用程序感知的 数据平面 ,而不仅仅是在主机间传输数据包或通过网络传输脉冲信号。

这种模式有利于全世界的工程师通过 微服务 达成共识:通过轻量级协议连接细粒度、松散耦合的服务。通用的跨平台和跨语言标准(例如 HTTP 和 gRPC )取代专有传输方式,且各种语言都有相关的库,使得不同的团队能够以最适合的语言编写整个体系架构的不同部分。此外,每个服务可以根据需要独立扩展。对这样的网络实施安全性、可观测性和流量控制的愿景推动了 Istio 的普及。

Istio 的 控制平面 本身就是一种现代的云原生应用程序。因此,它从一开始就作为一组微服务而构建。诸如服务发现(Pilot),配置(Galley),证书生成(Citadel)和可扩展性(Mixer)等各个 Istio 组件都被编写并部署为单独的微服务。这些组件需要安全地进行通信并易于观察,这为 Istio 提供了“吃自己的狗粮”的机会(或“喝自己的香槟”,更法语化的比喻!)。

复杂性的代价

优秀的团队会回顾他们的选择,并借助事后回顾重新审视当时的选择。通常,当团队接受微服务及其固有的复杂性时,他们会在其他方面寻求改进以证明其取舍的正确性。让我们看一下此视角下的 Istio 控制平面。

合并的好处:引入 istiod

在确定微服务的许多常见好处并不适用于 Istio 控制平面之后,我们决定将它们统一为一个二进制文件:istiod( ’d’ 代表 daemon)。

让我们看一下新打包方式的好处:

istiod 将先前由 Pilot,Galley,Citadel 和 sidecar 注入器执行的功能统一为一个二进制文件。

单独的组件 istio-agent 通过将配置和密钥安全地传递给 Envoy 代理,来帮助每个 sidecar 连接到网格。严格来说,尽管该代理仍然是控制平面的一部分,但它是按 per-pod(每 pod ) 运行的。通过将以前作为 DaemonSet 运行的 per-node(每节点) 功能移动到 per-pod(每 pod )代理中,我们进一步简化了操作。

专家说明

在某些情况下,您可能仍然想要独立运行 Istio 组件或替换某些组件。

一些用户可能想在网格外部使用证书颁发机构(CA),我们有如何执行此操作的文档。如果您使用其他工具进行证书设置,则可以使用它代替内置 CA。

进阶

本质上,istiod 只是打包和优化方面的改变。它与单独的组件基于相同的代码和 API 契约构建,并且仍由我们全面的测试套件覆盖。这使我们有信心将其设置为 Istio 1.5 中的默认设置。该服务现在称为 istiod - 在升级过程完成时,您会看到一个用于现有代理的 istio-pilot

虽然迁移到 istiod 似乎是一个巨大的变化,并且对于 管理维护 网格的人员来说是一个巨大的改进,但它不会让 使用 Istio 的日常生活变得有何不同。istiod 不会更改用于配置网格的任何 API,因此您现有的进程不会有什么变化。

这是否意味着微服务对于所有工作负载和架构设计都是错误的?当然不是。它们只是工具箱里的工具,当它们适合您组织的真实情况时,可以发挥最佳的作用。恰恰相反,此变更(引入 istiod )表明了 Istio 项目愿意根据用户的反馈进行更改,并为了所有用户持续专注于简化操作。微服务的大小必须合适,而我们相信我们已经为 Istio 找到了合适的大小。

Share this post