Kubeapps Extends Package Repository Management

New Package Repository API and UI in version 2.5.0

Authored by Pepe Baena, R&D Manager at VMware

The Kubeapps team is continuously looking for ways to improve the user experience when browsing and deploying applications on Kubernetes clusters. The new Kubeapps release ﹣ version 2.5.0 ﹣ extends the repository management feature by including Carvel packages. Now, users will be able to configure package repositories for both Helm and Carvel packages in just a few clicks. 

Keep reading to learn more about the key points that make it possible: a new Package Repository API and a revamped form that allows you to easily configure package repositories directly from the UI. 

Context of this Enhancement

Before releasing version 2.4.3, Kubeapps was mainly focused on Helm chart management, and as a  consequence, was tied closely to Helm repositories and OCI registries for Helm chart storage. When we added support for Carvel packages and Helm charts via Flux, it became necessary to standardize the management of different package repository types in Kubeapps. This brought the following challenges for the team:

• We needed to design and implement a new API, similar to the Kubeapps core API for managing packages, but in this case for managing package repositories as well as ensuring that the new API satisfies the requirements of the existing Helm functionality.
• We needed to implement a Package Repository API for the different plugins (Helm, Flux, and Carvel).
• We needed to revamp the current UI form to standardize the experience when configuring existing repositories (Helm and OCI) as well as Carvel and Flux sources.

Let’s see in detail what implementation strategy and steps were performed to successfully add this new feature to Kubeapps.

Design and Implementation of a New Package Repository API

The first step we followed was to design a new Package Repository API that allowed us to manage new package repositories on Kubeapps. The main component of the domain model is the PackageRepository (a repository of Kubernetes application packages that are available for installation). A repository may be served by any one of the backends supported by the configured plugins (Helm, Flux, and Carvel plugins), including, but not limited to:

