Skip to content

Latest commit

 

History

History
116 lines (91 loc) · 4 KB

install.md

File metadata and controls

116 lines (91 loc) · 4 KB
Raw

Installation Guide

Operators extend Kubernetes functionality and must be installed after the cluster is deployed.

This guide provides multiple ways to install the compliance-operator in an OpenShift or Kubernetes cluster and assumes you have adminsitrative privileges on the cluster to create the necessary resources.

By default, the compliance-operator is installed in the openshift-compliance namespace. This guide assumes all required resources are also installed within that namespace. You may run the operator in another namespace, but you need to ensure all subsequent resources, like service accounts, operator groups, and subscriptions also use the same namespace as the operator.

Deploying:

To deploy the operator using the latest released compliance-operator images available on quay.io, run:

$ make deploy

Alternately, to deploy the latest release through OLM, run:

$ make catalog-deploy

Building and deploying from source:

First set an image repo and tag to use. Make sure that you have permissions to push compliance-operator* images (and relevant tag) to the repo.

$ export IMAGE_REPO=quay.io/myrepo
$ export TAG=mytag

With these set, they will apply to the rest of the Makefile targets. Next, build and push the operator and bundle images by running:

$ make images && make push

Finally, deploy the operator with the built images,

$ make deploy

or build a catalog and deploy from OLM:

$ make catalog && make catalog-deploy

Deploying with Helm

The repository contains a Helm chart that deploys the compliance-operator. This chart is currently not published to any official registries and requires that you install Helm version v3.0.0 or greater. You're required to run the chart from this repository.

Make sure you create the namespace prior to running helm install:

$ kubectl create -f config/ns/ns.yaml

Next, deploy a release of the compliance-operator using helm install from config/helm/:

$ cd config/helm
$ helm install --namespace openshift-compliance --generate-name .

The chart defines defaults values in values.yaml. You can override these values in a specific file or supply them to helm using --set. For example, you can run the compliance-operator on EKS using the EKS-specific overrides in eks-values.yaml:

$ helm install . --namespace openshift-compliance --generate-name -f eks-values.yaml

You can use Helm to uninstall, or delete a release, but Helm does not cleanup custom resource definitions. You must do this manually if you want to remove the custom resource definitions required by the compliance-operator.

Verifying the installation

You can verify the operator deployed successfully by inspecting the cluster service version:

$ kubectl get csv --namespace openshift-compliance

You should also see a running deployment and pods within the namespace you created prior to the installation:

$ oc get deploy --namespace openshift-compliance
$ oc get pods --namespace openshift-compliance

Namespace removal

Many custom resources deployed with the compliance operators use finalizers to handle dependencies between objects. If the whole operator namespace gets deleted (e.g., with oc delete ns openshift-compliance), the order of deleting objects in the namespace is not guaranteed. What can happen is that the operator itself is removed before the finalizers are processed which would manifest as the namespace being stuck in the Terminating state.

It is recommended to remove all custom resources and custom resource defintions prior to removing the namespace to avoid this issue. The Makefile provides a tear-down target that does exactly that.

If the namespace is stuck, you can work around by the issue by hand-editing or patching any custom resources and removing the finalizers attributes manually.