Kubernetes 是高度可配置且可扩展的。因此，大多数情况下，
你不需要派生自己的 Kubernetes 副本或者向项目代码提交补丁。
本指南描述定制 Kubernetes 的可选方式。主要针对的读者是希望了解如何针对自身工作环境需要来调整 Kubernetes 的 集群管理者 。
对于那些充当 平台开发人员 的开发人员或 Kubernetes 项目的 贡献者 而言，
他们也会在本指南中找到有用的介绍信息，了解系统中存在哪些扩展点和扩展模式，
以及它们所附带的各种权衡和约束等等。
概述
定制化的方法主要可分为 配置（Configuration） 和 扩展（Extensions） 两种。
前者主要涉及改变参数标志、本地配置文件或者 API 资源；
后者则需要额外运行一些程序或服务。
本文主要关注扩展。
配置
配置文件和参数标志的说明位于在线文档的参考章节，按可执行文件组织：
- [kubelet]
- [kube-proxy]
- [kube-apiserver]
- [kube-controller-manager]
- [kube-scheduler]
在托管的 Kubernetes 服务中或者受控安装的发行版本中，参数标志和配置文件不总是可以修改的。
即使它们是可修改的，通常其修改权限也仅限于集群管理员。
此外，这些内容在将来的 Kubernetes 版本中很可能发生变化，设置新参数或配置文件可能需要重启进程。
有鉴于此，应该在没有其他替代方案时才会使用参数标志和配置文件。
内置的策略 API，例如[ResourceQuota]、 [PodSecurityPolicies]、 [NetworkPolicy]
和基于角色的访问控制（[RBAC]）
等等都是内置的 Kubernetes API。 API 通常用于托管的 Kubernetes 服务和受控的 Kubernetes 安装环境中。
这些 API 是声明式的，与 Pod 这类其他 Kubernetes 资源遵从相同的约定，
所以新的集群配置是可复用的，并且可以当作应用程序来管理。
此外，对于稳定版本的 API 而言，它们与其他 Kubernetes API 一样，
采纳的是一种[预定义的支持策略]。
出于以上原因，在条件允许的情况下，基于 API 的方案应该优先于配置文件和参数标志。
扩展
扩展（Extensions）是一些扩充 Kubernetes 能力并与之深度集成的软件组件。
它们调整 Kubernetes 的工作方式使之支持新的类型和新的硬件种类。
大多数集群管理员会使用一种托管的 Kubernetes 服务或者其某种发行版本。
这类集群通常都预先安装了扩展。因此，大多数 Kubernetes 用户不需要安装扩展，
至于需要自己编写新的扩展的情况就更少了。
扩展模式
Kubernetes 从设计上即支持通过编写客户端程序来将其操作自动化。
任何能够对 Kubernetes API 发出读写指令的程序都可以提供有用的自动化能力。 自动化组件可以运行在集群上，也可以运行在集群之外。
通过遵从本文中的指南，你可以编写高度可用的、运行稳定的自动化组件。
自动化组件通常可以用于所有 Kubernetes 集群，包括托管的集群和受控的安装环境。
编写客户端程序有一种特殊的 Controller（控制器） 模式，能够与 Kubernetes
很好地协同工作。控制器通常会读取某个对象的 .spec，或许还会执行一些操作，
之后更新对象的 .status。
Controller 是 Kubernetes 的客户端。当 Kubernetes 充当客户端，
调用某远程服务时，对应的远程组件称作 Webhook，远程服务称作 Webhook 后端。
与控制器模式相似，Webhook 也会在整个架构中引入新的失效点（Point of Failure）。
在 Webhook 模式中，Kubernetes 向远程服务发起网络请求。
在 可执行文件插件（Binary Plugin） 模式中，Kubernetes
执行某个可执行文件（程序）。可执行文件插件在 kubelet （例如， [FlexVolume 插件]
和[网络插件]）
和 kubectl 中使用。
下面的示意图中展示了这些扩展点如何与 Kubernetes 控制面交互。
扩展点
此示意图显示的是 Kubernetes 系统中的扩展点。
- 用户通常使用
kubectl与 Kubernetes API 交互。 [kubectl 插件]能够扩展 kubectl 程序的行为。 这些插件只会影响到每个用户的本地环境，因此无法用来强制实施整个站点范围的策略。 - API 服务器处理所有请求。API 服务器中的几种扩展点能够使用户对请求执行身份认证、 基于其内容阻止请求、编辑请求内容、处理删除操作等等。 这些扩展点在 [API 访问扩展] api-access-extensions
- API 服务器向外提供不同类型的资源（resources）。
诸如
pods的内置资源类型是由 Kubernetes 项目所定义的，无法改变。 你也可以添加自己定义的或者其他项目所定义的称作自定义资源（Custom Resources） 的资源，正如[自定义资源] user-defined-types 自定义资源通常与 API 访问扩展点结合使用。 - The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions] scheduler-extensions
- Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API server. Controllers are often used in conjunction with Custom Resources.
- The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins] network-plugins pod networking.
- The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins] storage-plugins If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions. –>
- Kubernetes 调度器负责决定 Pod 要放置到哪些节点上执行。 有几种方式来扩展调度行为。这些方法将在[调度器扩展] scheduler-extensions
- Kubernetes 中的很多行为都是通过称为控制器（Controllers）的程序来实现的， 这些程序也都是 API 服务器的客户端。控制器常常与自定义资源结合使用。
- 组件 kubelet 运行在各个节点上，帮助 Pod 展现为虚拟的服务器并在集群网络中拥有自己的 IP。 [网络插件] network-plugins
- 组件 kubelet 也会为容器增加或解除存储卷的挂载。 通过[存储插件] storage-plugins
如果你无法确定从何处入手，下面的流程图可能对你有些帮助。
注意，某些方案可能需要同时采用几种类型的扩展。
API 扩展
用户定义的类型
如果你想要定义新的控制器、应用配置对象或者其他声明式 API，并且使用 Kubernetes
工具（如 kubectl）来管理它们，可以考虑向 Kubernetes 添加自定义资源。
不要使用自定义资源来充当应用、用户或者监控数据的数据存储。
关于自定义资源的更多信息，可参见[自定义资源概念指南]。
结合使用新 API 与自动化组件
自定义资源 API 与控制回路的组合称作 [Operator 模式]。 Operator 模式用来管理特定的、通常是有状态的应用。
这些自定义 API 和控制回路也可用来控制其他资源，如存储或策略。
更改内置资源
当你通过添加自定义资源来扩展 Kubernetes 时，所添加的资源通常会被放在一个新的 API 组中。你不可以替换或更改现有的 API 组。
添加新的 API 不会直接让你影响现有 API（如 Pod）的行为，不过 API
访问扩展能够实现这点。
API 访问扩展
当请求到达 Kubernetes API 服务器时，首先要经过身份认证，之后是鉴权操作，
再之后要经过若干类型的准入控制器的检查。
参见[控制 Kubernetes API 访问]以了解此流程的细节。
这些步骤中都存在扩展点。 Kubernetes 提供若干内置的身份认证方法。它也可以运行在某种身份认证代理的后面，
并且可以将来自鉴权头部的令牌发送到某个远程服务（Webhook）来执行验证操作。
所有这些方法都在[身份认证文档]中有详细论述。
身份认证
[身份认证]负责将所有请求中的头部或证书映射到发出该请求的客户端的用户名。 Kubernetes 提供若干种内置的认证方法，
以及[认证 Webhook]
方法以备内置方法无法满足你的要求。
鉴权
[鉴权]操作负责确定特定的用户是否可以读、写 API
资源或对其执行其他操作。此操作仅在整个资源集合的层面进行。
换言之，它不会基于对象的特定字段作出不同的判决。
如果内置的鉴权选项无法满足你的需要，
你可以使用[鉴权 Webhook] 来调用用户提供的代码，
执行定制的鉴权操作。
动态准入控制
请求的鉴权操作结束之后，如果请求的是写操作，
还会经过[准入控制]处理步骤。
除了内置的处理步骤，还存在一些扩展点：
- [镜像策略 Webhook] 能够限制容器中可以运行哪些镜像。
- 为了执行任意的准入控制， 可以使用一种通用的[准入 Webhook] 机制。这类 Webhook 可以拒绝对象创建或更新请求。
Infrastructure Extensions
Storage Plugins
[Flex Volumes] allow users to mount volume types without built-in support by having the kubelet call a binary plugin to mount the volume. –>
基础设施扩展
存储插件
[Flex Volumes]
卷可以让用户挂载无需内建支持的卷类型， kubelet 会调用可执行文件插件来挂载对应的存储卷。
从 Kubernetes v1.23 开始，FlexVolume 被弃用。
在 Kubernetes 中编写卷驱动的推荐方式是使用树外（Out-of-tree）CSI 驱动。
详细信息可参阅 Kubernetes Volume Plugin FAQ for Storage Vendors。
设备插件
使用[设备插件]，
节点能够发现新的节点资源（除了内置的类似 CPU 和内存这类资源）。
网络插件
通过节点层面的[网络插件]，
可以支持不同的网络设施。
调度器扩展
调度器是一种特殊的控制器，负责监视 Pod 变化并将 Pod 分派给节点。
默认的调度器可以被整体替换掉，同时继续使用其他 Kubernetes 组件。
或者也可以在同一时刻使用[多个调度器]。
这是一项非同小可的任务，几乎绝大多数 Kubernetes
用户都会发现其实他们不需要修改调度器。
调度器也支持一种 [Webhook]，
允许使用某种 Webhook 后端（调度器扩展）来为 Pod 可选的节点执行过滤和优先排序操作。
- 进一步了解[自定义资源]
- 了解[动态准入控制]
- 进一步了解基础设施扩展
- [网络插件]
- [设备插件]
- 了解 [kubectl 插件]
- 了解 [Operator 模式]
