Kubernetes running under Docker UCP uses the Calico CNI plugin so that you can use Kubernetes NetworkPolicies to control pod to pod communication as well as communication between pods and other network endpoints.
This blog post will walk you through an example of configuring Kubernetes NetworkPolicies. We will block traffic from one namespace into another namespace, while still allowing external traffic to access the “restricted” namespace. As a high-level use case, we will consider the situation where a development team is working on multiple branches of a project, and the pods in the different branches should not be able to communicate with each other. If you are not familiar with the basic concepts of NetworkPolicies, see the Kubernetes documentation here.
In early 2018 Docker made an announcement of the release of its newest Docker Enterprise 2.0 product. This newest release provides a significant advancement in the Docker platform in the form of a choice between Swarm and/or Kubernetes orchestration. But that’s not what i want to talk about.
Layer 7 Routing
Another great addition to the platform is the replacement of the HTTP Routing Mesh, known as HRM, with a new Layer 7 routing and load balancing. This latest enhancement is built upon the new Interlock 2.0 architecture which provides a highly scalable and highly available routing solution for Swarm. Interlock provides the same functionality as HRM but also includes 2 new features: 1) path based routing and 2) SSL termination.