Trying to deploy deploy kotsadm via a Helm Chart (kots-helm)

Troubleshooting
1

Hi,

I work for Spectro Cloud and I’m trying to make it easy for Replicated customers to add kotsadm to their cluster definitions (in our platform), so that they can automate all (or part) of the steps to get their KOTS applications deployed onto K8s clusters that our platform provisions. Our platform can use K8s manifests and Helm charts to deploy content.

I’ve tried using kots-helm to get this working (with a few tweaks, like setting the version to v1.70.1), but I keep running into the same two issues:

  1. The kotsadm admin console deployed from this chart will somehow see other Helm charts in the cluster as apps that it can manage
  2. When I add a new application by uploading the KOTS license for it, after going through the “Pulling upstream”, “Creating base”, “Creating midstreams” and “Creating downstream” steps, the UI changes to a spinning circle forever and it never gets to the Config page for the application.

When I deploy kotsadm using the kubectl plugin into another namespace on the same cluster, everything works normally: I don’t see the other helm charts as pseudo-apps and I can deploy a new app just fine.

I’ve compared the resources between the two namespace, but apart from additional labels on objects (caused by the Helm deployment), they look pretty much identical.

Any idea what’s happening and how we can get this to work properly when kotsadm is deployed via a Helm chart?

2

Hey Kevin,

That helm chart that you’ve found is part of a new alpha feature we are shipping. It currently runs in that unexpected mode because of this env var: kots-helm/kotsadm-deployment.yaml at 0.2.1 · replicatedhq/kots-helm · GitHub

If you set that to “false” (or remove) it should return to the standard kotsadm application.

This isn’t currently configurable though. We should make that a values.yaml field (defaulting to true), to make this easier for you. If you want to try this, you’ll probably get the standard experience again.

3

Ahhhh, that indeed fixes it :slight_smile:
I removed the env var and normal behavior returned again, with the app install no longer getting stuck.

Thanks!