This project is a component of the Operator Framework, an open source toolkit to manage Kubernetes native applications, called Operators, in an effective, automated, and scalable way. Read more in the introduction blog post.
Operators make it easy to manage complex stateful applications on top of Kubernetes. However writing an operator today can be difficult because of challenges such as using low level APIs, writing boilerplate, and a lack of modularity which leads to duplication.
The Operator SDK is a framework that uses the controller-runtime library to make writing operators easier by providing:
- High level APIs and abstractions to write the operational logic more intuitively
- Tools for scaffolding and code generation to bootstrap a new project fast
- Extensions to cover common operator use cases
The SDK provides workflows to develop operators in Go, Ansible, or Helm.
The following workflow is for a new Go operator:
- Create a new operator project using the SDK Command Line Interface(CLI)
- Define new resource APIs by adding Custom Resource Definitions(CRD)
- Define Controllers to watch and reconcile resources
- Write the reconciling logic for your Controller using the SDK and controller-runtime APIs
- Use the SDK CLI to build and generate the operator deployment manifests
The following workflow is for a new Ansible operator:
- Create a new operator project using the SDK Command Line Interface(CLI)
- Write the reconciling logic for your object using ansible playbooks and roles
- Use the SDK CLI to build and generate the operator deployment manifests
- Optionally add additional CRD's using the SDK CLI and repeat steps 2 and 3
The following workflow is for a new Helm operator:
- Create a new operator project using the SDK Command Line Interface(CLI)
- Create a new (or add your existing) Helm chart for use by the operator's reconciling logic
- Use the SDK CLI to build and generate the operator deployment manifests
- Optionally add additional CRD's using the SDK CLI and repeat steps 2 and 3
- git
- go version v1.13+.
- mercurial version 3.9+
- docker version 17.03+.
- kubectl version v1.11.3+.
- Access to a Kubernetes v1.11.3+ cluster.
- Optional: delve version 1.2.0+ (for
up local --enable-delve).
Follow the steps in the installation guide to learn how to install the Operator SDK CLI tool.
Note: If you are using a release version of the SDK, make sure to follow the documentation for that version. e.g.: For version 0.8.1, see docs in https://github.com/operator-framework/operator-sdk/tree/v0.8.1.
# Create an app-operator project that defines the App CR.
$ mkdir -p $HOME/projects/example-inc/
# Create a new app-operator project
$ cd $HOME/projects/example-inc/
$ operator-sdk new app-operator --repo github.com/example-inc/app-operator
$ cd app-operator
# Add a new API for the custom resource AppService
$ operator-sdk add api --api-version=app.example.com/v1alpha1 --kind=AppService
# Add a new controller that watches for AppService
$ operator-sdk add controller --api-version=app.example.com/v1alpha1 --kind=AppService
# Build and push the app-operator image to a public registry such as quay.io
$ operator-sdk build quay.io/example/app-operator
$ docker push quay.io/example/app-operator
# Update the operator manifest to use the built image name (if you are performing these steps on OSX, see note below)
$ sed -i 's|REPLACE_IMAGE|quay.io/example/app-operator|g' deploy/operator.yaml
# On OSX use:
$ sed -i "" 's|REPLACE_IMAGE|quay.io/example/app-operator|g' deploy/operator.yaml
# Setup Service Account
$ kubectl create -f deploy/service_account.yaml
# Setup RBAC
$ kubectl create -f deploy/role.yaml
$ kubectl create -f deploy/role_binding.yaml
# Setup the CRD
$ kubectl create -f deploy/crds/app.example.com_appservices_crd.yaml
# Deploy the app-operator
$ kubectl create -f deploy/operator.yaml
# Create an AppService CR
# The default controller will watch for AppService objects and create a pod for each CR
$ kubectl create -f deploy/crds/app.example.com_v1alpha1_appservice_cr.yaml
# Verify that a pod is created
$ kubectl get pod -l app=example-appservice
NAME READY STATUS RESTARTS AGE
example-appservice-pod 1/1 Running 0 1m
# Test the new Resource Type
$ kubectl describe appservice example-appservice
Name: example-appservice
Namespace: myproject
Labels: <none>
Annotations: <none>
API Version: app.example.com/v1alpha1
Kind: AppService
Metadata:
Cluster Name:
Creation Timestamp: 2018-12-17T21:18:43Z
Generation: 1
Resource Version: 248412
Self Link: /apis/app.example.com/v1alpha1/namespaces/myproject/appservices/example-appservice
UID: 554f301f-0241-11e9-b551-080027c7d133
Spec:
Size: 3
# Cleanup
$ kubectl delete -f deploy/crds/app.example.com_v1alpha1_appservice_cr.yaml
$ kubectl delete -f deploy/operator.yaml
$ kubectl delete -f deploy/role.yaml
$ kubectl delete -f deploy/role_binding.yaml
$ kubectl delete -f deploy/service_account.yaml
$ kubectl delete -f deploy/crds/app.example.com_appservices_crd.yamlNote: Follow the steps in the Getting Started Repository to learn how to develop your Operator projects.
To learn more about the SDK CLI, see the SDK CLI Reference, or run operator-sdk [command] -h.
To learn more about the writing an operator in Go, see the user guide.
The SDK also supports developing an operator using Ansible or Helm. See the Ansible and Helm operator user guides.
Note that each operator type has a different set of capabilities. When choosing what type to use for your project, it is important to understand the features and limitations of each of the project types and the use cases for your operator.
To explore any operator samples built using the operator-sdk, see the operator-sdk-samples.
For common Operator SDK related questions, see the FAQ.
See CONTRIBUTING for details on submitting patches and the contribution workflow.
See the proposal docs and issues for ongoing or planned work.
See reporting bugs for details about reporting any issues.
Operator SDK is under Apache 2.0 license. See the LICENSE file for details.