HelmRequest is a CRD that defines how to install a helm charts. It's kind of like the helm cli, you can set various options when install a helm charts. But with HelmRequest, it easier to persistent the configuration, and because we now have a controller, which can ensure to successfully install the chats by retrying automatically. This can solve a lot of problems when using helm chats in helm 2, such as
- Some pre-existing resource cause the
helm install
to fail - CRD with
crd-install
hooks not deleted after delete a helm chart, which cause the previous problem again - arbitrary errors which can be resolved by retry
- ...
An example HelmRequest looks like this(after setting some defaults):
apiVersion: app.alauda.io/v1alpha1
kind: HelmRequest
metadata:
finalizers:
- captain.alauda.io
name: nginx-ingress
namespace: default
spec:
chart: stable/nginx-ingress
namespace: default
releaseName: nginx-ingress
clusterName: ""
dependencies:
- nginx
installToAllClusters: false
values:
env: prod
global:
namespace: h8
status:
lastSpecHash: "15900028196316601597"
notes: "<helm charts notes>"
phase: Synced
The chart name, format as <repo-name>/<chart-name>
, this is the only force required field in HelmRequest.Spec
The chart's version. It's optional, just likes helm cli.
If not set, default to HelmRequest.Name. In Helm2, if you not set the release name, helm will create a random string for you(which looks like docker container names), which is very unreasonable.
Also, since Release is namespace scoped CRD resource, it's name is not required to be global unique anymore
If not set, default to HelmRequest.Namespace
If not set, default to "", which means this chart will be installed to the current. Otherwise, the charts will be installed to the specific cluster
Default to false, and it override spec.clusterName
. If set to true
, means this charts will be installed to all the clusters, not only the existing ones,
even the ones added after this HelmRequest (informers will force rsync HelmRequest resource periodically, and captain will refresh cluster list, so just wait and see the magic happens!)
A list of HelmRequests in the current namespace that need to be synced before this one.
The same format and effect as in helm's values.yaml
file.
List of Secrets, ConfigMaps from which to take values. If both spec.values
and spec.valuesFrom
is set, the spec.values
will override.
spec:
# chart: ...
valuesFrom:
- configMapKeyRef:
# Name of the config map, must be in the same namespace as the
# HelmRequest
name: default-values # mandatory
# Key in the config map to get the values from
key: values.yaml # optional; defaults to values.yaml
# If set to true successful retrieval of the values file is no
# longer mandatory
optional: false # optional; defaults to false
- secretKeyRef:
# Name of the secret, must be in the same namespace as the
# HelmRequest
name: default-values # mandatory
# Key in the secret to get thre values from
key: values.yaml # optional; defaults to values.yaml
# If set to true successful retrieval of the values file is no
# longer mandatory
optional: true # optional; defaults to false
Centralized configuration can be a great helper to manage multiple HelmRequest resources.
now supports version v1 and has added new fields, as shown in the following examples
# OCI type
apiVersion: app.alauda.io/v1
kind: HelmRequest
metadata:
name: test-oci
namespace: default
spec:
source:
oci:
repo: 192.168.26.40:60080/acp/chart-tomcat # oci repo address
secretRef: ociSecret # optional, if basic authentication is required, specify a secretname here.
values:
namespace: default
version: 9.2.9 # required, oci version
---
# HTTP type
apiVersion: app.alauda.io/v1
kind: HelmRequest
metadata:
name: test-http
namespace: default
spec:
source:
http:
url: https://alauda.github.io/captain-test-charts/wordpress-lookup-11.0.13.tgz
values: {}
The chart's source. It's optional, this will indicate the source of the current chart, which will be an OCI or HTTP URL address.
If basic authentication is required, specify a secretname in the spec.source.oci
or spec.source.http
.