- [Instructor] Okay, welcome back. In this lecture we will now deploy the front end into the cluster. In this lecture we will provision the following Kubernetes' resources. 

A deployment, consisting of four pods, using the Cloud Academy front end V1 docker image. Which, will be configured to serve TCP traffic on port 80. The deployment will be configured for rolling updates and have liveness and readiness probes configured. We will create a service, which provides a stable, private vip, and provides internal lie bouncing over the four front end pods configured to listen on port 80. And, finally, an ingress resource will be created, which will forward external TCP port 80 traffic to the front end service. Okay, let's start. Within the terminal, I'll first navigate into the "voteapp" Kubernetes project directory. And here we will examine the directory structure using the "tree" command. 

Next, I'll use the "kubeclt" command to perform and ordered deployment of the files stored within the front end directory. We can do this by simply running the following command. "kubectl apply -f" and give it the name of the directory, in this case, "frontend/". Great, we can see here that the deployment service and ingress resources have been successfully provisioned. 

From here, let's clear the terminal and we'll run the following "kubectl" command to view the details for all pods currently deployed. We'll run "kubectl get pods -o wide" Here, indeed, we can see that the four front end pods have successfully launched, and are all in the running status. We can test the "engine x htdp" service exposed within the pod by retrieving the pod's IP address, like so and then curling to it. In this case we will send just a hid request indicated by the dash, capital "I" parameter. Here we can see that the engine X service on the pod has responded correctly within HTDP 200 response code. Which, is what we would expect. Next, we will perform the same test but this time using the front end registered service vip. "kubectl get svc" for service. 

Again, we use the "curl" command to curl to this IP address. And again, we can see that the engine X service on the pod has responded correctly with another HTDP 200 response code. Finally, we need to test this externally using the browser. To do so, let's first query for the public IP address that has been assigned to our EC 2 instance. 

Here we can see that is 52.42.21.253 let's copy this. Keep in mind that if you're forming your own deployment, then your public IP address will be different and even possibly just local host or 127.0.0.1 if you're deploying to your local wip station. Now, I'll jump into the browser browse to the nip.io in its name "frontend.52.42.21.253.nip.io" This is the address that we previously configured and updated in one of the earlier lectures. Remembering that the ingress resource requires a proper DNS name, not just a raw IP address. Regardless, the expectation here is that this will stall fail. And, as you can see, this has, indeed, failed. Why so? Well, we haven't yet deployed the engine X ingress controller. Which actually performs the forwarding of the external HTDP traffic to the back end service. 

Let's go ahead and set this up now, in the next lecture.