KEDA: Event Driven and Serverless Containers in Kubernetes - Jeff Hollan, Microsoft

perfect thank you so much Wow I haven't done anything yet wait to clap until I actually do something now thank you all very much we're gonna try to make this really fun I'm honestly thrilled and very humbled to be here today this is my first ever cube con I've been a Youtube attendee for the last few years it's it's been an incredible week so hopefully I'll be able to share some stuff here that you'll be able to take away but also one of the things that I really love about cube con in this community is that I also want to open this up to a dialog and whether it happens in this room or after the fact at the booth on Twitter and community stand-ups is we're kind of moving this world of serverless and kubernetes forward so as just mentioned I'm Jeff Holland we'll have a fun session today in fact I was well I switch to this first slide I was gonna make this entirely Star Wars themed and have like gifts all over the place from Star Wars stuff and I had all the jokes written but then earlier this week as I was going through the deck has like I don't know how someone from Disney is gonna be here or they're gonna catch wind and I do not want to get sued by Disney so just use your imagination and I still snuck some in at the end I've got a fun demo that will tie it back to Star Wars which I'm very in the mood for right now okay so to start with serverless means a lot of things and it means nothing because marketing but for now just focusing on how I think about service to set the context regardless of Technology in my mind serverless is really about enabling developers IT admins really anyone dealing with code to be able to focus primarily on just their application logic and all the other pieces that you're usually thinking about when shipping an application you don't have to worry about anymore they're taking care by the platform by tools behind the scenes to enable you to be faster and more efficient now service has a lot of attributes this isn't a requirements list there's a whole spectrum some things are service and they have some of these but a few of the qualities are things like event-driven something triggers an event it triggers your code to say hey something's happened here to run and as part of that event-driven it means that that compute will be made available on demand as well so hey an event happen that I need to run this code for let's make sure that we have computable just-in-time for that event and there's often this aspect of paper use and again this can vary there's an entire spectrum sometimes paper use is like running an AWS lambda or the Azure function service and you literally only pay when your code is actually executing but paper use might also just mean that because you're doing event-driven and on-demand computing that you're scaling your resources only when you need them and so you're able to more efficiently use your underlying compute so with this in mind as your functions has been around for a while I've been on the Azure functions team and working in service yeah sure for about five years now we see it used all over the place for a bunch of different things in fact I was just looking over the last just the last three weeks there's been over a quarter of a trillion executions that happened around as your functions so we have a bunch of stuff that make up those executions often where people get started our simple automation type tasks a pull request gets open can you add this label can you add these checks a 5 o'clock p.m. can you shut down these machines or run an update can you post a slack when it's lunchtime and ask for a vote on where we want to go for lunch really good way to get started I often call automation and serve a list like the gateway drug but often it grows from there and people can start to use them for other things glue is another very common place to see serverless containers and functions used I've got over here I've got sequel over there they need to be able to talk better to each other maybe I can glue them together with some serverless rapid api's I think about how Netflix is documented how they're using service Tekken's to service methodologies where they have front-end developers writing the UI for Netflix who need to be able to fetch fetch data from back-end services and rather than having to spin up a full micro service to fetch that data from they empower their developers to just write little functions they go grab the data that they need and return it back to the UI so these very rapid API is for mobile apps web apps you name it are a big one and then as things kind of grow up kind of the bigger ones that we see are really around event streaming and cue processing billions of messages funneling through queues and streams and kafka processing and ricci transforming the data making insights and analysis full suites that are made up of hundreds of functions with data's being passed around all with those service principles I talked about before actually a good example of this is Best Buy they gave a talk at the spring one conference that honestly I'd recommend checking out if you're interested about how they're using server lists and other tools to build a modern retail experience so they have a few cool stuff here one is that they do a lot of processing on premises at regional data centers they're using things like kubernetes you can see open shift here and at some point some of that data is gonna make its way to a cloud they're using a Kafka like service in Azure called event hubs they're processing those Kafka events those little lightning bolts that you see those are functions so they're using some service functions here to be able to scale rapidly transform the data put it into the right databases and power things like the bestbuy.com experience and Best Buy had a lot of requirements right one of them is hey we're gonna have things like Black Friday we need to make sure that our compute can scale rapidly at midnight or whenever Black Friday is earlier every year it's probably like 8 o'clock in the morning on Thanksgiving now but at 8 o'clock in the morning on Thanksgiving they need to be able to scale rapidly they also had some other requirements they knew Kafka they loved Kafka they're like hey if and if an exception happens if something goes wrong we want to be able to know that we have control to say you know what don't checkpoint the stream we need to retry these messages and the last one which is an important one we'll get to it later in the presentation ordering was super important it very much mattered if the item was purchased item was cancelled shipment was created what order those events get processed was very important to them they were able to build this they say in a matter of weeks where traditionally it would take them months that's a quote from their presentation again at that spring one conference which is kind of a good example to set the stage here now one of the things that we have been doing as a service and as I mentioned as a fan as your functions itself like those lightning bolts those have been open source since day one you can go to github.com slash Asher slash as your functions in our runtime the way that we trigger and run your code has been open-source but there were other things that made people choose things like servlet in the cloud things like that scaling that I talked about so one of the things that we've been working with and talking to the community some partners like red hat is how can we start to bring more of these experiences to that other side to where you don't want to have lock-in to a specific vendor like Azure but you want to run these service workloads anywhere one of the first things that we noticed from some of our learnings is that by default kubernetes is not very well suited for event-driven scaling and that's because by default kubernetes can really only do resource based scaling looking at CPU and memory and in many ways I think that's like treating the symptom and not the cause yes a bunch of cue messages will eventually cause the CPUs to rise but the real thing I want to be able to scale on is oh there's a million cue messages here that need to get processed and that's just not what kubernetes is doing by default so we looked at this we looked at some of the learnings that we had and the thing that we kind of developed and released again in partnership with Red Hat was kaida so this just went 1.0 this week on Tuesday and kada is that event-driven scale controlling that can run inside of any kubernetes cluster so kada can monitor the rate of events to proactively scale a container even before the CPU has been impacted so in the example of queues that I was using Keita can actually say oh wow there's a million queue messages here I need to hurry and scale out to a bunch of replicas I can't just wait for the autoscaler defaults to scale it out it's all it's doing behind the scenes is just feeding this data into the native kubernetes api so we didn't reinvent anything here it allows containers to scale to and from zero as well in the same way that a function or a lambda in the cloud can scale to and from zero it's completely open source we just worked with the service working group and got buy-off we're not working with the Oversight Committee and our plan is to onboard this to the CNC F in the coming months all right I was eating some popcorn before I think at a kernel stuck in my throat anyway so onboarding to the CNC F which we're excited about an install into any cluster so kate is very non-intrusive you can pop it into a cluster e where you already have deployments and you could just map it to only scale things you want to it's not a decision that's gonna change everything and it's got a bunch of extensible trigger sources it knows about as your events it knows about Kafka rabbitmq Nats Redis AWS GCP a lot of contributions from the community as well to improve this library so to kind of show you this in action I'm just gonna do a very quick demo I have a cluster already set up and the only thing I have in this cluster right now is well first I've already installed the k2 operator which I'll go into how that works in a second and then I have this RabbitMQ consumer this container that's going to trigger and consume rabbitmq events and you'll notice right now it's scaled all the way to zero and the reason it's scaled all the way to zero is because k2 knows that there's nothing on that queue that it needs to run let me actually switch to the right directory so what I'm gonna do here is I'm gonna run this job that will publish a thousand messages to this queue let's go ahead and watch what happens you'll see the job spinning up the job just completed so it's publishing those messages and right away you'll see that a consumer has just popped up Keita noticed oh there's actually work to be done here and it's now added one but even before I finish this sentence it's not just waiting for the CPU Keita actually can see oh there's actually a thousand messages here we want to be able to very rapidly scale out so I'm already at four I would guess by the time that I get to the end of this next sentence it will scale out to eight there we go like magic it's gonna continue to scale out this bursty serverless scale consume those messages and if we left this open for about thirty seconds once that queue is empty Keita will help drive the scaling decisions to bring that all the way back down to zero so I'm providing these service container x' to consume compute only when I need them because Keita is helping kubernetes know I only need these containers to run when there's actually events to process it's a very simple demo there to see kind of that in action so you're not just looking at slides so what's happening behind the scenes here as I mentioned there's an operator this you can install with like a helm chart yam or whatever else super-lightweight entirely written and go it's helping monitor those event sources at a configurable period and it also has with it those scalars the knowledge of those event sources this is extensible as well you could write a G RPC discoverable scale or you can contribute directly to Keita and the other pieces here is the metrics API that kubernetes exposes already in the horizontal pod autoscaler that knows how to talk to that metrics api and the other piece i have here is my event source and the demo i just said it was rabbitmq this could be Kafka it could be AWS SQS right could be anything and now the last thing I have is I've got my deployment I have my actual deployment my set of containers that I need to run in kubernetes in the way that I describe my relationship between the deployment and the event source is with this custom resource called the scaled object so I don't know how much you can read this now I know the fonts a little bit greyed out all this really has is it says hey what's the deployment that I'm scaling that scaled target reference which I'm calling my deployment here I can set some metadata like how frequently to pull for events you can control minimums and maximums if you want to make sure maybe you never want to scale to zero maybe you never want to scale about 60 and then you can just define the metadata for your event source like in this case hey I want to listen to Kafka this is where to find Kafka this is the consumer group I care about and this lag threshold thing that lets you control how aggressively it scales sometimes the single message might represent a lot of work so you want to scale out very aggressively and other times a thousand messages might just be a second of work so you want it to scale more conservatively you have some options here to control that more as you need so once I'm ready to go I can then just apply that deployment to kubernetes throw it in there in this case like I did before I've grade it out it's scaled to zero and all the Keita operator is doing now is it identified that scaled object and it just constantly is asking that event source how many events are being generated right is there work to be done here and eventually a queue message or a Kafka stream message or whatever else is going to land on that event source k-tiz can identify it and just like you saw my demo it's going to scale it up to one and then potentially help the HPA and again the HPA is doing all the scaling here kate is just feeding at the right data eventually scaled out to as many as you need okay so that's kind of how Keita works in a nutshell and there were a few core principles that we as a community had as we were building kata the first one is we didn't want to rebuild that kubernetes already offered out-of-the-box kubernetes has an auto scaler great let's use that one kubernetes has a metrics concept let's use that concept it's just augmenting what was out of the box with additional data and insights and capabilities to bring up these service workloads it is also extremely single purpose it's not a service platform this is not trying to do everything it only does one thing event-driven scaling and it tries to do that one thing very well super simple very non intrusive to see RDS and that's it just that single operator running in a cluster it can work with any container in any workload I'll show you later today you could you could take that container it could be running your own custom code it could be running an Asscher function doesn't matter any workload if it has an event source cated knows how to scale it we also in kind of a design principle and what makes kata different and we'll get to this a little bit too we wanted to make sure that application developers could take advantage of all of the features that make message brokers great RabbitMQ Kafka Nats all of these have really rich pieces of functionality that can improve my application we didn't want that to get lost in the translation of bringing service containers and then finally is open built with the community which will go into more - there's one scenario I want to call out quickly it's important to note when you think about these rapid scale out and also rapid scale in and that's what do I do if I have a long-running execution this came up very early with kada it came up with a few of our customers that we're working with where they were like hey yeah Jeff and your demo you dropped a thousand rabbitmq messages and you pretty much just printed out hello world but what if every cue message actually represented a significant amount of work what if every cue message is a video that has to be transcoded that's going to take 8 hours and the problem here can be imagine I drop a thousand videos that need to be transcoded ok to cease it you've configured your scale settings enough and k2 scales you out to a number of different replicas and I've it here there could be like a progress bar this is how far they are on their eight-hour job okay you can see instance two and three are close to being done one in four have just got started well the challenge is kate is feeding these metrics into the HPA and at some point the HPA might say hey you know what the Q's actually slowing down a lot we maybe don't need four instances anymore let's go ahead and start to scale down and the way HPA works the way I like to think about it is that the HPA is very much like vanos and that it's gonna snap its fingers and it's gonna get rid of a bunch of my instances but it has no regard if you are spider-man or Iron Man it's just gonna snap its fingers so the problem here with kada is that if I'm seven hours into an eight hour job and the HPA snaps its fingers it's very possible that the thing that only needed ten more minutes just got killed and so we were trying to figure out how do we solve for these more kind of advanced messaging workloads that might be long running so there's two options that we have to combat Thanos we call them Hulk and Iron Man this presentation is full of spoilers by the way so if the words baby Yoda or if you're sensitive to those words you might just want to leave now okay so there's two options you have here option one you can just leverage the out-of-the-box kubernetes life cycle so kubernetes does a few things it can do like pre hooks it sends a signal to delay termination if you're one hour into an eight-hour job kubernetes can say hey i want to scale you down and you can be just hold on a minute and you can tell - just hold on a minute for hours and hours and hours it works some people don't like it a whole bunch because you see it as a terminating state for eight hours but it's an option the other option that's really cool here is that while we've been talking a lot about scaling deployments with Keita you can also tell it you know what I have an event source here but for every event I actually want you to create a job and in that case Keita will schedule a job for every event you can control the parallelism and those jobs can run to completion so in the video example I might have a thousand things drop in that queue Keita will spin up a few jobs wait for a job to complete clean it up spin up another one and that way I don't have to worry about running to completion so the patterns a little different the intent of those jobs would be grabbed one event process it to completion and then terminate but it works it's a really useful pattern that I wanted to make sure I called out here to enable those long-running scenarios alright let's see what I have next oh this is a great discussion point before we get to the last demo is this the best way to do a vent driven okay and I specifically use the word the best because that's a very loaded question there's very rarely ever the best way to do anything but I did want to present some of the reasons that we feel the pattern of how kada is doing event-driven containers is useful and a useful tool to have in your toolbox and there's a few patterns that are pretty common here especially in the world of server lists and we're not the only ones who do it this way and there's not just one one project or one company who does things the alternative approach but these are kind of the two most common ways to handle event ribbon so how kate is doing it and some others like nucleo is that you have your event source and the thing that's actually consuming those events the thing the developer is writing they're in charge of actually connecting and pulling that event directly from RabbitMQ or Kafka the other alternative that's super common for a bunch of server list platforms and frameworks is that you have your event source but all the developer rights is an HTTP container the whole world is HTTP all I have to think about is I'm gonna write an event driven container expose an HTTP endpoint and then there's some channel or adapter or something else that actually is converting those messages you can imagine it's Kafka something's pulling those messages of Kafka and then throwing out HTTP requests to any service containers that are interested so there's pros and cons to both of these approaches but I want to help explain where where kata kind of fits in here so let's look at the one I talked about the alternative approach the big Pro here is that if I'm a server list developer if I'm a developer wants to do an event trip in container I only I don't have to know anything about how to use the SDKs SDKs can be a pain in the butt to use I don't have to think about that in this model I just think about exposing an HTTP endpoint which every language has a great example of how to do everything becomes HTTP everything becomes G RPC so that's great but there are some cons here as well it becomes much harder for a developer to leverage some of the native event capabilities think of a cue message I don't know how many of you have used a lot of cue technologies before but when you're consuming messages from a cue there's often this very common gesture where you lock the cue message to say I'm working on it and as your developer in your code you actually have a few choices you can make you can say I've completed processing which DQ's the message and it will never get processed again you can abandon that message you can say hey something's gone wrong I wasn't able to finish doing this someone else should go try to do this one again and abandon it and then the third choice is you can dead-letter it you could back you know what this message is crap no one should waste their time on this message again I'm gonna explicitly dead-letter it so even just with queues there's these three distinct options if I'm in this world where my code has been separated from the event source by this middle layer it becomes much harder for me to know how do I do an HTTP response that may be an abandoned may be a complete and it may be a dead letter it's a lot harder for me to reason around it I have to re-engineer those patterns for every single event source some context will also always be lost in transition as you're converting something from a rich type and then transferring it to a bunch of headers in a body there's always going to be some stuff that's gonna have to get lost in the mix especially when you wanna make it language agnostic so it's a trade-off you have to be aware of it also becomes really difficult to do some of those common patterns like ordering I mentioned in the example before Best Buy really wanted service but they really needed ordering we work with a bunch of financial customers who very much care when Jeff when Jeff bought Microsoft stock when Microsoft stock went down and when chef sold that stock the order of those three events are extremely extremely important okay so I need ordering but if I have this middle layer it's hard for me when I'm shooting off all these HTTP events to make sure that HTTP requests one got processed and completed before you should be event two there's ways around it you could be I actually only send one request at a time and wait for it to finish and then send the next one but again things like Kafka just have this out of the box it's like grab a whole batch of messages process of an order super high throughput super high control the only other one I'll flag this is more of an it too somebody has to worry about the SD case someone has to make sure that the events are successfully getting pulled from something like Kafka in this model if it's not the developer then it's someone else who has to make sure that all these events adapters are working they're connected to the right sources and that they're everything making work and in my mind very often as a developer I'm okay being aware of the fact I'm pulling from Kafka and I'll be the one who worries about that SDK ok so again this isn't necessarily wrong it's not necessarily right but there's important trade-offs here and that's why with kada we just wanted to call out this is a different approach right kata will monitor the rate of events and it's going to scale your container but it assumes that your container is going to connect with a whatever protocol it wants to this could be HTTP it could be AMQP it could be mqtt I don't know there's 1,800 different ways to pull messages from something but here we can support them all without having to build adapters that can do the translation layer okay so something I wanted to kind of pause it into this room now the downside to this approach though is that SDK suck okay I don't care what SDK you're using they all suck so for example I love rabbitmq I really do this is an example of the hello world rabbitmq Python example and so if I kind of just scroll through this code all this is really doing is it's pulling a message from RabbitMQ imprinting hello world but I need all this code to just establish the connection peek the message all those other things that's a whole bunch of code that if you're using the alternative approach the developer doesn't have to right so the only last thing I want to show and then I'll do our last Star Wars demo is that this is where we start to think more programming models and programming frameworks can help fill in that gap so I mentioned at the beginning as you're functions is completely open source just ignore the word azure for now we'll take care of that it's all on github it's open sourced this is what an azure function looks like that's doing the exact same task I just say I have a function I care about a queue print hello world now the SDK is still there but it's managed by the azure functions runtime so as a developer I can say I want to write a service function just write my four lines of code still use kata it's still doing peak walking behind the scenes and I can even pass an SDKs to say complete abandon checkpoint whatever but I'm not having to worry about it in my face as much okay so is this where it no not quite where I do it so you might be looking at this and thinking Jeff why are you talking about Azure again we were talking about kata and kubernetes you can take any Azure function you can run an it docker only and kubernetes deploy and you can deploy any Azure function that you write wherever you want to you could deploy it to Asher you could deploy it to Google you could deploy it and run it on premises you don't pay us anything there's no license we don't care you can take that as your function and run it wherever you want to so with that here is our final demo this is a fun one so what I have here what I want to build I have here a dashboard in power bi and you might be thinking Jeff is a cube Conway's at miss crow fauna and to that I would say I don't know how to use crow fauna but that's okay you could do this ingre fauna I'm very confident so this dashboard is very empty and lonely right now and what I want to do is that for those of you who are unaware Twitter is a flurry right now with information about Star Wars everything from Star Wars land to baby oh de to the rise of Skywalker Ben solo was trending yesterday but I was too afraid to dig into why so I want to be able to write a service app that can scale to the volume of all these tweets happening about Star Wars and populate this dashboard with some insight about it and so to do that I'm going to use my favorite tool the visual studio code and I have a Kafka stream that I've been publishing every tweet in real-time to Kafka now I have here an azure function so you'll notice there's no code here about Kafka I've just said hey I want a Kafka trigger you worry about pulling the messages from Kafka I'm gonna pull in these events in order process them in order you know this is in typescript could have done this in Python whatever Java and here I'm just gonna pull in the Twitter event I'm going to grab I'm gonna run some sentiment analysis on it are they happy about Star Wars are they angry about Star Wars I assume everyone's happy about Star Wars maybe should I bring up the last Jedi though that's a more controversy and then the last thing I'm gonna do I'm just going to make a simple HTTP post to that real-time dashboard now what's nice here and one of the things that makes this programming model nice I can go ahead and set a breakpoint press f5 to start spinning up and actually run that open source as your functions runtime directly on my machine you'll see here's the beautiful ASCII art also represented on my shirt saying okay we're gonna spin up we're gonna look at this app we're going to load up the user code that Jeff wrote here it actually already pulled a tweet so you can see I hit my breakpoint let's just step through this a bit whatever tweet this was it's got a score of zero so it's neutral and we could even come in here and see what is this tweet about hopefully there's Star Wars the Mandalorian Disney Plus baby Yoda I warned you I warned you it mentioned baby onna ok so I can break point to bug this and when I'm ready to go I can publish it but let's just not do a boring publish let's do an exciting publish so I'm just gonna one run more command I'm gonna switch the context of my cube CTL I'm gonna connect to Google Cloud so I'm gonna switch here let's do this whole thing on Google so I've just switched over to a kubernetes cluster running on Google cloud and here's where I can run the funk kubernetes deploy it's gonna look at this Asscher function it's gonna put it inside of a docker container build that container publish it to my registry public or private and then deploy that to my cluster now I don't want to have to worry about Wi-Fi and publishing this image so I actually already built the image this morning so let's just go ahead and apply it quickly not that one so I took that function and I just deployed it and here we'll switch to this screen where it's a little bit bigger I could do the same thing where I say watch pods and you'll notice as soon as I deployed it it's actually already said there's actually a bunch of tweets happening so it's spun up one of my Azure functions in Google Cloud kubernetes and I would imagine to an assuming you can all participate in the room as well if you tweet anything about Star Wars there's enough tweets happening right now it's automatically scaled me out to four of those functions so now the real moment of truth when we switch back to the - bored this has now come to life with real-time data the real-time sentiment you can see that heartbeat of everyone in the world who's tweeting about Star Wars right now I see some tweets coming from over here in San Diego so way to go room way to participate right so we can see here there's a bunch of weird hashtags I don't see anything hopefully nothing inappropriate this is unfiltered but that just gives you the idea is there something bad here I hope not yesterday yesterday when I was testing it there was something suggestive in one of the tweets and I was like please do not retweet this in the middle of my presentation people just need to figure their lives out but again this is this is a really cool way that in in the 40 lines of azor functions runtime code by deploying this to kubernetes in this case Google turning on Keita with that serverless scale I've been able to write a server this app that can scale to millions of events but run it wherever I want no vendor lock-in event-driven scale event driven containers whatever I need okay so that's a fun way to see what you can start to do with this stuff so that's it that's all I had to share today we'll have a little bit of time for questions if there's any a few resources if you're interesting kaida SH that's the landing page it will give you the docs the deployment scripts everything you need the code is all on github and we also have community stand-ups every Thursday so if you're interested in participating you want to help with the design you have feature requests you want to contribute some scalars Docs samples whatever we love it all please I would encourage you to join those stand-ups thank you all very much again you've been so welcoming I mentioned this was my first cube con I really hope I get to go to more of these this has been such a fun conference my twitter handles there at the very bottom at Jeff Holland as well if you have any questions as well so with that we do have like three minutes if there's any questions in the room we can answer them here but thank you all very much it's been a pleasure thanks Jeff okay I will run around with questions and just before that please do remember to rate the session on sket comm please do I didn't know it was first but I'll go for who its closest so excellent presentation so I'm fairly new to the kubernetes OpenShift and those sets of technologies I've heard of K native service technology but don't know the details of it but I was wondering if you could compare and contrast K native Takeda and where there's any intersection or how they integrate with one another overlap things like that great question thank you I think from the the biggest one k native is an entire I kind of mentioned kata super single purpose it only does the event-driven scale thing K native is like a full platform it's got Candide of serving Candide of eventing event-driven scale is one of the ten things that Canada can do so that's one of the big differences in considerations it's still evolving we're actually even just this morning we've been working with the K Native team to see what opportunities there might be there so kata itself is very single purpose the only other difference is K native eventing today does use that kind of alternate eventing strategy that I talked about where Kate is different so there there's kind of a change there but you can also mix and match these two like we've been working I mentioned with red hat red hats obviously involved with K native they're using K native with kata and they even have customers who are using that width as your function so there is a bit of mixing and matching kata though very single purpose Canada is a much broader kind of platform thing I think that's how I'd answer it I'm looking at the K native row to see I'm not seeing any disapproving shake so we'll go with that okay I think of the presentation is there also all just killing for the notes ah great question so this will this comes up very often kata itself won't do the cluster auto-scaling but because it's going to be requesting pods it will drive that so how it work you would set up like a cluster Auto scale rule and say if I need more resources I want you to see out Keita might say I need ten containers that each need one core those scheduling requests will drive the cluster autoscale decision so indirectly it does it just not directly you can also use this to kind of indirectly as well with things like the virtual cubelet or virtual nodes so the one I didn't do it in this demo because I was on Google Cloud but if I did this on aks I might also have those scale out into serverless containers like far gate or ACI and you can also drive scale out into manage containers as well pattern great question a question about the word provisioning do you handle it if you do how a provision of the other pots because you can provision too many of them so maybe it's not necessary because the queue is about to be exhausted right correct yes so there there is always the risk that it's like hey quedas making 18 scheduling requests but maybe two is enough and that's where those knobs in that scaled object of both the aggressiveness that you scale and also the maximums will really come into play especially something like Kafka we actually enforce it on Kafka but it will never scale out beyond the number of partitions that you have available so that you're not over provisioning in that way but kata will do the best that it can with the knowledge that it has but there's also some some responsibility to make sure you've got the right maximums in the right pod requests so you're requesting just the CPU you actually need as well we have time for one more do we have to stop at 11:30 sharp case the last one but will also be there's the Microsoft booth upstairs we can answer more there - okay just quick question can you like structure kata to do like workflows like could you say I want to have this execute in a particular order you talked about ordering so could you like save a workflow and then run it you know repeatedly it responds to certain events I haven't tried it there's nothing that would prevent it the one thing that came to mind when you were asking that is there's some workflow tools at least that I'm familiar with like Brigade that let you do like kubernetes jobs and execute a workflow I would imagine that there's a world that you could do the job thing and have that kick off a brigade workflow and it would actually just work so I guess the short answer is I haven't personally tried it I don't think there's anything blocking it but that's a fantastic feature request that even I'll try to mend remember but that's something I'd love to see that kind of stuff to kick off more of these stateful workflows as well yeah okay so that's it thank you all again for coming we'll be if you have other questions about kata you can find us at the booth later today thanks everyone [Applause]

Channel: CNCF [Cloud Native Computing Foundation]

Views: 10,762

Keywords:

Id: ZK2SS_GXF-g

Length: 35min 32sec (2132 seconds)

Published: Fri Nov 22 2019