Skip to content

Instantly share code, notes, and snippets.

@StevenACoffman

StevenACoffman/anOperatorPopularityContest.md

Last active May 7, 2020 00:35
Show Gist options
  • Save StevenACoffman/4d14a2d134575f3f6c5727d8e1c541ba to your computer and use it in GitHub Desktop.
Save StevenACoffman/4d14a2d134575f3f6c5727d8e1c541ba to your computer and use it in GitHub Desktop.
Download ZIP
Operator Popularity
Raw
anOperatorPopularityContest.md
Rank by PageRank Package/Repo Name Rank in github repos Github stars Rank by stars
254 github.com/operator-framework/operator-sdk 137 2867 472
1839 github.com/kubernetes-sigs/kubebuilder 1591 2103 656

Star History

From this comment:

Where they differ is:

  • Operator SDK also has support for Ansible and Helm operators, which make it easy to write operators without having to learn Go and if you already have experience with Ansible or Helm
  • Operator SDK includes integrations with the Operator Lifecycle Manager (OLM), which is a key component of the Operator Framework that is important to Day 2 cluster operations, like managing a live upgrade of your operator.
  • Operator SDK includes a scorecard subcommand that helps you understand if your operator follows best practices.
  • Operator SDK includes an e2e testing framework that simplifies testing your operator against an actual cluster.
  • Kubebuilder includes an envtest package that allows operator developers to run simple tests with a standalone etcd and apiserver.
  • Kubebuilder scaffolds a Makefile to assist users in operator tasks (build, test, run, code generation, etc.); Operator SDK is currently using built-in subcommands. Each has pros and cons. The SDK team will likely be migrating to a Makefile-based approach in the future.
  • Kubebuilder uses Kustomize to build deployment manifests; Operator SDK uses static files with placeholders.
  • Kubebuilder has recently improved its support for admission and CRD conversion webhooks, which has not yet made it into SDK.

The SDK and Kubebuilder teams work closely together, and we're planning to increase our efforts to help the kubebuilder team maintain controller-tools and controller-runtime so that the entire community has access to the latest features and bug fixes.

From these docs

Here are the steps that one needs to follow towards generating your own CRD/Operator code.

Generating Client/Listers/Informers:

For generating the client/listers/informers, etc. the first step is to create specific directory structure and define specific files in it. Here is that structure and the required files:

  • pkg/apis/some-controller-name/register.go
  • pkg/apis/some-controller-name/v1/doc.go
  • pkg/apis/some-controller-name/v1/types.go
  • pkg/client
  • pkg/signals

Following are detailed steps:

  1. Choose a name for your CRD's group name -- say 'postgrescontroller'
  2. Create pkg/apis/'CRD group name' directory
  3. cd pkg/apis/'CRD group name'
  4. Inside this directory create register.go to register the group name. When registering the name, choose some qualifier (example, in https://github.com/cloud-ark/kubeplus/blob/master/postgres-crd-v2/pkg/apis/postgrescontroller/register.go we have used "kubeplus" as the qualifier name.).
  5. Create v1 directory inside pkg/apis/'CRD group name'
  6. cd pkg/apis/'CRD group name'/v1
  7. Create doc.go. Make sure you set the "+groupName=." in line 20 of doc.go. Leave line 21 as it is. See https://github.com/cloud-ark/kubeplus/blob/master/postgres-crd-v2/pkg/apis/postgrescontroller/v1/doc.go
  8. Copy https://github.com/cloud-ark/kubeplus/tree/master/operator manager/pkg/apis/operatorcontroller/v1/register.go into pkg/apis//v1/. Make appropriate changes to this file.
  9. Define your CRD spec in types.go
  10. Nothing else needs to be created in the pkg/apis directory
  11. Create pkg/client directory. Nothing needs to be created inside the client directory -- leave it empty.
  12. Create pkg/signals directory and just copy all the files from https://github.com/cloud-ark/kubeplus/tree/master/postgres-crd-v2/pkg/signals into pkg/signals. You don't need to modify anything in any of these files.
  13. Go inside the hack/ directory.
  14. Edit update-codegen.sh to include the path of your folder
  15. Copy Gopkg.lock and Gopkg.toml from https://github.com/cloud-ark/kubeplus/tree/master/operator-manager
  16. Install Go dependencies dep ensure (this will create the vendor folder)
  17. mkdir vendor/k8s.io/code-generator/hack
  18. cp hack/boilerplate.go.txt vendor/k8s.io/code-generator/hack/.
  19. From the main directory of your CRD code execute following: ./hack/update-codegen.sh

Running the controller:

  1. In the controller.go (and other go files), include the CRD client/listers/informers etc. with appropriate path. See https://github.com/cloud-ark/kubeplus/blob/master/postgres-crd-v2/controller.go#L47 for an example.
  2. go run *.go -kubeconfig=$HOME/.kube/config

Reference:

kubernetes/sample-controller#13

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment