Clarify high availability recommendations in Elasticsearch orchestrat…

…ion docs (#8151) (#8154)

This updates the orchestration documentation to clarify high availability setup recommendations.

---------
Co-authored-by: David Kilfoyle <[email protected]>
Co-authored-by: Peter Brachwitz <[email protected]>
Co-authored-by: Stef Nestor <[email protected]>

docs/orchestrating-elastic-stack-applications/elasticsearch/orchestration.asciidoc

@@ -149,7 +149,7 @@ Due to relying on Kubernetes primitives such as StatefulSets, the ECK orchestrat
 ** Single-node clusters
 ** Clusters containing indices with no replicas
 
-If an Elasticsearch node holds the only copy of a shard, this shard becomes unavailable while the node is upgraded. Clusters with more than one node and at least one replica per index are recommended.
+If an {es} node holds the only copy of a shard, this shard becomes unavailable while the node is upgraded. To ensure link:{ref}/high-availability-cluster-design.html[high availability] it is recommended to configure clusters with three master nodes, more than one node per link:{ref}/data-tiers.html[data tier] and at least one replica per index.
 
 * Elasticsearch Pods may stay `Pending` during a rolling upgrade if the Kubernetes scheduler cannot re-schedule them back. This is especially important when using local PersistentVolumes. If the Kubernetes node bound to a local PersistentVolume does not have enough capacity to host an upgraded Pod which was temporarily removed, that Pod will stay `Pending`.