February may be the shortest month of the year, but we’ve still managed to pack in several new enhancements to Replicated. We’ve introduced the ability for Vendors to declare which application manager (aka KOTS) version is installed on an existing cluster. We’ve also improved support for semantically versioned releases, added new CLI commands, and introduced BETA support for K3s, RKE2, and a single-node-optimized Kubernetes installer. Keep reading for more details on these exciting new capabilities.
New Release Highlights
What’s New for the vendor portal:
- Vendor portal: Semantic versioning support is now enabled by default in Stable and Beta channels for new applications
What’s New for the application manager
- Application manager: Control the version of KOTS installed on existing clusters for a given application release
- Application manager: KOTS CLI now includes a ‘get versions’ command
- Application manager: MinIO images are no longer present in embedded cluster deployments unless explicitly added
What’s New for the Kubernetes installer
- Kubernetes installer: (BETA) Support for K3s, RKE2, and an installer optimized for single-node installations
What’s New for the vendor portal
Vendor portal: Semantic versioning support is now enabled by default in Stable and Beta channels for new applications
Replicated has historically sorted releases in a channel by their creation dates. If you promote a release to a channel, it becomes the latest release, and end users are prompted to update in the admin console. This made it difficult to patch an older version of an application, because end users would be prompted to update to the patch release even if they were already on a later major or minor version. Vendors had to get creative and use a release channel per major or minor version to accomplish patch releases like this.
Replicated’s recent support for semantic versioning gives you greater flexibility and control over releases in a channel. KOTS 1.58.0 introduced opt-in support for semantic versioning for a release channel. When enabled, Replicated validates that the version label for any release promoted to the channel is a valid semantic version. In the end user’s environment, the admin console sequences releases by their semantic versions rather than by their creation dates.
This allows you to have multiple major and minor versions active in a channel at the same time. You can patch an older version of your application, and the admin console will slot that version into its appropriate place in the version history, rather than simply putting it at the top because it is newly released. End users who are already on a later major or minor version will not be prompted to update since this release is not later than what they currently have deployed.
Previously, semantic versioning needed to be enabled for channels individually. Now, when a new application is created, the Stable and Beta channels will have semantic versioning enabled by default. The Unstable channel will continue to have semantic versioning disabled by default. Applications and existing channels created prior to this change will see no change in behavior.
To leverage this feature for your existing applications, select Enable Semantic Versioning in a channel’s settings in the vendor portal, or use the replicated channel enable-semantic-versioning command.
What’s New for the application manager
Application manager: Control the version of KOTS installed on existing clusters for a given application release
While the Kubernetes installer has offered the ability to specify a particular KOTS version to be installed in the created cluster, vendors installing their apps into existing clusters did not have this type of control. Existing cluster installations always installed the latest version of KOTS. This presented several challenges: it could be harder to reproduce issues, maintain end-user environment consistency, test an application against a given KOTS version, or gate the roll-out of KOTS feature changes.
To solve these challenges, we introduced several enhancements. First, we improved the `curl` command that installs the KOTS plugin so that it can also install a particular version of the `kots` CLI. For example, `curl https://kots.io/install/v1.62.0 | bash` will install version 1.62.0 of the `kots` CLI.
This is great for ad-hoc installations of KOTS, but to integrate it into our standard installation commands, we introduced a new `targetKotsVersion` field in the KOTS Application custom resource, available as of KOTS v1.62.0.
Specifying this field does two things. It changes the install command that is displayed on the channel card in the vendor portal, so the specified version of the `kots` CLI will be installed. Then during the installation, compatibility checks will block the install if the version of KOTS being used is greater than the specified target KOTS version.
While the target KOTS version helps vendors ensure their customers install a particular version of KOTS, it does not help them keep their customers up to date over time. So we also introduced a new `minKotsVersion` field in the Application custom resource, available as of KOTS v1.62.0.
This field is currently in beta, but specifying a minimum KOTS version will enforce compatibility checks that block both new installations and application upgrades from occurring if the currently installed KOTS version is less than the specified minimum KOTS version. An error message will be displayed informing the end-user to upgrade KOTS to at least the minimum version. If the error occurs during an application upgrade, the new version will appear in the version history, but it will not be downloaded. After updating KOTS, the end-user will have to click the download button next to this application version.
Try out these new enhancements for your existing cluster installations and share any feedback you have with your customer success manager!
Application manager: KOTS CLI now includes a ‘get versions’ command
When a KOTS CLI user runs the `upstream upgrade` command, it fetches and downloads the latest version of the application. However, an application end-user can also fetch and download the latest version by clicking the ‘Check for updates’ button in the application manager or by allowing the ‘automatically check for updates’ auto-download cron job to run. This could create a disconnect as any automated CLI scripts relying on these application version details would be unaware of these new versions downloaded outside of the CLI.
With the new `get versions` CLI command, you can get a list of all of the versions the application manager has for a given application. See the screenshot below for return details, which can optionally be returned as JSON too.
Application manager: MinIO images are no longer present in embedded cluster deployments unless explicitly added
Given MinIO’s transition to a GNU AGPL v3 license, we’ve been hard at work to provide options for customers to opt out of this technology if they have concerns about the license change implications. It has already been possible to opt-out of this technology in existing cluster or embedded cluster installations, but there was still an unused MinIO image present in the embedded cluster bundle in case it was needed at runtime. As of KOTS v1.64.0, a MinIO image will no longer be present in new embedded cluster deployments if MinIO is not explicitly specified as an add-on in the Kubernetes installer specification.
What’s New for the Kubernetes installer
Kubernetes installer: (BETA) Support for K3s, RKE2, and an installer optimized for single-node installations
To date, Replicated has recommended a single Kubernetes installer spec to vendors. Our aim was for that single installer to work well across the variety of potential deployment models used by vendors. As our customer base has grown, so have the variety of deployment use cases we’ve seen. One pattern we’ve recognized is that single-node installation use cases often have very different needs and technical requirements than multi-node deployment use cases. As such, we’re moving towards offering a specialized Kubernetes installer recommendation aimed at that single-node use case.
To support this goal, we’ve introduced beta support for the K3s and RKE2 add-ons. These Kubernetes distributions from Rancher are each packaged as a single binary, reducing the dependencies and steps needed to install, run, and update Kubernetes. They also come with several add-ons already included for things like storage and networking.
Beyond just offering these add-ons in the Kubernetes installer, we’ve also put together beta support for a Kubernetes installer spec that is optimized for single-node installations. This spec can leverage either K3s or RKE2 and currently supports a few add-ons. The goal is for this installer to increase installation success and decrease the support burden for single-node installations.
While these add-ons are in beta, there are several limitations that are described in the documentation. One limitation is that you cannot upgrade from one version of K3s or RKE2 to another. The Kubernetes installer currently supports the latest version of each of these add-ons, and we’ll work on adding upgrade support in the near future.
We would love for vendors to partner with us as we work to improve the single-node installation experience. If you have installations that are specifically designed for a single node, try out the single-node optimized installer spec and provide your questions and feedback to your customer success manager.
That’s it for the February release highlights! Want to learn more about these new features and what Replicated does to help vendors and customers install and manage modern apps on-prem? We would love to show you -- click here to schedule a demo.