Kubernetes SIG Windows, 8 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes SIG Windows 20200908

Description

Kubernetes SIG Windows 20200908

A

All right welcome to the september 8th, sig windows, meeting everybody. um This meeting is being recorded and so just make sure that you adhere by all of the cncf code of conduct and guidelines, uh we'll start off with a couple of announcements.

A

um The first one michael kind of added here is that calico is now open sourced for windows. So it's kind of big. I know there's a lot of customers asking for calco support for windows and it does operate with uh linux quite nicely. Everything. um The next announcement is that sig windows will be presenting at next week's uh community meeting. uh That's next thursday, 9 17..

A

um If anybody has anything that they want to be included in that community meeting, please reach out to myself or michael michael on slack and we'll make sure to kind of add any highlights there uh for people new here. This is just a an opportunity for different cigs to give a ten minute presentation to anybody else, who's at these community meetings to kind of highlight what they're working on um what the roadmap is and also solicit uh kind of support and new contributors.

A

So it's a good time to kind of share. All the work, and also just join for other sigs to kind of keep up to date with what's going on with the project.

A

um One more announcement which isn't done here is: we've started up a bi-weekly sig windows, backlog, grooming meeting every other thursday at 12, 30 eastern time, 9 30, pacific time. The next uh meeting is this thursday, so please uh join if you can we'll be posting links to the meeting in the sig windows slack a little bit before the meeting, and so now we'll get started with the agenda.

A

First item here is uh james. You want to take this.

B

Sure um so I was looking through some of the code for metrics. I think- and I came across, that we have still have some hyper-v support for uh docker and alpha um and I believe uh we're moving forward with container d for hyper-v because of multi-pod support. uh So I open up an issue to potentially remove that. I think the the recommendation came back to mark it as depreciated in 120 and removed support in 121, but I wanted to bring it up with the community to see if anybody had any thoughts.

A

Yeah, I remember looking at that and I believe, there's some pretty severe limitations for running uh pods with hyper-v isolation in docker.

A

So I think, given that we're moving towards container d and hopefully well and we'll, have much better container d support there, I think it makes sense to kind of depreciate this code path, but I'm open for the suggestions was: do you have any thoughts on that.

C

No, I haven't heard anyone uh using hyper-v with docker because of the limitations, so I think it's pretty safe to deprecate it unless we hear otherwise from someone in the community.

A

Okay yeah, I guess we can give people a few days to comment on that and then move forward with that. That sounds like a good plan.

A

Next item, uh pod security recommendations. I think people have been waiting to hear some of this. So do you want to take this one too james.

B

uh So um there's an open issue that would like um linked there and uh what I did was went through all the various psp.

B

That's already out there, and also through the pod security recommendations that the one of the other sigs went through and created, and I kind of did an analysis of what it looks like and some of the things that might this affect windows, and to summarize, I think, a lot of them don't affect windows, but the usage of volume types.

B

The usage of the host file system- and I think, we've discussed this in the past- was running as non-root, uh making sure that we're not running the container as container administrator, and then there was a specific one that wasn't listed in any of those but gmsa making sure certain pods don't uh run certain gsma, gmsa and uh so yeah. I just wanted to call it out. uh Have people take a look at it um and leave any comments uh and if, if not, then the next step would be to open up a documentation?

B

Pr to point people towards these are the recommendations from sig windows for um for various psps and linking it to that pod security standards.

B

The other thing that I also did in conjunction with the kepp for privileged containers, was to take a look at how that would change for um if we do introduce privileged containers and so there's quite a pretty extensive list in the kept there on how that how that would look. So please take a look at that as well and um yeah. I think the if there's any comments or questions.

B

Otherwise, please leave some notes.

A

Awesome thanks. I think people have been kind of looking for guidance on how to use these for windows for a few releases. Now, since windows is becoming more and more state mature in kubernetes yeah, I know.

D

Sorry, sorry james go ahead.

B

uh No, I know I think, maybe it was you too, as um I think, you've run into some problems with it being attached to the linux side, and so we've got a couple open pr's to resolve some of those as well. So I definitely see a lot of activity uh in this sense, so go ahead.

D

Yeah, one of the things that I would like to know is uh like in openshift the way we associate security policies to uh parts is uh we do it by default like for every part that is coming up. We, we add certain security policies like uh s, linux and other things, uh and we want to move into a world where we can rely more on runtime classes.

D

For this like in the part, spec say if there is a runtime class associated and if that runtime class associated is with the windows node instead of as a linux node, we would not like to apply. uh We would not like to apply those security policies to those uh type of parts, but the problem we see at this point of time is uh with the runtime classes.

D

There is no way to surface clearly if it's a windows, node or not, we are relying on a node selector, plus a toleration that gets appended to the pod spec, so anyone can actually add or uh or modify the port spec to say that, yes, I am a windows node, even though it's it's a even though it is a linux uh part. So I'm wondering if, if you want to have like some sort of standardization around it saying that this particular label is windows specific, this particular label.

D

Is uh linux specific just like how we have standard labels on the node saying that slash os is equal to windows or linux? Can we have something uh similar on the runtime classes, which is specified that this is a windows, specific runtime class versus linux, specific uh runtime class.

