Calico can be configured to allow pods to communicate with each other with or without IP-in-IP tunneling. IP-in-IP adds an additional header for all packets as part of the encapsulation, but containers can communicate on its overlay network through almost any non-overlapping underlay network. In some environments where the underlay subnet address space is constrained and there is no access to add additional IP Pools, like on some public clouds, Calico can be a good fit. 

However, in environments that do not require an overlay, IP-in-IP tunneling should be disabled to remove the packet encapsulation resource use, and enable any physical routing infrastructure to do packet inspection for compliance and audit. In such scenarios, the underlay network should be made aware of the additional pod subnets by adding the underlay network routers to the BGP mesh. See the discussion about this in “Calico components”. 

## Calico components 

The calico network is created by the following 3 components: node agent, CNI, and kube-controller. 

## Calico/node agent 

This entity has three components: felix, bird, and confd. 

GLYPH<SM590000> Felix’ s primary responsibility is to program the host’s iptables  and routes to provide the wanted connectivity to and from the pods on that host. 

GLYPH<SM590000> Bird is an open source BGP agent for Linux that is used to exchange routing information between the hosts. The routes that are programmed by felix are picked up by bird and distributed among the cluster hosts. 

GLYPH<SM590000> Confd monitors the etcd  data store for changes to the BGP configuration, such as IPAM information and AS number, and accordingly changes the bird configuration files and triggers bird to reload these files on each host. The calico/node creates veth-pairs to connect the Pod network namespace with the host’s default network namespace. 

## Calico/cni 

The CNI plug-in provides the IP address management (IPAM) functionality by provisioning IP addresses for the Pods hosted on the nodes. 

## Calico/kube-controller 

The calico/kube-controller watches Kubernetes NetworkPolicy objects and keeps the Calico data store in sync with the Kubernetes. calico/node runs on each node and uses the information in the Calico etcd  data store and program the local iptables  accordingly. 

## Calico network across different network segments 

When nodes are on different network segments, they are connected using a router in the underlay infrastructure network. The traffic between two nodes on different subnets happens through the router, which is the gateway for the two subnets. If the router is not aware of the pod subnet, it will not be able to forward the packets between the hosts. 

There are two scenarios that can be used to the Calico communication: 

GLYPH<SM590000> Calico can be configured to create IP-in-IP tunnel end points on each node for every subnet hosted on the node. Any packet originated by the pod and egressing the node is encapsulated with the IP-in-IP header, and the node IP address is utilized as the source. This way, the infrastructure router does not see the pod IP addresses. 

The IP-in-IP tunneling brings in extra resource use in terms of network throughput and latency due to the additional packet resource and processing at each endpoint to encapsulate and decapsulate packets. 

