Kubernetes扩展

Kubernetes 扩展

本文介绍通过 Kubernetes 扩展机制更改集群行为的多种方法。

Kubernetes 系统本身能够通过多种方式进行配置和扩展，使得使用者通常不需要通过复制（fork）整个项目代码或者向项目代码提交补丁的方式来满足自己的特定需求。

这份指南详细阐述了对 Kubernetes 集群进行自定义配置的可行选项。其主要目标受众为集群运维人员，旨在助力他们深入掌握如何让 Kubernetes 集群契合自身工作环境的特定需求。对于有意愿成为平台开发人员或是参与 Kubernetes 项目贡献的开发者而言，此指南同样颇具价值。它不仅清晰介绍了现存的各类扩展点与模式，还深入剖析了采用这些扩展点和模式时需要权衡的因素以及可能存在的限制。

在对系统进行自定义时，方法大致可划分为配置与扩展这两大类别。其中，配置所涵盖的操作较为单一，仅涉及对命令行参数、本地配置文件，或者 API 资源的更改；而扩展的范畴则更为广泛，它涉及到运行额外的程序、增设额外的网络服务，甚至可能是二者兼而有之。在本份文档中，将主要围绕扩展方面展开深入介绍，呈现相关技术细节与应用场景 。

配置

配置文件和命令参数记录在在线文档的参考部分中，每个二进制文件都有一个对应的页面。

• kube-apiserver¹
• kube-controller-manager²
• kube-scheduler³
• kubelet⁴
• kube-proxy⁵

在托管的 Kubernetes 服务或采用托管安装方式的发行版中，命令行参数与配置文件并非总能随意更改。即便可以修改，通常也仅允许集群管理员进行操作。此外，随着 Kubernetes 后续版本的更迭，这些参数和文件设置极有可能发生变动，并且在调整它们时，往往需要重启相关进程。鉴于上述原因，建议仅在别无他法的情况下，才考虑使用更改命令行参数和配置文件的方式。

诸如 ResourceQuota（资源配额）、NetworkPolicy（网络策略）以及基于角色的访问控制（RBAC）这类内置策略 API，是 Kubernetes 自带的 API，它们能够以声明式配置的方式来设定策略。即便在使用托管的 Kubernetes 服务或采用托管安装方式的环境中，这些 API 通常也都能正常发挥作用。内置策略 API 与 Pods 等其他 Kubernetes 资源遵循相同的规范。当使用稳定的策略 API 时，就像使用其他 Kubernetes API 一样，能得益于既定的支持策略。这意味着在 Kubernetes 系统的运行过程中，无论是在不同版本更迭时的兼容性，还是日常运维管理中的稳定性，稳定的策略 API 都有相应的保障机制。基于上述原因，在适用的场景下，相较于配置文件和命令参数，更推荐使用策略 API。因为使用策略 API 不仅能确保策略配置的规范性和稳定性，还能有效降低因配置不当引发问题的风险，让 Kubernetes 集群的管理和运行更加可靠。

扩展

扩展是一类软件组件，它们能够对 Kubernetes 进行功能拓展，并与之深度融合。借助这些扩展，Kubernetes 得以适配并支持新的类型以及各种新型硬件。

众多集群管理员选用托管的 Kubernetes 实例或发行版。这些集群在部署时便已预先安装了各类扩展，这一特性使得大部分 Kubernetes 用户无需自行安装扩展；进一步来说，需要自主编写新扩展的用户更是少之又少。

扩展模式

Kubernetes 旨在通过编写客户端程序实现自动化操作。实际上，任何能够对 Kubernetes API 进行读取和（或）写入操作的程序，都能为系统带来实用的自动化功能。这种自动化功能的运行位置较为灵活，既可以在 Kubernetes 集群内部执行，也能在集群外部发挥作用。依据本文档提供的指导，用户能够编写出具备高可用性和强大稳定性的自动化程序。值得一提的是，这类自动化程序通常具有广泛的适用性，无论是托管集群，还是采用托管安装方式的 Kubernetes 集群，都能顺利运行 。

在编写与 Kubernetes 协同良好的客户端程序时，存在一种特定模式，即控制器模式。控制器通常会读取对象的 .spec（规范）部分，这部分定义了对象期望达到的状态。之后，控制器可能会依据所读取的规范执行一系列操作，例如调配资源、调整配置等。完成这些操作后，控制器会更新对象的 .status（状态）部分，以此来反映对象实际的运行状态，确保对象的实际状态与期望状态保持一致，从而实现对 Kubernetes 资源的有效管理和自动化控制。

