This release of Talos accumulates a lot of changes resulting in an improved user experience.
It brings more knobs and switches to play with so that you can dial in exactly what you need.
Getting Ready for Something Awesome
If you run Kubernetes on bare metal you need Sidero Metal. It is the simplest, yet most flexible and reliable way to run Kubernetes in your data center. One reason for this is that we have designed it to work explicitly with Talos. This means that we can go all in and leverage the APIs of Talos to make the installation and operation of Kubernetes on bare metal more resilient and robust.
In this release, we added a feature to make this integration even tighter.
We call it “SideroLink.”
SideroLink allows us to set up a point-to-point Wireguard tunnel that connects Talos Linux nodes to Sidero Metal. What we can do with this in the future is virtually limitless.
One of the first things we plan to do is send all Talos events and kernel logs over the tunnel to Sidero Metal.
At face value, this may seem insignificant, however, the real magic is what you can do with this information.
When using a provisioning system, you need a way to get console output when a machine is booting. If you don’t have this, you have no clue what is going on with a box. This is especially true with Sidero Metal and Talos. If a machine reboots due to an error in the configuration file, for example, you won’t know this unless you watch the console output in real time.
With SideroLink we can ship off these logs to Sidero Metal so that you have a full record of all boot logs for a given machine, even if you weren’t connected to the console at the time of failure.
The more exciting possibility is what you can do with events.
Over the last year we added event publishing to Talos (you can try this today with talosctl events). An event in Talos is a structured message that represents a status change within Talos. For example, after an install Talos will publish an event stating whether or not the installation was successful. A subscriber can receive this structured event and not have to parse anything, unlike logs.
With SideroLink we can ship these events off to Sidero Metal where we can automatically process them and update the status of Server resources. Using the installation event example above, when Talos installs successfully we can see that in the events and mark the Server
We can also watch events in a controller responsible for upgrading nodes in a cluster. The controller can use these events in decision making to create reliable infrastructure in the same way that Kubernetes gives us a way to do this for applications.
These are just a few examples that we intend to implement in the near term. We are excited to see what our creative community cooks up with this!
Shipping Logs
A feature that has been long overdue is the shipping of logs for auditing and operational monitoring. We wanted to do this the “right way,” so we waited until Talos was ready – which is now! In v0.14 we now support sending log lines as JSON over either TCP or UDP.
Multiple destinations can be specified, and both service logs and kernel logs can be shipped!
For more details and to learn how to configure log shipping, you can checkout the docs .
Cluster Discovery
In the past it sometimes felt like you were flying in the dark when getting Talos up and running. Our users wanted to be able to use talosctl to get a full list of nodes that are part of the cluster without having to depend on Kubernetes. We added this functionality back in 0.13, but it was hidden behind a configuration option.
In v0.14, we now enable cluster discovery by default.
With cluster discovery you get the ability to see all members of a cluster without the need for Kubernetes (talosctl get nodes) and faster cluster join times on worker nodes (since we no longer depend on the kubelet).
This means one less thing to configure and a better out of the box experience!
Kexec – for blazing fast upgrades on bare metal.
In v0.13 we added the ability to kexec instead of rebooting to make installs and upgrades blazingly fast on bare metal. This makes such an impact in speed, it’s worth highlighting. By skipping the BIOS initialization (this is often referred to as a “warm reboot”), you don’t have to suffer the often tens-of-minutes-long memory checks and power-on self tests of large servers. This makes upgrading the OS and Kubernetes versions of such nodes super fast.
Due to the many problems in kexec on Rasbperry Pis, v0.14 disabled it for this platform.
VLAN Improvements
Another knob we added was the ability to set the MTU on a VLAN interface, a straightforward feature that needs no explaining.
We also added support for setting a virtual IP (VIP) on a VLAN interface. Our VIP feature has been one of the things that sets Talos apart. We added the feature so that bare metal users wouldn’t need any extra infrastructure (DNS or load balancers) to run highly available Kubernetes clusters in the data center. VIP support has been a feature loved by our community, so it only makes sense that we support it on a VLAN interface.
With Talos v0.14 you can!
Automated Support Data Gathering
The API of Talos is a feature that allows us to do things that would seem nearly impossible with traditional Linux distributions.
The new support subcommand in talosctl is one such example. Simply point it at a machine and it will spit out a zip file with everything we need to support you (or that you need to support others). We automate the process of digging into a problem with each API so that exchanges over Slack, for example, aren’t a wall of text asking for the output of twenty different commands.
This is a real time saver!
Managing the Kubelet
Earlier this year we announced the COSI project and our intention to make Talos the first OS based on this framework. We have made some further strides in this release toward that goal. In Talos v0.14 we added the controllers necessary to make changes to the kubelet apply immediately, without the need for rebooting the machine.
It seems simple enough, but it is a huge jump forward on the path to making Talos COSI-compliant.
While we were at it, we also decided to allow users to restart the kubelet using the API, and we threw in the ability to exclude a subnet when filtering the IP address chosen for the kubelet.
Component Sync
In this release, we have improved the upgrade-k8s subcommand such that all components considered to be part of the cluster are now upgraded.
In the past we skipped CoreDNS, Flannel (if used), and the kubelet.
Upgrading of CoreDNS and Flannel is straightforward, but the really cool feature is that we now keep the kubelet version in sync with the control plane version: no more manually managing that process across each and every node!
The Little Things
This release comes with 177 commits!
One of the minor features worth pointing out is the separation of the image generation functionality of our `installer` container into its own container, fittingly named “imager.”
This means less to pull when installing and upgrading Talos.
We added a host of little changes like NTP improvements, component version updates, Golang version bump, and more.
Grab the release on GitHub today!
You also can see the full CHANGELOG on GitHub.