Kubernetes API Aggregation API聚合-Toy模板网

这篇具有很好参考价值的文章主要介绍了Kubernetes API Aggregation API聚合。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

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：请求头中需要检查的用户名。