 Alrighty, I believe it is time for us to kick this off. So we have so much to cover I'm going to go ahead and start feel free to keep on coming if you're waiting in line. There's lots of seats up front here So yeah, welcome. Welcome. My name is Randy Abernethy. I'm a managing partner at RxM And this is kubernetes networking 101. So Let me just see a quick show of hands. How many people would consider themselves very savvy kubernetes networking people? All right, so everybody else if you saw someone raise their hand you got questions, you know where to go, right? Who's those people? So yeah, this is going to be a super fun tutorial. We have 90 minutes We have a ton of stuff to cover and I'll just give you a quick intro to the format We've stood up hundreds of machines in a cloud provider who shall remain nameless since they wouldn't sponsor us and so you guys can SSH into the box that you were Provided on this sheet now. I realize that we're on conference Wi-Fi, right? We all know what that means. It's probably really bang-in great Wi-Fi, but there's 200 300 people trying to use it all at the same time So the best thing that we could do is instead of you downloading all sorts of packages and And containers and stuff that would be really slow You can just SSH to these cloud instances and send a few characters back and forth every once in a while It's the lowest bandwidth thing that we can come up with for a session like this It's also really great because if you completely thrash this computer your laptop is still fine, right? So don't worry, right? It's a virtual machine and if you do completely thrash this computer We have spares so I have three folks helping me today Chris Ilyan and Valentin and Chris is by the way doing a talk at 1600 Coot-Cuttle said what which is going to be super awesome So I would go to that if I were you But those guys are going to come around and help with questions So if you have a question raise your hand those guys will be scanning the room They'll come to you they can give you a new machine if you need it We got spares and they can help you get unstuck if you're working on a part of the tutorial that isn't working We've tested it a bunch of time So I feel pretty good about if you read the tutorial steps carefully and do them the way that they say it's going to work so Hopefully won't have too many problems, but we're here to help if you have any questions at all Feel for you to ask yeah question. Ah great great question So when we get to the first lab break I'll go into this in some more detail But the question was hey, I don't have my laptop or my laptop's locked down or something and I can't get to these boxes What do I do? Well you can We're gonna have some slides and presentation and I'll probably do a lot of the steps if I have time while I'm running around So you get to see that but also there's instructions in the lab as to how to stand up a plain vanilla Ubuntu 20.04 server that you can do the labs on there's nothing special about these labs They just running on a plain vanilla Ubuntu 20.04 server We literally start from the absolute start install Kubernetes set up CNI start creating services Install the service mesh install that you know the ingress everything is is right in that lab So it'll be really easy to redo later also and I and I appreciate that question because hello virtual people all the people who are Over here hello virtual people all the people who are online Obviously you didn't get one of these sheets with an IP You know we just there's like 800 people or something signed up So we couldn't do it for everybody But if you've got a box that you can use that's a plain vanilla Ubuntu box of VM You can just either SSH into that if it's in a data center. It's on your laptop if it's in a cloud somewhere That's gonna work fine And there are instructions for doing exactly that in the lab right the lab points you to a Virtual machine setup dock which is a markdown on github and you can follow the instructions there to run a basic VM That we already provided for you It's just a plain vanilla Ubuntu box again, but you can stand that up and do the labs So yeah great questions and I'll continue to you know give you more information about the lab as we close in on getting started on The first step this this session is organized into five parts We're gonna take about 15 minutes for each part and then I've got you know a very tight budget here to get started So we're gonna do like maybe five minutes of discussion and then ten minutes of lab work five minutes of discussion Ten minutes of lab work. This is a hands-on session, right? This is a tutorial so you're gonna be doing all of this stuff And I'm only gonna give you the overview because you're gonna do it right? Why should I tell you the commands when you're gonna type on yourself so? All right, so that's that's it. So for these three guys are out there ready to help Also, you'll see that there is a tutorial lab dock in the slide deck here It's also on your sheet. So for the virtual people you can get this deck off sketch So these slides are on schedule ready so if you go to the talk you see this the schedule you know the slide link click that you'll get this Dock and then that link will take you to the markdown So let me just preview that markdown for you real quick make sure everybody's able to find it It looks like this All right, so if you if you follow this github link it takes you to kubecon EU 2022 So the full URL is github.com slash Rx dash m slash kubecon dash EU dash 2022 slash tree slash main obviously and then if you Click on the markdown it's just gonna open right up That's the lab right and you'll notice that it's broken up into steps so step one our first lab sessions going to be pod networking and That docks not going anywhere that'll be there forever So you can look at that in three years if you want to nothing will work. I'm sure but you could try it Okay, so that's a bit of the startup Hopefully now everybody's got a sheet with the IP the other thing you're gonna need to log into the lab system You need an IP address right to reach the host then you need to prove your identity And so you're gonna be a boon to big surprise right? That's your user ID and then you're gonna need a key and that key the link for the key is on here, too, right? So Here's a hint also. It's the same key So if somebody needs help you can log into their machine right with these machines are all going away in about two hours So All right, that's enough of the logistics. Let's talk about the talk so our goal is to introduce the world of kubernetes network communications in a high level but practical way the idea of each of These little thought experiments these little labs is to show you how a part of the kubernetes networking world works in Enough depth that you understand it and you could walk away and go cool I'm not a networking person But now I get it and it's everything's gonna be a lot easier for me because I understand all these little parts or If you are interested in digging deeper you have a beginning point, right? We've installed all the stuff everything works together That's a lot of the times, you know the big time waster now you can get down to the business of playing with it and experimenting and taking Your journey further so that's the idea behind this session Concepts and projects that we're gonna explore we're gonna begin with container networking and talk about pods and how they talk together And that is gonna involve a CNI plug-in Kubernetes doesn't it's not opinionated right it doesn't come with a networking solution It doesn't come with a container runtime It doesn't come with storage drivers right you have to add all those in through the container network interface The container runtime interface and the container storage interface right those are the three big legs of the kubernetes stool It's very rare to find a kubernetes cluster that doesn't have plug-ins for all three of those and sometimes multiple plug-ins for some of them But to just get up and running after you've installed kubernetes you're gonna need a container network Interface plug-in and we're gonna use psyllium psyllium is a project at the CNCF really cool Solution for networking and we'll talk about that briefly then we're gonna get into step two which is kubernetes services So once we've got our cluster running and we've got the network in place And we've seen how it works and understand the absolute basics We're gonna dig into services and we're gonna see how services give us a front-end for a set of dynamically changing pods Clients don't want the heartburn of figuring out who to connect to they want a virtual IP address that they can look up by name That they just connect to and then the magic happens and they get to one of the pods right so that's what services are all about We're gonna look at how kubernetes does that at least one of the ways that it does it and then we're gonna take a look at DNS Humans don't like to remember IP addresses also IP addresses tend to change a lot more than concepts a service name is a concept if you have a You know CFO reporting Service it's probably gonna be called CFO reporting forever or for a very long time and anywhere you put it But if you deploy that in Singapore it's gonna have one IP if you deploy that in London It's gonna have another IP so services use these names to create an abstraction Again another level of abstraction on top of that virtual IP and we're gonna see how kubernetes implements DNS And it does it in some interesting and creative ways one thing that's fundamental that we're gonna hammer on a little bit are Concepts around kubernetes. You'll never understand kubernetes networking If you don't understand kubernetes kubernetes thinks about the world a certain way you don't have to deploy applications that way But if you don't understand it you're gonna keep stepping into potholes if you understand it You can protect yourself and say well kubernetes wants this to be this way But we're gonna change it a little bit and we're gonna make sure we've done the correct things to keep kubernetes happy when we do it Slightly differently from how kubernetes expects and this really applies to networking and we're gonna see some of this in the DNS section Next we're gonna do step four which is outside access we're gonna see how from a cluster where you've got all your cool services running you can get from the outside in and There's a lot of ways to do that, but fundamentally there's two simple paths And there's lots of other crazy stuff that people are marketing and trying to tell you do all this There's two paths under the covers of all these things. There's two ways in and so we're gonna look at that And we're gonna talk about some of the cool Projects that fit in there in addition to core DNS on the DNS side We're gonna look at emissary for ingress and gateway kinds of functions Envoy is a proxy that emissary uses under the covers and then we're gonna look at what we're gonna talk about metal LB The sometimes when we do this talk we run metal LB, but with this many people and it would be crazy So we're not gonna do that, but we'll talk about it a little bit And then finally we're gonna get into service mesh step five This is sort of the pinnacle right after you've got everything else working perfectly That's when you might want to start thinking about service mesh. Not everybody needs a service mesh I don't buy that not everybody needs a service mesh. However a service mesh is an incredibly powerful and valuable thing And so you might need it you might want it it can be an incredibly valuable tool We're gonna talk about what service mesh is due and we're gonna use the only graduated project in the CNCF ecosystem that is a service mesh linker D and It's a super cool project has a ton of amazing features and we'll just Scratch the surface in this session, but you'll have it installed You'll see how easy it is to fire up and you'll know the basics So you can again carry on your journey and explore linker D all you want after the fact Okay, so that is our plan now. Let's see how we do I'm gonna quickly switch over here. We have burned ten minutes. Yeah, it's okay. We got to get going All right, so step one and remember if you've got questions, there's three guys, right? Chris Ilyan and Valentine out here that will help you out So just raise your hand and they'll come and answer your questions while I keep going to keep us on track All right, so container networking concepts. Let's talk about this just briefly the the first thing I want to say is There's no such thing as a container Maybe that's a little shocking in a container-based convention, but there really isn't right the Linux kernel has C groups What do they do? They are control groups. They control how much memory or CPU you can use the Linux kernel has namespaces What do they do? They isolate what your process can see Can your process only see itself and its children or can it see the PIDs of other processes? That's the PID namespace, but what we care about is the network namespace a network namespace makes it so that a process can have its own virtual copy of the IP stack Inside what we think of as a container you have your own route table your own IP tables your own Interfaces loopback and things like that So that's really useful because now we can reliably deploy things that listen on port 80 many many times on the same computer Because they all have their own interfaces So this is magic right if we had a big cluster of machines and we wanted to dynamically roll out applications They're all fighting for ports and craziness like that. That would be pretty tough So what ends up happening with container tech is you get reliable deployment. That's a really huge thing But we need something to sort of do the deployment right to make the the deployment work And that's where Kubernetes comes in and Kubernetes There's no such thing as a container What Kubernetes does is it takes container images, which are just little tar balls with root file systems in them and It runs several of them in the same network namespace That bundle is called a pod right they share the network namespace They also share the inter process communications namespace We want it to be cheap for them to talk to each other right so if you're using mqs or Shared memory stuff like that those are in the IPC namespace and if you're using the local loop back and stuff like that That's in the network namespace so pods are collections of container images That are all running in shared network namespaces so in kubernetes interestingly the pod is the unit of distribution It's the smallest thing you can schedule It's the smallest thing that you can scale and they're atomic you can't run part of it on one machine and part of it On another right so really what we're thinking about when we move to kubernetes is not container networking It's pod networking and so pod networking works like this You have an interface in one pod and an interface in another pod They both have IP addresses and now you can talk right these these two guys can communicate with each other You can have as many containers as you like in the first pod and as many containers as you like in the second pod Or as few as you like so pods are the the unit Distribution and also the unit of network identity right the unit of networking. They have an IP address Interestingly enough the pods need to be able to communicate with each other That's what kubernetes says all pods in a kubernetes cluster must be able to communicate with each other right now The world's changing there's lots of exceptions to the rule But as far as you know your basic network requirements to for kubernetes to function the way that it's supposed to All the pods have to be able to talk to each other now What if I want to put some pods in the Staging namespace and I don't want them talking to pods in the production namespace well You can create network policies that you know change the rules up and stuff But it has to be possible for every pod to talk to every other pod What that means is that pods need to be able to communicate with each other when they're on different machines Linux has stuff built into it like Linux bridge and things like that that acts like a virtual switch Where all the pods can talk to each other and you don't really need any extra software But as soon as you start communicating outside of the computer to another computer Something's got to happen right because these pods it's in the old days We might put a piece of software on there and then we might go and program the network a while and now everybody knows where it is That's not gonna fly in kubernetes right where we're deploying nine times a day ten times a day pods are scaling up and scaling down all Day long that's not gonna fly. It's got to be automated So we need software to find networking, but the problem is if kubernetes just said yes apply some software to find networking thing It wouldn't work because you know kubernetes would be integrating with 50,000 different things And so the CNI is a standard that makes it possible for kubernetes to make the requests that it wants to make like hey I've started up a pod and I created a network namespace for it, but it's plain vanilla. There's no interfaces. There's no rules There's no routes. There's nothing in there. So hey Mr. Software to find networking thing Please wire this pod up so that it can talk to other pods on this computer and any pod in the entire cluster So the CNI Solutions generally have at least one and sometimes two components The first component is a daemon set pod that runs on every node in the cluster and handles the you know The organization of all the pods on that cluster and then sometimes there's a control plane too But those CNI components make it possible for pods to reach each other when they're on different hosts And they can do that in lots of different ways They can just use routes right you can give every host a subnet and then the you know The plugins can discover each other subnets through lots of ways gossip or they could use that TD to save all that information And then once they get a an outbound connection they can say oh, yeah that IP address I know is on that host so I'll just route the traffic. They don't have to encapsulate it or do anything like that on the other hand It's nice sometimes to encapsulate the traffic because if you do then you can do things like encrypt it on the wire You can do things like Make sure that the the underlying network doesn't know that there are pods Right it just sees two hosts talking to each other instead of a bunch of you know 20 different IP addresses from one computer if you try that on a cloud provider They're probably gonna kill your traffic. They're gonna go. Hey, you know that machine I know its IP address is dot seven and I see all these crazy source IPs coming out of that box There's an attacker in there trying to spoof right and so of course you have to go to the cloud provider and change settings to make All this stuff work if you just don't want to have to worry about that you want something It's totally portable and goes from your bare metal environment to your cloud to somewhere else Then an overlay could be better right so there's pros and cons to everything There's no one right answer But in the case of a lot of these plugins you have choice So we're gonna talk about psyllium for just a second We're gonna use it in the first lab psyllium is a C&I plug-in that gives us options and it is kind of in the in the new generation of C&Is that are trying to leverage eBPF So there's a way to tell the Linux kernel to run little programs And therefore it's very fast because you don't have a user mode component constantly You know messing around with the network traffic and so that's exactly how psyllium works it uses eBPF leverages that and psyllium gives you the ability to use an overlay network so you can tunnel the traffic between the hosts where the Network underneath doesn't see the pod traffic. It just sees host talking or you can route the traffic It's up to you psyllium gives you some flexibility and it is a really cool CNCF project with a bunch of neat features So we're gonna use that as our C&I plug-in and that's gonna give us this now You all have one node right we already have like 400 computers stood up So it would have been 800 and it just keeps going from there So we're gonna do everything on a single node Kubernetes cluster But it's gonna work exactly the same as if you had a hundred nodes and that's the important thing And that's what Kubernetes and CNI brings to the table anyway So if you had two hosts for example the hosts have interfaces and the pods have interfaces and the CNI is the thing That takes care of making sure the traffic can get back and forth. All right cool So we've sort of disambiguated CNI. We've talked about some of the solutions There's lots of other really cool CNI plugins by the way We've is another one that we use a lot at RXM because it's just super easy to install Calico is probably one of the most popular ones out there that a lot of people use as well and the list goes on So there's many many options and they all have different pros and cons But what we're gonna do now is we are going to switch to lab mode and that link I put in the presentation again up here. So you have it on your sheet. You also have it up there, right and There's um, there's a backup link to if you for some reason can't get to github I thought the reason we did the backup link is github got flaky for the me this morning I was like, whoa, you know somebody attacking github that would be terrible And so we put a backup link But I would just use the the github link because if you do you're gonna get a nice Formatted, you know web page that you can just follow and and copy and paste from now one thing I want to mention is in the instructions. It's walking you through all the steps, right? So it says hey do this right and then it says hey do this But some of these things say hey do this and it's specific to your computer right for example if you create a pod through a deployment that pod is gonna have an IP address that is unique To your setup right and another example here pinging an IP right anytime you see an IP you got to ask yourself to question What IP should I be putting in there because it's not the one in the sheet, right? The the lab is an example, and then you're gonna have to make some interpolations usually it'll tell you right? It says right here, you know note, you know There are lots of different machines use your IP address, you know that sort of thing alright, so So yeah, so that's lab step one. It's gonna have you Let me just kind of walk through it real quick you can start right now if you want So open this document up you can read this little top section, and then it walks you through SSHing into the lab system Right it literally explains how to log in to the lab system with SSH if you've never done that before Here's the link that I was mentioning that can give you SSH help if you need that and Here's the link that shows you how to stand up one of these Ubuntu boxes on your own laptop So you can run the labs later if you want to do that Right, so once you've done this it has you install Kubernetes We built a really cool little script that does everything except set up the C&I plug-in So we're just gonna run that that's gonna take a minute or two So start that now if you if you can and then you're gonna see the status of your nodes You're gonna realize you need a C&I plug-in. We're gonna add psyllium. We're gonna play around with it a little bit Then we're gonna poke around under the covers and see how our pods work and how the IP addresses are getting assigned and Really just look at the whole IP space And then we'll clean up at the end and so step two is services. I will indeed Be breaking again for services in a little bit But if you get to the end of this lab and we're not back into the discussion Keep going right drill into the services. It's okay to get ahead because I'm pretty sure you're gonna be behind At some point in this session, so yeah SSH into your lab instance Install Kubernetes set up C&I and then explore the pod network have fun. Holler if you have questions And I am for the people who are virtual and who don't have laptops I'm gonna probably do these steps, you know real quickly on on the overhead so you can just see them All right, let me let me let me look at the time to okay. What are we talking about here? So it is 11 223 so this this one might take a little bit of time. I'm gonna give everybody till say 11 30 and then we'll do a check-in All right, obviously you can use any, you know SSH client you like I'm using mobex term which I love and if you want to use putty There's a PPK up there as well in the keys, and I think it's on the sheet if you need it Hey, Valentin. Hey Valentin. How many we have left? Do we have a lot left? Alright, I just started the kubernetes install on my well. I just grabbed a sheet just like you guys so I mess saged in I'm running the kubernetes install. It's installing Docker first. We're using Docker. That's the runtime Why Docker Docker's a poor choice for production not because Docker isn't amazing Docker is amazing It's just giant and it has all sorts of stuff in it that you don't want in your production environment If you're a developer or if you're experimenting you want Docker because it's awesome It has all sorts of cool tools and features and techniques that you can use for debugging and experimenting and exploring So that's why we use Docker here We just install Docker and then we install the Docker shim which no longer comes with kubernetes So you have to do both steps Docker is getting installed then the Docker shims getting installed Then we're gonna install kubernetes latest, which is 1.23 Might also ask what distribution of kubernetes are we using and the answer is none We're just using upstream kubernetes plain vanilla 100% completely compatible the kubernetes And we're using kubernetes to install it which is the reference installer It's the node installer that runs underneath like cube spray and stuff like that So no special gimmicks in our clusters just the basics and the stuff we add which is gonna be a lot Running this script is the thing that takes the longest so everything else is a lot shorter after this And if you think about it, you know, you're installing an entire kubernetes cluster from nothing. So that's not bad to just Minute or two there just look at my node. It's not ready. It's not ready because I don't have a CNI solution So I'm gonna read on in the lab lab tells me your nodes not ready Now we're gonna install psyllium This is gonna make our node ready. There's three steps here We just you know, I like to do everything kind of old-school so you can see what's happening. We're downloading a tar ball, right? that's the first piece and Then once we've got the tar ball downloaded we have to extract it and That's gonna give us the psyllium CLI So a lot of these, you know, kind of modern projects for kubernetes use the operator pattern where they actually have a maybe a Command line tool and then they run a service in kubernetes that you can interact with which is nice because you can get data And things from it and then that service is responsible for actually deploying the pods that are doing the thing you're trying to do So I have the psyllium CLI installed now I got my version information, but there's no psyllium on my cluster if I go back and do a get node You know still not ready. So I have to tell psyllium to install the CNI plug-in That's the last step here before we are up and running these guys Of course have all sorts of crazy icons in their output, which is cute Of course every time you do one of these things Containers are being downloaded right because Everything runs in containers kubernetes eats its own dog food in so far as it's possible when kubernetes installs things anyway The control plane runs in containers in pods. So you have the scheduler in a pod You have the controller manager in a pod you have the kube proxy in a prod The the node agent the kubic can't run in a pod because it's the thing that creates the pods But beyond that everything's in a pod So now we've got psyllium up and running We can do some things like ask it status All right, this is the nice thing about having a CLI and a control plane We get all sorts of pretty colors and so it looks looks good, right? We have the operator running and we have a single node So we have a single psyllium, you know agent running and if we were running, you know 40 nodes because it's a daemon set It would run on every single node and there'd be 40 of them You only have one node so we only have one of the psyllium plugins All right, and then it just has you look around and explore the network a little bit Make sure traffic is going back and forth Has us run a little pod and verify that we can get to it and do that real quick use the kube kuddle run command which Essentially creates a manifest behind the scenes and applies it to the cluster So this one's gonna create a pod called web with the image HTTP D and defaults for everything else Then we can take a look at this guy Output wide and kube kuddle get pod is gonna show us the IP of the pod And that way we can test it patchy up and running Thank you. It's more exploration goes on. We get a chance to take a look at psyllium config and Just run a couple more of these commands So this is the pool of IP addresses that's gonna be handed out to our pods the lab kind of walks you through the different pools Right, we have the internet where everything goes except some reserved address ranges Then you have your cloud host machines, which are probably using some reserve one of those reserved ranges And then you have the pod network, which is inside that cloud And so these things all need to not conflict right you don't want to conflict with the public IP address because they might Need to reach you or vice versa you could proxy them But and you don't want to conflict with the host IPs that would be confusing and then the pod IP space is also gonna need to be unique When you set up your cluster You can specify the IP range for services as we'll see in a minute But it's the CNI that decides what IP address your pod gets that's why it's set up here in the CNI function So if you wanted a different range, you'd have to tell psyllium when you installed it And if you do a psyllium install minus minus help It'll dump out a gajillion options that you can use and there's also a config that you can set and apply in kind of a more Infrastructure as code approach. All right, and so we test the pod network out do a couple more things and then finally we Clean up at the end Didn't actually create the client But I'm gonna go ahead and just delete the web guy and call it a day here step one done for me You just Do a quick show of hands if you're still working great. How many people have finished with step one though? Okay, great. Let's move on if you're still working. That's great. Don't you know, don't feel slow. You're probably going really fast actually but We're gonna try to keep on the clock here So so give me half an ear while you're keep working if you want to and this is a tutorial it's all about the hands-on so you know if you have a choice between ignoring me and You know doing doing the lab and not ignoring me. I would ignore me So Kubernetes service communications, let's take a look at how Kubernetes thinks about services when you are running pods Let's think about Kubernetes 1.0. Kubernetes 1.0 is for microservices Period end of story. There were no no no real provisions for any kind of stateful workloads Cassandra is not a microservice Right, it is a clustered storage engine where you run many many nodes and it's horizontally scalable and it's absolutely a Cloud-friendly kind of data store, but it's not a microservice microservices are stateless State is hard scaling your Cassandra cluster sizing it doing all those things is hard, but running a microservice is easy and Destroying it when you have seven others shouldn't ripple the waters at all. Nobody should care You get disconnected you reconnect and you end up with one of the other guys and they're all the same That's what microservices are all about and so Kubernetes embraces this and so we can run a whole bunch of copies of our service under a deployment in Kubernetes and then To avoid customers having to worry about the mayhem of pods scaling up and down and getting deleted because a node is Overloaded or whatever we put a service in front of it and that service has a head a Cluster IP a virtual IP address. It's not associated with any interface It's just an IP and when you try to connect to it The Linux kernel has to figure out what to do because that that address isn't associated with anything there's nowhere to send the packets right and so Kubernetes implements the routing functionality the forwarding functionality that makes that all work when you create a service You get a cluster IP and you get the wiring that delivers your connection to one of those back-end pods So how do we make that go? Well, there's a thing called the cube proxy It runs in a pod as a daemon set on every node in the cluster and it's doing that stuff Its job is every time a service is created. So it's watching the API service saying hey Tell me about any services and when a service gets created it immediately goes and tells the Linux kernel do all The stuff right and now the sudden people can reach those pods through those services and when pods come and go That cube proxies watching that too if a pod goes away He takes that pod out of the mesh if a pod shows up and has the right label He adds that pod into the mesh. So the cube proxy is is the magic now How does the cube proxy make this work? Well the slowest way is it can do user mode But this is deprecated and you know But this was used in the early beta days of Kubernetes where the traffic would literally connect to the proxy And then the proxy would make the connection outbound for you So that's no good because now you got a user mode process and your data path is going to be slow So the next thing we can do is use IP tables We just tell the kernel Hey when somebody connects to this IP address use a destination network address translation to one of these pods and A lot of people don't don't know it But you can randomly select a rule in a chain of of rules in IP tables and that's what's happening, right? So if there's 20 services back there, it's just gonna randomly select one of them and then send you to that guy So it's load balancing right it's random but it's load balancing and if pods are coming and going like crazy and one of the pods gets overloaded That pods likely to be evicted and all those connections are gonna break and they're gonna Redistribute immediately because the clients are gonna reconnect If you're talking to a microservice you should expect it to be ephemeral Right note to people writing client code Expect that connection to break don't be surprised by it when it does you just reconnect and you're gonna get distributed to somebody else So the entropy of the cluster naturally distributes the load pretty darn well a lot of people are like, you know Let's use some sophisticated global Rate limit Boba but in at the end of the day try it try the simple stuff first. It's often fastest, right? But if that doesn't work for you, there's other options now one thing that probably is an upgrade is IPvS so the kernel has also another mechanism IP virtual services and It's a little bit a teeny bit faster than IP tables In some situations and a lot faster in some others because it uses a lot of resources That's the main thing tape IP tables were never meant to be you know distributing traffic So IPvS is probably the better option You can tell Q proxy which of these modes you want to use and the default is IP tables So that's the one that we're using in our lab because we didn't tell it to do anything else, right? There are also CNI plug-ins that have fancy features too because ebpf Hey programming the kernel sounds like that would be a way to handle these services to right well It is and it has some benefits So some of the plug-ins let you do that you could replace the Q proxy with this with psyllium if you wanted to and Let it do all that stuff. We didn't tell it to do that again So it didn't but that's an option that's on the table now remember that all of the hosts in Your cloud virtual private cloud right have to have unique addresses if they're gonna talk to each other so all your kubernetes cluster nodes have to have unique addresses and Then all of the pods that run in them have to have unique addresses and since you need to be able to get to the pods from the host in Order to you know do things like check their health and stuff You know those addresses have to be unique right non-overlapping and then the last thing is these service IPs Need to be unique and non-overlapping. So we have three address spaces. We got to think about when we're setting up kubernetes This is part of the architecting a cluster process, right? What are the address ranges we're gonna use for for these things and another interesting thing is the support for IPv4 and IPv6 We're doing everything in IPv4 No for no reason. It's just what happens by default, right? This is the way things work by default but out there on the internet IPv6 Continues to gain steam a lot of companies especially telcos or IPv6 internally everywhere And so there's there's a good momentum towards IPv6 in kubernetes 1.0 It was IPv4 that was the end of the story Next IPv6 only went GA in 118, right? That was a long time later and you had one or the other right not both You could pick one right and this is this is as far as what kubernetes is responsible for so the the cluster IPs Right if you had a CNI plug-in that knew how to do IPv6. Well knock yourself out That's fine, but the services are always going to be IPv4 or IPv6 until 1.20 Where we got either IPv4 or IPv6 in the same cluster Right now you could pick you could have an IPv4 service over here and an IPv6 over here pretty cool But you still couldn't have a dual stack service, right? That was out of bounds until Duna one two three three weeks ago or whatever it was. We now have GA IPv4 IPv6 dual stack So you can pick on a cluster to make a service single stack You can make it prefer dual stack and then you can require dual stack and that means that the the users got to Have both right so those are those are those are pretty cool Features the kubernetes project is really stunning how fast it moves and how much tech is in it when you look at all The different places and how advanced it is so some things are a long time coming that maybe was but hey It's here now Services, how do we create one well in kubernetes you pretty much create everything by Specifying it and giving the specification to kubernetes and kubernetes just spends the rest of its life trying to make the status of the cluster The same as your specifications That's what kubernetes does it makes the status of the cluster the same as your specifications that way you don't have to Constantly get up in the middle of the night and say oh that pod stop. Let me restart it No, you said I want a pod running and if it stops kubernetes restarts it self healing You know all these types of you know automate the toil sre stuff. So this is a service. It's very simple one It has a name web. It has a port 80 The port has a name to in in case you have multiple ports You can use SRV records in DNS to discover which ones are which and stuff and then we have a selector that says hey Any pod that has the label key app value web Gets these this traffic right so if there's a hundred of them You'll have a hundred of those pods getting connections when this service is hit if there's one of them Then that that one will get it if there's none Then you can't connect. There's no such thing as a virtual IP, right? It's a virtual It's just rules in a table or something like that. So if there aren't any pods You're not going to go any further. All right So that's the idea behind a service now all of the pods that match that selector Create something called an endpoint right the the service could push all the pod information That match the service down to all the cube proxies But that'd be very expensive because you can have clusters with thousands and thousands of pods right and so what's better is to just create a little thing that has the IP address and That's about it right an endpoint that identifies the targets that you want and then you send those down to the cube proxy So earlier I said hey the cube proxies watching the pods It's actually looking for endpoints right and so the the service controller is creating the endpoints And then the cube proxies getting those so an endpoint looks like this up here What happens if you create a service that has no selector? That service will never ever identify any pods to send traffic to so you're gonna have to do it And this is something that you might do in a scenario where those pot those those pods aren't pods what if you have 16 vms and Every once in a while some of them shut down and some new ones stand up you could create your own glue to create these endpoints and Because the endpoint is named website We know it's a sub resource of the service website And then it's got an address and the ports just like we you know had before defined on the on the service side And then next thing you know you look at the endpoints for your service and this guy shows up if you apply that endpoint So you can create your own endpoints you can have them produced dynamically by Kubernetes So in general if the you're you know routing to pods you would want them dynamically created now What kinds of services do we have to work with there's a bunch? The first kind is a headless service a headless service has no cluster IP You literally say cluster IP none it actually turns out it's a cluster IP type of service With no cluster IP. I don't know how that works, but anyway You define a headless service by creating a cluster IP service with no cluster IP. What is that good for? It's good for situations where the pods aren't the same What if one of your pods is a Kafka pod and it has the topic? Nasdaq and what if the other of your pods is a Kafka pod and it has on it the topic New York Stock Exchange and another pod has Life and so on right well You can't connect to the life pod if you want to get the New York Stock Exchange data They have identity these pods. They're not microservices So anytime you have a situation where they're not microservices, but you want DNS resolution and stuff like that This is the kind of service you want next cluster IP cluster IP is for microservices, right? Where it just sends the traffic that's the first example. We looked at node port is another one where if if packets are coming in from the outside world And we want them to be delivered to our service We can use a port on every node on every host in the cluster and and have that port forward to our service So that that port is reserved for us in the entire cluster So obviously the the control plane needs to know what port range you want to use and it needs to be in Control of which ports are handed out and so on so we'll look at node port a little bit more later Load balancer is like node port except it also stands up an external load balancer. This requires a plug-in right we have to have some sort of external thing like a You know an Azure load balancer or a Google cloud network load balancer or something You know to interact with or a metal lb as we were looking at earlier and then lastly we have external name This is for scenarios where you have a service name that you want to be resolvable inside your cluster We're gonna look at DNS more in the next module, but you actually want it to Look for some name that's outside your cluster, right? So you're gonna make them a name mapping and you can do that with external name. All right So lab step two we're going to create a deployment which is gonna have several pods. We're gonna create a cluster IP service We're gonna connect to the service see the traffic reach the deployment and come back And then we're gonna figure out how it works. We're gonna get under the covers look at the IP tables poke around a little bit and see How things are happening. Okay, so we are looking at 1147 how is that possible? Okay, let's let's let's give everybody say Eight minutes. We'll come back at 55 minutes after Nothing to install in this session so But there is a lot of stuff to look at so 1155 And we will be coming back Okay, so I'm gonna go ahead and do this Second step for people virtual just so you can get an idea what's happening here And I'll talk through it, but for the people locally you can just ignore me and work on the lab yourself So first thing we're gonna do is we need some pods to connect to so we're gonna create a deployment with three replicas And it's just gonna run the Apache web server. So we do that Okay, cool I can type all right good. We got our three pods up and running now. We're going to go ahead and show the labels on these pods and When you create a deployment Using that imperative technique, which is that's just quick and dirty right normally you'd create a manifest But when you use that technique, you're gonna get a label key app and a value Which is the name of the deployment so I can predict that right? I know I'm gonna have this app website label I don't know what the name of the pods gonna be because they're ephemeral they come and go and their identity list right? I shouldn't care about the name, but I know that they're part of this website, you know package All right, so the next thing I want to do is I want to create a cluster IP service and we're gonna do this This is basically the exact same service. We just looked at in the slides drop that in there Qctl get all doesn't get everything but it gets most of the stuff you care about so I got my three pods I have the replica set under the deployment so the deployment created the replica set for me and Then I've got my service website and it has a cluster IP. So that was handed to me by kubernetes kubernetes decides what that's going to be because kubernetes has the service controller and it also Knows what the range of addresses that you want to use are now if we had used cube ADM with the config file Or didn't give into the right command line parameters. We get to change that to use something else if we wanted to All right, so I'm gonna curl that and it works But I have no idea which pod I hit and I don't care. They're all the same. They're replicas. That's the point All right, so there's some other good stuff in here and then the next thing that we're gonna do is We're gonna look for The range that kubernetes is using so this is that service controller IP range, right? That's where the The the IP addresses are coming from for these services. So it's a 1096 stroke 12 is what the default is you could change it Okay A little bit more poking around and now we're gonna look at some end points. So let's take a look at the end points for the website And we can see there's three of them right 1015 10154 and 1054 and Remember they're always gonna have the same You know first three octets because the hosts are subnetted at 24 bits And then the overall space is eight bits. We saw that in CNI So these are CNI controlled right by psyllium and then the service IP the cluster IP is controlled by kubernetes Because it's the service controller piece All right good See what else we got here So the next thing we're gonna do is try to figure out how this all works So we're gonna look into the IP tables and we're gonna look for the cluster IP Obviously, I can't use the one from the lab I have to use the one that I got which is potentially very different Service IPs aren't doled out sequentially because then you could predict what the next one would be and that leaves you open to some security issues So they're randomly selected from the range All right, so I can see that there's an IP Tables rule that says if TCP traffic comes from anywhere and goes to that address on TCP port 80 Use that chain to figure out what happens. So the next thing I need to do is I need to update my grep To look at the chain called this and and so that that is pointing us at our service and You can see here. This guy says all right Destination IP 80 There we go. And so those are the three pods that we saw In our deployment and you can see if you look at the packet counts You can of course tell which one you hit when you did your curl, right? It's this bottom guy as it turns out So it's just random probability 33% when there's three of them 50% when there's two of them And then the last one's the default and so this is the guy that got hit And so if I look for the pod that's 10 dot 0 dot 0 dot 54 and I look at that guy's logs Right, so this is 54 down here So let's look at the logs of this guy We'll see a bunch of stuff, but there's the hit All right, that was our curl and then if we do the same thing and look at logs For anybody with the label app Website oh, wow, we can see that there are no hits anywhere in here except this one from our curl So all three of the other pods right this guy no hits this guy no hits this guy got a hit So the service is working right IP tables are solving the problem of randomly distributing traffic to our pods on the back end There's a little bit more exploration that goes on there But that brings us down to the bottom section where we get to delete some things and see how stuff works So for example, I'm just gonna pick one of these guys at random and delete it and a bunch of things happen when you do this number one the curl keeps working and You never even see any hesitation and the reason is that the service proxy has taken the deleted pod out of the mesh and of course What also happens is that kubernetes immediately realizes that there aren't three pods anymore and Since the replica set and the deployment were set to have three it creates a brand new one. It's not the same pod Right that guy if you look at the IP Right not the same pod All right, this guy is 1 34 and he's been Running for 31 seconds versus the other guys, which are seven minutes. So the mesh is dynamic, right? It's Taking advantage of this dynamic environment and automatically updating all of the routing or forwarding necessary to make things go All right, so let's let's move on And keep in mind if you're if you're done with two before I move on feel free to move on yourself All right, so kubernetes DNS. Let's talk about DNS briefly and How kubernetes implements it if you're still working on lab to keep working just lend me half an ear So DNS and kubernetes there are three files that your containers get that come from the container runtime Not from your pot your image your container image They're always Overlaid by the container runtime and the reason is if you take a HTTP container and you run it in Singapore It's going to get one IP if you run it in London. It's going to get another IP So how could you possibly create an Etsy host file with the correct information? Right since it should have your IP and your host name in there How could you possibly create a host name file with the correct information since the name of your host when you're a pod is The name of your pod and that's dynamically being created So you don't even know what it's going to be and then the final thing is resolve.com Every kubernetes cluster runs core DNS By default some distros change it and use something else and some distros configure core DNS in different ways But there is a DNS server built into kubernetes And when you use the reference installer kubernetes you get core DNS Which is another CNCF project one of the earliest ones and so core DNS will automatically Resolve service names Inside your cluster to their virtual IPs so that you can just use names instead of IPs, which is great But that means those three files have to be correctly configured And so it's the cubelet that understands your kubernetes environment and sets these files up so that your pod works And so you have you know Core DNS running in the cube system namespace as you can see up here We have two pods core DNS pods So if one of them crashes we have resilience, right kubernetes eats its own dog food core DNS runs in a deployment and then there's a service also that gives us a cluster IP for DNS inside kubernetes, and it's 10 dot 96 dot 0 dot 10 That's the default IP for DNS and it's going to be injected into every single pod in resolve.conf Because when your pod tries to look up a name it needs to go to core DNS to find the IP of that service Right, we don't generally look at pods Right there ephemeral there there's there we don't care about them We care about the API that we're trying to consume right the interface not the implementation and so That's a quick look at core DNS and how it's set up and what it does and then If you want to think about DNS inside a cluster number one You might have many clusters so you can give every single cluster its own suffix right cluster dot locals the default And so you get cluster dot local in the example. We're gonna look at next There's the service bucket where services live. There's some other buckets But this is the most important one and then name spaces are a thing in kubernetes, right? If I want dev and production if I want team a and team b if I want You know blue green whatever different name spaces are isolated from each other And so if you create a service called Fred and I try to create one and I get an error That's gonna be confusing right if you're in completely different departments in context And we don't even normally talk to each other that's gonna be a big problem So name spaces give you the ability to create any name you want which means the DNS has to be isolated And so the name space is in the DNS name and then finally you have the name of the service itself So an example of a realistic production DNS name for a service in kubernetes might be web if your service is called web production if your name space is called production dot svc and then Kate's 54.Rx-m.com if that's the suffix you gave that cluster and so you can see with this kind of a unique name I could actually reach a service in a completely different cluster Right I could give the name of the service the name space in the cluster the Svc and then the cluster suffix and as long as my networking normal You know computer networking infrastructure knows how to deliver that packet to that cluster. We've got connectivity So headless services are another thing we mentioned if you say cluster IP none You'll get a headless service. Well, what happens in a headless service in a headless service You don't want the cluster IP. You don't want to look that up because it's no good, right? You don't want to randomly go somewhere if I want New York data I have to talk to that Kafka node if I want life data. I got to talk to that Kafka node So in a headless service You get the actual IPs of all of the nodes or all the pods when you look up the service name So it's not just one IP of the head of the cluster IP You're gonna get all the pod IPs together The other thing that is important is that there's a special controller for stateful pods call the stateful set and It creates pods with Deterministic names with identity with persistent identity if this pod which is let's call let's call it web 7 Gets evicted from a computer We won't get web 58 over here. We'll get web 7 again over here might have a different IP But the name will be the same so if you create a stateful set of redis The pods will be called redis 0 redis 1 redis 2 with an ordinal as they get created So you can predict the name and that name will be persistent It won't go away in other words the Kafka guy that's servicing the Nasdaq market data When it crashes it's gonna fire back up over here And it's gonna still be Kafka 7 with the Nasdaq data and the volume it was using is gonna chase it If it's network attachable, so that's what we want in a staple set and so if I need to look up Kafka 7 I don't want to fix myself on the IP What if he gets punted to a new machine and gets a different IP? I want to use the DNS name, right? I want to be abstract from the machinery of the networking and so I could say hey redis 1 dot redis dot Data in s which is my namespace Service cluster local. Let's say that's the guy who has the Nasdaq data Then I would just connect to that guy every time and I would always get the Nasdaq data So that's what ahead the service brings to the table it creates this DNS structure for Stateful pods and generally that's why you use ahead the service when you have stateful pods So overriding the DNS is also possible What if you're an administrator and you have to run a pod and that pod needs to talk to an external DNS system You don't want it going to the internal one you want to go into the external one You can set up your resolve.com as custom as you like a resolve.com is generally gonna have a name server to connect to Searches so suffixes that you would add right if I look for web. It's gonna work Why because there's a suffix in there that is gonna specify my namespace dot service dot whatever my cluster suffix is I can just look up the service and it works if I want to look up a service in another name space I can just say service dot of the namespace and it will work because there's multiple search paths, right for each piece of the DNS name and then finally you have options that you can set So this is if you're if you're not a DNS guru you can ignore this But basically these are the ways that you can override what's in the resolve.com. So step three playing around with DNS Let's give everybody Let's say until 10 after to work through that Seven minutes Again, go ahead and work on your own I'm just gonna for the virtual folks and for people who don't have a laptop. I'll just give you a preview here So let's see. Did I clean up after myself last time? I Did not let me go ahead and do that So I'm gonna could'll delete some stuff real quick. All right, so on the DNS side We're gonna create a deployment again, and then we're gonna expose it. This is a cheeky way to create a service All right, it creates a service that's wired to that deployment so it figures out what labels to use automatically and Now I'm going to run a client and we're gonna look around it How we can resolve the name? instead of the IP So busy box image has to download we'll let it do that and the idea is let's just try first to W There's no curl in busy box So we'll W get the website and we're gonna this is DNS, right? I'm saying hey look up website. I Mean, how does that work right? How does that work? It works, but how does it work? Well, let's take a look at the DNS machinery right the first thing that we would want to do is look at the resolve calm right whenever your resolver the part of the Linux library or the you know the G libc or whatever it is. It's doing your resolution. It's probably going to a cache If it doesn't see the name there, then it's looking in your Etsy hosts If it doesn't see the name there, then it's going to DNS. So where does it find the DNS server? Well, there you go My resolve calm recognize that IP? It's 10.96.0.1. That's our core DNS service. It's the cluster IP of our core DNS Kubernetes eats its own dog food then look at the search stuff fixes I'm in the default namespace on cluster.local so when you Make the name right if you if you fully qualify it and you say dot default dot service Dot cluster dot local Right, that's what's happening right we're just adding that search suffix and it's a fully qualified name It won't conflict with Website services in other namespaces. What if I want to get to a website service in another namespace? Well, you can Right, you can simply say website Dot prod let's say now that's not going to work because I don't have a prod namespace But you can see it doesn't work right it it would have worked if it was in default But you said go look in prod and there isn't one there and so Notice that this guy was resolving with service dot cluster dot local the second search Right suffix and then we have cluster.local and then whatever gets inherited from the host machines All right, cool, so we can we now have the idea like how the pod side of it's working right and It's gonna exit out of this guy And if we do a cube CTL get all in the namespace Cube system, you know, there's the machinery right in cube system. We have the core DNS Deployment with two pods and we have our replica set and we have the two pods up there, and then there's the core DNS service So those are the pieces of the puzzle All right, and the lab goes on and it has you play around a little bit with some of this stuff Then it has you create a headless service Got a couple minutes. I might do that real quick So I'm gonna go ahead and create this headless service the special thing about the headless service over a normal service Is that it has no cluster IP? And so you can see at the bottom here cluster IP none and then the lab has us Take a look at the cluster IP service We see that he's got no cluster IP and then we're gonna jump back into that pod And we're gonna do some NS lookups to see what kind of DNS trouble we can get into so I'm gonna cube CTL attach My input stream to what was it called client? Client there we go. Okay, and so let's go ahead and try that NS lookup on headless website that we just created And you can see I don't get back a single IP. I get back all of them. There's three pods I get all three of them and Some DNS errors, but you get the idea right so we did it the lookup worked We got the three pods and you can see that these these these three pods They don't have unique identity. They're created by a deployment. They have random names So we just hey here are the IP addresses if you want to connect to one you can But the idea then is to take this to the next level where we put the headless service on top of a Staple set so that's this guy down here note that a YAML file can have multiple YAML documents And that's exactly what's going on in here. We have the first part as our service, right? So that's just the the Service without the cluster IP right the headless service and then this is the staple set We're saying hey, you know, we're gonna pretend that these engine X guys are actually Stateful, they're not but it's all right and now let's Cube CTO apply minus F That guy Now what we can see is we have the We've got this new staple set called web state All right, and that web state has created a pod web state zero So the pod gets the name of the staple set plus an ordinal and if I cube CTL scale Stateful set Web state to Replicas equal three you got to spell it right Fortunately, there's a shortcut. All right, so that's scaled Now there we go right zero one and two so if we go back up and attach again To our previous guy and then we NS look up Web state Let's let's just do that you can see that we get the look up as always Right web state is in fact a service, but now what we can do is we can ask for a different kind of query You can ask for an SRV query equal There we go, and you can see that over here web state zero one and two so we can identify these guys now by their actual names and if we try to for example curl a specific one of them We could say web state. I want to talk to specifically the NASDAQ guy, right? Because I don't I don't I don't want them the New York Stock Exchange data I want the the NASDAQ guy, and he's number one And curls not found so I use W get and there you go right we hit the engine X guy there So that's that's DNS in its various flavors in Kubernetes Right, and of course, I mean as you guys know there's there's a lot more to know But the lab does start you down the road Hopefully is you know pulling away the veil on some of the more confusing bits and the things that aren't obvious When you start off All right, so let's move into our next section accessing services from the outside How do we get from the outside in keep working on the labs if you want? Let me in here So outside access can be performed in lots of ways at the end of the day There's host port and node port and a lot of stuff on top of them host port and node port handle 99.99% of the traffic flowing into a cluster one of those two techniques So what does a host port do? It's not a service in a pod you can say Take this port on the host and map it to the pods Listening port right and that will work the problem with that is it's not very Friendly to the cluster right if you want to map port 80 on the host I mean good luck What if none of the hosts have port 80 open your pod can't run anywhere? So it's not a great solution for your users for us developers who are trying to deploy apps, right? You don't want to use a host port. It's for administrators, right? If I'm running, you know SSH in a pod. Well, yeah, I wanted to listen on 22 So I might host port that or something For diagnostics or testing, but it's not for general use for users, right? what what users should be using is a node port a node ports a service and It's a cluster IP You get a cluster IP, right? It's like an inheritance hierarchy, right? Cluster IP is the base class and and node port is a derived class all the cluster IP stuff you get plus a Port is selected from the node port range like let's say 310 right three three zero zero one zero so thirty thousand ten I guess and that's your port and Every single host computer will now take traffic on that port and forward it to your service So if you set up for example a load balancer In front of all the nodes in your cluster and direct traffic to that port You will be reaching your service and that's exactly what a load balancer service does So the inheritance hierarchy continues cluster IP Node port load balancer the node balancer load balancer is the most derived, right? It is a node port and it is a cluster IP. So inside the cluster you can use the cluster IP. That's best It's DNS resolvable. It's gonna load balance you. It's fast Then node port that's one hop right you go right to the pod node port is two hops right because you have to first hit the port on the host and Somebody's got to forward your traffic to the next hop, right? There are scenarios where you can have actually a user mode proxy like cube cube proxy and some versions of Kubernetes We'll actually listen on all the node ports and forward the traffic in other cases It's handled by the kernel the ebpf and stuff like that But then ultimately your traffic ends up being delivered to the pod and the pods probably not on that computer Right unless you know specifically what if there's a hundred computers in the cluster and you're running five pods You're only running on five percent of the nodes if you pick a host and hit the node port chances are your pods Not on that node so you're gonna have two hops right you're gonna hit the host And then it's gonna have to forward your traffic over to the machine that has the pod right and then load balancer three hops The load balancer there's no load balancers built into Kubernetes. You have to have a plug-in that stands one up for you So metal LB can be stood up and use it BGP to create advertise a virtual IP that goes to the node port or something like that You can also Use things like you know the load balancers for your cloud providers and you know F5 has one There's all sorts of load balancers out there that will plug in but you got to do it Right kubernetes is not opinionated you pick your load balancer and then when you set up your service it it You know creates the event and then if somebody wants to do something with it They can't in our cluster when you create a load balancer. It's gonna be Pending you're never gonna get the external IP of the load balancer because there's no plug-in installed And so load balancers three hops you hit the load balancer, which is a thing a real device or a logical thing right and then it hits the node port on one of the machines and then Third hop is back to the pod. So it's a hierarchy and each one's more expensive So, you know you got to decide what you want to do load balancers are nice because that you can give them a DNS name out On the internet for example, and you might have a hardware, you know replication of them There might be like seven of them so if one fails, you know ha and all that so load balancers are good for external access To but they're based on node ports typically they get into the cluster through a node port And then you have ingress an ingress is a controller that runs in your cluster typically Has a load balancer or a node port service in front of it But the thing about an ingress controller is what if I have five services? Do you want to tell your iPhone? Developers oh if you want that you connect over to here And if you want that you connect over to here and then oh this part of the API is actually hosted over here Not really right Micro-services shouldn't be exposed outside of the context within which you're developing them the external API deals with different language different different semantics different Bandwidths right the internet is flaky and low bandwidth your data center is going to be fast and reliable They're very different worlds the ingress controller can create kind of like a firewall an adapter from the outside world to the inside world You could have two services or eight and then you could say hey if somebody has hits slash Engine send them over here if they hit slash web send them over there And so an ingress controller gets rules that tell it how to send the traffic inside the cluster to the different services that are on The inside so you might have a bunch of your little micro services with cluster IPs only You don't want them accessed from the outside and then you have an ingress controller that provides your public interface And it sends all the traffic to those guys behind the scenes And it's the ingress controller that has a load balancer service in front of it and only the ingress controller It's the one-way in right so you might create node ports on the fly to test things into experiment if you're on the inside But the outside world never sees those. What's a gateway? A gateway is a more powerful ingress controller ingress is a thing in Kubernetes It's a defined framework again Kubernetes doesn't provide one you have to install one and we're going to use ambassador Oh, sorry emissary used to be called ambassador And so we're going to use emissary for that. Well, guess what emissary does the Kubernetes ingress framework But in emissary is crazy powerful and has tons of other features. It can inject headers It can do, you know fault stuff for chaos, you know Operations it could do all sorts of things and so it's a gateway It's a super powerful way to provide a single place where all your traffic can come in it can do, you know security stuff Obviously TLS is even part of ingress, but it can do some more advanced security thing So it's a very very powerful tool, right? So this is an example of host port right where you have host port in the pod spec and then the container port and if there's No host with that port open your pods pending forever until that port is available somewhere, right? So not a not a great thing for developers or users more for operators That's a node port you just ask for type node port and then you can ask for the port that you want But if you if it's in use you'll get an error if you leave the node port off Kubernetes will assign you one from the range Just like with the cluster IP as we saw and then this is a load balancer, right? You just say type load balancer. That's it right in this case. This guy has two ports right HTTP and HTTPS Which is kind of common and then you've got ingress. This is an ingress rule This ingress rule says hey if somebody hits the ingress controller using the HTTP protocol By the way ingress only supports HTTP and HTTPS and they are using the route slash engine as their prefix could be anything after that Then send them to the back-end service called engine. That's the name of the service DNS resolved on port 80 Right very simple and you can the developers can create these rules. I My DevOps team can deploy the can provide the deployment that runs my pods The service that lets people inside the cluster get to them and the ingress rule that allows traffic from the outside to route in now Obviously, I got to coordinate with the other people so we don't have overlapping routes and stuff But that's the idea right let those teams be independent And then the last thing is the gateway. This is an example of configuring a gateway. That's a custom resource definition It's not part of Kubernetes But Kubernetes gives you the ability to create your own resource definitions like this one And this one gives you the ability then to do things like inject headers and fancy stuff like you know control the maximum connections none of that's supported in ingress, but Emissaries super powerful and has all these kind of advanced features so we would call it typically a gateway It also supports protocols that the ingress controller doesn't support ingress only HTTP and HTTPS if you want STP or UDP you're gonna need a gateway and So lab step 4 walks you through installing emissary and Doing some ingress and some gateway stuff so you get a chance to work with the CRDs that emissary installs and The ingress controller standard Kubernetes stuff. Why would you use ingress if gateways are so much more powerful? Well those specs I just showed you those custom resource definitions are emissary custom resource definitions if you later switch to something else They're not gonna work, but ingress is a Kubernetes framework standard. It's gonna work everywhere The engine x ingress controller will take them the emissary will take them So if you can get away with just using ingress, it's portable, right? Not a bad thing So you have to decide what you need Alright, what I'm gonna do is cover service mesh because we got a little bit of time left If you want to start on the emissary lab go for it But I'm gonna cover service mesh real quick and I tell you what We'll leave these boxes up for another hour or two So if you didn't get through all the labs you'll have some time there and then you know probably like after lunch We'll shut them down. Let's say that way. So if you want to work through lunch, you can So let's let's hit the service mesh stuff service mesh functionality. I mean we've got all this functionality built into Kubernetes We've got the CNI. We've got services. We've got ingress and now these gateways And there's just so much power and capability from a networking standpoint And there is complexity, but you know when you start poking around and looking at it in the labs here You realize that you know, it's manageable, but what's left, right? Well, if you're a developer and Your boss is hammering on you about security security security Do you really want to go back and instrument every single service you wrote with mutual TLS and How likely are you to get that right? anyway, right and Then you're gonna be now you got another thing to debug and to manage right that alone right there as a killer Right and then as soon as you do it now all your customers are broken They got to implement, you know on their side the mutual TLS stuff. That's a pain You know in Java or C++ or go or rust or whatever. Well, wouldn't it be amazing if you could just flip a switch and Inject a proxy into every pod that did the mutual TLS Automatically for every single outbound connection and on the other side for everything that comes in That would be amazing and wouldn't it be amazing if those pods so that you didn't have to Reported telemetry that says I'm connecting at this moment in time. I've been connected for this period of time Oh, I'm seeing these errors come back and just reported that all to a central Repository that you could open up in Prometheus and chart and look at and set alerts on That would be amazing and that's why service meshes are amazing. Those are the things that they do They give you MTLS for free communication metrics for free communication policy You can't talk to that guy, but you can't talk to this guy and you can't talk to that guy on Friday You know or whatever policy Traces fault injection chaos support advanced traffic management. This is what service mesh brings to the table and there are a bunch of them to choose from There are proxy based service meshes. So this is the the long-standing Group right your your Lincordies and Istio's and open service meshes and so on and so forth And so those guys are well understood They're also nice because they operate in the pod sphere They're not messing around in the in the kernel or you know down at the host level And this means that the second your traffic leaves your pod It's encrypted and so that's nice, right if you're running some sensitive workloads Who's who are the administrators on those computers, right? so there's some really nice things about having a proxy based solution and Then the other thing that's also nice about that is that that you know, it's it's not in your software You can upgrade the proxy without messing with your software, right? They have different, you know life cycles and stuff Then you have ebpf based so this is a little bit bleeding edge There's some really awesome stuff in the the hopper there But there's some downsides too and the the biggest thing is that I don't think you're gonna see a lot of GA ebpf Service mesh implementations at this moment soon, but it's a it's a little early days there Silium for example and others can provide that kind of functionality and then library based What if you're using gRPC everywhere? Well gRPC could do the TLS for you in its gRPC library, right? If you're using it on both sides then you could flip that on and gRPC just I think went GA with their You know proxy list service mesh and so you could use the control plane of a standard service mesh to talk to your gRPC libraries and Tell them to do what they need to do to do the service mesh stuff and now you don't have a proxy So the proxy does add some latency, right? So that's why the people who build their proxies build them to be crazy fast linker D Which is what we're gonna use is super awesome and has a rust-based proxy So compiled down to super compact fast native code and in linker D It's kind of famous for being the fastest of the service of the proxy based service mesh is out there And it's also super easy to install and works really great So the last lab which I know there's no slide lab 5 is Gonna have you install linker D and then start looking at some of the metrics See how you can see connections and see them that they're secured and it's really an amazing thing to see and it's so easy To to try out so one of the shorter lab steps So what I am going to do is say thank you a ton for coming We do have another few minutes if you want to hang out to the bottom of the hour But I think they will kick us out in like three minutes So feel free to keep working on the lab up until the last if you want to or work on it for lunch We'll leave the boxes up for a bit and and yeah, thanks a bunch for coming to have a wonderful rest of your convention