Bitnami package for Kubeapps

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 install my-release oci://registry-1.docker.io/bitnamicharts/kubeapps --namespace kubeapps --create-namespace

Looking to use Kubeapps in production? Try VMware Tanzu Application Catalog⁠, the commercial edition of the Bitnami catalog.

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.23+
• Helm 3.8.0+
• 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 my-release:

helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/kubeapps --namespace kubeapps --create-namespace

The command deploys Kubeapps on the Kubernetes cluster in the kubeapps namespace. The Parameters section lists the parameters that can be configured during installation.

Once you have installed Kubeapps follow the Getting Started Guide⁠ for additional information on how to access and use Kubeapps.

Configuration and installation details

Resource requests and limits

Bitnami charts allow setting resource requests and limits for all containers inside the chart deployment. These are inside the resources value (check parameter table). Setting requests is essential for production workloads and these should be adapted to your specific use case.

To make this process easier, the chart contains the resourcesPreset values, which automatically sets the resources section according to different presets. Check these presets in the bitnami/common chart⁠. However, in production workloads using resourcesPreset is discouraged as it may not fully adapt to your specific needs. Find more information on container resource management in the official Kubernetes documentation⁠.

Backup and restore

To back up and restore Helm chart deployments on Kubernetes, you need to back up the persistent volumes from the source deployment and attach them to a new deployment using Velero⁠, a Kubernetes backup/restore tool. Find the instructions for using Velero in this guide⁠.

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

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-controller⁠ or contour⁠ you can utilize the ingress controller to serve your application.

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

  Copy

• keys should look like:

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

  Copy

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

Parameters

Global parameters

Common parameters

Traffic Exposure Parameters

Kubeapps packaging options

Frontend parameters

Note: the README for this chart is longer than the DockerHub length limit of 25000, so it has been trimmed. The full README can be found at https://github.com/bitnami/charts/blob/main/bitnami/kubeapps/README.md⁠