Kubernetes SIG Network, 16 Feb 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes SIG Network meeting 20230216 (Part 1)

Description

Kubernetes SIG Network meeting 20230216 (Part 1)

A

This meeting is being recorded, hello, everybody Welcome to February 16th edition of the Sig Network meeting. As a reminder, this meeting is governed by the kubernetes code of conduct, which boils down to pretty much be nice to one another.

A

If you have anything to add to the agenda feel free, we have a.

B

Fairly sizable.

A

Agenda so it might get bumped to next week, but go ahead and add it anyway.

A

Hopefully, you can now see the dock and.

C

By next week, of course, we mean two weeks from now sorry.

A

Two weeks from now, thank you and uh we'll get started with triage, so Antonio. uh Why don't we start with you? You brought up one that was closed, that you wanted to talk about.

D

Yeah I I want it, because uh this is an example of the how a small change can have a big impact and and how long it takes has to detect it, and this was detected by chance by Patrick. So the the history is in the CI. We set up the Q proxy habitable scene period to 10 seconds and.

E

D

Was developing a test and that can become racist in the same situation, so I I was checking some graphs and doing some experiments and I say what we can use one. Second, it should be good and it seemed that it was good. But after four months you do scroll down and go to the graphs. You can see that we reduce the latency.

D

We reduce the network program latency, but we increased the DNS lookup latency. Those are five thousand node customers, and this is an example that small changes can have a big impact and we should be careful and this time I use broken. It's only the CI, but as you can see, it's an ugly progress.

D

The good thing is that that there is one thing from then we see it as we use the latency. The higher high percentages of 95 and 99 now are much better with his team, so this graph, the graph with the cycle. So you just see the latest one, the 95 and 99, that's the type, those improve and and the other way that's when I rejected my change.

A

Cool good catch to you guys and.

D

uh Thanks to to the Parker for reporting that well, that's the other thing is for people that want to test things. We have this stuff running in kubernetes, so I mean you go through secret, scalability, understand and, and they will be happy too, to show you how to run.

F

A

Alrighty, so next up, uh I was looking at issues and there's only one that was open recently that doesn't have an owner, and that is uh Coupe proxy does not validate Health Z State when answering to HC for EDP local.

B

Yeah I opened this. This is.

C

B

uh Just spiral out of that kept that I had filed for when the 20 7, whereby we we agree that this should be treated as a bug and hence dealt with accordingly.

D

But you are going to fix it right.

B

I found a PR for it already. It I think if I.

E

B

Scroll down you'll see the the pr should be yeah right. There.

A

D

You assign it to you.

B

I assigned it to you actually I.

D

B

ah Okay, I'll do that.

G

A

Then we probably don't need to spend much more time on this one for today, because it's in hand and Tim just picked it up and.

H

We'll get I just assigned it. Thank you. um I did want to talk about one other one for triage um light week this week, which is kind of awesome, um the other one that I thought was interesting. Well, there's a cni issue open, uh which.

A

I didn't read yet: let's grab that one.

H

Okay, so uh Mike you got it. If you think it's a real bug, triage accept it uh then the the new there's, a new bot, you may have noticed the new bot, goes through old issues and untriages them forcing the sigs to re-evaluate whether we really want to look at these old bugs or not.

H

um It ignores Frozen.

A

We're talking about the 2018 one here, yeah.

H

It ignores the issues that are life cycle Frozen, so we might also want to go through and sort of unlife cycle, freeze things that are really old, because if you go like the last page of Sig network issues, there's some really old ones that we probably should discuss again and and I picked a few of those for my backlog grooming.

H

um But this one uh Network policy proposal extend network policy. Layer, seven is a is a 50k range issue from 2018 filed by none other than Thomas Graf um and I thought. It was worth talking about a little bit here at the Sig. um Is this something we want to consider, or should we close it out?

H

Is kubernetes proper ever going to have policy at L7.

E

We were having a discussion on that right then, like on this network policy, having something not call it Network policy, but something else V2 as we did with Ingress V2, which is kind of Gateway API. Instead, so sorry, Antonio I yeah go ahead.

I

D

I the same thing: it is not available.

H

It could be that is Gateway. The API for new policy also.

J

A

Already seen somebody making a case for it but yeah and see someone definitely pushing for it.

J

Yeah I mean I I think it's actually come up and in some meeting or issue at some point, uh so so I know and I know. Certainly if you squint at you know and look at our API and look at what an L7 Network policy API would look like they're I can see similarities.

J

um We just have so many other things. We're trying to prioritize first um I.

H

J

H

Know well the good news. This has been open for five years, so no rush.

E

