scale.bythebay.io: Alexandre Bergeron, Building systems on top of Kubernetes
Recording: scale.bythebay.io: Alexandre Bergeron, Building systems on top of Kubernetes
thank you very much well my name is Alex I'm a software engineer at Terminal data lab where we are building a data science platform that allows dinner scientists to have a system of record work yet they can build an execute and personalize their different models which means in some ways that free yellow data scientists to run arbitrary pattern and are killed on the kubernetes clusters so using kubernetes to deploy things at runtime is kind of interesting and even if it's a skillet talk it's going to be kind of more of object-oriented and less constant skill attack than what is happening at the functional room like during this conference so all right I'm just going to start by introducing some of the base concepts for kubernetes and talk really quickly like just give you enough information about our networking work works on communities to select we can rien DUP being able to write every app pretty simple pretty basic reverse proxy and kubernetes please don't use what I'm doing in production there are better services like traffic and linker D that does that in a way that is actually sound to use in production so all right so first the basic concept on communities is called a pod so basically kubernetes as a container orchestration system allows you to run any darker container over a given cluster but these containers gets packaged in what is called a pod which is kind of equivalent to having one physical machine with your darker containers running on the same machine you can have multiple pods running on the same community's node but only the containers that are running inside of the same pod are guaranteed to be able to see each other as if they were running on the same machine so you could have two pods running on the same machine and they're not necessarily able to talk to each other as if there were running on the same machine so to a little documentation of how to communicate with pods that are all stood on a kubernetes that worked there is this concept called a service which basically describes a contract to communicate with these given parts so basically these sets of parts at respects this multiple patterns exposes a survey web service on part 80 and from that communities will be able to create what it's called endpoints which are IP addresses that allows you to address each individual part described by that given service at that different port which kind of allows you to handle networking over that there are different kinds of part for the sake of simplicity that I'm just going to mention two of them by default every service our cluster IP is which means that you can't access them outside of a kubernetes cluster you can but you'll also create some load port services which exposes what is called an old port which is a randomly assigned port and it will be open on all communities nodes so you can access your service from outside of kubernetes and that is pretty practical but assuming that you might want to have multiple different macro services running on kubernetes at the same time while having only one actual service serving all of your external traffic and being exposed to the outside world you need something to describe how to access every driven service based on some routing rules and so there's this concept called some ingress resources that basically are simple descriptions of routing rules there are different types I'm just going to use some pad based running for my presentation which busy describe one path slash users redirect all traffic to your user services but you can also do some routing over the URL but then that means that you need to end all DNS and I only 20 minutes so I don't want to get too deep into DNS for for a sake of representation so that's pretty much all basically these concepts I'm going to use for a sake of my presentation there are a lot more but I don't think it will be really useful just to get started to write my reverse proxy however I think it's there's are some parts of communities networking that needs to be addressed to understand how it all works so continuing that kubernetes will run darker on many different nodes that are different physical machines you do need to have a networking layer that will emulate having all of these parts as if parts running on the same machine are are not actually running on the same machine well but all of your parts running over your cluster can be access to each other as if they add their own individual IP address so it uses what we call some application networking layers like flat flannel and calico that basically handles assigning IP addresses and handling all of your networking and IP tables rules to ensure that everything remains accessible and what this means is that each part will have their own unique IP address each part that is represented by a service will also gets its own IP address to paying that particular end point for that service and ultimately if you want to get these IP addresses dynamically well you ultimately will need to call kubernetes which is really important if you're writing let's say a reverse proxy if you're writing something that is more static and want to have something easier there is this service called tube DNS which handles this abstraction so basically what it does is that it for every part and every services that are described on your communities cluster you will have some DNS addresses that describes how to access them four paths you can it will be its IP address its communities namespace that cluster that loco definitely you won't even know really what is your part I P when you're running your application so typically this is where you would really want to take a look at the service at a way to access the service which is series name that namespace that SVC cluster local and continuing that we're writing a reverse proxy it if I wanted to make things optimal I would take a look at all to have each endpoint and now to load balanced or these endpoints I have twenty minutes in front of me so I basically just decided to use cube DNS to simplify my codebase so yeah my busy what it means to write a reverse proxy based on these simple concepts is that real we will have a service running on kubernetes exposed to a node part that will what every updates that are done to ingress resources on kubernetes and update its local running rules everything will be wrapped in an HP service I use Finn's because it's a nice is to be later in Scala and we're at Twitter so I think it's nice to use something that users can haggle in the backend and ultimately when we know when we receive a request for particular service in there is an ingress resource that describes how to access that we just redirect the traffic to the correct service implementation and I'm going to give you a quick demo of how it looks like can you see it alright so just for the sake of it I've got a humanities cluster running with my reverse proxy literally named proxy but in the reverse order so it is running there's nothing else there's an there's no ingress is running right now it's pretty basic just to give a quick demo of the code base I'm using a library written by fabricate which is a Java system to interact with like kubernetes and OpenShift luster clusters there's no naturally any good scholar client for twenties right now so you do need to indulge using as general library routes it can be impractical at times so basically the only thing I'm really doing to know which are the ingresses being pushed on kubernetes right now is to set up what we call a community's water and to register it to the ingress resources so basically I have my credit line that wraps that Java client and I at line 21 I'm registering the new what the water that I'm defining which basically will be called every time it we receive a new action over a particular kubernetes concept in this case it will be ingresses and just keep things simple I'm just pushing that new ingress rules overriding previous ingress rules every time I'm every time I'm receiving and you value and basically what it means when I'm ending my routes is that I'm yeah if there's already if I were you everything rest if that ingress already exists I just override it in writing this doesn't exist then I just add it to my list and I forgot to implement delete that's totally on me otherwise I'm just keeping a list of what are my children ingress is for that reason of the rods my night manager and what paths maps to different community services so basically this means that I'm just iterating over my ingresses extracting its different true rules taking a look at the pattern second rule and I'm just mapping that but to a given service and when we're worrying that we're just mapping over the head of the pad to see if we have any ingress defining I'll to access that given pad and then we return the right community service there's not nothing more it's pretty simple and it I was asked to when we have nothing running there when we're calling kubernetes and node port for that for my proxy I'm getting a huge service not found for Pat hello which is exactly the error that we're seeing at line 15 and they think this works great except that I'm not doing anything that is actually protocol practical right now so for the sake of actually Des Moines something that is complete I'm going to deploy a new service which is just a simple in the next cluster that will always return hello Scala by the bay as text as I said this defines a service argument can make it not an old port just to make things more complicated for me so yeah it maps this service as I was saying world map every part running with label hello application hello and I'm creating my parts to what we call communities deployment which answers as there's always a certain numbers of reptiles running by default one and I'm defining an ingress to access that ll service that when we paying Pat hello will be redirecting traffic to the service health service so let's create that these resources everything gets created you can get my ingress rules I've got ello ingress created I can get my pods I've got my reverse proxy and my dip deployment running and when I run that same query I get ll skele by the way and this is why my second most complex in the world I've ever done yeah that's all add for you you have any questions I implemented a hello world using macro iske recursive sieves are interesting this is why I decided to do a talk on kubernetes and not recursion seems I'm not at this point yet yeah that that's the whole point of using ingresses and watching over the values of ingress so you don't have to restart your reverse proxy and yet you're running rules updated dynamically up-to-date yeah [Applause]