This example demonstrates a simple Operator for Kubernetes that relies on a shell script for its main logic. This Operator is based on the config watcher Controller. We recommend trying the Controller demo first, as it will provide valuable context for understanding this Operator.
The Operator utilizes a dedicated Custom Resource Definition (CRD) called ConfigWatcher
, transforming our controller into an Operator. Most of the information about the Operator can be found within the resource files and the shell script that contains the main logic.
For a detailed explanation of how this demo works, refer to the Operator pattern in our book. This document will provide a brief walk-through of the example code.
Note
|
Before proceeding, ensure you have stopped the controller deployment from the Controller demo. You can remove it using kubectl delete -f config-watcher-controller.yml . Then, set up this Operator demo in a new namespace.
|
Warning
|
This example is meant for educational purposes only and is unsuitable for general-purpose usage. |
The following steps assume you are using minikube
. More options for running the example are described in the installation instructions.
First, install the CRD and create a role that allows the modification of custom resources created by this CRD:
kubectl apply -f https://k8spatterns.io/Operator/config-watcher-crd.yml
Verify that the CRD has been registered:
kubectl get crd
The operator script is stored in a ConfigMap
:
kubectl create configmap config-watcher-operator --from-file=./config-watcher-operator.sh
To deploy the Operator, a Deployment
creates a pod with two containers:
-
A Kubernetes API proxy container that exposes the Kubernetes API on localhost with port 8001. The image for
k8spatterns/kubeapi-proxy
is defined in this Dockerfile. -
The main container executes the script from the
ConfigMap
. It is based on an Alpine base image with included curl and jq. The Dockerfile for this imagek8spattern/curl-jq
can be found here.
Both images, k8spatterns/kubeapi-proxy and k8spatterns/curl-jq are available from Docker Hub.
To create this deployment in the current namespace, run the following:
kubectl apply -f https://k8spatterns.io/Operator/config-watcher-operator.yml
To see our Operator in action, we will reuse the same simple web application as in the Controller
example. This image exposes an environment variable as HTTP content on any request. The image uses nc
to deliver the content and is available on Docker Hub as k8spatterns/mini-http-server.
Before deploying the web app, open another terminal and tail the log of our Operator to see the events received by the Operator as they come in:
kubectl logs -f $(kubectl get pods -l role=operator -o name) config-watcher
Now, create the web application:
kubectl apply -f https://k8spatterns.io/Operator/web-app.yml
In the web-app.yml file, you will find a Deployment
using our HTTP server that references the content environment variable via a ConfigMap
. Unlike the other controller example, this ConfigMap
does not contain a reference to the pods to restart.
With minikube, access the application in your browser:
minikube service webapp
(Use the option -n namespace
if you have deployed this example in a different namespace than default
).
Stop the tunnel created by minikube service
(with CTRL-C
), update the content of ConfigMap
, and watch the controller’s log:
To trigger the Operator on a config change, install a custom resource of the ConfigWatcher
kind:
kubectl apply -f https://k8spatterns.io/Operator/config-watcher-sample.yml
Check that the resource has been created:
kubectl get configwatchers
After establishing the connection between the ConfigMap
and Pods
, change the content of the ConfigMap
and watch the Operator log:
kubectl patch configmap webapp-config -p '{"data":{"message":"Greets from your smooth operator!"}}'
Finally, call the URL again to verify that the content has been updated:
minikube service webapp