Handle single-platform container images

With node auto-provisioning and Fleets, Cloudfleet always picks the cheapest available node to run your container. Many cloud providers offer ARM architecture nodes, which often cost less than amd64 nodes. However, before scheduling a node, Cloudfleet does not know if your container image supports only one architecture. If your image is only available for amd64 and Cloudfleet provisions an ARM node, your container does not run on that node. The result is a crash loop.

Solution

To prevent the crash loop, set the kubernetes.io/arch label to amd64 in your Pod specification. The label tells Cloudfleet in advance which architecture your container image supports. Use either the nodeSelector property or a node affinity rule:

Option 1: Using nodeSelector

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
    - name: my-app
      image: myregistry/my-app:latest
  nodeSelector:
    kubernetes.io/arch: amd64

Option 2: Using node affinity

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
    - name: my-app
      image: myregistry/my-app:latest
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: kubernetes.io/arch
                operator: In
                values:
                  - amd64

With both approaches, Kubernetes schedules your container only on amd64 nodes, which prevents crash loops from architecture mismatches.

Recommended approach: Multi-platform images

Consider building multi-platform container images. A multi-platform image supports both ARM and amd64 architectures. Cloudfleet can then schedule your containers on the cheapest compatible node, regardless of architecture.

Languages such as Go, Node.js, Python, Java, and Rust are well suited for multi-platform builds, because they have strong cross-architecture support.