KOTS provides a dynamic form to vendors that allow their customers to customize the configuration of the application both in the installation process and post-deployment. From an outpouring of vendor requests, we’ve added support for collecting multiple repeatable items. This feature helps vendors collect multiple, repeatable items for duplicating or extending application resources. This is helpful, for example, when opening up several custom network ports to the application’s components or when additional configuration options may be desired.
Support for retrieving filename data is also available as part of the File configuration item. This can be useful when a vendor’s app must act on several filenames, such as security certificate names or other custom files, that may be required for the application.
Lastly, customers can now easily delete files that may have been erroneously uploaded while on the configuration screen as seen in the screenshot below. This gap was cumbersome before as, once uploaded, files could only be replaced but not removed. Our team will continue to expand and improve config items to better serve our vendor community and we thank you for your ongoing feedback!
For vendors that use Helm charts, we’re excited to share a new beta feature is available that adds a new Helm rendering workflow with more robust interoperability for Helm hooks and hook weights. This new workflow supports the following hooks: pre-install, post-install, pre-upgrade, post-upgrade. This feature is currently only available as a beta and should not be used in production. This feature can only be enabled for new applications or for new Helm charts in existing applications in the Vendor Portal.
Our team would love for you to try out this beta feature and are excited to receive all of your feedback! Please contact your Replicated account team so they can enable the feature for your organization. Once enabled, additional information on how to use this feature can be found here.
Some vendors had expressed concerns over the usage of MinIO in KOTS after MinIO recently adopted the GNU GPLv3 license. As a result, we’ve taken the first of several steps to allow vendors to remove the use of MinIO as the object store for KOTS application archives and support bundles.
To opt-in to this feature as part of a new install or an upgrade, here are the details:
--with-minio=falseonto your existing KOTS CLI Admin Console upgrade command. When this change is executed on upgrade, KOTS will migrate the app archive and support bundle data in the MinIO standalone object store instance to a new blob/filesystem that is part of the new KOTS Admin Console statefulset. Once confirmed as successfully migrated, KOTS will then remove the MinIO instance automatically.
(kURL provided cluster installation)
“disableS3: true”in the installer YAML for the KOTS add-on in your kURL upgrade. Executing this change on an embedded cluster will migrate the app archive and support bundle data out of the installer-specified standalone object store instance (Rook/Ceph or MinIO) into a new blob/filesystem that is part of the new KOTS Admin Console statefulset. Given the MinIO kURL add-on can be used for other purposes, this upgrade will not automatically clean up the MinIO instance. With embedded cluster installations, KOTS still requires an object store to be available for default Snapshot storage and the kURL registry add-on.
While usage of this opt-in feature reduces the KOTS dependency on an object store for some use cases, a kURL-based cluster with the KOTS add-on still requires an object store (either MinIO or Rook/Ceph) at this time.
Before proceeding with this opt-in at install or upgrade, our team recommends taking a full snapshot backup of the resources in the namespace that KOTS was installed prior to upgrading. For additional details or questions, please reach out to our Customer Success Team.
You may recall in our May Product Updates blog that we announced the new K8s .x patch version option to help ease path upkeep. We’re excited to share that now these .x patch options are available for all add-ons conforming to semantic versioning, not just Kubernetes. Using this notation (e.g., Longhorn 1.1.x), add-ons will resolve to the latest patch version for the specified major and minor versions. Vendors are highly encouraged to use this feature, as this is a great way to ensure you are using tested and predictable versions while continuing to receive bug fixes and security patches.
We’ve been busy developing the host preflight capabilities to make them more useful for vendors. Host preflights run before Kubernetes and other add-ons are installed and are meant to verify that the hosts are sufficiently configured to support the specified add-ons. Host preflight results are now stored and tracked in the directory /var/lib/kurl/host-preflights. When a support bundle is created, kURL host preflights will be included in that support bundle for more detailed troubleshooting.
The Longhorn add-on is now fully production-ready! Vendors that are using Rook/Ceph in their kURL installers and have expressed interest in using an alternative CSI driver can now use kURL to deploy a second Kubernetes cluster that leverages Longhorn and MinIO instead of Rook/Ceph. They can then use KOTS Snapshots to migrate workloads to the new cluster in order to remove their dependency on Rook. In fact, this method works to change any of the CRI, CNI, and CSI providers. Please contact your technical account manager if you would like to leverage this migration path. We are currently working on functionality to migrate clusters in-place from Rook/Ceph to Longhorn and MinIO by merely changing the kURL spec and rerunning the installer. Look out for that in the near future!
That’s it for this month’s release highlights! We would love to help you learn more about these new features and what Replicated does to help vendors and customers install and manage modern apps on-prem — Click here to schedule a demo.