2024 is spinning up just as fast as an OpenShift cluster in our Compatibility Matrix (for those who haven’t tried it out yet, that’s really fast!). Check out the recently shipped features and release highlights for January 2024 below.
We released our first CVE-free version of KOTS! (v1.104.7). By using Chainguard tooling to build our images, we’re able to resolve more CVEs than was previously possible and ensure that fewer CVEs are present moving forward.
You can now update the TTL for a running cluster. If someone creates a CMX cluster and deploys their app but discovers a bug, they can now extend the cluster’s TTL to investigate before the cluster expires: [.pre] replicated cluster update ttl CLUSTER_ID --ttl NEW_TTL [.pre]
You can now remove a cluster by name or tag. Previously, the Replicated CLI could only remove clusters by ID (or --all). Now, you can remove clusters by name (which are human-readable and easier to use) or by tag. Use the [.pre] --dry-run [.pre] flag first to see which clusters will be deleted. For example, [.pre]replicated cluster rm --name fervent_wilson --name beautiful_mclaren and replicated cluster rm --tag drink=water [.pre]
You can now specify tags on cluster creation in the vendor portal and when using GitHub actions. You no longer need to use the CLI to specify tags when creating a cluster. You can do it from the vendor portal UI and from a GitHub action, too. For more information on the GitHub action, see the create-cluster README.
Compatibility Matrix now includes:
- AKS, GKE, EKS and K3s support for Kubernetes 1.28
- KiND support for Kubernetes 1.29
- Support for OpenShift 4.14
Additional support changes:
-Amazon removed support for deploying 1.23 EKS clusters, so we've also removed it from the Compatibility Matrix.
We added information on how application releases are created and modified. Previously, vendors did not have visibility into who created or modified a given release. With this change, vendors looking at a release can see who created and modified a release and when, the method used (API, CLI, or UI), as well as who promoted that release and when.
We added information on how customer licenses are created. Previously vendors did not have visibility into who created a license and how. With this change, vendors can now see who created the customer license and when, as well as the method used (API, CLI or UI).
Vendors can now see when a given customer last downloaded the application from the download portal, and which version.
Relevant instance insights data is now displayed alongside a support bundle. With this improvement, support bundles displayed in the vendor portal include a new Bundle Details overview section containing helpful links to other data points associated with the instance and support escalation. New Bundle State and Instance Information telemetry overviews share point-in-time telemetry on things like app version, KOTS version, K8s version, and more, to help provide context when troubleshooting a customer issue.
Vendors can now add their own “friendly” custom name and tags to a given instance. By default, instances are labeled with a random alphanumeric instance ID. Now, vendors can give these instances a user-friendly name and add vendor-defined custom tags to a given instance, similar to the instance tagging functionality of cloud providers like AWS.
Vendors can now upload multiple support bundles at a time. When opening a support case, vendors often have more than one bundle to upload, like when there are one or more host collector bundles plus an in-cluster bundle. Now vendors can select multiple bundles at once to upload, and find them all linked in the corresponding Github issue.
We added support for Kubernetes 1.29 and latest patch versions, as well as other new add-on versions (kURL v2024.01.02-0). Kubernetes 1.29 was released in mid-December. In keeping with our one-month SLA, kURL introduced support for Kuberntes 1.29, as well as the latest patch versions for other supported minor versions (1.28.5, 1.28.4, 1.27.9, 1.27.8, 1.26.12, and 1.26.11). We also added support for OpenEBS 3.10.0, Flannel 0.24.0, Goldpinger 3.9.0-6.1.2, and EKCO 0.28.3.
We added information about managing resources for Helm charts deployed with KOTS. The Conditionally Including or Excluding Resources and Orchestrating Resource Deployment topics in the KOTS documentation now include content that applies to Helm charts (in addition to the existing content for standard manifests). As part of this change, these topics were also rewritten to make the content more complete and easier to follow. These improvements allow vendors to go to one location in the docs to find info about working with resources and objects for all types of applications deployed with KOTS.
We improved overview content for KOTS template functions and custom resources. To help vendors distributing their app with KOTS, the overview pages for KOTS template functions and custom resources are updated to provide better definitions of each and to more fully explain their use cases. For template functions, the improvements also include more clearly listing the types of files where KOTS template functions can be used (as in, not in Helm charts). These improvements were made because some vendors were getting confused about how and when to use KOTS template functions.
Want to learn more about what Replicated does to help vendors distribute software to self-hosted environments? We would love to show you -- click here to schedule a demo.