This adds support for installing CRDs well before any other resource
kinds are installed.
This PR introduces a new hook, `crd-install`, that fires before
manifests are even validated. It is used to install a CRD before any
other part of a chart is installed.
Currently, this hook is _only implemented for install_. That means we
currently cannot add new CRDs during `helm upgrade`, nor can they
be rolled back. This is the safest configuration, as the update/rollback
cycle gets very challenging when CRDs are added and removed.
f.StringVar(&inst.namespace,"namespace","","namespace to install the release into. Defaults to the current kube config namespace.")
f.StringVar(&inst.namespace,"namespace","","namespace to install the release into. Defaults to the current kube config namespace.")
f.BoolVar(&inst.dryRun,"dry-run",false,"simulate an install")
f.BoolVar(&inst.dryRun,"dry-run",false,"simulate an install")
f.BoolVar(&inst.disableHooks,"no-hooks",false,"prevent hooks from running during install")
f.BoolVar(&inst.disableHooks,"no-hooks",false,"prevent hooks from running during install")
f.BoolVar(&inst.disableCRDHook,"no-crd-hook",false,"prevent CRD hooks from running, but run other hooks")
f.BoolVar(&inst.replace,"replace",false,"re-use the given name, even if that name is already used. This is unsafe in production")
f.BoolVar(&inst.replace,"replace",false,"re-use the given name, even if that name is already used. This is unsafe in production")
f.StringArrayVar(&inst.values,"set",[]string{},"set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)")
f.StringArrayVar(&inst.values,"set",[]string{},"set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)")
f.StringArrayVar(&inst.stringValues,"set-string",[]string{},"set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)")
f.StringArrayVar(&inst.stringValues,"set-string",[]string{},"set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)")
@ -273,6 +275,7 @@ func (i *installCmd) run() error {
helm.InstallDryRun(i.dryRun),
helm.InstallDryRun(i.dryRun),
helm.InstallReuseName(i.replace),
helm.InstallReuseName(i.replace),
helm.InstallDisableHooks(i.disableHooks),
helm.InstallDisableHooks(i.disableHooks),
helm.InstallDisableCRDHook(i.disableCRDHook),
helm.InstallTimeout(i.timeout),
helm.InstallTimeout(i.timeout),
helm.InstallWait(i.wait))
helm.InstallWait(i.wait))
iferr!=nil{
iferr!=nil{
@ -287,6 +290,10 @@ func (i *installCmd) run() error {
// If this is a dry run, we can't display status.
// If this is a dry run, we can't display status.
ifi.dryRun{
ifi.dryRun{
// This is special casing to avoid breaking backward compatibility:
ifres.Release.Info.Description!="Dry run complete"{
@ -16,6 +16,17 @@ Hooks work like regular templates, but they have special annotations
that cause Helm to utilize them differently. In this section, we cover
that cause Helm to utilize them differently. In this section, we cover
the basic usage pattern for hooks.
the basic usage pattern for hooks.
Hooks are declared as an annotation in the metadata section of a manifest:
```yaml
apiVersion: ...
kind: ....
metadata:
annotations:
"helm.sh/hook": "pre-install"
# ...
```
## The Available Hooks
## The Available Hooks
The following hooks are defined:
The following hooks are defined:
@ -36,6 +47,8 @@ The following hooks are defined:
rendered, but before any resources have been rolled back.
rendered, but before any resources have been rolled back.
- post-rollback: Executes on a rollback request after all resources
- post-rollback: Executes on a rollback request after all resources
have been modified.
have been modified.
- crd-install: Adds CRD resources before any other checks are run. This is used
only on CRD definitions that are used by other manifests in the chart.
## Hooks and the Release Lifecycle
## Hooks and the Release Lifecycle
@ -62,7 +75,7 @@ hooks, the lifecycle is altered like this:
Kubernetes)
Kubernetes)
5. Tiller sorts hooks by weight (assigning a weight of 0 by default) and by name for those hooks with the same weight in ascending order.
5. Tiller sorts hooks by weight (assigning a weight of 0 by default) and by name for those hooks with the same weight in ascending order.
6. Tiller then loads the hook with the lowest weight first (negative to positive)
6. Tiller then loads the hook with the lowest weight first (negative to positive)
7. Tiller waits until the hook is "Ready"
7. Tiller waits until the hook is "Ready" (except for CRDs)
8. Tiller loads the resulting resources into Kubernetes. Note that if the `--wait`
8. Tiller loads the resulting resources into Kubernetes. Note that if the `--wait`
flag is set, Tiller will wait until all resources are in a ready state
flag is set, Tiller will wait until all resources are in a ready state
and will not run the `post-install` hook until they are ready.
and will not run the `post-install` hook until they are ready.
@ -185,6 +198,52 @@ You can choose one or more defined annotation values:
* `"hook-failed"` specifies Tiller should delete the hook if the hook failed during execution.
* `"hook-failed"` specifies Tiller should delete the hook if the hook failed during execution.
* `"before-hook-creation"` specifies Tiller should delete the previous hook before the new hook is launched.
* `"before-hook-creation"` specifies Tiller should delete the previous hook before the new hook is launched.
### Defining a CRD with the `crd-install` Hook
Custom Resource Definitions (CRDs) are a special kind in Kubernetes. They provide
a way to define other kinds.
On occasion, a chart needs to both define a kind and then use it. This is done
with the `crd-install` hook.
The `crd-install` hook is executed very early during an installation, before
the rest of the manifests are verified. CRDs can be annotated with this hook so
that they are installed before any instances of that CRD are referenced. In this
way, when verification happens later, the CRDs will be available.
Here is an example of defining a CRD with a hook, and an instance of the CRD:
```yaml
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
name: crontabs.stable.example.com
annotations:
"helm.sh/hook": crd-install
spec:
group: stable.example.com
version: v1
scope: Namespaced
names:
plural: crontabs
singular: crontab
kind: CronTab
shortNames:
- ct
```
And:
```yaml
apiVersion: stable.example.com/v1
kind: CronTab
metadata:
name: {{ .Release.Name }}-inst
```
Both of these can now be in the same chart, provided that the CRD is correctly
annotated.
### Automatically delete hook from previous release
### Automatically delete hook from previous release
When helm release being updated it is possible, that hook resource already exists in cluster. By default helm will try to create resource and fail with `"... already exists"` error.
When helm release being updated it is possible, that hook resource already exists in cluster. By default helm will try to create resource and fail with `"... already exists"` error.
Matt Butcher
7 years ago
committed by
GitHub