Intro: Network Service Mesh (NSM) - Frederick Kautz, Doc.ai & Ed Warnicke, Cisco

for those of you who've seen a speak before you know that I particularly like to have very interactive talks it's super boring to just talk at a set of slides it's boring for me it's boring for you but what is interesting is finding out what's going on with you so I will often in the course of our talk ask you to raise your hand and response to questions now I was raised a physicist so what's the first thing you do when you going to conduct an experiment you do calibration so the calibrate how many of you can raise your hands awesome there we go very good compliance on that so for those of you who've been in the room this is basic housekeeping on how to find out all the things going on with network service Mitch this week and how to actually get these slides if you find me or Frederick or Nikolay or any of the other network service miss out here afterwards we have stickers for you that have QR codes and the new logo we're incredibly happy with the new logo so oh power I forgot to plug in the power yeah I'll get a power cord there we go cool so um let's talk about the journey we're about to go on together so to begin with I'm going to wax a little bit philosophical about cloud native networking because if you look at where things have gone in cloud native there are these very heavy patterns that have been coming in from the outside and we'll talk about them about what makeup mix applications cloud native and they've come part of the way into how we do networking but they haven't come all the way in yet and I really think we want to get to fully cloud native networking and we'll talk a little bit about how the existing kubernetes networking API is an incredibly good example of what to do right as far as it went then we'll have at story time so how many folks have seen some network service mesh talks before and you know that I'm prone to storytime but we have an entirely new story for you this time I think you'll rather like it um then we'll talk about how network service mesh works at a high level how many folks have seen the basic sequence diagrams before for the sort of how things set up and are called in other talks ok not so many will do a slight variation on that that gives you sort of a broader picture and then we'll have information about how to get involved in the network service mesh Community Network service mesh is a very broad community we have people from a large number of companies working with us it's very active we've already got subgroups for documentation and use cases and we're really interested in providing a good way to solve more interesting networking problems in the cloud native world that are applicable across all domains so if you have use cases we're very interested in getting you plugged in so waxing philosophical so this wall of text which I don't expect you to read is the cloud native definition that was put together by the CN CF talk I highly recommend you go read it it is incredibly well done but nobody reads a wall of text on slides these however are the things that I think are super important and I'm gonna highlight here today with Frederick immutable infrastructure is a really important aspect of cloud native you can't just go changing everything because you don't actually control the infrastructure you run on yourself you're just a workload loosely coupled is really important for reasons that are super obvious to all of us and and who doesn't love minimal toil show of hands for people who like to work harder than they have to now it's always one so minimal toil networking so what do we mean by minimal toil so we start with minimal conceptual toil so how many of you want to know everything that's going on in your network like who wants to know all the subnets and routes and wants to have to configure them in your paws and so on so we have one person like soil in the back it's always one and so part of so part of what we're trying to do is we say okay well what is the thing that you actually want like the person doesn't want to want to have all these little things leading up to it what they want is they want something solved for them they want something done for them some action it could be something like connect me to my corporate intranet they don't care about what the connectivity actually looks like or what the security looks like other than it has to be secure whether there's load balancing mat or all I kind of stuff in the middle they just care about being able to get to the things that they want and not have to focus on the interface routes or subnets so we also have the minimal consumption toil so what we mean by that is and as a user you ask for the thing that you want I want secure Internet connectivity I want manufacturing partner network or Marsh's app connectivity whatever that thing is will be rendered and inserted into the into the environment with all contexts taken care of so as a user you don't have to focus on the little details even though the details matter but the the but the details should be should be something that come as part of your system to get auto negotiated not part of something that the user has to think really hard about so a really good example of minimal toil is the excellent work that the kubernetes community is done with kubernetes networking right so kubernetes networking gives you connectivity l-3 connectivity between all of your pods it gives you really easy and flexible security with network policies so that you can isolate pods and selectively give access to some of them it gives you really simple but easy-to-use load balancing with services and endpoints um but it's mostly an intra cluster API most of what the kubernetes networking api is talking about is about the networking that happens inside your cluster not all of it there are a few exceptions but mostly and it's a really excellent example of how to do that so that's the conceptual minimal toil you don't actually have to think a lot right everybody can talk to everybody isolation is very intuitive and sewer services consumption is also very minimal toil in kubernetes networking you get connectivity out of the box and network policies are super easy to set up services are super easy to set up so it's a really good example of minimal toil networking and we've taken a great deal of inspiration from that minimal toil so another thing we're a huge fan of is loose coupling so when you are building so application developers tend to understand this really well you want to build something that has a very clean interface that way you can mock what's be it or or replace it with something else with with minimal change so unfortunately much of the previous infrastructure was not based on this coupling things were very tightly coupled to the thing to specific protocols or specific applications and so one of the things that we're trying to push very hard towards is yet that loose coupling so you could have your Lego block assembly say if you want to if your if your operator says this particular connect this particular connection to this system is dealing with sensitive data we really need to have a special firewall and intrusion detection system there to make sure that our users remain safe then like you should be able to easily add these type of things in as part of the policy and not and not have it's so strongly coupled that you cannot die basically is like a giant black box you can't actually work out what's going on and when you start looking at the operational side as well if you have things that are black boxes that means you can't observe them you can't fix them in an easy way and in the worst case scenario fixing them might even be blow away everything and have downtime that's good loop they can lose your company millions of dollars or more not even looking at the reputation side so what other quick thing I forgot to mention this upfront initiative please ask questions as we go it makes it enormous ly more fun for everyone if there's a question that you have in your mind it is almost certainly true that other people are wondering the same thing and you do everybody is service by asking it how many people here like nerd knobs all nerds like their knobs so there's an interesting kind of strong coupling that has become so pervasive in the world around networking that we don't even think about it but if you start thinking about it you start realizing how terrible is making it's making your life and that is our networking is strongly coupled to the infrastructure that it lives in kubernetes gives you inter cluster networking within a particular cluster so you have networking but it's pegged to your cluster your servers are using data center networking that is pegged to your data center if you're running a vim of some sort it has networking that's pegged to your V if you're running in the public cloud you have a V PC that is pegged to your public cloud so everywhere you turn everything in the world is becoming loosely coupled except for your networking which is strongly coupled to the thing you don't care about which is your infrastructure we would like to see that networking become loosely coupled to the infrastructure so it can bind more tightly to the needs of the application developer and if you are the application developer the the vnf or we're saying CNF found native network function developer then having that loose coupling means you don't have to worry about what comes before or comes afterwards you design your application to the best implementation that you're capable of providing and what comes before or after is is not your concern and it makes it very easy for you to focus only on the thing the value that you're trying to provide so and one of the things that's problematic about the pegging of the particular network service to the infrastructure is you have an infrastructure provides precisely one network service to every workload in that infrastructure the granularity you're dealing with is exceptionally course if I have a V PC I have a bunch of things running in that V PC the service provider but that V PC is available to a bunch of workloads that may have entirely different needs once and desires from their network so the granularity becomes an important issue as well ok so we have a couple examples so kubernetes api has been loosely coupled to the implementation there are many CNI plug-ins how many of you have tried different CNI plug-ins did you have heaps of different trouble between where one application would only work on one CNI and not on another or did it just work across once you got the CNI part working so this is a good example of loose coupling and so you have also have some strongly coupled portions to the cluster so when you run your cluster you generally can only have one CNI and there's some ways around this but generally you have one see Nigel cluster so it's an example of strong clustering you have a single edge for your entire cluster or possibly multiple clusters so you have so we start looking at granularity you know once and you start looking at what were close do you have that means that if you have if you only have one knob that you can turn and one application wants you to turn that knob far to the left and the other wants to turn that knob all the way to the right you're only placing a price ticket is in the center and both applications will be unhappy so getting back getting that coarse granularity and being able to to apply it towards different applications is something that's really really difficult at this point so the third thing I mentioned was immutable infrastructure um and this is the realization and this is super-important that effectively when you deploy a workload into kubernetes or anything else um that pod that workload isn't going to change the infrastructure it's going to use it and the same has to be true if I'm going to deploy a pod that is going to provide a network service to other workloads right I shouldn't be mucking with the curl or inserting kernel modules to do that I need to be able to have a way to run something that processes packets to provide special networking functions in exactly the same way that I would run any other pod in the cluster and that pod should be unprivileged unprivileged definitely so you can see some of this graphically up here you have a server you're running kubernetes on it network service met on top of kubernetes and then you have various network services that are provided via network service mesh and then you may have pods running on top consuming all of it storytime how many folks like stories it's a fundamental thing about being human liking stories it's a very good way to communicate things so we like to tell stories so meet Marsha Marsha is a friend of Sarah and she is building an application that has a lot of multi cloud and hybrid cloud aspects so she's running lots of lots of clouds and lots of hybrid things in that cloud so Marsha may have kubernetes clusters running in various public clouds possibly more than one she may have kubernetes clusters running on prep but datacenters possibly on premon industrial sites at branch locations kubernetes clusters are popping up everywhere she may also have some legacy VMs that are running in some kind of a film somewhere that are also part of the application that she's building and there may even be things running on bare metal behind some intranet gateway that she also needs to reach some giant Oracle database running on a server and so these are all pieces of the puzzle that she has to interact with with the micro services she's writing in her application does this resemble anyone's current environment of curiosity for those of you who does how happy is your experience so far it's it's super painful as beautiful as kubernetes networking makes it living inside the cluster once you actually have to get out in an interconnected way to resources that are not globally available to the world everything gets complicated and complicated is bad complicated means when something breaks you can't fix it right so obviously in all these environments you've still got the kubernetes networking and the on-prem and the cloud environment that still has to be there because applications rely on it there's whatever networking is provided by your vim in your VM environment you have whatever networking is going on with the Internet gateways but with the current mechanisms you would use to link these together with things like direct links IPSec tunnels from V pcs etc you run into the following problem and the problem is I don't actually want to connect clusters to clusters I wanna connect workloads to workloads and so to connect clusters to clusters I introduce all kinds of complexity in terms of having to do security across the thing all the ways of doing the service spoken complicated and painful it's a very unhappy experience again how many of you are experiencing something like this or see something like this in your future okay so this is the ghost of Christmas future for some of you or present present for others have any of you actually found a way that has not been painful to solve this so far okay that's what I expected good it means we're solving a real problem so before we move on to the next slide I'd also like to point out that the salmon color lines are connecting directly to the big center boxes so highlighting so this is important moving on to the next slide it is it is clusters not not workloads and when we moved to here we can see that we're now connecting workloads to other workloads not clusters - this is what people actually want you have microservices that have to be able to talk to other micro services so how many of you actually care to have to deal with the granular detail of where your micro services live when you enter connect them that's roughly what I expected and that's the wonder and beauty of living inside the same cluster if you're living inside the same cluster you don't have to worry about where your pure micro services live but if you are dealing with micro services that are not broadly available in a public sense that are some in some way restricted spread across multiple infrastructures this is an unsolved problem up until this point and this is where network service mesh comes in because what never service mesh is intended to do is to allow individual workloads to connect to the network service that actually meets their needs in a way that is independent of the particular infrastructure you're running on so you can use it to say for example you wanted to connect together an application that you're running in a public cloud to a database that's running on Prem that's a very particular network service there's a small number of things on Prem that a particular workload needs to be able to talk to maybe you have particular security appliances that have to be interposed in that conversation that your InfoSec people are insisting upon those are all things they're going to give you slightly different implementation details for that network service and you need to be able to get the thing that you need without having to think about it as a developer the thing you want is the named network service that's it so we have here Marcia's app connectivity provides her with the correct connectivity security and various other services for her application and so again this so usually when when I think of network service mesh like trying to build the mental model of what we're trying to solve I use I usually try to separate it into well we'll say through a three in a scenario the types of users that we care about in this scenario so one of them is the person who who is consuming the network service so in this case this is Marsha so Marshall wants some app connectivity that gets all the connectivity security and so on the second type of user that we care about is the operator the operator who has to decide what does that connectivity security and other services look like and give them an easy way to define this this list of things the third thing is the person or companies the vendors who are providing that thing that is security or that thing that is connectivity or that other that other service and give them a very easy entry point so that they can get injected into those environments based upon the needs of the operator so we have these three needs that we have to balance and so so we've been so when we build out network service mesh we're very cognizant of trying to keep that separation in a very clean way with very clean abstracts very clean declarative declarative formats and so I mean I would a double-click on precisely what this network services to Marcia right this network service is a thing which gives her secure for some value of secure she doesn't want understand too well l3 connectivity not the things in her particular cluster she still has that via the kubernetes networking that is still available to her but to the other micro services wherever they may be on prim in other public clouds on bare metal servers providing Oracle databases wherever that is the network service that Marsha is getting connected to by network service mesh in this story now you can have others we're very flexible on that point network service meshes ambitiously unambitious we connect you to network services we don't insist on what they have to be so minimal toil so how do we how does Marsha say please connect me to Marsha zap connectivity so if you take a look up here we have an annotation the annotation is ns Tod networking service meshed IO so this goes into the in this scenario the metadata of the pod and she specifies the thing that she wants and so what network service mesh will do is it'll it'll use this information to connect Marsha to Marsha zap connectivity yep so ask for what you want that's it so so in a nutshell like as he as a consumer if you all you need is a currently interface to this to some thing that you want this is this is as complex as it gets for for Marcia's viewpoint yep so loose coupling so we've been talking and talking and talking about loose coupling and I've beaten a couple of times on the point that we peg our networking to the particular infrastructure for the particular clustered the particular public cloud VPC in a way that's actually not helpful it's a relic it's an artifact of the fact that we needed a networking somewhere and so somebody built into the thing that was attached to the infrastructure they understood network service mesh allows you to loosely couple your networking to your infrastructure so that the networking that your application gets no matter where it's running these mini parts may be scattered is a single network service that does the things that it needs right you have some magical load balancing behavior that you like that's different than what you normally get you can build that into your network service you have some particular set of IPs or other security requirements you can build that into your network service your InfoSec people want particular NetFlow information so they can monitor for problems that they may be seeing in the network you can build that into your network service and you can connect all the many pieces the workload to that network service without having to peg them to this cluster that cluster this public cloud this on-prem data center yeah speaking of loose coupling if Marcia's app connectivity changes its definition I mean that's a really good couple and then I loose coupling because this Marcia doesn't have to change anything their true Marsha doesn't have to understand how the sausage is made so immutable infrastructure so immuno immutable infrastructure is something where when you you want to establish your your infrastructure in a very specific way and the pods the workloads you were running should not have the ability to manipulate and mutate that infrastructure underneath of them so the infrastructure gets provided and they consume the infrastructure but they but they're not able to change that infrastructure themselves without the help of a scheduler or of the infrastructure itself and so they zero so this so the general de way that it looks is when you're installing every service mesh de 0 is helm install NSM congratulations your kubernetes cluster is now NSF enabled day one we found the thing that we want to to run so we'll do helm install marshes at connectivity congratulations you now have a network service available in your cluster for market to use for our app connectivity so surely this must have changed something under curry Nettie's and everything must be broken no no so the nice thing about network service mesh is we don't require any changes in kubernetes kubernetes is perfectly fine for this purpose already you just have to use it intelligently we also don't require any particular CNI the way that most people have approached having needs that are greater than the kerbin a DS api in the past has been we will hack the C&I and this has a number of problems the first problem is to get the thing you want you have to run the particular CNI that provides it and you basically more or less get one CNI for cluster you're back to the fighting over which direction the knob turns we don't do that at all network service mesh is completely orthogonal to CNI it doesn't touch it it leaves it alone it continues to provide your kubernetes networking that you know and love it exactly the way it's there and this also means we don't have the opportunity to break it we go to great lengths to make sure that no matter what happens we do not interfere in any way with the kubernetes networking that you know and love because that's what keeps your inter cluster stuff working and that is finely tuned for a particular purpose and should be left alone how many folks actually like kubernetes networking ah interesting I expected more it's super nice as far as it goes so for the folks who didn't raise their hands is it because it doesn't do something you want so how many folks is there's just something you want that it doesn't do okay I expected more than that anyway but this is actually really important it's a minimal and minimal impact it's actually a very immutable infrastructure way of approaching the problem kubernetes does things well we don't need to fix it we just need to enhance it so in terms of network service mesh so we've been building AI to work on Google's cloud infrastructure on Azure and on elastic we also have vanilla kubernetes on bare metal we've actually been testing that with the packet packet net for those of you who are the sneaky network people we've been running we've been testing things with with DP DK and other similar or similar things so every time that you that you submit a patch we go through the full CI on this inter this environment and so this is gonna have two effects number one is that over time we're going to flush out all the bugs that that appear on the on the networking side because and not just on our side but actually we've been finding bugs with providers and say we wouldn't call them bugs just and they failed to do things that would be convenient for us if they did them sometimes an unsurprising in surprising ways rather than give a good example like gke is a really great example if there's something that they don't use in the kernel they just strip it out which is good practice and stripped out some things that we would prefer to use but can't now but we have other things we can use so I mean this this the whole point here is we're here to demonstrably prove that we run on immutable infrastructure and the way that you do that is by running your CI on as many different environments as are available to you so we run across the public cloud so that we know that it always works on all the public managed kubernetes so that we know that you when we say just type helm install NSM you can go and type helm install NSM on your cluster on your eks cluster on your eks cluster and get the thing that we're building here one of our one of our goals is if you are running a if you are building the network service itself you should be able to as the provider be able to generate the thing that you want implement the thing that you want and have it run on any of these things and with with minimal to zero differences between them so truly like bringing cloud native networking yep so how the magic works there's a question how many units are actually curious how we do this whoo into how many of you does it actually sound like magic Oh excellent cool so how the magic works so I'm gonna start talking a little bit abstract Li to begin with right so you have a network service registry anybody who's got us any kind of a semester for services of any kind and we're just dealing with the mesh that does things for packets instead of for HTTP headers um anyone who's doing that it's got to have some kind of a registry that you register your servers is with so that when you go to do service discovery as a system that can work number service mesh has one as well now we've constructed in a way that's fairly agnostic as to where it's stored because our ambitions are not to welde ourselves to kubernetes we love kubernetes we do a lot with kubernetes but there's a lot of legacy workloads that need to be part of the network service mesh as well so in kubernetes we happen to be using the kubernetes api server as our network service registry but there you don't have to there are lots of other ways you could do it so how many of you have heard of G RPC so we use G RPC to create the the protocol the the abstract definition itself and so when you connect to the registry you're actually connecting over G RPC and then that service in the background is then storing them in kubernetes but you could if you really wanted to and you decided we're not gonna use kubernetes anymore for storing this stuff I mean you can stick whatever database you want then the background is provided you just implement the API yep exactly so that's where we store information about the network services the network service endpoints all the rest of that stuff and the managers you'll see this in a moment so the next constant we have is these things we call network service managers and you could think of these this way there's sort of like hyper local control plates you can almost think of them as less cubelet for the network service mesh in kubernetes they run one per node as a daemon set and their job is to be able to handle the service discovery service routing and connection management for providing those virtual wires because there's no standard way to do connection management for virtual wires that carry packets or Ethernet frames so we have to provide that as well so those are the second component they're hyper local control planes think of them like cubelet for the network service mesh and they have some domain that they run it in kubernetes they be a single node and that means that there's a set of clients things that consume network services network service endpoints that provide network services and possibly some data plane element that cross connects between them that lives in that particular domain all of those are managed by the network service manager so the client comes up and says I want a network service so it turns to its network service manager the network service manager then turns to the network service registry with the G RPC call and says I've been asked for this network service please tell me all the things I need to know and it gets back the network service any policy associated with it and a list of the network service endpoints that provide it from that point then every service manager can establish a set of candidates to connect to just like if you were doing this with any other service mesh and it can pick one and go to connect and that looks like another G RPC call going peer-to-peer between the network service managers it turns out that the way kubernetes fundamentally thinks and it's the way that scales is to have a small number of local control point control loops that have the minimal amount of central data and interaction in order to function at all and that's exactly what never service mesh does we do not have a big brain in the sky controller instead we have interactions peer to peer and this request would basically have what network service manager asking the other hey please give me a connection to you know that carries packets Ethernet frames to this network service that you registered as being under your purview and here's the list of end cap types that I would prefer in preference order maybe I would rather use SR v6 but I could also use VX LAN maybe I could also use Giri so for those of you who are not familiar with any caps that's where if you wanted to have like a private network on top of another network then endcap will give you that yep it's the the muddy details that you never have to see as a user because we negotiate at all you never have to worry about it as a user of network service mash yep and having negotiated that process with the request then the network service managers cause this point-to-point connection to come up between the client and the endpoint yes yes yes because you know precisely who you're talking to it's the granularity issue again now there are ways in which this can be handled so probably what you're concerned about is the proliferation of interfaces so the proliferation of interfaces on the kernel side is a problem the kernel doesn't scale well for interfaces if you're actually building a network service endpoint there are more exotic options like mem I F that will happily scale quite trivially to having tens of thousands of interfaces in a single network service endpoint without a lot of difficulty at all so basically if you're at all serious in terms of writing a scalable Network Service in point it's super simple and because network service mesh will handle the transliteration for you you don't have to worry about what your client is plugged into it can have a kernel interface there can be an intervening tunnel and when it pops up to you it shows up as whatever kind of thing you wanted the network service mesh to give you as an interface type nope well me so when you say multi-hop do you mean multi hopper do you mean a multi-point yep well but but please note it's connecting to a network service endpoint something that provides the network service right so if it that may be itself a virtual router it may be some kind of other virtual thing that is multi-point that is doing more complicated things so it's not like I'm doing a MIDI MIDI connection between every pod on every pod in the system that wouldn't scale but I'm saying look there is something smart that gives me the network service that I want I'm going to connect the people who want it to that thing and of course I can also do replicas about it like anything else in cloud native and and handle that for both resiliency and scalability yeah there's some really great use cases that where you really want to have that multi-point so we started looking at things like multi casting with video or so on oh yeah I mean if you wouldn't have deeper into the details there's going to be a brainstorming session at the hub lounge it's on the events page that's a really good venue to talk about these kinds of details because I'm delighted to talk about them but we've got a broad audience yeah cool so well we just described you is literally what happens inside a single domain which you could think of as like a single cluster so that we have implemented today it works where we're going and what we're going to be implementing very shortly is inter domain and inter domain literally means that I have two separate domains multiple clusters possibly other places and I would like them to actually be able to interact with each other's network services and so for inter domain when a client comes up and says hey network service manager I would like a network service instead of asking for good instead of asking for something like Marsh's you'll Marsh's network service i could ask for Marsh's connect app connect it's our masters out connectivity I could ask for Marcia's app connectivity example.com and will interpret that example.com as the domain from wit of the network service you want to connect to then the network service manager bakwin simply looks up a service record indiana's for the service registry for that domain it's a very simple mechanism it just lets us find our own the service registry for that domain and then once we've done that we use exactly the same G RPC call we used before we were in a single domain to make exact exactly the same question just from the different registry and we make exactly the same request to appear that we made before it just so happens that this peer network service manager is living in a different domain please note there's authentication credentials and things going on here in the background as well and then we stand up in l2 l3 connection point-to-point just like before because literally other than that first step of finding the service registry which we do with DNS everything functionally is the same as if we were operating at a single domain yes Deanna so you're asking a good question that I think is slightly off-center and we'll get it to Center so basically DNS in general is the network service manager has to have access to DNS to be able to reach a DNS record that part we just presume you have to access to DNS because you're writing the network service manager somewhere that has access to DNS there's a second question that you may be asking which is how do I provide DNS for the l2 l3 connection that I have to something else is that your question or Oh so the DNS does not know about the network service endpoints all the DNS knows is the where the service record for the network service registries which are not fast-moving objects like network services and their employees yes how do we hit a wet how do we handle the IP clashes between the domains okay so this is actually a really good question so you've suddenly gotten with the way you face your question you subtly actually got to the to an interesting point about pegging networking to infrastructure right and are horrible horrible abusive not historically so when network service mesh negotiates these connections the network service itself provides the IP to be attached to the secondary interface and also routes for what's supposed to be routed to the secondary interface now obviously you don't want this to clash with the IPS of your cluster so when the network service manager is making that request it sends an exclude prefix list which includes at least the cluster prefixes so your network service is basically told when you can act you can give me any IPS or routes you want as long as they don't conflict with what's already happening within my domain so if you're providing a network service and you expect to be dealing with someone who may be in a domain where you could have clashes of IPs you as the network service provider will have to decide what strategy you're going to apply to that yeah they just they're compatible but they're completely independent in their management because global IPM is a horrible pain in the ass it's terrible avoid it at all costs yeah oh I'm sorry we're being cut off for time I'd be delighted to talk to folks after I'm sure Frederick would as well we do have if folks want to as we're sort of closing up we have QR codes for pass fox we've done at cube con that are also super helpful we did not cover in this talk all the material that are in those talks mostly because of time we love to talk to you guys and please do follow the events link and get stickers we have QR code stickers that will thank you there as well yeah well one last thing if you want to get involved if you're interested in either from a user and you want to make sure you use case works in ours in our environment or you want to contribute with code or documentation or anything come get ahold of us we will we will help you get involved as well yep you guys have been a great audience you've been super fun thank you [Applause]

Channel: CNCF [Cloud Native Computing Foundation]

Views: 1,929

Rating: 5 out of 5

Keywords:

Id: eLTjXdtlMzA

Length: 38min 37sec (2317 seconds)

Published: Wed May 22 2019