Your web browser doesn't support some required capabilities.
This interactive demo works best with the latest version of Chrome, Firefox, or Safari.
An error occurred. Please reload the page or download again from the VMware Demo Library:
For VMware partners:
www.vmware.com/go/partnerdemos
For VMware employees:
www.vmware.com/go/demos
Visit the VMware Demo Library
to get more demos!
For VMware partners:
www.vmware.com/go/partnerdemos
For VMware employees:
www.vmware.com/go/demos
Unable to initialize the simulation player:
This demo file may be incomplete or damaged. Please reload the page or download again from the VMware Demo Library:
For VMware partners:
www.vmware.com/go/partnerdemos
For VMware employees:
www.vmware.com/go/demos
Drive it with your mouse, your finger, or just use the arrow keys.
Use Learn mode to learn the demo. The orange boxes show where to click.
Use Present mode to hide the orange boxes and notes.
Click a Shortcut to jump to a specific part of the demo.
VMware Cloud Foundation
Verifying a TKG Cluster Deployment
INTRODUCTION
After deploying a Tanzu Kubernetes Grid (TKG) Cluster, you can validate the environment by deploying a sample application.
In this demo we will deploy a MySQL/WordPress application inside a TKG Cluster running on vSphere with Kubernetes. At a glance, this application is comprised of the following resources:
Details about each of these resources, to include the YAML resource definitions used in this example, are covered later in the demo.
DEMO PROCEEDURE
We begin by reviewing the TKG Cluster in the vSphere Web Client.
Expanding the “wld01-ns01” namespace we see a single TKG Cluster named “gc01”.
The vSphere web client displays details about the TKG Cluster and its associated virtual machines. Note, however, that it does not provide any visibility into the TKG Cluster. To view the applications running inside the TKG Cluster, we will use the Kubernetes Dashboard.
Here we see the four virtual machines that make up the nodes in the "gc01" TKG Cluster.
From the Pods page we see there are no applications currently deployed.
At a high-level, deploying an application inside a TKG Cluster involves:
To authenticate, we run the “kubectl vSphere login” command and pass in the SSO user credentials, the name of the vSphere Namespace, and the name of TKG Cluster.
We have logged into the "gc01" TKG Cluster as the SSO user administrator@vsphere.local.
Once authenticated, we are presented with a list of available namespaces. Notice that the TKG Guest cluster “gc01” is listed as an available context. We will switch our context to “gc01”.
We are now working in the context of the TKG Cluster “gc01”.
There are two ways to create pods inside a TKG Cluster: directly or indirectly. You create a pod directly by deploying a pod spec. You create a pod indirectly by defining a higher-level resource, such as a Deployment. When deploying pods indirectly, a service account creates the underlying pod. This requires binding a Pod Security Policy (PSP) to a service account in the TKG Cluster. This is done via a RoleBinding.
For more informationon PSPs and RoleBindings see: https://docs.vmware.com/en/VMware-vSphere/7.0/vmware-vsphere-with-kubernetes/GUID-4CCDBB85-2770-4FB8-BF0E-5146B45C9543.html?hWord=N4IghgNiBcIEoHsIFMBCBLAdgEywcxAF8g).
Note, TKG Clusters do not provide default RoleBinding. Rolebinding must be done manually prior to deploying applications.
This YAML file creates a RoleBinding that grants access to all service accounts using the default PSP “vmware-system-privileged”.
To apply the Rolebinding we run the command “kubectl apply -f RoleBindingTKC.yaml”.
With the RoleBinding in place we are now ready to deploy our MySQL/WordPress application. Let’s start by checking for any existing pods.
We see that our namespace is currently empty, as observed by the “no resources found in default namespace” message.
In this example, we will deploy the MySQL/WordPress application using a Kustomize File.
For more information on Kubernetes Kustimze Files see https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/.
We begin by creating a “kustomization.yaml” file in our working directory on our Linux workstation.
Inside the kustomization.yaml file we define a “secretGenerator” with the password that we will use for the MySQL instance. We have also identified two additional YAML files that will be used to deploy our application: mysql-deployment.yaml and wordpress-deployment.yaml.
Here we see the mysql-deployment.yaml file.
Inside the mysql-deployment.yaml file we have resource definitions that defined the components that make up our MySQL application. Here we see the resource definitions for the MySQL “Service”, “PersistentVolumeClaim”, and “Deployment”.
Along with the mysql-deployment.yaml, we also have the wordpress-deployment.yaml.
Just like with MySQL, we see resource definitions for the “Service”, “PersistentVolumeClaim”, and “Deployment” components.
We place all three files (kustomization.yaml, msql-deployment.yaml and wordpress-deployment.yaml) into our working directory on our Linux workstation.
When then run the “kubectl apply -k ./” command to deploy the application. (Remember, we already logged in and set our context to the ‘gc01’ TKG Cluster, so this is where the application will be deployed.)
We are able to monitor the deployment using the ‘kubectl’ command.
Running the ‘kubectl get pods’ command displays the pods that have been deployed.
Running the ‘kubectl get deployments’ command displays the Kubernetes Deployments.
Running the ‘kubectl get services’ command displays the Kubernetes Services.
Note the EXTERNAL-IP for the WordPress instance is set to 192.168.51.4. We will use this IP to connect to the WordPress instance in an upcoming step in the demo.
Running the ‘kubectl get persistentvolumeclaims’ displays the persistent volume claims.
We can also view these components from Kubernetes Dashboard.
Here we see the two pods that were deployed. One for the WordPress instance and a second for the MySQL database instance.
Here we see the Deployment resources.
Along with the two Persistent Volume Claims. Again, one for WordPress and the second for MySQL.
Here we see the service resources. Notice the WordPress service has a hyperlink to the external IP that has been assigned.
Clicking the hyperlink we are connected to the WordPress Instance.
Where we can verify the application is running.
We have successfully deployed our example WordPress/MySQL application. Next, we’ll remove the application.
Removing the WordPress/MySQL application is easy with the Kustomization.yaml file. We simply type ‘kubectl delete -k ./’
The output shows that the secret, service, deployment and persistent volume claims have all been removed.
When we run the “kubectl get pods” command again, we are able to confirm that the pods have been removed.
In the Kubernetes Dashboard we see that the Services page has automatically been updated to show the removal of the WordPress and MySQL Services
We are also able to confirm that the persistent volume claims have been removed.
Along with the deployments...
and the Pods.
This completes our demonstration on validating our TKG Cluster running onto of our vSphere with Kubernetes instance.
SUMMARY
In this demo we deployed an example MySQL/WordPress application into a TKG Cluster using a Kustomization file. We saw how to login to the TKG Cluster, configure role bindings, and deploy the application. We then verified the application was working. After confirming the application was working, we then removed the application.
For more VMware Cloud Foundation demos visit the Cloud Foundation Resource Center at https://vmware.com/go/vcfrc.
For more information on VMware Cloud Foundation, visit our website at https://vmware.com/go/cloudfoundation.