paint-brush
Here's How I Got Started With Kubernetes: Part Iby@miketechgame
449 reads
449 reads

Here's How I Got Started With Kubernetes: Part I

by Mike WolfeOctober 20th, 2020
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

The plan was to use four Raspberry Pi’s, one master, and three worker nodes to create a Kubernetes Cluster. The goal was to deploy databases, scheduled tasks, APIs, front-end applications and set up a CI/CD tunnel. Part 2 of the project will move from the Raspberry Pi onto an actual server. The cluster spreads out the different applications across the worker nodes using the storage of those nodes in a more effective way. In Part 2, we’ll move onto the actual server that contains virtual machines as well as the cluster.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Here's How I Got Started With Kubernetes: Part I
Mike Wolfe HackerNoon profile picture

While scheduling classes for my final semester of college, I was very eager to do something different. Like many of my computer science peers, I had grown tired of the typical class where we have to reinvent the wheel when learning new concepts.

However important it may be to understand those concepts and know what goes on behind the scenes, it was time for a change of pace. That’s where the idea of taking an Individual Study course came to mind.

The plan was relatively simple (naturally, this all had to be okayed by my professor). I was going to use four Raspberry Pi’s, one master, and three worker nodes to create a Kubernetes Cluster.

After that, the goal was to deploy databases, scheduled tasks, APIs, front-end applications and set up a CI/CD tunnel.

Once all of this was up and running, I would then compare and contrast this new environment to my current environment running on multiple servers and virtual machines. Pretty straight forward right!?

Creating the cluster was actually easier than expected. There was an obvious learning curve, but what was supposed to take a couple of weeks only took a couple of days.

Figuring that I was off to a good start, I jumped right into setting up a CI/CD (Continuous Integration/Continuous Delivery) pipeline on the cluster. This is where the real fun started (sarcasm).

For the longest time, I have been wanting to learn how to use Jenkins and I thought this project would be a good place to start. I really wanted it to run in a container on the cluster.

I searched high and low looking for a Docker container that would support the ARM architecture of Pis. Unfortunately, no such luck. In the end, I settled on setting it up on one of my local machines and used it to create Docker images from a Github repo and deploy them to the cluster.

The second sucker punch came with MySQL.

I got the persistent volume and persistent volume claim all set up only to run into the same roadblock of no Docker image for ARM.

I spent a few days trying some potential workarounds that were found on Google, but no such luck getting these to work. Since I couldn’t spend any more time trying to get a MySQL image to run, Postgres seemed like a good alternative.

Luckily, I was able to get the Postgres image up and running and also successfully created a test database as well.

At this point, it was time to add a test API and front-end application. For the API, I quickly created it using Python (Flask micro-framework specifically) and connected it to the Postgres database.

After that, I created an Angular application and built it for production use (Nothing fancy, just a “hello world” app).

It took me quite a long time to figure this out, but when creating Docker images for custom applications they need to be created on a machine that is the same architecture as the one you are deploying to.

Once I realized this, they worked pretty well when testing in Postman and a web browser.

At last, I was able to do the comparison of the cluster to the servers running services, apps, databases, etc. on virtual machines. In my case, I was comparing a server (Dell Poweredge R710) to Raspberry Pi’s, so I wasn’t looking at CPU and RAM performance.

Instead, deployment time performance, deployment ease of use, and disk space storage were more of a concern. For deployments, there was an obvious learning curve, but configuring the YAML files and then pushing them to the cluster was very simple and gave me some ideas on potential automation using Jenkins.

In terms of disk space storage, there were some obvious savings there. Unlike my current setup where applications are organized onto different virtual machines, the cluster spreads out the different applications across the worker nodes utilizing the storage of those nodes in a more effective way.

To sum things up, this was an amazing learning experience. I definitely accomplished the goal of getting to do something different in my final semester of college.

In Part 2, we’ll move from the Raspberry Pis onto an actual server that will contain virtual machines as our cluster.

I hope you enjoyed this part of the journey and will continue with me onto the next. Cheers!

(Image Credits: https://www.logo.wine/logo/Kubernetes)

Read behind a paywall here.