In an earlier post, we looked at how to convert OpenShift templates to helm charts. In this post, we’ll see how to live migrate running production customer workloads from being managed by OpenShift templates to Helm charts.
Helm is not designed to be used as a target of migration from another deployment-management system like OCP templates. Helm assumes that when Helm charts are installed, they will create afresh all Kubernetes objects included in the chart.
In our case, many Kubernetes objects, that are now packaged as Helm charts, were already created in the OCP cluster using OCP templates. When you install a chart, it simply tries to create all objects & fails because objects by the same name already exist in the cluster.
This document explores a workaround for this issue.
Helm uses a label & 2 annotations to keep track of which objects in the cluster are managed by Helm & which Helm release created them. Specifically, every Helm-managed object has:
Try Installing the Helm Chart
Now, if you try to install this chart, you get an error:
helm install my-release my-chart
Error: INSTALLATION FAILED:
rendered manifests contain a resource that already exists.
Unable to continue with install:
ConfigMap "my-cm" in namespace "my-ns" exists and cannot be imported into the current release:
invalid ownership metadata;
label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm";
annotation validation error: missing key "meta.helm.sh/release-name": must be set to "my-release";
annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "my-ns"
Add Label & Annotations
The last 3 lines of the error above, tell us exactly what we need to do to make our ConfigMap adoptable by Helm. So let’s do that:
$ kubectl label cm my-cm app.kubernetes.io/managed-by=Helm
$ kubectl annotate cm my-cm meta.helm.sh/release-name=my-release
$ kubectl annotate cm my-cm meta.helm.sh/release-namespace=helm-test
At this point, even though the required labels & annotations exist on the object, it’s not being managed by Helm at all because there exists no Helm release in the cluster that can adopt this ConfigMap resource.
Create an Empty Helm Release
So the next step is to create an “empty” Helm release. It has to be empty in the sense that the chart cannot contain any objects. If it does, we will get the same error as before.
$ helm upgrade my-release my-chart
Release "my-release" has been upgraded. Happy Helming!
TEST SUITE: None
$ kubectl get cm my-cm -o yaml
As the objects are now managed by Helm, helm uninstall will delete them as well:
$ helm uninstall my-release
release "my-release" uninstalled
$ kubectl get cm my-cm
Error from server (NotFound): configmaps "my-cm" not found
This article was quite an elaborate walkthrough of how you can accomplish safe & zero-downtime migration of workloads managed by OpenShift templates to Helm charts. Head on over to part 3 of this blog series to learn how to migrate DeploymentConfigs to Deployments & Routes to Ingresses.
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.