CRD是什么
Custom Resource Definition,k8s允许用户自定义资源。定义CRM对象会创建一个具有您指定的名称和架构的新定义资源。Kubernetes API 提供并处理您的自定义资源的存储。
CR是什么
Custom Resouce,自定义资源,CRM的具体实例。CR是Kubernetes API的扩展。自定义资源可以通过动态注册在正在运行的集群中出现和消失,并且集群管理员可以独立于集群本身更新自定义资源。安装自定义资源后,用户可以使用 kubectl创建和访问其对象,就像对 Pods等内置资源所做的那样。
Custom controllers 的作用
当我们将自定义资源与自定义控制器组合时,自定义资源才提供了真正的声明性API。声明性API强制执行职责分离,我们声明资源的所需状态,控制器使Kubernetes对象的当前状态与声明的所需状态保持同步。
怎么强化对CRD的理解
可以把CRD理解成一个数据库表,定义了表的列名和类型等格式。CR 为表里一行一行的记录(record)。参见:CRD 就像 Kubernetes 中的一张表! - 知乎
CRD 操作示例
新建CRM
编写一个 resourcedefinition.yaml,如下:
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
# name must match the spec fields below, and be in the form: <plural>.<group>
name: crontabs.stable.example.com
spec:
# group name to use for REST API: /apis/<group>/<version>
group: stable.example.com
# list of versions supported by this CustomResourceDefinition
versions:
- name: v1
# Each version can be enabled/disabled by Served flag.
served: true
# One and only one version must be marked as the storage version.
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
cronSpec:
type: string
image:
type: string
replicas:
type: integer
# either Namespaced or Cluster,指定该CRD是命名空间或集群范围的
scope: Namespaced
names:
# plural name to be used in the URL: /apis/<group>/<version>/<plural>
plural: crontabs
# singular name to be used as an alias on the CLI and for display
singular: crontab
# kind is normally the CamelCased singular type. Your resource manifests use this.
kind: CronTab
# shortNames allow shorter string to match your resource on the CLI
shortNames:
- ct
使用以上的yaml文件进行自定义资源的创建:
kubectl apply -f resourcedefinition.yaml
创建自定义对象(custom objects)
编写 my-crontab.yaml,如下:
apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
name: my-new-cron-object
spec:
cronSpec: "* * * * */5"
image: my-awesome-cron-image
使用以上的yaml文件进行自定义资源的创建:
kubectl apply -f my-crontab.yaml
删除CRD
kubectl delete -f resourcedefinition.yaml
介绍Operator之前,先简单总结一下Kubernetes中的CRD在API Server中的设计和实现机制。根据Kubernetes的设计,每种官方内建的资源对象对 Node、Pod、Service等的实现都包含以下主要功能。
- 资源对象的元数据(Schema)的定义: 可以将其理解为数据库Table的定义,定义了对应的资源对象的数据结构,官方内建资源对象的元数据定义是固化在源码中的。
- 资源对象的校验逻辑:确保用户提交的资源对象的属性的合法性。
- 资源对象的CURD操作代码: 可以将其理解为数据库表的CURD代码,但比后者更难,因为API Server对资源对象的CURD操作都会保存到etcd数据库中,对处理性能的要求也更高,还要考虑版本兼容性和版本转换等复杂问题。
- 资源对象相关的“自动控制器”(如:RC、Deployment等资源对象背后的控制器):这是很重要的功能。Kubernetes是一个以自动化为核心目标的平台,用户给出期望的资源对象声明,运行过程中由资源背后的“自动控制器”确保对应资源对象的数量、状态、行为等始终符合用户的预期。
类似的,每个自定义CRD的开发人都需要实现上面的功能。为了降低编程难度与工作量,API Server的设计者们做出了大量的努力,使得直接编写YAML定义文件即可实现以上前3个功能。对于唯一需要编程的第4个功能,由于API Server提供了大量的基础API库,特别是易用的List-Watch的编程框架,所以CRD自动控制器的编程难度大大降低。
Operator 是什么
Operator框架并不是面对普通用户的,而是面向Kubernetes平台开发者的。平台开发者借助Operator框架提供的API,可以更方便地开发一个类似StatefulSet的控制器。在这个控制器里,开发者通过编码方式实现对目标集群的自定义操纵,包括集群部署、故障发现及集群调整等方面都可以实现有针对性的操控,从而实现更好的自动部署和智能运维功能。从实现上来说,operator = CRD + webhook + controller。
Operator的场景就是专门给有状态应用而设计的,从发展趋势来看,未来主流的有状态集群基本都会以Operator方式部署到Kubernetes集群中。
Operator常见工作模式
参考文档:
Custom Resources | Kubernetes
Extend the Kubernetes API with CustomResourceDefinitions | Kubernetes
Operator pattern | Kubernetes