NVIDIA Jetson + K3s: Edge AI Cluster Tutorial (2026)

Answer-First Lede

An NVIDIA Jetson k3s edge AI cluster is the canonical 2026 recipe for running production GPU inference outside the data center. You take a lightweight x86 control plane, attach Jetson Orin Nano, Orin NX, or AGX Orin nodes as K3s workers, install the nvidia-container-runtime so containerd can expose the GPU through CDI, then tag each Jetson with taints and node labels so only AI pods land there. The result is a single Kubernetes API that fleet-manages mixed CPU and GPU edge hardware, ships Triton or Isaac ROS containers, and rolls JetPack upgrades the same way you roll any other DaemonSet. This tutorial walks the full join, scheduling, observability, and lifecycle path with working commands. Hedge: JetPack and L4T pin to specific Jetson modules — always cross-check with NVIDIA’s official compatibility matrix before flashing in production.

What this post covers: topology, prerequisites, the join procedure, GPU runtime wiring, scheduling rules, a sample AI workload, monitoring, OTA upgrades, gotchas, and an FAQ.

Why Jetson + K3s is the canonical 2026 edge-AI recipe

K3s plus Jetson has become the default edge AI cluster pattern because nothing else hits the same triangle of small footprint, full Kubernetes API, and first-class NVIDIA GPU support. K3s strips the control plane to a single binary under 100 MB and runs comfortably on a Raspberry Pi 5 or a low-end NUC. Jetson Orin modules deliver between 40 and 275 sparse INT8 TOPS in a 7 to 60 watt envelope, so a small fleet can host vision pipelines, speech models, and lightweight LLMs without a dedicated GPU server.

Three forces converged to make this the 2026 standard. First, NVIDIA stabilized the nvidia-container-runtime for JetPack 6.x and adopted the Container Device Interface spec, which lets containerd inject GPU devices without legacy device plugin shims. Second, K3s 1.30+ shipped clean ARM64 binaries and validated GPU support via the NVIDIA GPU Operator. Third, the alternatives lost ground — full kubeadm is too heavy, KubeEdge adds an extra control plane to manage, and pure Docker Compose on Jetson cannot survive a multi-site rollout. For a deeper comparison, see our KubeEdge production deep-dive tutorial.

The pattern fits four production workloads especially well: warehouse robotics with ROS 2 Jazzy on Jetson Orin, retail computer vision, smart-city traffic analytics, and quality-control inspection on the factory floor. Each shares one constraint: latency under 50 ms, which rules out round-tripping to a cloud GPU.

Reference cluster topology

The reference cluster has three logical pools: a small x86 control plane, an x86 worker pool for ingress and stateful services, and a Jetson worker pool for GPU inference. Edge inputs feed the Jetson pool directly. The cluster mirrors model artifacts and metrics to a cloud sync layer.

Why split into three pools

The x86 control plane runs the K3s server binary, etcd or embedded SQLite, the scheduler, and the controller manager. Jetson modules can run the control plane too, but you waste their GPU budget on idle Kubernetes overhead. A $200 Intel N100 mini-PC handles 30+ nodes comfortably.

The x86 worker pool hosts the Traefik ingress, an in-cluster Harbor registry, the observability stack, and any non-GPU control workloads such as MQTT brokers or message bus shims. We keep these off the Jetsons so a sudden inference burst cannot evict the ingress controller.

The Jetson worker pool is taint-isolated. Only pods that carry the matching toleration land there, which prevents stray CPU workloads from stealing memory bandwidth from CUDA kernels. We will configure the taint in a later section.

Sizing rule of thumb

1 control-plane node per site, 3 if you need HA via embedded etcd.
1 to 3 x86 workers per site for ingress, registry, observability.
2 to 20 Jetson workers per site, sized to inference throughput.

If you need site-to-site fleet sync, layer GitOps on top using ArgoCD or Flux for industrial fleets.

Prerequisites

Before joining a Jetson as a K3s worker, every device needs four things in place: a supported JetPack version, a configured container runtime, the right OS, and network reachability to the control plane.

JetPack version

Use JetPack 6.x or later on Orin-class modules. JetPack 6 ships L4T 36.x, kernel 5.15+, and CUDA 12.x, which is the minimum for current Triton, TensorRT-LLM, and Isaac ROS releases. Older JetPack 5.x still works for some workloads but is missing CDI support in containerd, which forces you back to the legacy device plugin. We do not recommend JetPack 5 for new deployments in 2026.

