Skip to main content
In Fusion 5.19, you can run several services on ARM64 nodes to lower infrastructure costs, while the rest of Fusion runs on x86-64 (amd64) nodes in the same cluster.
ARM64 support is a preview and isn’t supported for production workloads in Fusion 5.19.

​
Supported services

These services can run on ARM64 nodes:
  • api-gateway
  • fusion-indexing
  • job-config
  • templating
  • The connectors services: connector-plugin-service, rest-service, and rpc-service
Keep all other Fusion services on amd64 nodes, along with the third-party services that Fusion deploys, such as Kafka, ZooKeeper, and Argo Workflows. Their images, or the setup containers they run before starting, are amd64 only. GPU-based machine learning jobs also require amd64 nodes, because cloud providers don’t offer GPUs on ARM64 instances. The supported services publish ARM64 variants under the same image tags as their amd64 images. Kubernetes pulls the variant that matches each node, so you don’t need to change image references.
Some setup containers use an amd64-only image and fail with an exec format error on ARM64 nodes. Keep a service on amd64 nodes in these cases:
  • TLS or trusted certificate import is enabled for the service.
  • api-gateway during a new installation, because its generate-jks setup job runs on the same nodes as the service.

​
Schedule services on ARM64 nodes

1

Create an ARM64 node pool

Add a node pool that uses an ARM64 machine type, such as Google Axion (C4A) on GKE or AWS Graviton on EKS. Keep your existing amd64 node pools.
2

Taint the ARM64 nodes

Taint the ARM64 nodes so that only services you opt in can run on them:
GKE adds this taint to ARM64 nodes automatically, so skip this step on GKE.
3

Opt services in to ARM64

In your custom values YAML file, add a nodeSelector and a matching toleration for each supported service:
If you use workload isolation, keep your existing fusion_node_type label in the nodeSelector and add kubernetes.io/arch next to it.
4

Upgrade the release

Apply the values with helm upgrade, then confirm where the pods landed:
Because the ARM64 nodes are tainted, services without the toleration stay on amd64 nodes. Without the taint, Kubernetes can schedule an amd64-only service on an ARM64 node, where its pod fails with an exec format error.