Before you begin this walkthrough, ensure you are logged onto the VMware Enterprise PKS desktop by following the instructions found here. If you ran out of time and coming back to this lab later, your clusters might be deleted so you need to authenticate and recreate k8s cluster as mentioned in VMware Enterprise PKS - Quick Start Guide.

The command line tool used to interact with Kubernetes clusters is kubectl. If you took module 2 of the lab, you have some familiarilty with using kubectl. We will dive deeper here. While you can use curl and other programs to communicate with Kubernetes at the API level, the kubectl command makes interacting with the cluster from the command line easy, packaging up your requests and making the API calls for you. In this section you will become familiar with some of the basic kubectl commands and get comfortable with a few of the constructs we described in the overview section. You will focus on system level components before moving on to applications. Module 2 already deployed a k8s cluster. The cluster contains 3 nodes - one master and two workers. Let's take a look at what we have deployed.

Note: This Lab assumes that k8s cluster creation was already performed in Module 2. If you are starting with this Module and have not gone through lab 2, please perform the following steps from Module 2 before continuing.

Let's start getting familiar with using the Kubernetes CLI. You will start using the "get" command to view system level components of your Kubernetes cluster.

That's it for the system services. Let's move on to Namespaces.

Namespaces are intended for use in environments with many users spread across multiple teams, or projects. Namespace provides a scope for a name. Names of resources need to be unique within a namespace, but not across namespaces. They are a way to divide cluster resources between multiple users. As Kubernetes continues to evolve, namespaces will provide true multi-tenancy for your cluster. They are only partially there at this point. You can reference objects in a namespace by applying command line label/selector and permanently by setting the context for your environment. You will do both in this section.

Before interacting with your cluster you must configure kubectl to point to your cluster and provide the namespace, along with any authentication needed. In our case, we created the context in the last section using "pks get-credentials" command. That command updated the file C:\Users\<username>/.kube/config to hold the kubectl configuration info. By setting up the config file, you remove the need to include that information on each kubectl command. The cluster config names the cluster and points kubectl to a specific certificate and API Server for the cluster.

The set-context command creates a config file that is used by kubectl to interact with the cluster. Our file is much simpler as we only have one cluster with one namespace. In production environments you might see key or certs, as well as specific user and cluster settings that explicitly define the context for how to interact with a particular cluster. View the contents of the config file.

You don't actually have to cat the config directly to see the configuration. kubectl provides a command to do that.

Let's take a look at the namespaces in our cluster. What we care about for this lab are the kube-system and default namespaces. As we have previously seen, kube-system contains the Kubernetes cluster system objects. Default will be where we are deploying our applications.
​

Now we will see how the namespaces label selector changes the output of the get commands.
Our current context is default, and you have not created any application pods yet. So no resources are found. As you saw previously, the kube-system namespace is running the Kubernetes cluster system services.

So far you have interacted with your Kubernetes cluster in the context of system services. You looked at pods that make up kube-system, set your CLI context and got some familiarity with CLI constructs. Now you will see how these relate to actually deploying an application. First a quick review on a couple of Kubernetes object definitions.
​
​• Pod - A group of one or more containers (such as Docker containers), the shared storage for those containers, and options about how to run the containers. A pod's contents are always co-located and co-scheduled, and run in a shared context.
​
​• Service - Kubernetes pods are ephemeral. When they die, they are recreated - not restarted. Replication controllers in particular create and destroy pods dynamically (e.g. when scaling up or down or when doing rolling updates). While each pod gets its own IP address, even those IP addresses cannot be relied upon to be stable over time. This leads to a problem: if some set of pods (lets call them backends) provides functionality to other pods (lets call them frontends) inside the Kubernetes cluster, how do those frontends Und out and keep track of which backends are in that set? A Kubernetes Service is an abstraction which defines a logical set of pods and a policy by which to access them - sometimes called a microservice.
The set of pods targeted by a Service is (usually) determined by a Label Selector. Not only does a service provide discovery of the underlying pods, but handles East/West Load Balancing across them through the Kube-Proxy process running on each Node.
​
​• Deployment - Provides declarative updates for pods and replica sets (the next-generation replication controller). You only need to describe the desired state in a deployment object, and the deployment controller will change the actual state to the desired state at a controlled rate for you. You can define deployments to create new replica sets, or remove existing deployments and adopt all of their resources with new deployments.
Just a reminder that Module 1 of this lab goes into a more detailed explanation of these
components.

Navigate to the folder with different k8s application manifest files in powershell

Central to Kubernetes are the process control loops that attempt to continuously reconcile the actual state of the system with the desired state. The desired state is defined in object specifications that can be presented to the system from yaml or json specification files. You are going to deploy a simple nginx web server. The yaml file specification will create a Deployment with a set of pods and a service. Let's see how that works.

Let's break apart the components of this file.

The next spec is for the service. In addition to the name and label, the spec itself has two very important components:

The nginx.yaml defines the desired state for the deployment of this application, but we haven't defined what it actually does. Nginx is an application that can act as a Web Server or reverse proxy server. You will deploy the application, look at its running components and verify that the web server is running through your browser.
​

We have running pods, but no way to access the service from our network. Remember that the pod IP addresses are private to the cluster (actually we break that rule because of the lab setup, generally this will be true). Also, what happens if the replication controller has to restart one of them and the IP changes. So we need the service to discover our application endpoints

If you see the "Welcome to nginx" page, your Web Server is running.

As discussed previously with services, the labels are very important for Kubernetes to group objects. Let's see how that works with replica sets.
​

Applications may need to be scaled up or down to improve performance or availability. Kubernetes can do that with no application downtime by adding or removing pods. Remember that the success of scaling is dependent upon the underlying application's ability to support it.
Let's scale our deployment and see what happens. Remember that scaling is changing the desired state for our app, and the replication controller will notice a difference between desired state and current state, then add replicas.

You may have to execute get pods more than once to see the new running pods, but you have gone from an application that had three copies of the nginx web server running to five replicas. The service automatically knows about the new endpoints and nsx-kube-proxy has updating the control Vows to provide internal load balancing across the new pods. Pretty cool!!

You can also remove unneeded capacity by reducing the number of replicas in your deployment.

Now let's delete our deployment. Its very simple. Just reference the same spec file you used to create the deployment.