• a Helm chart repository (e.g. https://charts.bitnami.com/bitnami ) – via Helm or via Flux plugins
• an OCI helm repository ﹣ via Helm plugin or via Flux plugin
• a Git repository containing artifacts ﹣ gzip compressed TAR archives, via Flux plugin
• object storage buckets containing artifacts coming from S3 compatible storage such as Minio, Amazon S3, Google Cloud Storage, Alibaba Cloud OSS, and others ﹣ via Flux plugin
• a Git repository or HTTP tarball of installable packages ﹣ for Carvel kapp﹣controller plugin
• a Docker image reference for an Image or ImagePackageBundle ﹣ used by Carvel kapp﹣controller to define a repository of installable packages

PackageRepositories may be either global (cluster-wide) or namespace-scoped, in which case only users with access to that namespace will have access to the repositories﹣Flux does not have the concept of global repositories. Furthermore, PackageRepository may be public (i.e. require no authentication to access its contents) or private (i.e. require some form of authentication to access its packages). Taking all those requirements into consideration, the Repositories API definition was defined and made publicly available in order to provide a complete reference to the new API. In addition, the API is also available for each Kubeapps instance and includes a documentation portal accessible using user credentials: https://<kubeapps url>/#/docs.

Once the initial version of the Package Repository API was defined, the next step was to implement the API for each available plugin in Kubeapps ﹣Helm, Flux, and Carvel plugins. We decided to begin the work by implementing the API for the Flux plugin ﹣as any other could have been selected ﹣ while continuing in parallel the development of the API for Helm and Carvel. Fortunately, we could speed up the development thanks to the pluggable architecture of Kubeapps implemented in prior versions. During the implementation for each plugin, we verified that the new API satisfied the needs of the UI and found some gaps in the existing form that needed to be addressed.

Revamping of the Kubeapps UI

When the new Package Repository API had been totally implemented, it was time to adapt the UI to comply with the new API, and at the same time, to simplify the user experience in managing package repositories in Kubeapps. 

The main challenge we found was how to group and display all the fields in a way that the Kubeapps UI will be able to guide users through the configuring process. The revamping process of the form was tackled in three stages:

1. Using the new repository API in the existing UI to manage new API calls, report issues back, and improve the API when needed. The main goal of all these actions was to ensure feature parity between the new API and what Kubeapps supports with a consistent implementation across plugins.
2. Completing support for secret management in private repos. To do so, we had to unblock all the issues related to authentication and the existing inconsistencies across plugins that were identified in previous stages.
3. Working on code and UI enhancements. In this last stage, the team focused on cleaning the code including the removal of pending calls to deprecate kubeops, adding some improvements in the form such as the scope field to select for global or namespaced repos, and fixing some issues identified when using the new UI in different scenarios.

As a result, the new UI for Package Repository management includes the following sections:

Basic information

In this section, users will include information about the repository such as litname, URL,  packaging format, and storage type. 

To improve the user experience, we have added a new field in this form: the repository scope. This was previously set by default depending on the namespace. Adding an extra field to set the scope of the repository allows Kubeapps users to perform this configuration explicitly.

Note that the storage types field for Helm differs from the one set for Carvel packages as mentioned above. Refer to the next image to see how it looks when you  select Carvel packages as the packaging format: 

 

Authentication

Once the basic information has been entered in the form, depending on whether the repository where the packages live is public or private, Kubeapps will require authentication data. We originally planned to support scenarios where the user may choose to provide a reference to an existing secret or string cert_authority, which Kubeapps would convert into a new secret on the backend but we found that approach to be complex, particularly in those cases that require an update in the Package Repository. To simplify the process, the form now includes only two options for secrets: 

a. The user will manage secrets

b. Secrets will be managed by Kubeapps

These options are set on a per-repository basis; thus, different users can use whatever option they prefer in the same Kubeapps installation.  When the Auth and/or TlsConfig options are configured, the user has the choice to select an existing secret (option A) or to enter the credentials (option B). Any updates thereafter must be according to the original option selected.

• If the secret was created by choosing option A, the plugin will return the secret name and any update must be done via secrets; 
• If the secret was created by choosing option B, the plugin will return the credentials and any update must be done by providing the credentials again.

The plugin will automatically detect and manage whether the package repository is using option A or B. In the case of option B, it is recommended to leverage the Kubernetes ownerReference mechanism along with a managed-by annotation.

From a UI perspective, the revamped form includes a section for Authentication with all these different options:

Advanced

Finally,  some advanced fields have been included to configure different aspects of the repository such as the synchronization interval ﹣ available for Flux and Carvel plugins ﹣ CA certificate, skip TLS verification, or passing credentials to 3rd party's URL as shown in the image below:

Conclusion and Next steps

Thanks to the implementation of the Package Repository API and the pluggable architecture in Kubeapps, the team was able to move forward and boost development when the API was defined. The new form lays down the foundation for making Kubeapps simple by guiding users through the configuration process.

Next, we plan to tackle challenges such as the support for OCI registries in the Flux plugin, adding sync intervals for the Helm plugin as well as exploring repository configuration for multi-cluster and air-gapped environments. 

I would like to highlight the great work done by the Kubeapps team in implementing the new Package Repository API and revamping the user interface.  

Support and Resources

Since Kubeapps is an open-source software project, support will be provided on a best-effort basis. To get a resolution on issues such as deployment support, operational support, and bug fixes, please open an issue in the Kubeapps GitHub repository. A Markdown template is provided by default to open new issues, with certain information requested to help us prioritize and respond as soon as possible. Also, if you want to contribute to the project, feel free to send us a pull request, and the team will guide you in the process of a successful merge.

In addition, you can reach out to Kubeapps developers at #kubeapps on Kubernetes Slack (click here to sign up).

For more information about the topics discussed in this blog post, refer to the following links:

• Get Started with Kubeapps
• Managing Carvel Packages with Kubeapps
• Managing Flux V2 Packages with Kubeapps

Kubeapps 2.4.3 - Now Supports for Carvel and Flux Packages

Michael Nelson and Raquel Campuzano co-wrote this blog post 

A new release of Kubeapps is out, and it introduces major changes that mark a milestone in the history of this tool. We are thrilled to announce that the support of different Kubernetes packages has now become a reality with the implementation of the Kubeapps API service. Helm charts are no longer the only option to choose from: now Kubeapps users can deploy Carvel and Flux packages as well! 

In addition to this new capability, the Kubeapps team has solved a long-standing security issue by removing the reverse proxy to Kubernetes API server.  

Keep reading to learn more about how the team has implemented a pluggable architecture that allows users to discover new implementation that make Kubeapps a robust and secure way to deploy applications on Kubernetes infrastructure.  

We will also cover how to deploy and manage Carvel and Flux packages from the Kubeapps user interface (UI).  

Kubeapps APIs – A Pluggable System Supporting Different Kubernetes Packages 

The design of the Kubeapps APIs server solves two main goals for Kubeapps. 

1. Enable pluggable support for presenting catalogs of different Kubernetes packaging formats for installation 

Kubeapps coupled to HelmPrior to this release, Kubeapps was tied closely to the Helm packaging API for listing, installing, and updating Helm charts. The team has abstracted the functionality for listing, installing, and updating packages so that it can be applied to other packaging formats apart from Helm charts. 

Each format is supported by a plugin that implements a core gRPC protocol for package interactions. Since each plugin implements the same packages protocol, Kubeapps can present the results from multiple plugins in the UI, so that, for example, both Helm and Carvel packages can be seen in the catalog together.  

2. Remove the long-standing requirement for the Kubeapps UI to talk directly with the Kubernetes API server 

Kubeapps UI gathering data via the resources pluginSimilarly, prior to this release, the Kubeapps UI needed to communicate directly with the Kubernetes API server and as a result, Kubeapps forwarded requests from the Kubeapps UI through to the Kubernetes API server. The team has now encapsulated the functionality required by the Kubeapps UI into a separate Kubernetes Resources plugin, which allows the Kubeapps UI to, for example, fetch or watch resources created by a specific installed package (if the authenticated user has access to those resources). 

With this change, only a very limited subset of the functionality of the Kubernetes API server is available to the Kubeapps UI. 

A side-effect of these changes is that the client code in the Kubeapps UI can be simplified significantly, which is not only easier to maintain but also opens the possibility for other Kubeapps clients. 

For more details about the implementation of the Kubeapps APIs service, see Kubeapps APIs: A pluggable system supporting different Kubernetes packages. 

New Package Types Discoverable through the Kubeapps UI  

This new release comes with new features and capabilities that provide cluster administrators and operators more flexibility when deploying applications on their Kubernetes environments. Let’s deep dive into them! 

Update your Helm repositories to ensure that you have the latest Kubeapps version. Refer to the Get Started guide to learn how to deploy Kubeapps for your cluster.  

Once you have made some configurations in your cluster and set up Kubeapps to enable Carvel and Flux packages, you will be able to find packages labeled
as Helm, Carvel, and Flux when navigating to the “Catalog” section.  

 

The process of deploying Carvel and/or Flux packages from the Kubeapps UI and managing applications is similar to the processes followed for a Helm chart, but there are some requirements that your cluster must carry out to make sure that the deployment of these new packaging formats will work. 

Deploy and Manage Carvel Packages with Kubeapps 

Check out this step-by-step guide to learn how to manage Carvel packages with Kubeapps. 

Carvel is usually defined as a set of tools that helps you to build and configure applications for their deployment on Kubernetes. To enable the consumption of Carvel packages from the Kubeapps UI, you must make some configurations first. 

These are the pre-requisite steps to follow to make sure that both your cluster and Kubeapps deployment are ready to work with Carvel packages: 

1. Install kapp-controller in your cluster 
2. Configure Kubeapps to support Carvel packages 
3. Install a package repository 
4. Create a service account in your namespace 

Once everything is arranged, you’ll be ready to pick packages to deploy on the Kubeapps UI by navigating to the “Catalog” section. 

• Log in to Kubeapps and navigate to the “Catalog” section. Search for Carvel packages:  

• Pick an application to deploy. This blog post uses Contour as an example, but you can choose any other application from your catalog. 

You will find detailed information about the package you’re about to deploy such as the requirements, release notes, where to find support, licenses, or the maintainers of the image. 

• Select the version you want to deploy. And click “Deploy” to continue:  

• In the resulting screen, add a name for your deployment, select the service account, and make changes to the YAML file if applicable. Click “Deploy” to finish the process.  

• Navigate to the “Applications” section. If the deployment went smoothly, your application will show a green label saying that the package was installed successfully in your cluster.  

• Click on “Show apps in all namespaces” to get an overview of the applications running in your cluster regardless of the namespace.  

• Look at the deployment details by clicking on the application you just deployed.  

In the resulting screen, you will have access to meaningful information such as the number of pods deployed, access URLs, secrets, installation notes, and application resources. Note that from this page, you can also upgrade your application to the next version available or delete it from your cluster.  

 Deploy and Manage Flux Packages with Kubeapps 

Check out this step-by-step guide to learn how to manage Flux V2 packages with Kubeapps. 

Flux is a set of continuous and progressive delivery solutions for Kubernetes that are open and extensible. The latest version of Kubeapps allows you to manage Helm releases declaratively with Kubernetes manifests via Fluxv2. Similar to Carvel packages, there are some previous configurations that you must perform in your cluster and Kubeapps installation to fully activate Flux packaging support.  

These are the pre-requisite steps to follow to make sure that both your cluster and Kubeapps deployment are ready to work with Carvel packages: 

1. Install Flux controllers in your cluster 
2. Configure Kubeapps to support Flux Helm release 
3. Install a Flux Helm repository 
4. Create a service account in your namespace 

Now everything is ready for the deployment of Helm packages via Flux.  

• Log in to Kubeapps and navigate to the “Catalog” section. Search for Flux packages:  

• Pick the package you want to install. We use Apache as an example.  

Enter the configuration parameters for your deployment. Note that for Flux, you must enter a ServiceAccount to be used for installing the package. Apart from that, the process for deploying and managing Flux packages is similar to those for any other packages available in Kubeapps.   

Laying Down the Foundation for Future Improvements 

Thanks to the implementation of the Kubeapps API service, we will be able to move forward and support different packaging formats in the future as the Kubernetes landscape and the needs of users will evolve. The current release lays down the foundation for making Kubeapps a more inclusive and secure path for Kubernetes deployments.  

Support and resources   

Since Kubeapps is an OSS project, support for this version of Kubeapps will be provided on a best-effort basis. To get a resolution on issues such as deployment support, operational support, and bug fixes, please open an issue in the Kubeapps GitHub repository. A markdown template is provided by default to open new issues, with certain information requested to help us prioritize and respond as soon as possible. Also, if you want to contribute to the project, feel free to send us a pull request, and the team will check it and guide you in the process for a successful merge.  

In addition, you can reach out to Kubeapps developers at #kubeapps on Kubernetes Slack (click here to sign up).  

For more information about the topics discussed in this blog post, refer to the following links:  

• Get Started with Kubeapps 
• Managing Carvel Packages with Kubeapps 
• Managing Flux V2 Packages with Kubeapps 
• Bitnami Application Catalog documentation for Helm charts  
• Bitnami documentation for Kubernetes deployments  

The Bitnami Helm charts and Containers Catalog is Growing!

The Bitnami Application Catalog grows every month to offer to both our catalog users and our enterprise users new Helm charts and containers to help shorten the builder’s journey for running applications in production. 

In the last 4 months, we have added more than 15 new solutions to our catalog. Additionally, delivering on our community promise, the Bitnami content team has merged more than 300 pull requests (approximately 60% of them from external contributors) and closed almost the same number of user issues.   

As always, community feedback and external contributions are essential for us to improve our solutions based on the user experience. 

Along with these new additions, we have also incorporated in the catalog two Data Platform blueprints implemented via Helm charts. 

Find in the list below the new Helm charts and containers available for you to discover. 

Bitnami Helm charts Releases (Jun - Sep 2021) 

• HAProxy 
• Grafana Tempo 
• OAuth2 Proxy 
• Concourse 
• Argo CD 

Bitnami Containers Releases (Jun - Sep 2021) 

• Argo CD  
• Dex 
• Neo4j 
• HAProxy 
• Concourse 
• OpenResty 
• Grafana Tempo 
• Grafana Tempo Query 
• Grafana Tempo Vulture 
• OAuth2 Proxy 
• Kubeapps APIs 
• OpenLDAP 

Data Platform Blueprints for Deployment Automation

Bitnami has added to its catalogs two data platform blueprints in the form of Helm charts specifically designed for enabling enterprise development teams to automate the deployment of multi-stacks data platforms on Kubernetes:  

Data Platform Blueprint 1 with Kafka-Spark-Solr  

Data Platform Blueprint 2 with Kafka-Spark-Elasticsearch  

The use of blueprints reduces the need for reconfigurations after initial data platform deployments. These Helm charts have pre-defined parameters to automate the deployment lifecycle. This default configuration covers:  

• Pod placement rules 
• Pod resource sizing rules 
• Default settings to ensure Pod access security 
• Optional Tanzu Observability framework configuration 

To learn how to use Bitnami deployment blueprints to simplify the complexity of new data analytics platform deployment, check out this series of tutorials.  

Support and Resources 

Refer to the Bitnami documentation and our Tutorials site to learn more about Kubernetes and Bitnami Helm charts and containers. 

For solving the problems you may have (including deployment support, operational support, and bug fixes), please open an issue in the Bitnami Helm chart GitHub repository.  Also, if you want to contribute to the catalog, feel free to send us a pull request, and the team will check it and guide you in the process for a successful merge.   

Visit the Bitnami Helm chart repository in GitHub for more information about our charts’ latest releases and improvements or navigate to the Bitnami Application Catalog and VMware Marketplace for deploying the solution of your choice in any Kubernetes platform. 

Bitnami Helm charts are also available for deployment via Kubeapps installation. 

 

Kubeapps 2.3.4 - Easier Deployment in VMware Tanzu™ Kubernetes Grid Clusters

A new Kubeapps release is out, and it is even easier to run in TKG clusters! The last version of Kubeapps necessitated a manual update of the current Pinniped version to the latest – this step is no longer required.  Cluster administrators can now configure Kubeapps to simply use the built-in Pinniped instance to authenticate through the same OIDC provider as they have already installed in their VMware Tanzu™ Kubernetes Grid (TKG) clusters. 

Keep reading to learn more about how to benefit from installing the Kubeapps 2.3.4 version.  

Advanced Features for Tanzu Users 

Kubeapps enables users to consume and manage open-source trusted and validated solutions through an intuitive web-based interface. 

With the previous release, Tanzu users gained the possibility of deploying Kubeapps directly to TKG workload clusters. This integration allows users to operate Kubernetes deployments through a web-based dashboard both on-premises in vSphere, and even in the public cloud on Amazon EC2 or Microsoft Azure. 

Kubeapps provides a wide catalog of ready-to-run-on Kubernetes solutions. In addition to the default Kubeapps catalog, Tanzu users have the flexibility to configure either VMware Tanzu™ Application Catalog (TAC) as a private chart repository or any of VMware Marketplace™ Catalog or the Bitnami Application Catalog as public chart repositories. This extends the number of available solutions and sources for development teams to work with. Refer to this blog post to learn more about Kubeapps key features for Tanzu users.  

How to Use Kubeapps in TKG 

However, once Kubeapps is enabled in a cluster, some concerns may arise for cluster administrators when users need to access the tool:  

• How to ensure secure authentication for users to Kubeapps? 
• How to manage the different application catalogs? 
• Is possible to customize the layout of Kubeapps to align it with my corporate branding policies? 

This new release of Kubeapps comes to address all these questions. When you install Kubeapps in a TKG cluster, you at once get:  

1) An in-built authentication system in TKG via Pinniped using the same version as the cluster runs

