If you haven't seen my entry in the Linode + Dev Hackathon, I recently built a Discord bot and deployed it on Linode's cloud using Kubernetes. As I was unfamiliar with Kubernetes, I learned quite a lot from the process of deploying a working application with it.
I thought I would share some of my thoughts from the experience as well as summarize the concepts that I learned to help anybody else interested in learning how to use Kubernetes.
Kubernetes Features I like
Kubernetes offers several key features that I found very attractive formy project such as:
Automatic rebooting of failed containers.
Container replication, meaning that if one instance of a container goes down, traffic is automatically redirected to a healthy container, preventing service interruptions.
No downtime rollouts and rollbacks --- because containers can be replicated, updates and rollbacks can be deployed in such a way that the updates result in zero downtime for end users.
Finally, because containers can be distributed across multiple cloud machines, if one machine goes down, Kubernetes, can redirect all the web traffic to other healthy machines, again preventing disruptions.
Overall thoughts on using Kubernetes
Overall, I really enjoyed using Kubernetes. Unlike most of the projects I have hosted on the cloud where I have to set up a cloud instance, log in, run a bunch of commands to configure it correctly, then setup a bunch of DNS records, change firewall rules, etc., using Kubernetes was really simple: create a cluster, run kubectl apply -f several times,
and my project was live.
Getting to the point where I knew exactly which commands to run and how to setup my object files was a more difficult journey, but overall it was worth the time put into it.
The other downside of running a project with Kubernetes is the cost. Running a Kubernetes cluster with the recommended number of machines in it is more expensive than I would typically prefer for a project, but if high availability is a priority, then a Kubernetes cluster is probably an investment that's worth the money.
Concepts I Learned
Pod
A Pod is the core unit of work in a Kubernetes environment. Pods the code you deployed in containers.
Node
Nodes represent the underlying hardware on which pods run. Pods are not necessarily tied to specific nodes and nodes do not need to be limited to running only one pod (or one single type of pod).
It's important to separate the concept of nodes from the concept of code execution in Kubernetes because the nodes themselves aren't running your code, rather the pods run your code.
Service
Services group pods together under a single IP. Services are a little bit like load balancers. They take distributed pods and combine them under a single umbrella. Services are not one-to-one analogous to load balancers, though because services can group together different components under a single IP.
For example, one could configure a microservice Pod and a website
hosting Pod to be combined in a single service. Two different types of execution, one IP address for both types.
Configmap
Config maps are the most unfamiliar concept I had to deal with when deploying my Discord Bot. They way I used config maps, they were kind of like if I had a tiny redis database attached to a Pod that was pretending to be a file --- a little complicated, I know.
Basically, in the pod, the configmap functions as a file. In the mind of the Kubernetes cluster, however, the config map is more like a bunch of key-value pairs.
Secret
Finally, the last Kubernetes concept I learned was the concept of
Secrets. In my environment, the secrets I used functioned very similarly to environment variables, but with added security features to prevent them from being read directly.
Would I recommend Kubernetes for your project?
Possibly. If you want to learn Kubernetes, or want to create a project which is intended to have as little downtime as possible, then yes I would heartily recommend using a Kubernetes cluster. Otherwise, if you are planning on hosting a small project for friends and family that you don't intend to leave running for a long time, then Kubernetes is probably overkill.
That said, I quite enjoyed the process of learning how to use and deploy a Kubernetes cluster and hope to help out anyone with a similar interest. I'm happy to answer any questions you might have below.
Kubernetes Documentation:
https://kubernetes.io/docs/home/
My entry in the Linode + Dev hackathon:
Top comments (0)