Kubeapps packaged by Bitnami ¶

Kubeapps is a web-based UI for launching and managing applications on Kubernetes. It allows users to deploy trusted applications and operators to control users access to the cluster.

Overview of Kubeapps

TL;DR ¶

helm repo add bitnami https://charts.bitnami.com/bitnami
kubectl create namespace kubeapps
helm install kubeapps --namespace kubeapps bitnami/kubeapps

Check out the getting started to start deploying apps with Kubeapps.

Introduction ¶

This chart bootstraps a Kubeapps deployment on a Kubernetes cluster using the Helm package manager.

With Kubeapps you can:

• Customize deployments through an intuitive, form-based user interface
• Inspect, upgrade and delete applications installed in the cluster
• Browse and deploy Helm charts from public or private chart repositories (including VMware Marketplace™ and Bitnami Application Catalog )
• Browse and deploy Kubernetes Operators
• Secure authentication to Kubeapps using a standalone OAuth2/OIDC provider or using Pinniped
• Secure authorization based on Kubernetes Role-Based Access Control

Note: Kubeapps 2.0 and onwards supports Helm 3 only. While only the Helm 3 API is supported, in most cases, charts made for Helm 2 will still work.

It also packages the Bitnami PostgreSQL chart , which is required for bootstrapping a deployment for the database requirements of the Kubeapps application.

Prerequisites ¶

• Kubernetes 1.16+ (tested with both bare-metal and managed clusters, including EKS, AKS, GKE and Tanzu Kubernetes Grid, as well as dev clusters, such as Kind, Minikube and Docker for Desktop Kubernetes)
• Helm 3.0.2+
• Administrative access to the cluster to create Custom Resource Definitions (CRDs)
• PV provisioner support in the underlying infrastructure (required for PostgreSQL database)

Installing the Chart ¶

To install the chart with the release name kubeapps:

helm repo add bitnami https://charts.bitnami.com/bitnami
kubectl create namespace kubeapps
helm install kubeapps --namespace kubeapps bitnami/kubeapps

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.

Parameters ¶

Global parameters ¶

Common parameters ¶

Traffic Exposure Parameters ¶

Kubeapps packaging options ¶

Frontend parameters ¶

Dashboard parameters ¶

AppRepository Controller parameters ¶

Kubeops parameters ¶

Auth Proxy parameters ¶

Pinniped Proxy parameters ¶

Other Parameters ¶

Database Parameters ¶

kubeappsapis parameters ¶

Redis® chart configuration ¶

Specify each parameter using the --set key=value[,key=value] argument to helm install. For example,

helm install kubeapps --namespace kubeapps \
  --set ingress.enabled=true \
    bitnami/kubeapps

The above command enables an Ingress Rule to expose Kubeapps.

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

Configuration and installation details ¶

Configuring Initial Repositories ¶

By default, Kubeapps will track the Bitnami Application Catalog . To change these defaults, override with your desired parameters the apprepository.initialRepos object present in the values.yaml file.

Enabling Operators ¶

Since v1.9.0 (and by default since v2.0), Kubeapps supports deploying and managing Operators within its dashboard. More information about how to enable and use this feature can be found in this guide .

Exposing Externally ¶

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. It is highly recommended that you use an OAuth2/OIDC provider with Kubeapps to ensure that your authentication proxy is exposed rather than the Kubeapps frontend. This ensures that only the configured users trusted by your Identity Provider will be able to reach the Kubeapps frontend and therefore the Kubernetes API. Kubernetes service token authentication should only be used for users for demonstration purposes only, not production environments.

LoadBalancer Service ¶

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

Ingress ¶

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

Hosts ¶

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.

Annotations ¶

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.

TLS ¶

This chart will facilitate the creation of TLS secrets for use with the ingress controller, however, this is not required. There are four common use cases:

• Helm generates/manages certificate secrets based on the parameters.
• The user generates/manages certificates separately.
• Helm creates self-signed certificates and generates/manages certificate secrets.
• An additional tool (like cert-manager ) manages the secrets for the application.

In the first two cases, it is needed a certificate and a key. We would expect them to look like this:

