Understanding Container-to-Container Networking
This topic provides an overview of how Container-to-Container Networking works.
The Container-to-Container Networking feature enables app instances to communicate with each other directly. When the Container-to-Container Networking feature is disabled, all app-to-app traffic must go through the Gorouter.
Container-to-Container Networking integrates with Garden-runC in a Diego deployment. The Container-to-Container Networking BOSH release includes several core components, as well as swappable components.
To understand the components and how they work, see the diagram and tables below. The diagram displays the Container-to-Container Networking components in blue and other CF components in gray. The diagram also highlights swappable components in yellow.
The Container-to-Container Networking BOSH release includes the following core components:
|Cloud Foundry Command Line Interface (CF CLI) plugin||A plugin that you download to control network access policies between apps.|
|Policy Server||A central management node that does the following:
|Garden External Networker||
A Garden-runC add-on deployed to every Diego cell that does the following:
The Container-to-Container Networking BOSH release includes the following swappable components:
|Flannel CNI plugin
||A plugin that provides IP address management and network connectivity to apps.
|VXLAN Policy Agent
||Enforces network policy for traffic between apps as follows:
The diagram below illustrates how two app instances communicate in a deployment without Container-to-Container Networking enabled. Traffic from App A must route out and back in through the Gorouter, which restricts performance and the protocol used to send the traffic. In this scenario, App B does not know the real source of the traffic it receives and must trust all inbound traffic.
The diagram below illustrates how app instances communicate in a deployment with Container-to-Container Networking enabled. In this example, the operator creates two policies to regulate the flow of traffic between App A, App B, and App C.
- Allow traffic from App A to App B
- Allow traffic from App A to App C
If traffic and its direction is not explicitly allowed, it is denied. For example, App B cannot send traffic to App C.
Both application security groups (ASGs) and Container-to-Container Networking policies affect traffic from app instances. The following table highlights differences between ASGs and Container-to-Container Networking policies.
|ASGs||Container-to-Container Networking Policies|
|Policy granularity||From a space to an IP address range||From a source app to a destination app|
|Scope||For a space, org, or deployment||For app to app only|
|Traffic direction||Outbound control||Policies apply for incoming packets from other app instances|
|Source app||Is not known||Is identified because of direct addressability|
|Policies take affect||After app restart||Immediately|
Enabling Container-to-Container Networking for your deployment allows you to create policies for communication between app instances. The Container-to-Container Networking feature also provides a unique IP address to each app container and provides direct IP reachability between app instances.
The policies you create specify a source app, destination app, protocol, and port so that app instances can communicate directly without going through the Gorouter, a load balancer, or a firewall. Container-to-Container Networking supports UDP and TCP, and you can configure policies for multiple ports. These policies apply immediately without having to restart the app.
The BOSH release that contains the Container-to-Container Networking feature is composed of a pluggable network stack. Advanced users or third-party vendors can integrate a different network stack. For more information about third-party plugins, see the Container-to-Container Networking BOSH release documentation.