[Kubernetes Operator] The point about the integration of operator-sdk and kubebuilder

Operator-sdk command structure changed from v0.19.0 (2020/7 release)

Because the command structure of Go-based Operator is now along the lines of kubebuilder, existing commands are no longer passed.

operator-sdk new osushi-operator --repo github.com/iaoiui/osushi
Error: unknown flag: --repo

The version of operator-sdk is as follows:

❯ operator-sdk version
operator-sdk version: "v0.19.2", commit: "4282ce9acdef6d7a1e9f90832db4dc5a212ae850", kubernetes version: "v1.18.2", go version: "go1.14.5 darwin/amd64"

If you check the Operatorframework documentation below, prior to v0.19.0, it was called “Legacy" and instructed to refer to a other document.

There seems to be a lot of changes, but it seems that the subcommand to create the first template has been changed from “new" to “init" and there is an error that there is no --repo option.

Golang Based Operator Quickstart

So I was able to handle it by replacing the “new" with "init".

operator-sdk init osushi-operator --repo github.com/iaoiui/osushi

According to the release information for operator-sdk, v0.19.0 will be released in July, 2020, so almost all books will need to be replaced with new command structure of operator-sdk.

https://github.com/operator-framework/operator-sdk/releases/tag/v0.19.0

Background on Operator-sdk and kubebuilder's Go-based Operator integration

There are two major frameworks for creating Kubernetes Operators, operator-sdk and kubebuilder, each of which has been maintained by different communities.

Both tools could do operator scaffolding (template generation) using Go, and although the directories and files created were different, the purpose of what they could achieve was the same.

Since we are doing the same thing with both tools, our motivation has been to reduce maintenance costs and speed up development by integrating them.

In concrete terms, since operator SDK has various functions related to Go Operator, the contributor on operator SDK side will take the lead in merging those functions into kubebuilder side.

In other words, I'm guessing it was settled in a way that smells a bit of politics, with kubebuilder as the upstream and operator sdk acting as a wrapper for kubebuilder.

It will merge operator sdk documents to kubebuilder and maintain kubebuilder as well.

Reference: kubebuilder's design documentation on the integration of kubebuilder and operator-sdk

The PR on the change of CLI in operator-sdk

As indicated in operator-sdk's PR(#3190), Operator for Go is now in line with the Kubebuilder CLI.

For that reason, the command has changed since 0.19.0, and the previous command is Legacy now.

In particular, note that the files generated by the operator-sdk command have changed entirely and it would be faster to got the point by forgetting the legacy operator-sdk.

It's safer to avoid specifying particular books, but I purchased the following books yesterday and will read it while taking into account the background on integration.
The Road to Custom Controller

This is also great book "Kubernetes perfect guide 2nd edition" which is the 2nd edition of kubernetes perfect guide, which I recently read.

Conclusion

• As the use of Kubernetes Operator becomes more and more widespread, the integration of similar frameworks will reduce the amount of time spent on choosing tools for first-time users, which is a very positive development trend.
• To be precise, it's not a complete integration of the operator creation for Helm and Ansible based Operator but Go-based. It is clear that they want to make operator-sdk wrapper because the function relationship will be operator-sdk>kubebuilder.
• Anyway, it's a problem for the user side if the command changes many times, so we'll continue to keep a close eye on developments.