update design doc with affinity
= postgres Operator Design
+:toc:
v2.5, {docdate}
+
image::crunchy_logo.png?raw=true[]
== Reference Architecture
@@ -98,6 +100,41 @@ pgo create cluster mycluster
In the above example, the *show*, *backup*, *delete*, and *create* verbs are used. The CLI is case sensitive and supports only lowercase.
+== Affinity
+
+You can have the Operator add an affinity section to
+a new Cluster Deployment if you want to cause Kube to
+attempt to schedule a Primary cluster to a specific Kube node.
+
+You can see the nodes on your Kube cluster by:
+....
+kubectl get nodes
+....
+
+You can then specify one of those names (e.g. kubeadm-node2) when creating a cluster:
+....
+pgo create cluster thatcluster --node-name=kubeadm-node2
+....
+
+The affinity rule inserted in the Deployment will used a *preferred*
+strategy so that if the node were down or not available, Kube would
+go ahead and schedule the Pod on another node.
+
+You can always view the actual node your cluster pod is scheduled
+on by:
+....
+kubectl get pod -o wide
+....
+
+When you scale up a Cluster and add a replica, the scaling will
+take into account the use of "--node-name". If it sees that a
+cluster was created with a specific node name, then the replica
+Deployment will add an affinity rule to attempt to schedule
+the replica on a different node than the node the primary is
+schedule on. This gets you a simple for of High Availability so
+that your primary and replicas will not live on the same Kube node.
+
+
== Debugging
To see if the operator pod is running enter the following:
