Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2018 (Seattle), 15 Dec 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: CRDs Aren't Just for Add-Ons Anymore - Painting a Picture of the Future - Tim Hockin

Description

Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io

Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects

Lightning Talk: CRDs Aren't Just for Add-Ons Anymore - Painting a Picture of the Future - Tim Hockin, Google

Kubernetes has a huge contributor community. There is a steady flow of new ideas for things Kubernetes could or should do, and those almost always change the API in some way. We already have a broad API - we can't grow the scope forever.This talk will lay out a vision for how our thinking is evolving around API definitions and growth. The API machinery is evolving and becoming more general-purpose. We can use that to our advantage, enabling more modular and consistently defined APIs. Put another way: "I heard a rumor that all new APIs have to be CRDs, is that true?" Let's chat.

To learn more: https://sched.co/GrUp

A

I've only got five minutes: hi everybody. My name is Tim I'm here to talk a little bit about the evolution of what we call our API machinery within communities. Everybody please note. This talk is very forward-looking. I'm gonna say things that sound insane they're, not true. They will be true. Eventually, everybody knows what a TPR is. Yes, right: okay, good, third party resources.

A

Once upon a time there was an idea that kubernetes would grow and was going to grow a whole bunch of new features and we needed a way for people to prototype those new features. So we built Brendan burns and a bunch of other people built this idea of third-party resources.

A

You can plug in a new API type into kubernetes and it was really super crappy, but it was good enough and it lets you capture the kubernetes api style, build your thing like you would build a communities API and then prototype proved that your idea was actually worth doing. It's very limited, though there was no schemas, there was no validation, there's no defaulting, it was really second class, but it gave birth to the operator pattern. Everybody's heard about operators right, it's sort of the thing, so people started creating really interesting operators.

A

Operators is it's a software robot that runs in a communities cluster that manages something. Usually it's a stateful application, but it could be anything. People started to use it for really interesting and clever things. They were managing external systems. They were linking up to other applications driven by declarative. Api is just like kubernetes actuated asynchronously by controllers, just like kubernetes. It was a really powerful pattern, so they became a little bit more native.

A

We decided we're gonna, we're gonna, take this idea of TP RS, which eventually became CR, DS custom, resource definitions and we're gonna make them a little bit more native, and so we added this concept of admission control, admission control, memes on the way into the system. I'm gonna do something to you: I mean they're, gonna, say no you're not allowed to be here because something's invalid or I'm gonna change you in some I'm gonna apply some defaults. So we added webhook admission controllers.

A

Now you could add admission control to your own custom resource definition, so you could do validation. You could do defaulting and you could do it without fiddling kubernetes. You didn't need to change a single line of code, Randy's code to produce a resource that sort of feels like a built-in kubernetes type, and now we have schemas, so you can define schemas through open API and if you have sort of declarative validation. So you can say this field is an integer and it must be greater than X and less than Y those sorts of things right.

A

This covers the vast majority of what people need to do with custom resources. So how do custom resources fit into kubernetes, mostly they're, being used for out of tree things? Operators add-ons stateful, orchestration people. You know you want to create your my sequels or domain-specific api's anybody heard of AST. Oh it's entirely written in C, our DS. It usually provides a higher level of abstraction. Now their system is called K native. It's a serverless framework built on top of communities.

A

More recently, though, we've been using them for entry. First party, things, storage, snapshots, a pretty cool idea. It's built entirely on C RDS, even though it links up with the rest of the community system through persistent volumes. Runtime classes is a new way to describe how your machines are being managed. This is all defined through CR, DS CSI. The container storage interface is again linked deeply into the system, but it's defined in custom resources, and you can expect to see more of this.

A

This is the direction that we're setting for the project through cig architecture that all new ideas are coming in as custom resources. The gold here is custom. Resources are not second-class anymore, so let me paint you the vision here we go. It built all the way up to this all new C. All new api's should be CR DS unless they can't be and there's a couple of reasons they can't be, but for the most part, all new api is our CR DS.

A

Eventually, everything is a CR D I want to take all the bits that are built into communities today, pods services deployments, replicas sets and I want them all to be kicked out. I want them all to be custom resources I want the API server to be this generic box that you load type sets into, and then anybody can use the kubernetes api machinery to serve any kubernetes tile api that they want. Their call is the kubernetes resource model. It's super powerful.

A

It's really attractive way to build cloud native declarative, API is now in truth, CRD is not quite there yet we're not able to handle some of the crazy, weird crap that pods throw at us, but we're working on it and you know. In truth, we may need to simplify some of what we're doing with these. The built in kubernetes api is but we're working on it. There should be nothing literally, nothing that we Cobra Nettie's can do that. The average consumer of the kubernetes api machinery can't do it should be a totally equal playing field.

A

You can see here we're gonna load, the type sets into the API server. This is all work in progress. I said this was forward-looking. We're adding stuff like versioning sub resources, better validation. This is becoming a project of its own entirely and I've done right on time.