Skip to main content

KOTS Terminology and FAQs

This topic lists key terminology and frequently-asked questions (FAQs) for the Replicated KOTS installer that are helpful to understand before getting started.

Key Terminology​

Air Gap​

Air gap or air-gapped refers to customer environments that do not have outbound internet access. Air gap environments are common for enterprise users that require high security.

Embedded Clusters​

Embedded clusters are Kubernetes clusters provisioned on a virtual machine (VM) or a bare metal server. Embedded clusters are built from a customized Kubernetes distribution embedded with an application and provisioned in the customer environment at the time of installation. Enterprise users that do not have an existing cluster (or do not have experience with Kubernetes) can install an application with KOTS in an embedded cluster.

Software vendors can use the Replicated embedded cluster feature or Replicated kURL to create a custom Kubernetes distribution and support embedded cluster installations. For more information, see Using Embedded Cluster or Introduction to kURL.

KOTS Custom Resources​

KOTS provides several Kubernetes custom resources in the kots.io API group. KOTS custom resources are consumed by KOTS or other kubectl plugins and are not deployed to the cluster.

Software vendors can configure KOTS custom resources to provide installation instructions and control the application experience.

For more information, see About Custom Resources.

KOTS Template Functions​

KOTS provides a set of custom template functions based on the Go text/template library that can be used in any Kubernetes manifests for applications deployed with KOTS.

KOTS template functions can be used to generate values specific to the customer environment that can be useful during installation. For example, customer entitlement information, user-provided configuration values, or the number of nodes detected in the Kubernetes cluster where the application is installed.

For more information, see About Template Functions.

FAQs​

What is KOTS?​

Replicated KOTS is an open source kubectl plugin maintained by Replicated. KOTS provides highly successful installations of Kubernetes applications into diverse environments (including on-prem and air gap environments).

For more information, see About KOTS and kURL.

What do I have to do to enable KOTS installations for my application?​

Enabling KOTS installations requires that the Replicated KOTS entitlement is assigned to your vendor portal team.

Teams with the KOTS entitlement can create KOTS-enabled releases by configuring the custom resources required by KOTS to install the application. For a checklist of the required and optional custom resources for KOTS, see Onboarding with KOTS.

How do KOTS installations work?​

Enterprise users installing an application with KOTS first run the kubectl kots install command to install KOTS in the target cluster. KOTS deploys the admin console, where users can log in to provide their license file, define application-specific configuration values, run preflight checks, and install the application.

For detailed installation steps, see Installing in Existing Clusters.

How do embedded cluster installations work?​

In embedded cluster installations, users run an installation command to provision a cluster on a VM or bare metal server. Embedded clusters can be provisioned with Replicated embedded cluster or with Replicated kURL.

KOTS deploys the admin console, where users can log in to provide their license file, define application-specific configuration values, run preflight checks, and install the application.

For more information, see Using Embedded Cluster (Beta) or Introduction to kURL.

What's the difference between embedded cluster and kURL?​

Replicated embedded cluster is a successor to Replicated kURL. Compared to kURL, the embedded cluster feature offers significantly faster installation, updates, and node joins, a redesigned admin console UI, improved support for multi-node clusters, one-click updates that update the application and the cluster at the same time, and more.

For more information, see Using Embedded Cluster (Beta) or Introduction to kURL.

Can I use my own branding for KOTS installations?​

The KOTS admin console and the download portal support the use of a custom logo. Additionally, software vendors can use custom domains for Replicated services to avoid exposing the default Replicated domains to enterprise users.

For more information, see Customizing the Admin Console and Download Portal and About Custom Domains.

Does KOTS support installations into air gap environments?​

Yes. Software vendors can use KOTS to generate air gap bundles for installation into air gap environments. KOTS also provides customer-specific download portals where air gap bundles and license files can be shared with enterprise users.

Air gap installations are supported for existing and embedded clusters.

Can I deploy Helm charts with KOTS?​

Yes. An application deployed with KOTS can use one or more Helm charts, can include Helm charts as components, and can use more than a single instance of any Helm chart. Each Helm chart deployed by KOTS requires a unique HelmChart custom resource (apiVersion: kots.io/v1beta2) in the release.

For more information, see About Distributing Helm Charts with KOTS.

What are the use cases for installing applications with KOTS versus Helm?​

Helm is a popular package manager for Kubernetes applications. Many enterprise users that have experience with Kubernetes and Helm will expect to be able to install an application with the Helm CLI.

The UI-based installation experience of KOTS can provide an easier installation experience for enterprise users that do not have experience with Kubernetes or Helm. Additionally, KOTS provides support for installations into air gap environments, which is not directly supported by Helm.

Can I support both Helm CLI and KOTS installations for my application?​

Yes. Software vendors that distribute their application as one or more Helm charts can support installations with both the Helm CLI and with KOTS from the same release.

For a tutorial that demonstrates how to add the Bitnami Gitea Helm chart to a release in the Replicated vendor portal and then install with both KOTS and the Helm CLI, see Deploy a Helm Chart with KOTS and Helm CLI.

How does the Replicated SDK work with KOTS?​

The Replicated SDK is a Helm chart that can be installed as a small service alongside an application, or as a standalone component. The SDK can be installed using the Helm CLI or KOTS.

Replicated recommends that all applications include the SDK because it provides access to key functionality not available through KOTS, such as support for sending custom metrics from application instances. When both the SDK and KOTS are installed in a cluster alongside an application, both send instance telemetry to the vendor portal.

For more information, see Installing the Replicated SDK.