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.