WIP: [kots]: use Helm for the Installer job #8490
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This changes the KOTS Installer job to use Helm for the installation of Gitpod rather than
kubectl apply
. IMPORTANT this still uses the Gitpod Installer for generating the Kubernetes YAML and is not in any way us going back to using Helm for installing Gitpod.One thing we have to be aware of with KOTS is that we control what resources third-parties/customers have installed on their clusters under the umbrella of "Gitpod". It is key that we should remove resources when they've been finished with.
An example of this:
If we use
kubectl apply
, there is no history and any resources that are no longer required (eg, themysql-0
statefulset) remain in the cluster. As they are no longer being used, they become orphaned from Gitpod installation YAML. More importantly, any persistent volume claims remain and the costs therein.By switching to
helm upgrade
, we hook into Helm's history. Any resources that are removed between the previous and current installations are deleted.Helm can be thought of as fulfilling two jobs:
As we are still using the Installer to generate the YAML (ie, part 1), we're only using Helm for part 2.
The alternative way of doing this is to implement our own version of this. In reality, we'd likely end up building something very similar to how Helm works. By doing it this way, we reduce the time involved and benefit from all their testing.
How to test
Deploy via KOTS:
Release Notes
Documentation