I typically ask this question in front of like a bunch of natural engineers, and I ask
like how many of you know no Kubernetes by show of hands, I imagine that this in this room
this would be a lot more, so how many of you know Kubernetes and how many have you
played the round with it? That's the answer I expected quite a lot more than in front
of more traditional networking folks. So what's cool about Kubernetes right? So the
API server is really about making sure that eight humans and machines, controllers, in
this case, can happily coexist and work together. So the API server exposes a number
of resources, be the part, be the service, be the deployment, and there's some
storage behind it. So another part of it is the controller or the reconciler or the
operator or other names that are available for it, that basically execute the controller.
They get a certain input, they run a certain task, they actuate a certain system and
provide status back into the API. So we thought this controller or the custom resource
definition and that framework inside of Kubernetes is a pretty awesome thing to drive
network automation. So this close loop, the most practical thing that you can compare
with is your, to terms that you monitor a certain temperature, if it goes below or above
a certain threshold, you actuate a certain system to drive something. Another thing that we
liked about the KRM, the Kubernetes resource model is that you get a lot for free. So
you get the enormous ecosystem that's out there for free. There's other controllers
for its search manager to name one that can help you issue certificates. Certificates
that you might need on a traditional networking box to expose API interfaces like
Natcon for Genemi or whatnot. And the API model is really cool in the sense that if you know
how to drive one resource, you know how to drive them all basically. So it's a pretty consistent
thing. And as a developer inside of that framework, basically you don't need to reinvent
that a real on a lot of things. So how do we leverage this framework for network automation?
So one of the things that the guys from Kubernetes that really goods is to abstract a lot
of things, right? So they segmented the problem space and the domain. They used reusable components,
they made it declarative. The clarity is really important in the sense that I want my
network to look like this. And this you fire off to a controller and the controller
figures out what needs to be done, given a certain state and the network getting from
A to B. And the closed loop system was something that really we liked. So comparing what Kubernetes
is that in containers and orchestrating containers is I mean if you compare it to networking
or the control plane side of the networking, it's pretty much the same. So we have a network
which is essentially a bunch of devices, a bunch of interfaces which are all interconnected.
And the differences are like really certain use cases, the protocols that we use in networking
to interconnect a bunch of devices using one's P.A. or I.A.S. or B.G.P. or whatever. The APIs and
that's required. So the Kubernetes controller is really to help network engineers build
Kubernetes controllers themselves to mainly drive traditional networking gear or to allow
to expose your traditional network in a cloud native friendly way. So the ideas that
we built a number of abstractions on top of each other where you have a bunch of controllers
that would take traditional networking config for a vendor gear. Another abstraction layer
would be a normalized model where you could create your own abstraction for what a network
should look like. Because either way or either vendor you use an interface is still an interface,
a portal, a still a port, a physical port. Those the terminologies are quite a say. So
essentially what you need to define a VPC is basically a high level abstraction. Then the
network design that you want to apply. Do I want my network to run VGP and generally
doesn't need to run OSPF? Does it not need to run I.S.I.S. Which encapsulation is required
VX LAN or MPLS? Which addressing do I need to use? Do I want to use single stack? Do I want
to use dual stack? Do I want to go V6 only? And then the resources on the other side of the
pain is really about which nodes are in the topologies, which links are there, how are the
interconnected, which IP addresses are in my stateful database like my iPAM system, which I maintain.
I'm so on. So the mental model is really about creating these layers of abstraction on top
of each other. And I'll go through this a bit faster to get into the first layer. So you have
a network with a number of devices. On top of it you would have a provider, which in the queue
that story is the schema driven configuration component. On top of that you would have a number
of other controllers that would expose abstract networking config as you would want it. So
the queue net initiative is really to help network engineers define their own abstraction models
because person A might want to abstract a network in a certain way, but person B might want to do it
in another way. So coming into as they see our schema driven configuration and state,
this is really the component that talks to the network. So it bridges the gap between Kubernetes
so the control of that integrate all of the CRDs and those kind of things and the actual
analysis on the on the cell bound. So what we do in as you see is basically we ingest all of the
young models. So young models is the networking slang for the data modeling language that we use
inside of networking. So we could have gone with protobov or crept or whatever, but the time
that the angle was invented none of those were available and in the networking industry. We kind
of want to do things or we have the thing to reinvent the wheel sometimes a little bit too much,
but okay. So as you see handles structured config format, different ones. So we do Yamo,
we do Jason, we do XML, we do protobov, we have several interfaces, cell bound to the device,
G&MI and NATCOMF and basically what this does and we have to learn it a hard way is this aggregates
all of the intends that you define in your Kubernetes resource. It ingest that for a certain physical
network device and validates the config. So we have our schema or data modeling language,
we have actual config, we try to validate it offline, we merge all of those declarative snippets of
config and then when we have a valid config we the disk controller actually pushes it down to the
device and monitors that the config is going to be in sync with the actual device.
So we have a number of KRM resources to do that. So we have a config CR. This is basically your
sonic config or your S.O. Linux config or your S.O.S.config or your Junior config or
that you ingest into a CR. We have a also a config set CR that is where for instance you would want to
replicate a control plane echo that's similar to a lot of devices. So basically the
analogy with a replica set a bit. We have CRs that are not humanly created but created by the
controller which is the running config. So that's syncs the actual config that's on the running
device and the unmanaged config. So unmanaged config is snippets of config that's on the box
that's not defined by an intent and that really allows us to onboard physical devices
making sure that users are gaining trust in the system that it's working and then they can
slowly onboard snippets of config that they define on their devices inside of the system.
So they can really, I mean we can really start onboarding, brownfield systems like existing networks
on there to onboard it into our system. So this is running short for time I guess.
The CRD. So we ingest schema, the schema CR is a reference to a GitHub repo where the
young models are hosted, we ingest those into a schema server. We have a bunch of discovery rules
where we can automatically discover network targets and network devices in the network and then a bunch
of other ones. The young schema, as I mentioned, it's a bunch, it's a data modeling language
that we use inside of networking or the complex site of networking at least where we define
modules, containers list, leaves, types, those kind of things. So I won't bore you too much with
a bit, but it looks a bit like this. And what we do from and as a see point of view is we
do all of the validations of the data model language. So we validate leaf graphs, we validate ranges,
lengths, mandatory statements, patterns, choice cases and those kind of things inside of the thing.
The important takeaway is that we know or to a high degree of certainty that the conflict
is going to be valid before we send it down towards the device. Obviously there's always some
runtime things on the device that can go wrong, like for instance the fit might be at a certain
threshold, not allowing us to provision certain adults and things can still go wrong on the
device, but we try to cover as much as we can before it hits the device. So that was the device
layer and I'll go quickly through it. So we have another controller on top of that. That's
a choreo, that's also part of the CubeNAT initiative. And that's really to once you have that
vendor config is how do you abstract that? How do you make your own model available to open API
or whatever and expose that. So you can define, I won't a VPC with a minimum set of inputs and that will
render basically the device config, vendor config that can be pushed down with as you see.
What I forgot to mention it as you see is that currently we do support everything or
anything that has a young model. So we support a Resta, we support Cisco, we support Juniper,
obviously the own network operating systems that Nokia provides like as a Linux and SLS,
Juniper, so anything Sonic, anything that has a young model, we can ingest.
Sometimes there's still a bug with okay, the bugs are there to be solved right.
And choreo which is also part of the CubeNAT initiative really helps network engineers
to find their own Kubernetes controllers. The key takeaway here is that we allow network engineers to
or make it more user-friendly to define a controller for networking purposes. So the business
logic that they can apply is either Python there or ginger templates or common codes to generate
networking snippets basically. With that I think I still have a minute left.
So a bunch of PR codes we have a discord where we collaborate with a bunch of network engineers
trying to develop this stuff, our GitHub repo and some some YouTube links where you can check
some more informative sessions about what CubeNAT is and what we're trying to do.
With that I'm at the end of my presentation and I'll take any questions if they are there.
Hey Hans, thanks for the presentation two questions quick. How are you handling state from the
devices with respect to monitoring state and secondly if there is any storage so as you
remember things is in memory or are you writing to discuss well is it at CD?
Yeah. So inside of the as a C2 we also touch state from the networking device and we
kind of catch that there in memory state. The config part like the actual config which is
synced with the device we also persisted in stored at in memory.