Kubernetes API Aggregation - Kubernetes - Wiki.Shileizcc.com
API 聚合机制是 Kubernetes 1.7 版本引入的特性，能够将用户扩展的 API 注册到 kube-apiserver 上，仍然通过 API Server 的 HTTP URL 对新的 API 进行访问和操作。为了实现这个机制，Kubernetes 在 kube-apiserver 服务中引入了一个 API 聚合层（API Aggregation Layer），用于将扩展 API 的访问请求转发到用户服务的功能。
设计 API 聚合机制的主要目标如下。
- 增加 API 的扩展性：使得开发人员可以编写自己的 API Server 来发布他们的 API，而无需对 Kubernetes 核心代码进行任何修改。
- 无需等待 Kubernetes 核心团队的复杂审查：允许开发人员将其 API 作为单独的 API Server 发布，使集群管理员不用对 Kubernetes 核心代码进行修改就能使用新的 API，也就无需等待社区繁杂的审查了。
- 支持试验性新特性 API 开发：可以在独立的 API 聚合服务中开发新的 API，不影响系统现有的功能。
- 确保新的 API 遵循 Kubernetes 的规范：如果没有 API 聚合机制，开发人员就可能会被迫推出自己的设计，可能不遵循 Kubernetes 规范。
总的来说，API 聚合机制的目标是提供集中的 API 发现机制和安全的代理功能，将开发人员的新 API 动态地、无缝地注册到 Kubernetes API Server 中进行测试和使用。
在 Master 的 API Server 中启用 API 聚合功能
为了能够将用户自定义的 API 注册到 Master 的 API Server 中，首先需要配置 kube-apiserver 服务的以下启动参数来启用 API 聚合功能。
-
--proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.pem：在请求期间验证 Aggregator 的客户端 CA 证书。
-
--proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client-key.pem：在请求期间验证 Aggregator 的客户端私钥。
-
--requestheader-allowed-names=front-proxy-client：允许访问的客户端 common names 列表，通过 header 中 --requestheader-username-headers 参数指定的字段获取。客户端 common names 的名称需要在 client-ca-file 中进行设置，将其设置为空时，表示任意客户端都可以访问。
-
--requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.pem：客户端 CA 证书。
-
--requestheader-extra-headers-prefix=X-Remote-Extra-：请求头中需要检查的前缀名。
-
--requestheader-group-headers=X-Remote-Group：请求头中需要检查的组名。
-
--requestheader-username-headers=X-Remote-User：请求头中需要检查的用户名。
如果 kube-apiserver 所在的主机上没有运行 kube-proxy，既无法通过服务的 ClusterIP 进行访问，那么还需要设置一下启动参数：
--enable-aggregator-routing=true在设置完成重启 kube-apiserver 服务，就启用 API 聚合功能了。