Authorization is delegated to the Kubernetes RBAC, which means that the same policies and roles configured for your cluster will be used when users want to enter and use Kubeapps.  

That way, the authentication to Kubeapps is completely safe since it will use the same OIDC provider as the TKG cluster uses.  

Follow these steps to configure an OIDC provider in your cluster to use for Kubeapps authentication: 

• Configure an Identity Management Provider in the Cluster 
• Configure and install Kubeapps by enabling the Pinniped Proxy component 

2) An easy way to deploy applications from the Tanzu Application Catalog and the Bitnami Application Catalog from the VMware Marketplace through Kubeapps

With Kubeapps, you can either deploy custom applications from a private repository or access the different catalogs from both public and private repositories that VMware provides. To configure application catalogs in Kubeapps once it is running on your TKG cluster, use the following instructions depending on which solutions you want to add:   

• Add the Bitnami Application Catalog from the VMware Marketplace – Public repository 
• Add the Tanzu Application Catalog for Tanzu Advanced – Private repository 

Once Kubeapps has been configured with one or more application repositories, you can start to use it to deploy, upgrade, roll back, or delete applications on your TKG clusters through its dashboard. Check out this documentation to learn how. 

3) A custom user interface

To provide a rich user experience, Kubeapps supplies a set of parameters to use for configuring a custom user interface. Learn how to configure the user interface to follow your company branding guidelines.  

