简介 istiod：简化控制平面

当微服务将服务映射到交付它们的独立团队，或者独立部署和独立扩展的价值大于编排成本时，微服务模式非常有用。我们定期与在现实世界中运行 Istio 的客户和团队进行交流，他们告诉我们，对于 Istio 控制平面来说，这些情况都不存在。因此，在 Istio 1.5 中，我们改变了 Istio 的打包方式，将控制平面功能整合到名为 istiod 的单个二进制文件中。

Istio 控制平面的历史

Istio 实现了一种多年来在 Google 和 IBM 都使用的模式，后来被称为“服务网格”。通过将客户端和服务器进程与代理服务器配对，它们充当应用程序感知的 数据平面，不仅仅是在主机之间移动数据包，或者在电线上传输脉冲。

这种模式帮助世界理解 微服务：通过轻量级协议连接的细粒度、松散耦合的服务。像 HTTP 和 gRPC 这样的通用跨平台和跨语言标准取代了专有传输，以及所需库的广泛存在，使不同的团队能够使用最适合的语言编写整体架构的不同部分。此外，每个服务可以根据需要独立扩展。对为这种网络实现安全、可观察性和流量控制的渴望推动了 Istio 的普及。

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

复杂性的代价

优秀的团队会回顾自己的选择，并在事后诸葛亮的情况下重新审视它们。通常，当团队采用微服务及其固有的复杂性时，他们会寻求其他方面的改进，以证明这些权衡的合理性。让我们从这个角度来看待 Istio 控制平面。

• 微服务使您能够使用不同的语言进行编写。 数据平面（Envoy 代理）是用 C++ 编写的，这种边界在 xDS API 方面得益于清晰的分离。但是，所有 Istio 控制平面组件都是用 Go 编写的。我们能够为合适的工作选择合适的语言：高性能的 C++ 用于代理，但其他所有工作都易于访问且开发速度快。

• 微服务使您能够让不同的团队独立管理服务。 在大多数 Istio 安装中，所有组件都是由单个团队或个人安装和操作的。Istio 内部完成的组件化与构建 Istio 的开发团队的边界相一致。如果 Istio 组件是由编写它们的团队作为托管服务交付的，那么这将有意义，但这并非如此！为开发团队简化生活对数量级更多的用户的可用性产生了过大的影响。

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

• 微服务使您能够独立扩展组件。 在 Istio 1.5 中，控制平面成本主要由一项功能决定：为对数据平面进行编程的 Envoy xDS API 提供服务。其他所有功能的成本都很低，这意味着将这些功能置于独立可扩展的微服务中几乎没有价值。

• 微服务使您能够维护安全边界。 将应用程序分成不同的微服务的另一个充分理由是，它们具有不同的安全角色。多个 Istio 微服务（如 sidecar 注入器、Envoy 启动程序、Citadel 和 Pilot）拥有几乎等效的权限来更改代理配置。因此，利用这些服务中的任何一个都会造成几乎等效的损害。当您部署 Istio 时，所有组件默认情况下都安装在同一个 Kubernetes 命名空间中，这提供了有限的安全隔离。

整合的好处：介绍 istiod

既然已经确定微服务的一些常见好处不适用于 Istio 控制平面，我们决定将它们统一到单个二进制文件中：istiod（'d' 代表 守护进程）。

让我们看看新包装的好处

• 安装变得更容易。 需要更少的 Kubernetes 部署和相关配置，因此 Istio 的配置选项和标志集大大减少。在最简单的情况下，您可以通过启动单个 Pod 来启动 Istio 控制平面，并启用所有功能。

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

• 使用 VM 变得更容易。 要将工作负载添加到网格，您现在只需要安装一个代理和生成的证书。该代理仅连接回单个服务。

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

• 可扩展性变得更容易。 现在只有一个组件需要扩展。

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

• 启动时间缩短。 组件不再需要等待彼此以定义的顺序启动。

• 资源使用量减少，响应速度提高。 组件之间的通信变得有保证，不受 gRPC 大小限制的影响。可以安全地共享缓存，从而减少资源占用。

istiod 将 Pilot、Galley、Citadel 和 sidecar 注入器以前执行的功能统一到单个二进制文件中。

一个单独的组件，istio-agent，通过将配置和机密安全地传递给 Envoy 代理，帮助每个 sidecar 连接到网格。虽然代理严格意义上仍然是控制平面的一部分，但它在每个 Pod 的基础上运行。我们通过将以前作为 DaemonSet 运行的每个节点功能滚动到每个 Pod 代理中，进一步简化了操作。

专家补充

仍然有一些情况，您可能希望独立运行 Istio 组件，或替换某些组件。

有些用户可能希望在网格之外使用证书颁发机构 (CA)，我们有 关于如何执行此操作的文档。如果您使用不同的工具进行证书配置，我们可以使用该工具而不是内置的 CA。

展望未来

istiod 的核心只是一个打包和优化更改。它基于与独立组件相同的代码和 API 合同，并继续受到我们全面的测试套件的覆盖。这让我们有信心在 Istio 1.5 中将其设为默认值。该服务现在称为 istiod - 您将在升级过程完成后看到用于现有代理的 istio-pilot。

虽然迁移到 istiod 看起来是一个很大的变化，并且对管理和维护网格的人来说是一个巨大的改进，但它不会改变使用 Istio 的日常工作。istiod 不会更改用于配置网格的任何 API，因此您现有的流程将保持不变。

这种变化是否意味着微服务对于所有工作负载和架构来说都是错误的？当然不是。它们是工具箱中的工具，并且在反映您的组织现实时效果最佳。相反，这种变化表明该项目愿意根据用户反馈进行更改，并继续专注于简化所有用户的操作。微服务必须适度，我们相信我们已经找到了 Istio 的适当规模。