Hedge: NVIDIA periodically pulls and re-tags minor JetPack releases, so always confirm the JetPack SDK release notes against the specific Jetson module SKU you ship. Mixing JetPack minors across the same node pool is supported, but plan a flash window for any major bump.

Container runtime

K3s defaults to containerd. JetPack 6 installs nvidia-container-runtime and an Open Container Initiative hook at /usr/bin/nvidia-container-runtime-hook. We configure containerd to use it as the default low-level runtime for GPU pods. Do not install Docker on the Jetson alongside K3s — the two will fight over the cgroup driver and you will spend a Friday afternoon untangling it.

OS and kernel

Stay on the NVIDIA-supplied L4T image. Do not swap to a stock Ubuntu kernel — the Jetson BSP contains out-of-tree drivers for the Ampere GPU, the ISP, and the hardware video encoder. You will lose CUDA on reboot if you replace the kernel. If you need a custom kernel, build from the Jetson Linux source bundle and keep the NVIDIA nvgpu and nvhost modules.

Network

Static IP or DHCP reservation for every node.
Open ports 6443, 8472 (Flannel VXLAN), and 10250 between nodes.
Outbound 443 to your container registry.
If you use Cilium with eBPF observability, confirm kernel 5.10+ and BPF JIT enabled — JetPack 6 ships this by default.

Pre-flight checklist

# On each Jetson, run before joining
sudo nvpmodel -q                  # check power mode
sudo jetson_release -v            # confirm L4T and JetPack
nvidia-smi || sudo nvidia-smi     # confirm GPU detected (JetPack 6+)
sudo systemctl status containerd  # should be inactive — K3s installs its own

Joining a Jetson as a K3s worker

The fastest path is k3sup, which wraps SSH-based K3s installation. We will install the server on the x86 control plane first, then join each Jetson with the cluster token.

Step 1 — Bring up the control plane

# From your workstation, install k3s server on the x86 control node
k3sup install \
  --ip 10.0.0.10 \
  --user ubuntu \
  --ssh-key ~/.ssh/id_ed25519 \
  --k3s-channel stable \
  --k3s-extra-args "--disable=traefik --node-taint CriticalAddonsOnly=true:NoExecute" \
  --local-path ~/.kube/edge-config

We disable the bundled Traefik so we can install a version that matches our gateway API needs. The CriticalAddonsOnly taint on the control plane keeps user workloads off the API server node.

Step 2 — Capture the node token

ssh ubuntu@10.0.0.10 'sudo cat /var/lib/rancher/k3s/server/node-token'
# K10abc...::server:def456...

Stash this token in a secret manager — Vault, AWS Secrets Manager, or sops in your GitOps repo. Do not paste it into Slack.

Step 3 — Join the Jetson as a worker

# From your workstation, join a Jetson Orin NX at 10.0.0.21
k3sup join \
  --ip 10.0.0.21 \
  --server-ip 10.0.0.10 \
  --user ubuntu \
  --ssh-key ~/.ssh/id_ed25519 \
  --k3s-channel stable \
  --k3s-extra-args "--node-label accelerator=jetson --node-label arch=arm64 --node-taint jetson=true:NoSchedule"

The --node-label accelerator=jetson is how downstream nodeSelectors find these workers. The taint blocks accidental scheduling of CPU-only pods.

Step 4 — Verify

kubectl --kubeconfig ~/.kube/edge-config get nodes -o wide
# orin-nx-01   Ready   <none>   2m   v1.30.x+k3s1   10.0.0.21   ...   aarch64

If a Jetson stays NotReady, the most common cause is a missing or misconfigured cgroup_enable=memory in /boot/extlinux/extlinux.conf. Edit, save, and reboot.

For air-gapped sites, replace k3sup with the manual installer — download the K3s ARM64 binary, copy it to the Jetson, run INSTALL_K3S_SKIP_DOWNLOAD=true ./install.sh. The procedure is the same shape; just slower.

Configuring GPU runtime, device plugin, and the GPU Operator on Jetson

