Talos 0.3 Released
The wait is over. Version 0.3 of Talos is out! This release is jam packed with goodies, but the thing I am most excited about is the stability we have gained. Throughout the course of the development cycle of v0.3 of Talos, we have worked with our community on getting Talos polished for production use.
We will continue to build upon this base, but v0.3 should cover a large portion of use cases out there. I couldn't be more proud of our community (employees, contributors, and users) in achieving this milestone.
To go from zero code, to a production ready OS with a fundamentally different approach to managing the system (an API), written in a modern language (Go), in the time we did is an impressive feat.
It is also exciting to see how many people love the design decisions we have made with Talos, some being scary at first glance:
- No shell
- No SSH
- API driven
Under normal circumstances these ideas are frightening and sound impractical, but if you dig into the design of Talos you will see that they make a lot of sense in the context of Talos and Kubernetes.
Our users have embraced these decisions, bringing both energy and new ideas to the project. We feel extremely honored to be the team to usher in a new era of OS management, and we thank everyone who has been involved so far!
As for the features in v0.3, I went into a bit more depth in my previous blog, but it is worth reiterating a few of the highlights.
In this version of Talos we made the switch to a self-hosted control plane. This allows users to manage Kubernetes just as they would any other application. The control plane is a set of manifests that can be applied and rolled out using Kubernetes primitives to do so.
Need to enable a feature gate? Edit the manifest and watch the control plane update itself. Need to enable OIDC? Patch the API server's manifest.
This provides an incredible amount of flexibility to the user and also aligns with the philosophy of Talos.
We now support automated upgrades using our controller. Using channels, and what we are calling upgrade "pools", you can now set upgrade policies for different sets of nodes in your cluster. A pool allows users to do things like:
- Set a channel, or an explicit version
- Set the concurrency
- Set how often upgrade availability is checked
- Failure policies (retry or pause)
An example might be that you have a 20 node cluster with 2 nodes on the beta channel, running a low-impact application. Then maybe you have 5 nodes subscribed to the "stable" channel, which will automatically upgrade the nodes as releases become available.
Three of the remaining 13 are the control plane, and you don't want those upgrading automatically, but you do want to roll out the upgrade using the controller, so you set the version explicitly and with a failure policy of "Pause."
The remaining 10, well, you get the picture: you can carve up into pools as you see fit.
Grab the release on GitHub if you are already familiar with Talos and upgrade today!
If you are new to Talos, check out our getting started guide!
If you are interested in trying Talos, check out our Getting Started guide! You can set up a test cluster in a local Docker environment in just a couple of minutes.
Talk to Us
Do you have questions? Are you interested in learning more about our services and support offerings? Contact us and we’ll get back to you right away.