Network-as-a-Service Part 2 – Designing a Network API
In the previous post, we’ve examined the foundation of the Network-as-a-Service platform. A couple of services were used to build the configuration from data models and templates and push it to network devices using Nornir and Napalm. In this post, we’ll focus on the user-facing part of the platform. I’ll show how to expose a part of the device data model via a custom API built on top of Kubernetes and how to tie it together with the rest of the platform components.
Interacting with a Kubernetes API
There are two main ways to interact with a Kubernetes API: one using a client library, which is how NaaS services communicate with K8s internally, the other way is with a command line tool called kubectl, which is intended to be used by humans. In either case, each API request is expected to contain at least the following fields:
- apiVersion - all API resources are grouped and versioned to allow multiple versions of the same kind to co-exist at the same time.
- kind - defines the type of object to be created.
- metadata - collection of request attributes like name, namespaces, labels etc.
- spec - the actual payload Continue reading