The Jetson is now a Kubernetes worker but cannot yet expose its GPU to pods. We need three pieces: containerd configured to use nvidia-container-runtime, a device plugin that advertises nvidia.com/gpu resources, and optionally the GPU Operator for unified management.

Wire containerd to nvidia-container-runtime

K3s renders a containerd config template at /var/lib/rancher/k3s/agent/etc/containerd/config.toml.tmpl. Create this file on each Jetson:

# /var/lib/rancher/k3s/agent/etc/containerd/config.toml.tmpl
version = 2

[plugins."io.containerd.grpc.v1.cri".containerd]
  default_runtime_name = "nvidia"

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia]
  runtime_type = "io.containerd.runc.v2"

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia.options]
  BinaryName = "/usr/bin/nvidia-container-runtime"
  SystemdCgroup = true

Restart the K3s agent so it picks up the new template:

sudo systemctl restart k3s-agent

Install the NVIDIA Device Plugin (JetPack-aware)

For Jetson, we use the device plugin variant that understands integrated GPUs. The mainline k8s-device-plugin Helm chart accepts a Jetson values override:

# nvidia-device-plugin-jetson-values.yaml
nodeSelector:
  accelerator: jetson
tolerations:
  - key: jetson
    operator: Equal
    value: "true"
    effect: NoSchedule
runtimeClassName: nvidia
config:
  name: default
  default: |
    version: v1
    flags:
      migStrategy: none

helm repo add nvdp https://nvidia.github.io/k8s-device-plugin
helm repo update
helm install nvdp nvdp/nvidia-device-plugin \
  --version 0.15.x \
  --namespace nvidia-device-plugin \
  --create-namespace \
  -f nvidia-device-plugin-jetson-values.yaml

Hedge: the exact chart version that supports Jetson Orin shifts release to release — pin the chart in your GitOps repo after a successful test, do not chase --version latest.

Verify GPU resources

kubectl describe node orin-nx-01 | grep nvidia.com/gpu
# nvidia.com/gpu: 1

If you see 0 or no entry, the most common causes are containerd not restarted, the device plugin pod stuck in CrashLoopBackOff, or the toleration missing.

When to add the full GPU Operator

The NVIDIA GPU Operator bundles the driver, container toolkit, device plugin, DCGM exporter, MIG manager, and node feature discovery into one Helm chart. On Jetson, the driver is already baked into JetPack, so we skip the driver component:

helm install gpu-operator nvidia/gpu-operator \
  --namespace gpu-operator --create-namespace \
  --set driver.enabled=false \
  --set toolkit.enabled=false \
  --set nodeSelector.accelerator=jetson

Pros: unified upgrade path, automatic MIG slicing on AGX Orin, integrated DCGM out of the box. Cons: heavier than a hand-rolled device plugin, occasional version mismatches with JetPack on bleeding-edge releases. For most fleets under 50 nodes, the GPU Operator is worth it.

Taints, tolerations, and workload scheduling

Tainting Jetson nodes and adding tolerations to GPU pods is what stops a developer’s nginx deployment from accidentally landing on your most expensive hardware. The scheduling flow is strict.

The three gates

Every pod that wants a Jetson must clear three gates: declare a nvidia.com/gpu resource request, carry a matching toleration for the jetson=true:NoSchedule taint, and match the accelerator=jetson label via nodeSelector or node affinity.

A minimal GPU pod manifest looks like this:

apiVersion: v1
kind: Pod
metadata:
  name: triton-test
spec:
  nodeSelector:
    accelerator: jetson
    arch: arm64
  tolerations:
    - key: jetson
      operator: Equal
      value: "true"
      effect: NoSchedule
  runtimeClassName: nvidia
  containers:
    - name: triton
      image: nvcr.io/nvidia/tritonserver:24.10-py3-igpu
      resources:
        limits:
          nvidia.com/gpu: 1

Note the igpu suffix on the image tag — Jetson uses an integrated GPU image variant, not the discrete-GPU variant used in the data center. Pulling the wrong tag will appear to work but silently fail at first inference.

NodeFeatureDiscovery for fine-grained targeting

When you mix Orin Nano, Orin NX, and AGX Orin in the same pool, you need finer labels than accelerator=jetson. Install Node Feature Discovery (NFD) and pair it with a small custom rule:

