mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
55 lines
4.0 KiB
Plaintext
55 lines
4.0 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * scalability_and_performance/telco_ran_du_ref_design_specs/telco-ran-du-rds.adoc
|
|
// * scalability_and_performance/telco_ref_design_specs/core/telco-core-ref-design-components.adoc
|
|
|
|
:_mod-docs-content-type: REFERENCE
|
|
[id="telco-ran-gitops-operator-and-ztp-plugins_{context}"]
|
|
= GitOps Operator and {ztp}
|
|
|
|
New in this release::
|
|
* No reference design updates in this release
|
|
|
|
Description::
|
|
+
|
|
--
|
|
GitOps Operator and {ztp} provide a GitOps-based infrastructure for managing cluster deployment and configuration.
|
|
Cluster definitions and configurations are maintained as a declarative state in Git.
|
|
You can apply `ClusterInstance` CRs to the hub cluster where the `SiteConfig` Operator renders them as installation CRs.
|
|
In earlier releases, a {ztp} plugin supported the generation of installation CRs from `SiteConfig` CRs.
|
|
This plugin is now removed.
|
|
A separate {ztp} plugin is available to enable automatic wrapping of configuration CRs into policies based on the `PolicyGenerator` or `PolicyGenTemplate` CR.
|
|
|
|
You can deploy and manage multiple versions of {product-title} on managed clusters using the baseline reference configuration CRs.
|
|
You can use custom CRs alongside the baseline CRs.
|
|
To maintain multiple per-version policies simultaneously, use Git to manage the versions of the source and policy CRs by using `PolicyGenerator` or `PolicyGenTemplate` CRs.
|
|
{rh-rhacm} `PolicyGenerator` is the recommended generator plugin starting from {product-title} 4.19 release.
|
|
--
|
|
|
|
Limits and requirements::
|
|
// Scale results ACM-17868
|
|
* 1000 `ClusterInstance` CRs per ArgoCD application.
|
|
Multiple applications can be used to achieve the maximum number of clusters supported by a single hub cluster
|
|
* Content in the `source-crs/` directory in Git overrides content provided in the ZTP plugin container, as Git takes precedence in the search path.
|
|
* The `source-crs/` directory must be located in the same directory as the `kustomization.yaml` file, which includes `PolicyGenerator` CRs as a generator.
|
|
Alternative locations for the `source-crs/` directory are not supported in this context.
|
|
|
|
Engineering considerations::
|
|
* For multi-node cluster upgrades, you can pause `MachineConfigPool` (`MCP`) CRs during maintenance windows by setting the `paused` field to `true`.
|
|
You can increase the number of simultaneously updated nodes per `MCP` CR by configuring the `maxUnavailable` setting in the `MCP` CR.
|
|
The `MaxUnavailable` field defines the percentage of nodes in the pool that can be simultaneously unavailable during a `MachineConfig` update.
|
|
Set `maxUnavailable` to the maximum tolerable value.
|
|
This reduces the number of reboots in a cluster during upgrades which results in shorter upgrade times.
|
|
When you finally unpause the `MCP` CR, all the changed configurations are applied with a single reboot.
|
|
* During cluster installation, you can pause custom MCP CRs by setting the paused field to true and setting `maxUnavailable` to 100% to improve installation times.
|
|
* Keep reference CRs and custom CRs under different directories.
|
|
Doing this allows you to patch and update the reference CRs by simple replacement of all directory contents without touching the custom CRs.
|
|
When managing multiple versions, the following best practices are recommended:
|
|
** Keep all source CRs and policy creation CRs in Git repositories to ensure consistent generation of policies for each {product-title} version based solely on the contents in Git.
|
|
** Keep reference source CRs in a separate directory from custom CRs.
|
|
This facilitates easy update of reference CRs as required.
|
|
* To avoid confusion or unintentional overwrites when updating content, it is highly recommended to use unique and distinguishable names for custom CRs in the `source-crs/` directory and extra manifests in Git.
|
|
* Extra installation manifests are referenced in the `ClusterInstance` CR through a `ConfigMap` CR.
|
|
The `ConfigMap` CR should be stored alongside the `ClusterInstance` CR in Git, serving as the single source of truth for the cluster.
|
|
If needed, you can use a `ConfigMap` generator to create the `ConfigMap` CR.
|