 All right, next up we've got Phyllis is gonna give us an update on container D All right good to see everybody Who's heard of container D? All right, so I'm not gonna spend a whole lot of time on Deep dive of the architecture. There's lots of great talks on that that you can find Most recently Kubecon Seattle we did both an intro and a deep dive where we had more time But in 20 minutes, I'm just gonna kind of give you an update on the past year I spoke in this room last year container D was a bit younger than we just Reached our 1.0 a few months before that so I'm gonna kind of start there and and let you know What's happened in the past year a Little bit of overview. I just threw a few slides in here from our Graduation proposal to the CNCF just because it happened to be a good collection of information So sounds like again most of you have heard of container D again the reason it sort of came to life related to this idea of Just a Intentions around what docker was becoming Kubernetes gaining popularity and an outcry of hey, we just want a boring container runtime that can be this sort of level playing field on which Docker can build its its Projects and products the Kubernetes community can have this sort of core container runtime that moves at a slower pace And has well supported releases. So that was kind of the basis on which container D came to life And really the key tenants are that we've focused on Since we created the project is reliability and stability. So strong guarantees about the API about its life You know EOL dates how long things are supported a Very clear and stable client API and so I think up on the screen those tweets are way too small to read I'll post all this online After the talk, but these are people saying hey the API is great It's so easy to build on top of container D And we'll look at how that's grown in the past year to not just being used by Docker and Kubernetes But others are finding that API attractive and using container D as a runtime in their own Personal projects or even larger projects And then performance again is another key focus area that we've had The community has grown quite a bit in the past year This graph again way too small for you to take too many meaningful things from it although it's straight from the CNCF dashboard so at any time you can go to the dev stats Website on the CNCF and dig into any project and all the statistics We can see at some point when we joined CNCF. It's interesting to note a Broad array of new contributors showed up and a lot more activity across a lot more companies We currently have 12 maintainers representing eight different companies and we also have a class of Project maintainers we call reviewers who can LGTM and that even adds more companies who are involved in the building of container D Again, I just mentioned that usage again that initial Kind of proposal for container D was let's have this stable boring container runtime that Docker can build on that Kubernetes can build on But since then we've definitely seen a huge increase in the number of adopters of Projects that are using container D and I'll come around Toward the end of the talk and talk about a few of these And show this list again As I mentioned that those Slides we just looked at came from the graduation proposal the CNCF has levels of maturity and Kubernetes has graduated and a few others core core DNS. I believe You can find that on the CNCF website, but at the moment we Proposed to graduate last November. I think is when we open this PR You can read there again the URL is at the top and I'll post this Set of slides as well so you can follow through to the links Effectively we presented this to the CNCF late in the year Then there was kubcon and a TOC election. So we're just now getting back on the docket to to graduate That may or may not be important to some of you, but at least this document collects up the requirements for graduation and you can see some things that we've done in the last year to Approach Project health maturity of the code base security audit all those things are referenced in here and maybe of interest To some of you. I'll skip this first one because that's history prior to last FOSDOM This picks up here. We had just done one oh Late 2017 so last year at FOSDOM. We were a few months into that and then a few months after FOSDOM We released our 1.1 release That's around the time that the CRI implementation so again the plug-in that implements the Kubernetes CRI interface Was a separate project and I think I may have said In the containers dev room last year that the CRI project was going to merge into our Same github repo that did happen and now the CRI and Container D core itself are developed by the same group of people The maintainers for the CRI plug-in are also maintainers and container D and vice versa So we've been working together now for just about a year and Then container D 1.2 was released in October again just about three months ago The runtime shim API stabilized and that's now being used by Cata and firecracker as was mentioned in a prior talk here today Again, we've continued to focus on stability and also extensibility which we'll look at in the architecture So I don't remember where we were a year ago with both IBM cloud and and Google's Google clouds manage Kubernetes offering But now both of us both IBM cloud and GKE have adopted container D as the runtime underneath our Kubernetes offerings and so again, you can go to GKE and Start to create a cluster and you can select container D as the runtime For IBM cloud if you create Kubernetes 1.12 or now 1.13 clusters You automatically get container D as a runtime. I just mentioned for graduation the security audit so the CNCF pays for a third-party security company to do audits of your code base and your project and So that work completed in December and so that's now published on our github repo and on our website And that's actually a really well done report on the code quality and security posture of container D And I already talked about the graduation criteria The interesting thing that I wanted to mention that I said earlier is that we're seeing use cases Not just in these sort of traditional Docker and Kubernetes models, but we're in discussions with CERN about use of container D in the HPC space and we'll see why that may be interesting when we look at the plug-in model that We've matured in the last year You've already heard about firecracker if you were in the room earlier That rust based VMM has an integration with container D as well And again a lot of that coming out of focusing on a pluggable design and having a clean use of JPI So this is The architecture. I'm gonna again. I'm not doing a deep dive here today in 20 minutes because I really couldn't Do that in a feasible way, but we'll look at some highlights and like I said, it's Very easy to go out to YouTube and find the talks from Kubcon Seattle The deep dive talk especially digging into the the architecture But effectively there's a set of gRPC services that are organized around Containers images and namespaces and the metadata around that And that those services sit over top of a runtime manager, which gives us the pluggability to not just use Run-C But run HCS so we have full Windows support now That Microsoft has provided through their OCI implementation Cata containers has a shim again You can actually with the cata integration of firecracker. You can use their shim to either drive their QMU KVM based Lightway virtualization or you can now use it after the PR merged in December To drive firecracker from the cata shim and again, that's pluggable and other shims can show up there as well and then snapshotters are the interface to file systems like overlay So traditionally in docker you think of graph drivers Snapshotters are a simpler interface that can also be extended and that's where CERN is interested in having a snapshotter that understands their highly distributed file system So focus on a few few areas here the next few slides The go API that I talked about the client library Is being used by docker of course by our CTR tool our client tool by alababa's pouch container project And other projects as well This is the area where you know people have been very happy with the design Of this API it's clean. It's easy to use and it it simply operates around the OCI specifications So give me an OCI config and a bundle and container D can create and start containers It also handles push-pull so it obviously can talk to registries And actually is extensible If you want to do more interesting things than the standard Docker v2 and which is now becoming the OCI distribution spec Again that sits over top of the actual gRPC API if you wanted to use a specific service of container D Without using container D as a whole then you can go straight to the gRPC API and have low-level access To components or some interesting projects that we highlight that people have built just using the services themselves It also has built-in metrics support exposed through Prometheus. You can turn that on in your config And then I mentioned the CRI plug-in. So this is obviously how Kubernetes support is provided through container D The plug-in now obviously uses that same go client So it's the CRI plug-in is written and go and becomes a client of container D to handle the CRI API calls And in fact uses the same listener Unix sockets and Kubelet talks to the CRI Says create me a sandbox create me a container and the CRI plug-in obviously uses a container D Go API to to actually do that work in container D So CRI is just one of many plugins again the the Design is pluggable CRI is one type of plug-in It's built in by default. So if you download a container D release You automatically have the CRI plug-in and part of that is why we merge the repositories Snapshot or plugins like I said, there's going to be built-ins like overlay butterfs a ufs But now we actually in version one two of container D We support custom plugins and so you can actually have Your own snapshot or your own custom file system. This is what we're working on with CERN And this allows you to to basically not even build yourself into the container D code base But have container D call your plug-in to do the Snapshot or operations And I believe we actually have an example of that in the code base So if you want to see what it looks like to use an external snapshot or Derek McGowan one of our maintainers actually wrote a simple one And I think the deep dive talk actually covers that in detail. I Mentioned runtime plug-ins. So again, this is where you can use Custom shims for other runtimes other than Run-C Obviously the most common use case is VM based runtimes like kata or firecracker But it's also used by the Windows team to support Calling out to their Windows shim To support Windows containers The interesting thing is we actually have a client Install command that works with images so you could create a container image Put your runtime plug-in In that image as a single file and you CTR install get it installed into your container D Installation and then begin using it and I think Darren Shepard from Rancher said this is an amazing feature that now he can basically package his whole project Use container D to install it and run it without creating any other packaging So again the whole idea here was to have Extensibility so anything you need to do that container D hasn't provided for you These are all interfaces that you can implement yourself. I already mentioned The resolver interface say you have a special custom registry or some other way that you want to interact With container images you can implement that And then again the server side also has the plug-in Architecture where you can register and then have your own plug-ins and have direct access to the rest of the container D services I Mentioned I would come back around To adoption Obviously I think most of Let's see what we haven't talked through I mentioned both cloud so GKE and IBM cloud Kubernetes service Both using container D today Docker obviously has been using container D for a while. I think the important point here is that Docker has been using the runtime side of container D for a number of years now but the image So you can think of the Docker code base having a set of features that now container D has and so there'll be a set of refactoring of the Docker code base Probably mostly this year to start using more of container D services and removing that code from Docker And so you'll see an increase of the use of container D From the Docker engine going forward Linux kit uses container D as its runtime within the immutable images you build I mentioned rancher's Rio project from Darren Shepard We've talked about Kata and their shim and firecracker as well Bolina is a a mobi project Subset, so that's just the the Docker engine side for IOT Cloud Foundry has been using run C. So they they basically wrote wrappers around the OCI run C for their container runtime and now the Cloud Foundry Garden project is actually using container D and moving from run C which allows them to get rid of some of their code That was doing some of the image interactions and root file system creation they can now leave that up to container D And then of course if you've ever followed Kelsey high towers kubernetes the hard way That also uses container D as the Kubernetes runtime A few other notes on integrations We already talked about the CRI being part of the container D project now Yeah, so Derek actually put here that in 2019 docker should switch to actually use the container D image back end Again, it's been using the runtime side of container D for a number of years already Who's heard of build kit? Just a few so very interesting open source project Coming from uh, tannis at at docker Docker build has been a feature of The docker engine for for obviously forever But build kit is basically that build concept Separated out into its own project and it's possible to use build kit standalone It can drive run C and it can also drive container D and so Very recent versions of docker engine are now importing build kit And it has a set of features that I don't have time to go into Very high performing and a lot of interesting use cases with build kit And so again, that's a that's an integration with container D as well I mentioned alibaba cloud from china We have maintainers and reviewers From alibaba working on container D and they're using it very broadly within their cloud You can look at their open source pouch container project For more detail on how they're using container D I mentioned cloud foundry cata firecracker And then a few personal projects. Michael Crosby One of our core maintainers has a boss project, which is a great example of how to drive container D From another go program And then evan hazelett has something that built around that called stellar that does multi node clustering using container D At the beginning I talked a little bit about our cncf maturity That our security review Was completed in december and that's now published and I already talked about the proposal And that we expect that graduation review Sometime this year So that's kind of a whirlwind tour through I wanted to save a few minutes at the end. I think I think we still have a How much time do we have One minute who has a very important question that will take one minute or less Or did I answer all okay, we have We've got one question up here in the middle stuff on where right here Uh, what's about creo that is developed also by red hat and why do you compete with yourself? Uh, that is not a question we can answer in one minute. Um But uh, I'm happy to talk about that dong su was in here earlier and mentioned creo Um, my company happens to be purchasing red hat. So we're going to figure that out this year. Um But uh, yeah, I There's many things that go into that, but yep All right, I think we're totally out of time All right, good play. Thank you