---
title: How to deploy both x86 and ARM images in Kubernetes
description: This page explains how to deploy both x86 and ARM images in Kubernetes
tags: kubernetes kapsule arm x86
dates:
  validation: 2025-09-17
  posted: 2024-02-29
---

In a multi-architecture computing environment, where both x86 and ARM architectures are used, deploying applications in a Kubernetes cluster can present challenges.
However, Kubernetes provides several mechanisms to manage architectural diversity effectively. Two of the most common approaches are using multi-arch images and architecture-specific deployments.

## What is ARM architecture, and why is it different from x86?

 - ARM architecture is commonly used in devices like Raspberry Pi, IoT devices, and recent [ARM-based Instances](https://www.scaleway.com/en/cost-optimized-instances-based-on-arm/).
 - Kubernetes clusters may consist of nodes with different architectures, including x86 and ARM.
 - Deploying applications across these diverse architectures requires special consideration.

For a detailed comparison between ARM and x86 architectures, refer to our dedicated documentation [Understanding the differences between ARM and x86 Instances](/instances/reference-content/understanding-differences-x86-arm/).

## Using multi-arch images

The most common approach to using ARM and x86 architecture Instances in a Kubernetes cluster is multi-arch images.
These images contain binaries for multiple architectures, allowing Kubernetes to pull the appropriate binaries for each node.

### How to deploy multi-arch images

1. Build multi-arch images. Docker supports multi-arch builds using `buildx`.
2. Push the built images to a container registry accessible by your Kubernetes cluster. For example, you can use the [Scaleway Container Registry](/container-registry/quickstart/).
3. Specify node selectors and affinity. Use either [node selectors](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) and [affinity rules](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) to ensure Pods are scheduled on nodes with compatible architectures.
    <Message type="tip">
      Alternatively, use taints to mark nodes with specific architectures and tolerations to allow Pods to run on those nodes. Refer to the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) for more information regarding taints and tolerations.
    </Message>
#### Example

Below, you can find an example of a Pod configuration with affinity set to target the `kubernetes.io/arch=arm64` label, which is present by default on Scaleway ARM nodes:

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: example-pod-with-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/arch
            operator: In
            values:
            - arm64
  containers:
  - name: my-container
    image: my-image:latest
    # Add more container configurations as needed
```

In this example, the Pod's affinity is configured to be scheduled on nodes that have the label `kubernetes.io/arch` with the value `arm64`.
This ensures that the Pod will only be scheduled on nodes with this architecture.

<Message type="note">
  Using multi-arch images you benefit from a
    - simplified deployment process.
    - scalable solution for managing multi-architecture clusters.
</Message>

## Using architecture-specific deployments

You can also use architecture-specific deployments as an alternative, if multi-arch images are not available.

## How to deploy architecture-specific images

1. Start by determining the architecture of each node in the Kubernetes cluster.
2. Build architecture-specific images by creating separate images for each architecture (x86 and ARM).
3. Assign [labels](https://kubernetes.io/docs/reference/labels-annotations-taints/#kubernetes-io-arch) to images with the corresponding architecture name.
4. Deploy with architecture-specific manifests for each architecture.

<Message type="note">
  Keep in mind that,
  - there is an increased management overhead due to maintaining separate images and manifests.
  - this approach is mostly suitable for scenarios where multi-arch images are not suitable.
</Message>