Sorry, team, I, I I I think that I I kind of uh got misunderstood on that I'm, not pointing that this should be Gateway API. What I was saying is that uh during our Network policy meetings, uh we were kind of discussing uh having some new network policy, but not calling that V2, because we are not never gonna, have a V2 right, uh getting compatibility with V1.

E

So what we've been thinking actually then and and and Andrea was creating some similar thing that is like Network policy V2, but with a different name as Gateway API was like the Ingress V2, but never got. That was never the Ingress V2 right. So we don't have this kind of confusion, and probably we should move that to that effort. That's that's my point on that.

G

We actually discussed it just two weeks ago when we looked at danvianships uh doc, so how if we should add in layer 7 as partners, moving forward.

I

I think we brought it up in a oh yeah. This is something we should think about, but exactly I don't think anybody was especially.

I

No, no exactly.

H

I mean I, think layer. 7 policy is a really important aspect of a complete system and I'm also not sure that it's kubernetes problem or right to solve.

D

Your seven minutes here they HTTP bats, are all the drpc or things that's the.

H

Thing exactly like look at what uh like istio does for layer 7 policy right like they do traffic sniffing on inbound packets, to try to figure out if you're speaking, my sequel like? Are we gonna? Do that I? Don't think so?.

G

But we could offer the support to uh basically forward if you have only four points like we have now that you would send it on basically service chain to level seven layer, seven uh function that would do uh handle that to be able to evaluate the the layer, 7 policy.

H

But is that something that kubernetes defines or is that something that some other implementation defines like istio already kind of? Does this right, uh yeah, Bridget you're, exactly right, um uh istio kind of? Does this already transparently, like you as a user, you don't need to know that you're using a service mesh and it can do packet sniffing or it can be disabled, to figure out what L7 policies it wants to apply and then there's a policy language that it uses to Define. What is a MySQL policy?

H

Look like as different from an HTTP policy right, um I, don't I, don't know, I'm, very wary of kubernetes opening that can of worms because there's a lot of worms in there.

A

I'm particularly wary of it in lieu of anybody being really noisy on this issue like doing its one thing, but then doing it when nobody's like apparently beating down our door to do it. I think is another, so I I would lean towards we close the issue and then, if somebody really wants to start beating down our door, they can, and we can reopen it and talk about it more.

C

C

I'd ask the question: why do we think we could do a better job here or a more consistent job here over the long term than somebody else like istio and.

E

H

C

Standardizing something there, but still it seems like a really big space to try to standardize that I.

F

Agree out of sorry, we should also just add a forwarding to the Gateway gamma right, because isn't that basically kind of this? If we, if that's like standardizing, maybe.

F

I

Could apply to http connections that were not service right, like in theory, you might want to have L7 Network policy for some external service that pods are connecting to.

F

I

Right but that I think like that.

F

That is within the scope of the gamma stuff. If they're converging the service mesh descriptions.

H

So there's an opportunity.

F

Which means we can close.

H

It there's there's an opportunity to say within the Gateway framework. This is where you would attach policy resources, but policy resources aren't defined by the Gateway API and uh standardization doesn't necessarily mean it has a case.io API. It could mean it has an istio.io API or it has a psyllium.io API, because those are both cncf projects too, like we don't need to own everything. In fact, that's poisonous right. That's.

G

That's I didn't say what it was, but I mean before we get to the function. That can do it, but we also and there's nothing here, but at some point need to start looking at. Should we try to do something around quick I would say it's really really hard to do. Multiple T subp we'll have more and more encryption everywhere. So so, how do we manage that from a from a service perspective? Are we asked gonna do TCP and UDP and that's it, and so, where would? If anyone wants you to do quick?

G

Where would it fit in okay.

A

I don't know if we are running on time a little bit.

H

For the sake of time, I think we're all violently agreeing um for the sake of time, I'll uh I'll capture, some of the notes of what we discussed and I will go ahead and close that issue and we'll take it off the triage board. um Back to you.

A

Shane some sounds good. Thank you all right cool. So that's for that's.

A

Extension to triage and I think we should probably time box it a little bit um for backlog, grooming, finding old issues and bringing them up that we started doing a couple weeks ago. Tim I think I already have this one open.

A

Is it this one? No, it's not this one! It's one of these I'll just reopen it.

H

It was uh the one the link here is Port ranges or whole IPS. Okay,.

A

um So support pull ranges are whole IPS and services from 2016. yep.

H

We got as far as actually having a cap, and then we didn't follow through with it, because it was hard and there wasn't a ton of obvious demand. um I think everybody thinks yeah. We probably need to do this, but unless somebody feels like I need to do this, it's not getting done um and I will note that it is currently marked as life cycle Frozen, which I'm going to remove right now and force us to reevaluate this issue periodically.

H

