Allow configuring a NodeSelector in the Postgres kind

[ksala]

This add support for adding the NodeSelector label to the Postgresql kind.
We use this in a GKE cluster which has two node pools, default and preemptible, to have the Postgres pods scheduled only on the normal nodes.

[coveralls]

Coverage decreased (-0.002%) to 10.999% when pulling fdc1223 on ksala:master into 8c9033d on zalando-incubator:master.

[alexeyklyukin]

The code at cluster.go:compareStatefulSetWith needs to be extended to replace the statefulset when the nodeSelector changes and to report the differences (in the logs). That should require a rolling upgrade, as old pods might have been scheduled to the wrong node according to the new nodeSelector.

[alexeyklyukin]

Please, use the camelCase for the parameter name

[cehoffman]

I think having per cluster node affinity is useful. Did you know this can be done for all postgresql cluster operator config key node_readiness_label with a value of the form <label>:<value>,<2nd label>:<2nd value>. For example, in our configuration to only run on nodes with portworx.

  node_readiness_label: "px/enabled:true"

[Jan-M]

Yes, this does sounds like a reasonable use case. But maybe our naming of the variable is confusing then or there should be a second one that is explicit for this.

I also see this as a possible per cluster config option, in a way to add additional labels.

[alexeyklyukin]

@ksala I think what you are doing here can be indeed achieved with a node_readiness_label parameter as described at at the procedure for doing cluster upgrades. In addition to making sure your pod is scheduled on the nodes with a certain label, this feature also migrates master pods for you when the node label changes to indicate the node is no longer part of the 'ready' node.

Do you see any use case outside of choosing the ready/not-ready nodes that can be covered by setting node labels per-cluster?

[sdudoladov]

what you are doing here can be indeed achieved with a node_readiness_label parameter

Given that, and also the fact that the nodeSelector will be deprecated in favor of node affinity (see "Affinity and anti-affinity"), I suggest we close this PR.