mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
38 lines
2.2 KiB
Plaintext
38 lines
2.2 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
|
|
|
|
:_mod-docs-content-type: REFERENCE
|
|
[id="telco-ran-red-hat-advanced-cluster-management-rhacm_{context}"]
|
|
= Red Hat Advanced Cluster Management
|
|
|
|
New in this release::
|
|
* The CRI-O wipe disable `MachineConfig` CR is no longer needed as cri-o now handles unclean shutdowns by performing a quick check and repair.
|
|
|
|
Description::
|
|
+
|
|
--
|
|
{rh-rhacm} provides Multi Cluster Engine (MCE) installation and ongoing lifecycle management functionality for deployed clusters.
|
|
You manage cluster configuration and upgrades declaratively by applying `Policy` custom resources (CRs) to clusters during maintenance windows.
|
|
|
|
{rh-rhacm} provides the following functionality:
|
|
|
|
* Zero touch provisioning (ZTP) of clusters using the MCE component in {rh-rhacm}.
|
|
* Configuration, upgrades, and cluster status through the {rh-rhacm} policy controller.
|
|
* During managed cluster installation, {rh-rhacm} can apply labels to individual nodes as configured through the `ClusterInstance` CR.
|
|
|
|
The recommended method for {sno} cluster installation is the image-based installation approach, available in MCE, using the `ClusterInstance` CR for cluster definition.
|
|
|
|
Image-based upgrade is the recommended method for {sno} cluster upgrade.
|
|
--
|
|
|
|
Limits and requirements::
|
|
* A single hub cluster supports up to 3500 deployed {sno} clusters with 5 `Policy` CRs bound to each cluster.
|
|
|
|
Engineering considerations::
|
|
* Use {rh-rhacm} policy hub-side templating to better scale cluster configuration.
|
|
You can significantly reduce the number of policies by using a single group policy or small number of general group policies where the group and per-cluster values are substituted into templates.
|
|
* Cluster specific configuration: managed clusters typically have some number of configuration values that are specific to the individual cluster.
|
|
These configurations should be managed using {rh-rhacm} policy hub-side templating with values pulled from `ConfigMap` CRs based on the cluster name.
|
|
* To save CPU resources on managed clusters, policies that apply static configurations should be unbound from managed clusters after {ztp} installation of the cluster.
|