um Anybody have thoughts like new ideas or new Burning inputs into why this is actually really important and we're idiots for not doing it.

C

Just quick clarification there: the is the question either Port ranges or whole IPS.

H

I think the question is something better than individual Singleton ports. If.

C

I, remember correctly: wasn't there some discussion around well, Port ranges might be hard or otherwise more complicated. So when we deal with that was just let's just do whole IP, and then we skip what ranges entirely. That.

H

Was where the cap sort of ended up? Okay, all right thanks.

I

E

Right sorry, then,.

I

I was just gonna say, but the cap then ran into all sorts of problems with whole IPS, so could have turned out that maybe Port ranges would have been better I.

H

I mean what I recall was Port ranges were simply not implementable. uh In, like ipvs like there isn't a affordance in ipbs for doing a range. You can do a whole IP with a sort of weird the persistent flag, um and you could do a single port, but you couldn't do ranges and in iptables you couldn't do remapping, which I think is okay. We could ignore that we could wave that feature away with in the face of ranges, um but uh you're looking at NF tables. What what are the capabilities of NF tables here.

I

But probably about the same as IP tables.

I

G

Use it as a notation right, that's a short form today. What you'll do if you want to automate this? Probably that you, you have a function that runs over you sort of the definition with the port with the range and makes one I mean, makes it the single entries. You could do the same thing in the back end right. Yes, you cannot use the port range.

G

You will have to generate the rule for every port in the range which, of course, can be very costly if the range is like 3000 ports, but anyone doing 3000 ports should be well the source problems, because if we added here, you also probably want to do something with the service audio map interest. You want to have a service over ranges, so.

H

Yeah I I mean I'm afraid. The first thing people will do is want to turn on 60 000 ports, everything everything except the bottom 1K right and then ipvs is forced to open code, 64k virtual servers and.

G

That will collide with some other programs. That's yeah! It's like it's so foreign.

G

Application that doesn't work for this. It's just a matter of easiness and perhaps uh uh so ease of ease of reading and uh so I think just leave it if.

H

We leave it all into you.

G

Yeah, take it I mean say that there is a. There is a way that works by specifying Port by port and that's as we'll have to be well.

H

I mean it actually doesn't work because the there's a limit on the SCD resource side. So if you go in in open code, 64k ports, I, don't think XD will store it for you.

G

Yeah but yeah, but then writing the container specification with all these ports will be pretty tough as well there's so many places you need to change in.

H

Yeah I I, don't think that's a practical answer. um I I think we could get away with saying here's how you specify the whole IP will be forwarded with no remapping, um but I. Don't think we can get away with saying like realistically, it's either list your specifically list your ports and they better be a relatively small number or that's it.

H

So personally, I would love to see us go back to this I think the biggest issues we ran into with the kept were around API and expression. And how do we express this in the API, given the constraints that we've already laid for ourselves around ports being a required field and and so forth,.

G

H

G

Would you then say that, okay, you set the it, but if you want to do a service that we would be specific, Port specific course for the service um assume that default has implemented that, even though it's not possible then to map. Of course,.

H

Yes, I I mean it would be take that whole IP address and forward the whole thing on to one of the back ends and some of the sort of clever parts of service would not be applicable. Shane I see you waving the clock. There.

G

Yeah so there's of course, problems with that as well. Anything that comes in fragments will be have to keep track of uh yeah I.

H

Know yeah There's issues with affinity like is it all? Ports have the same Affinity there's a lot of issues to solve. It's.

G

Going to be this yeah.

A

Yeah, it sounds, it seems like this falls into the Fairly common category. We have of things that are open, but won't be moving that we talked about last time and we need to come up with some kind of solutions for, but like removing life cycle. Frozen for now may be good enough as an action I think, and then we just need to keep following up on how we're going to better organize some of these issues that need Champions, which I think this is basically the problem that we have here.

A

Right I mean there's technical problems we want to talk through, but the big overarching issue is that somebody needs to Champion it and nobody's ready to right now.

H

I'll um I'll capture some notes in this one too, just to indicate that we a we talked about it, so that the bot will be happy and not bring it back to us um and to suggest if, if somebody wants to pursue this, we're not against it, we just know that it's some challenges is that fair.

A

Help Wanted sounds good to me all right.

H

G

Have to go over all these things for multi-networking anyway, so put it in us. It needs to be looked at.

H

If we have other issues in the backlog which are of the same, like we'd like to do this, but we're sort of constrained by API compatibility that we need to talk about at some point.

A

Roger, that is, anybody opposed to Jumping forward and uh saving some backlog grooming for next time. Given the time that we're at go for it, then I would like to open it up for Antonio.

D

uh Okay, so let me check this again: yep.