一、Custom Resource Definition（CRD）
1. CRD的基本概念
CRD（Custom Resource Definition）是 Kubernetes 中用于定义自定义资源的一种机制。通过 CRD，用户可以扩展 Kubernetes API，添加新的资源类型，使其能够管理特定的应用场景或业务需求。
CRD的组成
apiVersion：定义 CRD 所属的 API 组和版本。
kind：定义资源类型，这里是 CustomResourceDefinition。
metadata：包含资源的元数据，如名称。
spec：定义 CRD 的具体配置，包括 API 组、版本、资源的范围（集群或命名空间）、资源的名称（单数、复数、简写）等。
schema：定义自定义资源的结构，使用 OpenAPI v3 格式。
CRD的作用
扩展 Kubernetes API，支持新的资源类型。
提供 RESTful 接口，方便用户通过 kubectl 或 API 客户端操作自定义资源。
支持声明式 API，用户可以通过 YAML 文件定义资源的状态，由控制器处理具体实现。
2. CRD的生命周期管理
创建 CRD：将 CRD 的 YAML 文件提交到 Kubernetes 集群中，API 服务器会自动注册新的资源类型。
验证 CRD：提交后，可以通过 kubectl get crd 命令查看 CRD 是否生效。
删除 CRD：删除 CRD 资源时，API 服务器会卸载对应的 RESTful 接口，并删除存储的数据。
3. CRD的应用场景
扩展 Kubernetes 功能：如实现特定的应用部署策略、监控指标等。
管理有状态应用：通过 CRD 和控制器实现复杂的应用生命周期管理。
第三方集成：为第三方服务（如数据库、消息队列）提供 Kubernetes 原生的管理方式。
4. 示例：定义一个 CRD
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
# name 必须匹配下面的 spec 字段：<plural>.<group>
name: crontabs.stable.example.com
spec:
# group 名用于 REST API 中的定义：/apis/<group>/<version>
group: stable.example.com
# 列出自定义资源的所有 API 版本
versions:
- name: v1beta1 # 版本名称，比如 v1、v2beta1 等等
served: true # 是否开启通过 REST APIs 访问 `/apis/<group>/<version>/...`
storage: true # 必须将一个且只有一个版本标记为存储版本
schema: # 定义自定义对象的声明规范
openAPIV3Schema:
description: Define CronTab YAML Spec
type: object
properties:
spec:
type: object
properties:
cronSpec:
type: string
image:
type: string
replicas:
type: integer
# 定义作用范围：Namespaced（命名空间级别）或者 Cluster（整个集群）
scope: Namespaced
names:
# kind 是 sigular 的一个驼峰形式定义，在资源清单中会使用
kind: CronTab
# plural 名字用于 REST API 中的定义：/apis/<group>/<version>/<plural>
plural: crontabs
# singular 名称用于 CLI 操作或显示的一个别名
singular: crontab
# shortNames 相当于缩写形式
shortNames:
- ct
解释：该 CRD 定义了一个名为 CronTab 的资源，支持在命名空间级别管理 Cron 任务，包含 cronSpec、image 和 replicas 三个字段。
二、Custom Resource（自定义资源）
1. 自定义资源的概念
自定义资源是基于 CRD 定义的具体实例。用户可以通过 YAML 文件或 API 创建、更新和删除这些资源。
2. 自定义资源的使用
创建资源：使用 kubectl apply -f 命令提交资源定义文件。
查询资源：使用 kubectl get 命令查看资源状态。
更新资源：通过更新 YAML 文件并重新提交，Kubernetes 会自动同步状态。
3. 示例：创建一个 CronTab 资源
apiVersion: "stable.example.com/v1beta1"
kind: CronTab
metadata:
name: my-new-cron-object
spec:
cronSpec: "* * * * */5"
image: my-awesome-cron-image
replicas: 3
定义资源的存储
自定义资源的数据存储在 Kubernetes 的 etcd 中，与其他资源类似。
通过 CRD 的 spec.storage 字段指定存储版本，确保数据的持久性和一致性。
三、Custom Controller（自定义控制器）
1. 控制器的作用
控制器是 Kubernetes 中用于实现声明式 API 的核心机制。它通过监听资源的变化，自动调整集群状态以达到期望状态。
2. 自定义控制器的实现
client - go 库：Kubernetes 官方提供的 Go 客户端库，用于与 API 服务器交互。
事件监听：使用 Informer 和 Controller 机制监听资源的变化。
业务逻辑实现：在资源变化时，执行相应的逻辑（如创建 Pod、更新配置等）。
3. 控制器的实现原理
Informer 机制：用于高效地监听资源的变化，减少对 API 服务器的压力。
Reconciler 模式：通过不断对比当前状态和期望状态，确保系统达到目标状态。
幂等性设计：确保多次执行相同的操作不会导致错误或重复资源。
四、Operator 模式
1. Operator 的定义
Operator 是 Kubernetes 中的一种高级扩展模式，结合了 CRD 和自定义控制器扩展了 Kubernetes API 资源，使用户管理 Kubernetes 的内置资源一样创建、配置和管理应用程序。
Operator 是一个特定的应用程序的控制器，通过扩展 Kubernetes API 资源以代表 Kubernetes 用户创建、配置和管理复杂应用程序的实例，通常包含资源模型定义和控制器，通过 Operator 通常是为了实现某种特定软件（通常是有状态服务）的自动化运维。
2. Operator 的优势
领域特定知识：Operator 可以封装特定领域的知识，简化用户的使用。
自动化运维：通过 Operator，用户可以自动化部署、配置和管理复杂的应用。
声明式 API：提供声明式的接口，用户只需定义期望状态，Operator 负责实现。
3. Operator 的实现框架
kubebuilder：一个用于快速开发 Operator 的工具链。
Operator Framework：提供 Operator 开发的工具和库，支持 Go、Java 等多种语言。
4. Operator 实现详见
https://www.qikqiak.com/k8strain/operator/operator/
5. Operator 的应用场景
有状态应用：如数据库、消息队列等需要复杂生命周期管理的应用。
多组件应用：如微服务架构中的服务网格、CI/CD pipeline 等。
第三方服务集成：为第三方服务提供 Kubernetes 原生的管理方式。
————————————————
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/woshihlf/article/details/145691733
