diff --git a/modules/multi-architecture-enabling-64k-pages.adoc b/modules/multi-architecture-enabling-64k-pages.adoc index 81e295e723d6..f6fec504bc1d 100644 --- a/modules/multi-architecture-enabling-64k-pages.adoc +++ b/modules/multi-architecture-enabling-64k-pages.adoc @@ -4,9 +4,9 @@ :_mod-docs-content-type: PROCEDURE [id="multi-architecture-enabling-64k-pages_{context}"] - = Enabling 64k pages on the {op-system-first} kernel +[role="_abstract"] You can enable the 64k memory page in the {op-system-first} kernel on the 64-bit ARM compute machines in your cluster. The 64k page size kernel specification can be used for large GPU or high memory workloads. This is done using the Machine Config Operator (MCO) which uses a machine config pool to update the kernel. To enable 64k page sizes, you must dedicate a machine config pool for ARM64 to enable on the kernel. [IMPORTANT] @@ -15,12 +15,14 @@ Using 64k pages is exclusive to 64-bit ARM architecture compute nodes or cluster ==== .Prerequisites -* You installed the OpenShift CLI (`oc`). + +* You installed the {oc-first}. * You created a cluster with compute nodes of different architecture on one of the supported platforms. .Procedure . Label the nodes where you want to run the 64k page size kernel: ++ [source,terminal] + ---- @@ -69,13 +71,16 @@ apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: - machineconfiguration.openshift.io/role: "worker-64k-pages" <1> + machineconfiguration.openshift.io/role: "worker-64k-pages" name: 99-worker-64kpages spec: - kernelType: 64k-pages <2> + kernelType: 64k-pages ---- -<1> Specify the value of the `machineconfiguration.openshift.io/role` label in the custom machine config pool. The example MachineConfig uses the `worker-64k-pages` label to enable 64k pages in the `worker-64k-pages` pool. -<2> Specify your desired kernel type. Valid values are `64k-pages` and `default` ++ +where: ++ +`metadata.labels.machineconfiguration.openshift.io/role`:: Specifies the value of the `machineconfiguration.openshift.io/role` label in the custom machine config pool. The example MachineConfig uses the `worker-64k-pages` label to enable 64k pages in the `worker-64k-pages` pool. +`spec.kernalType`:: Specifies your desired kernel type. Valid values are `64k-pages` and `default` + [NOTE] ==== diff --git a/modules/multi-architecture-import-imagestreams.adoc b/modules/multi-architecture-import-imagestreams.adoc index 4a64a466c0c7..c3f2cf5f4c81 100644 --- a/modules/multi-architecture-import-imagestreams.adoc +++ b/modules/multi-architecture-import-imagestreams.adoc @@ -4,18 +4,18 @@ :_mod-docs-content-type: PROCEDURE [id="multi-architecture-import-imagestreams_{context}"] - = Importing manifest lists in image streams on your multi-architecture compute machines +[role="_abstract"] On an {product-title} {product-version} cluster with multi-architecture compute machines, the image streams in the cluster do not import manifest lists automatically. You must manually change the default `importMode` option to the `PreserveOriginal` option in order to import the manifest list. .Prerequisites -* You installed the {product-title} CLI (`oc`). +* You installed the {oc-first}. .Procedure -* The following example command shows how to patch the `ImageStream` cli-artifacts so that the `cli-artifacts:latest` image stream tag is imported as a manifest list. +* Enter a command similar to the following example command to patch the `ImageStream` cli-artifacts so that the `cli-artifacts:latest` image stream tag is imported as a manifest list: + [source,terminal] ---- @@ -30,10 +30,8 @@ $ oc patch is/cli-artifacts -n openshift -p '{"spec":{"tags":[{"name":"latest"," ---- $ oc get istag cli-artifacts:latest -n openshift -oyaml ---- - + -If the `dockerImageManifests` object is present, then the manifest list import was successful. - +If the `dockerImageManifests` object is present, the manifest list imported successfully. + .Example output of the `dockerImageManifests` object [source, yaml] diff --git a/modules/multi-architecture-scheduling-examples.adoc b/modules/multi-architecture-scheduling-examples.adoc index d786a0efd813..d86a2bdc906b 100644 --- a/modules/multi-architecture-scheduling-examples.adoc +++ b/modules/multi-architecture-scheduling-examples.adoc @@ -2,10 +2,11 @@ // //post_installation_configuration/configuring-multi-arch-compute-machines/multi-architecture-compute-managing.adoc -:_mod-docs-content-type: CONCEPT +:_mod-docs-content-type: REFERENCE [id="multi-architecture-scheduling-examples_{context}"] = Sample multi-architecture node workload deployments +[role="_abstract"] Scheduling a workload to an appropriate node based on architecture works in the same way as scheduling based on any other node characteristic. ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] Consider the following options when determining how to schedule your workloads. diff --git a/modules/multi-architecture-scheduling.adoc b/modules/multi-architecture-scheduling.adoc index 4ee6bcd915b5..b616fe11bc8f 100644 --- a/modules/multi-architecture-scheduling.adoc +++ b/modules/multi-architecture-scheduling.adoc @@ -1,11 +1,16 @@ +// Module included in the following assemblies: +// +// * post_installation_configuration/configuring-multi-arch-compute-machines/multi-architecture-compute-managing.adoc + :_mod-docs-content-type: CONCEPT [id="multi-architecture-scheduling_{context}"] = Scheduling workloads on clusters with multi-architecture compute machines -When you deploy workloads on a cluster with compute nodes that use different architectures, you must align pod architecture with the architecture of the underlying node. Your workload may also require additional configuration to particular resources depending on the underlying node architecture. +[role="_abstract"] +When you deploy workloads on a cluster with compute nodes that use different architectures, you must align pod architecture with the architecture of the underlying node. Your workload might also require additional configuration to particular resources depending on the underlying node architecture. You can use the Multiarch Tuning Operator to enable architecture-aware scheduling of workloads on clusters with multi-architecture compute machines. The Multiarch Tuning Operator implements additional scheduler predicates in the pods specifications based on the architectures that the pods can support at creation time. ifndef::openshift-enterprise[] -For information about the Multiarch Tuning Operator, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/postinstallation_configuration/configuring-multi-architecture-compute-machines-on-an-openshift-cluster#multiarch-tuning-operator[Managing workloads on multi-architecture clusters by using the Multiarch Tuning Operator]. +For information about the Multiarch Tuning Operator, see "Managing workloads on multi-architecture clusters by using the Multiarch Tuning Operator". endif::openshift-enterprise[] \ No newline at end of file diff --git a/post_installation_configuration/configuring-multi-arch-compute-machines/multi-architecture-compute-managing.adoc b/post_installation_configuration/configuring-multi-arch-compute-machines/multi-architecture-compute-managing.adoc index edf20985e70e..7df8f8cd9db9 100644 --- a/post_installation_configuration/configuring-multi-arch-compute-machines/multi-architecture-compute-managing.adoc +++ b/post_installation_configuration/configuring-multi-arch-compute-machines/multi-architecture-compute-managing.adoc @@ -6,17 +6,25 @@ include::_attributes/common-attributes.adoc[] toc::[] +[role="_abstract"] Managing a cluster that has nodes with multiple architectures requires you to consider node architecture as you monitor the cluster and manage your workloads. This requires you to take additional considerations into account when you ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -configure cluster resource requirements and behavior, or +configure cluster resource requirements and behaviors, or endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] schedule workloads in a multi-architecture cluster. include::modules/multi-architecture-scheduling.adoc[leveloffset=+1] +[role="_additional-resources"] +.Additional resources + +* link:https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/postinstallation_configuration/configuring-multi-architecture-compute-machines-on-an-openshift-cluster#multiarch-tuning-operator[Managing workloads on multi-architecture clusters by using the Multiarch Tuning Operator] + include::modules/multi-architecture-scheduling-examples.adoc[leveloffset=+2] +[role="_additional-resources"] .Additional resources + * xref:../../post_installation_configuration/configuring-multi-arch-compute-machines/multiarch-tuning-operator.adoc#multiarch-tuning-operator[Managing workloads on multi-architecture clusters by using the Multiarch Tuning Operator] * xref:../../nodes/scheduling/nodes-scheduler-taints-tolerations.adoc#nodes-scheduler-taints-tolerations[Controlling pod placement using node taints] * xref:../../nodes/scheduling/nodes-scheduler-node-affinity.adoc#nodes-scheduler-node-affinity[Controlling pod placement on nodes using node affinity] diff --git a/snippets/multi-arch-schedule-affinity-taint-toleration.adoc b/snippets/multi-arch-schedule-affinity-taint-toleration.adoc index b6f4b7ccbd5d..f5856615fe73 100644 --- a/snippets/multi-arch-schedule-affinity-taint-toleration.adoc +++ b/snippets/multi-arch-schedule-affinity-taint-toleration.adoc @@ -3,7 +3,6 @@ Using node affinity with taints and tolerations:: When a scheduler computes the set of nodes to schedule a pod, tolerations can broaden the set while node affinity restricts the set. If you set a taint on nodes that have a specific architecture, you must also add a toleration to workloads that you want to be scheduled there. + .Example deployment with node affinity and toleration set --- [source,yaml] ---- apiVersion: apps/v1 @@ -30,4 +29,3 @@ spec: operator: "Equal" effect: "NoSchedule" ---- --- diff --git a/snippets/multi-arch-schedule-default-toleration-namespace.adoc b/snippets/multi-arch-schedule-default-toleration-namespace.adoc index be4d2bee293a..f0dff378e6fd 100644 --- a/snippets/multi-arch-schedule-default-toleration-namespace.adoc +++ b/snippets/multi-arch-schedule-default-toleration-namespace.adoc @@ -3,10 +3,9 @@ Creating a default toleration in a namespace:: When a node or machine set has a taint, only workloads that tolerate that taint can be scheduled. You can annotate a namespace so all of the workloads get the same default toleration by running the following command: + .Example default toleration set on a namespace --- [source,terminal] ---- $ oc annotate namespace my-namespace \ 'scheduler.alpha.kubernetes.io/defaultTolerations'='[{"operator": "Exists", "effect": "NoSchedule", "key": "multiarch.openshift.io/arch"}]' ---- --- + diff --git a/snippets/multi-arch-schedule-nodeaffinity.adoc b/snippets/multi-arch-schedule-nodeaffinity.adoc index 591398f38f23..8af2013cc5cf 100644 --- a/snippets/multi-arch-schedule-nodeaffinity.adoc +++ b/snippets/multi-arch-schedule-nodeaffinity.adoc @@ -3,7 +3,6 @@ Using `nodeAffinity` to schedule nodes with specific architectures:: You can allow a workload to be scheduled on only a set of nodes with architectures supported by its images, you can set the `spec.affinity.nodeAffinity` field in your pod's template specification. + .Example deployment with node affinity set --- [source,yaml] ---- apiVersion: apps/v1 @@ -21,10 +20,11 @@ spec: - matchExpressions: - key: kubernetes.io/arch operator: In - values: <1> + values: - amd64 - arm64 +# ... ---- -<1> Specify the supported architectures. Valid values include `amd64`,`arm64`, or both values. -[source,yaml] --- ++ +** The `values` parameter specifies the supported architectures. Valid values include `amd64`,`arm64`, or both values. + diff --git a/snippets/multi-arch-schedule-taint.adoc b/snippets/multi-arch-schedule-taint.adoc index d3dea3ceb167..92072356e8e9 100644 --- a/snippets/multi-arch-schedule-taint.adoc +++ b/snippets/multi-arch-schedule-taint.adoc @@ -5,7 +5,6 @@ Tainting each node for a specific architecture:: You can taint a node to avoid t Before you add a taint to a node, you must scale down the `MachineSet` object or remove existing available machines. For more information, see _Modifying a compute machine set_. + .Example machine set with taint set --- [source,yaml] ---- apiVersion: machine.openshift.io/v1beta1 @@ -22,7 +21,6 @@ spec: key: multiarch.openshift.io/arch value: arm64 ---- --- + You can also set a taint on a specific node by running the following command: + diff --git a/snippets/multi-arch-schedule-toleration.adoc b/snippets/multi-arch-schedule-toleration.adoc index 558ec5eea5ac..db346af88eb1 100644 --- a/snippets/multi-arch-schedule-toleration.adoc +++ b/snippets/multi-arch-schedule-toleration.adoc @@ -3,7 +3,6 @@ Tolerating architecture taints in workloads:: When a node or machine set has a taint, only workloads that tolerate that taint can be scheduled. You can configure your workload with a `toleration` so that it is scheduled on nodes with specific architecture taints. + .Example deployment with toleration set --- [source,yaml] ---- apiVersion: apps/v1 @@ -20,5 +19,5 @@ spec: operator: "Equal" effect: "NoSchedule" ---- ++ This example deployment can be scheduled on nodes and machine sets that have the `multiarch.openshift.io/arch=arm64` taint specified. ---