Description of problem:
The operators that are responsible for the pods in the namespaces
have no option to configure the workload via an NodeSelector.
Version-Release number of selected component (if applicable):
OCP4 HTB 3
Steps to Reproduce:
1. Deploy cluster
2. There is no NodeSelector available to configure the workload as desired
The marketplace-operator runs on the master nodes, and its "replicas" is 1. As below:
mac:~ jianzhang$ oc get deployment marketplace-operator -o yaml|grep -i nodeSelector -A 2
mac:~ jianzhang$ oc get deployment marketplace-operator -o yaml|grep replicas
mac:~ jianzhang$ oc get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
certified-operators-7bd7768fcf-lbxb2 1/1 Running 0 3h49m 10.128.2.6 ip-172-31-130-114.us-east-2.compute.internal <none> <none>
community-operators-74d75b747c-d7rvr 1/1 Running 0 3h49m 10.131.0.7 ip-172-31-151-102.us-east-2.compute.internal <none> <none>
marketplace-operator-5d8bf7668f-r28pn 1/1 Running 0 3h49m 10.128.0.32 ip-172-31-158-104.us-east-2.compute.internal <none> <none>
redhat-operators-6865f9b7b5-g9xm4 1/1 Running 0 3h49m 10.128.2.7 ip-172-31-130-114.us-east-2.compute.internal <none> <none>
only the marketplace-operator is running on the masters, all others pods in the namespace openshift-marketplace are not bound via nodeSelector to the masters.
oc get po -n openshift-marketplace -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
certified-operators-7dc989fc9d-fmzl7 1/1 Running 0 3d18h 192.168.20.11 ocp4-nmz4m-infra-s2large4-eude03-nxbfd <none>
community-operators-5995cd994b-szhrq 1/1 Running 0 3d18h 192.168.20.12 ocp4-nmz4m-infra-s2large4-eude03-nxbfd <none>
marketplace-operator-6ffff946cc-24vm7 1/1 Running 0 3d18h 192.168.2.58 ocp4-nmz4m-master-2 <none>
redhat-operators-6c5595fd66-mk224 1/1 Running 0 3d18h 192.168.14.9 ocp4-nmz4m-worker-s2large4-eude03-rwmgn <none>
From my point of view it will be good to be able to bind the pods to the infra nodes.
certified-operators, redhat-operators and community-operator pods are ones associated with CatalogSources that are created as a result of adding those OperatorSources (which is a CR that the marketplace operator watches) to the cluster. They are not part of the marketplace operator. Given that, they shouldn't be bound to the master node via a nodeSelector.
After discussing with Jessica, we concluded that the grpc CatalogSource pods should *not* be running on master as they are secondary resources. Moreover they should be launched with multiple replicas in such a way that the OperatorHub experience does not degrade. Currently we shouldn't see any degradation given the way CatalogSource are synced, but we should not depend on that. This is something we can fix in the 4.2 time frame rather introducing this change at this juncture.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.