Replicated is delighted to announce support for the Helm CLI as a new install method (now in alpha), complementing our other install methods. Now, in addition to using KOTS to manage the lifecycle of an application deployed on an existing or embedded Kubernetes cluster, Helm can be used. Rather than offering only one piece of the puzzle, Replicated aims to maximize your addressable market (and your customers’ success!) by providing a wide choice of installation methods all based on the same underlying tooling. This new capability reflects the industry trend among advanced customers toward using Kubernetes-adjacent open source projects where possible.
Our goal is to help you (the software vendor) meet your customers where they are today, and increasingly there are Kubernetes-savvy enterprise customers who are consolidating on Helm as their tool of choice. This segment of customers might not be comfortable or familiar with KOTS, might need security reviews or approvals, or have other perceived friction with a different installation method. We want to help you eliminate these barriers and focus on distributing your applications any way your customers prefer to install them.
A major reason to use Replicated to assist with Helm-based installation is that we provide a transparent mechanism to authenticate customers using their license prior to giving them access to the application artifacts. For example, you can host your application’s container images in a private registry and automatically generate the associated customer-specific image pull secrets (credentials) during the installation, rather than creating and distributing these secrets out of band. Revoking a customer’s license also revokes their access to the images, giving you full control over onboarding and offboarding.
We’re also adapting the admin console as an optional dependency if you’d like customers to still have access to a UI for post-installation information and tasks. Functionality in the admin console is updated so that Helm rather than KOTS manages the lifecycle of the application. So instead of clicking a button to deploy a newly available version, the button provides the necessary Helm commands to perform the upgrade. Other functionality like checking for updates to the application and generating support bundles still works too.
But we’re getting ahead of ourselves here. Let’s look at what’s in the works for installing applications with Helm using Replicated. (Note, as with any alpha/beta feature, this is subject to change before GA.
One of our goals is for a single application release to be installable into various and heterogenous customer environments. Whether or not customers have Kubernetes clusters, and whether or not they use Helm to deploy applications, are just some of the factors that we hope to abstract away so that your application can be installed by a variety of enterprise users.
In this case, some advanced end customers have standardized on Helm, and KOTS can be viewed as an exception that slows down adoption or installation due to needed reviews of the tooling used to deliver the application.
Our solution allows a software vendor to continue delivering a single architecture/packaging of their application to all customers, whether those customers lack a Kubernetes cluster, have a cluster and prefer a KOTS-based installation with its friendly UI, or have a cluster and prefer to use Helm. This only assumes that the vendor packages the application as one or more Helm charts.
Note that this is a limited-availability alpha feature and will undoubtedly change a bit before becoming generally available.
Your application must be packaged as Helm chart(s). The application can contain multiple charts, but only Helm charts will be installed when the customer chooses the Helm install option. End customers using the Helm install option must have an existing Kubernetes cluster.
Note: Replicated has developed & open sourced a KOTS2Helm migration option for existing vendors. This project can be used as a starting point if you don’t yet use Helm charts.
When a release is promoted to a channel, the Replicated servers detect all Helm charts in the release and push them to our internal, private registry. This already happens for applications today.
For example, given the following application, if the application "slug" is "my-app", the following Helm chart will be published automatically when this application is promoted to the "stable" channel:
Every Helm 3 chart is automatically extracted and published to the private registry. These charts are not publicly available. The format of the reference in the registry is always:
where chart-name and chart-version are read from the Chart.yaml in the chart's .tgz archive.
In addition to the chart being published, Replicated will find the "kind: Preflight" and "kind: SupportBundle" specs, if present, and publish each of these as OCI artifacts to the registry. The OCI references for these manifests are:
(The exact names of the preflight and support bundle references are an implementation detail and may change. The product will handle updates to the names.)
The Helm install method supports everything that Helm 3 supports, so you can include additional charts as dependencies and use any other built-in Helm functionality.
We also recommend including the admin console as a dependency (subchart) so your customers continue to benefit from its features and UI. For more information about delivering the admin console as a subchart, see Delivering the Admin Console with your Application.
To find the customer-specific Helm install instructions, visit the Customers page in the vendor portal, select the customer, and click "Helm Install Instructions" at the top right:
The username and password are customer-specific and required.
To install the application, the end customer only needs Helm (3.8 or later) along with credentials. Simply deliver the commands from the above section for the customer to execute. All normal Helm functionality will exist as expected.
When the end customer retrieves the chart, the values file from the top-level chart is rendered using Replicated template functions before delivering to the customer. This exists to inject license fields, the license ID, and other customer-specific data into the application. In order to use and consume these fields in your application, have the Helm chart read them from the .Values context.
“But wait!” you say. “Why do I need this at all? Don’t Kubernetes and Helm already give me everything I need to install my applications?” To this, we would politely respond, “Nope.”
Let’s compare what functionality you get from Helm by itself versus with Replicated. Note we are still exploring ways to add some Replicated features in the context of a Helm install.
Sure, you could maybe build some of the stuff that Replicated can do for you, but at a horrendous cost in terms of time, effort, and opportunities lost. And then you’d be stuck with maintaining your cobbled together Frankenstein’s monster for all eternity.
Hopefully that gives you a good idea of how we intend to support the Helm CLI as an installation method. Check out this demo video for an overview of the Helm install method and a walkthrough of installing an application using Helm and using the admin console:
If you’re a current Replicated customer and would like to preview this new Helm capability for use with your applications and customers, please reach out via our Alpha/Beta program or your account team.
If you’re evaluating Replicated and like what you’re hearing, please request a live demo.