[K8s] Hardcoded --platform=linux/amd64 breaks arm64 clusters (Apple Silicon, Graviton)

[mskuratowski]

Problem

KubernetesBackend.build_runtime (lithops/serverless/backends/k8s/k8s.py:138,140) hardcodes docker build --platform=linux/amd64. Pulling that image on an arm64 cluster - local dev on Apple Silicon (kind / minikube / Rancher Desktop) or AWS Graviton nodes in production — fails with:

rpc error: code = NotFound desc = failed to pull and unpack image "<user>/lithops-k8s:01":
no match for platform in manifest: not found                                                                                                                                 
ErrImagePull                                                                                                                                                                 

Reproduced on macOS arm64 with kind v0.30+, Lithops 3.6.5.dev0.

Proposed fix

Add an opt-in runtime_arch key to the k8s config section. Default amd64 so existing setups don't change behavior. Validated against an allow-list {amd64, arm64} so typos fail fast instead of producing a broken image.

k8s:
    runtime_arch: arm64   # default: amd64

build_runtime reads it and substitutes into --platform=linux/<arch>. Backwards compatible, explicit, no extra cluster round-trips, no silent guessing on mixed clusters.

Bigger picture

The same hardcoded --platform=linux/amd64 exists in 10 other backends, all with the same two-liner pattern:

Backend	File	Arch policy
aws_batch	aws_batch.py:391,393	both, user-chosen
aws_lambda	aws_lambda.py:340,342	both (Lambda Graviton), user-chosen
azure_containers	azure_containers.py:118,120	amd64 only
code_engine	code_engine.py:249,251	amd64 only
gcp_cloudrun	cloudrun.py:220,222	amd64 only (today)
ibm_cf	ibm_cf.py:177,179	amd64 only
knative	knative.py:563,565	depends on cluster
openwhisk	openwhisk.py:119,121	amd64 only
oracle_f	oracle_f.py:203,205	amd64 only

This is the same two-liner copy-pasted into ten other backends, so it'd probably be cleaner to pull the docker build into a small helper in lithops/utils.py and add runtime_arch to each backend that supports multiple architectures. I'd be up for doing that in a follow-up PR if you'd find it useful - but I'd rather get the k8s case settled first before pulling in nine other backends.

[JosepSampe]

Thanks for the detailed write-up and for clearly outlining both the problem and the broader impact.

If you’d like to contribute, I’d be glad if you can proceed for now with the Kubernetes backend adoption. We can handle the rest separately in a follow-up.

And many thanks for digging into this!

[mskuratowski]

PR up: #1465.

Implemented auto-detect from cluster nodes with a runtime_arch config override and amd64 fallback for mixed/unknown clusters. The refactor across the other 10 backends stays as a separate follow-up.

Tested on kind (arm64) and Rancher Desktop (arm64) end-to-end; override and config validation also covered.