Kubeapps is a web-based UI for deploying and managing applications in Kubernetes clusters. Kubeapps allows you to:
- Browse and deploy Helm charts from chart repositories
- Inspect, upgrade and delete Helm-based applications installed in the cluster
- Add custom and private chart repositories (supports ChartMuseum and JFrog Artifactory)
- Browse and provision external services from the Service Catalog and available Service Brokers
- Connect Helm-based applications to external services with Service Catalog Bindings
- Secure authentication to Kubeapps using an OAuth2/OIDC provider
- Secure authorization based on Kubernetes Role-Based Access Control
For Helm 2:
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install --name kubeapps --namespace kubeapps bitnami/kubeapps
For Helm 3:
helm repo add bitnami https://charts.bitnami.com/bitnami
kubectl create namespace kubeapps
helm install kubeapps --namespace kubeapps bitnami/kubeapps --set useHelm3=true
This chart bootstraps a Kubeapps deployment on a Kubernetes cluster using the Helm package manager.
It also packages the Bitnami MongoDB chart or the Bitnami PostgreSQL chart which is required for bootstrapping a deployment for the database requirements of the Kubeapps application.
- Kubernetes 1.8+ (tested with Azure Kubernetes Service, Google Kubernetes Engine, minikube and Docker for Desktop Kubernetes)
- Helm 2.14.0+
- Administrative access to the cluster to create Custom Resource Definitions (CRDs)
To install the chart with the release name kubeapps
:
For Helm 2:
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install --name kubeapps --namespace kubeapps bitnami/kubeapps
IMPORTANT This assumes an insecure Helm 2 installation, which is not recommended in production. See the documentation to learn how to secure Helm 2 and Kubeapps in production.
For Helm 3:
helm repo add bitnami https://charts.bitnami.com/bitnami
kubectl create namespace kubeapps
helm install kubeapps --namespace kubeapps bitnami/kubeapps --set useHelm3=true
The command deploys Kubeapps on the Kubernetes cluster in the kubeapps
namespace. The Parameters section lists the parameters that can be configured during installation.
Caveat: Only one Kubeapps installation is supported per namespace
Once you have installed Kubeapps follow the Getting Started Guide for additional information on how to access and use Kubeapps.
For a full list of configuration parameters of the Kubeapps chart, see the values.yaml file.
Specify each parameter using the --set key=value[,key=value]
argument to helm install
. For example,
helm install kubeapps --namespace kubeapps \
--set assetsvc.service.port=9090 \
bitnami/kubeapps
The above command sets the port for the assetsvc Service to 9090.
Alternatively, a YAML file that specifies the values for parameters can be provided while installing the chart. For example,
helm install kubeapps --namespace kubeapps -f custom-values.yaml bitnami/kubeapps
By default, Kubeapps will track the community Helm charts and the Kubernetes Service Catalog charts. To change these defaults, override with your desired parameters the apprepository.initialRepos
object present in the values.yaml file.
Kubeapps supports two database types: MongoDB or PostgreSQL. By default MongoDB is installed. If you want to enable PostgreSQL instead set the following values when installing the application: mongodb.enabled=false
and postresql.enabled=true
.
Note: Changing the database type when upgrading is not supported.
Since v1.9.0, Kubeapps supports to deploy and manage Operators within its dashboard. To enable this feature, set the flag featureFlags.operators=true
. More information about how to enable and use this feature can be found in this guide.
By default, Kubeapps connects to the Tiller Service in the kube-system
namespace, the default install location for Helm.
If your instance of Tiller is running in a different namespace or you want to have different instances of Kubeapps connected to different Tiller instances, you can achieve it by setting the tillerProxy.host
parameter. For example, you can set tillerProxy.host=tiller-deploy.my-custom-namespace:44134
In production, we strongly recommend setting up a secure installation of Tiller, the Helm server side component.
Learn more about how to secure your Kubeapps installation here.
Note: The Kubeapps frontend sets up a proxy to the Kubernetes API service which means that when exposing the Kubeapps service to a network external to the Kubernetes cluster (perhaps on an internal or public network), the Kubernetes API will also be exposed for authenticated requests from that network. If you explicitly use an OAuth2/OIDC provider with Kubeapps (recommended), then only the configured users trusted by your Identity Provider will be able to reach the Kubernetes API. See #1111 for more details.
The simplest way to expose the Kubeapps Dashboard is to assign a LoadBalancer type to the Kubeapps frontend Service. For example, you can use the following parameter: frontend.service.type=LoadBalancer
Wait for your cluster to assign a LoadBalancer IP or Hostname to the kubeapps
Service and access it on that address:
kubectl get services --namespace kubeapps --watch
This chart provides support for ingress resources. If you have an ingress controller installed on your cluster, such as nginx-ingress or traefik you can utilize the ingress controller to expose Kubeapps.
To enable ingress integration, please set ingress.enabled
to true
Most likely you will only want to have one hostname that maps to this Kubeapps installation (use the ingress.hostname
parameter to set the hostname), however, it is possible to have more than one host. To facilitate this, the ingress.extraHosts
object is an array.
For annotations, please see this document. Not all annotations are supported by all ingress controllers, but this document does a good job of indicating which annotation is supported by many popular ingress controllers. Annotations can be set using ingress.annotations
.
To enable TLS, please set ingress.tls
to true
. When enabling this parameter, the TLS certificates will be retrieved from a TLS secret with name INGRESS_HOSTNAME-tls (where INGRESS_HOSTNAME is a placeholder to be replaced with the hostname you set using the ingress.hostname
parameter).
You can use the ingress.extraTls
to provide the TLS configuration for the extra hosts you set using the ingress.extraHosts
array. Please see this example for more information.
You can provide your own certificates using the ingress.secrets
object. If your cluster has a cert-manager add-on to automate the management and issuance of TLS certificates, set ingress.certManager
boolean to true to enable the corresponding annotations for cert-manager. For a full list of configuration parameters related to configuring TLS can see the values.yaml file.
You can upgrade Kubeapps from the Kubeapps web interface. Select the namespace in which Kubeapps is installed (kubeapps
if you followed the instructions in this guide) and click on the "Upgrade" button. Select the new version and confirm.
You can also use the Helm CLI to upgrade Kubeapps, first ensure you have updated your local chart repository cache:
helm repo update
Now upgrade Kubeapps:
export RELEASE_NAME=kubeapps
helm upgrade $RELEASE_NAME bitnami/kubeapps
If you find issues upgrading Kubeapps, check the troubleshooting section.
To uninstall/delete the kubeapps
deployment:
# For Helm 2
helm delete --purge kubeapps
# For Helm 3
helm uninstall kubeapps
# Optional: Only if there are no more instances of Kubeapps
kubectl delete crd apprepositories.kubeapps.com
The first command removes most of the Kubernetes components associated with the chart and deletes the release. After that, if there are no more instances of Kubeapps in the cluster you can manually delete the apprepositories.kubeapps.com
CRD used by Kubeapps that is shared for the entire cluster.
NOTE: If you delete the CRD for
apprepositories.kubeapps.com
it will delete the repositories for all the installed instances ofkubeapps
. This will break existing installations ofkubeapps
if they exist.
If you have dedicated a namespace only for Kubeapps you can completely clean remaining completed/failed jobs or any stale resources by deleting the namespace
kubectl delete namespace kubeapps
When starting the application with the --set enableIPv6=true
option, the Nginx server present in the services kubeapps
and kubeapps-internal-dashboard
may fail with the following:
nginx: [emerg] socket() [::]:8080 failed (97: Address family not supported by protocol)
This usually means that your cluster is not compatible with IPv6. To disable it, install kubeapps with the flag: --set enableIPv6=false
.
If during installation you run into an error similar to:
Error: release kubeapps failed: clusterroles.rbac.authorization.k8s.io "kubeapps-apprepository-controller" is forbidden: attempt to grant extra privileges: [{[get] [batch] [cronjobs] [] []...
Or:
Error: namespaces "kubeapps" is forbidden: User "system:serviceaccount:kube-system:default" cannot get namespaces in the namespace "kubeapps"
This usually is an indication that Tiller was not installed with enough permissions to create the resources required by Kubeapps. In order to install Kubeapps, tiller will need to be able to install Custom Resource Definitions cluster-wide, as well as manage app repositories in your kubeapps namespace. The easiest way to enable this in a development environment is install Tiller with elevated permissions (e.g. as a cluster-admin). For example:
kubectl -n kube-system create sa tiller
kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller
helm init --service-account tiller
but for a production environment you can assign the specific permissions so that tiller can manage CRDs on the cluster as well as create app repositories in your Kubeapps namespace (examples are from our in development support for OpenShift).
It is also possible, though less common, that your cluster does not have Role Based Access Control (RBAC) enabled. To check if your cluster has RBAC you can execute:
kubectl api-versions
If the above command does not include entries for rbac.authorization.k8s.io
you should perform the chart installation by setting rbac.create=false
:
helm install --name kubeapps --namespace kubeapps bitnami/kubeapps --set rbac.create=false
It is possible that when upgrading Kubeapps an error appears. That can be caused by a breaking change in the new chart or because the current chart installation is in an inconsistent state. If you find issues upgrading Kubeapps you can follow these steps:
Note: This steps assume that you have installed Kubeapps in the namespace
kubeapps
using the namekubeapps
. If that is not the case replace the command with your namespace and/or name.
- (Optional) Backup your personal repositories (if you have any):
kubectl get apprepository --namespace kubeapps -o yaml <repo name> > <repo name>.yaml
- Delete Kubeapps:
helm del --purge kubeapps
- (Optional) Delete the App Repositories CRD:
Warning: Don't execute this step if you have more than one Kubeapps installation in your cluster.
kubectl delete crd apprepositories.kubeapps.com
- (Optional) Clean the Kubeapps namespace:
Warning: Don't execute this step if you have workloads other than Kubeapps in the
kubeapps
namespace.
kubectl delete namespace kubeapps
- Install the latest version of Kubeapps (using any custom modifications you need):
helm repo update
helm install --name kubeapps --namespace kubeapps bitnami/kubeapps
- (Optional) Restore any repositories you backed up in the first step:
kubectl apply -f <repo name>.yaml
After that you should be able to access the new version of Kubeapps. If the above doesn't work for you or you run into any other issues please open an issue.