move cluster info to explanations

Author: gilesknap

docs/how-to/kubernetes_cluster.rst renamed to docs/explanations/kubernetes_cluster.rst

@@ -6,21 +6,29 @@ Cluster Options
 
 Three cluster topology approaches were considered for this project.
 
-- **Separate Kubernetes cluster per beamline**. This could be as simple as
-  a single server and the K3S installation described in
+:Cluster per beamline:
+  This could be as simple as
+  a single server: the K3S installation described in
   `setup_kubernetes` may be sufficient. The documentation at
   https://rancher.com/docs/k3s/ also details how to make a high availability
   cluster, requiring a minimum of 4 servers.
-
-- **A Central Facility Cluster**. A central facility cluster that runs
+  This approach keeps the configuration of the clusters quite straightforward
+  but at the cost of having multiple separate clusters to maintain. Also
+  it requires control plane servers for every beamline, whereas a centralized
+  approach would only need a handful of control plane servers for the entire
+  facility.
+
+:Central Facility Cluster:
+  A central facility cluster that runs
   all IOCs on its own nodes would keep everything centralized and provide
   economy of scale. However, there are significant issues with routing
   Channel Access, PVA and some device protocols to IOCs running in a
   different subnet to the beamline. DLS spent some time working around these
   issues but eventually abandoned this approach.
 
-- **Central Cluster with Beamline nodes**. This approach uses the central
-  cluster but adds beamline nodes that sit in the beamline itself,
+:Beamline Worker Nodes:
+  This approach uses the central
+  cluster but adds remote beamline nodes located in the beamline itself,
   connected to the beamline subnet. This has all the benefits of central
   management but is able to overcome the problems with protocol routing.
   The DLS argus cluster configuration described below is an example of

docs/images

@@ -0,0 +1 @@
+../images/

docs/index.rst

@@ -58,6 +58,7 @@ About the documentation
     explanations/strategy
     explanations/whats_in
     explanations/net_protocols
+    explanations/kubernetes_cluster
 
 .. toctree::
     :caption: How-to Guides
@@ -67,7 +68,6 @@ About the documentation
     how-to/create_ioc
     how-to/generic_iocs
     how-to/debug
-    how-to/kubernetes_cluster
 
 .. rst-class:: no-margin-after-ul
 

docs/reference/faq.rst

@@ -40,7 +40,8 @@ IOC instance Helm Charts. However it is still possible to roll back an IOC
 version when the internet is not available.
 
 That is because Helm keeps track of several versions of each chart it
-deploys, they are stored in the cluster itself.
+deploys, they are stored in the cluster itself (as ReplicaSets). By
+default the last 10 are saved.
 
 It is also necessary Kubernetes to be able to pull the generic IOC image. If
 the beamline has only one Kubernetes worker node then the previous image will