vmwclabot
commented
3 years ago @hrosenbe, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding Signed-off-by: John Doe <john.doe@email.org> to the last line of each Git commit message. The e-mail address used to sign must match the e-mail address of the Git author. Click here to view the Developer Certificate of Origin agreement.
- Commit c570947d7f01a294dc24ad8f09e752e3c313bd09 must be signed by griderr@vmware.com
- Commit b9e59232075e03c9d6ade595d108e540e25a8ce9 has a no-reply/unreachable author email address: 45051453+bhoflich@users.noreply.github.com
- Commit 070411080940d2a048576f9f44ef8135887dc696 has a no-reply/unreachable author email address: 45051453+bhoflich@users.noreply.github.com
The changes in this pull request add parameters that control the addition of pod affinity and anti-affinity rules to the pod manifests. With these changes, the default is to add rules that create a preference for anti-affinity for pods of a given type across all namespaces. This leads to a more even load across all nodes and more predictable results.
The parameters are:
podInstanceAffinity: If true, a podAffinity rule will be used to create affinity among pods of the same application instance. Default = false.podInstanceAffinityWeight: The weight for the above rule. Default = 50 .serviceTypeAntiAffinity: If true, a podAntiAffinity rule will be used to create anti-affinity among pods of the same type across all application instance. Default = trueserviceTypeAntiAffinityWeight: The weight for the above rule. Default = 100serviceTypeAffinity: If true, a required podAntiAffinity rule will be used to create affinity among pods of the same type across all application instances. There must be enough nodes for each type, and the largest pods of all instances must fit into a single node. This is mutually exclusive withpodInstanceAffinityandserviceTypeAntiAffinity. Default = falseserviceTypeNodeLabels: This works similar to instanceNodeLabels, but allows you to label specific nodes for specific types of pods. The label must exist for the pod to be schedule-able (it is a required rule). The node labels are of the form wvappServer= , wvwebServer=, etc. A node can have multiple of these labels to host multiple types of pods, and you can have multiple nodes with the same label, but there must be at least one node labeled for each type of pod.