• certificate files should look like (and there can be more than one certificate if there is a certificate chain)

  -----BEGIN CERTIFICATE-----
  MIID6TCCAtGgAwIBAgIJAIaCwivkeB5EMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV
  ...
  jScrvkiBO65F46KioCL9h5tDvomdU1aqpI/CBzhvZn1c0ZTf87tGQR8NK7v7
  -----END CERTIFICATE-----
  

• keys should look like:

  -----BEGIN RSA PRIVATE KEY-----
  MIIEogIBAAKCAQEAvLYcyu8f3skuRyUgeeNpeDvYBCDcgq+LsWap6zbX5f8oLqp4
  ...
  wrj2wDbCDCFmfqnSJ+dKI3vFLlEz44sAV8jX/kd4Y6ZTQhlLbYc=
  -----END RSA PRIVATE KEY-----
  

• If you are going to use Helm to manage the certificates based on the parameters, please copy these values into the certificate and key values for a given ingress.secrets entry.

• In case you are going to manage TLS secrets separately, please know that you must use 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).

• To use self-signed certificates created by Helm, set both ingress.tls and ingress.selfSigned to true.

• 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.

Upgrading Kubeapps ¶

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.

Uninstalling the Chart ¶

To uninstall/delete the kubeapps deployment:

helm uninstall -n kubeapps 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 of kubeapps. This will break existing installations of kubeapps if they exist.

If you have dedicated a namespace only for Kubeapps you can completely clean the remaining completed/failed jobs or any stale resources by deleting the namespace

kubectl delete namespace kubeapps

FAQ ¶

• How to install Kubeapps for demo purposes?
• How to install Kubeapps in production scenarios?
• How to use Kubeapps?
• How to configure Kubeapps with Ingress
  • Serving Kubeapps in a subpath
• Can Kubeapps install apps into more than one cluster?
• Can Kubeapps be installed without Internet connection?
• Does Kubeapps support private repositories?
• Is there any API documentation?
• Why can’t I configure global private repositories?
• Does Kubeapps support Operators?
• Slow response when listing namespaces?
• More questions?

How to install Kubeapps for demo purposes? ¶

Install Kubeapps for exclusively demo purposes by simply following the getting started docs.

How to install Kubeapps in production scenarios? ¶

For any user-facing installation, you should configure an OAuth2/OIDC provider to enable secure user authentication with Kubeapps and the cluster. Please also refer to the Access Control documentation to configure fine-grained access control for users.

How to use Kubeapps? ¶

Have a look at the dashboard documentation for knowing how to use the Kubeapps dashboard: deploying applications, listing and removing the applications running in your cluster and adding new repositories.

How to configure Kubeapps with Ingress ¶

The example below will match the URL http://example.com to the Kubeapps dashboard. For further configuration, please refer to your specific Ingress configuration docs (e.g., NGINX or HAProxy ).

helm install kubeapps bitnami/kubeapps \
  --namespace kubeapps \
  --set ingress.enabled=true \
  --set ingress.hostname=example.com \
  --set ingress.annotations."kubernetes\.io/ingress\.class"=nginx # or your preferred ingress controller

Serving Kubeapps in a subpath ¶

You may want to serve Kubeapps with a subpath, for instance http://example.com/subpath, you have to set the proper Ingress configuration. If you are using the ingress configuration provided by the Kubeapps chart, you will have to set the ingress.hostname and path parameters:

helm install kubeapps bitnami/kubeapps \
  --namespace kubeapps \
  --set ingress.enabled=true \
  --set ingress.hostname=example.com \
  --set ingress.path=/subpath \
  --set ingress.annotations."kubernetes\.io/ingress\.class"=nginx # or your preferred ingress controller

Besides, if you are using the OAuth2/OIDC login (more information at the using an OIDC provider documentation ), you will need, also, to configure the different URLs:

helm install kubeapps bitnami/kubeapps \
  --namespace kubeapps \
  # ... other OIDC and ingress flags
  --set authProxy.oauthLoginURI="/subpath/oauth2/login" \
  --set authProxy.oauthLogoutURI="/subpath/oauth2/logout" \
  --set authProxy.extraFlags="{<other flags>,--proxy-prefix=/subpath/oauth2}"

