provider-helm
provider-helm is a Crossplane Provider that enables deployment and management
of Helm Releases on Kubernetes clusters typically provisioned by Crossplane, and
has the following functionality:
- A
Releaseresource type to manage Helm Releases. - A managed resource controller that reconciles
Releaseobjects and manages
Install
If you would like to install the latest version of provider-helm without modifications, you may do
so using the Crossplane CLI in a Kubernetes cluster where Crossplane is
installed:
latest_tag=$(crane ls xpkg.crossplane.io/crossplane-contrib/provider-helm | grep -E '^v[0-9]+\.[0-9]+\.[0-9]+$' | sort -V | tail -n1)
crossplane xpkg install provider xpkg.crossplane.io/crossplane-contrib/provider-helm:$latest_tag
Then you will need to create a ProviderConfig that specifies the credentials
to connect to the Kubernetes API. This is commonly done within a Composition
by storing a kubeconfig into a secret that the ProviderConfig references. An
example of this approach can be found in
configuration-aws-eks.
Quick start
An alternative, that will get you started quickly, is to reuse existing credentials from within the control plane.
First install provider-helm with additional
configuration to bind its
service account to an existing role in the cluster:
``console
kubectl apply -f ./examples/cluster/provider-config/provider-incluster.yaml
console
kubectl apply -f ./examples/cluster/provider-config/provider-config-incluster.yaml
Then simply create a
ProviderConfig
that uses an InjectedIdentity source:
console
kubectl create -f examples/cluster/sample/release.yaml
provider-helm will then be installed and ready to use within the cluster. You
can now create Release resources, such as sample
release.yaml.## Design
See the design document.
Developing locally
Pre-requisite: A Kubernetes cluster with Crossplane installed
To run the provider-helm controller against your existing local cluster,
simply run:console
make run
Since the controller is running outside the local cluster, you need to make
the API server accessible (on a separate terminal):console
sudo kubectl proxy --port=8081
console KUBECONFIG=$(kind get kubeconfig | sed -e 's|server:\s.$|server: http://localhost:8081|g') kubectl -n crossplane-system create secret generic cluster-config --from-literal=kubeconfig="${KUBECONFIG}" kubectl apply -f examples/cluster/provider-config/provider-config-with-secret.yamlThen we must prepare aProviderConfigfor the local cluster (assuming you are usingkindfor local development):
console kubectl create -f examples/cluster/sample/release.yaml ``Now you can createReleaseresources with thisProviderConfig, for example sample release.yaml.