Cloud-Native Network Controller

The philosophy in application operations has changed significantly over the last few years. Most applications no longer run on dedicated servers but have been migrated to virtual machines. For some time, they were used as best practices. Nowadays, applications are already developed in a cloud-native manner for easy deployment in container-based infrastructures. What happened in the meantime in the domain of network configuration management? The focus was set on automation enhancement with popular tools like Ansible and various proprietary solutions. They provide a one-shot way of deployment, where the configuration will be applied but still leave the possibility open to overwrite the changes manually. In this approach, there is no built-in self-healing of configuration drift. A group of network engineers is developing a tool stack around Kubernetes, allowing the user to leverage its cloud-native advantages for network configuration.

The objective of this bachelor thesis is to analyze the main component of the tool stack SDC (Schema Driven Configuration) in the use case of automating an EVPN fabric. The analysis shall examine the operating principle of SDC while also considering its place in the cloud-native ecosystem from data source to the device. Based on the analysis, a verdict should be given on SDC’s fulfillment of requirements, multi-vendor compatibility, and readiness for use in production.

The findings prove that SDC follows great principles: It is designed to be vendor agnostic, working with virtually every vendor that supports Netconf or gNMI as a configuration interface and is customizable. This facilitates avoiding vendor lock-in. Being comprised of Kubernetes resources, SDC works completely declaratively and uses a mechanism for continuous reconciliation. The tool is open-source. Therefore, it is possible for anyone to use and improve it.

Since SDC is still in heavy development, the authors also found a few minor bugs - some of which have been fixed during this project. The more significant issue lies in the usage of YANG: SDC uses YANG schemas to validate the configuration before writing it to the devices. It was found that SDC often has trouble loading these schemas either because of bugs in SDCs loading mechanism or due to the fact, that some of the (vendor-supplied) schemas contain many deviations which lead to breaking the configuration tree. Therefore, using SDC in production requires a fair amount of effort to rework the available YANG schemas for the devices.

SDC integrates with Kubenet as the configuration generation component. It first enables the creation of an abstract configuration, which will then be transformed into the device-specific configuration. Due to some disadvantages of running the configuration creation in Kubernetes, such as the lack of a good way to do a dry run, a new tool called Choreo exists. It replicates the API functionality of Kubernetes while providing additional functionality, such as running to completion with either a successful or failed result. These tools’ customizability enables extreme flexibility but also increases their complexity, and many components for their functionality must still be created. This development is expected to be done by the user or the community as they have not (yet) been provided by the developers. As can be seen, SDC still needs some time for development to be entirely usable in productive environments. Nevertheless, it has many exceptional traits, making it inimitable in the current market.