Overriding CatalogSource Pod Scheduling Configuration

Overriding CatalogSource Pod Scheduling Configuration

When given a CatalogSource of type grpc with spec.image defined, the catalog operator will create Pod that serves the content in spec.image. By default, this pod defines in its spec no tolerations, no priorityClassName, and only the following node selector: kubernetes.io/os=linux. These values can be overriden with CatalogSource’s spec.grpcPodConfig. For instance,

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: operatorhubio-catalog
  namespace: olm
spec:
  sourceType: grpc
  image: quay.io/operatorhubio/catalog:latest
  displayName: Community Operators
  publisher: OperatorHub.io

  # optional
  grpcPodConfig:
    # override nodeSelector
    # for more information on nodeSelectors see:
    # https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector
    # optional
    nodeSelector:
      custom_label: value
    
    # change priorityClassName
    # kubernetes ships with: system-cluster-critical and system-node-critical
    # setting it to empty ("") will assign the pod the default priority.
    # Other priority classes can be defined manually. For more information on priority classes see:
    # https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass
    # optional
    priorityClassName: system-cluster-critical

    # override tolerations
    # for more information on taints and tolerations see:
    # https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration
    # optional
    tolerations:
      - key: "key1"
        operator: "Equal"
        value: "value1"
        effect: "NoSchedule"

As can be seen in the example, spec.grpcPodConfig and all of its attributes are optional. These attributes are: nodeSelector, priorityClassName, and tolerations. It should be noted that priorityClassName can be overriden to be "". This will give the pod the default priority. Any value outside system-cluster-critical, system-node-critical, and "" will need to correspond to a pre-existing and custom defined priorityClass.

Previously, the only pod scheduling parameter that could be overriden was the priorityClassName. This was done by adding the following annotation to the CatalogSource CR: operatorframework.io/priorityclass. For instance:

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: operatorhubio-catalog
  namespace: olm
  annotations:
    # kubernetes ships with: system-cluster-critical and system-node-critical
    # setting it to empty ("") will assign the pod the default priority.
    # Other priority classes can be defined manually. For more information on priority classes see:
    # https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass
    # optional
    operatorframework.io/priorityclass: system-cluster-critical
spec:
  sourceType: grpc
  image: quay.io/operatorhubio/catalog:latest
  displayName: Community Operators
  publisher: OperatorHub.io

NOTE: If a CatalogSource CR defines both the annotation and spec.grpcPodConfig.priorityClassName, the annotation will take precedence over the configuration parameter.