Can Kubeapps install apps into more than one cluster? ¶

Yes! Kubeapps 2.0+ supports multicluster environments. Have a look at the Kubeapps dashboard documentation to know more.

Can Kubeapps be installed without Internet connection? ¶

Yes! Follow the offline installation documentation to discover how to perform an installation in an air-gapped scenario.

Does Kubeapps support private repositories? ¶

Of course! Have a look at the private package repositories documentation to learn how to configure a private repository in Kubeapps.

Is there any API documentation? ¶

Yes! But it is not definitive and is still subject to change. Check out the latest API online documentation or download the Kubeapps OpenAPI Specification yaml file from the repository.

Why can’t I configure global private repositories? ¶

You can, but you will need to configure the imagePullSecrets manually.

Kubeapps does not allow you to add imagePullSecrets to an AppRepository that is available to the whole cluster because it would require that Kubeapps copies those secrets to the target namespace when a user deploys an app.

If you create a global AppRepository but the images are on a private registry requiring imagePullSecrets, the best way to configure that is to ensure your Kubernetes nodes are configured with the required imagePullSecrets - this allows all users (of those nodes) to use those images in their deployments without ever requiring access to the secrets.

You could alternatively ensure that the imagePullSecret is available in all namespaces in which you want people to deploy, but this unnecessarily compromises the secret.

Does Kubeapps support Operators? ¶

Yes! You can get started by following the operators documentation .

Slow response when listing namespaces ¶

Kubeapps uses the currently logged-in user credential to retrieve the list of all namespaces. If the user does not have permission to list namespaces, the backend will try again with its own service account. It will list all the namespaces and then will iterate through each namespace to check if the user has permissions to get secrets for each one. This can lead to a slow response if the number of namespaces on the cluster is large.

To reduce this response time, you can increase the number of checks that Kubeapps will perform in parallel (per connection) setting the value: kubeappsapis.burst=<desired_number> and kubeappsapis.QPS=<desired_number>.

More questions? ¶

Feel free to open an issue if you have any questions!

Troubleshooting ¶

Upgrading to chart version 8.0.0 ¶

This major release renames several values in this chart and adds missing features, in order to get aligned with the rest of the assets in the Bitnami charts repository.

Additionally, it updates both the PostgreSQL and the Redis subcharts to their latest major versions, 11.0.0 and 16.0.0 respectively, where similar changes have been also performed. Check PostgreSQL Upgrading Notes and Redis Upgrading Notes for more information.

The following values have been renamed:

• frontend.service.port renamed as frontend.service.ports.http.
• frontend.service.nodePort renamed as frontend.service.nodePorts.http.
• frontend.containerPort renamed as frontend.containerPorts.http.
• dashboard.service.port renamed as dashboard.service.ports.http.
• dashboard.containerPort renamed as dashboard.containerPorts.http.
• apprepository.service.port renamed as apprepository.service.ports.http.
• apprepository.containerPort renamed as apprepository.containerPorts.http.
• kubeops.service.port renamed as kubeops.service.ports.http.
• kubeops.containerPort renamed as kubeops.containerPorts.http.
• assetsvc.service.port renamed as assetsvc.service.ports.http.
• assetsvc.containerPort renamed as assetsvc.containerPorts.http.
• authProxy.containerPort renamed as authProxy.containerPorts.proxy.
• authProxy.additionalFlags renamed as authProxy.extraFlags,
• Pinniped Proxy service no longer uses pinnipedProxy.containerPort. Use pinnipedProxy.service.ports.pinnipedProxy to change the service port.
• pinnipedProxy.containerPort renamed as pinnipedProxy.containerPorts.pinnipedProxy.
• postgresql.replication.enabled has been removed. Use postgresql.architecture instead.
• postgresql.postgresqlDatabase renamed as postgresql.auth.database.
• postgresql.postgresqlPassword renamed as postgresql.auth.password.
• postgresql.existingSecret renamed as postgresql.auth.existingSecret.
• redis.redisPassword renamed as redis.auth.password.
• redis.existingSecret renamed as redis.auth.existingSecret.

