 My name's Joe Bita. I'm the CTO and co-founder of Heptio. If you were at the morning keynotes, you saw my my other co-founder Craig Give a little bit of the business case of where he sees Kubernetes going I'm gonna dig into some of the details on what can we do? How can we approach making Kubernetes a more usable system and I'm also one of the folks along with Craig that that started Kubernetes back at Google three years ago All right, so why do I care? Why do I want to make Kubernetes more usable? It turns out that there's this trap in open-source communities where If the product is hard to use that's a great opportunities for vendors I'm you know, I have a company. I want to sell some stuff. I like money exchange goods and services for monetary, you know gain, right? So Kubernetes being hard to use to some degree creates opportunities for me But I think my my view of it goes beyond that one of the special things I think about the Kubernetes community is that there's this idea of project first a lot of people believe in making the project itself great regardless of where folks work and that's something that I think is really special and I want to make sure that it continues to be that way and So making Kubernetes easy is a critical thing for us to grow the community And if we can't keep the community growing and vibrant, it's gonna wither and die All right, so six months ago ish at Kubecon EU I got up on stage and I said that Kubernetes sucks and But I also put it in the context of all software sucks But this really ruffled a lot of feathers for folks on folks It really caught people by surprise and I don't really mean that Kubernetes sucks What I mean though is that not everybody loves it necessarily as much as I do as much as the folks Folks who have been putting their heart and soul into it and we really need to take a cold hard look to really understand Where are the places where we're falling short? You have to take a sober look at something to really improve it and and that's some of what I want to do Here and that's some of what I was trying to get at when I talked about all software sucking and Kubernetes being software We can't believe our own hype It's really easy to sort of get up on stage 4,000 people pat ourselves on the back. That's great We should celebrate how far our community has come But we also have to be very sober about how far we have to go yet. I started my career at Microsoft I was at Microsoft for seven and a half years. I Lived through the Longhorn days So I don't know does anybody in the audience know what Longhorn was do you remember this right? So it's not Texas. It's a bar between Whistler and Blackcomb and In Classic software development style. There was a release of Windows called Whistler and then the next one was Blackhorn home Blackcomb and then there's a there's a bar between them up in Whistler called the Longhorn And there's supposed to be a quick pit stop on the final destination. Well, you know like a lot of folks Microsoft got stuck in that bar and and Longhorn turned into a Windows Vista and The psychology of being inside of a company like that where you think everything's going great There's a lot of good people doing good work that went into that But the end result was something that was was disappointing to the general public We can't fall into that trap and it's not just Microsoft that falls into that trap so many software companies really do and so many software projects do so one of the tools that we can bring to bear on this is this idea of UX personas, so this is a very common thing that we see in the sort of UI UX world and this is the idea that you segment your population you identify the different users and In the most extreme cases you start giving them names and identities and backstories and you get stock photos And you set a place for them at lunch and like they become your friends and It's a really useful tool because it helps you build empathy for the set of users that you may not otherwise relate to and that's great And so I want to apply that tool here. I also want to recognize that there's some caveats There's some warning signs and some things that we have to be careful of as we do this So the first thing is that these personas are fractal the more you start looking at the type of use case the more you realize that there's sub use cases underneath that and And you can really get lost in the weeds when you start doing that The next thing is that nobody is average, right? We can have this idea of the average person, but everybody is actually, you know in some ways outside of the norm There's actually a great 99% invisible podcast on this that talks about Air Force pilots and seating But that applies here also and so these personas are sort of some sort of platonic ideal of a user and Nobody fits into those things cleanly and nobody fits into those things cleanly all the time, right? So so depending on what job you have to do on a day-to-day basis You may find yourself shifting between these different types of personas So to sum this up view these personas as guidelines, but not guardrails We really want to make sure that that we build empathy with users We understand the different places that they're coming from but we don't want to build siloed experiences for these different personas All right, so here's my breakdown. Please excuse my bad handwriting of One way that I've been thinking about breaking down personas and there's two different axes that I've been looking at Operator versus developer cluster and services versus application And if we do that we end up with different types of users in each of those things and again This is an imperfect way to break this down There's ways to actually pick this apart but for me this has been a useful way to think about it now When you start looking at it in this case I think it starts to become obvious that sometimes these different needs for these different users conflict with each other Right, there are gonna be some users that want the super easy to use Press one button make it work type of thing, right? And then there's gonna be other users who really want to understand the details and they want the flexibility And they want to be able to adapt it to you know something that's very very different from what a lot of other users are doing and this is a Problem that faces any time you're building a product or a platform for a wide set of users And it's something that we struggle with in the Kubernetes community again and again There's no silver bullet here. It's hard So let's break down the breakdown a bit Cluster versus Service a cluster and service versus application in my mind the difference between these things is who is your customer when you're Building stuff and working on things that are at the cluster level your customer is other Developers other people who are actually software developers and one of the big traps here is that you think that those folks are always like you I'm a developer. You're a developer. Obviously. We understand each other well, our world is big enough now that that doesn't work and And then when we look at developers versus operators This again is a spectrum. I don't think there's any clean lines here I think you know the whole idea of DevOps is actually to get across that there are not clean lines here And you shouldn't create strong process and structure around that But the way I break this down is that on the operator end of the spectrum a lot of the value that's being delivered is not visible to users You're worried about stability. You're worried about uptime. It's only visible to users when you fail I think there's these you know famous idea that like when and when folks on that operator hat wearing that operator hat People only notice they're there when things go down application Folks are on the other side of the spectrum. I mean, I'm sorry Developer folks are on the other side of the spectrum. Those are people who are focused on very visible end user value Right features. I want to actually get this new thing out there I want to enable new types of scenarios and so these things are oftentimes attention and that's really at the core of Building better understanding Across these things when people talk about DevOps All right, so there's another overlay here. I think around security I'm not quite sure where it fits in this particular grid, but it's something that is very important It's a separate discipline. It needs to be bound into the rest of this Unfortunately, I don't have a ton of time to dig into that right now today But I don't want to present pretend that this represents all the different concerns that folks have all right, so Cluster and service ops So this has been so much of what we've been focused on up until now as a community How do I get a cluster up and running? it's It's been a distraction, honestly I think you know some of the stuff that we've been seen in the keynote so far At cube con has assumed that you have a cluster Nobody's spending a ton of time thinking about how do I get a cluster up and running now? That doesn't mean that we're done with this It just means that folks are starting to look past this particular role But I think we're not done because I think cluster is is getting kubernetes up and running But as we expand the ecosystem This role also includes all the different ways to manage clusters whether you're doing multi-tenancy or not and extend clusters with things like you know operators and controllers that you can provide added value So problems here there are still too many ways to install kubernetes This is obviously a huge pain point for folks things are getting better. We're starting to see More turnkey solutions. We're starting to see a little bit of consolidation But this is still incredibly intimidating for new folks to our community One of the things that we're doing here is that we're separating concerns between like provisioning and bootstrapping and management and Observability of the cluster itself starting to separate out those things means that we can start sharing more tools And that's a good thing I think This is a weakness for kubernetes, but it's also a strength and that seems a little bit counter-intuitive But when you compare kubernetes to the Linux kernel The Linux kernel is an amazing piece of technology. It runs on everything from a phone to an IBM mainframe That's actually really really cool It's it really pervades every part of computing and kubernetes You know follows on a little bit to that I think you know, it's not exactly the same but kubernetes can run as a dev ops tool across a couple of machines all the way up to you know Huge clusters that can cover large enterprises There's also ideas around can we run embedded kubernetes into a set of boxes where folks don't even know that kubernetes is there It's a hidden detail. So there's all sorts of places where kubernetes can play a role And that's reflected in the ways that people install and manage kubernetes One of the interesting sort of things that's happening with the community here are all the different ways to Manage and control kubernetes things like our back network policies quote a pod security policies taints and tolerations audit logs All that stuff and that's that's the expanding Set of things that folks who are managing clusters are thinking about now You know, obviously these are the folks that care about kubernetes being boring, right? Their job is reliability on the operations side you want boring, right? And so that message of kubernetes is boring really appeals to folks that are wearing this hat So things that we can do to actually make this better find commonalities, right? I think when we started the cube ADM project the goal there was to build a toolbox not necessarily an all-in-one experience and we're starting to see some uptake across the different installers as we Leverage that toolbox to reduce the amount of duplication and then as we build these pieces as kubernetes developers and members of the community Let's focus on not just individual features, but how all these features fit together. We're not doing a great job right now of telling that story All right, let's move on to the next one application operations The fact that cluster and service operations versus application operations are two separate things is actually one of those really Powerful concepts that fall out of both cloud and cloud native It's this idea that I don't have to worry about the whole stack I can offload that to somebody else whether it be my cloud provider or whether it be another team inside of my organization So with that in mind the main concerns of folks in the application ops Profile our persona are defining and deploying applications the application lifecycle Understanding how the app is running so app observability from cluster observability and then portability across Kubernetes Implementations again, this brings up the theme that Craig brought up in the keynote around conformance. It's a really important piece of the puzzle So the activities here include like packaging like Docker build This is the type of thing that sometimes hits the application ops side of the house How do you just describe what you're deploying the yaml? How do you automate it testing that thing and deploying it CI and CD How do you you know observe that and then how do you do this for both the application itself? And how the application interacts with the underlying platform Kubernetes And and so a lot of the stuff that folks have been talking about have been how do we actually find ways to simplify all of those things? But again, I don't you know, I don't think there's a one-size-fits-all solution Understanding that these separate concerns can sometimes be solved in a holistic way But sometimes need to be broken out is key to be able to hit all the different sub personas of this particular This particular scenario this is a super active area of innovation. I'm really excited with so much the work that's going on here I think, you know, there's helm. There's jsonnet and case on it the stuff that we've been working at at Heptio And I'm gonna give a demo a little bit later Kedge build the the deep-mind capitan stuff. That's all on the application description This crosses a whole bunch of sigs and Kubernetes sig apps sig CLI with all the cube controls stuff API machinery how do those tools interact with the API itself things like auto scaling because that's actually part of part of the experience for Applications and we're starting to form working groups like the application definition working group to try and address these things in a horizontal way So that's an exciting area of innovation. It's also very very confusing to users So one of the things we can do here to actually improve this is understand the sub personas What are the different ways if you're installing package software versus, you know building and deploying your own software? There's our two separate personas that actually come into play here and then Recognize that we're not going to come up with the one beautiful systems that that's actually going to solve everybody's needs in this thing So let's find ways to build reusable components so that folks can actually transition from one type of system to another Okay application developers so Writing apps in a kubernetes world is hard a No developer expects to go npm install npm start. That's their world. That's what they live and that's how they develop That's how they think Transitioning that to Docker build and cube control apply is a painful transition and the experience is very different I think one of the big things that we get with kubernetes and with Docker and containers in general is a really well-defined build step Where we create an artifact that we can test Not all languages not all developers really just understanding that you have this build step that creates an artifact It's actually a huge leap for a lot of developers and it doesn't work with their application flow So there's a lot of challenges ahead for us about how we actually start bridging that gap a lot of that bridging will have to be in a Language and environment specific way whether you're running a compiled language or an interpreted language whether you rely on logging or Debuggers to be able to actually understand what's going on in your application Each of those things brings different constraints and then as we start building out of microservices world What happens when the entire set of microservices that you want to address are no longer on your laptop? Right, that's a very hard problem now. How do I actually test how I validate? Do I mock everything do I create some network connections? Do I debug and actually run all my development workflow on the on the cloud in my inside my cluster? I don't think anybody's cracked that yet So there's a lot of work to be done there also The other part of this and I think this is something that we started to see hints of in in Brendan's sort of very forward-looking keynote last night I don't know if you all saw that was how do we get applications to start taking advantage of the special context of running Kubernetes? When you write a Linux application right now It talks to the syscall interface right Linux through through, you know, libc But when you're running on a cluster you have a whole new set of toys and tools that you can actually access Which is the kubernetes cluster itself? So how do we move applications so that they can start becoming kubernetes native we can do this and as sort of you know Let's move everything into that world or we can start doing it in a more incremental way So one example here is the latest versions of the JVM our container aware when they're running in a container They can realize how much RAM that container has By looking at the C groups hierarchy and automatically setting the heap size of the JVM That's a really nice integration it and it reduces the amount of configuration You need to to make sure that you have your application configured. Well but There's more we can do there Brendan brought up ideas around using standard mechanisms for doing locks Sharding right who are my peers so that I can create a circular hash and actually assign things correctly being able to Discover that is a primitive that folks can take on and and in the limit We start seeing this stuff become a blend of application development application ops as applications become Self-operable as they start managing themselves. So when you launch a map reduced job inside of Google What happens is you launch a controller and that controller itself goes ahead and talks to Borg Launches all of its workers does the computation Collects all the results and then returns it all so that thing is both the application itself and a controller all bundled into one And so we're going to see more and more of those things in the future So what can we do to help users here? We need to meet application developers where they are We have to start finding ways to bring them in the Kubernetes world in a soft way without making them reevaluate their life choices We need to create STK's right We need to find ways to make it easier to talk to Kubernetes without necessarily having to sync the like I don't know like terabyte that is Kubernetes slash Kubernetes, right? So we need to do better there There's progress being made, but but there's still a lot more to go All right, so the final thing here is the cluster and service developer So the canonical example of this are the folks that are part of the community building Kubernetes itself But that's not where this ends Kubernetes from the from the start was really thought of as an extensible system How can we turn Kubernetes to be a platform for building platforms? And so not only all the folks who are working on Kubernetes directly But those that are extending and integrating with Kubernetes in a way to provide wide value Those are folks that I would consider part of this persona This is an incredibly exciting place And I think we haven't seen anything yet in terms of the type of things that folks can build on top of Kubernetes So all the operators and controller stuff that we're talking about that all belongs in this bucket I'm particularly excited with the meta controller stuff that was demoed this morning I personally haven't had a chance to dig into that but it's been on my radar for a while And I think you know after cubecom I'm gonna go back and probably do that on one of my my YouTube streaming shows So Conformance is a big part of this here We want to make sure that when somebody builds an integration to the Kubernetes that integration can be leveraged as widely as possible We want to be able to create communities around Extending and building new capabilities on top of Kubernetes So we need to continue to double down on conformance not just from the application point of view But also from the folks extending Kubernetes So when I say extending Kubernetes, I think like There's a lot to take in but there's a lot to be done here There's like controllers the cloud providers CRDs aggregated API servers admission controllers and initializers There is extensibility around how you store secrets and then custom schedulers There's all sorts of interesting ways to extend Kubernetes All right, so call the action here. What can we do as a community to make this better? Well, we need to build extension points over extending Kubernetes and we've been doubling down on this This is really painful because a lot of folks come to the Kubernetes community and they're like, hey I just want to extend it in this way. Can I check in code? We say no We really like we should build an extension point before we do that because we don't want to put more stuff into the Nucleus or the core they're like, well, but look at this other code. It already did it I'm like, yeah, but like that was a mistake. We should try and get that out But it's unfair they got to do it and I don't get to do it It's a really painful conversation to be able to do this stuff because there's a lot of Community dynamics that come into play We need better documentation around API's. We need better examples We need better clients that are easier to use Anybody who's tried to use client go has felt the pain of the fact that there's no documentation On how to use the thing itself Installing it is very very difficult the compatibility matrix across clusters is is really difficult to understand and the exam Examples out there are are scattered everywhere and sometimes conflict with each other So again this points to an SDK. This is an SDK really at sort of like a kernel level SDK versus a sort of user mode SDK To draw that sort of Linux kernel extension example So with that in mind, I want to start talking about a project that we've been working at at Heptio called case on it This is an open-source project. We really you know, we've been driving it But I would love more folks to get involved You can go to case on it.io if you want to check out more so this is based on some of the experiences of How workloads are managed on top of board and just fair warning those experiences are controversial, right? There is no agreed-upon way to solve this problem And so even inside of Google the way that Google has like probably two or three systems to actually solve this problem So so I don't think anybody has found the right way to do this much like programming languages or make systems or Apparently according to Bitcoin this morning money So It's like 20,000. I'm not an investor. I'm glad I stayed away so so this is aimed at that application operations persona and The reason why we did this and let me tell you a story so new users come in they read a tutorial They call cube control run and they're like hey, this is pretty easy. What's the big deal about Kubernetes? I use GKE. I brought up a cluster. I ran cube control run. I'm up and running in five minutes, right? that's awesome and Then a little bit later. They realize that that is a dead end right because they want to be able to manage this stuff in a responsible manner and So now or they want to get access to some of the more advanced features that aren't exposed through that very limited sort of Keyhole that is cube control run and then all of a sudden it's like here's YAML And they're like oh now I understand why everybody says it's so complicated. It's like you know throwing a book at their face it's very very difficult that transition and and not only that a lot of the work and a lot of the learning that they've done for Qt control run is very difficult to actually translate into that YAML world and Generally what they do is they're like I'm gonna copy and paste some stuff from the docs And I'm gonna like poke at it until I can do a Qt control apply or create and I don't get an error I like oh I indented this thing the wrong amount of space, right? So it's a lot of trial and error not everybody goes and looks at the schema for these things It's mostly based on examples a quick poll. How many folks have actually gone and found the API Documentation so that they can figure out what to put in their YAML is it okay? I do you think it's enough do you think that API documentation is good enough for writing YAML? No, okay, that's one place where we need to do better now so so the idea here is that I think folks once they start getting Kubernetes this idea of And it's kind of I roll here, but get ops, right? I want to take the the source of truth of what I should be running and move it from my cluster into something that actually You know integrates with the rest of my tool chain. That's a great idea We haven't provided great tools to be able to do there and YAML is really an assembly level primitive when we need higher level Languages and so that's really where case on it comes in and so now I'm going to try and do a demo here and Unfortunately, I Can't see the screen here, and so I'm really glad that I'm using this like auto typing thing here Can you all see that? Yeah, I was really typing quietly there. Did you see that? Is it big should I make it bigger? Yeah, okay here. Hopefully I won't break stuff. Oh, there we go Okay, well you can see all of the stuff that I've done before there, okay So one of the things is that we can install this with brew if you're running on the Mac Otherwise, there's other ways to do it. I'm not actually installing it here cuz cuz Wi-Fi in a in a in a conference But and this cable is not working So let's cross our fingers and then the first thing we do is we actually do a chaos a knit and you name your application And this is going to create a directory structure for you So we can CDN to that and so some of our inspiration here. Oh, is there there looks like there's more there than should be there I might be left over from an old. Oh shoot, oh Man, all right. Well The demo will still work But now you're seeing a preview of what's coming But the idea here is that we are inspired in some ways by things like static site generators and ruby on rails Right, it's this idea that having a well-known directory structure where you can drop in some files Is a good way to eliminate some of the sort of fiddly configuration that you have to do and so that's one of the things that inspires This is not ruby specific if we're inspired by the pattern there just to be clear All right, so what we can do here. Let's see. Is this going to give us an error in May? Is that we can go through and we can do a chaos generate? And Okay, so that ended up being a no op there should be some output there But this is the this is half of Cube control run. This is creating the definition of what we want to run We're specifying the image and we're saying that we want to expose it because it's an exposed service And we want to expose it with with a node port So half of cube control run, that's great. Actually, you know what we're gonna start this over man I'm gonna do a little a little bit of surgery here. I have another terminal window. Maybe I Apologize guys. There we go There we go I'm still really good at typing this stuff. All right, there we go. Okay much less there because we haven't gone ahead Okay, so now I can go through and I do the chaos generate and that's gonna actually that's half of cube control run it's just creating some files on local disk and Then the next thing we can do is we can do a chaos apply and we're applying it to an environment That's a target cluster plus namespace and these are all things that you can check in to get and you can track And you can do code reviews all that good stuff applies here also and then I can see that I'm actually really running the thing so I can go through and See I can do a cube control get on this and then if I go through and Click on this link again. I can't see the screen. Well, so let's see. Oh, man. I brought it up in the wrong window Let's uh, okay, so let's oh, man Okay, there we go. We have a guest book here I can be like hello cube con and I probably miss type stuff because I can't see but whatever and it's not saving because we Don't have a database yet. All right, so this is a little front end So our apps not complete so let's go ahead and go back and create our database. Sorry. I've turned away from the mic too here So now what we can go through is we can look at the prototypes that we have and prototypes are those things that generate uses So you generate you use a prototype to run generate it produces a component a component as a set of Kubernetes resources that work together And we can see the the deployed service here that we have now We could go through and create a Redis database here Which is what we're looking to do by starting with the deployed service and then Picking the right Redis thing and setting the right options and you can go and edit files to start doing that stuff But one of the things we wanted to do is reduce the amount of copy and paste that users did as they did stuff like this and so we can actually go through and we can look at packages and I can install a package and Then I'm glad the network is working and then when I look at prototypes you can see I have more options here And so I have three different Redis options I have one that's totally stateless one that uses a PV and then one that comes with the full meal deal We're gonna use the stateless one and I can find a little bit more about it by doing a KS prototype describe and You can see that there's some parameters here. This one's pretty simple I'm gonna go ahead and generate from that and this is gonna create a new component and And then those params that's really interesting that I have parameters One of the things we can do is we can go ahead and we can edit those parameters after we do the generate And you can add your noon parameters as you go through this stuff So I can actually list the set of parameters I have here and let's go back and upgrade to the new version of the guest book because we made it fancier And so I can do that with a simple one line parameter set To 0.2 now I can do this across environment so I can say I want to use one type of image for my production environment I can use another type of image for my staging that type of thing I'm not gonna be demoing the multi-environment stuff right here right now But these parameters can be specialized depending on where you're targeting your deployment and Now I can go through and I can apply that and this will both in one step update my Deployment to a new version of the guest book and deploy the Redis database So with that I get another link that I can click on if I can find the mouse. Where is it? Where'd it go? Oh? There we go, okay And let's cross our fingers and hope this comes up on the right window. Oh, yes. Look. It's a very fancy guest book We made it really nice It's fabulous Hello And I have to click the button Yes, and you can see it's actually saving it now. This is running on mini cube on my on my laptop So you all can't hack me. That's that's my that's my approach All right, so that's all great And so you can you can iterate your components you can check this in you can test it You can share it with other folks and this really provides a much smoother experience from that sort of like here's what I want To do declarative model, but also in a way that I'll grow with you as your application deployment gets more complicated and More real All right, so there that's case on it That's not the last word in how we're gonna do that I think you know we Have some really good ideas on on where we want to take that but we don't have a monopoly on all the good ideas So we would love for more folks to get in To get involved there So the big thing I want to end up here is that we're still just getting started with Kubernetes, right? We're still in the opening acts if we're successful as we build this community The interesting thing is not the community the Kubernetes itself, but the stuff that we build on top of it But the stuff that we were doing before which is building stuff that would work for For folks who've been at Google for a long time or folks who are already sort of familiar with these cloud native ideas That's not going to get us to where we need to go to really really Get the Ubiquity that I think everybody can imagine Kubernetes having we need to start thinking outside of our own experiences And really take the time to understand how other users are viewing and approaching what we're doing here with With Kubernetes and the larger community so with that I have just a few minutes I was running a little late because of the demo snafus for any questions if folks want to come up to the microphones We can probably take a few minutes Yeah, Mike I can repeat it if you're if you weren't right up there, right? So so it's a good question the question is how did the guestbook actually find and authenticate to the Redis instance? So there's a couple things going on there Number one is that the guestbook was hard-coded for Redis using a Kubernetes service discovery So that's how it found it and that Redis database is running without a password the the bit Nami folks who are also been involved with us with with Case on it a little bit and have been early users and early advisors on this stuff They have this project called sealed secrets Which I think is something that we're going to be looking to integrate with this workflow also so that we can provide a really great way to bridge that gap with secrets you could also go through and Have these things be able to draw it from pre-existing secrets that are managed out of band Yeah question up here So the question is how does case on it relate to helm and I'm over time This is the last question, but you can find me later at the Heptio booth if you want to if you want to ask more about case on it so It's a really interesting question. I think Helm in my mind when we start looking at the sub personas around application operators is great for taking widely You know community generated widely shared applications and being able to install those right? and One of the places where helm starts to struggle is when you have a large degree of Configure it for configurability if you look at the engine X ingress controller and helm it has like three pages worth of parameters Right, so that's one of the things that we wanted to start looking at here Is that can we actually parameterize the common things? But then also give you easy access to the definitions underneath when you want to actually customize less common things in the limit what I would like to see is Case on it be a great way to author helm charts and then have helm be a great way to deploy those things because authoring helm charts right now Is not for the faint of heart? It's going to take a while to get there helm three planning starts in February We're going to be looking at that very carefully and then development starts after that So it's going to be quite a while before we can actually see the integration or the possibility of integration that we'd like So with that, thank you very much everybody. I appreciate you taking the time Come find us at the Heptio booth if you want to learn more