June was another big month for the Replicated Product & Engineering teams! We have some exciting new capabilities to share based on input from vendors like you.
Let's take a look at what's now available in our application manager (building on the open source "KOTS" project AKA Kubernetes Off-The-Shelf) and our Kubernetes installer (expanding on "kURL.”) Read on for all the juicy details!
Previously, application releases and Kubernetes installers were always promoted separately in channels – there was no direct coupling between a release and an installer. Feedback from vendors like you indicated a need to test and support installing a particular release on a specific Kubernetes installation together instead of having to manually keep track of these couplings. This gap made it harder to ensure that the right Kubernetes installer was used when installing each application release, which sometimes complicated customer support efforts.
Now you can include a specific installer in each release and tightly couple the two, giving you more control and simplifying support with more reproducible and predictable releases, including both the infrastructure and the application. When coupled, the vanity installer URL is updated to point to the installer in the release, rather than a separate installer promoted to the channel. We also create a versioned URL that allows you to deterministically install a particular application version and use the installer included in that release. For example, `curl -sSL https://k8s.kurl.sh/myapp-beta-1.2.3 | sudo bash` will use the installer included with version 1.2.3 of myapp in the beta channel, and it will install app version 1.2.3.
This feature is currently in alpha but will be moving to beta soon (perhaps with minor changes.) You can learn more in the docs on packaging an embedded Kubernetes installer.
We recently made it possible for you to install previous versions of an application, not just the latest version. But the instructions on how to use install commands for specific versions were buried in documentation (see --app-version-label for both the app manager and the Kubernetes installer) and not readily apparent in the product. This made it harder to ensure you had the proper install command for a given version.
Now you can go to the release history page for a channel to view and copy installation commands for any historical version. This works the same for both existing and embedded cluster installations. Now you don't have to piece them together manually; you can just find your desired version in the history and copy the complete command!
You might want to reach out to the experts on our team for many different reasons. To make reaching the right team at Replicated even easier, we've added some new options to the Vendor Portal.
Submit a support request: This familiar option has now been enhanced to allow you to choose the specific product area or component that isn't working as expected. This additional information will help us identify the problem area more quickly and engage the best experts to assist.
Request a feature: Replicated may solve a lot of problems for vendors and their customers, but we don't solve everything quite yet. Now you can submit a feature request directly to the Replicated Product Management team. These requests are regularly reviewed by the product and engineering teams, making it easier than ever to share your ideas and propose future enhancements.
Get help with Replicated: We love open source software and contributions from our community, including ideas on how to work with the product itself. This option will quickly steer you to common resources, including our extensive documentation (filled with tutorials and examples!) and the Replicated community site itself. You'll find answers to common questions, details on how to achieve the desired end result, and can ask your own questions to collaborate with the community and expert Replicated engineers who actively monitor the forum. If you do not want to ask the question publicly or if there are sensitive details in the question, you can optionally fill out a request for help form instead.
Prior to app manager 1.74.0, our product didn't request or require that Kubernetes installer updates be applied when updating your application. Vendors would often document that the installer should be re-run before an application upgrade, for example, but you couldn't control (or even encourage) this directly through Replicated. This meant that enterprises could use your application on an outdated Kubernetes cluster, causing potential support and security issues.
Now, if you couple an installer with your release, you can use a new preflight check that will compare the installer in the release with the installer currently used in the environment. Since this is a standard preflight check, you can do lots of customization if the two installers don't match. You can choose whether this should warn or fail, you can make this a strict preflight check so that failure will block the installation, or you can use the `message` field to provide instructions to the user on how to re-run their installer to update their cluster. This helps close the loop between including the installer in the release and ensuring that customers use the specified installer with each application version.
You can read more in the docs about using preflight checks with a specific embedded Kubernetes installer.
Keeping with the times, we have added support for Kubernetes 1.24 within one month of its release, meeting our goal SLA for supporting new versions of Kubernetes and many commonly associated projects. Specifically, Replicated's Kubernetes Installer was certified by the Kubernetes community for Kubernetes 1.24. This continues our dedication to passing these end-to-end conformance tests, ensuring stability and backward compatibility for embedded clusters deployed using the Kubernetes installer, and reducing the likelihood of running into compatibility issues or security gaps from unpatched CVEs.
In addition, we have now also added support for:
Vendors can now go to the release notes to see which Critical and High CVEs are patched in a given release of Replicated. This helps vendors to more easily track our progress against essential security fixes.
We made several updates to the How to Package and Distribute a Production Application procedure to better describe what you should do when packaging your application with Replicated and what additional recommended functionality exists.
We also added a workflow diagram that illustrates the major decision points in the packaging process. Our goal is to give you a better tool for navigating and making informed decisions about packaging and distributing your app with Replicated.
When installing an application with Replicated, it can be helpful to know how to completely delete the admin console components to start over with a fresh install. Deleting the Admin Console and Removing Applications describes how to do this on existing clusters and embedded clusters created by the Kubernetes installer.
The installation docs now include minimum system requirements for installing on an existing cluster. Users can reference these requirements to understand how much space is needed for the admin console components on existing clusters.
See? We told you it was a busy month at Replicated! 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.