介绍 istiod：简化控制平面

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

Istio 控制平面的历史

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

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

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

复杂性的代价

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

• 微服务使您能够使用不同的语言编写。 数据平面（ Envoy 代理）是用 C++ 编写的，并且此边界受益于 xDS API 的清晰隔离设计。此外，所有 Istio 控制平面组件都是用 Go 编写的。我们为适当的工作选择了适当的语言：高性能的 C++ 用于代理，而在考虑易于访问和快速开发的其他所有场景都会使用 Go。

• 微服务使您能够允许不同的团队分别管理服务。 在绝大多数 Istio 安装过程中，所有组件都是由单个团队或个人安装和操作的。Istio 的组件划分与构建它的开发团队的划分是一致的，如果 Istio 的组件是由其开发团队作为托管服务交付，那么这样看起来似乎是很合理的，但事实并非如此！虽然这使得组件开发团队的工作变得更简单，但这对数量更多的普通用户的易用性产生了巨大影响。

• 微服务使您能够解耦版本，并在不同时间发布不同的组件。 控制平面的所有组件从始至终均在同一版本中发布。我们从未测试或支持运行（例如）Citadel 和 Pilot 的不同版本。

• 微服务使您能够独立扩展组件。 在 Istio 1.5 中，控制平面的开销主要决于一个功能：Envoy xDS API（对数据平面进行编程）。每个其他的功能都有边际成本，这意味着在可单独伸缩的微服务中拥有这些功能的价值很小。

• 微服务使您能够维护安全边界。 将应用程序分为不同的微服务的另一个很好的理由是，它们是否具有不同的安全角色。诸如 sidecar 注入器，Envoy 引导程序，Citadel 和 Pilot 之类的多个 Istio 微服务拥有几乎等同的更改代理配置的权限。因此，利用其中的任何服务都将造成几乎同等的损害。部署 Istio 时，默认情况下，所有组件都安装在同一 Kubernetes 命名空间中，从而提供了有限的安全隔离。

合并的好处：引入 istiod

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

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

• 安装变得更加容易。 所需的 Kubernetes deployment 和相关配置更少，因此 Istio 的配置选项和参数集大大减少了。在最简单的情况下，您只需启动单个 Pod，就可以启用一个包含了所有功能的 Istio 控制平面。

• 配置变得更加容易。 Istio 目前拥有的许多配置选项都是编排控制平面组件的方法，因此不再需要。您也不再需要更改群集范围内的 PodSecurityPolicy 来部署Istio。

• 使用虚拟机变得更加容易。 要将工作负载添加到网格中，现在只需要安装一个代理和已生成的证书即可。该代理仅连接单个后台服务。

• 维护变得更加容易。 安装、升级和删除 Istio 不再需要复杂的版本依赖关系和启动顺序。例如：要升级控制平面，您只需要在现有控制平面边上启动一个新的 istiod 版本，对其进行金丝雀部署，然后将所有流量移至该平面即可。

• 伸缩变得更加容易。 现在只有一个需要伸缩的组件。

• 调试变得更加容易。 更少的组件意味着更少的跨组件环境调试。

• 启动时间减少。 在以预定义的顺序启动时，组件不再需要彼此等待。

• 资源使用率下降，响应能力上升。 组件之间的通信将得到保证，并且不受 gRPC 报文大小限制。缓存可以被安全的共享，从而减少了资源占用。

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 找到了合适的大小。