by Rich Burroughs
We’re excited to announce that Loft v2 has shipped. v2 is a set of improvements that we think makes Loft even easier to use and more powerful. Here’s a quick look at what’s in the release. For more details, see the release notes.
One of the most significant changes in the release is the deprecation of the account primitive. Some feedback that we’ve received from users repeatedly is that they were confused by accounts, users, and account templates. Users in Loft represent an individual signing into Loft, while an account represented a user in the Kubernetes clusters connected to Loft. Account templates were designed to auto-create accounts for users in clusters when they sign in via SSO. If you are confused after reading this, you’ll understand the problem.
We’ve introduced a new primitive, cluster access, to make things more straightforward. Cluster access has multiple advantages over accounts:
- Cluster access can be defined for each user or for each team, just like accounts. But now when working with teams you can set resource quotas for individual team members, instead of one limit for the entire team.
- Cluster access is multi-cluster. Before, accounts had to be configured in each individual cluster, making it much harder to maintain them for a large number of users and clusters. With cluster access, you only have to maintain a few cluster access objects at a global level.
- Cluster access is the single source of truth now. You have one single CRD at the global level, where you can easily define a simple, transparent mapping between users or teams and the clusters they should get access to.
We think cluster access is a much clearer abstraction and should be significantly easier for people to use.
While accounts and account templates have been deprecated, you can continue to use them while you migrate to the new cluster access model. Loft will automatically create one default cluster access for each account that you have. To migrate to the new model you can create a new cluster access, and then delete the cluster access object that Loft created and the corresponding account to see if everything works as expected. Then slowly migrate users or teams.
There’s not a date set for removing the account primitive yet, but we will notify Loft customers several months in advance. So don’t stress.
We heard from users who want it to be even easier to provision a space or virtual cluster, and that’s where space constraints come into play. Instead of wrangling multiple security templates in each individual cluster defining how a space is provisioned, we’ve created a new primitive that allows you to define the settings for your spaces and the resources you’d like to be available in them at the global level.
This means you can define things like sleep mode settings, auto-delete, labels, and annotations in the space constraints just like you could with security templates. But the space constraints are defined once and do not have to be copied manually anymore to each cluster. We believe this change will make it even easier for administrators using Loft to set guardrails for spaces that are provisioned and for users to understand these constraints.
Virtual Cluster Templates
We’ve been very excited by the fantastic response to our virtual cluster implementation over the last few months. If you’re not familiar with virtual clusters, they’re kind of like namespaces on caffeine. A virtual cluster runs in a namespace on your host cluster but appears to the user as if it’s a full-blown Kubernetes cluster. Virtual clusters allow users to manage cluster-wide objects like CustomResourceDefinitions (CRDs), which isn’t possible with namespace isolation alone.
But what do you do once the virtual clusters are provisioned? There’s probably a massive gap between a freshly provisioned virtual cluster and what’s a usable environment for your developers. That’s where virtual cluster templates come in.
Now a Loft user can create virtual cluster templates that perform post-provisioning tasks in their virtual clusters. Things you can do with a virtual cluster template include: adding development tooling to a virtual cluster, deploying pre-populated databases with test data, installing CRDs, and much more. Virtual cluster templates make it even faster and easier to provision usable virtual clusters with Loft, so your developers can get right to the important work they have to do.
Sleep Mode Scheduling
Sleep mode is the Loft feature that can suspend workloads running in spaces and virtual clusters that aren’t actively being used. That’s done by scaling down the number of replicas running in a ReplicaSet when there are no API calls for the space or virtual cluster and automatically scaling them up again when activity resumes. This can result in huge cost savings for workloads that don’t need to be available 24x7.
We’ve now added the ability to schedule specific times you would like sleep mode to be enforced. For example, you might set it up to take effect an hour after your developers typically end their day and for sleep mode to end an hour before they start work in the morning, so their environments are ready and waiting when they begin their day.
For some teams, having sleep mode take effect automatically might still be a better option, but we want to give teams and users more flexibility to manage it in a way that suits them best. Note that you can combine inactivity-based and scheduled sleep mode. And for distributed teams, the sleep mode schedule can be defined globally but is applied in the timezone of each individual user (unless you enforce the timezone as well).
We see sleep mode as a critical Loft feature for enabling teams to waste fewer resources and save money, so have a look at sleep mode if you haven’t.
Activity View in the Loft UI
Now auditing is enabled by default in Loft-managed clusters, and we’ve surfaced that audit data in the Loft UI. This allows you to track what users and teams are doing in the management instance, any connected clusters, or virtual clusters. We think this additional visibility will be very helpful for teams that manage Kubernetes clusters.
We want Loft users to get the information they need as quickly and easily as possible. We’ve completely overhauled the Loft documentation, focusing on better organization and ease of use. Check out the new docs here.
There are many other new and shiny things in Loft v2, like the ability to pass parameters to apps you install via Loft, improved descriptions in the UI, and the ability to open a terminal to a running pod from the UI. For the complete list of new features and improvements, see the full release notes.
One thing that ties most of the improvements in Loft v2 together is that they originated with user feedback. We appreciate all of the feedback and suggestions we’ve received from our customers and the community. If you’d like to chat with the Loft Labs team and other Loft users, we have a community Slack for Loft and the open source tools that we maintain. We’d love to see you there.
We hope you enjoy the new features and improvements in Loft v2 as much as we’ve enjoyed building them. If you’d like to try Loft for free, head to our installation guide.
Originally published at https://loft.sh.