Bare metal to the cloud
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 57 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/54480 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Point cloudCartesian coordinate systemWorkload2 (number)BitPoint cloudComputer animationLecture/Conference
00:25
Point cloudSoftwareComputer-generated imageryDemosceneScheduling (computing)TwitterEmailPhysical systemData managementObject (grammar)Run time (program lifecycle phase)Instance (computer science)Integrated development environmentDefault (computer science)DecimalCASE <Informatik>Computer fileHypothesisMereologyProduct (business)Software testingGradientSoftware engineeringFocus (optics)Computer clusterNavigationStapeldateiBootingReal numberInstance (computer science)Medical imagingRoutingDefault (computer science)Interface (computing)Integrated development environmentChord (peer-to-peer)SoftwareGenderWordDemonData managementProcess (computing)InformationMultiplication signVirtual machineConnectivity (graph theory)Demo (music)Cartesian coordinate systemPhysical systemPoint cloudDifferent (Kate Ryan album)Software developerObject (grammar)Run time (program lifecycle phase)Scheduling (computing)BitSystem administratorWorkloadXMLUML
05:27
AliasingOpen setArmMedical imagingMaxima and minimaScheduling (computing)Software maintenanceProcess (computing)CASE <Informatik>WorkloadCartesian coordinate systemArithmetic meanDefault (computer science)AdditionDemonRepresentational state transferSlide ruleLine (geometry)Bit2 (number)Wrapper (data mining)Scripting languagePoint (geometry)State of matterRepository (publishing)Configuration spaceJava appletComputer fileDirectory serviceOcean currentReal numberQueue (abstract data type)
09:25
Point cloudSoftwareScheduling (computing)TwitterEmailPhysical systemData managementComputer-generated imageryRun time (program lifecycle phase)Instance (computer science)Integrated development environmentDefault (computer science)Operator (mathematics)Game controllerService (economics)Block (periodic table)BuildingProcess (computing)Data storage deviceComputer networkLoop (music)MultiplicationDemonGame controllerInstance (computer science)Medical imagingCartesian coordinate systemData storage deviceVideo game consoleComputer architectureConnectivity (graph theory)MereologyServer (computing)Configuration space2 (number)DemonSystem callCASE <Informatik>Template (C++)Complete metric spaceArmMobile appPoint (geometry)Service (economics)BootingArithmetic meanMessage passingLocal ringDirectory serviceScheduling (computing)Block (periodic table)AbstractionSoftwareLogicSet (mathematics)Directed graphWeb 2.0DatabasePhysical systemPoint cloudPublic-key cryptographyEncapsulation (object-oriented programming)IP addressInterface (computing)Multitier architectureComplex numberData managementAddress spaceMultiplication signOpen sourceKey (cryptography)Process (computing)BuildingXMLUMLProgram flowchartComputer animation
16:24
DemosceneIntegrated development environmentCubeMessage passingServer (computing)System administratorIntegrated development environmentShared memorySemiconductor memoryArmDirect numerical simulationMereologyDemo (music)Cache (computing)Game controllerDemonScaling (geometry)Set (mathematics)Natural numberCASE <Informatik>Service (economics)Volume (thermodynamics)Data storage deviceDifferent (Kate Ryan album)Identity managementGoodness of fitNumberVirtual machineQueue (abstract data type)State of matterComputer animationDiagram
19:51
Channel capacityData storage deviceTemplate (C++)CountingKey (cryptography)QuicksortSemiconductor memoryAsynchronous Transfer ModeCASE <Informatik>Different (Kate Ryan album)Game controllerMultiplication signMedical imagingCartesian coordinate systemMessage passingIntegrated development environmentDirectory serviceVolume (thermodynamics)Data storage deviceDemonSystem administratorMereologyConfiguration spaceComputer fileLine (geometry)Revision control2 (number)WorkloadPoint cloudNamespaceSocial classSheaf (mathematics)Channel capacityDirection (geometry)Variable (mathematics)Type theoryServer (computing)Musical ensembleDependent and independent variablesLatent heatBooting1 (number)Reading (process)WritingComputer animationLecture/Conference
25:50
AdditionVolumeTemplate (C++)RepetitionQueue (abstract data type)Different (Kate Ryan album)State of matterDemonSoftware developerSet (mathematics)MereologyVolume (thermodynamics)Integrated development environmentBootingVariable (mathematics)Directory serviceNamespaceProduct (business)Game controller2 (number)Line (geometry)Message passingScripting languageService (economics)Computer fileHookingCubeMusical ensembleRepetitionSource code
31:50
Cartesian closed categoryEvent horizonHypermediaLecture/ConferenceComputer animation
Transcript: English(auto-generated)
00:08
So welcome, everybody. So I will talk about how to bring your application or your workload from bare metal to the cloud. So I'm pretty lucky that at least a couple of people joined.
00:22
So a couple of seconds. Only one guy was here. So I was a bit afraid if nobody will come. This will be the agenda of my talk. So I will do a short introduction, which in the end means who am I, what's my background of that topic. I will give you really just a couple of words how to dockerize your application, how you
00:45
can bring your Docker image into the cloud, which means in my case to Kubernetes. At the end, we will do a short demo, yeah, so you will see how to generate all these
01:01
files and how to bring that in a running Kubernetes cluster. And as always, question and answers. Who am I? So my name is Stefan Haas. I'm a senior software engineer at Univa Corporation. This is a small American company. So I'm a former SUSE employee, but this is meanwhile nine years ago, so I wrote
01:23
my diploma thesis in the YaaS team back then. After that, I started to work for Sun Microsystems, later for Oracle, and I was part of the development team for GridEngine.
01:41
This is meanwhile the main product of my current company, and the GridEngine will be the test object for this talk, so we will try to containerize GridEngine and bring that into the Kubernetes cloud. My current main focus is NavOps command.
02:00
This is a product, though this is more or less a scheduler and policy management system for Kubernetes, so we are exchanging the stock scheduler of Kubernetes. But that's another topic. First of all, just a small introduction what Univa GridEngine is so that you have a bit of an overview what we want to get into the cloud.
02:22
So UGE, so the abbreviation, is a batch queuing system. Some of you might remember it as Sun GridEngine or Oracle GridEngine, so it's all the same product. So it's a batch queuing system, or if you want a grid computing cluster software, some folks call it distributed resource management system, so whatever you want.
02:43
The main parts in this architectural overview are the UGE, the GridEngine master. The master is responsible for all incoming requests by the user, like QSAP, which means
03:00
submitting a job into your batch system, or if some administrator wants to configure it via QConf or stuff like that, and also everything goes to the master. The master is also responsible for scheduling the jobs and for the actual dispatching of the incoming jobs to the execution demands.
03:24
And the execution demand is actually the second part we need to containerize, and the execution demand is actually responsible for really executing your workload and for monitoring the job on your, in former times, bare metal machine.
03:44
So again, these are the two components we want to bring into the cloud. So we will end up with just one image, which includes the master as also the execution demand, but you will see how at boot up time of this container, it will recognize
04:01
what it has to start and what not. So first of all, I want to start on how you can dockerize your application or your workload. So first of all, we do not create containers, we create images, so what's the difference? Image is, let me cite, a standalone and executable package, which includes everything
04:22
we need to run our application. And the container on the other hand, so this is the real runtime instance of that image. So usually by default, if you do not do anything fancy, a container is completely isolated from the host environment by default.
04:40
If you want to create a docker container or a docker image, you have to create a manifest or a recipe. In the docker world, you have to create a docker file. So a docker file defines what goes inside your container. So you can set access to resources like network interfaces, which are usually not available
05:07
from outside of the container. For example, you map some ports, port 80 if you want to have some Nginx instance or something like that. You have also to specify what files you want to copy inside your container.
05:22
So first of all, we need to copy our application inside of the container. So let's have a look at a real world example. So if you're talking about grid engine, we want to see that.
05:58
So in the first line, you say what image you will base on.
06:05
So as this is OpenSUSE conference, and this is a real world example, so we are running that at customers. Our grid engine image on OpenSUSE, just as a bit of a background, we choose that first of all because I'm an OpenSUSE member. And second of that, the OpenSUSE image is way smaller than most of the competitors.
06:27
So the base OpenSUSE image, which just includes 42, we are using 42.1, is about 100 Mac. If you compare it with CentOS or something like that, you're at 150 or even 200 Macs.
06:42
So you have to say the maintainer, this is in this case IAM. So we are running commands. So for running grid engine in that container and for later on running workload in that container, which means workload in the meaning of workload, which runs as grid engine jobs.
07:03
I'm installing a couple of additional packages. In this case, we are installing SSST. We are, which is needed for the configuration of grid engine. And we also need Java because our REST API in grid engine is written in Java.
07:22
After that, we clean all the temporary files from zipper. We define a working directory. So this means the working, the current working directory, which you get when you start up your container. I copy a bunch of files into that working directory.
07:43
So this is the scheduler configuration for grid engine, these are details which are not that important. We are copying, this one is important, wrapper script and renaming it to UGE. This will be later on our so-called entry point. The entry point is this process or
08:04
script which gets executed when you start your Docker container and without any additional command. So if you do a Docker run image name, it will start this entry, what you state here as entry point. As soon as this entry point script or application process stops,
08:24
your container will automatically also stop. You can also, as you have seen here with zipper, a couple of, I do here also a couple of run commands. So I'm installing here, for example, an additional RPM, which is not available by default in any of the repositories.
08:43
And here, this is another interesting thing. I have to expose a couple of ports. So as said, usually, no port of a container is available from the outside of the container. So I have to expose the ports for my queue master process. Said, my execution demons can communicate with the queue master.
09:04
I have to expose this port, which is responsible for the execution demon. And the last one is the responsible port for my UGE REST interface. Let's go back to the slides.
09:28
Let's start from this. So if you want to generate and test your image, you simply have to do a docker build dash t. Dash t means you give it a tag and a name.
09:44
And you have to say where docker will find your docker file. After that, you simply can execute a docker images. And you hopefully will find your application, something like that, with the tag. If you do not add a tag, it will automatically call it latest
10:04
with a certain image ID. So I will not show you how to build a docker image, because at least in the case of Grid Engine, it takes about ten minutes to build all that stuff. It has to grab the complete OpenSUSE image, which is about 100 meg and install all this additional software.
10:21
And after that, you can locally execute your container via docker run your app. And again, this will just start inside of your container the application you configured as entry point. But now we have a docker image.
10:42
That's okay, but we want to have a cluster of Grid Engine nodes. And you do not want to go to every of your nodes and install the docker image and boot it up by hand or manually. If you would do it like that, there is no meaning in doing it in a docker image.
11:01
So for that, we are using Kubernetes. So what's Kubernetes? This is an open source system held by the CNCF, the Cloud Native Foundation console or something like that, originally invented by Google. It's a tool for automating deployment and
11:23
management of containerized applications. So not only docker, but I think, so at least what I, the customers we have, I think, at least 95% are running docker images within Kubernetes and nothing else. Kubernetes follows, similar to Grid Engine, the master-slave architecture.
11:46
So the components can be easily divided into those who manage the individual nodes. Here, the most important part is the so-called kubelet, which is responsible for starting the pods. So a pod, I will tell you later what this is, but to be easy,
12:02
this is the container itself. And we have the Kubernetes master, which includes the stock scheduler and, for example, the etcd instance, which is a key value pair
12:21
server instance for storing all the configuration of Kubernetes. So to do a short overview of the namings in Kubernetes so that you know what I'm talking all about. The first thing, which I just said a couple of seconds ago, is a pod.
12:42
This is the basic block of Kubernetes, so it's more or less a process on your Kubernetes host node. A pod encapsulates a container or more. You can have running as many containers as you want in a container,
13:02
in a pod, as also resources like storage. So we will see that in our example, in Grid Engine, we need additional storage for our daemons. And you can also encapsulate resources like network interfaces and stuff like that.
13:20
The next thing I want to shortly talk about is controller. So a controller in Kubernetes is easy said concept or a manifest how you want to deploy your pods in a cluster. For example, which I choose for the execution daemon a replication controller,
13:41
and the replication controller is responsible. So you say, I have this execution daemon, you have a template of a pod. This execution daemon wants to have a storage. This container wants to have the storage mounted to this and that path.
14:00
And the controller is responsible for how many of them you want to have. For example, five replicas. And the controller is responsible that you always have these five controllers running in the system. So in case of a replication controller. So if one of the containers depots dies, a replication controller will automatically start up a new one.
14:21
If you downscale a replication controller, you do not want to have five anymore. You're okay with three. It will automatically kill two of them. The last thing I want to shortly introduce is the service. Pods in the Kubernetes world, they call it, they are ephemeral or mortal.
14:44
This means they are born, and when they die, they do not get resurrected or stuff like that. So while each pod gets its own IP address, even those IP addresses cannot be, you cannot rely on those IP addresses to be stable over time.
15:02
So a Kubernetes service is more or less an abstraction which defines a logical set of pods. You can have no pods as a service. And a policy by which to access these pods. So let's think on a multi-tier application.
15:21
So you have a web server, database, and you do not want to access a real instance, a real pod on your Kubernetes cluster, so you want to access the service for all that stuff. So when it comes to bringing your Docker image to Kubernetes, first of all, we have to decide what controller fits best.
15:43
For your application, so here's another example, a daemon set. So with a daemon set, you can ensure that every node in the cluster runs an instance of your pod. And you have to prepare storage for your application. So we need to do that. So a storage in Kubernetes can be NFS, CFS, Amazon EBS,
16:05
and can be an Azure drive or something in the Google Cloud wherever you want. And it also can be a so-called host pass, which simply means a local pass or local directory on your node, which is only for reasonable for demoing purposes.
16:23
So again, real-world example. First of all, I want to show you my demo environment. Unfortunately, the demo gods haven't been with me, so I destroyed yesterday in the evening my CAS installation. So I have to fall back to Minikube. Minikube is a virtual machine which runs Kubernetes inside.
16:44
So that's also the reason why I'm now relying on a local gear, a host pass. Usually, I'm showing that stuff with an NFS server running as a pod. Okay, nevertheless, first of all, we have to create a PV, so a persistent volume. This is a storage provisioned by the administrator.
17:01
Again, this can be NFS, whatever you want. The administrator has to say, okay, I have here an NFS share. This is mounted on this server. You can have access via this NFS server, and there are 30 gigs of memory. We need a PVC.
17:22
This is the persistent volume claim. This is the request for storage by a user. So a user usually does not care where his storage is. So a user does not want to know if this is on Amazon, if this is on Microsoft Azure, if this is somewhere in the Google Cloud, he doesn't care.
17:41
The only thing he wants to, he says, okay, I need here five gigs, stuff like that. For the UG execution daemon, I choose a replication controller. Just for demoing purposes, usually you would say for a execution daemon, you would choose a daemon set,
18:01
which means that you have one execution daemon per node in your Kubernetes cluster. But in a Minikube environment, this doesn't make many sense. For the UG queue master, I choose a stateful set. Stateful set is pretty similar to a replication controller with the difference
18:22
that stateful set provides a unique identity to your pod. This means the first one will get called UG queue master-o, the second one dash one, dash two, and so on and so on. Instead of, if you do a replication controller, you get UG execution daemon dash some arbitrary numbers and letters.
18:46
Another good thing about the stateful set is that it provides a guarantee about the ordering of scaling and deleting. So as said, you can count all the numbers, and if you downscale your stateful set,
19:03
you can get sure that the last one will get killed first. You're not sure in case of a replication controller. Last but not least, we need a service. So in this case, we need a headless service, as we have only one queue master running.
19:22
And this headless service is tied to this stateful set, which means we get a DNS entry directly for this UG queue master pod. So we can connect from the outside to our UniverGrid engine cluster. So we can do a QSAP or QConf even from outside of Kubernetes, if you want.
19:47
Let's go back to the examples.
20:30
Let's start with the persistent volume. Again, this is what you as administrator has to create. So you have to create or prepare some storage that your pods or controllers or whatever can rely on.
20:45
So this is a pretty simple example. You can get that as sophisticated as you want. So first of all, I say, you can do your configuration in Kubernetes either via JSON files or YAML.
21:01
So in my opinion, a YAML file is more easy to read, so I choose that for the demonstration. So the first line says, OK, this is all about a persistent volume. In Kubernetes, you always have to say which API version this persistent volume belongs to.
21:20
You have to give it a name, for sure. And in Kubernetes, you can add labels. These are just simple key value pairs where you can do sort and ordering later on. So there is nothing special about that in Kubernetes itself. It's just for monitoring and stuff like that. So I said, OK, this is the type local.
21:44
You have to specify what kind of persistent volume this is. So I give it a capacity of 10 gig of memory. You have to specify the access mode. In this case, I said read write many. This means that on many nodes, from many nodes,
22:03
many different nodes, you can read and write at the same time to this persistent volume. And I have to say what kind of persistent volume this is. So in this case, it's a host pass, which means it's a local directory. On the node, the persistent volume gets created on.
22:20
So if you would have an NFS server, you would have to say here NFS. Here, you would have something like a server entry and stuff like that.
22:42
This is the persistent volume claim. This is the thing the user will create, so user will rely on. So again, I said it's a persistent volume claim, the kind. The name is UGE claim. I have the same access mode, and I want to get three. So I need for my workload, my application, my part,
23:04
I need to have three gig of available. So this is my request. This would be all about the storage. So let's dive into the controllers.
23:33
This is the replication controller responsible for the execution daemon. Again, you have to give it a name. You have to say what it is at all.
23:42
This is the specification for the replication controller. So when creating that replication controller, it will boot up no pod so far. So you could also say I want to have it boot up 10 or something like that. Then you have to specify what container you want to run inside this pod, or containers.
24:03
Again, you can have multiple containers running inside that. So in this case, we have only one container running inside. I named that container execution daemon. You have to say where Kubernetes can download this image. In my case, I have it lying on the Google Cloud.
24:22
You can additionally add a so-called pull policy. So in my case, it says if it's not present on the node you want to boot up or to start this pod, please go to this direction and download it. You also can say something like always. In this case, it will always go to this path
24:44
and look up if there is a new version of your application. You can down pass environment variables directly inside of your container. So in my case, I have a couple ones.
25:01
So this one is the first one, the UGH type. This says what the container should start inside. So in this case, it should start an execution daemon. This is just for demoing purposes. So if this wouldn't be O, so the UGH deletion timer, it would cause the pod to destroy itself
25:20
if, for example, you don't have for 10 seconds workload on your execution daemon running. And I want to know inside the container in which namespace I'm running. So in Kubernetes, you can have different namespaces which is a pretty basic and simple way
25:42
to divide your, or to cluster your Kubernetes cluster or divide your Kubernetes cluster in different sections. For example, you have some development, you want to have a development namespace
26:01
and you have additionally some for the production. You can also add lifecycle hoops. So in this example, I added a pre-stop hook, which means as soon as before the pod actually gets stopped or killed by Kubernetes, it should execute that command.
26:21
So this command will only go to the queue master and say, okay, I will be not available in a couple of seconds anymore. And again, like in Docker, you have to say which ports should be accessible from outside of Grid Engine, sorry, of Kubernetes.
26:44
The last couple of lines here says, okay, I want to mount a pass inside of my container and this pass should be from the persistent volume claim we just created.
27:04
This is the so-called UG claim. So this one should be available at all my, later at all my execution daemon pods.
27:25
So this is the stateful set for queue master. It's pretty the same except that it's a stateful set and I want to boot up on replica at the time. And there are a couple of environment variables missing which are not necessary for the queue master.
27:40
But again, I want to have a shared directory between the execution daemon and the queue master. So you can see here, this is the same persistent volume claim. Both of them are available. So this claim should be available in my queue master parts as also my execution daemon parts.
28:07
Oh, this takes a while. I have to boot up my Minikube cluster which should take a couple of seconds. So I created a script which will add all these YAML files
28:25
to my Kubernetes cluster because we have here four different, five, we have the service also. And it's always the same. You do a kubectl create-f and this YAML file.
28:41
So we do not have to look at that. So okay, Minikube is up and running. So there are no pods running so far. So let's create our UGE cluster.
29:07
So as you can see here, the first what I did, I created these persistent volume. After that, I was able to create my persistent volume claim started up my UGE queue master. So I created my stateful set for the queue master
29:22
and I created a replication controller. So now we should have one queue master replica running but no execution daemon.
29:50
Yeah, so we have one queue master running here, one of one. So let's add a couple of execution daemons.
30:27
Okay, so it says, I scaled my stuff. Now you can see that we have three execution daemons up and running. And now we can go inside of the queue master
30:42
just to demonstrate that they are really up and running and that we really have a running grid engine cluster.
31:20
So for those who are familiar, maybe this grid engine, so you can see here, I'm on my queue master host and I have here three different execution daemons running inside which are exactly the parts we just booted up here in my Minikube environment. So that's what I wanted to show you.
31:42
Are there any questions? Don't see anybody. Okay, thank you.