控制器是 Kubernetes API 的客户端。当 Kubernetes 充当客户端去调用远程服务时，Kubernetes 将此调用行为称作 Webhook，而被调用的远程服务则被称为 Webhook 后端。和自定义控制器相同，Webhook 的确会增添一个故障点。

在 Kubernetes 体系之外，“webhook” 这一术语通常指的是一种异步通知机制，其中 webhook 调用以单向通知的形式发往另一个系统或组件。而在 Kubernetes 生态系统里，即便是同步的 HTTP 调用，也常被称作 “webhooks” 。

在 Webhook 模型里，Kubernetes 会向远程服务发起网络请求。与之不同，在二进制插件模型中，Kubernetes 执行的是一个二进制文件（程序）。二进制插件既被 kubelet 使用（比如 CSI 存储插件和 CNI 网络插件） ，也被 kubectl 使用（可参考使用插件扩展 kubectl）。

扩展点

Kubernetes 集群中的扩展点以及访问它的客户端包括：

1. 用户常常借助 kubectl 与 Kubernetes API 展开交互。插件能够对客户端的行为进行自定义。既存在可应用于不同客户端的通用扩展，也有专门针对 kubectl 进行扩展的特定方法。
2. API 服务器负责处理所有请求。在 API 服务器中，存在多种类型的扩展点，这些扩展点能够实现对请求的身份验证，或是依据请求内容阻止请求、编辑内容以及处理删除操作。
3. API 服务器提供各类资源。像 pods 这类内置资源类型，由 Kubernetes 项目定义，无法被修改。
4. Kubernetes 调度器决定将 Pod 放置在哪些节点上。有多种方法可以扩展调度功能。
5. Kubernetes 的诸多行为由被称作控制器的程序来实现，这些控制器是 API 服务器的客户端，并且通常会与自定义资源配合使用。
6. kubelet 部署于服务器（节点）上，它可使 Pod 在集群网络中宛如拥有独立 IP 的虚拟服务器。网络插件支持以不同方式构建 Pod 网络。
7. 可借助设备插件集成自定义硬件或其他特殊的节点本地设施，让这些设施能供集群中运行的 Pod 使用。kubelet 具备与设备插件协同工作的支持能力。
   kubelet 会为 Pod 及其容器进行存储卷的挂载和卸载操作。可以使用存储插件来增加对新型存储以及其他存储卷类型的支持。

扩展点选择流程

如果不确定从何处开始，此流程图可以提供帮助。请注意，某些解决方案可能涉及多种类型的扩展。

客户端扩展

kubectl 的插件是独立的二进制文件，能够增添特定子命令的功能，或者改变特定子命令的原有行为。此外，kubectl 工具还能与凭证插件集成。不过，这些扩展仅对单个用户的本地环境产生作用，所以无法用来实施全站策略。

如果要扩展 kubectl 工具，请阅读使用插件扩展 kubectl。

API 扩展

定制资源对象

如果想要在 Kubernetes 中定义新的控制器、应用配置对象或其他声明式 API，并使用 Kubernetes 工具（如 kubectl）对其进行管理，那么可以考虑向 Kubernetes 添加自定义资源。

有关自定义资源的更多信息，请参阅自定义资源概念指南。

API 聚合层

可以使用 Kubernetes 的 API 聚合层将 Kubernetes API 与其他服务（例如指标）集成。

结合使用新 API 与自动化组件

自定义资源 API 与控制循环的组合，被称作控制器模式。当你的控制器替代人工运维人员，依据期望状态来部署基础设施时，该控制器很可能也遵循运维人员模式。运维人员模式主要用于管理特定的应用程序，这些应用程序通常会保存状态，并且在管理过程中需要格外谨慎。

也可以创建自己的自定义 API 和控制循环来管理其他资源，例如存储，或者定义策略（如访问控制限制）。

更改内置资源

当借助添加自定义资源来扩展 Kubernetes API 时，新增的资源必定归属于新的 API 组，无法替换或更改现有的 API 组。添加一个 API 不会直接对现有 API（如 Pods）的行为产生影响，不过 API 访问扩展却能够影响现有 API 的行为。

