operator 之旅(一) (5)

创建 CustomResourceDefinition 对象后,您可以创建自定义对象。自定义对象可包含自定义字段。这些字段可以包含任意 JSON。在以下示例中, cronSpec 和 image 自定义字段在自定义对象中设置 CronTab。CronTab 类型来自您在上面创建的 CustomResourceDefinition 对象的规范。

如果您将以下 YAML 保存到 my-crontab.yaml:

apiVersion: "stable.example.com/v1" kind: CronTab metadata: name: my-new-cron-object spec: cronSpec: "* * * * */5" image: my-awesome-cron-image

并创建它:

kubectl create -f my-crontab.yaml

然后,您可以使用 kubectl 管理 CronTab 对象。例如:

kubectl get crontab

应该打印这样的列表:

NAME AGE my-new-cron-object 6s

...
https://jimmysong.io/kubernetes-handbook/concepts/crd.html

https://liqiang.io/post/kubernetes-all-about-crd-part01-crd-introduction-fb14d399

Operator简介

Kubernetes 是一个高度可扩展的系统,虽然它的扩展点这么多,但是一般来说我们接触的比较多的还是 自定义资源,控制器,准入控制,有些还会对 kubectl 和 调度器做一些扩展,其他的大部分使用成熟的开源组件就可以了。

官方对Operator的介绍:https://kubernetes.io/zh/docs/concepts/extend-kubernetes/operator/ ,Operator模式的执行流程如下图所示:

operator 之旅(一)


Operator 遵循 Kubernetes 的理念,它利用自定义资源管理应用及其组件, Operator 模式会封装你编写的任务自动化代码。

Operator 常见使用范围包括:

按需部署应用

获取/还原应用状态的备份

处理应用代码的升级以及相关改动。例如,数据库 schema 或额外的配置设置

发布一个 service,要求不支持 Kubernetes API 的应用也能发现它

模拟整个或部分集群中的故障以测试其稳定性

在没有内部成员选举程序的情况下,为分布式应用选择首领角色

从 Operator 理念的提出到现在已经有了很多工具可以帮助快速低成本的开发,其中最常用的就是 CoreOS 开源的 operator-sdk 和 k8s sig 小组维护的 kubebuilder。

除了自己开发之外还可以在 https://operatorhub.io/ 上找到别人开发的现成的 Operator 进行使用

kubebuilder kubebuilder 初体验 # mkdir kubedev # cd kubedev # go mod init kubedev go: creating new go.mod: module kubedev # kubebuilder init --domain zise.feizhu Error: failed to initialize project: unable to run pre-scaffold tasks of "base.go.kubebuilder.io/v3": go version 'go1.17.6' is incompatible because 'requires 1.13 <= version < 1.17'. You can skip this check using the --skip-go-version-check flag

这种情况下可以添加 --skip-go-version-check 忽略这个错误,但是还是建议使用官方推荐的版本

# kubebuilder init --domain zise.feizhu --skip-go-version-check Writing scaffold for you to edit... Get controller runtime: $ go get sigs.k8s.io/controller-runtime@v0.8.3 Update dependencies: $ go mod tidy Next: define a resource with: $ kubebuilder create api

在当前目录下新增以下内容,可见这是个标准的go module工程:

. ├── Dockerfile ├── Makefile # 这里定义了很多脚本命令,例如运行测试,开始执行等 ├── PROJECT # 这里是 kubebuilder 的一些元数据信息 ├── config # config目录下获得启动配置 │   ├── default # 一些默认配置 │   │   ├── kustomization.yaml │   │   ├── manager_auth_proxy_patch.yaml │   │   └── manager_config_patch.yaml │   ├── manager # 部署 crd 所需的 yaml │   │   ├── controller_manager_config.yaml │   │   ├── kustomization.yaml │   │   └── manager.yaml │   ├── prometheus # 监控指标数据采集配置 │   │   ├── kustomization.yaml │   │   └── monitor.yaml │   └── rbac # 部署所需的 rbac 授权 yaml │   ├── auth_proxy_client_clusterrole.yaml │   ├── auth_proxy_role.yaml │   ├── auth_proxy_role_binding.yaml │   ├── auth_proxy_service.yaml │   ├── kustomization.yaml │   ├── leader_election_role.yaml │   ├── leader_election_role_binding.yaml │   ├── role_binding.yaml │   └── service_account.yaml ├── go.mod # 一个新的Go模块,与我们的项目相匹配,具有基本的依赖项 ├── go.sum ├── hack # 脚本 │   └── boilerplate.go.txt └── main.go 6 directories, 24 files 创建API(CRD和Controller) # kubebuilder create api --group apps --version v1 --kind Application Create Resource [y/n] # 是否创建资源 y Create Controller [y/n] # 是否创建控制器 y

执行之后我们可以发现项目结构发生了一些变化

├── api │   └── v1 │   ├── application_types.go # crd定义 │   ├── groupversion_info.go # 主要存放schema和我们的gvk的定义 │   └── zz_generated.deepcopy.go # 序列化和反序列化我们的crd资源。这个一般不需要关注 ├── bin │   └── controller-gen ├── config │   ├── crd # 自动生成的 crd 文件,不用修改这里,只需要修改了 v1 中的 go 文件之后执行 make generate 即可 │   │   ├── kustomization.yaml │   │   ├── kustomizeconfig.yaml │   │   └── patches │   │   ├── cainjection_in_applications.yaml │   │   └── webhook_in_applications.yaml │   ├── rbac │   │   ├── application_editor_role.yaml │   │   ├── application_viewer_role.yaml │   │   ├── auth_proxy_client_clusterrole.yaml │   │   ├── auth_proxy_role.yaml │   │   ├── auth_proxy_role_binding.yaml │   │   ├── auth_proxy_service.yaml │   │   ├── kustomization.yaml │   │   ├── leader_election_role.yaml │   │   ├── leader_election_role_binding.yaml │   │   ├── role_binding.yaml │   │   └── service_account.yaml │   └── samples # 这里是 crd 示例文件,可以用来部署到集群当中 │   └── apps_v1_application.yaml ├── controllers │   ├── application_controller.go # 自定义控制器主要实现cr的reconcile方法,通过拿到cr资源信息,我们真正业务逻辑存放的地方 │   └── suite_test.go # 测试组件 13 directories, 37 files 构建和部署CRD

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zzzjfw.html