NOTE: The most important part of this plugin, "chartification" that turns a set of Kubernetes manifests or a kustomization into a temporary chart, is extracted to https://github.com/variantdev/chartify and maintained there. PTAL!
No more "Kustomize vs Helm".
helm-x
makes helm
better integrate with vanilla Kubernetes manifests, kustomize, and manual sidecar injections.
With helm-x
, you can install and sidecar-inject helm charts, manifests, kustomize apps in the same way.
Installing your kustomize app as a helm chart is as easy as running:
$ helm x apply myapp examples/kustomize --version 1.2.3 \
-f examples/kustomize/values.yaml
Then you can even run a helm test:
$ helm test myapp
RUNNING: myapp-test
PASSED: myapp-test
Show diff before further upgrade:
$ helm x diff myapp examples/kustomize --version 1.2.4 \
-f examples/kustomize/values.2.yaml
Add an adhoc dependency:
$ helm x diff myapp examples/kustomize --version 1.2.4 \
-f examples/kustomize/values.2.yaml \
--adhoc-dependency $ALIAS=stable/mysql:$CHART_VER
Apply JSON patches or Strategic-Merge patches to K8s resources being helm install
ed:
# See examples/hpa.strategicmergepatch.yaml and examples/hpa.jsonpatch.yaml for examples
$ helm x diff myapp examples/kustomize --version 1.2.4 \
-f examples/kustomize/values.2.yaml \
--adhoc-dependency $ALIAS=stable/mysql:$CHART_VER \
--strategic-merge-patch path/to/strategicmerge.patch.yaml \
--jsonpatch path/to/json.patch.yaml
Check out the examples in the examples directory!
It keeps all the good things of helm
as an extendable package manager.
That is, helm x apply
is able to automatically remove resources that have gone from the desired state, without any additions like --prune
and --prune-whitelist
of kubectl apply
.
Also, you can leverage useful helm
commands like below, even though your app is written with a tool like kustomize
:
helm diff
to diff your apphelm test
to test your apphelm list
to list all the apps running on your cluster, written with whatever tool not onlyhelm
.helm package
to package your app into a helm chart(even if it was originally written as akustomization
)helm s3
to stored packaged apps into AWS S3 as a chart registry(even if your app is written withkustomize
)helm tiller
to go tillerless!
If you're familiar with helm
, what makes helm-x
unique is it runs helm upgrade --install
to install your apps described as:
- kustomizations
- directories containing manifests
- local and remote helm charts.
Install or upgrade the helm release from the directory or the chart specified.
Under the hood, this generates Kubernetes manifests from (1)directory containing manifests/kustomization/local helm chart or (2)remote helm chart, then inject sidecars, and finally install the result as a Helm release
When DIR_OR_CHART is a local helm chart, this copies it into a temporary directory, renders all the templates into manifests by running "helm template", and then run injectors to update manifests, and install the temporary chart by running "helm upgrade --install".
It's better than installing it with "kubectl apply -f", as you can leverage various helm sub-commands like "helm test" if you included tests in the "templates/tests" directory of the chart. It's also better in regard to security and reproducibility, as creating a helm release allows helm to detect Kubernetes resources removed from the desired state but still exist in the cluster, and automatically delete unnecessary resources.
When DIR_OR_CHART is a local directory containing Kubernetes manifests, this copies all the manifests into a temporary directory, and turns it into a local Helm chart by generating a Chart.yaml whose version and appVersion are set to the value of the --version flag.
When DIR_OR_CHART contains kustomization.yaml, this runs "kustomize build" to generate manifests, and then run injectors to update manifests, and install the temporary chart by running "helm upgrade --install".
Usage:
helm-x apply [RELEASE] [DIR_OR_CHART] [flags]
Flags:
--adhoc-dependency stringArray Adhoc dependencies to be added to the temporary local helm chart being installed. Syntax: ALIAS=REPO/CHART:VERSION e.g. mydb=stable/mysql:1.2.3
--adopt strings adopt existing k8s resources before apply
--debug enable verbose output
--dry-run simulate an upgrade
-h, --help help for apply
--inject 'istioctl kube-inject -f FILE' injector to use (must be pre-installed) and flags to be passed in the syntax of 'istioctl kube-inject -f FILE'. "FILE" is replaced with the Kubernetes manifest file being injected
--injector --inject "CMD ARG1 ARG2" DEPRECATED: Use --inject "CMD ARG1 ARG2" instead. injector to use (must be pre-installed) and flags to be passed in the syntax of `'CMD SUBCMD,FLAG1=VAL1,FLAG2=VAL2'`. Flags should be without leading "--" (can specify multiple). "FILE" in values are replaced with the Kubernetes manifest file being injected. Example: "--injector 'istioctl kube-inject f=FILE,injectConfigFile=inject-config.yaml,meshConfigFile=mesh.config.yaml"
--install install the release if missing (default true)
--json-patch stringArray Kustomize JSON Patch file to be applied to the rendered K8s manifests. Allows customizing your chart without forking or updating
--kubecontext string name of the kubeconfig context to use
--namespace string namespace to install the release into (only used if --install is set). Defaults to the current kube config namespace
--set stringArray set values on the command line (can specify multiple)
--strategic-merge-patch stringArray Kustomize Strategic Merge Patch file to be applied to the rendered K8s manifests. Allows customizing your chart without forking or updating
--tiller-namespace string namespace to in which release configmap/secret objects reside (default "kube-system")
--timeout int time in seconds to wait for any individual Kubernetes operation (like Jobs for hooks) (default 300)
--tls enable TLS for request
--tls-cert string path to TLS certificate file (default: $HELM_HOME/cert.pem)
--tls-key string path to TLS key file (default: $HELM_HOME/key.pem)
-f, --values stringArray specify values in a YAML file or a URL (can specify multiple)
--version string specify the exact chart version to use. If this is not specified, the latest version is used
Show a diff explaining what helm x apply
would change.
Under the hood, this generates Kubernetes manifests from (1)directory containing manifests/kustomization/local helm chart or (2)remote helm chart, then inject sidecars, and finally print the resulting manifests
When DIR_OR_CHART is a local helm chart, this copies it into a temporary directory, renders all the templates into manifests by running "helm template", and then run injectors to update manifests, and prints the results.
When DIR_OR_CHART is a local directory containing Kubernetes manifests, this copies all the manifests into a temporary directory, and turns it into a local Helm chart by generating a Chart.yaml whose version and appVersion are set to the value of the --version flag.
When DIR_OR_CHART contains kustomization.yaml, this runs "kustomize build" to generate manifests, and then run injectors to update manifests, and prints the results.
Usage:
helm-x diff [RELEASE] [DIR_OR_CHART] [flags]
Flags:
--adhoc-dependency stringArray Adhoc dependencies to be added to the temporary local helm chart being installed. Syntax: ALIAS=REPO/CHART:VERSION e.g. mydb=stable/mysql:1.2.3
--debug enable verbose output
-h, --help help for diff
--inject 'istioctl kube-inject -f FILE' injector to use (must be pre-installed) and flags to be passed in the syntax of 'istioctl kube-inject -f FILE'. "FILE" is replaced with the Kubernetes manifest file being injected
--injector --inject "CMD ARG1 ARG2" DEPRECATED: Use --inject "CMD ARG1 ARG2" instead. injector to use (must be pre-installed) and flags to be passed in the syntax of `'CMD SUBCMD,FLAG1=VAL1,FLAG2=VAL2'`. Flags should be without leading "--" (can specify multiple). "FILE" in values are replaced with the Kubernetes manifest file being injected. Example: "--injector 'istioctl kube-inject f=FILE,injectConfigFile=inject-config.yaml,meshConfigFile=mesh.config.yaml"
--json-patch stringArray Kustomize JSON Patch file to be applied to the rendered K8s manifests. Allows customizing your chart without forking or updating
--kubecontext string name of the kubeconfig context to use
--namespace string namespace to install the release into (only used if --install is set). Defaults to the current kube config namespace
--set stringArray set values on the command line (can specify multiple)
--strategic-merge-patch stringArray Kustomize Strategic Merge Patch file to be applied to the rendered K8s manifests. Allows customizing your chart without forking or updating
--tiller-namespace string namespace to in which release configmap/secret objects reside (default "kube-system")
--tls enable TLS for request
--tls-cert string path to TLS certificate file (default: $HELM_HOME/cert.pem)
--tls-key string path to TLS key file (default: $HELM_HOME/key.pem)
-f, --values stringArray specify values in a YAML file or a URL (can specify multiple)
--version string specify the exact chart version to use. If this is not specified, the latest version is used
Print Kubernetes manifests that would be generated by helm x apply
Under the hood, this generates Kubernetes manifests from (1)directory containing manifests/kustomization/local helm chart or (2)remote helm chart, then inject sidecars, and finally print the resulting manifests
When DIR_OR_CHART is a local helm chart, this copies it into a temporary directory, renders all the templates into manifests by running "helm template", and then run injectors to update manifests, and prints the results.
When DIR_OR_CHART is a local directory containing Kubernetes manifests, this copies all the manifests into a temporary directory, and turns it into a local Helm chart by generating a Chart.yaml whose version and appVersion are set to the value of the --version flag.
When DIR_OR_CHART contains kustomization.yaml, this runs "kustomize build" to generate manifests, and then run injectors to update manifests, and prints the results.
Usage:
helm-x template [DIR_OR_CHART] [flags]
Flags:
--adhoc-dependency stringArray Adhoc dependencies to be added to the temporary local helm chart being installed. Syntax: ALIAS=REPO/CHART:VERSION e.g. mydb=stable/mysql:1.2.3
--as-release helm [upgrade|install] turn the result into a proper helm release, by removing hooks from the manifest, and including a helm release configmap/secret that should otherwise created by helm [upgrade|install]
--debug enable verbose output
-h, --help help for template
--inject 'istioctl kube-inject -f FILE' injector to use (must be pre-installed) and flags to be passed in the syntax of 'istioctl kube-inject -f FILE'. "FILE" is replaced with the Kubernetes manifest file being injected
--injector --inject "CMD ARG1 ARG2" DEPRECATED: Use --inject "CMD ARG1 ARG2" instead. injector to use (must be pre-installed) and flags to be passed in the syntax of `'CMD SUBCMD,FLAG1=VAL1,FLAG2=VAL2'`. Flags should be without leading "--" (can specify multiple). "FILE" in values are replaced with the Kubernetes manifest file being injected. Example: "--injector 'istioctl kube-inject f=FILE,injectConfigFile=inject-config.yaml,meshConfigFile=mesh.config.yaml"
--json-patch stringArray Kustomize JSON Patch file to be applied to the rendered K8s manifests. Allows customizing your chart without forking or updating
--kubecontext string name of the kubeconfig context to use
--name string release name (default "release-name") (default "release-name")
--namespace string namespace to install the release into (only used if --install is set). Defaults to the current kube config namespace
--set stringArray set values on the command line (can specify multiple)
--strategic-merge-patch stringArray Kustomize Strategic Merge Patch file to be applied to the rendered K8s manifests. Allows customizing your chart without forking or updating
--tiller-namespace string namespace to in which release configmap/secret objects reside (default "kube-system")
--tiller-namsepace string namespace in which release confgimap/secret objects reside (default "kube-system")
-f, --values stringArray specify values in a YAML file or a URL (can specify multiple)
--version string specify the exact chart version to use. If this is not specified, the latest version is used
Adopt a set of existing K8s resources as if they are installed originally as a Helm chart.
Adopt the existing kubernetes resources as a helm release
RESOURCES are represented as a whitespace-separated list of kind/name, like:
configmap/foo.v1 secret/bar deployment/myapp
So that the full command looks like:
helm x adopt myrelease configmap/foo.v1 secret/bar deployment/myapp
Usage:
helm-x adopt [RELEASE] [RESOURCES]... [flags]
Flags:
-h, --help help for adopt
--kubecontext string the kubeconfig context to use
--namespace string The namespace in which the resources to be adopted reside
--tiller-namespace string the tiller namespaceto use (default "kube-system")
--tls enable TLS for request
--tls-cert string path to TLS certificate file (default: $HELM_HOME/cert.pem)
--tls-key string path to TLS key file (default: $HELM_HOME/key.pem)
$ helm plugin install https://github.com/mumoshu/helm-x
The above will fetch the latest binary release of helm-x
and install it.
If you would like to handle the build yourself, instead of fetching a binary, this is how recommend doing it.
First, set up your environment:
- You need to have Go 1.12 or greater installed.
Clone this repo anywhere OUSTSIDE of your $GOPATH
:
$ git clone git@github.com:mumoshu/helm-x
$ make install
If you don't want to install it as a helm plugin, you can still run it stand-alone:
$ make build
$ ./helm-x template --name myapp examples/manifests/ --version 1.2.3
$ ./helm-x diff myapp examples/manifests/ --version 1.2.3 --debug
$ ./helm-x apply myapp examples/manifests/ --version 1.2.3 --debug
- Not all flags present in the original
helm diff
,helm template
,helm upgrade
flags are implemented. If you need any other flags, please feel free to open issues and even submit pull requests. - If you are using the
--kube-context
flag, you need to change it to--kubecontext
, since helm plugins drop this flag.
Relies on helm template
to generate K8s manifests that kustomize
can work on.
This method implies that you can't use helm
for release management, as also explained in the original article as follows:
First, Helm is no longer controlling releases of manifests into the cluster. This means that you cannot use helm rollback or helm list or any of the helm release related commands to manage your deployments.
helm-x
, on the other hand, solves this issue by treating the final output of kustomize
as a temporary Helm chart, and actually helm-install
it.
This project's implementation has been largely inspired from the awesome helm-inject project maintained by @maorfr. Thanks a lot for your work, @maorfr!