diff --git a/modules/multi-arch-creating-podplacment-config.adoc b/modules/multi-arch-creating-podplacment-config.adoc index c281a36231..324b2937e1 100644 --- a/modules/multi-arch-creating-podplacment-config.adoc +++ b/modules/multi-arch-creating-podplacment-config.adoc @@ -46,5 +46,5 @@ In this example, the `operator` field value is set to `Exists`. Therefore, the o [IMPORTANT] ==== -The namespaces starting with `openshift-`, `kube-`, and `hypershift-` are excluded. +This Operator excludes pods in namespaces starting with `kube-`. It also excludes pods that are expected to be scheduled on control plane nodes. ==== \ No newline at end of file diff --git a/modules/multi-arch-deleting-podplacment-config-using-cli.adoc b/modules/multi-arch-deleting-podplacment-config-using-cli.adoc index ada6fdd8c1..a0962815e9 100644 --- a/modules/multi-arch-deleting-podplacment-config-using-cli.adoc +++ b/modules/multi-arch-deleting-podplacment-config-using-cli.adoc @@ -39,13 +39,4 @@ $ oc get clusterpodplacementconfig [source,terminal] ---- No resources found ----- - -.Next steps - -* After deleting the `ClusterPodPlacementConfig` object, ensure that none of the pods are in the `Pending` phase due to the `SchedulingGated` reason. You can delete the scheduling gate from all of the gated pods by running the following command: -+ -[source,terminal] ----- -$ oc get pods -A -l multiarch.openshift.io/scheduling-gate=gated -o json | jq 'del(.items[].spec.schedulingGates[] | select(.name=="multiarch.openshift.io/scheduling-gate"))' | oc apply -f - ---- \ No newline at end of file diff --git a/modules/multi-arch-deleting-podplacment-config-using-web-console.adoc b/modules/multi-arch-deleting-podplacment-config-using-web-console.adoc index 1ce6b6eff5..b2a69615e4 100644 --- a/modules/multi-arch-deleting-podplacment-config-using-web-console.adoc +++ b/modules/multi-arch-deleting-podplacment-config-using-web-console.adoc @@ -34,12 +34,3 @@ You can delete this object by using the {product-title} web console. .Verification * On the *Cluster Pod Placement Config* page, check that the `ClusterPodPlacementConfig` object has been deleted. - -.Next steps - -* After deleting the `ClusterPodPlacementConfig` object, ensure that none of the pods are in the `Pending` phase due to the `SchedulingGated` reason. You can delete the scheduling gate from all the gated pods by running the following command in the {oc-first}: -+ -[source,terminal] ----- -$ oc get pods -A -l multiarch.openshift.io/scheduling-gate=gated -o json | jq 'del(.items[].spec.schedulingGates[] | select(.name=="multiarch.openshift.io/scheduling-gate"))' | oc apply -f - ----- diff --git a/post_installation_configuration/configuring-multi-arch-compute-machines/multiarch-tuning-operator.adoc b/post_installation_configuration/configuring-multi-arch-compute-machines/multiarch-tuning-operator.adoc index 51ed78c677..60b97a6e51 100644 --- a/post_installation_configuration/configuring-multi-arch-compute-machines/multiarch-tuning-operator.adoc +++ b/post_installation_configuration/configuring-multi-arch-compute-machines/multiarch-tuning-operator.adoc @@ -6,30 +6,30 @@ include::_attributes/common-attributes.adoc[] toc::[] -[IMPORTANT] -==== -The Multiarch Tuning Operator is a Technology Preview feature only. Technology Preview features are not supported with Red{nbsp}Hat production service level agreements (SLAs) and might not be functionally complete. Red{nbsp}Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. -For more information about the support scope of Red{nbsp}Hat Technology Preview features, see link:https://access.redhat.com/support/offerings/techpreview/[Technology Preview Features Support Scope]. -==== +The Multiarch Tuning Operator optimizes workload management within multi-architecture clusters and in single-architecture clusters transitioning to multi-architecture environments. -The Multiarch Tuning Operator enhances the operational experience within multi-architecture clusters, and single-architecture clusters that are migrating to a multi-architecture compute configuration. +Architecture-aware workload scheduling allows the scheduler to place pods onto nodes that match the architecture of the pod images. -This Operator implements the `clusterpodplacementconfigs` custom resource (CR) to support architecture-aware workload scheduling. +By default, the scheduler does not consider the architecture of a pod's container images when determining the placement of new pods onto nodes. -To enable architecture-aware workload scheduling, you must create the `ClusterPodPlacementConfig` object. When you create the `ClusterPodPlacementConfig` object, this Operator deploys an operand. +To enable architecture-aware workload scheduling, you must create the `ClusterPodPlacementConfig` object. When you create the `ClusterPodPlacementConfig` object, the Multiarch Tuning Operator deploys the necessary operands to support architecture-aware workload scheduling. -When a pod is created, the operand performs the following actions: +When a pod is created, the operands perform the following actions: . Add the `multiarch.openshift.io/scheduling-gate` scheduling gate that prevents the scheduling of the pod. . Compute a scheduling predicate that includes the supported architecture values for the `kubernetes.io/arch` label. . Integrate the scheduling predicate as a `nodeAffinity` requirement in the pod specification. . Remove the scheduling gate from the pod. - -When the operand removes the scheduling gate, the pod enters the scheduling cycle. The workload is then scheduled on nodes based on the supported architectures. - + [IMPORTANT] ==== -The Technology Preview version of the Multiarch Tuning Operator does not support clusters with restricted network scenarios. +Note the following operand behaviors: + +* If the `nodeSelector` field is already configured with the `kubernetes.io/arch` label for a workload, the operand does not update the `nodeAffinity` field for that workload. + +* If the `nodeSelector` field is not configured with the `kubernetes.io/arch` label for a workload, the operand updates the `nodeAffinity` field for that workload. However, in that `nodeAffinity` field, the operand updates only the node selector terms that are not configured with the `kubernetes.io/arch` label. + +* If the `nodeName` field is already set, the Multiarch Tuning Operator does not process the pod. ==== //Installing Multiarch Tuning Operator