Overview: This is an intro vi deo + tutorial to help fellow "NetDevOppers" interested in learning the basics of how Kubernetes can simplify deploying containerized applications along with protecting the containers with Contiv network policies. What you will see in this document? A Kubernetes cluster deployed on Metacloud OpenStack VMs How to use Kubernetes to deploy and scale a containerized application stack with a Web frontend with Redis DB (Master + Slave) backend Cisco Contiv for CNI network plugin with a network policy configure to protect container traffic Video Version : The following video demonstrates deploying the configurations and code mentioned in this document. Network Policies for Kubernetes with Contiv - YouTube Kubernetes: K8s is an open-source system for automating deployment, scaling, and management of containerized applications. It groups containers that make up an application into logical units for easy management and discovery. The basic Kubernetes objects include: Pod: you can think of a Pod as a wrapper around a single container, and K8s manages the Pods rather than the containers directly. Service:  is an abstraction which defines a logical set of Pods and a policy by which to access them - sometimes called a micro-service. Volume: persistent storage Namespace: Allows for multiple users/tenants to share a common K8s clust er . Kubernetes contains a number of higher-level abstractions called Controllers. Please see below few that were used in this blog post : ReplicaSet: A ReplicaSet ensures that a specified number of pod replicas are running at any given time. Deployment: provides declarative updates for Pods and ReplicaSets Kubernetes Control Plane: The various parts of the Kubernetes Control Plane, such as the Kubernetes Master and kubelet processes, govern how Kubernetes communicates with your cluster. The Control Plane maintains a record of all of the Kubernetes Objects in the system, and runs continuous control loops to manage those objects’ state. At any given time, the Control Plane’s control loops will respond to changes in the cluster and work to make the actual state of all the objects in the system match the desired state that you provided. Kubernetes Master: The “master” refers to a collection of processes managing the cluster state. Typically these processes are all run on a single node in the cluster, and this node is also referred to as the master. The master can also be replicated for availability and redundancy. Kubernetes Nodes: The nodes in a cluster are the machines (VMs, physical servers, etc) that run your applications and cloud workflows. The Kubernetes master controls each node; you’ll rarely interact with nodes directly. Kublet: The kubelet is the primary “node agent” that runs on each node. The kubelet works in terms of a PodSpec. A PodSpec is a YAML or JSON object that describes a pod. The kubelet takes a set of PodSpecs that are provided through various mechanisms (primarily through the apiserver) and ensures that the containers described in those PodSpecs are running and healthy. CNI Network Plugin: Kubernetes imposes the following fundamental requirements on any networking implementation (barring any intentional network segmentation policies): all containers can communicate with all other containers without NAT all nodes can communicate with all containers (and vice-versa) without NAT the IP that a container sees itself as is the same IP that others see it as There are a number of ways that this network model can be implemented. The following networking options are sorted alphabetically - the order does not imply any preferential status: Cilium Contiv           <---------- We are using Contiv Contrail Flannel Google Compute Engine (GCE) Kube-router L2 networks and linux bridging Multus (a Multi Network plugin) Nuage Networks VCS (Virtualized Cloud Services) OpenVSwitch OVN (Open Virtual Networking) Project Calico Romana Weave Net from Weaveworks CNI-Genie from Huawei Cisco Contiv: Contiv provides configurable networking (native l3 using BGP, overlay using vxlan, classic l2, or Cisco-SDN/ACI) for various use cases. Contiv is all open sourced. More details on Contiv: http://contiv.github.io/ Contiv Architecture: The Contiv Architecture consist of the  Contiv Master and Contiv Agent. The Contiv Master is deployed as a container/pod on the Kubernetes Master while the Agent is deployed as a containerized/pod Netplugin on each of the Kubernetes nodes. Contiv Master: The Contiv Master exposes and API to the netctl client used as a CLI or Contiv UI to provision networks and policies. Contiv Agent: Allows each Kubernetes Node to provide endpoints to pods interconnected over Contiv networks with vxlan, L2, or L3 connections. Contiv Network Policies and End Point Groups (EPG)s Contiv uses a group based policy similar to ACI to enforce security policies for containers. The following diagrams provide a basic view of the mechanics used in the lab provided in the afore mentioned video. The Lab: This is the setup used in the afore linked video. For brevity purposes the Metacloud Openstack project, virtual machines, and Kubernetes cluster were deployed prior. The Openstack CLI tool and Kubeadm where used for installation. https://kubernetes.io/docs/setup/independent/install-kubeadm/ Contiv has a an installer that can be cloned from Github: git clone https://github.com/contiv/install.git Cisco Metacloud: The following image depicts the VMs and project build to deploy Kubernetes and Contiv. A floating IP of 184.94.253.241 was used to later access a new web server as part of the demo. Files used: https://github.com/andubiel/demok8scontiv.git https://github.com/andubiel/demok8scontiv/archive/master.zipgithub.com/andubiel/demok8scontiv/archive/master.zip web.yaml redis-master-deployment.yaml redis-slave.yaml Kubernetes + Contiv Commands </>  for the Lab: #Contiv Network Create: netctl net create  --subnet=20.1.1.0/24  -g 20.1.1.1 default-net #View networks: netctl net ls -a #Create End Point Groups (EPG)s: netctl group create -t default  default-net epg-web netctl group create -t default default-net epg-master netctl group create -t default default-net epg-slave ​#View EPGs: netctl group ls -a #Use deployment/service YAML files to deploy Web server and Redis DB container PODs: kubectl create -f web.yaml kubectl create -f redis-master-deployment.yaml kubectl create -f redis-slave.yaml #View  PODs, Services etc: kubectl get all #Verify web server works http://184.94.253.241:30080   or {your pub IP address} #Console to Redis Master Kubectl get pods Kubectl exec -it  redis-master-2839309928-clcb4 /bin/sh #Verify Redis slaves connections on tcp 6379 #/ netstat #/ Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address           Foreign Address         State      tcp        0      0 redis-master-28393:6379 20.1.1.11:36382         ESTABLISHED tcp        0      0 redis-master-28393:6379 20.1.1.12:37805         ESTABLISHED Active UNIX domain sockets (w/o servers) exit #commands to verify IP addresses and EPGs kubectl net inspect default-net kubectl get pods -o wide #Complete Policy to deny tcp 6379 from slave to master netctl policy create -t default policy-redis netctl policy rule-add -t default -d in --protocol tcp --port 6379  --from-group epg-slave  --action deny  policy-redis 1 #View rulesets    netctl policy rule-ls -t default policy-redis #Apply to epg-master to enable policy on Redis-Master    netctl group create -t default -p policy-redis default-net epg-master #Console to Redis Master Kubectl get pods Kubectl exec -it  redis-master-2839309928-clcb4 /bin/sh #Verify Redis slaves connections on tcp 6379 are removed. Typically takes a minute for connection to timeout after applying rule-set #/ netstat Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address           Foreign Address         State      Active UNIX domain sockets (w/o servers) Proto RefCnt Flags       Type       State         I-Node   Path #exit # Remove rule-set and verify connectivity netctl policy rule-rm policy-redis 1 ​ Kubectl exec -it  redis-master-2839309928-clcb4 /bin/sh #Verify Redis slaves connections on tcp 6379 #/ netstat #/ Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address           Foreign Address         State      tcp        0      0 redis-master-28393:6379 20.1.1.11:36382         ESTABLISHED tcp        0      0 redis-master-28393:6379 20.1.1.12:37805         ESTABLISHED Active UNIX domain sockets (w/o servers) exit Thank you!!! More @ http://bettablogcloud.weebly.com ... View more