Previously, KOTS Admin only allowed you to make config changes to the latest release version downloaded. For some downstream customers with complex change management, the version deployed may actually be older than the latest available version from the Vendor. That meant that customers wanting to make a config change to their deployed software version could be forced to upgrade to a newer version.
As of KOTS v1.40.0, customers can now make changes to the currently deployed application version via the KOTS Admin UI, even if there are newer pending releases upstream. This effort also included improvements to the View and Edit config icons to help clarify which Version History releases can be edited and which can not.
Please note that this new capability is only available via the UI at this time. The CLI command
kots set config only allows for editing the latest release version.
Customers are now able to use their existing Bitbucket Server when configuring a GitOps workflow in KOTS Admin.
Recent releases of KOTS have also added new capabilities to the KOTS CLI.
--cacert flag allows customers to configure other s3 providers with custom and self-signed certificates for KOTS Snapshots backup storage (available as of KOTS v1.40.0).
In order to increase upgrade speed and reduce change risk, kURL will no longer reapply packages if those packages are identical to the prior install.
If reapplying all packages is desirable, for example in troubleshooting scenarios, a new kURL CLI flag,
force-reapply-addons, is available that will force a reinstall of all add-ons, regardless of whether they’ve changed since the last install. (kURL CLI documentation)
kURL allows you to pin your installer spec to the “latest” version of a given add-on, but “latest” doesn’t always mean the newest version of an add-on available. In kURL, the version pinned as “latest” is the version that the kURL project maintainers have the most confidence in, with regards to compatibility and support. In order to make “latest” more explicit, kurl.sh now appends the version number on to the “latest” selection, reducing confusion around which add-on version can be expected. (Read more about “latest” in the kURL Docs)
kURL installer authors can now select a
.x patch version (example: Kubernetes
1.21.x) when selecting their preferred Kubernetes version. By selecting a .x version of a Kubernetes minor release, kURL will resolve to the most recent patch version available for that specified minor, with no need to update the installer spec. This helps support Kubernetes installer authors that want to stay pinned to an older version of Kubernetes, such as 1.19.x, but still want to benefit from the security patches made available for their selected minor version.
In the prior month, kURL has added new support for the following Kubernetes and add-on versions.
Additionally, kURL has added Oracle Linux as a supported operating system.
isSharedFilesystemDisabled configuration option is now available under the Rook add-on for those kURL installer authors that do not require this feature and are looking to reduce resource demands. Selecting this option will disable the rook-ceph shared filesystem, reducing CPU and Memory load by no longer needing to schedule several pods.
Most airgap uploads are disk i/o intense. We’ve observed that on machines with slow disks that are also shared by etcd, Kubernetes operations can become very slow, and may even cause problematic timeouts. We’ve recently added a new kURL Host Preflight that checks for 99th percentile filesystem write latency in the etcd data directory to be less than 20ms (warning when more than 10ms). This check will help to ensure more stable customer installations.
This check runs only on new installs on primary nodes. The kURL documentation includes examples for major cloud providers that are known to be sufficient for disk iops performance.
For new installations with sufficiently fast disks, this preflight should add no more than 1 minute to the overall kURL installation process. If not yet complete, at two minutes this test will complete its benchmarking and do the calculations based on the smaller sample size it was able to run.
As a reminder, Host Preflights are not currently installation blocking. Additionally, warnings and errors can be bypassed with the
preflight-ignore-warnings flags (kURL CLI docs), though we recommend not bypassing these types of resource stability checks.
The kURL project now publishes release notes for each release version: kURL release notes.
For vendors who would like to move towards managing release YAML via git, we’ve now made it easier to discover our CLI Quickstart Guide from your Vendor Web release management workflow.
We’ll be back next month with a brand new release highlights post. Until then, want to learn more about these features and how Replicated makes it easier to manage Day 2 of the application lifecycle? Click here to schedule a demo.