CODEWITHSUNDEEP
kuberneteskubernetes-helm
caarlos0
caarlos0

Reputation: 20633

Migrate from plain kubernetes to helm without downtime

I have several apps deployed into a kubernetes cluster. I have the receipts and etc as yaml files and I deploy and apply everything with kubectl.

I decided to migrate to helm because of its features and to avoid replicating code between dev and prod (I could use variables and etc).

The problem is: my services are AWS ELBs, and, as far as I found out, to migrate something already deployed with kubectl to helm, I need to delete it and install it again with helm - which will destroy and re-create my ELBs, so I'll need to change DNS records, etc. On top of all that, I'll have downtime - which is not really desired.

I thought about renaming the old-things and create the new things with the right name, keeping a common label to use in the service - so I could create the new one, change the DNS records, and then delete the old stuff - but apparently renames are not allowed by kubernetes.

Another strategy would be to launch a new cluster - which I don't really want to do.

Are there any other alternatives?

Upvotes: 2

Views: 1855

Answers (1)

Radek 'Goblin' Pieczonka
Radek 'Goblin' Pieczonka

Reputation: 22882

A properly designed chart should namespace deployed resources by .Release.Name. That way you can deploy chart side by side with existing software you have. It's likely that you will be able create large part of your stack in parallel and then update your off-chart services to point to on-chart pods, that way you can have both on-chart and off-chart services defined and working with two distinct ELBs and if you want to get rid of off-charts, just edit DNS and let it propagate, then, after a day, week or month you can scrap it and be left with chart only.

Upvotes: 1

Related Questions