Hi I've been trying to use this feature in my recently rebuilt k3s cluster, so I'm not sure what "Integrate tailscale into k3s" means and what additional capabilities have been added for a simple homelab user like me.

[brandond]

          Hi I've been trying to use this feature in my recently rebuilt k3s cluster, so I'm not sure what "Integrate tailscale into k3s" means and what additional capabilities have been added for a simple homelab user like me.

I was expecting that I could just type prometheus.monitoring.svc.cluster.local or something and see my prometheus instance after setting it up, so digging deeper, here's what I found.

I see only one route added 10.42.0.0/24 which makes pods reachable but not services, which are on 10.43.0.0/24 by default.

Also, it would be nice if we could set up DNS as well, with split dns, so that we could resolve as if we were inside the cluster.

Originally posted by @autolisis in #7353 (comment)

[manuelbuil]

For services, kube-proxy sets up a DNAT that replaces the Service IP by a podIP implementing the service, so it is correct that you don't see any route

[wohlben]

I feel like the original question hasn't been answered, exactly @manuelbuil.

I'm guessing from your statement that the usecase brandond had in mind was just straight up never in scope, and the added tailscale support was only meant to connect cluster nodes, right?
At least thats my intepretation of it, as kubectl proxy doesn't set any routes / hostnames either to my knowledge- so you probably meant the kube proxy thats running on cluster nodes.

I expected other tailscale devices to be able to connect to the service IPs too (i.e. my laptop). The docs never said it did, but i think a simple note might clear up the confusion for easily misguided users like me ;)

i.e. "note: this is only meant to connect the kubernetes cluster nodes, it is not meant to enable general kubernetes access from tailscale devices"

[brandond]

The question was from @autolisis, not me. I just moved it here from a comment on the work tracking issue, since that was not the correct place for it.

[brandond]

But yes, the tailscale integration is just intended for use as a flannel backend, to provide the cluster underlay network for traffic between pods and services within the cluster. It is not intended as a mechanism to expose the cluster api or services, outside the cluster.

[autolyticus]

Hi I was the original owner of the issue here and I recently came across this: https://tailscale.com/kb/1236/kubernetes-operator which does implement exactly this :)

[asierzd]

Hello,

I don't know if this is something to post it here (It is not exactly a problem/issue to fix), but I've been struggling with the issue of connecting an agent node to another master node in different machines and networks for way too much time. I tried with Wireguard and I somehow messed up my internet connection in a machine, gave up on this VPN, and then tried to setup manually the connection with OpenVPN, which worked in some machines and in others not, but I didn't try with Tailscale, because at first I thought it was a paid service and I couldn't afford it.

However I came back to try Tailscale, and found out that it had a free tier and I could do some testing. At first, at least for me, it wasn't very clear how this could be done as with Wireguard, but it turned out that K3s does all the configurations for you as well as Tailscale, which is incredible and I love it because it handles all the communication between nodes by itself.

So I wanted to thank the K3s team for this feature, however, it could be be clarified in the docs that there is a free tier, and maybe a simple example could be nice. Also found out that there is a Tailscale operator for resolving internal DNS outside of the cluster, which I don't need at the moment, but it is also a great feature.

Keep up the good work, K3s is by far the best Kubernetes project out here, thank you very much!! :)

Edit: Also, it can be underlined that, unlike other VPNs, it can be setup for using it without the need to open additional ports, because it can use DERP servers and NAT traversal techniques that enables the node to communicate with others (by default), so it is very easy to start connecting agent nodes!