Kubernetes 资源编排系列之四：CRD+Operator 篇

1. 什么是 CRD

如果 K8S 中的自带资源类型不足以满足业务需求，需要定制开发资源怎么办？自定义资源(Custom Resource)由此产生。那么，如何让 Kubernetes 认识这些自定义的资源呢？CRD(Custom Resource Definition)就承担了一个说明书的角色，让 Kubernetes 来认识这个自定义资源 CR。

那么 CRD 是怎么来的呢？最早是谷歌提出 Third Party Resource 的概念，希望开发者以插件化形式扩展 K8s API 对象模型，以增强整个 k8s 的生态。基于 Third Party Resource 这一概念，Kubernetes 社区在 1.7 版本中提出了 CRD 的概念。

随便打开一个 CRD 的 YAML 可以看到，其主体部分是使用 OpenAPI v3 schema 来描述 CR 的字段结构，类似编程语言中的强类型声明。

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: humans.human.sreworks.io
spec:
  group: human.sreworks.io
  names:
    kind: Human
    plural: humans
  scope: Namespaced
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          description: ...
          type: object
          properties:
            spec:
              type: object
              properties:
                company:
                  type: string
                ...

复制代码

有了 CRD 之后，我们可以自由地增加各种与 Pod 平级的资源，很多之前需要落在 CMDB 中的数据，也可以被放在 k8s 集群中。这极大地拓宽了我们的想象力，什么交换机、作业、路由等各种关联的资源都一股脑地放进集群里面去。

在各种自定义资源被放进去之后，就会有人问，这放进去是挺方便的，但是放进去就会生效吗？是的，资源的生效就是 Operator 的功劳。下面我们就开始介绍 Operator。

2. 什么是 Operator

首先随便翻看一本词典看一下 operator 这个词的定义：操作员/运算符，是个名词。那么，operator 描述的应该是一个围绕"操作、控制"概念的东西。为了让大家有个更直观的认识，我们来举一个例子，比如 1 + 2 = 3&#