You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/learning-paths/servers-and-cloud-computing/arm-cost-savings/migrationsteps.md
+47-42Lines changed: 47 additions & 42 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,64 +1,72 @@
1
1
---
2
-
title: Migrate an x86 workload to Arm on AWS
2
+
title: Migrate an x86 workload to Arm on AWS
3
3
weight: 2
4
4
5
5
### FIXED, DO NOT MODIFY
6
6
layout: learningpathall
7
7
---
8
8
9
-
Migrating workloads from x86 to Arm on AWS can help reduce costsand improve performance. The steps below explain how to assess your workload compatibility, enable multi-architecture support in Red Hat OpenShift, configure arm64 nodes, rebuild and verify container images, and safely transition your deployments.
9
+
Migrating container workloads from x86 to Arm on AWS can help reduce cloud costs, improve energy efficiency, and enhance performance. This Learning Path shows you how to assess workload compatibility, enable multi-architecture support in Red Hat OpenShift, configure Arm64 nodes, rebuild and verify container images, and transition your deployments safely.
10
10
11
-
This example assumes you have the [OpenShift Pipelines Tutorial](https://github.com/openshift/pipelines-tutorial)built and running on x86.
11
+
This example uses the [OpenShift Pipelines Tutorial](https://github.com/openshift/pipelines-tutorial)as the baseline and assumes it is running on x86 infrastructure.
12
12
13
-
### 1. Assess Workload Compatibility
13
+
##Assess workload compatibility
14
14
15
-
Before migrating, determine whether your applications can run on 64-bit Arm architecture. Most modern applications built with portable runtimes such as Java, Go, Python, or Node.js can run seamlessly on 64-bit Arm with little or no modifications. Check your container images and dependencies for 64-bit Arm compatibility.
15
+
Before migrating, confirm that your applications can run on the Arm 64-bit (`arm64`) architecture. Most modern applications built with portable runtimes such as Java, Go, Python, or Node.js run on Arm with little or no changes. Check your container images and dependencies for compatibility.
16
16
17
-
To check if your container images support multiple architectures (such as arm64 and amd64), you can use tools like [KubeArchInspect](https://learn.arm.com/learning-paths/servers-and-cloud-computing/kubearchinspect/)to analyze images in your Kubernetes cluster.
17
+
Use the following tools to inspect container images for multi-architecture support:
18
18
19
-
Additionally, you can use the Python script provided in [Learn how to use Docker](https://learn.arm.com/learning-paths/cross-platform/docker/check-images/) to inspect images for multi-architecture support.
19
+
-[KubeArchInspect](https://learn.arm.com/learning-paths/servers-and-cloud-computing/kubearchinspect/): scans container images in your Kubernetes cluster.
20
+
-[Docker inspect script](https://learn.arm.com/learning-paths/cross-platform/docker/check-images/): checks local image manifests for platform variants.
20
21
21
-
The OpenShift Pipelines Tutorial supports arm64 and doesn't have any architecture restrictions.
22
+
{{% notice Note %}}
23
+
The OpenShift Pipelines Tutorial supports `arm64` and has no architecture restrictions.
24
+
{{% /notice %}}
22
25
23
-
### 2. Enable Multi-Arch Support in Red Hat OpenShift
24
26
25
-
Red Hat OpenShift supports multi-architecture workloads, allowing you to run both x86 and Arm based nodes in the same cluster.
27
+
## Enable multi-architecture support in Red Hat OpenShift
26
28
27
-
Red Hat OpenShift's [documentation](https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/postinstallation_configuration/configuring-multi-architecture-compute-machines-on-an-openshift-cluster#multi-architecture-verifying-cluster-compatibility_creating-multi-arch-compute-nodes-aws) provides full details for the process.
29
+
OpenShift supports multi-architecture workloads, allowing you to run x86 and Arm nodes in the same cluster.
28
30
29
-
To check if your cluster is multi-architecture compatible, use the OpenShift CLI and run:
31
+
To check if your cluster is multi-architecture compatible, run:
30
32
31
33
```bash
32
34
oc adm release info -o jsonpath="{ .metadata.metadata }"
33
35
```
34
36
35
-
If the output includes `"release.openshift.io/architecture": "multi"`, your cluster supports multi-architecture compute nodes.
37
+
If the output includes:
38
+
39
+
```json
40
+
"release.openshift.io/architecture": "multi"
41
+
```
42
+
43
+
...then your cluster supports multi-architecture nodes.
36
44
37
45
If your cluster is not multi-architecture compatible, you must migrate it to use the multi-architecture release payload. This involves updating your OpenShift cluster to a version that supports multi-architecture and switching to the multi-architecture payload. For step-by-step instructions, see the OpenShift documentation on [migrating to a cluster with multi-architecture compute machines](https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html-single/updating_clusters/#migrating-to-multi-payload). Once migration is complete, you can add compute nodes with different architectures.
38
46
39
-
### 3. Add 64-bit Arm MachineSets
47
+
## Add 64-bit Arm MachineSets
40
48
41
49
To take advantage of Arm-based compute, you need to add new MachineSets to your OpenShift cluster that use Arm (Graviton) EC2 instances. This step enables your cluster to schedule workloads on Arm nodes, allowing you to run and test your applications on the target architecture while maintaining your existing x86 nodes for a smooth migration.
42
50
43
-
####Decide on a scheduling strategy
51
+
## Decide on a scheduling strategy
44
52
45
53
When introducing Arm nodes into your OpenShift cluster, you need to control which workloads are scheduled onto these new nodes. There are two main approaches:
46
54
47
-
-**Manual scheduling with Taints and Tolerations:**By applying a taint to your Arm nodes, you ensure that only workloads with a matching toleration are scheduled there. This gives you precise control over which applications run on Arm, making it easier to test and migrate workloads incrementally.
48
-
-**Automated scheduling with the Multiarch Tuning Operator:**This operator helps automate the placement of workloads on the appropriate architecture by managing node affinity and tolerations for you. This is useful for larger environments or when you want to simplify multi-architecture workload management.
55
+
-**Manual scheduling with Taints and Tolerations:**by applying a taint to your Arm nodes, you ensure that only workloads with a matching toleration are scheduled there. This gives you precise control over which applications run on Arm, making it easier to test and migrate workloads incrementally.
56
+
-**Automated scheduling with the Multiarch Tuning Operator:**this operator helps automate the placement of workloads on the appropriate architecture by managing node affinity and tolerations for you. This is useful for larger environments or when you want to simplify multi-architecture workload management.
49
57
50
-
For scenarios with a single workload in the build pipeline, the manual taint and toleration method can be used. The following taint can be added to new Arm machine sets:
58
+
For manual scheduling, add the following taint:
51
59
52
-
```
53
-
taints:
54
-
- effect: NoSchedule
55
-
key: newarch
56
-
value: arm64
60
+
```yaml
61
+
taints:
62
+
- effect: NoSchedule
63
+
key: newarch
64
+
value: arm64
57
65
```
58
66
59
67
This prevents existing x86 workloads from being scheduled to the Arm nodes, ensuring only workloads that explicitly tolerate this taint will run on Arm.
60
68
61
-
####Reimport needed ImageStreams with import-mode set to PreserveOriginal
69
+
## Reimport needed ImageStreams with import-mode set to PreserveOriginal
62
70
63
71
When running workloads on Arm nodes, you may need to ensure that the required container images are available for the arm64 architecture. OpenShift uses ImageStreams to manage container images, and by default, these may only include x86 (amd64) images.
This step is important to avoid image pull errors when deploying workloads to Arm nodes.
82
+
{{% notice Note %}}
83
+
This avoids image pull errors when deploying on Arm nodes.
84
+
{{% /notice %}}
85
+
75
86
76
-
### 4. Rebuild and Verify Container Images
87
+
##Rebuild and verify container images
77
88
78
89
To build 64-bit Arm compatible images, the OpenShift Pipelines Tutorial has been modified to patch deployments with the Tekton Task's podTemplate information. This will allow you to pass a podTemplate for building and deploying your newly built application on the target architecture. It also makes it easy to revert back to 64-bit x86 by re-running the pipeline without the template.
79
90
80
91
{{% notice Note %}}
81
-
Red Hat OpenShift only supports native architecture container builds. Cross-architecture container builds are not supported.
92
+
Red Hat OpenShift only supports native builds. Cross-architecture builds are not supported.
82
93
{{% /notice %}}
83
94
95
+
## Define a podTemplate
84
96
Create a podTemplate defining a toleration and a node affinity to make the builds deploy on Arm machines.
85
97
86
-
Save the code below in a file named `arm64.yaml`
98
+
Save the following as `arm64.yaml`:
87
99
88
100
```yaml
89
101
tolerations:
@@ -172,30 +184,23 @@ Finally the `04_pipeline.yaml` needs to be updated to pass the taskrun-name to t
172
184
173
185
```yaml
174
186
- name: update-deployment
175
-
taskRef:
187
+
taskRef:
176
188
name: update-deployment
177
-
params:
189
+
params:
178
190
- name: deployment
179
-
value: $(params.deployment-name)
191
+
value: $(params.deployment-name)
180
192
- name: IMAGE
181
-
value: $(params.IMAGE)
182
-
- name: taskrun-name //add these
183
-
value: $(context.taskRun.name) //lines
193
+
value: $(params.IMAGE)
194
+
- name: taskrun-name
195
+
value: $(context.taskRun.name)
184
196
```
185
197
186
198
Now the UI and API can be redeployed using the `arm64.yaml` podTemplate. This will force all parts of the build pipeline and deployment to the tainted Arm nodes.
Once the pods are up and running, you can safely remove the x86 worker nodes from the cluster, and remove the taints from the Arm worker nodes (if you choose to do so).
0 commit comments