Showing results for 
Search instead for 
Did you mean: 

Protect Containers running in Kubernetes on Metacloud with Cisco Contiv



This is an intro video + 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


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 cluster.

Kubernetes contains a number of higher-level abstractions called Controllers. Please see below few that were used in this blog post :

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.

Screenshot 2017-10-18 20.52.06.png

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.


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:

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.

Screenshot 2017-10-25 10.46.47.png

Screenshot 2017-10-20 11.18.54.png

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.

Screenshot 2017-10-25 10.11.22.png

Screenshot 2017-10-25 10.47.22.png

Screenshot 2017-10-25 10.47.03.png

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.

Contiv has a an installer that can be cloned from Github: git clone

Screenshot 2017-10-20 11.45.08.png

Cisco Metacloud:

The following image depicts the VMs and project build to deploy Kubernetes and Contiv. A floating IP of was used to later access a new web server as part of the demo.

Screenshot 2017-10-20 11.55.47.png

Files used:




Content for Community-Ad

This widget could not be displayed.