Support and resources 

Since Kubeapps is an OSS project, support for this version of Kubeapps will be provided on a best-effort basis. For solving the problems you may have (including deployment support, operational support, and bug fixes), please open an issue in the Kubeapps GitHub repository. A markdown template is provided by default to open new issues with the information requested to prioritize and respond to them as soon as possible. Also, if you want to contribute to the project, feel free to send us a pull request, and the team will check it and guide you in the process for a successful merge. 

In addition, you can reach out to Kubeapps developers at #kubeapps on Kubernetes Slack (click here to sign up). 

For more information about the topics discussed in this blog post, refer to the following links: 

• Kubeapps for TKG useful links 
• Bitnami Application Catalog documentation for Helm charts 
• Bitnami documentation for Kubernetes deployments 

The Kubeapps team continues to work on the revamp of the Kubeapps backend. It will support multiple package formats really soon. Stay tuned!

Download Kubeapps 2.3.4 Now

Kubeapps Meets Tanzu Kubernetes Grid: a New Release is Out

The latest version of Kubeapps (v.2.3.2) is now available for deployment on VMware Tanzu™ Kubernetes Grid™ (TKG) workload clusters. VMware Tanzu users already benefit from deploying Kubeapps in several environments and, now with a little configuration Kubeapps can be integrated with your TKG workload cluster. In addition to this capability,  Kubeapps also features full compatibility with the latest versions of Pinniped which means that it can be used with any OIDC provider for your TKG clusters and even in managed clusters such as Azure Kubernetes Service (AKS) and Google Kubernetes Engine (GKE). 

