[00:00.000 --> 00:14.200]  Awesome, thanks everybody for joining me to chat about CNI 2.0.
[00:14.200 --> 00:15.200]  My name's Doug.
[00:15.200 --> 00:24.560]  I work in a variety of areas with Kubernetes networking primarily, but to scale the conversation,
[00:24.560 --> 00:29.320]  I wanted to see a show of hands of who knows what CNI is.
[00:29.320 --> 00:32.040]  All right, that's pretty good.
[00:32.040 --> 00:36.840]  And for everyone else, it is the container networking interface.
[00:36.840 --> 00:47.440]  And really what I think most people know CNI for is it's a plug-in that you use to get
[00:47.440 --> 00:50.080]  your network plumbed in Kubernetes.
[00:50.080 --> 00:55.000]  So it's going to define how your pods are going to talk to one another.
[00:55.000 --> 01:02.440]  But there's kind of an underlying part of CNI that I'm not sure everybody realizes
[01:02.440 --> 01:06.000]  is that it is COE agnostic.
[01:06.000 --> 01:10.440]  Who knows what a COE is?
[01:10.440 --> 01:11.600]  Not as many people.
[01:11.600 --> 01:17.120]  Well, I have a junior engineer on my team, and he was asking me some questions about
[01:17.120 --> 01:18.120]  it.
[01:18.120 --> 01:23.480]  And I said, I can't do that, because it's COE agnostic, and he goes, what's a COE?
[01:23.480 --> 01:27.760]  And I said, well, it's a container orchestration engine.
[01:27.760 --> 01:31.280]  And he's like, well, what's a container orchestration engine?
[01:31.280 --> 01:37.480]  Well, I'm wondering if anyone can name one container orchestration engine.
[01:37.480 --> 01:42.360]  Kubernetes, yeah, totally.
[01:42.360 --> 01:48.080]  And really, we just kind of talk about Kubernetes, right, because who can name two of these?
[01:49.040 --> 01:51.320]  That's Kubernetes.
[01:51.320 --> 01:55.240]  Well, it's an opinionated Kubernetes, for sure.
[01:55.240 --> 01:59.120]  But it's still Kubernetes under the hood.
[01:59.120 --> 02:01.160]  So yeah, there you go.
[02:01.160 --> 02:06.400]  So now we know who's been around this area for a long time, because we used to have to
[02:06.400 --> 02:12.360]  talk about these generically, like we were going to have a bunch of them.
[02:12.360 --> 02:15.000]  But Kubernetes won.
[02:15.000 --> 02:19.280]  And CNI is container orchestration agnostic.
[02:19.280 --> 02:22.520]  Well, does it need to be anymore?
[02:22.520 --> 02:25.640]  I really, I'm not sure about that.
[02:25.640 --> 02:30.760]  So I wanted to bring up that we love CNI.
[02:30.760 --> 02:31.760]  It's great.
[02:31.760 --> 02:33.200]  It's really modular.
[02:33.200 --> 02:40.320]  It allows us to have an interface that we use to be able to do the detailed kind of work
[02:40.320 --> 02:46.480]  that we need to do as people who care about networking in Kubernetes.
[02:46.480 --> 02:51.520]  We want to get in there, and we want to have this interface to say, this is how I want
[02:51.520 --> 02:56.640]  to set up networking in Kubernetes.
[02:56.640 --> 03:03.840]  And really, something that's kind of happening because it's container orchestration agnostic
[03:03.840 --> 03:11.760]  is that people might not actually use it anymore.
[03:11.760 --> 03:16.440]  They're thinking about Kubernetes, and they don't care that it's container orchestration
[03:16.440 --> 03:18.280]  agnostic.
[03:18.280 --> 03:25.280]  And they really want to have a deeper integration, and they're ignoring this.
[03:25.280 --> 03:32.640]  They want to do everything with Kubernetes, and they don't want to just say, oh, well,
[03:32.640 --> 03:38.760]  since it's container orchestration agnostic, CNI doesn't do anything with Kubernetes.
[03:38.760 --> 03:42.600]  And so people are starting to ignore CNI.
[03:42.600 --> 03:46.800]  This is really bad for our space.
[03:46.800 --> 03:52.520]  It's what it's doing is it's basically people are saying, I'm going to totally bypass this
[03:52.520 --> 03:53.520]  API.
[03:53.520 --> 03:56.840]  I'm just going to do everything in Kubernetes.
[03:56.840 --> 04:01.000]  I'm just going to set up my networking however I want.
[04:01.480 --> 04:05.600]  If you're somebody that has to go and administer these systems, or you're somebody who has
[04:05.600 --> 04:12.040]  to develop on these systems, you're going to have to track down all of these things
[04:12.040 --> 04:16.680]  that somebody else did that didn't follow this standard.
[04:16.680 --> 04:19.320]  I think it's really bad for our ecosystem.
[04:19.320 --> 04:25.440]  So I'm kind of on a warpath here to let people know this is happening.
[04:25.440 --> 04:32.160]  I'm not going to call out any names, but there's plenty of providers that have Kubernetes
[04:32.160 --> 04:38.000]  as a service or as something that you buy and you install out of the box.
[04:38.000 --> 04:41.680]  And they're like, oh, well, you don't need to worry about this.
[04:41.680 --> 04:44.240]  We've taken care of it for you.
[04:44.240 --> 04:50.400]  And I'd love to believe that you don't have to worry about this anymore.
[04:50.680 --> 04:56.840]  I've been working in production systems, in operations, as a developer of these kind
[04:56.840 --> 04:58.160]  of things.
[04:58.160 --> 05:02.520]  And I realized that the world is kind of a dirtier place than that.
[05:02.520 --> 05:05.480]  There's always going to be stuff that you want to get in there.
[05:05.480 --> 05:12.880]  And when you are using this pure upstream Kubernetes, you want the detail to get in
[05:12.880 --> 05:16.360]  and to figure out how this stuff works.
[05:16.360 --> 05:22.280]  I don't want to have to take apart somebody else's science experiment.
[05:22.280 --> 05:26.680]  And the reason people are doing this is because they want a tighter integration with Kubernetes.
[05:26.680 --> 05:30.920]  So CNI plugins are binaries.
[05:30.920 --> 05:32.800]  They run on disk.
[05:32.800 --> 05:36.080]  They're called by your container runtime.
[05:36.080 --> 05:39.360]  And they execute these binaries on disk.
[05:39.360 --> 05:44.280]  So for example, junior engineer on my team, we deal with CNI plugins all day, long day
[05:44.280 --> 05:46.400]  and day out.
[05:46.400 --> 05:48.920]  And he's looking at these other teams.
[05:48.920 --> 05:56.680]  And they're working on Kubernetes operators, all this stuff that integrates tightly with
[05:56.680 --> 05:57.680]  Kubernetes.
[05:57.680 --> 06:02.320]  And he's like, look at all these awesome tools that they have to interactively debug
[06:02.320 --> 06:04.840]  their programs.
[06:04.840 --> 06:09.480]  And if I want to do that with a CNI plugin that's not really running in Kubernetes because
[06:09.480 --> 06:14.200]  it's container agnostic, well, I can see why.
[06:15.120 --> 06:20.840]  Some Kubernetes distributors are saying, I'll just ignore it and just do this another way
[06:20.840 --> 06:28.080]  because I can get a tighter Kubernetes integration if I just bypass CNI.
[06:28.080 --> 06:31.720]  I am a maintainer of something called Multis CNI.
[06:31.720 --> 06:38.280]  And what it's used for is having multiple interfaces in a pod in Kubernetes.
[06:38.280 --> 06:45.120]  So if you're doing something that's more of a high-powered networking kind of stuff
[06:45.120 --> 06:51.800]  where you want to have isolation of networks, so a classic thing would be control and media
[06:51.800 --> 06:57.320]  on separate networks and you want to divide traffic so that that's isolated.
[06:57.320 --> 06:59.840]  That's the kind of thing you would use Multis for.
[06:59.840 --> 07:04.960]  And Multis is Kubernetes-aware, and it's CNI-aware.
[07:04.960 --> 07:10.600]  And it's designed to have multiple, to give you these multiple network interfaces.
[07:10.600 --> 07:16.320]  But because it's Kubernetes-aware and it's CNI-aware, people are trying to use it as
[07:16.320 --> 07:19.120]  kind of a CNI runtime.
[07:19.120 --> 07:21.440]  And that's not what it is.
[07:21.440 --> 07:29.360]  And kind of as this, so today we have CNI 1.0, CNI 2.0 is on the horizon.
[07:29.360 --> 07:34.360]  And as this conversation came up, and I'm seeing more people in my community coming
[07:34.360 --> 07:39.720]  to me like, hey, I want Multis CNI to do this thing that's in the CNI spec.
[07:39.720 --> 07:45.680]  And I mean, I want to make it work as well as I can to fit everyone's use cases, but
[07:45.680 --> 07:53.800]  I'm really starting to realize, hey, we need to get this kind of functionality into CNI
[07:53.800 --> 08:02.360]  itself and to use CNI in a way that really has this Kubernetes-awareness.
[08:02.360 --> 08:11.560]  So I'm really trying to invite everyone to get involved and to make sure that CNI and
[08:11.560 --> 08:16.880]  Kubernetes are kind of like a happy family together.
[08:16.880 --> 08:22.360]  And I think that we've got like a strong opportunity here.
[08:22.360 --> 08:27.160]  I'm sure if anyone saw the previous lightning talk, which was about YAML, but kind of a
[08:27.160 --> 08:35.240]  weird thing between Kubernetes and CNI is that if you are specifying like workloads and
[08:35.240 --> 08:43.400]  resources, et cetera, your pod specs in Kubernetes, you're using YAML, which has its problems
[08:43.400 --> 08:49.440]  as you saw in the last talk, but CNI itself uses JSON.
[08:49.440 --> 08:55.320]  So when you're trying to sort of marry these two worlds together, you have this kind of
[08:55.320 --> 09:02.400]  problem, especially in my space with Multis where you're kind of multiplexing CNI plugins
[09:02.400 --> 09:04.520]  to get these multiple interfaces.
[09:04.520 --> 09:12.440]  So you're taking YAML that's in Kubernetes and then you're packing JSON into those specs
[09:12.440 --> 09:16.280]  and it's kind of dirty in its own way.
[09:16.280 --> 09:21.400]  So that's like one of those things I'd like to see happen better.
[09:21.400 --> 09:29.080]  And I think it's really awkward for when you're trying to like programmatically interact
[09:29.080 --> 09:30.080]  with this stuff.
[09:30.080 --> 09:35.240]  So sure, as a user, you specify your YAML, you pack some JSON in it, no big deal.
[09:35.240 --> 09:40.880]  But if you're writing an application that parses that YAML, it also has to parse the
[09:40.880 --> 09:46.280]  JSON inside it, which is worse.
[09:46.280 --> 09:54.920]  So I want everyone to have the CNI 2.0 revolution live long and strong.
[09:54.920 --> 09:59.840]  And so I'm trying to get everyone to get involved.
[09:59.840 --> 10:06.600]  And this is a space that I can invite you to that is a working group that I know and
[10:06.600 --> 10:11.000]  love, the Kubernetes network planning working group.
[10:11.000 --> 10:17.080]  We meet every other Thursday in a time that's supposed to be the most friendly for Asia,
[10:17.080 --> 10:19.520]  Europe and the US.
[10:19.520 --> 10:24.800]  And we will be discussing this until it's solved.
[10:24.800 --> 10:30.520]  And we're going to take these considerations up with the CNI community as well.
[10:30.520 --> 10:37.440]  And I'd love to see any faces join and we can keep rocking and rolling on this.
[10:37.440 --> 10:39.640]  So thank you.
[10:39.640 --> 10:46.640]  And yeah, floor is open for any questions.
[10:46.640 --> 11:16.600]  So the question is the
[11:17.600 --> 11:22.640]  given by Casey Calandrello from Red Hat, no longer at Red Hat.
[11:22.640 --> 11:26.880]  A couple Q-cons ago, there's about CNI 2.0.
[11:26.880 --> 11:30.960]  And yes, this is a related effort.
[11:30.960 --> 11:37.000]  And I think that what Casey was talking about at the time was so one of the problems that
[11:37.000 --> 11:42.800]  I mentioned was you've got these CNI plugins, they're binaries on disk, wouldn't it be better
[11:42.800 --> 11:46.000]  if, say, they were containerized?
[11:46.000 --> 11:50.160]  And that was something that Casey was talking about is that we'd like to see CNI plugins
[11:50.160 --> 11:53.120]  be containerized instead of binaries on disk.
[11:53.120 --> 12:01.120]  They're going to be more familiar to folks that work on Kubernetes applications.
[12:01.120 --> 12:05.480]  He was also talking about getting a GRPC interface.
[12:05.480 --> 12:09.320]  But I think that this is kind of a newer thought process.
[12:09.320 --> 12:13.960]  And I don't want to put words in Casey's mouth.
[12:13.960 --> 12:15.800]  So I won't.
[12:15.800 --> 12:19.920]  But I have a feeling that he is also on board.
[12:19.920 --> 12:26.360]  And for those of you who don't know, Casey Calandrello is the originator of CNI and is
[12:26.360 --> 12:29.960]  also an awesome guy.
[12:29.960 --> 12:37.480]  So yeah, so related.
[12:37.480 --> 12:38.480]  Go for it.
[12:38.480 --> 12:45.160]  OK, so in that talk, he was talking most about CNI would be more like a more complete life
[12:45.160 --> 12:49.160]  cycle meant for networks and all of that.
[12:49.160 --> 12:58.160]  And at the same time, but now there is an activity to create like a proper API for networks.
[12:58.160 --> 13:02.920]  So how is this to make a happy marriage?
[13:02.920 --> 13:06.720]  So the question is, and it's a great one.
[13:06.720 --> 13:13.920]  And so one thing that was talked about in that presentation was the idea of a more complete
[13:13.920 --> 13:15.840]  life cycle management.
[13:15.840 --> 13:24.600]  And there is also concurrently an effort happening now that is to define a networks object for
[13:24.600 --> 13:28.760]  Kubernetes, so a data representation of networks.
[13:28.760 --> 13:35.960]  So this is a complex two part question and I have 90 seconds for it, but I love it.
[13:35.960 --> 13:45.800]  So yes, also, so second part first, there is an effort that is called I call it Kubernetes
[13:45.800 --> 13:47.960]  native multi networking.
[13:47.960 --> 13:53.960]  If you join the SIG network call, you can find out all the connection or information
[13:53.960 --> 13:55.040]  about it.
[13:55.040 --> 13:56.400]  Very interesting effort.
[13:56.400 --> 14:00.280]  And as I mentioned, multi CNI does multi networking stuff.
[14:00.280 --> 14:01.280]  That's awesome.
[14:01.280 --> 14:11.680]  And that particular conversation is to me bringing up lots of questions about what CNI 2.0 is
[14:11.680 --> 14:13.480]  going to look like.
[14:13.480 --> 14:19.240]  And for the first part of the question, which is richer life cycle management of networking
[14:19.240 --> 14:27.040]  in containers is so something about CNI is that it primarily functions on container creation
[14:27.040 --> 14:29.800]  and container deletion.
[14:29.800 --> 14:35.600]  There's some exceptions to this, but primarily so CNI add is a command happens when your
[14:35.600 --> 14:43.120]  container is created, your CNI plug in kicks off, does its work, goes to sleep dies.
[14:43.120 --> 14:48.160]  And then delete when your container is deleted, it tears it down and cleans it up.
[14:48.160 --> 14:52.600]  However, networking can still happen between those two to 10 points, right?
[14:52.600 --> 14:55.880]  So things happen, things change IPv6.
[14:55.880 --> 15:03.800]  You could have Slack happening and auto assign routing and IPs.
[15:03.800 --> 15:04.800]  And that's it.
[15:04.800 --> 15:05.800]  So we want to fix that too.
[15:05.800 --> 15:06.800]  So thank you very much.
[15:06.800 --> 15:07.800]  Appreciate it.
[15:07.800 --> 15:08.560]  Thanks for the question.