1 operator-sdk
除了kubebuilder，operator-sdk是另一个常用的用于开发Operator的框架，不过operator-sdk还是基于kubebuilder，因此，通常还是建议使用kubebuilder开发Operator。
2 环境准备
跟kubebuilder类似，需要安装golang、operator-sdk。
在Operator SDK下载对应环境的二进制，例如，x86环境一般下载operator-sdk_linux_amd64，然后重命名为operator-sdk，拷贝到/usr/local/bin/目录。
3 Operator Demo
这里采用跟kubebuilder一样的例子讲解operator-sdk的开发流程：开发的是一个类似ReplicaSet的资源，它会负责创建一定数量的Pod。
3.1 初始化项目
operator-sdk init --domain tutorial.kubebuilder.io --repo github.com/demo
上面的命令跟kubebuilder唯一的区别就是把kubebuilder命令换成了operator-sdk。
生成的目录结构跟kubebuilder的区别在于：
- kubebuilder的main.go在cmd目录，而operator-sdk的main.go在根路径
- operator-sdk的config目录下多了manifests目录和scorecard目录
3.2 创建API
operator-sdk create api --group batch --version v1 --kind Demo
与kubebuilder生成的文件的唯一的区别就是控制器所在的路径，kubebuilder是在internal/controller，而operator-sdk则将控制器代码放在controllers目录，代码是一样的，而且demo_types.go也是一样的，因此，完全可以直接将kubebuilder中的代码直接拷贝到operator-sdk中。因此，这里直接进入测试阶段。
3.3 部署测试
operator-sdk和kubebuilder的make help也没有太大区别，只是operator-sdk加了一些构建命令，里面还涉及到bundle和catalog image。
因此，也可以用同样的方式在本地进行测试：
- 生成CRD和RBAC：
make manifests - 为Demo资源重新生成zz_generated.deepcopy.go：
make generate - 在k8s中创建CRD：
make install - 本地运行Controller：
make run
4 kubebuilder vs operator-sdk
从上面的operator-sdk的使用看，基本跟kubebuilder没有区别，那operator-sdk到底有啥优势呢？或者说，既然operator-sdk基于kubebuilder，那肯定有很多kubebuilder没有的功能。
kubebuilder是基于controller-runtime开发的operator开发库，而operator-sdk在kubebuilder上增加了很多用于实践的工具：
- 执行
operator-sdk help时可以看到有很多插件，每种插件就对应一种项目类型，里面比较熟悉的可能就是ansible、kubebuilder、helm，也就是说，通过operator-sdk创建项目时不仅可以创建基于kubebuilder的项目，还可以创建基于ansible和helm的项目，这两种方式基本不需要用golang就可以开发operator - operator-sdk集成了OLM，它可以管理集群中的operator，当安装OperatorHub上的operator时，就需要先安装OLM
以上两点应该是operator-sdk和kubebuilder的比较大的区别。