heidloff.net - Building is my Passion
Post
Cancel

Defining Dependencies in Kubernetes Operators

Operators can automate the deployment and operations of custom Kubernetes resources. These resources might dependent on other third party resources. This article describes how to define these dependencies.

I’m working on a sample that describes different patterns and best practices to build operators with Golang. The repo demonstrates how a custom resource ‘Application’ uses internally a third party ‘Database’ resource which is managed by another controller. This is a simplified version of the typical scenario to use a managed database in the cloud. Read my previous blog that explains how to access third party resources in controllers’ Go code.

Additionally you need to ensure that the dependent operator (in my sample the database operator) exists when an operator (in my sample the application operator) is deployed. This can be done in the cluster service version (CSV). The CSV is the operator bundle/package which contains the definition of a specific operator version.

Here is the CSV of the application operator. The dependency is defined in the ‘required’ section of the spec.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
spec:
  apiservicedefinitions: {}
  customresourcedefinitions:
    owned:
    - displayName: Application
      kind: Application
      name: applications.application.sample.ibm.com
      version: v1alpha1
    required:
    - displayName: Database
      kind: Database
      name: databases.database.sample.third.party
      version: v1alpha1    

When you try to deploy the application operator, but the database operator doesn’t exist, you get an error.

1
2
3
4
5
$ operator-sdk run bundle "$REGISTRY/$ORG/$BUNDLEIMAGE" -n operators
INFO[0040] Successfully created registry pod: docker-io-nheidloff-application-controller-bundle-v15 
INFO[0041] Created CatalogSource: operator-application-catalog 
INFO[0041] Created Subscription: operator-application-v0-0-1-sub 
FATA[0120] Failed to run bundle: install plan is not available for the subscription operator-application-v0-0-1-sub: timed out waiting for the condition 

The logs in the catalog pod describe the error.

1
2
3
$ kubectl get pods -n olm
$ kubectl logs catalog-operator-b4dfcff47-55plr -n olm
Event(v1.ObjectReference{Kind:"Namespace", Namespace:"", Name:"operators", ... type: 'Warning' reason: 'ResolutionFailed' constraints not satisfiable: bundle operator-application.v0.0.1 requires an operator providing an API with group: database.sample.third.party, version: v1alpha1, kind: Database

The following resources describe more details.

Check out the repo and keep an eye on my blog. I’ll write more about other operator patterns soon.

Featured Blog Posts
Disclaimer
The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.
Trending Tags