Kubernetes SIG Node, 7 Mar 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SIG Node Sidecar WG 2023-03-07

Description

Meeting notes and agenda: https://docs.google.com/document/d/1E1guvFJ5KBQIGcjCrQqFywU9_cBQHRtHvjuqcVbCXvU/edit#heading=h.m8xoiv5t6qma

GMT20230307-170534_Recording_1406x1120.mp4

A

Hello, it's a sidecar working group weekly meeting, it's March, 7 2023, welcome everybody um yeah before the recording we started talking uh about uh active PRS. So um what do we start with? It's like I know that one PR was closed. Matthias. Can you it's different? I, don't I'm, not sure, there's all.

B

Right, yes, one PR was closed, but was replaced by another one, so yeah, basically, I gave up in uh trying to re-implement entirely the program manager with the butt status from Cube, runtime and uh uh so I I closed it and I use gunju's ID to like update both statues, the V1 status and the coupon time status so that we can use the keyboard 10 statues where we need it.

B

B

B

A

And you send this PR into mighty poster I was a little confused about that.

B

uh Yes, yes, yeah, because the other one was like on uh kubernetes uh main main repo, and this one I opened on your branch, because uh yeah I noticed that we we merge everything on your branch.

A

I think it's a pre-work that can be immersed there.

B

Okay, I can move it. If you want.

A

Yeah I wasn't sure like. If you study you give up and like it doesn't, it means that it doesn't work or you have it's. uh It means it's working um yeah. If you can move it uh to main reports, it will be great because it's it's a pre-work for actual uh PR that you have for sidecars right. Oh.

B

Okay, okay, so yes, sorry, yeah I will move it. Yeah I gave it because it it wouldn't work. I I, don't know why I I think it's partly on how how uh this particular test was written uh to set the preconditions and yeah. Now I spent like two two weeks on it uh one hour per one hour and it's difficult to to get into the code and try something and then you need to give up because of the kids or so yeah. Okay,.

C

Password issue uh I think the purpose of the issue is to make quiver on time manager be aware of start and ready state so that uh we can figure out which, in a container to start so I think that is the purpose of the issue and the original proposal was that to add, started and ready state to The Container status and pass it to the equivalent time manager right.

C

Yep. Yes, but, however, there are already proved managers in inside the quiver runtime manager.

C

There are already that information inside the coconut time manager, so I I think that we can just use those proof. Managers inside the file find in containers to start the function so that we can minimize the changes to the existing code base.

C

So yes, so my PR, the meant that approaching my PR.

A

Can can you paste it in a chat so I love? It.

C

A

I think it's here.

C

Yes, it is there.

C

So if you see clear on time, container.gov.

C

Thank you there there is the function find next. You need containers to run and create a generic runtime manager already has the proof manager inside the struct. So we can just use that information here.

C

A

um Yeah I see so you you're, using uh State running, uh means that the containers are always running right. Yes,.

C

And under that, yes, there are startup manager.

A

Okay, yeah so um yeah. This approach would work um for uh initial stage, but uh what we discussed is we would need to know when it started. So we went uh startup probe completed so we'll need uh my tspr anyway.

A

um It will be required, uh maybe at later stage so I mean independent from that, like it's another step of implementing the whole whole Camp right, foreign.

C

Manager is always he succeed after the startup, so we can always get that information here in starter manager.

C

A

Yeah, that's what this PR is trying to do right, so one that we looked at before so in this mirror that we want to know was it started. I mean right now started only indicated indicate the same as container State running. So it's the same. Oh wait.

C

Yes and the downside there are stuff to manager here.

A

A

What is a startup manager? Is it something new or.

C

It was there already, it is inside the curator on time manager, foreign.

A

A

A

Yeah I'm trying to think of implications like start does the failure mean that it's uh still being failed and then it will turn to success and we'll never go back to failure right, yeah, okay,.

B

Yeah as soon as we we succeed, we stop probing.

A

And we'll be around with uh with the status uh for the Lifetime right, okay, yeah, I guess this will work as well. I didn't realize that we have it.

A

What do you think about this approach? Is it.

B

Yeah I think I think it can work. Actually that's why I I added this to the to the meeting. uh uh It was the second point to review. Actually so it's good that uh yeah yeah yeah, it's exactly it's it's exactly this from uh yeah.

B

So as as someone uh looked in in depth in this uh pull request, number two.

B

Yeah exactly this one.

A

Okay, yeah look at the API version like I haven't looked at this in depth, and okay I I didn't realize that this is available, because I thought that we will need this refactoring before we. We can.

B

Even get this yeah, but apparently we don't yeah.

A

Okay, you enjoy it's a great find I think we can uh so with this um spr.

A

Awling, so is this PR has everything like? Is it uh uh basically starting sidecar and uh um we can just use it.

C

um Basically, I think uh eye cover a lot of cycle container life cycle things, but as I comment in my PR there are some uh difficulty in here. You can see downside. Yes, the last comment.

D

C

We we have to differentiate the initializing State and after initializing States, because in initializing State we have to start this unique containers in order. But we should not. We don't have to follow that order when, after the initialization state but I'm not sure how to differentiate.

C

That's is sidecar containers start and terminate after the initialization state, I'm, not sure how to figure out it is which state it is.

A

So, okay, when we want to at least when we calculate the status, we need to know whether we want to restart side car. Is it what is in and the side? If it's already passed in its initialization, then we need to restart it again. Is it so? The.

C

Situation, yes, yes, we have to restart the sidecar containers anyway, but initial in initializing State. We have to start the sidecar container in sequence, but after initialization State we don't have to follow that order. I think we can start every any containers as possible, but the problem is which state we are in here. Like is these sidecar containers terminated in when in the initialization state or after initialization state.

C