# nfd-jetson-rule.yaml
apiVersion: nfd.k8s-sigs.io/v1alpha1
kind: NodeFeatureRule
metadata:
  name: jetson-module-detect
spec:
  rules:
    - name: "jetson-agx-orin"
      labels:
        jetson.nvidia.com/module: "agx-orin"
      matchFeatures:
        - feature: kernel.config
          matchExpressions:
            CONFIG_TEGRA_CPUFREQ: {op: Exists}
        - feature: system.osrelease
          matchExpressions:
            CHASSIS_ASSET_TAG: {op: InRegexp, value: ["AGX.*Orin"]}

Now a Triton-LLM pod that needs 64 GB unified memory can target jetson.nvidia.com/module: agx-orin and avoid landing on an 8 GB Orin Nano.

MIG on AGX Orin

AGX Orin supports MIG-style GPU partitioning since JetPack 6. Slice the GPU into two halves with a single label, then expose nvidia.com/mig-3g.20gb resources. This is overkill for most edge sites — turn it on only when you need to co-locate two inference services that have different latency SLOs on the same module.

Deploying a sample AI workload (Triton + Isaac ROS)

We now ship a real workload: Triton Inference Server serving a YOLOv8 model, alongside an Isaac ROS DNN node consuming an RTSP camera. Both run on a Jetson Orin NX, share GPU access, and emit metrics through a DCGM sidecar.

Triton Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: triton-yolov8
  namespace: edge-ai
spec:
  replicas: 1
  selector:
    matchLabels: {app: triton-yolov8}
  template:
    metadata:
      labels: {app: triton-yolov8}
    spec:
      nodeSelector: {accelerator: jetson}
      tolerations:
        - {key: jetson, operator: Equal, value: "true", effect: NoSchedule}
      runtimeClassName: nvidia
      initContainers:
        - name: model-sync
          image: amazon/aws-cli:2.x
          command: ["aws", "s3", "sync", "s3://models/yolov8/", "/models/yolov8/"]
          volumeMounts:
            - {name: models, mountPath: /models}
      containers:
        - name: triton
          image: nvcr.io/nvidia/tritonserver:24.10-py3-igpu
          args: ["tritonserver", "--model-repository=/models"]
          ports:
            - {containerPort: 8000, name: http}
            - {containerPort: 8001, name: grpc}
            - {containerPort: 8002, name: metrics}
          resources:
            limits: {nvidia.com/gpu: 1, memory: "6Gi"}
          volumeMounts:
            - {name: models, mountPath: /models}
      volumes:
        - {name: models, emptyDir: {}}

The initContainer syncs model weights from S3 at pod startup. For larger models, swap emptyDir for a persistent volume backed by local NVMe so pod restarts skip the sync.

Ingress

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: triton-route
spec:
  parentRefs: [{name: edge-gateway}]
  hostnames: ["inference.edge.local"]
  rules:
    - matches: [{path: {type: PathPrefix, value: /v2}}]
      backendRefs: [{name: triton-yolov8, port: 8000}]

Isaac ROS pod

For Isaac ROS, follow the same nodeSelector and toleration pattern. Mount the host’s /dev/video* devices into the pod through CDI, expose the ROS DDS discovery port on the host network, and consume RTSP from cameras directly. The detailed wiring matches our ROS 2 Jazzy Jetson Orin tutorial.

Discovery and Akri

If your camera or sensor inventory changes at the edge — e.g., USB cameras hot-swap on a robot — install Akri on the Jetson pool to auto-discover OPC UA, ONVIF, and udev devices and bind them to broker pods.

Observability — Prometheus, dcgm-exporter, and GPU usage

The minimum viable observability stack on a Jetson K3s cluster is the kube-prometheus-stack Helm chart plus dcgm-exporter as a DaemonSet on the Jetson pool. Grafana then renders a single GPU dashboard.

Install kube-prometheus-stack on x86 workers

helm install kps prometheus-community/kube-prometheus-stack \
  --namespace observability --create-namespace \
  --set prometheus.prometheusSpec.nodeSelector."kubernetes\.io/arch"=amd64 \
  --set grafana.nodeSelector."kubernetes\.io/arch"=amd64

We pin Prometheus and Grafana to amd64 so they do not consume GPU node memory.