Want to know more? Keep reading to discover the latest capabilities of Kubeapps that will enable developers and admin clusters to deploy and manage trusted open-source content in TKG clusters. 

A bit of history: What is Kubeapps? 

Kubeapps is an in-cluster web-based application that enables users with a one-time installation to deploy, manage, and upgrade applications on a Kubernetes cluster.  

This past year, the Kubeapps team has added key new features to support different use cases and scenarios. Firstly, we added support for private Helm and Docker registries and later, in Kubeapps version 2.0, we built support to run Kubeapps on various VMware Tanzu™ platforms such as Tanzu™ Mission Control, vSphere, and Tanzu™ Kubernetes Grid.  

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 from public or private chart repositories including VMware Marketplace™ and Bitnami Application Catalog 

• secure authentication to Kubeapps using an OAuth2/OIDC provider such as the VMware Cloud Service Portal 

• secure authorization based on Kubernetes role-based access control 

Key Features of Kubeapps 2.3.2

In this Kubeapps release, we have focused on delivering key user experience features including the capability to enable Tanzu users to deploy Kubeapps directly as a Helm chart in TKG workload clusters. This version is tested and validated on the latest version of TKG (v1.3.1).  

Once Kubeapps is up and running, cluster admins will benefit from having: 

• SSO for Authentication with TKG using Pinniped by configuring an OIDC provider;

