I have worked over the past week to create a “system extension” for Talos OS allowing to connect to API of Talos using OpenZiti overlay network! Not only that but you could also serve your k8s services directly from the node within the default Talos k8s pod network.
There were multiple hard points to solve. From having the build for ziti-tunneler-sdk-c to fail on Alpine Linux(thanks scareything for a fast resolution), to trying to figure out how to force building a fully static binary of the tunneler. As well as figuring out that only hosting is allowed(no dialing) in this particular state of networking stack of Talos.
It's been a great week diving deep into ziti-tunneler-sdk, to see how it works and how it evolved into having run-host mode.
Merge request is still being reviewed but I hope it would get merged soon.
In the meantime you could either build an installer yourself and include my openziti image.
Or just use my installer that I built which includes openziti tunneler.
Hope that OpenZiti sees more adoption through this.
If we can find a compatible build configuration, a Talos extension would be very cool. I'll follow those PRs.
Summary of the PR conversations thus far: Talos needs to build the tunneler from the source with pinned dependencies. However, many build dependencies were perceived as friction or a liability. Alternatively, OpenZiti can ship a static variant of the release binary.
Are you aware of the tunneler daemonset? This is not equivalent to baking the tunneler into Talos OS, but you could do something similar like this daemonset to ensure that ziti-edge-tunnel run-host is always active on worker nodes. The daemonset seems like the most natural way to ensure one tunneler per node, but it would probably need to be modified (or customize the input values to the chart) to change the tunneler run mode to run-host and stop running in privileged mode, which is only necessary for creating routes. There would be no need for the CoreDNS node local cache in this case because the tunneler is not providing DNS.
Still, the run-host mode does not require elevated privileges, and you might need to control which Ziti identity is running in specific Kubernetes namespaces. You could configure this Helm chart openziti/ziti-host that provides a reverse-proxy pod. The same Ziti service hosting functionality can also be achieved by deploying the openziti/ziti-router chart in "host" mode.
Yeah, I am aware of the DaemonSet for k8s, but I wanted to have an alternative to Tailscale for controlling Talos using OpenZit overlay, as well as contributing to OpenZiti to see its adoption in Talos community as well.
Alright, good news.
Meanwhile the merge is getting done, I managed to create a routing rule to route traffic to the overlay.
So it is now possible not only to host, but also to dial other services!
Hi @bengcooper. We have in fact released static binaries with ziti-edge-tunnel 1.1.3, however it seems that those binaries may have some unexpected dependencies, specifically on the linux kernel version that the host uses, since the GitHub runners that are used to build the binaries have a newer kernel than the standard Ubuntu 22 image.
@nenkoru, I've been out for a bit but have been meaning to ask if you've tried the released binaries, and if they are working ok for you?
I haven’t had time these two weeks to check it properly, however I am onto to test this this weekend!
Will reply with an update tmrws morning or evening(Sunday, UTC+3).
Ok, I got one drive failed on the server. Need to replace it with a spare and restore the controller and other stuff from backups.
So might miss on that promise of tmrws morning or evening
