Okay, great. Thank you. So, welcome everyone. We are pastime soils are quickly. So, the
clarity of networking in the clarity world, 20, 25 edition, just quick vibe check. So, who
already saw this talk a year ago? Here at first them? Yeah. Okay. So, we start from scratch,
which is okay. Better for me because a lot of stuff will be the same. So, you will be bored,
but that's okay. So, I'm at Rikovazka, I work at Red Hat. It does like last year, two
years ago, three years ago, four years ago, time goes by. Yeah. So, I'm basically Switzerland.
I've been doing a lot of stuff before Red Hat. So, I've been in academia. I've been doing
some banking. That wasn't good stuff. I don't recommend that. I was doing telecode. That was
better. It gave me a lot of insights. So, I kind of see more other perspectives what I do. Now,
so I can put it somehow into, you know, into the framework. So, I can already answer why I'm
doing something. Since the beginning of time, I've been doing cloud and metal. Then I switched
to network security for a moment. I'm not touching cardiovascular intelligence. I'm trying
not to do this as long as my management doesn't force me to. So, thankfully, it's not happening.
Yeah. Let's, let's give it like this. So, three to the middle of the talk. So, we are in containers.
So, it may be not so super clear why we are even talking about this. But, basically, the starting point
into this whole journey here is that we have systems with multiple network interfaces. And, of
course, half of the audience will now question, why do we even care about this? I have Docker container.
If it's one network interface and I'm happy I don't need to know anything else. Well, that's
that's true as long as you are running some, you know, web app with database and front end,
like, you know, on some classic containers, one-on-one class. But, but then we start
setting people who are running network equipment as containers. This happens in, you know,
telco 5G. It's not anymore. Well, it is physical hardware, but inside this hardware,
you don't run processes directly. It's, it's a containerized, some, some 5G telcos,
they are even doing Kubernetes, good for them. So, that's super cool. So, router routers,
which is basically SDN. So, all the software defined networking called the fans,
routing devices. It's, it's all containerized nowadays. Then telco, then we have high performance
computing. So, those are people who are running containers on Burmett Hall and they need a lot
of performance and it doesn't mean let's get a server, let's buy 10 and VDR GPUs. It means,
let's have a lot of network, let's have super fast network. And for those people, this is also a
use case. Because, you know, for data transfer, they have something else, for management, they have
something else. And it all boils down to the fact that you have a server somewhere
down during the basement. And this server has dozens of network interface. And it can go from,
you know, from two network interfaces to hundreds. We've seen that all, and, you know, each order
of magnitude brings its own problems, but it still boils to the fact that you don't have one
interface, but you have a lot of them. So, let's, let's go back 50 years ago, let's say.
So, network managers, standard binux, this admin, so you basically SSH to your machine,
and you do everything yourself. So, forget, you know, Ansible, Puppet, this kind of stuff
doesn't exist yet. All you had was network managers, static config files. And, you know,
let's not get fooled. It's still there. It may be hidden by some layers of abstractions,
but this stuff is still there. It all boils down to, you know, your systems, I think,
bunch of files managed by network manager, and it's not going away. It will be there for, you know,
for the next 50 years. But, okay, it's, it's not about renting about that, because at the end
of the day, well, Linux, everything is a file. So, it's good. But, there is a problem, from the
mental problem with this configuration like this, because it's super nice as long as your configuration
is stable. But, what happens when you start changing this config? It's a file, right? So, you
would SSH to be server, you would open this file, you would modify some values, and then,
this is a potential for problem big is. You can quit the editor without saving the file,
so far so good. You may save the configuration, and that's it. Now, is it applied or not? Well,
it's not immediately applied, because now, whoever consumes this config file needs to be told,
hey, I updated the config file. Can you please, can you please read the file and do what's necessary?
And then we go even further, because now, okay, so we tell this something, which is network
manager of your, hey, updated the file, please take changes into account. So, what now happens,
if you basically, well, broke this configuration, oh, let's say something like that right here.
It's, it's recorded, so, so what, what if you put invalid configuration in this file,
you go and you tell network manager, hey, please restart and apply this configuration.
Well, this configuration that it reads now is incorrect. So, if you are lucky,
you just lost access to your server, and if you're doing this remotely, well, bye-bye. So,
yeah, and, you know, a lot of problems, I've seen a lot of problems that people update this file,
and they just forget, and these file sits updated, well, modified, and one year,
afterwards, they reboot the server and server is suddenly not going up. Well, good luck debugging,
what happened, and then the one. So, we can, we can improve, and on top of network manager,
we got this project, and then state. So, it gives us ability to configure network manager configuration
at runtime. It doesn't sound like something, you know, huge, but it's basically, it changes the
paradigm. So, you don't modify a file with some configuration that is not even validated,
and good luck if you have been plugging the validate syntax of network manager config file,
well, good for you, but, but people don't do this. We have a CLI, which will be basically,
you know, network manager, modify connection, and, you know, it's, it's better. It's not ideal.
It's not declarative. It's not keyword netty's way, but at least it won't allow you to break
the configuration immediately. So, I have this screenshot, well, it's bad liking, but,
but, basically, what I was trying to do, I am changing IP address, and everything looks good.
I mean, it's an IP address. It's not like I'm putting 9, 9, 9, 9, 9, as one of the objects,
but instead of slashing doing bugs, or the other way around, basically, I'm doing the wrong one.
So, if I did it in this, in the static config file, it just breaks, and thank you very much,
good luck. Here, I get immediate, you know, feedback, well, sorry, this is not a correct IP address.
So, already better. It doesn't give us everything that you would like from keyword netty's world,
but, you know, step by step. So, we don't need to do this from, you know, from bash,
putting everything, like this, we can take YAML. I don't judge, you know, YAML was a choice,
there are maybe better, there are maybe worse, but, you know, at least, at least we have something.
So, now, we go to the state that you craft a YAML describing your network configuration. So,
what I want to have as DNS setup, what I want to have as routing, what I want to have as interfaces,
and, you know, it goes further and further, and you have this file. So, you then basically apply
this YAML as a network configuration for your host. So, now, you don't need to remember and go through
your bash history to see who modified what, but you basically open the YAML and you see what
your configuration. Well, with a small disclaimer, that when I apply this YAML and the U.S.
Sets and the YAML and you start doing, you know, IP address, delete, add, you will mess up,
and this will not hold, but, you know, step by step. We already have YAML, we already had something
that we already applied this YAML. So, what are we missing now in this, in this scheme, you know,
in this state of the art? Well, let's do what Kubernetes does. So, let's have continuous reconciliation.
So, let's have operator, which will have inside the controller, which will be basically applying
this configuration, this configuration all the time. So, you see the YAML looks almost the same,
it just wrapped around the CRD in Kubernetes. So, we created the CRD node network configuration policy,
crazy name, but you know, there are reasons. And in this CRD, well, in this CR, then, we define
the same configuration that you just saw, which basically means that now, from now on, Kubernetes
will be managing network configuration of this node. Which, okay, maybe not a big deal, but, you know,
it's now nice because I think it's, yeah, it's them. So, let's do. So, let me show you.
I have a bunch of policies set in DNS server, some additional IP others, and so on.
So, basically what I can do right now, so we will work with this one. What I'm going to do
with, with this CR? Oh, sorry. Yeah, the excuse, they always go my understanding right with
them all. So, I will basically take one of the network interfaces on my server, I will add IP address,
which we'll see, hit 10, 2, 4, 1, 3, 3, 3, and whatever. And I will apply this, you have now.
Now, we have the node selector, so this configuration will apply only to this particular node.
We can go deeper afterwards, but, you know, we need to have node selector, because we don't always
apply configuration, which is specific to the node, sometimes it's super global. So, but with IP
others, I don't want to apply this to my whole cluster, that would be stupid. So, just to prove
that I don't have this IP address on this server. So, you can see that this interface is
something similar, but it's 0, 3, not 1, 3. So, I'm going to apply now the next one. So,
let's apply this configuration, see, get an mcp, okay, in that place. Oh, okay, configured.
Now, let's see again what I have. And I have this, 1, 3, nice, okay. So, let's be now this,
well, rogue admin, new junior in that team, you know, I made, but you know, basically someone goes
and deletes this this configuration. So, now, go ahead and remember the syntax.
And delete 24. And now, I think it's like this. Okay, it disappeared. Now, a bit of hacking
from my side. Do some due to some performance tuning and so on, I have right now timer, so it
doesn't check it immediately continuously, but I think there is like 300 seconds. I don't have
300 seconds now to just, you know, stand and entertain you. So, what I will do, I will just restart
the pod, so that the timer starts from 0. And if we'll go and apply everything, get, get pod.
Now, pod running on Master 0 is this one. Now, restart or do I need to kill it, I think,
to delete the pod. It's always the danger with live demo. Now, 50% chances it won't start again.
Ah, no, it's started actually, okay. So, let's see, oh, see, good, and then Cp.
Okay, healthy stage and did something happen on the node. Okay, I have this IP address back. Yeah,
so we did fast forward, yeah, but, you know, those are, those are rules of the,
of the live demos that you have limited time. We have six minutes, so I will not show you more
demos. I could show you know, ten different configurations, but, but I cannot, well, so basically,
about the NM state itself, some, you know, some PR. It's written in RAS because RAS is the cool
kid in the block nowadays, so I not network manager as a backend. Well, you don't have a choice,
right? This is what we have. Kubernetes operator, so this is something that we have live in action,
people use it. I'm from Red Hat, so of course, you know, we, we sell stuff, so there are people paying
for this, but it's open source, it works on Kubernetes, not only on, you know, the Red Hat flavor of
Kubernetes, so it's upstream, you can take vanilla Kubernetes cluster, take the operator from
GitHub and it works. There is no any hidden tricks, there is no any small footprint, it just works.
The NM state itself, you can use it from RAS, go and buy from there are bindings and a lot of
stuff, so it's, it's really super friendly and, and easy to use. What we did comparing to last year,
so we introduced a lot of usage metrics, and I won't go too much into detail because we have
five minutes and there may be some questions, but basically what we want to have is when you have a
huge fleet of nodes in your cluster and use the operator, and presumably every one of the nodes
has some network configuration. We want to see some statistics, I, for example, how many static DNS
servers have you configured? How many nodes with static route you have? How many static routes you have?
How many nodes do you have with static IP addresses versus, you know, DHCP or, you know,
Slack if you are doing IPv6? All these kind of stuff, so we can draw some numbers about the topology,
and we see, you know, what's what, and, you know, people like statistics, people like graphs,
so this is what we do. Performance improvements, this is something that I cannot easily demo,
but we basically started running the operator on cluster with hundreds of nodes and then
hundreds of network configurations, then every of the nodes going into,
after do the, after two digits of number of interfaces, and we started discovering, okay,
it's still here, it's still there, and you know, you need to tune that. What are we going to do in 2025?
So, reverting the configuration when you did it an NCP, I didn't explain what happens here when
we start deleting the stuff, so I will not go into details, but basically there is people complain
that it's counterintuitive because they would expect when you delete an NCP with configuration,
the configuration will get deleted. It's not as simple because sometimes you have changed
configuration and deleting one will break the other, so we need to figure out what to do and how to do
it. Well, we will, we have a plan for that. Of course, there is always something that you want to
find, you need to configure yourself, so people are asking us, hey, why did you hard code this
value here? I would like to change it. Okay, we will give you ability to change it. Some bigger changes,
so we have this CRD here and it's very opinionated because, you know, you need to start from something.
Now we are working a lot of with telco people and they are telling us, oh, but this CRD, it's not
actually what we would like to have, you would like to have something speaking more telco language,
so we are working with them to get this CRD, you know, more in telco English, not in our English,
much more performance stuff, so we are still hitting a lot of API, you know, a lot of calls, a lot of
calls, a lot of calls and it's expensive on the API, we will fix that. As for today, we are publishing
the upstream operator in the oil, as the oil, you know, that's our trust, you can always build it
from the call, it's super simple, it's goal, so we will basically, you know, compile it, it's easy,
but people are telling us that it would be nice to have a home chart, so we are working on this,
we already have some upstream contributor implementing this, so it's, it's to be merged, you know,
in the next week or two, and something much more on the political side, not three technical, so we are
about to join the Kubernetes network planning working group, and this is part of a bigger plan
to have a real app through and with outside contributors and so on, so it's not only, you know,
red cut project for red cut customers, and this is, you know, an nice, nice kick start,
it's not like we don't have upstream today, but being under the umbrella of, you know, Kubernetes
see good, be something much, much, much, much bigger. So yeah, this is the end, we have less than one
minute, so I guess I can take one question, and that would be this, thank you.
All right, I do just one question here. Thank you for the interesting talk.
I have one question, because for instance, I'm from the Turkey world, so I know what you're talking
about. We have many use cases with VLAN, VX LANs, and so on, NMS state comes super handy,
and I'm actually I'm using it, but you still need to configure some stuff in Kubernetes.
You need to rely on plug-in such as a multi-CNI and so on, so any plans on joining forces
with them or somehow. Yeah, so that's exactly the part of the CRD, so the operator will not
be doing multi-CNI and this kind of stuff, so we will not merit it on the operator side,
but I'm talking with people to have unified CRD, so that you wouldn't have, you know, CRD
for multi-CRD for something else, but unified CRD for your telco side, and then we would have
operators managing, you know, dispatching this. So we don't want to have one operator to who
everything, because then we are basically doing next Kubernetes, but you will have interface as a
user, which is CRD, and through this one CRD you will configure SRIOV, VX LAN, side VPN, and whatever you need,
and then, okay, you will still need to install this operator, that operator, but you would manage
them from one CRD altogether, so this is the plan. All right, thanks a lot.