Note also that if you have an existing Postgresql secret that is used for Kubeapps, you will need to update the key from postgresql-password to postgres-password.

Nginx Ipv6 error ¶

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 deactivate it, install kubeapps with the flag: --set enableIPv6=false.

Forbidden error while installing the Chart ¶

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"

It is possible, though uncommon, that your cluster does not have Role-Based Access Control (RBAC) enabled. To check if your cluster has RBAC you can run the following command:

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

Error while upgrading the Chart ¶

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: These steps assume that you have installed Kubeapps in the namespace kubeapps using the name kubeapps. If that is not the case replace the command with your namespace and/or name. Note: If you are upgrading from 2.3.1 see the following section . Note: If you are upgrading from 2.3.1 see the following section . Note: If you are upgrading from 1.X to 2.X see the following section .

1. (Optional) Backup your personal repositories (if you have any):

kubectl get apprepository -A -o yaml > <repo name>.yaml

2. Delete Kubeapps:

helm del --purge kubeapps

3. (Optional) Delete the App Repositories CRD:

Warning: Do not run this step if you have more than one Kubeapps installation in your cluster.

kubectl delete crd apprepositories.kubeapps.com

4. (Optional) Clean the Kubeapps namespace:

Warning: Do not run this step if you have workloads other than Kubeapps in the kubeapps namespace.

kubectl delete namespace kubeapps

5. Install the latest version of Kubeapps (using any custom modifications you need):

helm repo update
helm install --name kubeapps --namespace kubeapps bitnami/kubeapps

