Loading Wird geladen Cargando 正在加载 Chargement en cours 載入 Carregando 読み込み中 로드 중 Caricamento in corso Загрузка  

Sorry

Your web browser doesn't support some required capabilities.

This interactive demo works best with the latest version of Chrome, Firefox, or Safari.

Sorry

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

Sorry

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

Sorry

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

X

This is an interactive demo

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.

X

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:

  • Pods – One for the MySQL instance and one for the WordPress instance.
  • Deployments – Two deployments are defined to provided declarative updates to the pods.  Again, one for MySQL and one for WordPress. 
  • Persistent Volume Claims – Two PVCs are created using the default vSAN Storage Policy.  One for the MySQL instance and the second for the WordPress instance.
  • Services – One service object for MySQL and another for WordPress. 

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.

  • Click wld01-ns01

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.

  • Click the ‘Kubernetes Dashboard’ browser tab

Here we see the four virtual machines that make up the nodes in the "gc01" TKG Cluster.

  • Click Pods

From the Pods page we see there are no applications currently deployed.

  • Click the Putty icon

At a high-level, deploying an application inside a TKG Cluster involves:

  1. Authentication to the TKG Cluster
  2. Setting the Kubernetes pod security policy (PSP)
  3. Deploying the application 

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.

  • Click Continue

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

  • Click Continue

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.

  • Click Continue

This YAML file creates a RoleBinding that grants access to all service accounts using the default PSP “vmware-system-privileged”.

  • Click Continue

To apply the Rolebinding we run the command “kubectl apply -f RoleBindingTKC.yaml”. 

  • Click Continue

With the RoleBinding in place we are now ready to deploy our MySQL/WordPress application.  Let’s start by checking for any existing pods. 

  • Click Continue

We see that our namespace is currently empty, as observed by the “no resources found in default namespace” message. 

  • Click Continue

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. 

  • Click Continue

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. 

  • Click Continue

Here we see the mysql-deployment.yaml file. 

  • Click Continue

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

  • Click Continue to view the rest of the mysql-deployment.yaml file
  • Click Continue

Along with the mysql-deployment.yaml, we also have the wordpress-deployment.yaml. 

  • Click Continue

Just like with MySQL, we see resource definitions for the “Service”,  “PersistentVolumeClaim”, and “Deployment” components. 

  • Click Continue to view the rest of the mysql-deployment.yaml file
  • Click Continue

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

    • Click Continue

    We are able to monitor the deployment using the ‘kubectl’ command. 

    • Click Continue

    Running the ‘kubectl get pods’ command displays the pods that have been deployed. 

    • Click Continue

    Running the ‘kubectl get deployments’ command displays the Kubernetes Deployments. 

    • Click Continue

    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. 

    • Click Continue

    Running the ‘kubectl get persistentvolumeclaims’ displays the persistent volume claims.

    We can also view these components from Kubernetes Dashboard.

    • Click the Kubernetes Dashboard browser tab

    Here we see the two pods that were deployed.  One for the WordPress instance and a second for the MySQL database instance. 

    • Click Deployments

     Here we see the Deployment resources.

    • Click the Scroll Bar
    • Click Persistent Volume Claims

    Along with the two Persistent Volume Claims.  Again, one for WordPress and the second for MySQL. 

    • Click Services

    Here we see the service resources.  Notice the WordPress service has a hyperlink to the external IP that has been assigned. 

    • Click 192.168.51.4:80

    Clicking the hyperlink we are connected to the WordPress Instance. 

    • Click Continue

    Where we can verify the application is running. 

    • Click “X” to close the WordPress browser tab

     We have successfully deployed our example WordPress/MySQL application.  Next, we’ll remove the application.

    • Click the Putty icon in the system tray

    Removing the WordPress/MySQL application is easy with the Kustomization.yaml file.  We simply type ‘kubectl delete -k ./’ 

    • Click Continue

    The output shows that the secret, service, deployment and persistent volume claims have all been removed. 

    • Click Continue

    When we run the “kubectl get pods” command again, we are able to confirm that the pods have been removed. 

    • Click the Kubernetes Dashboard Browser tab

    In the Kubernetes Dashboard we see that the Services page has automatically been updated to show the removal of the WordPress and MySQL Services

    • Click Persistent Volume Claims

    We are also able to confirm that the persistent volume claims have been removed. 

    • Click Deployments

    Along with the deployments... 

    • Click Pods

    and the Pods. 

    • Click the vSphere browser tab

    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.

    How likely is it that you would recommend this demo to a friend or colleague?
    Not at all likely Extremely likely
    Thanks, we appreciate your feedback!