Package Delivery

Confd as an Add-On

Calico comes with a specially tuned version of Confd, which docks with Etcd in the background and fetches configuration data there. From the data, it generates configuration files on the respective systems for those services that cannot retrieve their configurations directly from Etcd. In fact, Confd replaces a part of the functionality of Puppet, Ansible, and the like, but it is far more dynamic.

Moreover, the configuration of an individual system or all systems can change continuously in Calico. If you wanted to map this manually, you would have to use solutions such as the inotify API to monitor the relevant configuration files, rewrite them, and then send a SIGHUP to the service that uses them. Confd in Calico relieves you of all these tasks.

Variant B: Kubernetes

Although Calico is also explicitly designed for Kubernetes, the container manager comes with its own controller services, which already include the required configuration data. Here, the Calico developers have built the connection to the datastore in a modular way. Instead of the module for Etcd, Calico can load a module for Kubernetes and communicate directly with the Kubernetes API.

If you want to supply many Kubernetes instances with Calico, Typha lets you scale an instance of Calico, including the datastore, horizontally. Kubernetes then only talks indirectly to Calico through Typha, which acts as a kind of cache. This architecture means that you can use a Calico instance to populate huge environments on a Kubernetes basis without sacrificing the benefits of a single point of administration.

Intelligence in the Controller

Calico's controller is of central importance. A conceptual distinction is necessary: The datastore contains information on the configuration – but essentially on the configuration that must ultimately be implemented on the target systems.

The Calico controller is responsible for translating this configuration into Calico-speak. Only then is the interaction of interfaces, namespaces, iptables, and the BGP daemon that the Calico configuration requires created on the target systems. The control plane therefore reads the desired configuration on the one hand and converts it into a specific system configuration on the other.

The counterpart to the Calico API on the target systems is Felix, the Calico agent. It receives instructions from the Calico control plane and creates the corresponding idempotent configuration on the system. As long as the system is stored with the same configuration in the control plane, Felix reliably creates the same configuration on the server and defends it against any external intervention, if necessary.