April was another big month for the Replicated Product & Engineering teams! Based on input from vendors like you, we have some exciting new capabilities to share.
Let’s take a look at what’s now available in our application manager (building on the open source “KOTS” project AKA Kubernetes Off-The-Shelf), and our Kubernetes installer (expanding on “kURL”.) Read on for all the juicy details!
We now permit changing licenses from a community license, which can be useful for freemium-style vendors who regularly transition their community users to paying customers – yay!
Vendors who distribute a free version of their software often use Replicated to distribute to their community users. However, managing licenses for community users has been unnecessarily burdensome to date. Vendors can publish a single community license that all community users use, but without a way to change their license, community users have needed to reinstall the application when they progress to become paying customers.
Now, if a community license is in use, a “Change license” button appears on the License page of the Replicated admin console. This allows community users to upload a new license given to them by the vendor after becoming a paying customer. They can keep all their data intact and avoid having to reinstall software.
Vendors shipping a community version of their application can read about community licenses and how to change a community license to learn more.
The version history page previously displayed all versions on a single page. Generally, this was fine, but as the number of versions increased to hundreds and thousands, the page became more difficult to use. This was particularly common for vendors’ QA instances where they often test many new versions.
In application manager v1.68.0, we implemented pagination on the version history page so that a smaller subset of versions is retrieved and displayed at a time. End users can also choose the number of versions displayed per page as of version 1.70.0.
Upgrade the admin console to version 1.68.0 to see the pagination in action.
Many end users perform automated installations of the app manager and the vendor’s application by passing the license file, config values, and more to the kots install command. Previously, there was little information shared about any errors that may have occurred during this process. For example, if a license expired or preflight checks failed, the install command exited silently and with a “zero” status code, giving no indication that the installation failed.
In application manager v1.70.0, we added error messaging and nonzero status codes to clearly indicate that failures have occurred and that the application was not deployed. Because the kots install command now waits for preflights to run before exiting, the `--preflights-wait-duration` flag was also added so that the timeout used when waiting for preflights to complete can be customized as needed.
With this change, vendors whose customers perform automated installations can rest assured that errors during installation will not go unnoticed by their customers.
Last month, we introduced a way for adding labels on Kubernetes installer nodes. Since these settings happen at installation or node addition to an existing cluster, making them visible without having to run any kubectl commands seemed like a significant next step. We expect that this can help folks see the node’s config more clearly, especially since they can view the labels without having to leave the application manager. This can help confirm that things were installed as expected, but it can also have implications later on as well.
For example, suppose a vendor’s app uses these node labels to help control pod placement or segregate portions of the app across different hosts. This could assist when triaging issues more quickly since it is easy to see which nodes have which labels. This prevents the need to search through all the nodes to find where different parts or services of their app reside. There are many other use cases for node labels, so we’re excited to see all the ways this quick-view will be helpful. Let us know how you use your node labels!
Not all enterprises have an existing Kubernetes cluster, or they may prefer that the vendor installs the app instance into its own new cluster, for example as part of a proof-of-value. If a cluster becomes stressed and resource starved, issues could arise – especially if logs cannot be collected from the cluster. To help combat this challenge, these Kubernetes settings can now be specified in the Kubernetes installer with the kubeadm add-on.
For kubereserved, things are handled dynamically. These settings can help ensure that even when resources are constrained, Kubernetes clusters will be resilient and have the resources required to run so the user or vendor can access the node.
Although not dynamic, allowing access to the eviction threshold and system reserved settings also gives more flexibility if needed. Folks should consider the recommendations at the links above before using these settings. Configuring these at time-of-install helps enterprises benefit from the lessons learned from the vendor if and when the reservations were ever needed in production. It also helps ensure that vendors can better guarantee required, critical resources so they can best support their customers who may not be intimately familiar with Kubernetes.
Our team has been hard at work over the last few months to consolidate and clarify the Replicated documentation for vendors and their enterprise customers, and the improvements keep coming.
We added a new topic that lists the step-by-step workflow for how to distribute your application with Replicated. Software vendors onboarding with Replicated can use this topic as a map to learn what they have to do, and easily find the docs they need during each step.
Other recent updates include improvements to the Connecting to an Image Registry topic. This topic provides additional insight into how the app manager uses the Replicated proxy service to access private images on an external registry. We also added a new page in this section that describes security for the Replicated private registry to help answer common questions.
You can also find new content on the site about how to create a support bundle using the CLI. If an enterprise end-user can't access the admin console, they can still generate a support bundle using the CLI, and this procedure helps them understand how.
Finally, a set of new topics in the Team Management section provide information on how to configure role-based access control for your vendor portal team. This includes a step-by-step procedure, examples, and the complete list of RBAC resource names.
See? We told you it was a busy month at Replicated! Want to learn more about these new features and what Replicated does to help vendors and customers install and manage modern apps on-prem?
We would love to show you -- click here to schedule a demo.