API 访问扩展

当请求抵达 Kubernetes API 服务器时，首先会进行身份验证，紧接着开展授权操作，随后将接受各类准入控制的检验（实际上，存在部分未经身份验证的请求，这些请求会被特殊处理）。若想深入了解这一流程的更多内容，可参考控制对 Kubernetes API 的访问。

Kubernetes 身份验证/授权流程中的每个步骤都提供了扩展点。

身份认证

在所有请求中，身份验证将请求中的头部信息（headers）或证书（certificates）映射为发出请求的客户端的用户名。

Kubernetes 拥有多种内置的认证方法并提供支持，同时它也可部署在认证代理之后。若内置认证方法无法满足需求，Kubernetes 能够从 Authorization: 头部提取令牌，发送至远程服务进行验证（这是一种认证 Webhook）。

鉴权

Authorization（鉴权） 负责判定特定用户是否有权对 API 资源执行读取、写入以及其他操作。它在整个资源层面发挥作用，并不会依据任意对象字段进行区分。

如果内置鉴权选项不能满足您的需求，鉴权 Webhook允许调用自定义代码来做出鉴权决策。

动态准入控制

请求获得授权后，如果是写入操作，它还会执行准入控制步骤。除了内置步骤之外，还有几个扩展：

• Image Policy Webhook限制了可以在容器中运行的镜像。
• 通用准入 Webhook 能够用于做出任意的准入控制决策，它可以拒绝资源的创建或更新操作。部分准入 Webhook 还会在 Kubernetes 对传入的请求数据做进一步处理前对其加以修改。

基础设施扩展

设备插件

设备插件允许节点通过设备插件发现新的 Node 资源（除了 cpu 和内存等内置资源）。

存储插件

容器存储接口（CSI）插件为 Kubernetes 的扩展提供了一种途径，使其得以支持新型存储卷。这些存储卷既可以由持久化的外部存储支撑，也能够提供临时存储，还可能运用文件系统范例为信息提供只读接口。

Kubernetes 还包括对 FlexVolume 插件的支持，这些插件从 Kubernetes v1.23 开始就被弃用了（支持 CSI）。

FlexVolume 插件允许用户挂载 Kubernetes 本身不支持的卷类型。当运行依赖于 FlexVolume 存储的 Pod 时，kubelet 会调用一个二进制插件来挂载该卷。已存档的 FlexVolume 设计提案对此方法有更详细的说明。

面向存储供应商的 Kubernetes 卷插件常见问题解答包括有关存储插件的常见信息。

网络插件

Kubernetes 集群需要部署一个网络插件，这样才能构建起正常运行的 Pod 网络，并全面支持 Kubernetes 网络模型的其他各项功能。

网络插件允许 Kubernetes 使用不同的网络拓扑和技术。

Kublete 镜像凭据提供程序插件

功能状态：Kubernetes v1.26 [stable]

Kubelet 镜像凭证提供程序是 kubelet 的插件，专门用于动态获取镜像注册中心凭证。当从与配置相符的容器镜像注册中心中拉取镜像时，就会用到这些凭证。

插件能够与外部服务进行通信，或者借助本地文件来获取凭证。如此一来，kubelet 无需为每个注册表配备静态凭证，而且能够支持多种身份验证方法和协议。

有关插件配置的详细信息，请参阅配置 kubelet 镜像凭证提供程序。

调度扩展

调度器是一类特殊的控制器，它持续监视 Pod，并负责将 Pod 分配至各个节点。默认调度器可被完全替换，替换后仍能继续使用 Kubernetes 的其他组件；此外，也可以同时运行多个调度器。

这是一项极为重要的任务，而且几乎所有 Kubernetes 用户都察觉到，自己并不需要对调度器进行修改。

能够掌控哪些调度插件处于启用状态，也能够将插件集与不同命名的调度程序配置文件关联起来。此外，还可以编写自己的插件，使其与 kube-scheduler 的一个或多个扩展点实现集成。

最后，内置的 kube-scheduler 组件支持一种 webhook，借助这个 webhook，远程 HTTP 后端（即调度器扩展）能够对 kube-scheduler 为 Pod 选定的节点进行过滤和 / 或优先级确定。

使用调度器扩展 Webhook 只能影响节点过滤和节点优先级排序；其他扩展点无法通过 Webhook 集成获得。

链接

• Kubernetes 扩展