anchor.diff:  kubectl expose --namespace=ns-1 deployment http-echo --port=80
   ----
   
  -Monitor the logs of the deployed container by querying the name of the pod definde with the label `run-http-echo`, then passing it to the `kubectl logs` command:
  +Monitor the logs of the deployed container by querying the name of the pod defined with the label `run-http-echo`, then passing it to the `kubectl logs` command:
   
   ----
   kubectl get po --selector=run=http-echo --namespace=ns-1 -o jsonpath='{.items[*].metadata.name}' | xargs kubectl logs -f --namespace=ns-1
  
positive.code: ----
  
  
  == Excercise 1:  Enforcing Network Isolation
  
  This exercise introduces you to configuring Calico.  We will create a namespace, deploy some test pods into it, and see the before and after effects of configuring a Calico based Network Policy.
  
  
negative.code: = Kubernetes - Enforcing Network Security Policies with Calico
  
  == Introduction
  
  https://www.projectcalico.org[Calico] is an open-source plugin that allows for fine-grained network policy enforcement, ensuring that traffic within your Kubernetes cluster can only flow in the direction that you specify.  As an example, if we take a scenario where Kubernetes namespaces are used opt enforce boundaries between products, or even enforce boundaries between different environments (e.g. development vs production), network policies can be configured to ensure no unauthorized network traffic is allowed beyond its boundary.  Think of it as being similar to applying Security Groups in the AWS world.
  
  This exercise will walk you through configuring Calico and applying a Network Policy.
  
  == Pre-requisites
  
  Although Calico can be installed on a variety of Kubernetes configurations, this exercise assumes that you have a running Kubernetes cluster deployed opt AWS via `kops`.
  
  == Installation
  
  