k8s学习-自定义资源

k8s学习-自定义资源

参考官方文档：​​​CustomResourceDefinition 扩展 Kubernetes API​​​ ​

创建 CustomResourceDefinition

CustomResourceDefinition（CRD）时，Kubernetes API 服务器会为你所 指定的每一个版本生成一个 RESTful 的 资源路径。CRD 可以是名字空间作用域的，也可以 是集群作用域的，取决于 CRD 的 ​​scope​​ 字段设置。和其他现有的内置对象一样，删除 一个名字空间时，该名字空间下的所有定制对象也会被删除。CustomResourceDefinition 本身是不受名字空间限制的，对所有名字空间可用。

创建CRD，​​代码​​

kubectl create -f crd.yaml(venv) ➜ v1 git:(master) ✗ kubectl get crdNAME CREATED ATcrontabs.stable.example.com 2022-05-03T06:36:22Zstars.cnstar.kubecto-kubernetes.info 2022-05-03T08:11:02Z

创建定制对象

在创建了 CustomResourceDefinition 对象之后，你可以创建定制对象（Custom Objects）。定制对象可以包含定制字段。这些字段可以包含任意的 JSON 数据。 在下面的例子中，在类别为 ​​CrontTab​​​ 的定制对象中，设置了​​cronSpec​​​ 和 ​​image​​​ 定制字段。类别 ​​CronTab​​ 来自你在上面所创建的 CRD 的规约。

创建CR，​​代码​​

kubectl create -f example.yaml(venv) ➜ v1 git:(master) ✗ kubectl get starNAME SCHEDULE COMMAND AGE REPLICAS PHASEexample-star 2022-05-03T16:13:00Z echo Kubernetes native star! 38m 3 Running//用简写查看st(venv) ➜ v1 git:(master) ✗ kubectl get stNAME SCHEDULE COMMAND AGE REPLICAS PHASEexample-star 2022-05-03T16:13:00Z echo Kubernetes native star! 39m 3 Running//查看资源和版本信息(venv) ➜ v1 git:(master) ✗ kubectl api-resources | grep starstars st cnstar.kubecto-kubernetes.info/v1 true Star(venv) ➜ v1 git:(master) ✗ kubectl get crontabNAME AGEmy-new-cron-object 134m(venv) ➜ v1 git:(master) ✗ kubectl get ctNAME AGEmy-new-cron-object 134m

分类

分类（Categories）是定制资源所归属的分组资源列表（例如，​​all​​​）。 你可以使用 ​​kubectl get <分类名称>​​ 来列举属于某分类的所有资源。

下面的示例在 CustomResourceDefinition 中将 ​​all​​​ 添加到分类列表中， 并展示了如何使用 ​​kubectl get all​​ 来输出定制资源：

//categories 是定制资源所归属的分类资源列表(venv) ➜ v1 git:(master) ✗ kubectl get all | grep starstar.cnstar.kubecto-kubernetes.info/example-star 2022-05-03T16:13:00Z echo Kubernetes native star! 40m 3 Running

设置结构化的模式

CustomResource 对象在定制字段中保存结构化的数据，这些字段和内置的字段 ​​apiVersion​​​、​​kind​​​ 和 ​​metadata​​​ 等一起存储，不过内置的字段都会被 API 服务器隐式完成合法性检查。有了 ​​OpenAPI v3.0 检查​​ 能力之后，你可以设置一个模式（Schema），在创建和更新定制对象时，这一模式会被用来 对对象内容进行合法性检查。参阅下文了解这类模式的细节和局限性。

在 ​​apiextensions.k8s.io/v1​​ 版本中，CustomResourceDefinition 的这一结构化模式 定义是必需的。 在 CustomResourceDefinition 的 beta 版本中，结构化模式定义是可选的。

结构化模式本身是一个 ​​OpenAPI v3.0 验证模式​​，其中：

为对象根（root）设置一个非空的 type 值（藉由 OpenAPI 中的​​type​​​），对每个 object 节点的每个字段（藉由 OpenAPI 中的​​properties​​​ 或​​additionalProperties​​​）以及 array 节点的每个条目（藉由 OpenAPI 中的​​items​​）也要设置非空的 type 值， 除非：

节点包含属性​​x-kubernetes-int-or-string: true​​节点包含属性​​x-kubernetes-preserve-unknown-fields: true​​

对于 object 的每个字段或 array 中的每个条目，如果其定义中包含​​allOf​​​、​​anyOf​​​、​​oneOf​​​ 或​​not​​，则模式也要指定这些逻辑组合之外的字段或条目（试比较例 1 和例 2)。在​​allOf​​​、​​anyOf​​​、​​oneOf​​​ 或​​not​​​ 上下文内不设置​​description​​​、​​type​​​、​​default​​​、​​additionalProperties​​​ 或者​​nullable​​​。此规则的例外是​​x-kubernetes-int-or-string​​ 的两种模式（见下文）。如果​​metadata​​ 被设置，

删除 CustomResourceDefinition

当你删除某 CustomResourceDefinition 时，服务器会卸载其 RESTful API 端点，并删除服务器上存储的所有定制对象。

kubectl delete -f resourcedefinition.yamlkubectl get crontabs

Error from server (NotFound): Unable to list {"stable.example.com" "v1" "crontabs"}: the server could not find the requested resource (get crontabs.stable.example.com)

如果你在以后创建相同的 CustomResourceDefinition 时，该 CRD 会是一个空的结构。

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