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

最新推荐文章于 2025-05-14 13:54:51 发布

原创

最新推荐文章于 2025-05-14 13:54:51 发布 · 1.4k 阅读

5 ·

CC 4.0 BY-SA版权

文章标签：

#kubernetes #云原生 #容器 #后端 #java

本文深入探讨了Kubernetes的CRD（Custom Resource Definition）和Operator，揭示了如何利用它们扩展K8S API以满足自定义需求。通过CRD创建自定义资源，Operator则负责管理和控制这些资源，实现应用的自动化运维。文章介绍了Spark Operator作为案例，以及通用大数据Operator的设计思想，强调了Operator在复杂场景中的应用和简化运维的潜力。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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。