Kubernetes Operators

Appendix A. Running an Operator as a Deployment Inside a Cluster

Running an Operator outside of the cluster, is convenient for testing and debugging purposes, but production Operators run as Kubernetes deployments. There are a few extra steps involved for this deployment style:

1. Build the image. The Operator SDK’s build command chains to the underlying Docker daemon to build the Operator image, and takes the full image name and version when run:

   $ operator-sdk build jdob/visitors-operator:0.1
   

2. Configure the deployment. Update the deploy/operator.yaml file that the SDK generates with the name of the image. The field to update is named image and can be found under:

   spec -> template -> spec -> containers

   The generated file defaults the value to REPLACE_IMAGE, which you should update to reflect the name of the image built in the previous command.

   Once built, push the image to an externally accessible repository such as Quay.io or Docker Hub.

3. Deploy the CRD. The SDK generates a skeleton CRD that will function correctly, but see Appendix B for more information on fleshing out this file:

   $ kubectl apply -f deploy/crds/*_crd.yaml
   

4. Deploy the service account and role. The SDK generates the service account and role required by the Operator. Update these to limit the permissions of the role to the minimum of what is needed for the Operator to function.

   Once you have scoped the role permissions appropriately, deploy the resources into the cluster:

   $ kubectl apply -f deploy/service_account.yaml ...