I have been working on Kubernetes for the past few weeks. Here is my thoughts.

I have been working on Kubernetes for the past few weeks. Here is my thoughts.

·

6 min read

A few weeks ago, I was fortunate enough to be involved in migration to Kubernetes in my company. We were running our nodeJS-based monoliths app in a single Compute Engine setup and decided a change to run on Google Kubernetes Engine. To be fair, my knowledge on Kubernetes was "just enough to show off" at that point of time. However, I am comfortable in Linux commands and Google Cloud, have experience in Go and Docker, which were extremely helpful in learning Kubernetes.

Learning Curve

Kubernetes has been well-known for steep learning curve compared to similar solutions. I had the exact feeling when I just stepped in to it. Not to mention how complex are CNCF projects. If you look at the landscapes, there are a lot of new words or concepts that I never heard of, and no idea what's going on.

I started to looked for online resources, and simply copying example yaml files and just hope it works. But it didn't work that well. So I took a step back, and start reading the documentations. It wasn't so straight forward though. There were so much unknown terms in the equation. For example, people often use Kubernetes with Prometheus and Grafana. My first impression was like "WTH are those?"

I will cover those in the below sections.

Read and read documentation

Don't get me wrong, the official Kubernetes was nice to read. However, the API reference was hard to navigate. I kept jumping back and forth on the API reference docs, due to the yaml spec has nested fields. When I clicked on it, it brought me to another section of documentation and vice versa. The experience of reading the API reference was not that good.

On the other hand, Google Cloud documentation is the best in class in my opinion. It provides different options on doing the same action with tabs as shown as example below.

GKE documentation

But do pay attention on limitation section, the GKE ingress I created does not reflect the new changes and I have no idea what was going on for few days. Then I found the answer on limitation section of the docs.

Docker

You need to learn Docker, if you wanted to run your application on Kubernetes. Try to reduce the image size as small as possible. The smallest I can get for monoliths NodeJS based app was around 775MB. I wasn't sure how to optimised any further. Put that with the Go based side project that I was working on, it was just 22 MB and unoptimised. I found out the hidden feature of Google Container Registry. If you click on the column on the Container Registry's console, it has the virtual size option. It shows the size of the images after compression. Roughly about 50 % in size reduction.

Google Container Registry console

Logging

Log is your best friend when you have no idea what you did wrong.

You need to know how to read logs from Kubernetes before anything else.

I had to emphasise on this. Because of this, i have spent fair amount of time on guessing what went right what went wrong. If you happened to use GKE like me, you can read the logs from Stackdriver Logging, or from kubectl logs

Monitoring

A monitoring project, Prometheus often used with Kubernetes. However, it wasn't so straight forward to setup Prometheus in my opinion. Luckily, we can use Helm to setup Prometheus, along with Alert Manager and Grafana via prometheus operator. However the problem with Helm is you need to read the values.yaml or docs to know the default values or customise values on your own.

What did i get from here

I learned a lot from the past few weeks, and it did not stop here. Cloud Native projects are indeed very complex, yet powerful. I have better understanding on other CNCF projects as well. Kubernetes is a very wide topic, and it is keep evolving. I encourage everyone to start to learn today!

Cover image taken from unDraw

Did you find this article valuable?

Support Wei Lun by becoming a sponsor. Any amount is appreciated!