6. (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 .

Upgrading to chart version 7.0.0 ¶

In this release, no breaking changes were included in Kubeapps (version 2.3.2). However, the chart adopted the standardizations included in the rest of the charts in the Bitnami catalog.

Most of these standardizations simply add new parameters that allow to add more customizations such as adding custom env. variables, volumes or sidecar containers. That said, some of them include breaking changes:

• Chart labels were adapted to follow the Helm charts standard labels .
• securityContext.* parameters are deprecated in favor of XXX.podSecurityContext.* and XXX.containerSecurityContext.*, where XXX is placeholder you need to replace with the actual component(s). For instance, to modify the container security context for “kubeops” use kubeops.podSecurityContext and kubeops.containerSecurityContext parameters.

Upgrading to 2.3.1 ¶

Kubeapps 2.3.1 (Chart version 6.0.0) introduces some breaking changes. Helm-specific functionality has been removed in order to support other installation methods (like using YAML manifests, kapp or kustomize ). Because of that, there are some steps required before upgrading from a previous version:

1. Kubeapps will no longer create a database secret for you automatically but rather will rely on the default behavior of the PostgreSQL chart. If you try to upgrade Kubeapps and you installed it without setting a password, you will get the following error:

Error: UPGRADE FAILED: template: kubeapps/templates/NOTES.txt:73:4: executing "kubeapps/templates/NOTES.txt" at <include "common.errors.upgrade.passwords.empty" (dict "validationErrors" $passwordValidationErrors "context" $)>: error calling include: template: kubeapps/charts/common/templates/_errors.tpl:18:48: executing "common.errors.upgrade.passwords.empty" at <fail>: error calling fail:
PASSWORDS ERROR: you must provide your current passwords when upgrade the release
    'postgresql.postgresqlPassword' must not be empty, please add '--set postgresql.postgresqlPassword=$POSTGRESQL_PASSWORD' to the command. To get the current value:

The error gives you generic instructions for retrieving the PostgreSQL password, but if you have installed a Kubeapps version prior to 2.3.1, the name of the secret will differ. Run the following command:

export POSTGRESQL_PASSWORD=$(kubectl get secret --namespace "kubeapps" kubeapps-db -o jsonpath="{.data.postgresql-password}" | base64 -d)

NOTE: Replace the namespace in the command with the namespace in which you have deployed Kubeapps.

Make sure that you have stored the password in the variable $POSTGRESQL_PASSWORD before continuing with the next issue.

2. The chart initialRepos are no longer installed using Helm hooks , which caused these repos not to be handled by Helm after the first installation. Now they will be tracked for every update. However, if you do not delete the existing ones, it will fail to update with:

Error: UPGRADE FAILED: rendered manifests contain a resource that already exists. Unable to continue with update: AppRepository "bitnami" in namespace "kubeapps" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "kubeapps"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "kubeapps"

To bypass this issue, you will need to before delete all the initialRepos from the chart values (only the bitnami repo by default):

$ kubectl delete apprepositories.kubeapps.com -n kubeapps bitnami

NOTE: Replace the namespace in the command with the namespace in which you have deployed Kubeapps.

After that, you will be able to upgrade Kubeapps to 2.3.1 using the existing database secret:

WARNING: Make sure that the variable $POSTGRESQL_PASSWORD is properly populated. Setting a wrong (or empty) password will corrupt the release.

$ helm upgrade kubeapps bitnami/kubeapps -n kubeapps --set postgresql.postgresqlPassword=$POSTGRESQL_PASSWORD

Upgrading to 2.0.1 (Chart 5.0.0) ¶

On November 13, 2020, Helm 2 support was formally finished , this major version is the result of the required changes applied to the Helm Chart to be able to incorporate the different features added in Helm 3 and to be consistent with the Helm project itself regarding the Helm 2 EOL.

What changes were introduced in this major version?

• Previous versions of this Helm Chart use apiVersion: v1 (installable by both Helm 2 and 3), this Helm Chart was updated to apiVersion: v2 (installable by Helm 3 only). Here you can find more information about the apiVersion field.
• Move dependency information from the requirements.yaml to the Chart.yaml
• After running helm dependency update, a Chart.lock file is generated containing the same structure used in the previous requirements.lock
• The different fields present in the Chart.yaml file has been ordered alphabetically in a homogeneous way for all the Bitnami Helm Charts
• In the case of PostgreSQL subchart, apart from the same changes that are described in this section, there are also other major changes due to the master/slave nomenclature was replaced by primary/readReplica. Here you can find more information about the changes introduced.

Considerations when upgrading to this version

• If you want to upgrade to this version using Helm 2, this scenario is not supported as this version does not support Helm 2 anymore
• If you installed the previous version with Helm 2 and wants to upgrade to this version with Helm 3, please refer to the official Helm documentation about migrating from Helm 2 to 3
• If you want to upgrade to this version from a previous one installed with Helm 3, you should not face any issues related to the new apiVersion. Due to the PostgreSQL major version bump, it is necessary to remove the existing statefulsets:

Note: The command below assumes that Kubeapps has been deployed in the kubeapps namespace using “kubeapps” as release name, if that is not the case, adapt the command accordingly.

$ kubectl delete statefulset -n kubeapps kubeapps-postgresql-master kubeapps-postgresql-slave

Useful links

• https://docs.bitnami.com/tutorials/resolve-helm2-helm3-post-migration-issues/
• https://helm.sh/docs/topics/v2_v3_migration/
• https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/

Upgrading to 2.0 ¶

Kubeapps 2.0 (Chart version 4.0.0) introduces some breaking changes:

• Helm 2 is no longer supported. If you are still using some Helm 2 charts, migrate them with the available tools . Note that some charts (but not all of them) may require to be migrated to the new Chart specification (v2) . If you are facing any issue managing this migration and Kubeapps, please open a new issue!
• MongoDB® is no longer supported. Since 2.0, the only database supported is PostgreSQL.
• PostgreSQL chart dependency has been upgraded to a new major version.

Due to the last point, it is necessary to run a command before upgrading to Kubeapps 2.0:

Note: The command below assumes that Kubeapps has been deployed in the kubeapps namespace using “kubeapps” as release name, if that is not the case, adapt the command accordingly.

kubectl delete statefulset -n kubeapps kubeapps-postgresql-master kubeapps-postgresql-slave

After that, you should be able to upgrade Kubeapps as always and the database will be repopulated.

License ¶

Copyright © 2022 Bitnami

Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.