One of the great aspects of working at a larger company like VMware is that there are programs like Take 3, designed to help people who meet certain criteria to take 3 months on a different project to learn new skills in other contexts and bring those skills and experience back to their team - rather than potentially looking elsewhere for a similar learning experience. This post documents my own recent learning experience of an exciting Take3 project at VMware, with the hope that others may be able to take up the opportunity to learn and bring new skills back to their teams.
The recent release of Kubeapps marks a milestone for the Kubeapps team in that we are no longer restricted to presenting a catalog of only Helm packages in our UI and, behind the scenes, we’ve addressed a long-standing security issue to remove the reverse proxy to the Kubernetes API server that our UI depended on until now. We’ve done a few overviews of the new Kubeapps APIs service which makes this possible (see Kubeapps APIs: Beyond Helm, or the TanzuTV episode 74 where Antonio gives an in-depth demo of the Carvel support), or more recently, a demo of the Flux and Carvel support together:
We’ve been able to run Kubeapps in a multi-cluster setup on various Kubernetes clusters for a while now, but this was dependent on the Kubeapps’ user being authenticated in a way that all the clusters trust. Up until now, this meant having all the clusters configured to trust the same OIDC identity provider, which is not possible in some Kubernetes environments.
Particularly, this meant we were unable to demonstrate multi-cluster Kubeapps with clusters created by Tanzu Mission Control since we can’t specify API server options, such as OIDC configuration, when creating a cluster in TMC. But that requirement has now changed thanks to a new project called Pinniped.
For the past couple of years I’ve been working on the Kubeapps project, which until recently has been a UI dashboard for the Helm project - providing a simple, web-based UI to deploy applications on Kubernetes.
I’m currently looking at generalising Kubeapps to support other Kubernetes packages formats, including Carvel from VMware of course. So I set out today to start learning more about Carvel, which in contrast to more monolithic tools like Helm, provides “a set of single-purpose, composable tools that aid in your application building, configuration and deployment to Kubernetes”.
As an example of that composability, I found I can deploy a helm chart using a set of immutable images by utilizing Helm’s new-ish support for post rendering of a chart. Here’s how…
For over a year now I’ve been working together with Andres on the Kubeapps project at VMware and have made various videos of new features that we’ve worked on, but I’ve never stepped back to give an overview and answer the more general question, “What is Kubeapps?” and show how those features work towards a single goal.
This is part two of a series detailing the steps required to run Kubeapps on a VMware TKG management cluster (on AWS) configured to allow users to deploy applications to multiple workload clusters, using the new multicluster support in Kubeapps. Though details will differ, a similar configuration works on other non-TKG multicluster setups as well.
Andres and I have been doing quite a bit of feature work in Kubeapps over the past months at VMware and one of the key features that I’ve been working on personally is enabling Kubeapps users to deploy applications not only on the cluster on which Kubeapps is installed, but to multiple other clusters as well.