update design doc with affinity

Jeff McCormick · Jeff McCormick · commit 510354218112 · 2018-02-09T16:34:58.000-06:00
diff --git a/docs/design.asciidoc b/docs/design.asciidoc
@@ -1,6 +1,8 @@
 = 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:
