Merge pull request #47565 from lahinson/hosted-control-planes-overview

OSDOCS-3809 initial draft of overview for hosted control planes (hypershift)

Author: michaelryanpeter

architecture/control-plane.adoc

@@ -37,8 +37,16 @@ include::modules/update-service-overview.adoc[leveloffset=+1]
 
 include::modules/understanding-machine-config-operator.adoc[leveloffset=+1]
 
-.Additional information
+[role="_additional-resources"]
+.Additional resources
+* For more information about detecting configuration drift, see xref:../post_installation_configuration/machine-configuration-tasks.adoc#machine-config-drift-detection_post-install-machine-configuration-tasks[Understanding configuration drift detection].
+
+* For information about preventing the control plane machines from rebooting after the Machine Config Operator makes changes to the machine configuration, see xref:../support/troubleshooting/troubleshooting-operator-issues.adoc#troubleshooting-disabling-autoreboot-mco_troubleshooting-operator-issues[Disabling Machine Config Operator from automatically rebooting].
 
-* For more information on detecting configuration drift, see xref:../post_installation_configuration/machine-configuration-tasks.adoc#machine-config-drift-detection_post-install-machine-configuration-tasks[Understanding configuration drift detection].
+include::modules/hosted-control-planes-overview.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+* link:https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.5/html/multicluster_engine/advanced-config-engine#hypershift-addon-intro[Hypershift add-on (Technology Preview)]
 
-* For information on preventing the control plane machines from rebooting after the Machine Config Operator makes changes to the machine config, see xref:../support/troubleshooting/troubleshooting-operator-issues.adoc#troubleshooting-disabling-autoreboot-mco_troubleshooting-operator-issues[Disabling Machine Config Operator from automatically rebooting].
+* link:https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.5/html/clusters/managing-your-clusters#hosted-control-plane-intro[Leveraging hosted control plane clusters (Technology Preview)]

images/hosted-control-planes-diagram.png

@@ -0,0 +1,41 @@
+// Module included in the following assemblies:
+//
+// * architecture/control-plane.adoc
+
+
+:_content-type: CONCEPT
+[id="hosted-control-planes-overview_{context}"]
+= Overview of hosted control planes (Technology Preview)
+
+You can use hosted control planes for Red Hat {product-title} to reduce management costs, optimize cluster deployment time, and separate management and workload concerns so that you can focus on your applications.
+
+You can enable hosted control planes as a Technology Preview feature by using the link:https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.5/html/multicluster_engine/requirements-and-recommendations[multicluster engine for Kubernetes operator version 2.0] on Amazon Web Services (AWS).
+
+:FeatureName: Hosted control planes
+include::snippets/technology-preview.adoc[]
+
+[id="hosted-control-planes-architecture_{context}"]
+== Architecture of hosted control planes
+
+Typically, {product-title} is deployed in a coupled model, where a cluster consists of a control plane and a data plane. The control plane includes an API endpoint, a storage endpoint, a workload scheduler, and an actuator that ensures state. The data plane includes compute, storage, and networking where workloads and applications run.
+
+The control plane is hosted by a dedicated group of nodes, which can be physical or virtual, with a minimum number to ensure quorum. The network stack is shared. Administrator access to a cluster offers visibility into the cluster's control plane, machine management APIs, and other components that contribute to the state of a cluster.
+
+Although the coupled model works well, some situations require an architecture where the control plane and data plane are decoupled. In those cases, the data plane is on a separate network domain with a dedicated physical hosting environment. The control plane is hosted by using high-level primitives such as deployments and stateful sets that are native to Kubernetes. The control plane is treated as any other workload.
+
+image::hosted-control-planes-diagram.png[Diagram that compares the hosted control plane model against OpenShift with a coupled control plane and workers]
+
+[id="hosted-control-planes-benefits_{context}"]
+== Benefits of hosted control planes
+
+With hosted control planes for {product-title}, you can pave the way for a true hybrid-cloud approach and enjoy several other benefits.
+
+* The security boundaries between management and workloads are stronger because the control plane is decoupled and hosted on a dedicated hosting service cluster. As a result, you are less likely to leak credentials for clusters to other users. Because infrastructure secret account management is also decoupled, cluster infrastructure administrators cannot accidentally delete control plane infrastructure.
+
+* With hosted control planes, you can run many control planes on fewer nodes. As a result, clusters are more affordable.
+
+* Because the control planes consist of pods that are launched on {product-title}, control planes start quickly. The same principles apply to control planes and workloads, such as monitoring, logging, and auto-scaling.
+
+* From an infrastructure perspective, you can push registries, HAProxy, cluster monitoring, storage nodes, and other infrastructure components to the tenant's cloud provider account, isolating usage to the tenant.
+
+* From an operational perspective, multicluster management is more centralized, which results in fewer external factors that affect the cluster status and consistency. Site reliability engineers have a central place to debug issues and navigate to the cluster data plane, which can lead to shorter Time to Resolution (TTR) and greater productivity.