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
   $ kubectl apply -f deploy/role.yaml
   $ kubectl apply -f deploy/role_binding.yaml
   

   Warning

   You must deploy these files in the order listed, as the role binding requires both the role and the service account to be in place.

5. Create the Operator deployment. The last step is to deploy the Operator itself. You can use the previously edited operator.yaml file to deploy the Operator image into the cluster:

   $ kubectl apply -f deploy/operator.yaml