Hmmn... I think it really depends on what you call "service discovery", but I'd note that k8s doesn't give you something as complicated as Consul either -- by default, you get DNS & IP networking for service discovery, which Incus also supports.
If you mean service discovery as in being able to use the k8s API (ex. to find service manually) from inside your application, then incus allows for that too..
Maybe the key difference you're pointing at here is that Incus does not give you one huge network (where by default everything is routable), so you have to set up your own bridge networks:
For the most part, DNS service discovery is good for a lot of use cases where you just want one service to find another service without needing to hardcode IPs/ports.
> by default, you get DNS & IP networking for service discovery, which Incus also supports.
Supports, as in "good luck with your perl scripts" or, as Kubernetes does, automatically updates dns with the A record(s) and SRV records of the constituent hosts? Because I didn't see anything in the docs about DNS support and I don't know systemd well enough to know what problem this is solving <https://linuxcontainers.org/incus/docs/main/howto/network_br...>
I think of this more as routing than service discovery -- there's nothing in k8s that tells you how to reach a related service, you still need to know it's IP or DNS name and reach out.
Incus is not bridged by default, so you have to do more work to get to that starting point (IP addresses), there's some configuration for IPAM as well.
Incus also does not provide name resolution support out of the box, contrasted with kubernetes which will modify resolution rules via the Kubelet. Incus can do this via systemd i.e. at the system level for traffic into a specific Incus node.
> If the system that runs Incus uses systemd-resolved to perform DNS lookups, you should notify resolved of the domains that Incus can resolve.
This, combined with BGP[0] would give you a mesh-like system.
So basically, Incus definitely doesn't do it out of the box -- you need to do your own plumbing.
To be clear, I stand corrected here -- this is a legitimate difference between the two, but it's not that it's impossible/completely out of scope with Incus, it's just that it's not built in.
You may have a point there that k8s is not meant for single machines but that’s not a hard rule, more like a “why would you want to” you can absolutely run single node Kubernetes.
Also strictly speaking incus is not a container nor vm runtime, it’s an orchestrator of those things.
