postgres-operator icon indicating copy to clipboard operation
postgres-operator copied to clipboard

Primary node priority and optimal Pod placement

Open dberardo-com opened this issue 2 years ago • 1 comments
trafficstars

Have an idea to improve PGO? We'd love to hear it! We're going to need some information from you to learn more about your feature requests.

Please be sure you've done the following:

  • [ x] Provide a concise description of your feature request.
  • [ x] Describe your use case. Detail the problem you are trying to solve.
  • [ x] Describe how you envision that the feature would work.
  • [ ] Provide general information about your current PGO environment.

Overview

It would be great to have all ingredients to achieve the following during "steady-state" cluster operation:

  • database intensive pods should be always placed on the node where the current primary is located. this way their queries will go "over localhost" and be much faster
  • "high budget" machines should be more likely to become primaries during elections. If the current primary is not the "preferred one" then a new election should be triggered

Use Case

The second point from the list above is a quite demanded feature. The first point on the list is what i am trying to achieve, and point 2 could actually be a possible workaround. Even better would be having something like a dynamic NodeLabel being assigned by pgo on the node hosting the primary, so that this label can be used within node affinity rules by the pod.

Environment

Tell us about your environment:

Please provide the following details:

  • Kubernetes / k3s

dberardo-com avatar Jan 31 '23 14:01 dberardo-com

i see that the pod holding the lock is labeled with:: postgres-operator.crunchydata.com/role=master

would it be possible to use this label with pod-affinity rules ? and is it possible to make sure the rule always hold, even after election ?

example:

  • pod 1 and postgres leader are on same node A
  • node A fails
  • pod 1 and postgres leader are now changed to node B
  • node A comes back
  • postgres cluster triggers election and node A becomes leader
  • pod 1 is restarted on node A after leader change

this would be a use cas for requiredDuringSchedulingRequiredDuringExecution but i am not sure if this is already availale

dberardo-com avatar Jan 31 '23 14:01 dberardo-com