Deploy dcgm-exporter on the Jetson pool

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: dcgm-exporter
  namespace: observability
spec:
  selector:
    matchLabels: {app: dcgm-exporter}
  template:
    metadata:
      labels: {app: dcgm-exporter}
    spec:
      nodeSelector: {accelerator: jetson}
      tolerations:
        - {key: jetson, operator: Equal, value: "true", effect: NoSchedule}
      runtimeClassName: nvidia
      containers:
        - name: dcgm-exporter
          image: nvcr.io/nvidia/k8s/dcgm-exporter:3.3.x-ubuntu22.04
          ports: [{containerPort: 9400, name: metrics}]
          resources:
            limits: {nvidia.com/gpu: 1}

DCGM on Jetson reports a slightly smaller metric set than on data center cards — utilization, memory usage, temperature, and power are available, but ECC counters and some clock-domain metrics are not. The official Grafana dashboard ID 12239 works out of the box; ignore the “no data” panels for ECC.

Key alerts

GPU utilization >95% for 10 minutes — capacity warning.
GPU temperature >85°C for 5 minutes — thermal throttling risk.
DCGM exporter scrape failure — agent or runtime issue.
Pod restart count >3 in 1 hour — model load loop.

Pipe alerts to Slack via Alertmanager, and to PagerDuty for SEV-2 thermal events.

Lifecycle — rolling JetPack upgrades and image OTA

Lifecycle on a Jetson fleet has two axes: container image rollouts, which are easy, and JetPack base-image upgrades, which are not. Treat them as separate workflows.

Container rollouts

Standard Kubernetes — kubectl apply -f deployment.yaml or GitOps via ArgoCD. Use a rolling update strategy with maxUnavailable: 1 for inference deployments so latency stays bounded.

For models too large to bake into the image, store weights in your S3-compatible registry (MinIO at the edge, S3 in the cloud) and pull at init. This keeps image size under 4 GB, which matters on a Jetson with only eMMC storage.

JetPack upgrade procedure

JetPack upgrades touch the kernel, BSP, and CUDA libraries. Roll one node at a time:

# Cordon and drain
kubectl cordon orin-nx-01
kubectl drain orin-nx-01 --ignore-daemonsets --delete-emptydir-data

# SSH to the node, run the SDK Manager upgrade flow or apt-based upgrade
# (procedure depends on JetPack major version — follow NVIDIA's official upgrade guide)

# After reboot, verify
ssh orin-nx-01 'sudo jetson_release -v'
kubectl uncordon orin-nx-01

For fleet-wide upgrades, drive the cordon-drain-flash-uncordon loop from a CI job and pace it so only one node per failure domain is offline at a time.

A/B partitioning for safety

Production Jetson modules support A/B root partitions. After flashing the B partition with a new JetPack, K3s and the node label survive across the swap. If the new JetPack fails to boot, the bootloader falls back to A. This is the closest thing Jetson has to atomic OS updates — use it for every production upgrade.

Trade-offs and gotchas

Running an NVIDIA Jetson k3s edge AI cluster is the right answer for most edge AI fleets, but it carries real costs and sharp edges.

Sharp edges:

Image tag drift. NVIDIA ships separate igpu (Jetson) and dgpu (data center) image tags. Pulling the wrong one produces opaque CUDA errors. Pin tags in your manifests.
Power mode matters. Jetson defaults to a balanced nvpmodel. For peak inference, set nvpmodel -m 0 (MAXN). For battery-powered robots, the opposite. K3s does not manage this — bake it into your image or use a DaemonSet.
eMMC wear. Heavy logging will burn out the on-board eMMC in 12 to 24 months. Mount /var/log and the kubelet pod log directory on an NVMe SSD.
Cgroup v1 vs v2. JetPack 6 ships cgroup v2; some older NVIDIA images expect v1. The GPU Operator handles this on newer charts, but custom DaemonSets may break.
Network MTU. Flannel VXLAN encapsulation drops effective MTU to ~1450. RTSP camera streams at 4K can fragment. Lower the camera MTU or move to Cilium with native routing.
Thermal throttling. A passively cooled Jetson under sustained inference will throttle silently. The DCGM temperature alert above catches this.
No data center GPU features. No MIG on Nano/NX, no GPUDirect RDMA, no NVLink, no NCCL multi-node training. Edge is for inference, not for training large models.

