Member post from Swisscom by Lea Brühwiler, Ashan Senevirathne, Joel Studler, Alexander North, Henry Chun-Hung Tseng, Fabian Schulz

Two weeks ago, we announced the availability of the NetBox Operator for Kubernetes, an open-source tool designed to integrate NetBox resource management directly into your Kubernetes environment. Today, we’ll take a deeper look at the NetBox Operator’s capabilities and how it works.

We have adopted the GitOps model and leveraged Kubernetes to revolutionize the management of network services and infrastructure, enhancing both operational efficiency and reliability. The NetBox Operator leverages the power of the Kubernetes API, allowing users to directly manage essential resources such as IP addresses and prefixes within the Kubernetes environment. This integration ensures automated network maintenance through reconciliation mechanisms, thereby significantly improving both the simplicity and robustness of operations.

The NetBox Operator uses the Kubernetes “claim” model to differentiate between the desired and the actual states. Users can conveniently express their high-level intent through a claim, such as reserving a specific prefix within a parent prefix. The operator then queries NetBox to identify the most suitable prefix that matches your requirements. Subsequently, a prefix CR (Custom Resource) is created in the Kubernetes cluster, representing the actual resource claimed by the prefix claim CR. Similarly,  IP addresses can be claimed from a parent prefix using the same mechanism. The operator uses the leaselocker library (inspired by client-go) to provide distributed locks and prevent race conditions where the same resource gets assigned to different claims. With the leaselocker library, the parent prefix is locked until the reservation of a resource is completed.

Furthermore, for applications requiring sticky IP addresses, the NetBox Operator offers a convenient feature: the ability to keep an IP address reserved in NetBox even if the corresponding Custom Resource (CR) is deleted from the Kubernetes cluster – just set the .spec.preserveInNetbox flag of your Claim CR to true. If the CR is later recreated, it will be assigned the same IP as before. By seamlessly ensuring IP address consistency, this feature significantly enhances application reliability, enabling redeployment without the need to worry about IP addresses while keeping IPs sticky. The same mechanism is available to keep prefixes sticky.

Ultimately, the NetBox Operator can be applied across a broad variety of Kubernetes-driven infrastructures, including 5G core infrastructure. The operator provides simplified resource management, enhanced operational efficiency, and improved reliability. By automating crucial aspects of network service and resource management, it empowers engineers to focus on higher-level tasks, driving greater scalability, flexibility, and agility within their infrastructure.

Diagram flow showing Netbox Operator

Try it out yourself!

Clone the NetBox Operator code from https://github.com/netbox-community/netbox-operator and follow the instructions in the README.md file to run the NetBox Operator and NetBox on a local kind cluster and test it using examples. Please also feel free to provide feedback and contribute.

Transforming the Industry Together 

The NetBox Operator is just one component of our broader GitOps strategy, leveraging the Kubernetes Resource Model to drive operational excellence. Consuming IPAM from within Kubernetes allows us to hydrate (or generate) configuration from values which also live on the cluster. If you want to see some examples of this and how we approach this, please have a look at the examples at https://github.com/swisscom/containerdays-2024-krm

To understand the bigger picture of our journey, feel free to watch our KubeCon presentation outlining our GitOps evolution.

Swisscom actively invites collaboration from the tech community to enhance and expand the NetBox Operator. Meet us at the upcoming conference Open Source Summit on September 17th, where we will present and engage with peers on Kubernetes-driven network infrastructure. 

Together, we can push the boundaries of cloud-native transformation!