https://github.com/bmatcuk/helm-take-ownership
Transfer ownership of a kubernetes release to helm
https://github.com/bmatcuk/helm-take-ownership
Last synced: 8 months ago
JSON representation
Transfer ownership of a kubernetes release to helm
- Host: GitHub
- URL: https://github.com/bmatcuk/helm-take-ownership
- Owner: bmatcuk
- License: mit
- Created: 2018-01-23T17:41:33.000Z (over 8 years ago)
- Default Branch: master
- Last Pushed: 2019-11-28T13:32:11.000Z (over 6 years ago)
- Last Synced: 2025-04-01T22:10:25.065Z (about 1 year ago)
- Language: Go
- Size: 32.2 KB
- Stars: 11
- Watchers: 2
- Forks: 5
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# [helm-take-ownership]
Transfer ownership of existing [kubernetes] release to [helm] v2.
Let's say you have an existing [kubernetes] deployment that you want to migrate
to [helm]. [helm] currently doesn't have any functionality to migrate owneship
of those existing resources to itself. This plugin attempts to solve that
problem.
## How Does it Work?
[helm] v2 records information about a release in a configmap. When you try to
upgrade the release, [helm] uses this information to figure out what to do.
This plugin simply downloads the existing resource configurations, creates a
[helm] "Chart" with this information, and stores it in a configmap in the
format [helm] is expecting. You can then use [helm] to "upgrade" this release
using a Chart that you have built.
## How Does This Differ From Chartify?
Think of [helm-take-ownership] as a companion to [chartify]. [chartify] creates
a Chart from existing resources, but it doesn't migrate those resources to
[helm] control. [helm-take-ownership] can migrate those resources to [helm]'s
control. So, you migrate your resources with [helm-take-ownership], and then use
[chartify] to create a Chart from those resources. In the future, if you need
to make any changes to your Chart, you can use [helm] to upgrade the release
and everything should (hopefully) work beautifully, as if you used [helm] all
along.
## Installation
[helm-take-ownership] is a [helm] plugin. Installation is simple:
```bash
helm plugin install git@github.com:bmatcuk/helm-take-ownership.git
```
## Usage
[helm-take-ownership]'s operation is fairly simple. You tell it what resources
to include in the [helm] release using command line flags, plus any additional
[kubernetes] connection options (namespace, context, etc) and a name for the
release. For example:
```bash
helm own --deploy my-deployment --svc my-service -n stg my-release
```
The above example would instruct [helm-take-ownership] to associate a
deployment called `my-deployment` and a service called `my-service` in the
`stg` namespace to a [helm] release called `my-release`.
The naming of flags for [kubernetes] resources is the same as with `kubectl
get` (`--deployment`, `--service`, etc), including shorthands (`--deploy`,
`--svc`, etc). [kubernetes] connection options (such as namespace, context,
etc) are prepended with `k8s` (ex: `--k8s-namespace`, `--k8s-context`, etc).
If no [kubernetes] connection options are passed, it will use your default
configuration, the same way `kubectl` will.
Full usage is available from the command line:
```bash
helm own --help
```
## Some Notes
I built this tool for my own use. Currently, there are two things this plugin
will do that you might not want:
1. It will remove any `nodePort` values from services. In my setup, I'm relying
on [kubernetes] giving me a random nodePort. When [helm-take-ownership]
downloads the resources from [kubernetes], the random nodePort is in the
data. If I then try to use [helm] to upgrade this release with a service
definition that does not define a nodePort, [helm] removes the nodePort
causing [kubernetes] to give me another port. This is undesirable.
2. It will remove any `selector` from a deployment spec. Similar to point #1:
I'm relying on [kubernetes] giving me a default value here. When I do a
[helm] upgrade, if I have the selector, [helm] removes it and [kubernetes]
recreates it causing a new replicaset to be created. The existing replicaset
is "lost" in the transition; orphaned and unmanaged.
I think, in the future, it might make sense to have some sort of "edit" option
that would allow a user to edit the Chart before it is installed to take care
of these very specific use cases.
## What about helm v3?
I don't use [kubernetes] or [helm] much in my daily life anymore, so this
project is semi-sunset. [helm] v2 is still supported and can be run alongside
v3. You could migrate your existing deployments to [helm] v2, and then migrate
from v2 to v3.
## Development
[helm-take-ownership] is written in [go]
```bash
# Grab latest code
git clone git@github.com:bmatcuk/helm-take-ownership.git
cd helm-take-ownership
# Install plugin locally
# helm plugin remove own
helm plugin install $(pwd)
# Build locally
make
```
If you'd like to contribute to [helm-take-ownership], submit a pull request.
## TODO
- [ ] command line switch to switch between [helm] configmaps and secrets
- [ ] command line switch to set the [helm] namespace (defaults to kube-system)
- [ ] allow a user to edit the Chart before installing it
[chartify]: https://github.com/appscode/chartify
[go]: https://golang.org/
[helm-take-ownership]: https://github.com/bmatcuk/helm-take-ownership
[helm]: https://helm.sh/
[kubernetes]: https://kubernetes.io/