Trade-offs:

vs. KubeEdge — K3s is simpler, KubeEdge handles intermittent network better.
vs. Docker Compose — K3s scales to fleets, Compose does not.
vs. cloud GPU inference — Jetson wins on latency and bandwidth, loses on raw model size.

Practical recommendations

If you are building this for the first time, here is the shortest path that does not skip anything load-bearing:

Pick a single x86 control-plane node, single x86 ingress worker, single Jetson worker. Get the trio working before scaling.
Pin JetPack 6.x or later on every Jetson. Do not mix JetPack 5 and 6 in one cluster.
Use k3sup for the first install, GitOps (ArgoCD or Flux) for everything after.
Taint Jetson nodes with jetson=true:NoSchedule from day one. Retrofitting is painful.
Run the NVIDIA GPU Operator with driver.enabled=false and toolkit.enabled=false for the cleanest path.
Always use the igpu Triton image tag on Jetson.
Install kube-prometheus-stack plus dcgm-exporter before you have an outage, not after.
Mount eMMC-burning paths on NVMe.
Use A/B partitioning for JetPack upgrades in production.
Layer GitOps fleet management once you cross 5 sites.

Checklist before going to production:
– [ ] All Jetson nodes on the same JetPack major.
– [ ] containerd configured with nvidia runtime as default.
– [ ] Device plugin or GPU Operator reports nvidia.com/gpu per node.
– [ ] Taint and toleration verified by running a non-GPU pod and confirming it skips Jetson.
– [ ] Triton image uses -igpu tag.
– [ ] dcgm-exporter scraping; Grafana dashboard 12239 imported.
– [ ] A/B rootfs partitions confirmed for OTA.

FAQ

Q1. Can I run the K3s server on a Jetson instead of an x86 node?
Yes, but only for small clusters under 5 nodes and only if you accept the GPU memory tax. The K3s server uses 500 MB to 2 GB of RAM depending on workload count, which directly steals from your inference budget. For anything larger or production-grade, dedicate a cheap x86 mini-PC or Raspberry Pi 5 to the control plane and keep the Jetsons focused on AI workloads.

Q2. Do I need the full NVIDIA GPU Operator, or is the standalone device plugin enough?
The standalone k8s-device-plugin is enough for a single homogeneous Jetson pool with no MIG and no driver management. Add the GPU Operator when you mix module types, need MIG slicing on AGX Orin, want bundled DCGM metrics, or run more than 20 nodes. The Operator adds a couple of pods per node but pays back in upgrade simplicity.

Q3. Which Triton container tag should I pull on Jetson?
Always the -py3-igpu variant — for example nvcr.io/nvidia/tritonserver:24.10-py3-igpu. The default -py3 tag is built for data center discrete GPUs and will pull libraries that segfault on integrated Tegra silicon. NVIDIA updates the iGPU tag on the same release cadence as the dGPU tag, so you are not behind on features.

Q4. How do I handle JetPack upgrades across a 50-node fleet?
Drive cordon, drain, flash, reboot, and uncordon from a CI pipeline. Pace one node per failure domain at a time. Use A/B root partitions so a failed flash auto-rolls back. Validate by checking jetson_release -v and waiting for the nvidia.com/gpu resource to reappear before uncordoning. Budget 30 to 60 minutes per node, including model image pulls after reboot.

Q5. Can I train models on a Jetson K3s cluster?
Only small models. Jetson is optimized for inference. You can fine-tune a YOLO variant, a small BERT, or a small diffusion model on AGX Orin’s 64 GB unified memory, but anything that needs multi-GPU collective communications (NCCL, GPUDirect) belongs in the cloud or in a data-center GPU cluster. Use the Jetson fleet for inference and fine-tuning at the edge; ship training to where the GPUs are dense.

Q6. How does this compare to running KubeEdge or OpenYurt?
K3s is a full Kubernetes API at the edge — every kubectl, Helm chart, and operator works unmodified. KubeEdge adds an edge-cloud control plane optimized for intermittent connectivity but requires you to learn new CRDs and split workloads between cloud and edge components. For sites with reliable VPN connectivity, K3s plus Jetson is simpler. For sites with frequent network partitions or hundreds of low-power devices, KubeEdge may be a better fit.