operator sdk与kubebuilder的区别
operator sdk和kubebuilder都是为了用户方便创建和管理operator而生的脚手架项目。对于用基于Golang开发的operator项目而言,operator sdk在底层使用了kubebuilder,例如operator sdk的命令行工具底层实际是调用kubebuilder的命令行工具。所以无论由operator sdk还是kubebuilder创建的operator项目都是调用的controller-runtime接口,而有相同的项目布局。
├── api
│ └── v1alpha1
├── bin
│ ├── controller-gen
│ ├── kustomize
│ ├── manager
│ └── opm
├── config
│ ├── crd
│ ├── default
│ ├── manager
│ ├── manifests
│ ├── prometheus
│ ├── rbac
│ ├── samples
│ └── scorecard
├── controllers
│ ├── suite_test.go
│ └── znbasecluster_controller.go
├── Dockerfile
├── go.mod
├── go.sum
├── hack
│ └── boilerplate.go.txt
├── main.go
├── Makefile
├── PROJECT
└── testbin
└── setup-envtest.sh
除此以外,operator sdk还增加了一些特性。默认情况下,使用operator-sdk init生成的项目集成如下功能:
- Operator Lifecycle Manager,安装和管理operator的系统
- OperatorHub,发布operator的社区中心
- operator sdk scorecard,一个有用的工具,用于确保operator具有最佳实践和开发过程中集群测试
另外,operator sdk除了支持golang以外,还支持Ansible和Helm。
总结:
- 两者并不是竞争关系,sdk相当于kubebuilder+;
- sdk的文档质量更高,感觉sdk更像是商业版的kubebuilder,而实际上它们是开源的;
如果你在两者之间犹豫不决,建议还是选择sdk吧。
更详细的信息请参考:
https://sdk.operatorframework.io/docs/faqs/
https://www.openshift.com/blog/operator-sdk-reaches-v1.0
operatorsdk和kubebuilder都是用于创建Kubernetes Operator的工具,但operatorsdk提供了更多便利功能,如集成OperatorLifecycleManager、OperatorHub和scorecard。它还支持Ansible和Helm,除了Golang。尽管两者底层使用相同的技术,operatorsdk的文档和附加特性使其成为更全面的选择。如果你在两者之间犹豫,推荐使用operatorsdk。
1227

被折叠的 条评论
为什么被折叠?



