Wait a minute, what do we mean, “December”? It’s January!
Yes, and Happy New Year! Like many of you, we took a little time off between the holidays to cozy up by a fire, sip some hot cocoa, and enjoy some much-needed time off with friends and family. We hope you won’t mind this update coming a week later than usual as a result. 🙂
Check out what the Replicated Product & Engineering teams were up to in December to drive our roadmap with exciting new capabilities for our application manager (a/k/a “KOTS” (Kubernetes Off-The-Shelf), our Kubernetes installer (a/k/a “kURL”), and the vendor portal (previously “Vendor Web”) below.
And if you haven’t yet considered the new Replicated Beta Program, give it some thought! Sign up for the beta mailing list to get notifications about early access to alpha and beta features. In exchange, we’d like feedback on your interest in the features, how well they work for your purposes, and any suggestions for improvements.
New Release Highlights:
What’s New for the vendor portal:
- Vendor portal: Expanded Helm workflow documentation brings clarity to Helm use
- Vendor portal: Default Kubernetes installer now pins minor versions instead of latest version
What’s New for the application manager
What’s New for the Kubernetes installer
What’s New for the vendor portal:
Vendor portal: Expanded Helm workflow documentation brings clarity to Helm use
Some users may have noticed the expanded documentation details available in Helm Processing for the new Helm installation workflow. The aim of this expanded documentation is to provide users with in-depth, step-by-step details on what the useHelmInstall flag does. This ‘under the hood’ documentation should help clarify how Replicated processes Helm charts while evaluating and using this new workflow. More comprehensive than what was available before, users can also better understand why this workflow is our recommendation for those that want to deploy their apps via Helm charts. Click the links above to review the details!
Vendor portal: Default Kubernetes installer now pins minor versions instead of latest versions
When you create a new application in the vendor portal, a default Kubernetes installer is created with it. Previously, this default installer specified the “latest” version for each add-on, which resolved to the latest recommended version of each add-on. However, the “latest” versions are subject to change, so using them makes your installers less predictable. We adjusted this spec to pin minor versions for all included add-ons except KOTS and EKCO. This is done using kURL’s support for .x patch versions. In addition, since the “latest” Kubernetes version was 1.19.15, we updated this spec to include Kubernetes 1.21.x instead.
This change has no impact on existing Kubernetes installers or any new Kubernetes installers created for an existing app. This change only alters the default installer that is created for a new application.
What’s New for the application manager
Application manager: New response includes version detail to `kots upstream upgrade`command
KOTS CLI `upstream upgrade` is enhanced to now return version details when run. Previously, running this command would notify the user of how many newer versions were available and fetch them. No information was returned about which versions were fetched. Without this information, it was challenging for users to save, evaluate, and act on version details programmatically. Now when running this command, version details for any newly fetched versions are returned. Additionally, a new–deploy-version-labelflag is available for specifying which version to deploy. For example, this can be used to upgrade to a specific version that was fetched that may not be the latest version.
What’s New for the Kubernetes installer
Kubernetes installer: Embedded clusters no longer require Rook or MinIO for object storage
In light of MinIO’s license change, as well as Replicated’s move toward Longhorn instead of Rook, Replicated needed a deployment path that no longer required object storage. For existing cluster installs and upgrades, we introduced the --with-minio=false option to remove KOTS’s dependency on MinIO. But for embedded clusters, the KOTS, Registry, and Velero add-ons had object storage dependencies. Now it is possible to not only deploy a new embedded cluster without object storage, but you can also migrate pre-existing embedded clusters so that they no longer leverage object storage. In order to do this, you must set the disableS3 flag to true in the KOTS add-on, and exclude any object storage provider (either Rook or MinIO) from your application’s Kubernetes installer spec. Several actions will be taken to use persistent volumes rather than object storage for any affected add-ons included in the installer spec, and necessary migrations will be performed too. These actions are detailed in the documentation. All Replicated installations—both existing and embedded cluster—continue to use object storage by default. However, if you are interested in using Longhorn as the PVC provisioner for embedded cluster installations and object to the use of MinIO’s AGPLv3 license, talk to your customer success manager to learn more about migrating to Longhorn without requiring object storage.
That’s it for the December release highlights. Thanks for reading! This month, we will get back to our regular schedule of sharing these updates with you at the end of the month. We hope you all had a wonderful holiday!
And as always, 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.