首先我们先来看一下API编程范式的需求来源。
在Kubernetes里面,API编程范式也就是自定义资源定义(CRD)。我们常讲的CRD,其实指的就是用户自定义资源。
为什么会有用户自定义资源问题呢?
随着Kubernetes使用的越来越多,用户自定义资源的需求也会越来越多。而Kubernetes提供的聚合各个子资源的功能,已经不能满足日益增长的广泛需求了。用户希望提供一种用户自定义的资源,把各个子资源全部聚合起来。但Kubernetes原生资源的扩展和使用比较复杂,因此诞生了用户自定义资源这么一个功能。
二、用例解读
CRD的一个实例
我们首先具体地介绍一下CRD是什么。
CRD功能是在Kubernetes 1.7版本被引入的,用户可以根据自己的需求添加自定义的Kubernetes对象资源。值得注意的是,这里用户自己添加的Kubernetes对象资源都是本地的,都是一等公民,和Kubernetes中自带的,原生的那些仓,部署是同样的对象资源。在Kubernetes的API服务器看来,它们都是存在于etcd中的一等资源。
同时,自定义资源和原生内置的资源一样,都可以用kubectl,来去创建,查看,也享有RBAC,安全功能。用户可以开发自定义控制器来感知或者操作自定义资源的变化。
下面我们来看一个简单的CRD实例。下图是一个CRD的定义。
<李>
图中的组为samplecontroller.k8s。李io;
<李>版为v1alpha1;
<李>名称指的是它的类型是什么,比如部署的类就是部署,Pod的那种就是仓,这里的那种被定义为了Foo;
<李>复数字段就是一个昵称,比如当一些字段或者一些资源的名字比较长时,可以用该字段自定义一些昵称来简化它的长度;
<李>字范围段表明该CRD是否被命名空间管理。比如ClusterRoleBinding就是集群级别的。再比如豆荚,部署可以被创建到不同的命名空间里,那么它们的范围就是名称空间的。这里的CRD就是名称空间的。
下图就是上图所定义的CRD的一个实例。
<李>
它的apiVersion就是我们刚才所定义的samplecontroller.k8s。io/v1alpha1;
<李>类就是Foo;
<李>元数据的名字就是我们这个例子的名字。
<李>这个实例中规范字段其实没有在CRD的模式中定义,我们可以在规范中根据自己的需求来写一写,格式就是关键:价值这种格式,比如图中的deploymentName: example-foo,副本:1。当然我们也可以去做一些检验或者状态资源去定义规范中到底包含什么。
带有校验的CRD
我们来看一个包含校验的CRD定义:
Kubernetes中CRD的介绍和使用
