Introduction to Calico Basic Architecture

Calico is a pure L3 datacenter networking solution that integrates seamlessly with Kubernetes and OpenStack, and it is one of the most commonly used CNIs for Kubernetes. This article will introduce the basic components and architecture of Calico.

Table of Contents

Basic Components

Calico consists of the following independent components:

Felix, the Calico Agent running on every endpoint
Orchestrator plugin, code that integrates Calico into different orchestrators
etcd, used for data storage
BIRD, the BGP Agent that distributes routing information
BGP Route Reflector, required for larger network environments

These components will be introduced one by one below.

Felix

Felix is a daemon that runs on every host providing endpoints, which in most cases refers to the hosts running VMs or containers. Felix is responsible for configuring routing, ACLs, and other functions; essentially, it handles the tasks and settings required on the host to provide network connectivity.

Depending on the platform, Felix is responsible for the following tasks:

Network Interface Management

Felix configures network interface information in the kernel so that the kernel can correctly handle networking for each endpoint. Its primary role is to ensure the host can respond to various ARP requests with its MAC address and to enable IP forwarding for the interfaces managed by Felix.

Additionally, Felix monitors the creation and deletion of network interfaces to ensure that relevant configurations are applied in real-time.

Routing Configuration

Felix is responsible for configuring the routes to endpoints in the Linux kernel FIB (Forwarding Information Base) on the host, ensuring that packets destined for endpoints can be forwarded correctly.

ACL Configuration

Felix is also responsible for the relevant ACL configurations in the Linux kernel. These ACL settings ensure that only valid traffic can pass between endpoints, preventing any bypass of Calico's security measures.

Status Reporting

Finally, Felix is responsible for providing network status data and reporting errors or issues encountered during host configuration. This data is written to etcd, allowing operations personnel and other components to monitor the current state.

Orchestrator Plugin

There isn't just one type of Orchestrator plugin; rather, different plugins exist for different platforms (Orchestrators). For example, Kubernetes has the Calico CNI, and OpenStack has the Calico Neutron ML2 mechanism driver. These plugins allow users to manage and operate Calico networks through these platforms.

The Orchestrator plugin is responsible for the following tasks:

API Translation

Each platform has its own network-related APIs. The primary job of the orchestrator plugin is to translate these APIs into Calico-related data models and store them in its storage space.

Feedback

If necessary, the orchestrator plugin reports the status of the Calico network to the platform, such as whether Felix is operating normally.

etcd

etcd is a distributed key-value store that Calico uses for component communication and as a datastore. Depending on the platform, etcd may serve as the primary datastore or as a separate lightweight mirror.

etcd is responsible for the following tasks:

Data Storage

etcd provides Calico with a distributed, consistent, and fault-tolerant storage space. This ensures that the Calico network can operate in a "known good" state and can tolerate failures of some hosts.

Communication

etcd also serves as a bridge for communication between various components. Different components continuously monitor the keyspace in etcd to ensure they receive all update information, allowing them to quickly configure the network when data changes.

BGP Client (BIRD)

Calico deploys a BGP client on all nodes running Felix. The BGP client reads Felix's configurations in the kernel and distributes them throughout the data center.

The BGP client is responsible for the following tasks:

Route Distribution

Once Felix writes routes into the FIB, the BGP client advertises this information to the nodes with which it has established BGP connections. This ensures that all traffic can be efficiently routed within the deployment.

BGP Route Reflector (BIRD)

In larger deployments, BGP may face challenges due to the need to maintain a full-mesh topology; therefore, Calico additionally deploys Route Reflectors in these larger environments.

The BGP Route Reflector provides a centralized point for all BGP clients to connect, avoiding the need for them to peer directly with every other node. In Calico, BIRD is typically used as the BGP Route Reflector.

The BGP Route Reflector is responsible for the following tasks:

Centralized Route Distribution

When a BGP client on a Calico node advertises routes from the FIB to the Route Reflector, the Route Reflector then advertises them to other nodes in the deployment.

Conclusion

This article introduced the various Calico-related components and their respective tasks. The next article will introduce several Calico architectures within the IP Interconnect Fabric.

Reference

https://docs.projectcalico.org/v3.7/reference/architecture/