A city Wi-Fi captive portal image contains only amd64 binaries, but several worker nodes are arm64. What should the team do?
Select an answer to reveal the explanation.
Short Explanation
Handing an amd64 binary to an arm64 node is like shipping a vinyl record player a cassette—wrong format. Build multi-arch manifests or arch-specific tags so each node pulls an image it can actually run.
Full Explanation
City Wi-Fi captive portal images built only for amd64 fail on arm64 workers with exec format errors. Publish a multi-architecture manifest (or arch-specific tags the Deployment selects) so each node pulls a binary matching its CPU architecture. Build pipelines should produce linux/amd64 and linux/arm64 variants and push an index list; municipal clusters increasingly mix architectures for cost efficiency and edge site coverage across the city’s network.
Scheduling amd64-only images onto arm64 and hoping qemu is present is fragile and slow even when emulation exists; CKAD expects proper images, not hidden emulation. Deleting arm64 nodes avoids the symptom by shrinking the platform rather than fixing the artifact. Setting imagePullPolicy to Never does not skip architecture checks during verification; it only prevents registry pulls and still cannot execute the wrong instruction set.
Exam caveat: node architecture must match image architecture. You may add nodeAffinity as a scheduling aid, but the primary fix is publishing correct multi-arch application images for the captive portal.
Operational check: kubectl get nodes -o wide (or kubernetes.io/arch labels), inspect the image index with crane manifest, deploy a test Pod on each architecture pool, and confirm Running without CrashLoopBackOff from exec format errors.