That is the problem. I think.

A

Okay, I haven't looked at this code.

A

uh Is it in uh runtime manager.

B

C

I think it is hard to find in the code.

C

In many case, this will just work fine, but.

C

C

Let's say this: when the at least when we finish the initialization state, so every side, clear container starts and Main container also starts, and if the sidecar container is terminated, then we have to restart it right.

C

C

And if the cycle containers is terminated and also main container is terminated at the same time, we should restart them at the same time, but.

C

We, if we don't know if this is initialization state or not we have to if this is initialization State, we have to start any container first and then restart main container.

B

So to me it's the same. It's the same. We always need to. If, if the init container uh is, is a network container, we need we need to finish. It start before we start the main container foreign.

C

Container will not restart, then we we don't have to restart the main container. That is my problem. If the cycle container is always terminated again on the and again, then what will be the next.

B

Yeah yeah, but so so the main container cannot start and the Pod is in a crush Loop or something like this I.

D

B

It makes sense because if someone has an important sidecar implemented as a neat container, he wants the sidecar to run before we start the the main container. That's a prerequisite. No.

C

But but after the initialization state we we already start all containers, so I think that we don't have to keep that sequence anymore.

C

Like maybe three containers are terminated at the same time, then do we have to restart it in sequence, or do we have to restart all containers at the same time?

C

That is my problem.

D

I'm saying if you had like three sidecars and they all crashed rough at the same time or do you need to ensure that they get restarted in the same order that they were declared?

D

Except this really question.

C

Yes, yes, do we have to do do we have to restart it in sequence or not even after the initialization state? That is my question.

A

I, don't think sequence was ever discussed because they already initialized everything they need. They just need to restart as soon as possible.

B

It it depends if it's uh data that is persisted or not.

B

Because, let's say you have a sidecar that needs to to get I, don't know a certificate, and the certificate is only in memory if it restarts it needs to fetch this certificate again.

A

Or yeah, but it doesn't depend on any other container right, so it can start in like and it will do its initialization, but all other containers can still work.

B

Yeah yeah uh there's no reason.

A

B

Trying to think at the use case that uh but okay, so so as he as as it is today, going to you always start in sequence and and you would like to start faster but by detecting that it's a restart and just start everybody. At the same time,.

C

Yes, after initialization State, I I think we can just restart all containers or terminated containers. At the same time,.

B

Yeah but I I think since we are in Alpha uh uh I I I, don't see a big problem in saying that we keep the order whatever. Even if it's after initialization, we keep the order and we wait for each.

D

B

It's it's easy to explain in the document and and if, if people start complaining because it takes too much time, then in the next iteration we can try to detect and and start all all of them. At the same time, no.

C

Okay, I think, if that is the case, the current the current Pier is just okay.

B

A

Okay, so I think action item is to use that PR and like matches and we don't need uapr.

B

Stuff yeah yeah, then we don't need my PR. Yes,.

A

Yeah, so I I saw another thing that uh people um like uh I, think team is trying to do uh for startup probe, support uh success, threshold, success threshold, meaning like how many successful Pro uh you need to uh see before you Market is yourself started so with this change. This will still work right so because it will not I just don't remember whether failure indication failure of individual probe or it's a failure of um uh it's still failing, meaning that it didn't uh exceed the success threshold.

B

To to be checked just add the comment there and we will check okay put it right now. So then we can like uh just just make sure.

A

A

Because it's not active work but uh I mean there is active PR, but it's not actually been worked on. You may change at any moment.

B

Yeah then it will be. It will be team's problem to to solve that if we merge first.

A

Yeah, okay, uh so yeah we have API change. We have this change and uh all other changes like uh it's much smaller I think they are mostly. What is the Uber issue.

A

And uh I I talked to a few people about Todd's idea with logs uh everybody loves it so I think we just uh we'll take it and start implementing unit end-to-end tests um so restart on failure. So I'm going to say you already have that part right, I, don't think it's! uh It will be needed after that change.

C

uh Yes, yes, it is already covered.

A

Here, oh nice, I didn't know. I can do that, um enable probes for sidecar containers this. This will be quite straightforward right. It's mostly API change Interstate at that point for Android State equation.

C

That that is already covered, I think part ready, I'm, not sure.

A

Yeah, um it may just work. I checked the code uh some time ago. It may just work but I'm, not sure what the radio State I mean it may just work after we enable probes, I think right now registered, for you need containers. Just uh it's true when it's completed um yes, so maybe there is some problem like once. We enable it for sure it probably will just work, but uh it needs double checking uh enable attack hooks uh yeah. This is also quite independent from any other work.

A

I think it will just uh because we have the same function start container for all containers right, so it just I mean whatever declare it as a life cycle hook will just be implemented.

A

A

Yeah, okay, so it feels that we covered everything that and um I didn't check what about the resource calculation? Did you change anything? No.

C

No I didn't change any okay.

A

Yeah I I found person in scheduler and um I've been doing many times. I really think like I will try to make uh thoughts be immersed, so we can update the resource. Calculation as well is on vacation and he will be on vacation till code free, so I don't have anybody who is like uh who can help Mirage PRS quickly quicker.

B

A

B

Is not available.

A

um Try to merge it in.

C

B

I will review as well to tomorrow morning, but uh go if, if you have a Cycles okay, you can review already today, yeah I, I I will have a look tomorrow morning as well.

A

Okay, thank you. Thank you, Matthias for trying so hard with this refactoring and uh I I didn't know it can be done differently, I I. Clearly, uh no.

B

I mean it's it's good, that we have a solution and I'm really happy by the the work of uh of gunju. Thank you very much.

C

A

Thank you. Thank you. Okay. Let's conclude our meeting and uh try to get reviews done. Thank you. Bye.