 All right. Good afternoon everyone. Thank you so much for coming to our talk sharpen that edge edge computer ops We are gonna talk about Kubernetes at the edge, but I mean you've heard enough about it We're actually gonna talk more about networking problems with kubernetes at the edge so My name's marina would you actually if you want to flip to the other slide? Awesome. Yeah, my name is marina. Widget. I am a developer platform advocate at solo I focused on a variety of different things from delivering talks to You know talking about service mesh as a VPN etc. And with me I have My name is Kevin I've been in I'm an architect here at solo, which is just a fancy way of saying I work on some of our greenfield stuff I've been working with networking problems and service mesh for a couple years now and excited to be here Awesome. Thanks Kevin. Can we get that second mic working too if possible? All right, so we already know what the edge is but I wanted to create a I Wanted to create a little bit of a background here because When we decided we want to build our own little cloud with edge computing with whatever options that are available to us We have to think about the network. The network is probably the most critical aspect of it I mean, maybe there are other perspectives on what is critical with the edge But from my perspective coming from a network engineering background Networking is critical to make sure that you know we have connectivity between our services that we have clusters that can communicate with each other and then a whole wealth of other things too around security Observability automation and operations But one thing I want to point out is that there are a few kinds of edges There is the content delivery style edge where you know, you might have played with a CDN And then there's the edge that you roll your own where you decide Hey, I want to keep take complete control of my cloud environment or the cloud environment that I've built Distribute all my workloads out everywhere Distribute my compute everywhere and still have it all tied together so that I know when let's say app a fails It has a place to run somewhere else or I have a good resiliency built into my entire edge compute strategy But before we actually, you know dig deeper into the networking side of things. Let's talk about the reasoning behind why Why would we want to do edge compute? I mean, I think there's enough, you know Reasoning behind why we would want to do it. You know, there's a lot of IOT There's a lot of agricultural systems that take advantage of it In fact, I think Stephen mentioned a few good excellent use cases as an excellent talk happening later on today about a particular use case But when we're actually starting to form our edge strategy There are several key things we have to think about if we're deploying to thousands of locations We have to first understand why we want to do this Do we have some specific applications that suffer from latency if we're having to hop across the pond? Do we have any sort of privacy or security requirements as previously mentioned in the last talk? Or do we have any sort of concerns around running workloads close to, you know individual users? More like a geographical distribution of our workloads and apps But then it also comes back to people right do we have enough people to support the solution that we build? Do we have the right footprint and hardware to go out and deploy? I mean considering hardware you have to think about procurement you have to think about the right fit You have to think about how much it's going to cost you from a budget standpoint to not only deploy But also life cycle it over time because guess what hardware doesn't last forever as we know and the most most of the Time you see that systems are swapped out every three to four years because of newer technologies faster chips More density that we require in our nodes, but that's how we arrive at edge computing We start to see that we can pack many kinds of workloads onto a single little node that you might have seen in the last presentation like a nut But we also have to consider other aspects too. How do we get services to talk to each other? Sure, we can you know employ traditional means of networking like an MPLS technology or you know some sort of VPN style technology But then you also have to consider the other layers to like authorization Authentication being able to provide encryption between your services that are communicating across, you know various edges as well as Seeing what's actually going on like, you know, hey, we have an edge down. We have an app down What is actually causing this? So as we start to dig into it We want to focus a lot on the the networking side of it like I mentioned previously So that falls into the realms of communication cloud devices and metrics and and even security and automation But before we dive into that, I want to just bring your attention to an existing Solution today that many of you might have played with called kube edge so kube edge is more is not truly kubernetes, but it behaves and acts like it's a kubernetes environment and The way it works is you have a few components like edgedy Which effectively is the equivalent of what you would see as the kubernetes control plane in a you know cluster as Well as a few other components like edge hub as well as an upstream kubernetes control plane and the reason why you have to deploy a kubernetes control plane is because kube edge acts as a translation layer so that I can simulate as if it's running as a kubernetes cluster There's also one more thing. I'll mention in in fact that There's a technology called edge mesh that allows for connectivity between all these different edge locations that you could deploy but there are limitations with something around edge mesh around Achieving zero-trust security making sure that you can see what's actually going on and capture telemetry KPIs and metrics from your apps It only provides connectivity at a very basic level. So you start to think okay If I want mesh like functionality if I want connectivity at the layer 7 level, you know, I have HTTP communications going on all over the place What do I do? So let's talk about the network stack first and then we'll start to dig into how a service mesh helps with this a true service mesh So you think about your network stack for a second and you could either go with cloud or x86 hardware that you procure You can deploy a physical network or use something like SDN or a VPC And then you could take that further and then decide hey I'm gonna run kubernetes or in a CNI or a container networking interface and then a service mesh Because that completes the network stack and the reason why that is is because yes You can get connectivity through a CNI you can have things talking to each other But when we're starting to talk between various different services, we're talking thousands upon thousands of services The mesh or the service mesh really provides a significant layer that helps us optimize those communications to cure them and see what's going on But let's talk about service mesh specifically and see how this helps So in service mesh, there are three key things that it provides. I mentioned already connectivity The security aspect and the observability but in order to do so it uses something called a sidecar proxy So you have kubernetes which communicates with something called a control plane or the Istio D control plane because we're talking about Istio in this case and Istio D acts as your point of configuration your point of management with respect to how your sidecars operate Your sidecars are something that are deployed. These are these little artifacts that are deployed alongside your main application container and They do all the routing all the Request responses for that service or on behalf of that service But here's the thing if you look on the very far left there there's so many different services that are running let's say inside of your environment and Every service that you have gets a sidecar so that consumes CPU and memory also when you think about this from an operational standpoint What actually happens when you onboard services that you already have deployed into a service mesh? You actually have to restart your services and that is impactful That's a service impact at that point Which means there could be an outage or you actually have to schedule a maintenance to take these services off line For a short period of time so that they can come back online with your sidecar Now in order to get away from this there were so many different approaches out there But I will say that solo and Google work together to develop something called ambient mesh a sidecarless approach Now the sidecarless approach means the sidecar proxy itself is no longer deployed However, all the capabilities of the Istio service mesh still exist. How is this possible? So if you actually look on the far right diagram there We have two things called the else L4 proxy and then the L7 proxy if you actually combine these two This is your sidecar except we've just moved it away from the actual workload itself Now the layer for proxy, which we'll refer to as the z-tunnel going forward Basically acts as the sidecar on behalf of multiple workloads that exist on the same node so the z-tunnel is a daemon set and Effectively will provide layer for connectivity layer for authorization policies as well as MTLS so that you can still provide Encryption between your services that are communicating with each other Then when you decide you want layer 7 authorization or you're you're trying to capture some level of observability at that layer This is where you would deploy a layer 7 proxy, which we refer to as the waypoint proxy Now the waypoint proxy is is still based on if you're familiar with envoy the envoy proxy Which effectively has always been the basis for how we do service mesh with Istio however with the z-tunnel or the layer for proxy we actually Developed a lightweight rust-based proxy to strictly focus on layer for connectivity in that MTLS The reason behind this was to optimize how this would work to reduce the footprint of the actual Sidecar itself just to focus on those two key features and then still ensure that we provide full service mesh functionality Now, how does this look if we actually decide? Hey, we want to deploy edge computing We also want to use a service mesh and then we decide. Oh, we have multiple clusters enter multi cluster ambient mesh so Ambient mesh is sidecar lists multi cluster ambient mesh or multi network ambient mesh is the same thing Except now you're scaling with so many different kinds of clusters They could be kubernetes clusters that exist in your cloud platform that you've built so that you're using as a service These could be data center kubernetes clusters or even edge clusters But the interesting thing here is the way this all works Now let me describe a few components here now if we focus entirely on Just the edge compute cluster one. We have a base operating system. It could be any flavor. It could be something completely locked down We're using some flavor of kubernetes in the case of the edge you may want to consider maybe something like k3d or Maybe kind. I mean kind is not super production But you consider the fact that you want to use something lightweight that doesn't consume a lot of resources But still provide you the functionality of kubernetes and then you also want to consider Yeah, you've got your CNI layer, but your Istio ambient mesh layer as well. So that gets deployed into the cluster There are a few components that do get deployed like Istio D as well as your z-tunnel Because you need it between different nodes as well as the way point if you decide you want layer 7 authorization There's also one more thing that gets deployed that maybe you all have never really seen before but it's called Istio CNI And it actually acts as the mechanism to route traffic into the z-tunnel from the source workload So let's just say in this environment book info is split up into two different You know clusters Book info is just a bunch of microservices that produce a page that tells us, you know How good this book is or several books, but we've split those services up across these two clusters Now how do we route to those clusters? How do we route services in the primary cluster or cluster one over to cluster two? Well, obviously we'll need access to a load balancer because that load balancer gives us that external connectivity inbound But the other thing that gets deployed is something called the east-west gateway in Istio So the east-west gateway services traffic that goes either from one cluster to the next cluster and Ensures that we could get traffic all the way through and ensure that requests make it through the through the mesh now how this all works is Z-tunnel is Co-located with the workloads or the source workloads the identity is captured of a source workload Shared with z-tunnel so that it can impersonate its ID Z-tunnel will will basically indicate to the other end to the destination side Hey, you know I have a node that or so I have a service that needs to communicate with you now That service communicating with that destination workload needs to pass through a few things and if you actually follow the red line Book info is communicating with a z-tunnel Z-tunnel is actually tunneling to the east-west gateway The east-west gateway is tunneling to that to a destination z-tunnel which you're not seeing the z-tunnels right now But finally the traffic is un-capped or sorry the traffic While it is encrypted is actually un-encapsulated so it could be passed directly to the other services The reverse is entirely possible too. So what you actually have here is tunneling. Are you all familiar with IP sec? Yes, can I get some nods sure? This is very similar to how IP sec works now interestingly enough if you see This red line that follows all the way through to the east-west gateway and into book info This is actually double encapsulation that we're doing here now I'm going to pass it to Kevin because Kevin's going to explain a little bit more about this double encapsulation And why we do it with z-tunnels and east-west gateways Yeah, so now we can hear the You know, thank you for the introduction Rena on Istio ambient So again the pitch here basically is this a couple changes, you know just like in the previous talk, you know We're working with edge devices here You know, we have resource constrained environments But we may need to actually talk to disparate Kubernetes clusters think about like phoning home for updates talking from an edge device to a cloud device One of the things that's majorly different about what we're able to do here is that when we look at this request flow We go from, you know one z-tunnel is all we need in our local, you know edge Device or a cluster right and everything else lives in your remote which could be your cloud and another network We want to make sure that these communications are secure The real goal here is to get mesh like functionality You know standardized but bring it to edge devices and we part of the reason we can do this or what's improved is that z-tunnel or the zero-trust tunnel is Implicitly designed to be very minimalistic You know the XDS configuration is tailored to this use case It runs on the order of megabytes whereas like a simple envoy runs much larger, right? And this means that we can bring mesh functionality to devices at a much lower cost than we could before Further we can do it more securely than we used to if you're familiar with Istio and how multicluster works for You know the classic sidecar model they would do like SNI routing There's some potential issues there with being able to like DDoS backing pods. There's no validation done once you reach the remote network We improve on this model here with with Istio ambient multicluster because we do this double tunnel, right? So the there the tunnel has two TLS Encryptions in two different identities the outer one is on the right. You can see we have H bone outer and inner H bone is just the Istio protocol. It's basically an H2B connect tunnel It's just stands for H2B based overlay network and that's basically what we're building here These this network of z-tunnels are basically an overlay network And this allows us to standardize and bring our edge devices to a like broader network if we want to right? We can do all of our compute locally and you know on the edge device and then phone home You know periodically when we need to securely and so that outer identity is the Z-tunnel identity it allows us for to do connection reuse if that doesn't verify We we kill the connection and then the inner tunnel goes to the final destination in this case service B Yeah, that's the this slide awesome So one of the biggest challenges is if you try to do Istio multicluster at scale It actually is very challenging There's a lot of different elements. You have to consider one of them is actually trust another one is automation And how you employ something like get-ups so when you start to think at that level of scale You're not just using a single cluster with Istio or even Istio ambient mesh or even a single edge environment You're actually thinking about multiple edge environments. You have to start thinking okay How can I manage this under a single platform? So sorry, I have to plug glue platform because glue platform enables this it takes a get-ups approach To ensuring that you could run multiple clusters multiple edge locations still have Istio ambient mesh in place But you're actually using a centralized control plane to push out configurations So if you look up at the very top we use glue platform to provide a set of CRDs That effectively translate into Istio resources Now as long as I configure this single set of CRDs This gets applied to the necessary edge locations as I would need it to and because of that now I'm actually simplifying my overall operations because onboarding becomes easier life cycle management of my environment's running Istio becomes significantly easier and now I can see literally every single environment under the same Observability platform So if you're starting to think about that scale especially when it comes to service mesh and edge computing check out glue platform So with that I'm actually going to pass it to Kevin to actually run a quick demo And he's actually going to show you how ambient mesh works in the multicluster multi-network environment take it away Kevin Is that all big enough? I think you can see yeah Fantastic So we should have an environment set up here and because I'm very forgetful at typing the commands I've kind of scripted up in advance, but this is a live demo. So hopefully it works So yeah, I've taken the liberty of kind of setting up two clusters here for us to take a jump into The first one here is basically like representing our our remote cloud cluster. So this is We can look at all the pods that we have In here, we have default namespace with details product page ratings. This kind of just is the classic Istio you know Example product like service. It's not it's not really that relevant except that we're good this is what we're going to query at the end, you know, we're going to phone home to a remote service and Just like Marino I talked about we have the CNI nodes this ingress gateway is our our You know ingress gateway. This is an envoy proxy and then we have the Z tunnels which are the zero trust tunnels And then in our remote cluster, you know in our edge cluster, it's much more minimal So we just have Istio. We really didn't need the ingress gateway here, but we have a sleep pod this is just representing like one process that we want to run on an edge device and then everything else is very limited Z tunnel is just You know the only other component that you really need to to go ahead and phone home And it's getting all that configuration pushed down by Istio D and so if we want to go ahead and set this up so that we can go ahead and You know phone home. Let's go ahead and apply some configuration I'm gonna have to scroll through this so we can take a look at everything here Starting from the top we have An Istio gateway, which tells us to configure our you know ingress gateway to listen on port 15,000 8 for each bone This is gonna help us be the destination for our traffic for decapsulating that outer H bone We'd mentioned briefly, you know a double encapsulated H bone This is telling us to listen and decapsulate that outer one You know validate that we verify this traffic is coming from within the mesh and then we have a service entry here You know, this is basically the us defining a way for us to to phone home. This is the host We're gonna hit we're gonna make requests to service entry istio.io on Fort 9080 we're gonna go to workloads that have the apps, you know app selected and we're gonna go with these identities You know Istio is identity based. We use spiffy for identities. That's all standard and built-in And then that app is gonna select here this workload entry This brickled entry in our environment, you know, this address is the address of the east-west gateway in this example You know predetermined that this is the IP that we're going to be using so we can go ahead and apply that configuration and This is you know going to be that source of truth for how we want to handle routing So I'm going to go ahead and Copy this command need a second hand and then we can go ahead and make a request And what we're going to see here is It's hard to read but what I want to highlight here is so we're making a request to the service entry IO that that service entry host that we had defined on 9080 to the product page the idea here is that we want to hit that ingress gateway and get in the first cluster And then that service in that first cluster. We're actually failing that request because of a TLS Verification error the self-signed certificate. It's kind of a misleading error here But basically what we we didn't do here is we've got two disjoint, you know, Istio configurations We need to make unify our route of trust Because this is a demo. I'm going to be lazy and just copy that secret from two to one But realistically we would have generated those secrets with the same root trust So now that we've gone ahead and done that We should be able to move beyond that that error for making requests So always got the logs running again on the right And we make the request again Again, we see a TLS error, but now we're getting a different one So again, I talked a little bit about we're doing double validation here of identity to make sure that our traffic is secure to TLS We can see here that we have a sand verification error. So we're basically getting the wrong identity You can see that we expected the identity bad ingress gateway service account But we got a good account and so what we have here is actually a misconfiguration error If we look on the left at the service entry that we had applied earlier You can see that the subject alt name has bad ingress gateway You know, this is about it, you know configuration error something that maybe we could You know improve upon if it were generated or handle for us by a platform but if we want to go ahead and plot, you know fix this error we can apply the new resource and We do that So now that we fixed that error, we can do the same thing and Again, we're gonna get an identity error But just to highlight that we've done a double tunnel here. This error is actually a different one It's still a sand error, but now we've actually got an error validating the inner tunnel so we've actually detunneled the outer one and now we can see that we have a bad value for the the surface account on the default namespace and this This identity value came from the workload entry, which was which was here We had again misconfigured our resources with a bad value If we go ahead and correct that Then we should be good to go And I expect this to work Beautiful awesome. So we got a request served by review Z1 This is like a full web page We've kind of successfully demonstrated here that we were able to use H bone and go to our east-west gateway Make a multi-network request with Istio ambient and you know, that's that's what we have here for the demo Awesome. Thank you so much Kevin. So if you just saw all of that Would you be willing to sit there and do this a thousand times over for all your edge locations? Nope. Nope. This is why This is exactly why I think y'all should come talk to us the solo booth to learn a little bit more about blue platform And how we simplify this process Kevin. Can you switch switch back to the presentation? So I want to just tie off here with a few edge use cases I'm not going to enumerate or list them all out But I want you to think if you currently are working for an organization that maps to any one of these use cases Yes, I'm sure you can certainly figure out the edge computing piece of it But when it actually comes to the networking, I will be very honest with you You will struggle unless you consider something production grade like a service mesh So come chat with us learn a little bit more about if you if you don't know how a service mesh works Come learn from us. We can teach you a little bit more about it. We're gonna be here at KubeCon for the next few days Kevin and I are just gonna be hanging around the booth Actually, I will say I'm actually doing a workshop tomorrow, which I think you all should come to it's about network foundations And that's also gonna set you up to understand how a service mesh works I can't remember where it is. It's somewhere, but it's one of the first workshops in the morning Come check it out, but I just want to say to wrap up when you think about edge computing It's not just about the number of resources you have available on your your system It's not just about the kinds of apps that you're going to deploy But it's also about the the platform that you have to consider if you're going to be managing multiple environments It's also about the fact that you have various different connectivity options But these connectivity options present their own challenges for example You might have a very far geographical edge that has very limited connectivity And it could only use satellite internet or it might be able to only use maybe DSL And you have to factor that in as you're deploying your edge environment too But understand one thing when you have changing network conditions the service mesh is actually gonna save you So I just want to end with you know if you want to learn a little bit more about edge computing There's a great book by Sergio Mendez He wrote a book that's focused on K3's and linker D but the pot of the the concepts can still be applied to Istio ambient mesh as well as any kind of edge compute and On the far right if you actually look want to look more about or want to look into more about Istio ambient mesh There's an e-book that you can download as well or come by our booth We probably might have a whole bunch waiting for you and finally if you want to learn a little more about application networking hit up Solo Academy I want to thank you all for your time. I want to thank Kevin for an excellent demo I wish you all an amazing Kube edge day in a coupon. Thanks everyone