Lesson learned: Kubernetes basics

Posted on November 20, 2020

3 minutes  • 520 words

This week was pretty stuffed with daily business, so there was not too much new insight until friday: At the end of the week, I had a chat with my colleague about kubernetes, because I’m a noob here and didn’t get some of the basics.

Services are identified by it’s name (and namespace)

So this was a stupid one, which I couldn’t get my head around:

I pretty much knew, how to get stuff into kubernetes with Helm and so on, but then I didn’t get how the different pods speak with each other. The answer is, that every pod (or group of pods) is wrapped into a “service” by kubernetes automatically. In my imagination, these are like internal reverse proxies which group pods together. Those services can be addressed inside of kubernetes simply by calling the service name. So if you have e.g. a postgres database deployed under the name “pg”, you can tell your application to simply call

postgresql://pg:5432/<database>

There’s one exception: If you need to access services between different namespaces, you need to used <namespace>/<service> to make sure, that kubernetes knows what you’re targeting. So if your datbase is in the space “ops”, you can address it by

postgresql://ops/pg:5432/<database>

Ingress - the gate to the outside world

So the Ingress in Kubernetes is really a reverse proxy which bridges between the outside world and our kubernetes cluster. I knew, that we need to “configure” it, but not how exactly I can tell, which requests need to be routed where. First of all, I had a fundamental wrong understanding, because I thought there’s “the” Ingress that routes stuff. However, in kubernetes every application can have it’s own Ingress. So if you deploy 3 applications, it could be that every app has an own Ingress implementation with it’s own external IP. As we have some loadbalancers in front of our cluster, I just needed to deploy a new ingress which listens for the intended URL et voilá, it already worked.

Deploying Helm charts

Helm charts are pretty cool, because there are so many pre-defined templates which just need to be altered a bit to deploy stuff. What the documentation doesn’t tell you (or at least I wasn’t able to pick it up): How to deploy pre-existing charts? My attempts of my own always were like checking out the chart via github, alter it and try to deploy it somehow to kubernetes. However, this is not how it’s intended! 😁

So my new workflow is simple: I create a new folder with a yaml file (values.yml) that overwrites values defined by the chart. Which values can be overwritten is dependent on the chart and can be looked up in the documentation (e.g. the github repository).

Then I create 2 shell files that will allow me to deploy and to update the chart.

deploy.sh:

$ helm install --values values.yaml <target chart> --namespace <namespace> --name <service-name>

upgrade.sh

helm upgrade --install --values values.yaml <service-name> <target chart>

…and that’s it!

So basically one can deploy and maintain the helm application by creating three simple files. This is pretty awesome!

Have a nice weekend everyone!