4th May 2020

Deploying an application using Kubeapps to Tanzu Kubernetes Cluster

Last post we deployed kubeapps to TKG. This time we’re going to use it to deploy something.

Create a new namespace from kubeapps
Browse the catalog for WordPress, review and submit for deployment
Troubleshoot and fix the deployment
Monitor to completion and login

Create a new namespace from kubeapps

Somewhat out of the eyeline within kubeapps is the namespace selector, if we want to deploy applications into particular namespaces we need to slect the namespace here, or if it isn’t available create one. I’m going to create a new namespace called ‘tkg-wordpress’

Browse the catalog for WordPress, review and submit for deployment

With the new namespace created, I need to search the catalog for available applications that I can deploy, I’m going to test by deploying wordpress into my tkg-wordpress namespace;

After selecting the application and hitting deploy, you are taken to a final configuration screen before submitting. Here for wordpress installation details can be added to a form;

or YAML;

I didn’t change anything in either and clicked submit.

Troubleshoot and fix the deployment

After hitting submit, you can track the progress of the installation from kubeapps itself, it does a really good job of telling you when resources are available – or if if they haven’t come online.

From reviewing kubeapps I can see that the deployment managed to create the service load balancers but got stuck deploying the pods.

I’d seen similar issues deploying onto TKG from kubeapps before, in that case it was linked to persistent volume claims, sure enough when I queried the TKG cluster the PVCs where stuck pending and the events for the namespace highlighted that the PVC binding had failed.

The fix is easy enough, there are two locations in the wordpress YAML that reference using default storage claims if the values are unset – it looks like even though I only have one storage claim configured (below) as this is not set to default it is being ignored by the deployment… which is slightly annoying and I’ll come back to later.

As mentioned the fix is very simple, I added values to the storage class sections of the YAML that lined up with the storage class available in the TKG cluster. As highlighted by the Diff below (which is another excellent view that kubeapps provides.

Fix applied I resubmitted and we can watch the installation.

Monitor to completion and login

Again I can use the kubeapps GUI to monitor the deployment of resources, straight away I can see that the deployment has been more successful;

The pods are deployed alongside the service load balancer and browsiing further down the application page I can see more details of the deployment;

Including more information about the deployed pods that have been deployed and specific information about the load balancer configuration. Browsing to the cluster IP I can hit the deployed wordpress site and pulling the logon information from the secrets section of the deployment I can also login to the admin interface;

Pretty cool, I appreciate that this example is for wordpress – but this is extensible to any containerised application or service, either hosted in a public repository or pulled from a private location. At the time of writing there are hundreds of applications available

Kubeapps, Tanzu Kubernetes and Persistant Volume Claims

A couple of times now I’ve hit scenarios where PVCs are not created when deploying applications via kubeapps. As mentioned it seems that many of the available charts make use of deploying PVCs to a default storage claim, if there is no default storage claim then the deployment fails. Now to set a storage claim as default is simple enough by running the following command (edit the part after storageclass to do this for yourself);

“kubectl patch storageclass vi-cluster1-vsan-storage-policy -p ‘{“metadata”: {“annotations”:{“storageclass.kubernetes.io/is-default-class”:”true”}}}’

Having run that I checked the storageclass to see if it was being flagged as default, and indeed it was;

I then retried a new wordpress deployment, only for it to fail again. sure enough when I checked back to my TKG cluster the default flag was missing again…

Not sure if this is a bug or a feature of TKG, but for the moment I would specify storage classes when deploying using kubeapps.

UPDATE: I’ve since discovered that this is not desired behaviour and documented the fix in this post

Thanks

Simon