mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
initial draft of overview for hosted control planes (hypershift)
This commit is contained in:
committed by
openshift-cherrypick-robot
parent
5b672eb51d
commit
f8022ee2bc
@@ -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 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].
|
||||
* 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 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].
|
||||
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)]
|
||||
|
||||
* 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)]
|
||||
BIN
images/hosted-control-planes-diagram.png
Normal file
BIN
images/hosted-control-planes-diagram.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 130 KiB |
41
modules/hosted-control-planes-overview.adoc
Normal file
41
modules/hosted-control-planes-overview.adoc
Normal file
@@ -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.
|
||||
Reference in New Issue
Block a user