Operator使用Kubernetes扩展机制,CRD,这样一来,由Operator管理的定制对象,其外观和行为就像内建的原生Kubernetes对象。本指南介绍了集群管理员如何通过创建和管理CRD来扩展其OCP集群。
在Kubernetes API中,资源(resource)是存储某一类API对象集合的endpoint。例如,内建的 pod
资源包含了 pod
对象集合。
CRD对象在集群中定义一个新的、唯一的对象类型,称为一个 kind
,并让Kubernetes API服务器处理其整个生命周期。
CR对象由集群管理员添加到集群中的CRD所创建,并支持所有集群用户在project中增加新的资源类型。
当集群管理员向集群中增加新的CRD时,Kubernetes API服务器的回应是新建一个RESTful资源路径,该资源路径可由整个集群或单个project(namespace)访问,并开始服务于指定的CR。
集群管理员如果要向其他用户授予CRD访问权限,可使用集群角色聚合来向用户授予 admin
、 edit
、 view
默认集群角色访问权限。集群角色聚合允许将定制策略规则插入到这些集群角色中。此行为将新资源整合到集群的RBAC策略中,就像内建资源一样。
Operator会通过“将CRD与任何所需RBAC策略和其它软件特定逻辑一起打包”来使用CRD。集群管理员也可以手动将CRD添加到Operator生命周期之外的集群中,使其对所有用户都可用。
注意:虽然只有集群管理员可创建CRD,但具有CRD读写权限的开发人员也可通过现有CRD来创建CR。
先创建一个包含以下字段类型的YAML文件:
apiVersion: apiextensions.k8s.io/v1 # 1
kind: CustomResourceDefinition
metadata:
name: crontabs.stable.example.com # 2
spec:
group: stable.example.com # 3
versions:
name: v1 # 4
scope: Namespaced # 5
names:
plural: crontabs # 6
singular: crontab # 7
kind: CronTab # 8
shortNames:
- ct # 9
使用 apiextensions.k8s.io/v1
API。
为定义指定名称。必须采用
格式,并使用 group
和 plural
字段的值。
为API指定组名。API组是一个逻辑上相关的对象集。例如,批处理对象(比如 Job
或 ScheduledJob
),可置于批处理API组(比如 batch.api.example.com
)。最好使用组织的FQDN(fully-qualified-domain name)。
指定URL中要用的版本名称。每个API组可能存在于多个版本中,例如 v1alpha
、 v1beta
、 v1
。
指定定制对象可用于某个project( Namespaced
)还是集群中的所有project( Cluster
)。
指定URL中要用的复数名称。 plural
字段与API URL中的资源相同。
指定单数名称,用于CLI上的别名,以及用于显示名称。
指定可创建的对象类型。类型可用驼峰命名法(CamelCase)。
指定与CLI中的资源相匹配的短字符串。
注意:默认情况下,CRD是集群范围的,可用于所有project。
创建CRD对象:
create -f .yaml
一个新的RESTful API endpoint被创建于:
/apis/group>///*//...
比如,对于上述示例文件,创建的endpoint是:
/apis/stable.example.com/v1/namespaces/*/crontabs/...
现在,就可使用该endpoint URL来创建和管理CR。对象类型是基于CRD对象的 spec.kind
字段。
集群管理员可以给现有的集群范围的CRD授予权限。如果使用 admin
、 edit
、 view
默认集群角色,可为其规则利用集群角色聚合。
注意:必须显式为每个角色分配权限。权限更多的角色不会继承权限较少角色的规则。如果要为某个角色分配规则,还必须将该动词分配给具有更多权限的角色。例如,如果要向 view
角色授予 get crontabs
的权限,必须也向 edit
和 admin
角色授予该权限。admin
或 edit
角色通常会分配给通过project模板创建project的用户。
为CRD创建集群角色定义文件。集群角色定义是一个YAML文件,其中包含了适用于各个集群角色的规则。OCP控制器会将指定的规则添加到默认集群角色中。
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1 # 1
metadata:
name: aggregate-cron-tabs-admin-edit # 2
labels:
rbac.authorization.k8s.io/aggregate-to-admin: "true" # 3
rbac.authorization.k8s.io/aggregate-to-edit: "true" # 4
rules:
- apiGroups: ["stable.example.com"] # 5
resources: ["crontabs"] # 6
verbs: ["get", "list", "watch", "create", "update", "patch", "delete", "deletecollection"] # 7
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: aggregate-cron-tabs-view # 8
labels:
# Add these permissions to the "view" default role.
rbac.authorization.k8s.io/aggregate-to-view: "true" # 9
rbac.authorization.k8s.io/aggregate-to-cluster-reader: "true" # 10
rules:
- apiGroups: ["stable.example.com"] # 11
resources: ["crontabs"] # 12
verbs: ["get", "list", "watch"] # 13
rbac.authorization.k8s.io/v1
API。admin
默认角色授予权限。edit
默认角色授予权限。view
默认角色授予权限。cluster-reader
默认角色授予权限。admin
和 edit
角色应用读写权限,对 view
角色应用只读权限。创建集群角色:
oc create -f .yaml
为CR创建YAML文件。在下面的定义示例中, cronSpec
和 image
定制字段在 Kind: CronTab
的CR中设定。 Kind
来自CRD对象的 spec.kind
字段:
apiVersion: "stable.example.com/v1" # 1
kind: CronTab # 2
metadata:
name: my-new-cron-object # 3
finalizers: # 4
- finalizer.stable.example.com
spec: # 5
cronSpec: "* * * * /5"
image: my-awesome-cron-image
oc create -f >.yaml
oc get
比如:
oc get crontab
资源名称不区分大小写,可用CRD中定义的单数或复数形式,也可使用简称。例如:
oc get crontabs
oc get crontab
oc get ct
查看CR的原始YAML数据:
oc get -o yaml
例如:
oc get ct -o yaml
输出示例:
apiVersion: v1
items:
- apiVersion: stable.example.com/v1
kind: CronTab
metadata:
clusterName: ""
creationTimestamp: 2017-05-31T12:56:35Z
deletionGracePeriodSeconds: null
deletionTimestamp: null
name: my-new-cron-object
namespace: default
resourceVersion: "285"
selfLink: /apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object
uid: 9423255b-4600-11e7-af6a-28d2447dc82b
spec:
cronSpec: '* * * * /5' # 1
image: my-awesome-cron-image # 2
注:其内容貌似和前面都一样。不再赘述。
https://access.redhat.com/documentation/en-us/openshift_container_platform/4.14/html-single/operators/index