 Welcome everyone to KubeCon North America 2020. Excited to give you a presentation today around the interesting SIG within Kubernetes SIG architecture. And hopefully we can give you a background and how you can get engaged and what our role within the project is. So we go to the next slide. I'm Derek Carr. I've been active in the Kubernetes. So the slide's not progressing, John. There you go. All right, virtual event. Well, I'm Derek Carr. I work at Red Hat. I've been active in the Kubernetes community since early inception. Presently serve on the steering committee and participate in SIG architecture and SIG node. And I'm joined today by John. Hi, I'm John Bellamerica from Red Google and I've been involved in Kubernetes since maybe, well, probably since late 2016, but primarily in SIG network. And then later in the last year or two in SIG architecture. So that's one of my primary areas of focus. Awesome. Well, hopefully with the two of us here, we can do a good job explaining how to engage in Kubernetes. All right. So let's take a step back and like remind everybody about the goals of the Kubernetes project. The project is maturing. But it's grounded by the goals that we've set out from its inception, right? Where we wanted Kubernetes to be portable across multiple clouds. We wanted to be kind of general purpose, not too opinionated. We want people to find value in multiple places. And that requires us to meet users where they are. And with that, when we design the project and the subsystems within, we want to ensure that we offer flexibility, extensibility, and points of integration or specialization to allow people to ultimately meet their needs. As a project, we aspire a lot to ensure that most of our procedures and practices are automated rather than manual. And we want to always ensure that like as a project, we don't stagnate and we recognize that users needs and platforms evolve. And so we want to make sure that we can keep promoting stable evolution of the project. So with those like framing goals in mind, we kind of go to the next slide here and we try to say like, well, those are great goals. And they hopefully allow the Kubernetes project to maintain long term success. But that only works if we back it up with community values that allow activities to scale. So one of the earliest things we did within Kubernetes was to define a governance model that prioritized distribution of responsibility among various groups within the project, rather than centralizing all decision making within a small few of individuals. Generally, we think if you know about networking, you should be exercising your domain and networking knowledge and have autonomy within that SIG. Same with, you know, Node or scheduling those people who work closest to that problem space know it best. And when we interface within the community, we want to make sure that we're representing the community rather than an individual product or company need, because by doing that, we're ensuring that everyone is ultimately being successful. As a community, you know, we always strive to do better and SIG architecture is no different than the rest. So we want to make sure that we're inclusive and hearing everyone's viewpoints. So if after seeing this presentation, you're inspired to join us in a SIG architecture meeting. I'm sure John or myself or anybody else who participates would would love to get your feedback and and help make your impact known in the community. And then the key point here on the community values, when we talked about the project wanting to ensure that it keeps advancing the state of the art, we need to ensure that like our community values evolve and don't stagnate themselves. So with that context in mind, if we go to the next slide, the communities project itself, as we said is composed of many SIGs, and there's kind of different ways you can look at SIGs. Some are very horizontally oriented, right? So they deal with the guts of how the communities project itself works, maybe the underlying API machinery or how authentication. And then some are more vertically oriented like scheduling the node networking storage. And then we have this specialized kind of group of SIGs, which we kind of look at from the project wide perspective. And SIG architecture was one of those early SIGs that while it doesn't have individual domain responsibility for any of those horizontal or vertical aligned areas, we do aspire to ensure that we can provide sufficient guidance and lessons learned across the communities community as a whole to ensure that every individual SIG is not repeating or encountering the same problems. And so today when John and I talked through the SIGs ultimate responsibilities, hopefully you'll see that the projects and practices we have running help keep ensuring that cube as a whole is successful. And so we'll go to the next slide. Sure. So as Derek said, SIG architecture fits as a sort of project scope SIG. And with that concept of distribution is better than centralization. We still see this need for sort of consistency and for a consistent bar across the project for that is bar of quality. And also for things like APIs, we have consistent set of conventions that we want to use so that the APIs from SIG network and the APIs from SIG node function essentially the same manner, not just the machinery but the structure of the API and the conventions around naming and things like that. Those general API conventions design principles, we're using declarative APIs with these reconciling controllers, things like that that are just fundamental to Kubernetes. Those live within this within this SIG. In addition, we work on some of these cross cutting policies. So things like how we deprecate features and APIs and the process by which we improve Kubernetes. So what are some of the other issues. It happens sometimes that a question will come up through a SIG that the SIG doesn't know how to answer. They want to make sure that it works in a consistent manner across what other SIGs may be doing. And those sort of things will come to SIG architecture to make decisions about or have discussions about. Sometimes SIGs will disagree, people within the SIG will disagree. At times they brought that to us as an escalation. We're really not an escalation point because again distribution is better than centralization. We're not alerting over all the other SIGs. We're setting policies across the project. So when those things come to us, we're not going to be overriding SIG decisions. But what we might be doing is talking about how those decisions might be made. Or what principles apply that might be repeatable within that decision making process. So I'm not sure what this last bullet is here. I didn't put it on here. But in general, we do like to solicit feedback from anybody in order to do that. You start a thread on our mailing list. SIG architecture. You're happy to join it. And once we've got a thread going, we try and resolve what we can on there before we actually talk about a meeting to try and be respectful of everybody's time. So subprojects. We have five subprojects within SIG architecture. One is the API review subproject, which essentially documents all of those conventions and design principles around the API. And also runs an actual review process where every time there's a PR that comes in that touches an API, there's a set of reviewers and approvers who will review that change. Make sure that it's adhering to those conventions and often give very good advice around how to improve your API. So it's a really valuable process that we've seen and we've gotten great results out of. We also have a code organization subproject. So here again is one of these larger structural things that the SIG handles. And this is about managing our dependencies and deciding what pieces of code can be moved out. We've got a set of staging repositories that allow us to sort of refactor the code a little more effectively and be able to import the code into other projects more effectively. So that's all managed by code organization. Conformance definition. We talked about a little bit earlier. That's the group that manages the conformance testing process decides which tests are to be deemed required for conformance and in effect defining what Kubernetes is. The enhancement subproject is new since the last QtCon here. It actually moved over from 6pm, which shut down. And that manages our Kubernetes enhancement proposal process. And that means how our engineers in the community can sort of get consensus around the features that they want to build and add. And how we can manage the progression of those features through alpha, beta and stable release and ensure the quality bar. As an adjunct to that, we've also recently added this production readiness review project, which runs a process, something like the API review process. But it's not reviewing code. Generally, it's reviewing a specialized section of the cap. So we've defined a set of questions that the developers must answer to ensure that the pieces of functionality and features we're adding to Kubernetes meet a bar of support availability. Awesome. Well, thanks, John. Many folks were new to engaging with Kubernetes. When we talk about these subprojects, they are literally like dedicated meetings that folks can join and participate in if they have a particular interest. And so while SIG architecture meets at a SIG-wide level at a biweekly cadence and topics for that meeting are usually generated through the mailing list. Individual subprojects, which John gave an overview on, have discrete meeting times to just focus on that particular activity as well. So one of those ones that we can talk a little bit about was around API review. A lot of people who engage with Kubernetes appreciate the fact that it has a relatively consistent API perspective. API review as a thing in the project was not something that was ultimately something that very few reviewers within the community had maybe the overall breadth of awareness and knowledge in the early formation of Kubernetes to ensure that that consistency happened. Within the API review subproject, though, now we're trying to figure out ways to scale that review process out further, but ensure that we don't lower our standards and that as new questions arise that we document those outcomes. So there's a project board if you're interested in checking out the activities that take place in that subproject. And as well, if you're just interested in understanding like the design philosophy around APIs and changing your APIs that Kubernetes aspires to follow, even in your own extension projects, which we talk about later, like as an ecosystem, it's great if we can all be aligned. I strongly encourage everyone to look at our API conventions documents like really deep and thorough and can help people build APIs that fit Kubernetes style, even when they're not in the Kubernetes project. Now, API review is required for anything that is in the main Kubernetes Kubernetes distribution. So when we talk about the goal of the community being portable, right, no matter where you procure Kubernetes, you want it to work. Consistently, we do recognize that there's a growing ecosystem of projects around Kubernetes. And so you might have seen some things come up around things like the usage of the Cates.io API namespace versus say like an x dash Cates.io namespace. And so where we talk through things around what things are subject to API review and the process around that, that's a lot of things that you might see in this subproject and we would love participation. But there's a lot of great lessons and things to learn. So we can go to the next slide. Code organization as John talked about like Kubernetes was originally just one massive repo right Kubernetes Kubernetes and we are building on the output of many other open source communities to open like do what we do in Kubernetes right whether that is some of our earliest dependencies were C advisor or RunC or Docker or any of the other projects you might see get rendered into a typical Go project. Well over time this gets this just gets crazy and it slows down progress in the community because you have a lot of folks all trying to work within one monorepo and getting rendering alignment to work well is sometimes difficult and then you sometimes have challenges where people try to consume individual libraries or subsystems within communities in their discrete projects and they don't want to bring the entire Kubernetes source tree with them. And so I would say in the last, I don't know if I'm wrong John maybe in the last year or two we've gotten probably far more disciplined on our approach to this and so the code organization subproject kind of was born out of that desire to realize oh we got to do things better. And so basically if you're interested in like taking a very large go project and figuring out the best way to structure it across a reasonable number of repositories that all of us in the community can follow like this is this is the place for you and as well as if you're interested in consuming particular subsystems within Kubernetes for use in your project that may not be well factored yet to meet your need. I think everyone in the community wants to help others, but they want to help it in a way that they know that they're providing the help on. And so making those those issues known can help us figure out then, as John talked about earlier, what things we should maybe promote into their own discrete repo that you can depend on without the whole thing so that's that's code organization and going to the next one. Conformance tests and promotion. So this is a process that is important and one that is ever evolving so Kubernetes rapidly expanded in its earliest formations and the actual set of project. Typically many things had a testing right we want to make sure the feature work, but not everything was labeled as conformant and for a variety of good reasons right there were maybe integration specific to particular cloud platforms that were not necessarily portable. And, but you still want to make sure that that function worked right and so while we have a very large and rich body of ED testing within the project and of course these things can always improve that which was required to be portable across everywhere you can consume this is is is a smaller set, and you know has to be expanded judiciously right. And so the conformance tests and promotion sub project is basically evaluating that problem right how do we identify the right set of tests, the right set of function that should and must be portable across all areas of which you can consume Kubernetes, and then where we had maybe project debt where we lack sufficient testing. We are now trying to go back and say well what can we do to supplement the those gaps within our testing. And then on a forward going basis how do we ensure that our project postures and positions like don't allow those gaps to reinsert them back reinsert themselves back. So one of the key things that came out of Sega architecture was like this is clarifying statement that like, you know you need to have these tests before you can promote your feature to beta right they might not be labeled yet for conformance but they're at least in the project and ready to go in case we know things actually were being properly tested so. If you're interested in helping define and enhance and enrich what Kubernetes means no matter where you consume it. The conformance test and promotion project is a great place to engage with that. And the last project here is around enhancements. The history lesson of Kubernetes is sometimes useful which is we we had a small group of engineers kind of collaborating and we kind of had a rough idea of let's write some design documents on what we want to do. But that wasn't really very formal. And then we kind of evolve that a little bit and we stuck things in a cube community repo and kind of throw ideas out there had an ad hoc way of of getting consensus among the maintainer community. And then as you can imagine over years Kubernetes just grown right and so we needed to scale that process. And so now we have this enhancement sub project where we have a standard enhancement template that says this is the change I want to make. This is how that change can be tracked by the release team. This is how we know that a test was being implemented and executed for this enhancement. This is how we can appropriately document that things got into the website documentation so our users know how to consume the feature. And then a clear set of like what is the use case my feature is trying to do what component areas does it impact. And then we from that we can kind of build a map of like helping you navigate the community to know these are who you need to approve these are the six you need to go and engage. And ultimately hopefully get your feature idea into the project. I would say that this is this is a an ever evolving process I think we've learned a lot and John would agree as we go through caps on on how things are. And so if you've wanted to write a cap or you've reviewed a cap where you've read a cap where you have a new idea. But if you want to suggest a tweak or a change to the process, please engage the enhancements of project because we're always trying to figure out ways to better automate this and drive attention to it. And so with that, go ahead, John. Yeah, so along those lines one thing that was recently added to the gap process was the idea of production production readiness where he is so I mentioned this a little bit earlier but he really tries to get, you know, developers in our community are, you know, top match professional folks but they're also developers meaning they think about their users and how their users are going to make use of these features to to do whatever it's going to do. And those users are typically application developers that they're thinking about because those are the features are mostly built in for so production readiness review is intended to shift to shift the thinking a little bit from to the to the operator point of view. So as a person operating this cluster. They don't necessarily care about the specific features that they're that that might be offered by a saying, but they care about making sure those features are working properly. So, how can the operator best ensure that whatever you're adding is serving your users. So essentially what that means is making sure you've got good metrics, making sure that you have a way to turn the feature off, making sure that you can roll back the feature, making sure that that those metrics can tell you not only that the features in use, but that is actually working as expected. That's some of the, the set of questions now that are part of the kept prep process. And essentially those questions are broken down into when you're going to alpha. Here's the things you have to have already figured out when you're going to beta here's the things you have to have already figured out here's when you're going to stable and with the bar obviously matching up each, each step of the way. And like API review, there's a set of a set of community members who are PRR approvers, and they actually will need to look over the answers to those questions and work with the author of the cap to make sure that the questions meet meet the needs of operators and this process. So this is pretty new. We've piloted it in 119 and 120. And it will be mandatory in 121. So folks that are writing caps. It was more or less mandatory to write it in 120 but it wasn't a blocking thing. If you didn't get approved in 121 now, we will potentially block advancing your cap or concluding it in the release, unless you fill this out to our satisfaction. Of course, we will work with you in any way we can to make sure that that the feature needs to meet the partner. And I don't think for most folks, it's a hard bar to meet. It's just now we have it documented now operators that and providers that consume Kubernetes and distribute Kubernetes actually have a label built in right there for how to handle certain situations. Excellent, John. So like, maybe one way we can think about Kubernetes now is like, obviously it's a it's a container orchestration system at heart, but it has grown to be kind of more than that, right? It's basically a platform for building higher order platforms. One of the things that we often experience in Kubernetes, whether it's at the individual discrete SIG level, or those who want to engage with SIG architecture is, you know, folks have great ideas, right? They want to use the enhancement process to propose their new feature. They're ready to sign up for their production readiness review. They got their API all spec'd out. They want to get their API review. And they're just, you know, ready to go. And so, John, I heard that you had an idea for an awesome feature you wanted to add to Kubernetes and maybe we could kind of talk through a right way of navigating your interaction with the community. Yeah, absolutely. So I have a little sign project I've got going where I'm trying to build my own launch platform for rockets that go to the moon. And the thing is that I haven't been able to build the rocket, you know, quite good enough to reach the moon, except if I time it just right so that, you know, the rocket will reach the moon right as it's closest approach to Earth. So I was thinking that I would build a model that models the orbit of the moon and when it, and how long it will take the rocket to get there and then calculate exactly when the rocket needs to launch. But the problem is that, you know, with cron job, all I can do is schedule like on these periodic intervals, right? I can't plug that in like how do I, I want to build my own controller that can model, you know, can include my own scheduler, whatever it is. Do you tell me I want to build something so that I can fire at the right time. And, you know, it's rockets you're dealing with, right? So I assume the users you're working with or your community you're representing are probably both important and full of cash and engineering know how to want to make this possible, right? And also you want to get that rocket to space. So you probably want to be able to deliver that value to your user at a prompt cadence, right? So maybe what we could do is ask, is that the right thing to get into Kubernetes? So if we go to the next slide, I think as a Kubernetes community, like our goal with engaging with you, John, is like, we want to make you successful. We don't want you to be bottlenecked on our API review process on the cat process on the production readiness process. If, like, that feature isn't broadly applicable to everyone who potentially could be consuming Kubernetes. Now I'm a little anxious that the use case you described might be very, you know, bespoke, but still important. But one thing to keep in mind is like when you're asking to make a change of that magnitude, like a new workload controller or a new fundamental capability. When we talk about the alpha beta stable progression, that takes time, right? That sometimes is measured in order of a year, maybe a little bit more because you're going through discrete loose periods. And so it's actually often better if you can fulfill your use case using one of the building blocks that Kubernetes already exposes without you need to get it into the core Kubernetes, right? As we said, distribution is better than centralization. I don't want you to be successful if and only if we bless your use case in the Kubernetes project. So to that concept, I would say one of the things in the Kubernetes community we've done is listen closely for where new extensions are needed. So let's maybe if we go to the next slide, we can talk through your example, right? So like you have a new API design, you have a new model, it sounds like a variant on jobs. Have you looked at CRDs? Are you familiar with that concept and what they would provide? No, tell me more about that. I don't know. All I heard is Kubernetes is really great and really solid, and I want to make sure that it can do what I need it to do. So like we have a lot of built-in APIs in Kubernetes that you're probably familiar with things like pods and the job thing you were looking at. But like there's a scope to what we offer within the community and then an ability for you to kind of write that new thing yourself, right? So one of the capabilities that was added was these things called custom resource definitions, right? So you can define a schema for your new job type and you can tell that to Kubernetes, this is my schema, and then you can produce instances of that object and write controllers against that. So if you want to use Kubernetes as a platform to build controllers over an arbitrary data model and you want it to follow the Kubernetes design principles, I think I would encourage you to look at custom resource definitions and experiment outside of Kubernetes first. So you're saying I could build something that works almost just like a built-in type with like almost just like current job, but I wouldn't have to modify Kubernetes itself? Yes, and you could be very successful for you and your users without being necessarily gate-kept by the project overall pacing community. And there's some other things like you talk about you want to be able to operate those things, right? So there's nothing, you probably want to use the CLI to like figure out what's going on with this object, right? Like you call it gate-kept pods and you know your thing's running. So one of the things that we've done is you can now, you know, using that custom resource definition kind of advertise how it gets displayed in the CLI user experience. So like if there's particular attributes you want to show about when that rocket needs to launch or when that job needs to run, I think you can make your users very happy and your operators very happy by exploring that. Now, I don't think there's anything particular about your use case that requires custom scheduling. I'm not afraid to ask in too much detail, but I would say like if we stop poking on John's custom example, there's a lot of other areas within Kubernetes that people can extend and enrich without needing to get their code base into the core of Kubernetes itself. And I think as a project community, we spend a lot of time trying to ensure that those can be successful building on top of us or around us. And that we recognize there might be exit points where not everything has been defined. But if John had an alternative example where he could identify a particular use case or nuance that's probably applicable that would empower him to do something else. I would say coming to SIG architecture to talking through your initial challenge or thought is is is a good thing. But our first reaction will be to try to ask if we have the right tools and mechanisms in place to enable you to be successful by building on top of rather than within Kubernetes. So thanks John for for placating there. Yep, go ahead John. So then the question that is where do we go from here. So really, the entire community has been focused on these extensions that Derek was just talking about, we really want to make sure that we have the right extension points. And so there's a big focus on that continues to be and that those extension points work as much as possible, like built in types. We also were continuing to build out coverage and conformance. And we're trying to improve the quality of the dot zero release. And we're sort of trying to improve the overall flow of features through this system so we have something that was recently added where things need to go to GA at some point we've had too many things that linger in beta for years, and that that's a problem for us. So, these are the main things we're looking at, as well as you know ensuring the project continues to scale, and we also make sure that that that kept process. So, how can you participate in this. Well, as Derek mentioned, come to our meetings we have a community meeting every other week. That's for the general signature architecture and then most of projects also have a meeting every other week. The schedules are there on the community schedule, and we are really eager to have you come and join us and help us. Thank you very much. All right, well thank you. And hopefully we're here to answer questions live now. So, thanks again.