Bare metal to the cloud
Haas, Stefan
Kubernetes is an open source project for orchestrating containerized applications. But how to containerize your workload? How to bring your containerized application into Kubernetes? This talk will show how we transferred our application to Kubernetes. - This includes containerizing the application (based on an openSUSE docker image) - How to expose your application services via Kubernetes. - How to create a shared file system for all Pod belonging to your application via Kubernetes. I will show how to do that plus a demo on a running Kubernetes System provided by SUSE CaaS.
 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. So a couple of seconds, only one guy was here. So I was a bit afraid if nobody will come. Okay. 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 can bring your docker image into the cloud, which means in my case, to Kubernetes. At the end, we will do a short demo. So you will see how to generate all these files and how to bring that in a running Kubernetes cluster. And there's always question and answers. Who am I? So my name is Stefan Haas. I'm Senior Software Engineer at Univer Corporation. This is a small American company. So I'm a former SUSE employee, but this is meanwhile nine years ago. So I brought my diploma thesis and the yes team back then. After that, I started to work for Sun Microsystems later for Oracle due to acquisition. So and I was part of the development team for Grid Engine. This is also meanwhile the main product of my current company. So and the Grid Engine will be the test object for this talk. So we will try to containerize Grid Engine and bring that into the Kubernetes cloud. My current main focus is NavOps command. 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 Univer Grid Engine is so that you have a bit of an overview what we want to get into the cloud. So UGE, so the abbreviation is a batch queuing system. Some of you might remember it as Sun Grid Engine or Oracle Grid Engine. So it's all the same product. So it's a batch queuing system. Or if you want a grid computing cluster software or somebody, some folks call it distributed resource management system. So whatever you want. The main parts in this architectural overview are the UGE, the Grid Engine master. The master is responsible for all incoming requests by the user like QSAP, which means 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 demons. And the execution demon is actually the second part we need to containerize. And the execution demon is actually responsible for really executing your workload and for monitoring the job on your Informatimes bare metal machine. So see as 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 demon. But you will see how at boot up time of this container it will recognize what it has to start and run at. 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 say the standalone and executable package which includes everything 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 container is completely isolated from the host environment by default. 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 from outside of the container. For example you map some ports, port 80 if you want to have some engine X instance or something like that. You have also to specify what files you want to copy inside your container. So first of all we need to copy our application inside of the container. So let's have a look at the real world example. So if you're talking about grid engine we want to see that. So in the first line you say what image you will base on. 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 openSUSE member and second of that the openSUSE image is way smaller than most of the competitors. So the base openSUSE image which just includes 42, we are using 42.1 is about 100 Mac. If you compare it with Santos or something like that you're at 150 or even 200 Macs. So you have to say the maintainer, this is in this case I am. 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. I'm installing a couple of additional packages. In this case we are installing SSSD, VI 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. 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 so this is the schedule a configuration for grid engine 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 script which gets executed when you start your Docker container without any additional command. So if you do a Docker run image name it will start this entry what do you state here as entry point. As soon as this entry point script or application process stops 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 am installing here for example an additional RPM which is not available by default in any of the repositories. And here this is also 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 Q master process said my execution demons can communicate with the Q master. 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. 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 and you have to say where Docker will find your Docker file. After that you simply can execute the 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 do call it latest with a certain image ID. So I will not show you how to build the Docker image because at least in the case of grid engine it takes about 10 minutes to build all that stuff it has to grab to complete. Open SUSE image which is about 100 meg and install all this additional software. 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. So but if you now we have a Docker image 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 start 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. 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 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 when it was in Kubernetes and nothing else. Kubernetes follows a similar to grid engine the master slave architecture so the components can be easily divided into those who manage the individual nodes. The most important part is the so-called kubelet which is responsible for starting the pots. So pot I will tell you later what this is but to be easy this is the container itself and we have the Kubernetes master which includes the stock scheduler and for example the et-cd instance is a key value pair 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 part. This is the basic block of Kubernetes so it's more or less a process in your Kubernetes host node. A pot encapsulates a container or more you can have running as many containers as you want in a container in a pot as also resources like storage. So we will see that in our example in grid engine we need additional storage for our demons. And you can also encapsulate resources like network interfaces and stuff like that. The next thing I want to shortly talk about is controller. So controller in Kubernetes is easy set, concept or manifest how you want to deploy your pots in a cluster. For example, I choose for the execution demon a replication controller and the replication controller is responsible. So you say I have this execution demon, you have a template of a pot, this execution demon wants to have a storage. He wants that this container wants to have the storage mounted to this and that pass. 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 departs dies, a replication controller will automatically start up a new one. If you downscale a replication controller, you do not want to have five anymore, you are okay with three. It will automatically kill two of them. The last thing I want to shortly introduce is the service. Pots in the Kubernetes world, they call it they are ephemeral or mortal. This means they are born and when they die, they do not get resurrected or stuff like that. So while each pot gets its own IP address, even those IP addresses cannot be, you cannot rely on those IP addresses to be stable over time. So a Kubernetes service is more or less an abstraction which defines a logical set of pots. You can have more pots in as a service and a policy by which to access these pots. So let's think on a multi-tier replication. So you have a web server database and you do not want to access a real instance, a real pot 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 for your application. So here's another example, a demon set. So with a demon set, you can ensure that every node in the cluster runs an instance of your pot. And you have to prepare storage for your application. So we need to do that. So a storage in Kubernetes can be NFS, CFFS, Amazon EBS, 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. 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. So that's also the reason why I'm now relying on a local host pass. Usually I'm showing that stuff with an NFS server running as a pot. Okay. Nevertheless. First of all, we have to create a PV, so persistent volume. This is the storage provisioned by the administrator. 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 to this via this NFS server and there are 30 gigs of memory. We need a PVC. 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. The only thing he wants to, he says, okay, I need here five gigs, stuff like that. For the UT 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, which means that you have one execution daemon per node in your Kubernetes cluster. But in a mini-cube environment, this doesn't make many sense. For the UT Q-Master, I choose a stateful set. A stateful set is pretty similar to a replication controller with the difference that a stateful set provides a unique identity to your pod. This means the first one will get called UG Q-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. 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 on the numbers, and if you downscale your stateful set, you can get sure that the last one will get killed first. You cannot get your natural 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 Q-Master running. And this headless service is tied to this stateful set, which means we get a DNS entry directly for this UG Q-Master pod. So we can connect from the outside to our UniverGrid Engine cluster. So we can do a Q-SAP or Q-COM even from outside of Kubernetes if you want. Let's go back to the examples. So let's start with the persistent volume. Again, this is what you as an administrator have to create. So you have to create or prepare some storage that your pods or controllers or whatever can rely on. 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. 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 the persistent volume. In Kubernetes, you always have to say which API version this persistent volume belongs to. 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. 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 from 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. 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. This is the persistent volume claim. This is the thing the user will create. The 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 pod, 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. 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. 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 a boot up 10 or something like that. Then you have to specify what container you want to run inside this pod. Or containers. 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. You have to, 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 pass 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 one. 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. 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 to divide your, to cluster your Kubernetes cluster or to divide your Kubernetes cluster in different sections. For example, you have some development. You want to have a development namespace and you have additionally some for the production. You can also add lifecycle hooks. 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. So this command will only go to the Q 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. The last couple of lines here says, okay, I want to have, I want to mount a pass inside of my container and this container, this pass should be from the persistent volume claim we just created. This is the so-called UG claim. So this one should be available at all my later, at all my execution human pods. So this is the stateful set for Q master. It's pretty the same except that it's a stateful set and I want to boot up one replica at the time. And there are a couple of environment variables missing which are not necessary for the Q master. But again, I want to have a shared directory between the execution human and the Q master. So you can see here, this is the same persistent volume claim. Both of them are available. So this claim will be, it should be available in my Q master pods as also in my execution human pods. This takes a while. I have to boot up my mini cube cluster. It should take a couple of seconds. So I created a script which will add all these YAML files 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 cube control, create dash F and dish YAML files. So we do not have to look at that. So okay, mini cube is up and running. So there are no pods running so far. So let's create our UG cluster. So as you can see here, the first what I did, I created this persistent volume. After that, I was able to create my persistent volume claim, started up my UG Q master. So I created my stateful set for the Q master and I created replication controller. So now we should have one Q master replica running but no execution daemon. So we have one Q master running here, one of one. So let's add a couple of execution daemons. 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 Q master just to demonstrate that they are really up and running and that we really have a running grid engine cluster. So for those who are familiar, maybe this grid engine so you can see here, I'm on my Q master host and I have here three different execution daemons running inside which are exactly the pots we just booted up here in my mini-cube environment. So that's what I wanted to show you. Are there any questions? Don't see anybody? Okay. Thank you. Okay. Thank you. Okay. Thank you. Okay. Thank you. Thank you. We'll come back to you in about the next video. Bye.
 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.  So a couple of seconds, only one guy was here.  So I was a bit afraid if nobody will come.  Okay.  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  can bring your docker image into the cloud, which means in my case, to Kubernetes.  At the end, we will do a short demo.  So you will see how to generate all these files and how to bring that in a running Kubernetes  cluster.  And there's always question and answers.  Who am I?  So my name is Stefan Haas.  I'm Senior Software Engineer at Univer Corporation.  This is a small American company.  So I'm a former SUSE employee, but this is meanwhile nine years ago.  So I brought my diploma thesis and the yes team back then.  After that, I started to work for Sun Microsystems later for Oracle due to acquisition.  So and I was part of the development team for Grid Engine.  This is also meanwhile the main product of my current company.  So and the Grid Engine will be the test object for this talk.  So we will try to containerize Grid Engine and bring that into the Kubernetes cloud.  My current main focus is NavOps command.  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 Univer Grid Engine is so that you have a  bit of an overview what we want to get into the cloud.  So UGE, so the abbreviation is a batch queuing system.  Some of you might remember it as Sun Grid Engine or Oracle Grid Engine.  So it's all the same product.  So it's a batch queuing system.  Or if you want a grid computing cluster software or somebody, some folks call it distributed  resource management system.  So whatever you want.  The main parts in this architectural overview are the UGE, the Grid Engine master.  The master is responsible for all incoming requests by the user like QSAP, which means  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 demons.  And the execution demon is actually the second part we need to containerize.  And the execution demon is actually responsible for really executing your workload and for  monitoring the job on your Informatimes bare metal machine.  So see as 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  demon.  But you will see how at boot up time of this container it will recognize what it has to  start and run at.  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 say the standalone and executable package which includes everything 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 container is completely isolated from  the host environment by default.  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  from outside of the container.  For example you map some ports, port 80 if you want to have some engine X instance or  something like that.  You have also to specify what files you want to copy inside your container.  So first of all we need to copy our application inside of the container.  So let's have a look at the real world example.  So if you're talking about grid engine we want to see that.  So in the first line you say what image you will base on.  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 openSUSE member and second of that the openSUSE image is way smaller  than most of the competitors.  So the base openSUSE image which just includes 42, we are using 42.1 is about 100 Mac.  If you compare it with Santos or something like that you're at 150 or even 200 Macs.  So you have to say the maintainer, this is in this case I am.  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.  I'm installing a couple of additional packages.  In this case we are installing SSSD, VI 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.  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 so this is the schedule a configuration  for grid engine 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 script which gets executed when you start your Docker  container without any additional command.  So if you do a Docker run image name it will start this entry what do you state here as  entry point.  As soon as this entry point script or application process stops 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 am installing here for example an additional RPM which is not available by  default in any of the repositories.  And here this is also 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 Q master process said my execution demons can communicate  with the Q master.  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.  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 and you have to say where Docker will find  your Docker file.  After that you simply can execute the 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 do call it latest with a certain image ID.  So I will not show you how to build the Docker image because at least in the case of grid  engine it takes about 10 minutes to build all that stuff it has to grab to complete.  Open SUSE image which is about 100 meg and install all this additional software.  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.  So but if you now we have a Docker image 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 start 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.  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 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 when it was in Kubernetes and nothing else.  Kubernetes follows a similar to grid engine the master slave architecture so the components  can be easily divided into those who manage the individual nodes.  The most important part is the so-called kubelet which is responsible for starting the pots.  So pot I will tell you later what this is but to be easy this is the container itself  and we have the Kubernetes master which includes the stock scheduler and for example the et-cd  instance is a key value pair 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 part.  This is the basic block of Kubernetes so it's more or less a process in your Kubernetes  host node.  A pot encapsulates a container or more you can have running as many containers as you  want in a container in a pot as also resources like storage.  So we will see that in our example in grid engine we need additional storage for our  demons.  And you can also encapsulate resources like network interfaces and stuff like that.  The next thing I want to shortly talk about is controller.  So controller in Kubernetes is easy set, concept or manifest how you want to deploy your pots  in a cluster.  For example, I choose for the execution demon a replication controller and the replication  controller is responsible.  So you say I have this execution demon, you have a template of a pot, this execution  demon wants to have a storage.  He wants that this container wants to have the storage mounted to this and that pass.  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 departs dies, a replication controller will automatically  start up a new one.  If you downscale a replication controller, you do not want to have five anymore, you  are okay with three.  It will automatically kill two of them.  The last thing I want to shortly introduce is the service.  Pots in the Kubernetes world, they call it they are ephemeral or mortal.  This means they are born and when they die, they do not get resurrected or stuff like  that.  So while each pot gets its own IP address, even those IP addresses cannot be, you cannot  rely on those IP addresses to be stable over time.  So a Kubernetes service is more or less an abstraction which defines a logical set of  pots.  You can have more pots in as a service and a policy by which to access these pots.  So let's think on a multi-tier replication.  So you have a web server database and you do not want to access a real instance, a real  pot 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 for your application.  So here's another example, a demon set.  So with a demon set, you can ensure that every node in the cluster runs an instance of your  pot.  And you have to prepare storage for your application.  So we need to do that.  So a storage in Kubernetes can be NFS, CFFS, Amazon EBS, 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.  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.  So that's also the reason why I'm now relying on a local host pass.  Usually I'm showing that stuff with an NFS server running as a pot.  Okay.  Nevertheless.  First of all, we have to create a PV, so persistent volume.  This is the storage provisioned by the administrator.  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 to this via this NFS server and there are 30 gigs of memory.  We need a PVC.  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.  The only thing he wants to, he says, okay, I need here five gigs, stuff like that.  For the UT 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, which means that you have one execution daemon per node in your Kubernetes  cluster.  But in a mini-cube environment, this doesn't make many sense.  For the UT Q-Master, I choose a stateful set.  A stateful set is pretty similar to a replication controller with the difference that a stateful  set provides a unique identity to your pod.  This means the first one will get called UG Q-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.  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 on the numbers, and if you downscale your stateful set, you  can get sure that the last one will get killed first.  You cannot get your natural 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 Q-Master running.  And this headless service is tied to this stateful set, which means we get a DNS entry  directly for this UG Q-Master pod.  So we can connect from the outside to our UniverGrid Engine cluster.  So we can do a Q-SAP or Q-COM even from outside of Kubernetes if you want.  Let's go back to the examples.  So let's start with the persistent volume.  Again, this is what you as an administrator have to create.  So you have to create or prepare some storage that your pods or controllers or whatever  can rely on.  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.  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 the persistent volume.  In Kubernetes, you always have to say which API version this persistent volume belongs  to.  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.  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 from 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.  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.  This is the persistent volume claim.  This is the thing the user will create.  The 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 pod, 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.  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.  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 a boot up 10 or something like that.  Then you have to specify what container you want to run inside this pod.  Or containers.  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.  You have to, 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 pass 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 one.  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.  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 to  divide your, to cluster your Kubernetes cluster or to divide your Kubernetes cluster in different  sections.  For example, you have some development.  You want to have a development namespace and you have additionally some for the production.  You can also add lifecycle hooks.  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.  So this command will only go to the Q 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.  The last couple of lines here says, okay, I want to have, I want to mount a pass inside  of my container and this container, this pass should be from the persistent volume claim  we just created.  This is the so-called UG claim.  So this one should be available at all my later, at all my execution human pods.  So this is the stateful set for Q master.  It's pretty the same except that it's a stateful set and I want to boot up one replica at the  time.  And there are a couple of environment variables missing which are not necessary for the Q  master.  But again, I want to have a shared directory between the execution human and the Q master.  So you can see here, this is the same persistent volume claim.  Both of them are available.  So this claim will be, it should be available in my Q master pods as also in my execution  human pods.  This takes a while.  I have to boot up my mini cube cluster.  It should take a couple of seconds.  So I created a script which will add all these YAML files 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 cube control, create dash F and dish YAML files.  So we do not have to look at that.  So okay, mini cube is up and running.  So there are no pods running so far.  So let's create our UG cluster.  So as you can see here, the first what I did, I created this persistent volume.  After that, I was able to create my persistent volume claim, started up my UG Q master.  So I created my stateful set for the Q master and I created replication controller.  So now we should have one Q master replica running but no execution daemon.  So we have one Q master running here, one of one.  So let's add a couple of execution daemons.  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 Q master just to demonstrate that they are really up and  running and that we really have a running grid engine cluster.  So for those who are familiar, maybe this grid engine so you can see here, I'm on my Q master  host and I have here three different execution daemons running inside which are exactly the  pots we just booted up here in my mini-cube environment.  So that's what I wanted to show you.  Are there any questions?  Don't see anybody?  Okay.  Thank you.  Okay.  Thank you.  Okay.  Thank you.  Okay.  Thank you.  Thank you.  We'll come back to you in about the next video.  Bye.
openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_0_47.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_48_203.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_204_251.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_252_467.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_468_515.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_516_587.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_588_719.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_720_6131.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_6132_7007.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_7008_8183.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_8184_8267.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_8268_8567.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_8568_8615.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_8616_8879.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_8880_14111.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_14112_14171.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_14172_14219.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_14220_14267.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_14268_14327.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_14328_14387.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_14388_15959.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_15960_18695.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_18696_23423.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_23424_24599.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_24600_29771.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_29772_30059.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_30060_30311.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_30312_30575.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_30576_30719.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_30720_33851.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_33852_35087.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_35088_35171.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_35172_42155.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_42156_43355.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_43356_44735.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_44736_45659.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_45660_45827.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_45828_47747.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_47748_47843.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_47844_47903.png openSUSE_Conference_2017_From_bare_metal_to_the_cl_HjjsOG3xHwA_47904_48027.png
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. So a couple of seconds, only one guy was here. So I was a bit afraid if nobody will come. Okay. 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 can bring your docker image into the cloud, which means in my case, to Kubernetes. At the end, we will do a short demo. So you will see how to generate all these files and how to bring that in a running Kubernetes cluster. And there's always question and answers. Who am I? So my name is Stefan Haas. I'm Senior Software Engineer at Univer Corporation. This is a small American company. So I'm a former SUSE employee, but this is meanwhile nine years ago. So I brought my diploma thesis and the yes team back then. After that, I started to work for Sun Microsystems later for Oracle due to acquisition. So and I was part of the development team for Grid Engine. This is also meanwhile the main product of my current company. So and the Grid Engine will be the test object for this talk. So we will try to containerize Grid Engine and bring that into the Kubernetes cloud. My current main focus is NavOps command. 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 Univer Grid Engine is so that you have a bit of an overview what we want to get into the cloud. So UGE, so the abbreviation is a batch queuing system. Some of you might remember it as Sun Grid Engine or Oracle Grid Engine. So it's all the same product. So it's a batch queuing system. Or if you want a grid computing cluster software or somebody, some folks call it distributed resource management system. So whatever you want. The main parts in this architectural overview are the UGE, the Grid Engine master. The master is responsible for all incoming requests by the user like QSAP, which means 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 demons. And the execution demon is actually the second part we need to containerize. And the execution demon is actually responsible for really executing your workload and for monitoring the job on your Informatimes bare metal machine. So see as 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 demon. But you will see how at boot up time of this container it will recognize what it has to start and run at. 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 say the standalone and executable package which includes everything 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 container is completely isolated from the host environment by default. 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 from outside of the container. For example you map some ports, port 80 if you want to have some engine X instance or something like that. You have also to specify what files you want to copy inside your container. So first of all we need to copy our application inside of the container. So let's have a look at the real world example. So if you're talking about grid engine we want to see that. So in the first line you say what image you will base on. 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 openSUSE member and second of that the openSUSE image is way smaller than most of the competitors. So the base openSUSE image which just includes 42, we are using 42.1 is about 100 Mac. If you compare it with Santos or something like that you're at 150 or even 200 Macs. So you have to say the maintainer, this is in this case I am. 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. I'm installing a couple of additional packages. In this case we are installing SSSD, VI 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. 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 so this is the schedule a configuration for grid engine 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 script which gets executed when you start your Docker container without any additional command. So if you do a Docker run image name it will start this entry what do you state here as entry point. As soon as this entry point script or application process stops 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 am installing here for example an additional RPM which is not available by default in any of the repositories. And here this is also 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 Q master process said my execution demons can communicate with the Q master. 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. 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 and you have to say where Docker will find your Docker file. After that you simply can execute the 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 do call it latest with a certain image ID. So I will not show you how to build the Docker image because at least in the case of grid engine it takes about 10 minutes to build all that stuff it has to grab to complete. Open SUSE image which is about 100 meg and install all this additional software. 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. So but if you now we have a Docker image 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 start 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. 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 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 when it was in Kubernetes and nothing else. Kubernetes follows a similar to grid engine the master slave architecture so the components can be easily divided into those who manage the individual nodes. The most important part is the so-called kubelet which is responsible for starting the pots. So pot I will tell you later what this is but to be easy this is the container itself and we have the Kubernetes master which includes the stock scheduler and for example the et-cd instance is a key value pair 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 part. This is the basic block of Kubernetes so it's more or less a process in your Kubernetes host node. A pot encapsulates a container or more you can have running as many containers as you want in a container in a pot as also resources like storage. So we will see that in our example in grid engine we need additional storage for our demons. And you can also encapsulate resources like network interfaces and stuff like that. The next thing I want to shortly talk about is controller. So controller in Kubernetes is easy set, concept or manifest how you want to deploy your pots in a cluster. For example, I choose for the execution demon a replication controller and the replication controller is responsible. So you say I have this execution demon, you have a template of a pot, this execution demon wants to have a storage. He wants that this container wants to have the storage mounted to this and that pass. 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 departs dies, a replication controller will automatically start up a new one. If you downscale a replication controller, you do not want to have five anymore, you are okay with three. It will automatically kill two of them. The last thing I want to shortly introduce is the service. Pots in the Kubernetes world, they call it they are ephemeral or mortal. This means they are born and when they die, they do not get resurrected or stuff like that. So while each pot gets its own IP address, even those IP addresses cannot be, you cannot rely on those IP addresses to be stable over time. So a Kubernetes service is more or less an abstraction which defines a logical set of pots. You can have more pots in as a service and a policy by which to access these pots. So let's think on a multi-tier replication. So you have a web server database and you do not want to access a real instance, a real pot 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 for your application. So here's another example, a demon set. So with a demon set, you can ensure that every node in the cluster runs an instance of your pot. And you have to prepare storage for your application. So we need to do that. So a storage in Kubernetes can be NFS, CFFS, Amazon EBS, 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. 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. So that's also the reason why I'm now relying on a local host pass. Usually I'm showing that stuff with an NFS server running as a pot. Okay. Nevertheless. First of all, we have to create a PV, so persistent volume. This is the storage provisioned by the administrator. 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 to this via this NFS server and there are 30 gigs of memory. We need a PVC. 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. The only thing he wants to, he says, okay, I need here five gigs, stuff like that. For the UT 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, which means that you have one execution daemon per node in your Kubernetes cluster. But in a mini-cube environment, this doesn't make many sense. For the UT Q-Master, I choose a stateful set. A stateful set is pretty similar to a replication controller with the difference that a stateful set provides a unique identity to your pod. This means the first one will get called UG Q-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. 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 on the numbers, and if you downscale your stateful set, you can get sure that the last one will get killed first. You cannot get your natural 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 Q-Master running. And this headless service is tied to this stateful set, which means we get a DNS entry directly for this UG Q-Master pod. So we can connect from the outside to our UniverGrid Engine cluster. So we can do a Q-SAP or Q-COM even from outside of Kubernetes if you want. Let's go back to the examples. So let's start with the persistent volume. Again, this is what you as an administrator have to create. So you have to create or prepare some storage that your pods or controllers or whatever can rely on. 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. 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 the persistent volume. In Kubernetes, you always have to say which API version this persistent volume belongs to. 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. 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 from 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. 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. This is the persistent volume claim. This is the thing the user will create. The 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 pod, 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. 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. 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 a boot up 10 or something like that. Then you have to specify what container you want to run inside this pod. Or containers. 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. You have to, 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 pass 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 one. 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. 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 to divide your, to cluster your Kubernetes cluster or to divide your Kubernetes cluster in different sections. For example, you have some development. You want to have a development namespace and you have additionally some for the production. You can also add lifecycle hooks. 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. So this command will only go to the Q 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. The last couple of lines here says, okay, I want to have, I want to mount a pass inside of my container and this container, this pass should be from the persistent volume claim we just created. This is the so-called UG claim. So this one should be available at all my later, at all my execution human pods. So this is the stateful set for Q master. It's pretty the same except that it's a stateful set and I want to boot up one replica at the time. And there are a couple of environment variables missing which are not necessary for the Q master. But again, I want to have a shared directory between the execution human and the Q master. So you can see here, this is the same persistent volume claim. Both of them are available. So this claim will be, it should be available in my Q master pods as also in my execution human pods. This takes a while. I have to boot up my mini cube cluster. It should take a couple of seconds. So I created a script which will add all these YAML files 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 cube control, create dash F and dish YAML files. So we do not have to look at that. So okay, mini cube is up and running. So there are no pods running so far. So let's create our UG cluster. So as you can see here, the first what I did, I created this persistent volume. After that, I was able to create my persistent volume claim, started up my UG Q master. So I created my stateful set for the Q master and I created replication controller. So now we should have one Q master replica running but no execution daemon. So we have one Q master running here, one of one. So let's add a couple of execution daemons. 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 Q master just to demonstrate that they are really up and running and that we really have a running grid engine cluster. So for those who are familiar, maybe this grid engine so you can see here, I'm on my Q master host and I have here three different execution daemons running inside which are exactly the pots we just booted up here in my mini-cube environment. So that's what I wanted to show you. Are there any questions? Don't see anybody? Okay. Thank you. Okay. Thank you. Okay. Thank you. Okay. Thank you. Thank you. We'll come back to you in about the next video. Bye.
bring your application or your workload from bare these files and how to bring that in a running for this talk. So we will try to containerize to create a docker container or a docker image all we need to copy our application inside of the the outside of the container. So I have to expose Kubernetes? This is an open source system held by management of containerized applications. So not storage for your application. So we need to do Q master. But again, I want to have a shared