A

So I I have been going to some of the signod meetings too, and I know that I think sergey from signode has been um trying to make a decision about if uh they should graduate runtime classes to stable, with this release or not and we're opening where they opened a google doc and we're asking for usage examples of runtime classes and also feature requests and our blockers from moving that to stable.

A

Can I I will uh post that in the sig windows slack channel after this meeting, that might be a good place to to comment on there and um have some other on-time class. Implementers also comment on that. If that works for you well,.

D

Sure that that works for me, I just want to get to know what does the sig think about it like the windows think about it like? Do you think it's because when I looked at the history of the runtime classes, implementation, I believe uh whoever has written the design document. He clearly mentioned that we can have an explicit label or a reserved label which says this is a windows.

D

Specific uh runtime class we can have is what he has mentioned in the design, but I we did not implement it as curious like if there was a reason for it not to do it. That way.

A

I don't have that history was, were you around when or were you here and involved when runtime classes were getting implemented, or was that mainly patrick.

C

I was in touch with patrick, I wasn't in the uh I wasn't too involved in the sig windows community. uh We had a discussion with patrick, but I patrick was the one driving insecurities.

C

Do you have a link to.

B

To that uh where, where it was maybe discussed, you can take a look.

D

At that, oh sure, uh I don't have it handy now, but I can uh post it on uh sigmundo slack.

A

Yeah yeah, I think we could probably take some of that conversation to slack with some more links after the meeting. I don't think I'm opposed to that idea. I know that just relying on node selectors is cause always kind of leaves windows with the short end of the stick. If people choose to not implement node selectors for all of their their workloads, so maybe we can have a salient argument for a dedicated field.

D

Yeah, the the other thing is, uh as they told some of the distributions of kubernetes. Most of them are like homogeneous clusters. Sorry heterogeneous clusters, uh both windows and linux, worker nodes.

A

D

There is an inherent bias towards linux nodes because they have been around for a long time in the kubernetes space and uh we cannot take the defaulting out, uh at least in openshift, for the security policies that are being applied to the pods. So if you have some sort of standard way to distinguish between a linux versus a windows worker node, we would say that, yes, this runtime class is specific to windows. So we would not like to apply uh the port security policies of linux on these windows nodes.

D

And that defaulting happens at the api server level when the when the pod is actually getting create.

A

Yeah, no, I think these are good. That's a good uh conversation to to have.

D

Sure I I'll post the uh the links. Thank you.

A

Sure, yeah and I'll make sure to follow up with that too. um I don't see anything else on the agenda, except for. um If we have a minute we can go and look at the 120 pr's and see where those are that was kind of the first thing here, um but I'll open it up. Does anybody have anything they want to discuss.

C

So I think one quick thing uh jing last time brought up uh the run as user uh affect the file permission like it does in linux. So I asked the the windows containers engineers.

C

They see user field being passed to hcs um and the assumption it will change the user context in the container uh and and hence it will affect the file permissions uh based on what the user will have access to. uh Now they were uh asking if there was a specific interaction with the file permissions um that we're looking into so I have asked jing before I mean I can take this conversation further but yeah I was looking at the you know the the github. I don't see the issue so just a reminder to jenny.

C

If you can open the issue, the engineers can look at it and there could be a back and forth there as well um on the on the github, uh because there were a couple of follow-up questions. The quick answer was yes, it will affect in some way, uh but they're trying to understand what interactions you will you're looking for. So you can open the issue on this github. uh That would be helpful in getting the answer you need.

A

Okay, I don't see jing on the call I'll ping her in slack and if not, we can just open up an issue and have her fill in the details. But thanks for following up on that nose.

A

um Okay, I have a quick update about the device class prs as well. I asked- and we do have a little bit of a budget to be able to run device class uh periodic jobs in azure. For um specifically, I think there's a couple of prs, both implementation and test prs around gpu support.

A

I don't have an eta of when those will be up, but it probably will be a few weeks, but I'm not sure who all was involved in that pr, but we'll have that coming at least to make sure regressions don't get introduced in the future, for that, at least on azure.

A

Anything else before we move into some of the 120 pr's.

A

All right, um as always, you can find the sig windows backlog up here at the top of the meeting notes. It's this project board number eight for uh in the kubernetes projects, which I open here, um and we do try and keep it organized for what's kind of in flight and in progress and in review for each review. I was taking a look before the meeting and I saw pretty much all the issues called out in the um july 21st meeting for move to 128 already open here.

A

So if anybody uh wants to start getting into reviewing some zig windows prs, this is probably a great great place to start. A lot of these already have been open for a couple releases and already have a lot of discussions, um so you can kind of see what people are commenting on and reviewing from as well.

A

uh I haven't checked the specific priority or the status of each one of these, but I think a number of these are still waiting for comments or waiting for some comments to address to be addressed.

B

A

All right, I don't think we need to go over this and this meeting. We can do this more on the next thursday meeting. So unless anybody else says anything, I'm going to give everybody 10 minutes back. I think.

A

All right, I guess that's it for this week's uh sigmundus meeting thanks everybody.

C

Thank you thank.

C

C