Handle single-platform container images
When using node auto-provisioning with Fleets, Cloudfleet always picks the cheapest available node to run your container. Many cloud providers offer ARM architecture nodes, which are often more cost-effective than amd64 nodes. However, before scheduling a node, Cloudfleet does not know if your container image only supports a single architecture. If your container image is only available for the amd64 architecture but Cloudfleet decides to provision a ARM node, your container will not run on ARM nodes, resulting in a crash loop.
Solution
To avoid this, use the kubernetes.io/arch
label by setting it to amd64
in your pod specification to preemptively signal Cloudfleet about the architecture that your container image supports. You can do this using either the nodeSelector
property or a node affinity rule. Here’s how:
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
Both approaches ensure your container is scheduled only on nodes with the amd64 architecture, preventing crash loops due to architecture mismatches.
Recommended Approach: Multi-Platform Images
For the best experience, consider building multi-platform container images. This allows you to support both ARM and amd64 architectures using a single image. Cloudfleet can then schedule your containers on the cheapest compatible node, regardless of architecture.
Languages like Go, Node.js, Python, Java, and Rust are especially well-suited for multi-platform builds, as they offer strong cross-architecture support.