k3s single-node cost reduction: which bundled components can be safely disabled without an alternative ingress path

I'm consolidating a low-traffic internal workload onto a single small VM and evaluating k3s's single-server, SQLite-backed mode to cut baseline compute cost compared to a multi-node upstream Kubernetes cluster. The single-binary footprint and embedded datastore are documented to lower idle memory, which fits this workload's traffic profile.

The documented --disable flag can strip bundled components such as traefik, servicelb, metrics-server, and local-storage to shrink overhead further. My uncertainty is the dependency boundary: the workload currently receives traffic through the default Traefik ingress and ServiceLB, and I have no external load balancer or alternative ingress controller provisioned. I also want to keep the option of migrating from SQLite to etcd later if traffic grows, without a painful datastore migration.

Assuming a recent k3s release (component names under --disable vary by version, so I'd confirm against the installed release's docs):

• Which bundled components are safe to disable on a single-server node when Traefik currently terminates all inbound traffic, and what minimal replacement (host networking, NodePort, external proxy) preserves reachability at the lowest idle cost?
• Does disabling metrics-server meaningfully reduce footprint, or does it break kubectl top-based verification of the very savings I'm targeting?
• If I start on SQLite, what is the realistic migration path to external etcd later, and does choosing SQLite now foreclose a zero-downtime transition?