0

We have recently moved from a pure kubernetes deployment to a helm chart deployment for one of our apps.

I'm trying to find a way to migrate a cluster that is currently running the old deployment to use the new helm chart.

I'm having an issue because the helm chart won't cleanly install when there are existing resources on the cluster that are the same as what it is installing. For example I have a service that looks like this

$ kubectl get service elasticsearch -oyaml
apiVersion: v1
kind: Service
metadata:
  annotations:
  kubectl.kubernetes.io/last-applied-configuration: |
  {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"creationTimestamp":"2018-01-26T01:39:20Z","labels":{"app":"elasticsearch"},"name":"elasticsearch","namespace":"default","resourceVersion":"18650241","selfLink":"/api/v1/namespaces/default/services/elasticsearch","uid":"bac30dfa-0239-11e8-b7a8-0015b2aa5ea6"},"spec":{"externalName":"100.64.0.100","sessionAffinity":"None","type":"ExternalName"},"status":{"loadBalancer":{}}}
  creationTimestamp: 2018-10-04T21:22:06Z
  labels:
    app: elasticsearch
    name: elasticsearch
    namespace: default
    resourceVersion: "31430"
  selfLink: /api/v1/namespaces/default/services/elasticsearch
  uid: 8b82157e-c81b-11e8-a0d8-94c69116956d
spec:
  externalName: 127.0.0.1
  sessionAffinity: None
  type: ExternalName
status:
  loadBalancer: {}

and my helm chart has a template that looks like this

$ cat elasticsearch.yaml 
apiVersion: v1
kind: Service
metadata:
  labels:
    app: elasticsearch
  name: elasticsearch
spec:
  type: ExternalName
  externalName: 127.0.0.1
status:
  load_balancer: {}

If I try to apply my chart using

$ helm install /path/to/chart --name=chart-name

It will fail with this error

Error: release chart-name failed: services "elasticsearch" already exists

To make matters worse even thought thee install fails the chart will appear in helm with the status FAILED. If I then delete the chart it will remove some of the running deployments.

I have two questions.

1) How can I install my chart and have it take control over the exisitng service.

2) Is it possible to remove a failed chart from helm without deleting the running deployments?

rvabdn
  • 235
  • 2
  • 11
  • Is it possible for you to create new namespace for installing helm chart? This way it will not interfere with the existing objects. – VAS Oct 05 '18 at 16:17

1 Answers1

-1

You shouldn't have that problem, if you deploy your Helm charts to another namespace and after ensuring that everything works as expected, redirect the clients traffic to that namespace.

Helm uses ConfigMaps to store information about installed releases, so probably there might be a way to install partial chart and then change ConfigMap by adding missed resources existing in that namespace and change the helm chart to include those resources in the chart templates at the same time.

Another way I can imagine, it's deploying a complete chart to another namespace and then change namespace in the ConfigMap(s) that tiller creates during chart installation.

Both ways are hacky and require precise manipulations and eventually you may end up with destroyed environment if you made a mistake, so it's better to try it with test environment and simple charts first.

To make Helm forget about particular release, you can delete corresponding ConfigMap from the Tiller namespace.

You can check the content of existing Helm ConfigMaps using the following command:

kubectl get configmap -n <tiller-namespace-name> -l "OWNER=TILLER"

Also, you may find this article useful:

VAS
  • 370
  • 1
  • 9