This post continues from Operator SDK Part1 and looks at building the operators container image and running the operator.
Building the Operator Container
An operator container image contains the operator runtime for the type of operator and your business logic.
The command make docker-build IMG=$IMG_NAME:TAG
creates the operator container image using a Dockerfile
in the projects root directory. The initialization process generates the Dockerfile
based on the type of operator.
The image needs to be pushed to an image registry before Kubernetes clusters can consume it.
Dockerfile for Ansible Operator
|
|
Dockerfile for Helm Operator
|
|
Dockerfile for Helm Operator
|
|
The operator container runs on a cluster in a pod called the manager
. The manager’s default imagePullPolicy
is IfNotPresent
, which means if you rerun a test with the same image tag, the cluster does not pull the updated image. To counter this behaviour without changing the imagePullPolicy
I use separate repositories for testing and production images.
Testing image tag: quay.io/brejohns/vault-helm-dev:0.0.50
Published image tag: quay.io/brejohns/vault-helm:0.0.2
Create a Bundle
Bundle creation uses Kustomize to generate manifests from the files in the config/
directory. The bundle includes
A bundle contains all the manifests required to deploy your operator to a cluster.
There are several arguments required to generate a bundle using the Makefile
:
CHANNELS
defines the operators release channelsDEFAULT_CHANNEL
the default channel to use if none is specified when deploying the operatorVERSION
the operators version numberIMG
the operators container image tag
After creating the bundle manifests can build and push a bundle container image. This image contains the bundle manifests and is used by OLM.
Deploying an Operator
There are several options deployment options available; Local, Bundle and OLM. You are likely to use all three during various operator testing and development stages, though OLM is the most like to be used for final distribution.
All deployment options require that the current-content
in ~/.kube/config
or the file referenced by the environmental variable KUBECONFIG
is valid.
Local
Run the command make install kustomize
to generate and apply the required manifests to the cluster.
The command make install run
applies all your manifests to the cluster and runs the manager process on your local machine. The command obtains the operator runtime binary for Ansible and Helm based operators; a binary is compiled for a Go-based operator.
Running an operator is simple deployment method and helpful for testing during the development process as the manager logs stream to stdout
.
As a Deployment
This option deploys the operator to the cluster using the manifest template config/manager/manager.yaml
.
To deploy the operator as a deployment, you’ll need to build the operators container image and push it to an image registry. Additional steps may be required to configure image pull secrets if you’re using a private registry.
Make sure to change the tag number each time or set the imagePullPolicy
to always
in config/manager/manager.yaml
.
After completing the image build and push steps, run make deploy IMG=<image tag>
. This command generates manifests with Kustomize and then applies them to the cluster.
Run make undeploy
to clean up the cluster between tests.
OLM
This method uses the OLM to deploy and manage your operator on a cluster by running an operator registry on your cluster. You’ll need to complete several steps to deploy using OLM.
Check if OLM is installed on the cluster by running operator-SDK olm status
.
OLM not installed:
|
|
OLM installed:
|
|
Run operator-sdk olm install
to install OLM if it is not already installed.
To deploy with OLM
- Build and Deploy an operator container image
- Create bundle manifests
- Build and push bundle image
- Validate bundle
- Use operator-SDK to serve the bundle to OLM.
The below commands perform the above-mentioned tasks:
|
|
The operator-sdk run bundle
command deploys a pod that serves as your operators’ source catalogue and creates a subscription
object. A subscription
object specifies your intent to install and operator and describes the installation parameters.
Summary
Part 2 of our look into the Operator-SDK focused on how to build and deploy operators for testing. This post did not cover distribution and Deployment using operator registries; a future post will cover this topic.
I hope this post helps you to continue building and deploying operators of your own.