The KAUST Information Technology Department blog
20 July, 2020
IT Research Computing is proud to announce that their production Kubernetes cluster is readily available for use by the KAUST research community. This cluster consists of on-premise and public cloud Kubernetes workers. The team already runs multiple diverse workloads (belonging to IT, research, and business) on these unified Kubernetes clusters. You can now run your Docker containers on a Kubernetes cluster managed by IT Research Computing. You create the science, the team will make sure it is up and running.
We mention the word cluster multiple times during this blog post. This has nothing to do with the HPC (High Performance Computing) clusters at KAUST. Those clusters are built to run parallel jobs (e.g. MPI) over fast networks (e.g. Infiniband) and fast storage (e.g. Lustre). A Kubernetes cluster is a set of node machines for running containerized applications; no HPC workloads involved. You can read more details here.
Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. It groups containers that make up an application into logical units for easy management and discovery. It builds upon Google's (it was called Borg) 15 years experience using it in production. Google has open sourced Kubernetes, releasing it to the community in 2015. The Cloud Native Computing Foundation maintains it now.
Containers wrap your application in something portable called an image. An image running somewhere, locally on your computer or remotely on a Kubernetes cluster, is called a container. Read our blog post on containers. Nowadays almost all technology companies use Kubernetes. Either on-premise (you manage it), on the cloud (it is managed for you), or (like IT Research Computing) in both flavors. Running your containers on a Kubernetes cluster hides from you all the complexities of managing the underlying resources. You could run containers on-premise because of cost but then push them to the cloud for higher availability or because they are closer to your customers. You as the container developer would not know where it is running nor should you care (unless you need features that only one of the aforementioned clouds offers). Using Kubernetes to manage your containers is appealing in so many ways. It was built from the ground up with scalability, high availability, and self healing in mind. Kubernetes can health check and self heal your applications with autoplacement, autorestart, autoreplication, and autoscaling.
A containerized application could be made of multiple processes that communicate with each other, e.g. a WordPress website. We run The Lens WordPress on our Kubernetes production cluster. This application is made of the following components:
This is where Kubernetes comes in handy. The web site crashes, Kubernetes restarts it automatically. We have to upgrade WordPress, Kubernetes allows us to do it without downtime. Kubernetes takes care of all these things and more for you. You just write a Kubernetes manifest file outlining these dependencies and rules, then sit back while Kubernetes turns on the autopilot. That means it takes care of:
One of the main reasons we like Kubernetes here in IT Research Computing is because it helps us maximize resources needed to run containers. We can pack hosts with many containers of different nature. Thanks to container technology these will not affect each other. Compare that to the old days when you would need a virtual machine to do the work done now by a container. This also comes with the side benefit of reducing infrastructure costs. This looks very promising and appealing on cloud, where you can pay-as-you-go. And it gets a lot more interesting if you consider that we could move all our Kubernetes workloads to the cloud. This means we would not have to buy hardware anymore. Allowing the team to focus on things that bring most value to KAUST because Kubernetes would be managed by a cloud provider. By the way, did we mention that you would not notice this shift because Kubernetes abstracts it away from you?
Kubernetes makes IT Research Computing's infrastructure more solid. Containers will die, we cannot prevent it. But we do not sweat it. Kubernetes will launch immediately a replacement container for us. We do not debug containers if something goes wrong, we kill it so a new fresh container is created for us on the fly.
Many times we would have to ask our customers how many resources they would need for a new virtual machine. How many users would be accessing their web application. Nobody knew the answers because nobody can foresee the future. These problems do not exist anymore thanks to Kubernetes managing our resources. You need more CPU or RAM or storage, do not worry, Kubernetes will help you during peak traffic. Once things go back to normal, Kubernetes will return those resources back to the shared pool. We just sit back and watch.
Probably not. At least not in the strict sense of what a modern Operating System means today. Kubernetes could become the de facto CloudOS. IT Research Computing would turn a few knobs in the Cloud to get some Kubernetes workers, some other knobs to attach terabytes of storage to those workers, yet other knobs to get one (or two or three) managed database(s). We (i.e. KAUST community) would consume these resources through Kubernetes. We would not know on how many servers our code is running; nor should we care. Everything is abstracted via Kubernetes, our gateway to the cloud. That is what the new Serverless paradigm focuses on. You still have servers (i.e. hardware) underneath your services, you just do not care because you do not interact directly with them. You do not have to manage those servers. You just interact with services that run your code.
This is IT Research Computing's ultimate goal: to go Serverless. We are not there yet because we still have many workloads that depend on data hosted on KAUST storage either on Noor Home or DataWaha or Shaheen. Those workloads are more cost effective by hosting them on our on-premise cloud. At least today, things might change in the future.
Get in touch with IT Research Computing. Use our Slack channels or email us. We will be more than happy to assess what your goal is, then guide you to achieve it. Our team has plenty of knowledge on automating workflows, containerizing applications, making sure they are up and running. We also help you maintain your container secure. We add static and dynamic scanning to the automation pipelines. This way you always know if you have to patch/fix code. Once your automated pipeline is ready, then your application is deployed to the Kubernetes cluster. We also help you publish it to the world; after all, you want your fellow researchers to access your work.
We know all the ropes, you just crank out your code.
Article written by: Antonio Arena