• the ability to configure VMware Tanzu™ Application Catalog (TAC) as a private Chart repository; 

• the capability to configure VMware Marketplace™ Catalog and the Bitnami Application Catalog as public chart repositories;

• a customized user interface adapted to the Tanzu look and feel. 

Kubeapps support for SSO Authentication 

All these new capabilities are designed to offer a seamless experience between Kubeapps and Tanzu Kubernetes Grid clusters. 

 

How can I configure Kubeapps to run in my TKG clusters? 

 

Tanzu users can execute these simple steps to gain the maximum advantage with this new version of Kubeapps: 

• Configure your cluster to enable SSO for Authentication with TKG using Pinniped and integrate Kubeapps with the identity management provider

• Adjust the Kubeapps user interface to get a customized look and feel 

• Configure role-based access control in Kubeapps (RBAC) to manage roles and permissions among the teams in your organization 

• Deploy Kubeapps in the cluster  

• Add public and private repositories to Kubeapps: the public VMware Marketplace™ repository and your private VMware Tanzu Application Catalog for Tanzu Advanced repository 

At this point your development team can start deploying, listing, removing and managing applications in your TKG clusters from the Kubeapps user interface with total confidence! Refer to the Kubeapps documentation to learn how to deploy and configure Kubeapps on VMware Tanzu Kubernetes Grid. 

Watch the following live demo to learn how to get Kubeapps up and running in your TKG clusters:

Support and Resources 

 

Since Kubeapps is an OSS project, support for this version of Kubeapps will be provided on a best-effort basis. For solving the problems you may have (including deployment support, operational support and bug fixes), please open an issue in the Kubeapps GitHub repository. A markdown template is provided by default to open new issues with the information requested to prioritize and respond to them as soon as possible. Also, if you want to contribute to the project, feel free to send us a pull request, and the team will check it and guide you in the process for a successful merge.  

The Kubeapps documentation section is full of useful resources to help you get the best of the chart.  

Check out the step-by-step guide for deploying and configuring Kubeapps on VMware Tanzu™ Kubernetes Grid™ and the Bitnami documentation tutorials site for improving your Kubernetes skills.  

Also, for more information about VMware Tanzu Kubernetes Grid, refer to its documentation page where you will find handy information on managing your Kubernetes clusters.