 Hello, hello. Welcome to KubeCon North America 2020 virtual edition Second-ever virtual edition This is the CNCF SIG network intro and deep dive SIGs special interest groups Working groups something different than SIGs What's the difference? Working groups have been well known and established within the CNCF for a good number of years Special interest groups, however, are a relatively new introduction A little about a year old now. They were initially formed to help offload The technical oversight committee or the CNCF TOC Different SIGs have been formed around the categories of technologies This SIG. Yes, that's right. It's focused on networking and projects related to traffic protocols and the like We'll look at a list of what those projects are first Let's understand why this SIG has been formed beyond trying to help offload the TOC This SIG has been formed in part because Network networks and networking have become Even more important than they were in the past or rather networking is quite important in context of cloud native and context of distributed systems Operations that might be performed by a workload by an application Have become distributed as those systems have become distributed as microservices and that way of architecting software has taken a hold as organizations that run systems Whether that's a SaaS offering or otherwise As they go to run these in a resilient way and part of that includes different geographic locations As edge takes flight and we have internet of things and we have networking all around A lot of different networking of various types This SIG has been formed to help in general. It has not been formed to Dictate to people it's been formed to clarify and inform to collaborate and interrelate with the any number of open source projects that are within the CNCF and outside the CNCF Open source groups and organizations and on to parlay efforts We're you were here informed in part to assist existing projects and attract new projects and our stewardship is Should be someone proved me wrong if it isn't impartial There's a collection of co-chairs here Matt Klein of Lyft Ken Owens of MasterCard And me Lee Calcoat of layer five The projects existing projects that fall in scope of this SIG Well, I guess we mark these by kubecon And so the initial set of projects as of a year ago kubecon north america 2019 container network interface core dns envoy grpc linker d Nats network service mesh Since then we have evaluated and assisted in incorporating new projects many in the in at a sandbox level and a couple at the incubation level BFE CNI genie contour kuma service mesh interface And most recently from this past kubecon EU which was held very recently We've incorporated two additional projects and at the sandbox level chaos mesh and open service mesh on the horizon and perhaps by the time that we have that we have this kubecon And that we're we're sitting here chatting at kubecon Ambassadors proposed at an incubation level Meshory and service mesh performance at sandbox level A lot of projects a lot of those had the word mesh in them if you'll notice Or didn't have that word but they were built for purposes of helping operate a service mesh or be a service mesh and hence service meshes are a focus of this special interest group Not the only focus however, we will talk a fair bit about service meshes today Part of the activities within the special interest group are to establish and Help provide a platform for individual working groups that have different focuses So one of those is the universal data plane api working group or udpa Which is To summarize it very briefly is essentially the on void projects apis being formalized and proposed as something of a standard or a commonly referenced specification that Is related to but someone independent of on void itself The other working group that has been established Over the last few months is the service mesh working group We'll talk more we'll talk about the activities within that group here in a moment the the sig network like the networking working group before it As in it within its charter to put out white papers to help inform and clarify Proposed right now as incorporation of a CNF or telecom centric Cloud native networking principles white paper There are also patterns and some reference architectures being worked on We also Encourage the community in general to come and present to come and share with us There is so much happening in this space and This sig network meets twice a month by the way Anyone who's here Watching this video at kubecon or after kubecon Or even if you're not watching this video this talk You're most welcome to come join the discussions Come and participate in the presentations and be part of the The efforts that are going on you don't have to be a CNCF member or your organization doesn't have to be a member of the CNCF to come and participate so So you have very little excuse not to come over and get into the initiatives that are going on Let's deep dive into some of those now There's a few initiatives. We're going to speak about Hopefully demo Yeah, some of these are interrelated in so much as They intend to use resources that the CNCF has like a A set of labs a set of servers To do at scale testing of some of the projects that are being worked on For those projects Part of the goal of doing that at scale testing is to publish results A lot of times those results have a performance centric Focus because At scale systems Aren't necessarily always available to each of these open source projects And so when they get their hands on hardware like that Their focus tends to be on performance Another common goal across the initiatives that we're about to speak to is was one of patterns and In this particular case specifically service mesh patterns Let's look at the collection of patterns that are being Itemized and categorized This is a it's a small wording. This is a snippet of Well, I believe exactly 60 patterns about how it is that People are getting started with Using deploying Configuring service meshes A lot of ways that you can configure a network Consequently, there are a lot of ways you can configure a service mesh And so This slide is something of a tease It isn't possible to show all the patterns on here. There's a link to that sheet if you Are watching this and you don't have the link Come see me directly. I'll make sure you get it if You don't want to talk to me then uh Please visit the see them the the cncf organizations Github so it'd be github.com slash cncf and you will find the sig network Within sig network, you will find the service mesh working group and a link to this sheet There are A few Specifications surrounding so by the way these initiatives if I didn't say it are a discussion of Work that is ongoing inside of the service mesh working group Again kind of a sub working group of sig network There are a number of discussions that revolve around Service mesh specifications or service mesh abstractions This tends to be a focus for us because For a few reasons but in part because the cncf is An open source foundation. That's a neutral vendor neutral And makes for a good platform a healthy platform to have To bring disparate organizations together sometimes competing organizations And those that want to collaborate on specifications by specifications. I mean things like service mesh interface smi If you're unfamiliar smi is um a collection currently of four apis four specs for defining Common service mesh functionality Sort of the most common service mesh functionality And it provides a set of interfaces that Work within a kubernetes environment and allow People who are adopting and using service meshes to interact with them and write their applications Marry up their applications to a service mesh in a mesh agnostic way Another specification that's being advanced here is service mesh performance or smp This is a standard for describing and capturing service mesh performance. So characterizing Both the overhead and the value that's derived from a mesh And doing so in a uniform way in a standard way Lastly there have been um discussions and work done with Hamlet or the multi-vendor service mesh inter-operation effort This effort is really about enabling service mesh federation Service catalog exchange it's about discovering Uh service meshes their resources their services helping establish um secure connectivity between The same type of service mesh or disparate service meshes it's also about providing Authorization and authentication Of Which services should be exposed to the other mesh and which shouldn't what resources are available Okay, so there's three abstractions at play here One of those abstractions smi service mesh interface has a number of adopters and by adopters, I mean Both service meshes that are adopting this particular set of apis the the four apis That that I don't think I prattle off the names too, but it's But they are traffic spec traffic split traffic metrics and traffic access control As seven different service meshes have implemented and claimed compatibility with smi We need to define what it means to be compatible hence a set a hence an initiative around Defining that creating assertions That can be used to verify whether or not a service mesh is in fact smi compatible in order to do that Once you've defined those tests you need to have tooling to Deploy those seven different service meshes Um then on board a sample application then generate ongoing Um load against those that those sample apps And uh to and then run the tests collect the results Guarantee the provenance of those results and send them back in centrally so that they can be reported on and And we can identify Which meshes are conformant or partially conformant and which aren't and report on that So there's been an effort to to do just this If this sounds familiar to you if you're familiar with sona boy As a project that offers similar conformance testing for kubernetes and validation of whether or not a software offering is in fact kubernetes compliant or adheres to kubernetes apis There's a good analogy analogy to to draw between those initiatives With respect to service mesh performance or smp I'll take a moment to describe this one more deeply we we described smi some And with smp I had said earlier at smp is the the purpose of it and what is written into the its current specification is that it Well enables you to capture the details of Your environment um and That environment can be cluster um nodes resources on those nodes And the configuration of your service mesh the type of service mesh the type of workloads All kinds of variables all kinds of information about your environment The type of performance tests that you're going to run The statistical analysis that that should be um provided and extracted The latency and throughput measurements that should be there and it this standard provides a consistent way to Articulate and capture all that information that's necessary to understand The performance of this infrastructure of a service mesh It Facilitates and we've seen some of those that are engaged use smp to build out a new Performance index an easy easy reference index what we'll talk about this in a moment To do comparison between service meshes to baseline their environment and track their performance over time The easy index that I was referring to earlier to just quickly articulate How how efficiently your service mesh is running is This effort called mesh mark or this new index called mesh mark It's built on top of service mesh performance and leverages it mesh mark provides a succinct way of articulating How how the overhead and the value both Of how your mesh is running If you're familiar with app decks, which I suspect Most of you wouldn't be but a quick google search on app decks with one p that will pull up a wiki page probably and And if you grok that that's a great analogy to what mesh mark is for service meshes You can learn more about mesh mark on the service mesh performance site, which is smp-spec.io Another initiative being worked within the The service mesh working group is that of distributed performance analysis And so here two tools are being married up the nighthawk load generator from the envoy project And meshery the service mesh management plane These two tools are being married up to be able to Well again sort of achieve the mission of clarifying and informing to provide Reusable tooling To all of us to all of you for understanding Well understanding and Judging our your distributed systems If you consider that You have systems that you have That you have systems that are distributed But if you're only measuring their performance from one vector from a single load generator, perhaps That's you're probably missing a lot of other insights. Um, and so The goals of this project include the ability to Programmatically dis Burse load generators have them Hammer on your services Concurrently or in serial, but to coalesce collect and coalesce those results Perform analysis on those Um, so that you can have a high fidelity perspective of the performance of your infrastructure from different perspectives from different angles And so Let's take a moment to Demo Maybe smi conformance and as we go to do that and I switch over to demo mode I'll Maybe wrap up here by saying yet again Come and participate in the sig We want to hear from you come and inform the agenda inform this the topics that we spend time on Okay, let's switch into demo mode all right, let's Jump into a demo of one of these initiatives For our demo, let's review service mesh interface conformance The smi conformance tooling so we will look at Both smi and some of its specs some of its apis as well as meshery and its ability to Validate conformance for a given mesh So meshery is the service mesh management plane. You can find out more about it and access it at meshery.io Among its various pieces of functionality with respect to performance management And letting you know about your best Whether or not you're running your service mesh in a best practices type of way Um, it also does service mesh interface compliance. It's the official tool for verifying this conformance It implements smp. We will uh Get started with it by clicking on run meshery And in this case, I'm on a mac um Or you could be on linux, but to use brew I'm going to go ahead and use brew and I'll go ahead and run um meshery ctl system start And this is how we will install meshery locally. It will go ahead and Uh Download the latest version of meshery start. What is in this case? A docker application on my local host. I'm running docker, um locally as well as kubernetes locally So meshery itself starts up we can See that it will manage a few different um service meshes In this particular case, let's let's work with open service mesh We'll navigate and actually, you know, let's Get a bit more familiar with my environment just to take a look around It should be the case that this is yep. It is a relatively clean install So it's more or less just kubernetes that's here in this cluster great let's Set up a watch here for pods in our environment We'll go over to let's make this a little bigger. Let's go over to open service mesh And within this administrative interface, we've got a few different options for OSM itself. First of all, let's go ahead and install open service mesh on our cluster and While that's coming up which we can see some changes happening here We note that there are different adapters, uh, which means different service mesh is supported Which is important for smi conformance Because there are well the nginx service mesh kuma open service mesh linker d istio and console all Um are to be conformant with smi all claim compatibility If we take a look at um the istio adapter, there's a number of of uh pieces of functionality that that you can Um work with it looks like we've got smi up fairly quickly, let's go back to smi Uh, wow osm rather open service mesh. Let's go back to open service mesh And on this mesh, let's go ahead and invoke the um smi conformance test And so we're seeing a small workload being created to orchestrate. Um smi conformance testing This testing actually um takes a little while Looks like we're starting to run some some Additional workloads are coming up. It'll take longer than We probably really have time for Results will be sent back to mashery for publication SMI results can be looked at under the conformance area Let's make this a little bigger. We've run three different, um tests here, um Just just earlier today Right now the smi conformance project is mid-flight in terms of defining all of the all of the tests all of the assertions um that should be verified To to determine whether or not a service mesh is in fact conformant to smi specifications So we're seeing traffic access traffic split traffic spec A few tests being run how long they've been taking Whether or not the mesh itself is um has that capability or is is not so I wouldn't read a whole lot into this failure here the both the conformance suite of tests And each of the service meshes are just now beginning to undergo validation And so we would expect a lot more flying colors for open service mesh and the other six or seven service meshes that implement smi Again, then eventually these test results will be um each of the service meshes will run mashery within their build process and publish results good and so The the particulars if you're interested in what these assertions are and how that what what in fact is being tested Well in um, there's a couple of links right here in the deck And and again if you can't find them in the deck it's issue number 70 in the smi Project but there's a design specification that covers In depth what each of these tests are what the sample workload is that's being Used for these tests and how that works so cool good Mission accomplished on a an intro and a deep dive for the cncf sig network i'll say it again Come and participate come and say hi come and ask some questions. We meet twice a month First and third thursday of the month You can dig into the meeting minutes with your public to get a sense of the discussions and what's going on and who's attending and but yeah I encourage you to join All right, if you have questions, I should be hanging out in chat Um bring your questions. Okay. Thank you