2.7　附加组件

集群附加组件广泛涵盖了那些分布在Kubernetes集群上平台服务的附件。在本节中，我们将不涉及安装什么附加组件到集群中的内容，这是本书其他章节的主题。本节将讲解如何安装附加组件，这些组件将把你原始的Kubernetes集群变成一个生产就绪的、对开发者友好的平台。

你添加到集群中的附加组件应该被看作部署模型的一部分。附加组件的安装通常会构成集群部署的最后阶段。这些附加组件应该与Kubernetes集群一起进行管理和版本控制。将Kubernetes和组成平台的附加组件视为一个包，一起进行测试和发布是很有用的，因为某些平台组件之间不可避免地存在版本和配置依赖。

kubeadm安装了“必需的”附加组件，这是通过Kubernetes项目的一致性测试所必需的（包括集群DNS和kube-proxy），它实现了Kubernetes服务资源。然而，还有许多类似的关键组件需要在kubeadm完成其工作后应用。最明显的例子是一个容器网络接口插件。如果没有一个Pod网络，你的集群将没有什么作用。可以说，你最终会有一个重要的组件列表需要添加到你的集群中，通常是以DaemonSet、Deployment或StatefulSet的形式，为你在Kubernetes上构建的平台添加功能。

在2.3节中，我们讨论了集群联邦和新集群在该系统中的注册。这通常是附加组件安装的前奏，因为系统和安装的定义通常存在于管理集群中。

无论使用什么架构，一旦实现注册，就可以触发集群附加组件的安装。这个安装过程将是对集群API服务器的一系列调用，以创建每个组件需要的Kubernetes资源。这些调用可以来自集群外部或内部的系统。

安装附加组件的一种方法是使用现有工具（如Jenkins）的持续交付管道。在这种情况下，“持续”部分是不相关的，因为触发器不是一个软件更新，而是一个新的安装目标。CI和CD的“持续”部分通常指的是一旦新的变化被合并到版本控制的源代码分支中，软件就会自动推出。触发安装集群附加软件到一个新部署的集群是一个完全不同的机制，但很有用，因为管道通常包含安装所需的能力。需要实现的仅是调用运行一个管道，以响应一个新集群的创建以及任何变量参数，以形成正确的安装。

另一种更适合Kubernetes的方法是使用Kubernetes operator来完成任务。这种更高级的方法包括用一个或多个自定义资源来扩展Kubernetes API，允许你定义集群的附加组件及其版本。它还涉及编写控制器逻辑，可以根据自定义资源中定义的规格执行附加组件的正确安装。

这种方法很有用，因为它为集群的附加组件提供了一个中心化、明确的来源。但更重要的是，它提供了对这些附加组件的生命周期进行程序化管理的机会。缺点是开发和维护更复杂软件的复杂性。如果你承担了这种复杂性，应该是因为你将实施升级和持续的管理，这将大大减少未来的人力劳作。如果你只停留在安装阶段，而不开发管理升级的逻辑和功能，你将耗费大量的工程量，却没有什么持续的好处。Kubernetes operator通过对代表所需状态的自定义资源的观察功能，在持续的运营管理中提供了最大的价值。

附加组件operator的概念并不一定完全独立于外部系统，如CI/CD。在现实中，它们更可能被结合使用。例如，你可以使用CD管道来安装operator和附加的自定义资源，然后让operator来接管。此外，operator可能需要获取安装声明文件，也许是从包含附加组件的模板化Kubernetes清单的代码库中获取。

以这种方式使用operator，可以减少外部依赖，从而推动可靠性的提高。然而，外部依赖是不能一并消除的。只有当你的工程师对Kubernetes的操作模式非常了解，并且有利用它的经验时，才可以使用operator来解决附加组件的问题。否则，坚持使用你的团队很熟悉的工具和系统，同时提高你的团队在这个领域的知识和经验。

现在我们结束了安装Kubernetes集群及其附加组件的系统的步骤，接下来将目光转向与升级相关的问题。