Last Friday afternoon (February 25th), our Innovative Tech unit had a ‘Tech-Friday’ knowledge sharing session, and I’m here to tell you all about it! Organized by the experienced Gopal Ramachandran and Miguel Lopes, this afternoon was all about coming together as colleagues and gaining more knowledge about Kubernetes. It was a beginner-friendly workshop covering the basics, including a challenge for those who were more experienced in Kubernetes.
Even though I am technically not part of this unit within Devoteam, it was great to partake in this learning experience because the topics covered were very relevant to the work I do as a consultant in my client project. This blog post will cover three of the key topics that were discussed, covering the basics of Kubernetes. Below you see the slide that was presented to display the 6 key values of our Tech Friday sessions.
Containerization & Kubernetes
While containers are similar to virtual machines, it’s a more lightweight way of setting up an application because containers share the Operating System among the applications. Furthermore, there are other benefits to applying containers such as consistency across different platforms and resource isolation. You need to manage these containers. This is where Kubernetes comes in. It’s is a framework that orchestrates these containers and automates processes like deployment and scaling. During this Tech-Friday, we installed Minikube, which allowed us to run Kubernetes locally.
Relevant resources:
- Want to learn more about Kubernetes? Watch our on-demand webinar called Kubernetes: form Zero to Hero.
- Looking to obtain the CKA or CKAD certificates? Check our this useful blog post with tips.
Cluster, Nodes & Pods
I’m starting with nodes, which are machines that run your workload. There are two types of nodes, the master node, and the worker node. The master node is comparable to a brain that controls and manages the hands and feet – the worker nodes. Usually, this means that there will be multiple worker nodes and also multiple master nodes to manage them. The collection of all of these nodes is called the cluster.
What do the nodes actually run? One of the most important things are the pods. These are meant to be replicable and easily scalable. So if your application is under heavy load, multiple instances can be created to carry this. Pods contain the container which runs your application. While pods can hold multiple containers, it’s usually one container per pod. It’s possible to create pods individually, but this would take a lot of time and effort. This is where a deployment comes in. In a deployment, you describe the desired state and let Kubernetes handle the rest. Now if you desire a constant four pods, Kubernetes will make sure they all four are running and will replace one if it goes down.
Service and Ingress
Okay, you’ve got your application running on multiple pods. But now what? Now it’s time to actually connect to the application. Luckily, Kubernetes makes this quite an easy process by introducing a service. This exposes the application as a network service. Pods can come and go, meaning that noting the names each time would be chaotic and inefficient. But a service assigns a name and IP address to these pods and handles load balancing across them, making it easier to connect.
Now that you’ve got a connection to your application you want to put it out there into the wide world. This is where ingress comes in to give your application a route to success. Ingress exposes the HTTP and HTTPS route from outside the cluster to a service inside the cluster. Meaning that with the proper configuration you can now go to a URL and see your application in your browser. Now let’s say you’ve spammed all of your friends with this URL to check out your new application. Ingress also comes with a controller that load-balances so your wonderful application can handle the influx of users.
Conclusion: Testing our learnings with Mario Bros
Amongst others, these three topics were explained to us in a nice presentation. To test our recently gained knowledge and skills, we were challenged to first play around with each component and then apply it all to get Mario Bros running in the browser. Spoilers: The only image I got in my browser was a JPEG image, sadly not a Docker image. While I didn’t get a sense of nostalgia by playing some Mario Bros in my browser, I still learned quite a lot about Kubernetes in a short time.
I’m very glad that I was invited to this Tech-Friday. Many thanks to Miguel and Gopal for giving us the opportunity of expanding our knowledge and having a nice techy Friday afternoon together with colleagues. I’m looking forward to the next one!
