在本系列的前两部分中我们介绍了 API Server 的总体流程,以及 API 对象如何存储到 etcd 中。在本文中我们将探讨如何扩展 API 资源。
我们提供的服务有:成都网站建设、做网站、微信公众号开发、网站优化、网站认证、泰兴ssl等。为近千家企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务,是有科学管理、有技术的泰兴网站制作公司
在一开始的时候,扩展 API 资源的唯一方法是扩展相关 API 源代码,集成为你所需的资源。或者,推动一个全新的类型为新的核心对象 API 合入社区代码。但是,这样就会导致核心 API 资源类型的不断增加,直至 API 过载。为了避免这种 API 资源的无限制扩展,在 Kubernetes 中提供两种扩展核心 API 的方法:
1. 使用自定义资源定义( CRDs ),最开始的时候被称为第三方资源( TPRs )。通过 CRD 你能够简单而灵活的方式定义自己的资源对象类型,并让 API server 处理整个生命周期。
2. 使用与主 API Servers 并行运行的用户 API Servers ( UAS )。这种方式,可能更多的设计代码开发,可能需要你投入较多的时间及精力。当然,这种方式也能够让你对 API 资源有更细致,全面的了解。
在本文中,我们主要对 CRD 相关定义以及使用进行探讨。
CRDs 的声明及创建
在本系列文章第一部分所提到过的,每个 API 资源根据 Group 群组分类,每个对象都有一个对应的版本号与 HTTP 路径相关联。现在如果想要实现一个 CRD ,首先需要的是就是命名一个新的 API Group 群组,这个 API 群组不能与已经存在的群组重复。在你自己新建的 API 群组中,你可以拥有任意数量的资源,并且它们可以与其他群组中的资源具有相同的名称。下面我们来列举一个实际的例子:
在之前我们有介绍过,每个版本的由
API
群组管理的
Kubernetes
资源是跟
HTTP
路径相关的。
CRD
类似于面向对象编程中一个类的定义,而实际使用的
CR
可以看做为它的一组实例。首先我们对例子中的一些字段作说明,第一行中的
CRD apiVersion
在
kube-apiserver 1.7
之后都是这样定义的。从第
5
行之后我们定义了
spec
的相关字段。在第
6
行
spec.group
是定义了你创建的
CRD
的
API
群组(在本例子中定义为了
example.com
)。第
7
行定义了
CRD
对象的版本。每个资源只有一个固定版本,但在
API
群组中还是能有多个不同版本的资源。第
8
行的
spec.names
有两个必填项:
kind
,按照惯例第一个字母大写,
plural
,按照惯例全为小写,这个字段与最终生成的
HTTP
路径相关,比如在本例子中,最终的
HTTP
路径为
https:// 上面的
kind
主要是用来描述对象的类型,而
resource
资源是与
HTTP
路径相关的。大多数情况下这两个是匹配的;但是在某些特定情况下在相同的
API HTTP
路径下可能返回不通的
kind
(比如
Status
错误对象会返回另一种
kind
)。 值得注意的是
resource
资源(在本例中是
databases
)和
group
群组(本例中是
example.com
)必须与
metadata.name
字段匹配(本例为第四行
databases. example.com
)。 现在我们根据上面的
YAML
文件来创建一个
CRD
: $ kubectl create -f databases-crd.yaml customresourcedefinition "databases.example.com" created 由于这个创建过程是异步进行的,所以你必须检查一下你创建的
CRD
的状态,确认你创建的
CRD
没有与其它资源冲突,并且
API Server
已经调用相关处理函数完成创建。你可以在脚本或代码中通过轮询完成这个过程。最后我们能得到以下状态: $ kubectl get crd databases.example.com -o yaml apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition metadata: creationTimestamp: 2017-08-09T09:21:43Z name: databases.example.com resourceVersion: "792" selfLink: /apis/apiextensions.k8s.io/v1beta1/customresourcedefinitions/databases.example.com uid: 28c94a05-7ce4-11e7-888c-42010a9a0fd5 spec: group: example.com names: kind: Database listKind: DatabaseList plural: databases singular: database scope: Namespaced version: v1 status: acceptedNames: kind: Database listKind: DatabaseList plural: databases singular: database conditions: - lastTransitionTime: null message: no conflicts found reason: NoConflicts status: "True" type: NamesAccepted - lastTransitionTime: 2017-08-09T09:21:43Z message: the initial names have been accepted reason: InitialNamesAccepted status: "True" type: Established 以上,我们可以看到通过
kubectl
可以看到我们之前创建的
CRD
,并且显示出了
CRD
的一些状态信息。 CRDs
的使用 在
通过
kubectl proxy
将
Kubernetes API
开启本地代理后,查看我们刚才创建的
CRD: $ http 127.0.0.1:8001/apis/example.com HTTP/1.1 200 OK Content-Length: 223 Content-Type: application/json Date: Wed, 09 Aug 2017 09:25:44 GMT { "apiVersion": "v1", "kind": "APIGroup", "name": "example.com", "preferredVersion": { "groupVersion": "example.com/v1", "version": "v1" }, "serverAddressByClientCIDRs": null, "versions": [ { "groupVersion": "example.com/v1", "version": "v1" } ] } 请注意,在默认情况下十分钟内,
kubectl
是查看存储在
~/.kube/cache/discovery
目录的缓存。所以,可能会需要
10
分钟后你才能看到你新创建的
CRD
资源。但是,当没有缓存时,
kubectl
发现不了所需的资源时,那么会重新缓存它。 接下来,我们来看一个
CRD
实例: $ cat wordpress-database.yaml apiVersion: example.com/v1 kind: Database metadata: name: wordpress spec: user: wp password: secret encoding: unicode $ kubectl create -f wordpress-databases.yaml database "wordpress" created $ kubectl get databases.example.com NAME KIND wordpress Database.v1.example.com 想要通过
API
来监控资源的创建与
更新,你可以通过对某个
resourceVersion
(我们通过
$ http 127.0.0.1:8001/apis/example.com/v1/namespaces/default/databases HTTP/1.1 200 OK Content-Length: 593 Content-Type: application/json Date: Wed, 09 Aug 2017 09:38:49 GMT { "apiVersion": "example.com/v1", "items": [ { "apiVersion": "example.com/v1", "kind": "Database", "metadata": { "clusterName": "", "creationTimestamp": "2017-08-09T09:38:30Z", "deletionGracePeriodSeconds": null, "deletionTimestamp": null, "name": "wordpress", "namespace": "default", "resourceVersion": "2154", "selfLink": "/apis/example.com/v1/namespaces/default/databases/wordpress", "uid": "8101a7af-7ce6-11e7-888c-42010a9a0fd5" }, "spec": { "encoding": "unicode", "password": "secret", "user": "wp" } } ], "kind": "DatabaseList", "metadata": { "resourceVersion": "2179", "selfLink": "/apis/example.com/v1/namespaces/default/databases" } } 我们可以对
/apis/example.com/v1/namespaces/default/databases/wordpress
CRD
的
HTTP
路径
通过
curl
命令对的
"resourceVersion": "2154"
进行监控
watch: $ curl -f 127.0.0.1:8001/apis/example.com/v1/namespaces/default/databases?watch=true&resourceVersion=2154 现在我们新开一个
shell
对话窗口,删除
$ kubectl delete databases.example.com/wordpress 请注意:我们能够使用
kubectl delete database wordpress
删除
CRD
资源,是因为之前在
Kubernetes
没有定义有
database
资源。此外,
database
是我们
CRD
中的
spec.name.singular
字段
,从英语语法派生而来。 我们可以看到之前监控
watch CRD databases
从
API Server
处返回的更新状态: {"type":"DELETED","object":{"apiVersion":"example.com/v1","kind":"Database","metadata":{"clusterName":"","creationTimestamp":"2017-0[0/515] :38:30Z","deletionGracePeriodSeconds":null,"deletionTimestamp":null,"name":"wordpress","namespace":"default","resourceVersion":"2154","selfLink":"/apis/example.com/v1/namespaces/ default/databases/wordpress","uid":"8101a7af-7ce6-11e7-888c-42010a9a0fd5"},"spec":{"encoding":"unicode","password":"secret","user":"wp"}}} 上述
shell
会话的运行及输出结果如下图所示: 最后,让我们看一下
CRD database
的各个数据是如何存储在
etcd
中的。下面是我们直接通过
HTTP API
进入
etcd
访问得到的数据: $ curl -s localhost:2379/v2/keys/registry/example.com/databases/default | jq . { "action": "get", "node": { "key": "/registry/example.com/databases/default", "dir": true, "nodes": [ { "key": "/registry/example.com/databases/default/wordpress", "value": "{\"apiVersion\":\"example.com/v1\",\"kind\":\"Database\",\"metadata\":{\"clusterName\":\"\",\"creationTimestamp\":\"2017-08-09T14:53:40Z\",\"deletionGracePeriodSeconds\":null,\"deletionTimestamp\":null,\"name\":\"wordpress\",\"namespace\":\"default\",\"selfLink\":\"\",\"uid\":\"8837f788-7d12-11e7-9d28-080027390640\"},\"spec\":{\"encoding\":\"unicode\",\"password\":\"secret\",\"user\":\"wp\"}}\n", "modifiedIndex": 670, "createdIndex": 670 } ], "modifiedIndex": 670, "createdIndex": 670 } } 从上面可以看到,
CRD
数据在
etcd
中最终以一个未解析的的状态存在。现在将
CRD
删除,所有的
CRD
实例也会跟着删除,这是一个级联删除操作。 目前
CRDs
的使用现状,局限及将来的展望 CRDs
的发展现状如下所示: 1.
在
Kubernetes 1.7
版本中
CRDs
开始取代
2.
将
TPRs
迁移到
CRDs
实例可以参考文档
migration
。 3.
支持一个
CRD
中只有单个
version
版本,当然,一个群组中可能有多个
version
版本。 4.
CRDs
提供一个
API
方案,在用户角度看它与
Kubernetes
原生的
API
资源基本没有区别 5.
CRDs
是多版本多分支稳定的基础。关于
CRD
资源的
JSON-Schema
的格式有效性校验可以参考文档
CRD validation proposal
。相关资源回收可以参考文档
Garbage collection
。 接下去我们来看一下一些
CRDs
的局限: 1.
CRD
不提供版本转换功能,也就是说,每个
CRD
只能有一个版本(预计不会在近期或中期内看到支持
CRD
版本转换)。 2.
在
Kubernetes1.7
当中,目前并没有对于
CRD
的相关校验
validation
。 3.
没有快速,实时的准入(
admission
)机制(但是可以支持
webhooks
形式的初始化及准入)。 4.
在
Kubernetes1.7
中你不能定义子资源(
sub-resources
),比如
scale
或者
status
,不过目前有在这方面
proposal
的讨论。 5.
CRD
目前不支持默认值配置,即不支持为特定的字段配默认值(在
Kubernetes1.7
后续的版本中可能会支持)。 为了解决上述的问题,并且灵活的扩展
Kubernetes
,你可以运行一个与主
API Server
并行的用户
API Servers
。我们将在本博文的以后部分中详细介绍如何编写
UAS
,并编写一个
custom controller
完整使用
CRD
。https://www.huaweicloud.com/product/cce.html
curl
来实例对指定版本的
database
做监控
)之后的修改做监控
watch
。
wordpress
CRD
资源,我们可以查看刚才的监控
watch
窗口是否接收到了这个消息:
ThirdPartyResources
(TPRs)
,并且
TPRs
将会在
Kubernetes 1.8
被删除。
网站标题:深度剖析KubernetesAPIServer三部曲-part3
转载注明:http://www.cdkjz.cn/article/pjdcjc.html