- [Instructor] Okay, welcome back. In this lecture, I'm going to provide a quick demonstration as to how to test and validate your network policies, ensuring that when deployed they behave in the desired manner. When we're creating and setting up network policies within the cluster it's incredibly useful to jump into the cluster and act or simulate as if we were one of the pods, generating network traffic to test the rules defined within the network policies. Let's see how this is done. Before we start, keep in mind that the diagram, as seen here, represents the current status of our networking policy deployment. 

Okay to begin with, let's retrieve the currently deployed set of pods within the Cloud Academy name space. In particular, I want to view the pod IP addresses, therefore I'll run the command kubectl get pods -o wide. Next, I'm going to run the following kubectl run command to spin up a pod based on the busybox image and importantly applies the label role=api to it. Before I execute this command, let's review each of the parameters to ensure you understand what each parameter accomplishes.

- -rm, this automatically removes the container when it exits. We add this to keep the cluster clean, since this pod is being used on a temporary basis, just for testing.

- i and --tty often presented in the combined form of just -it is used to create and provide an in-directive shell connected to the container's stdin.

-- image busybox, this is the docker image we'll launch. Busybox is an official docker image containing many common UNIX utilities. In particular, we'll be making use of the telnet utility.

-- restart, the restart policy to apply when the container exits. We don't need it to restart.

--labels, the metadata in the form of key-value pairs. 

In this demonstration, we're using the label role=api to simulate being an api pod. This allows us to test any of the network policies, which declare an ingress pod selector with the same label. Finally, the remaining double dash at the end of the command is used to separate the arguments you want to pass to the command from the kubectl arguments. In this case, we are simply requesting sh to launch. Where sh is a command language interpreter. Okay, we're all good to go. Let's execute this command and simulate being an API pod. 

Excellent, the pod has started and we're now inside it. Let's now use the telnet command and attempt a network connection to the mongo-0 pod whose pod IP address is 10.43.114.71 on port 27017. This is the default port that the mongo server listens on. And as expected this has connected successfully. Again, I'll highlight the fact that we're simulating being an API pod, by virtue of the role=api label. Okay, let's exit the current telnet session by entering the key sequence, Ctrl + C, followed by e and then exit the pod by typing exit, like so. 

I'll now clear the terminal and this time let's view all of the currently deployed network policies by running the command kubectl get netpol. Here we can see the three network policies deployed during the previous lecture. Let's now delete the allow-to-mongo-from-api network policy by running the command kutectl delete netpol allow-to-mongo-from-api. Okay, this looks good. The network policy has been successfully deleted. Again, let's clear the terminal and repeat the previous kutectl run command where we again attempt the same telnet connection to the same MongoDB pod on port 27017. This time you can see the connection is indeed denied. This is based on the fact that the default deny policy is now blocking the traffic. 

Okay, let's roll back this last delete and reapply all network policies. We'll run command kubectl apply -f and give it the netpol/ directory name. Finally, we'll jump back into the browser and retest the application by reloading it to ensure that is functional again. 

Okay, that concludes the network policy testing demonstration. The key takeaway from this lecture is knowing how to simulate and test network connections that your network policies have been explicitly designed to allow or deny.