k8s CRD相关

本文详细介绍了Kubernetes(CRD)自定义资源定义的含义和作用,以及在K8s上创建资源的过程。CRD允许用户扩展Kubernetes API,而无需直接修改源代码。创建资源涉及apiserver、etcd和控制器的交互。K8s资源扩展有三种方式:CRD、自定义apiserver和修改apiserver源码。自定义资源需配合控制器才能实际运行。总结了CRD与Operator的关系,强调了Controller在资源管理中的关键角色。

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

1、CRD的意义
        Kubernetes 1.7之后,提供了CRD(CustomResourceDefinitions)自定义资源的二次开发能力来扩展kubernetes API,通过此扩展可以向kubernetes API中增加新的资源类型,会比修改kubernetes apiserver的源代码或创建自定义的apiserver来的更加的简洁和容易,


2、在k8s上创建资源的过程
        用户创建一个资源,实际上是把k8s抽象的资源根据资源清单(yaml文件)做实例化。具体过程如下:
        (1)用户的资源请求发送给apiserver,通过apiserver的认证、授权、准入控制以后,通过apiserver把对应的资源定义信息存放在etcd中;
        (2)对应资源类型的控制器一般被称为 controller或operator,controller通过watch机制监听apiserver上的资源变动,通过对应资源变动事件触发对应类型资源的控制器从etcd中读取对应资源的定义,并将对应资源创建出来,并通过控制器内部的和解循环(control loop)监控着对应资源状态是否和用户定义的期望状态一样;如果发现不一样,内部和解循环就会被触发,对应的控制器会向apiserver发起创建资源的请求,将对应资源重建,让对应资源的状态始终满足用户期望的状态。
        对于etcd来说,它是就一个kv数据库,可以存储任意类型的kv数据,但在k8s上,apiserver将不同类型的资源定义抽象成不同的资源,使得用户创建对应资源必须是满足对应类型资源定义的规范,然后将资源定义存放在etcd中。简单讲就是存入etcd中的数据必须是满足对应apiserver接口定义的规范。


3、k8s扩展资源类型的方式
        在k8s上扩展资源类型的方式有三种:

        第一种是CRD,crd是k8s内置的资源类型,通过crd资源可以将用户自定义资源类型转换为k8s上资源类型;
        第二种是自定义apiserver,这种方式是复用 Kubernetes 的一些特性的同时,自由度最高的方式。可以自定义存储等,同时保有一定程度的公共特性。Cloud TiDB 的实现就是通过自定义 API server 进行的;
        第三种方式就是修改现有k8s apiserver的源码,让其支持对应用户自定义资源类型;

        另外,进行自定义资源类型,只能把对应资源类型的定义信息写入到etcd中,不能让对应自定义类型资源实例化为一个自定义资源对象,它不能真正的跑起来,要想真正的跑起来,我们还需要一个自定义控制器,将对应资源实例化为k8s上的资源对象,并专门负责监听对应的资源类型的资源变化。
        因此需要(1)自定义资源类型CRD;+(2)对应自定义资源类型的控制器controller;
        controller的作用是通过API Server提供的接口实时的对指定的resource进行监听和执行的动作(watch,diff,action)。


备注:
k8s api = k8s资源 = pod、service、PV等
5种控制器类型:Deployment;StatefulSet;DaemonSet;Job;CronJob


crd和operator的区别:
所有的Operator都是基于Controller模式,Operator是使用CRD实现的定制化的Controller. 它与内置K8S Controller遵循同样的运行模式(比如 watch, diff, action);operator的逻辑也是创建一个crd资源,再创建一个控制器。

即Kubernetes CRD Operator = kubernetes CRD+ custom controller


 

### 关于Kubernetes CRD和Operator模式 #### 自定义资源定义(CRD) CRD允许扩展API服务器的功能,无需修改核心组件即可引入新的API对象。通过CRD可以创建特定业务需求的对象类型[^1]。 ```yaml apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: kvdis.example.com spec: group: example.com versions: - name: v1alpha1 served: true storage: true scope: Namespaced names: plural: kvdis singular: kvdI kind: Kvdi shortNames: - kd ``` 这段YAML配置文件展示了如何定义一个新的名为`kvdI`的自定义资源,在命名空间范围内可用,并属于`example.com`组的一部分。 #### Operator模式 Operators是一种封装、部署并管理Kubernetes应用的方法。它利用定制控制器来实现复杂的状态管理和操作逻辑自动化。对于像KVDI这样的虚拟桌面基础设施项目来说,operator可以帮助简化集群中的VDI环境管理工作流。 为了构建一个基于Go语言编写的简单Operator,通常会遵循如下结构: - 定义所需的Custom Resource Definitions (CRDs). - 创建Controller用于监听这些新类型的事件变化. - 编写Reconcile函数处理实际的任务执行. ```go package main import ( "context" appsv1 "k8s.io/api/apps/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/client-go/kubernetes" ctrl "sigs.k8s.io/controller-runtime" logf "sigs.k8s.io/controller-runtime/pkg/log" "sigs.k8s.io/controller-runtime/pkg/manager/signals" ) func main() { ctx := context.Background() log := logf.Log.WithName("controller_kvd") mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{}) if err != nil { panic(err.Error()) } clientset, _ := kubernetes.NewForConfig(mgr.GetConfig()) kvdiCtrl := &KvdiController{ ClientSet: clientset, Log: log, Scheme: mgr.GetScheme(), } err = kvdiCtrl.SetupWithManager(mgr) if err != nil { panic(err.Error()) } log.Info("starting manager") if err := mgr.Start(signals.SetupSignalHandler()); err != nil { log.Error(err, "problem running manager") } } ``` 上述代码片段提供了一个基本框架,其中包含了启动带有自定义控制器的manager所需的关键部分. #### 最佳实践建议 当开发针对KVDI或其他项目的operators时,请考虑以下几点最佳做法: - **模块化设计**: 将功能分解成独立的小型服务或库,以便更容易维护和发展。 - **幂等性保障**: 确保每次调用都能得到相同的结果,即使重复多次也不会影响最终状态。 - **错误恢复机制**: 实现重试策略和其他方法来应对临时性的失败情况。 - **监控与日志记录**: 添加足够的指标暴露以及详细的日志输出支持调试工作。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值