#yyds干货盘点# Kubernetes 如何根据需求自定义你的 API？(26)

#yyds干货盘点# Kubernetes 如何根据需求自定义你的 API？(26)

随着使用的深入，你会发现 Kubernetes 中内置的对象定义，比如 Deployment、StatefulSet、Configmap，可能已经不能满足你的需求了。你很希望在 Kubernetes 定义一些自己的对象，一来可以通过 kube-apiserver 提供统一的访问入口，二来可以像其他内置对象一样，通过 kubectl 命令管理这些自定义的对象。Kubernetes 中提供了两种自定义对象的方式，一种是聚合 API，另一种是 CRD。我们今天就来看看。

聚合 API

聚合 API（Aggregation API，AA）是自 Kubernetes v1.7 版本就引入的功能，主要目的是方便用户将自己定义的 API 注册到 kube-apiserver 中，并且可以像使用其他内置的 API 一样，通过 APIServer 的 URL 就可以访问和操作。在使用 API 聚合之前，我们还需要通过一些参数在 kube-apiserver 中启用这个功能：

--requestheader-client-ca-file=--requestheader-allowed-names=front-proxy-client--requestheader-extra-headers-prefix=X-Remote-Extra---requestheader-group-headers=X-Remote-Group--requestheader-username-headers=X-Remote-User--proxy-client-cert-file=--proxy-client-key-file=

Kubernetes 在 kube-apiserver 中引入了一个 API 聚合层（API Aggregation Layer），可以将访问请求转发到后端用户自己的扩展 APIServer 中。你可以参考这个​​文档​​学习如何安装一个扩展的 APIServer。当然，扩展的 APIServer 需要你自己修改并实现相关的代码逻辑。

Kubernetes apiserver 会判断 --requestheader-client-ca-file 指定的 CA 证书中的 CN 是否是 --requestheader-allowed-names 提供的列表名称之一。如果不是，则该请求被拒绝。如果名称允许，则请求会被转发。接着 Kubernetes apiserver 将使用由 --proxy-client-*-file 指定的文件来访问用户的扩展 APIServer。

下图就是用户发起请求后一个完整的身份认证流程，你可以阅读​​官方文档​​来详细了解步骤 。

图 1：一个完整的身份认证流程配置好了上述参数后， 为了让 kube-apiserver 知道我们自定义的 API，我们需要创建一个 APIService 的对象，比如：

apiVersion: apiregistration.k8s.io/v1kind: APIServicemetadata: name: v1alpha1.wardle.example.com # 对象名称spec: insecureSkipTLSVerify: true group: wardle.example.com # 扩展 Apiserver 的 API group 名称 groupPriorityMinimum: 1000 # APIService 对对应 group 的优先级 versionPriority: 15 # 优先考虑 version 在 group 中的排序 service: name: myapi # 扩展 Apiserver 服务的 name namespace: wardle # 扩展 Apiserver 服务的 namespace version: v1alpha1 # 扩展 Apiserver 的 API version

CRD

CRD（CustomResourceDefinitions）在 v1.7 刚引入进来的时候，其实是 ThirdPartyResources（TPR）的升级版本，而 TPR 在 v1.8 的版本被剔除了。CRD 目前使用非常广泛，各个周边项目都在使用它，比如 Ingress、Rancher。我们来看一下官方的一个例子，通过如下的 YAML 文件，我们可以创建一个 API：

apiVersion: apiextensions.k8s.io/v1kind: CustomResourceDefinitionmetadata: # 名字必须与下面的 spec 字段匹配，并且格式为 '<名称的复数形式>.<组名>' name: crontabs.stable.example.comspec: # 组名称，用于 REST API: /apis/<组>/<版本> group: stable.example.com # 列举此 CustomResourceDefinition 所支持的版本 versions: - name: v1 # 每个版本都可以通过 served 标志来独立启用或禁止 served: true # 其中一个且只有一个版本必需被标记为存储版本 storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: cronSpec: type: string image: type: string replicas: type: integer # 可以是 Namespaced 或 Cluster scope: Namespaced names: # 名称的复数形式，用于 URL：/apis/<组>/<版本>/<名称的复数形式> plural: crontabs # 名称的单数形式，作为命令行使用时和显示时的别名 singular: crontab # kind 通常是单数形式的驼峰编码（CamelCased）形式。你的资源清单会使用这一形式。 kind: CronTab # shortNames 允许你在命令行使用较短的字符串来匹配资源 shortNames: - ct

apiVersion: "stable.example.com/v1"kind: CronTabmetadata: name: my-new-cron-objectspec: cronSpec: "* * * * */5" image: my-awesome-cron-image

通过 kubectl create 创建 my-new-cron-object 后，就可以通过 kubectl get 查看，并使用 kubectl 管理你的 CronTab 对象了。例如：

kubectl get crontabNAME AGEmy-new-cron-object 6s

这里的资源名是大小写不敏感的，我们在这里可以使用缩写 kubectl get ct，也可以使用 kubectl get crontabs。同时原生内置的 API 对象一样，这些 CRD 不仅可以通过 kubectl 来创建、查看、修改，删除等操作，还可以给其配置 RBAC 规则。我们还能开发自定义的控制器，来感知和操作这些自定义的 API。我们在创建 CRD 的时候，还可以一起定义 /status 和 /scale 子资源，如下所示：

apiVersion: apiextensions.k8s.io/v1kind: CustomResourceDefinitionmetadata: name: crontabs.stable.example.comspec: group: stable.example.com versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: cronSpec: type: string image: type: string replicas: type: integer status: type: object properties: replicas: type: integer labelSelector: type: string # subresources 描述定制资源的子资源 subresources: # status 启用 status 子资源 status: {} # scale 启用 scale 子资源 scale: # specReplicasPath 定义定制资源中对应 scale.spec.replicas 的 JSON 路径 specReplicasPath: .spec.replicas # statusReplicasPath 定义定制资源中对应 scale.status.replicas 的 JSON 路径 statusReplicasPath: .status.replicas # labelSelectorPath 定义定制资源中对应 scale.status.selector 的 JSON 路径 labelSelectorPath: .status.labelSelector scope: Namespaced names: plural: crontabs singular: crontab kind: CronTab shortNames: - ct

这些子资源的定义，可以帮助我们在更新对象的时候，只更改期望的部分，比如只更新 status 部分，避免误更新 spec 部分。同时 CRD 定义的时候还支持​​合法性检查​​、​​设置默认值​​等操作，你可以参照文档来实践。

小结

当然，你也可以选择在其他地方定义新的 API，你可以参考这份​​文档​​确定是否需要在 Kubernetes 中定义 API，还是让你的 API 独立运行。

你可以通过这个​​网址​​中的内容来比较 CRD 和 聚合 API 的功能差异。简单来说，CRD 更为易用，而聚合 API 更为灵活。Kubernetes 提供这两种选项以满足不同用户的需求，这样就既不会牺牲易用性也不会牺牲灵活性。

欢迎大家扫码关注，获取更多信息

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。