So you want to use Kubernetes?

Warning: The following essay is purely a work of fiction. Any resemblance with existing products, open-source projects or wales is pure coincidence.

This blog runs on Kubernetes.
Setting it up was super simple. I just had to follow tutorials, copy-pasting things here and there to get a new Kubernetes cluster.

Is that what Serverless is? I have docker containers that run somewhere magically, and I don’t need to worry about servers.
It’s the future after all. Everyone is running Docker on Kubernetes these days. So let’s jump to 1985 erm I mean 2025.

Can I be internet famous?

My cluster works awesomely. It can start containers, handles upgrades nicely and more and more people have started reading my blog, because it’s awesome. So I’ll just head home now.

Until one day, I write a great article about a Kubernetes story which reaches the front page of some big news site. No problem, I can scale up the number of running Pods.

Holy Batman, my site is down!

I have a single server running my blog. What? When I started more containers, I didn’t get more servers as well? I thought this was serverless.

All right, this is easy enough. I’ll need to setup an autoscaler.
That’s around 100 lines of yaml and I’m good to go.

I now have an autoscaler running inside my cluster as a new Pod which monitors the number of running Pods and will change my cloud provider’s autoscaler to run the appropriate number of instances.

My autoscaler configures the cloud provider’s autoscaler.

Once the traffic starts slowing down, I can reduce the number of Pods running my app.
This finally starts feeling like Serverless again, where I can focus on my blog’s core features, and not lose time on infrastructure.

I want superman’s vision

Obviously, I’m using an analytics tool to know what my traffic is. But how do I know how many Pods I need to handle 1 request? How about 1k?

How do I know if my Pods have memory issues? And how many I can run on each server (how come we’re still talking about servers at this point?)

So I’m going to setup prometheus-operator.
It’s just a bit more yaml anyway. And YAML isn’t real code, so that doesn’t count as technical debt.

Prometheus is hard to use though. I’m not smart enough to work at Google and I want to focus on my app’s code, not on writing queries to find the data I need, so I’ll setup grafana.
Again, it’s just a bit more YAML, which doesn’t count as code. I’m getting good at this!

I should setup remote storage for Prometheus too. But this starts going too deep, so I just won’t care about it for now. I’m not Google after all.

But I can’t see

Accessing my Prometheus and Grafana interfaces is super easy. I just need the following bash script:

#!/bin/bash -e
appName="$1"

case $appName in
	prometheus)
		port=9090
		podName=$(kubectl get pods -l prometheus=prometheus -n monitoring -o jsonpath={.items[0].metadata.name})
		;;
	grafana)
		port=3000
		podName=$(kubectl get pods -l app=grafana -o jsonpath={.items[0].metadata.name} -n monitoring)
		;;
	*)
		die "Unknown service to proxy '$appName'"
		;;
esac

kubectl port-forward $podName $port -n monitoring

And if I run ./my-script prometheus and open localhost:9090, I will see my prometheus dashboard.
This isn’t really a great interface though. If I get an alert at 3am on a sunday (why do alerts seem to always trigger on very early sunday when I’ve been partying all night?), I want to be able to access my monitoring data more easily than that.

So let’s setup a web interface that allows me to access my dashboards more easily.

Note: In a real world situation, we would already have a web interface to serve the blog itself, or course. This isn’t a real situation though, chop chop.

I will use ingress-nginx to have a single Load Balancer and spare my costs a bit.
Even more free code which is yaml, awesome.

EH BACK OFF! I saw you accessing my dashboards. Those are private!

I am going to secure my HTTP access with oauth2_proxy, because people are just mean and won’t keep off accessing my private data if I don’t prevent them from doing so.
We know the drill by now, it’s just a few more yaml.

Since we’re on the subject of security, I’m going to enable SSL too with cert-manager.
I’m really starting to love this yaml thing.

I can have nice things

I’m quite happy. My super awesome blog works fine now.
And it’s so much better than hosting it as a static site. Things that are too simple sucks.

This is what all the pods in my cluster look like. The first 2 ones (I censored them for obvious security reasons) are my blog.
Everything else is what allows me to run it. I can finally focus on my blog’s code without having to worry about infrastructure!

And all this runs for free. All I had is a total of 7202 lines of YAML. Not a single line of code!

This is bullshit right?

Warning: the fiction stops here (or does it?)

This blog doesn’t run on Kubernetes. It’s actually a static site generated by nanoc, with code hosted on GitHub and auto-deployed by circle ci to S3 and ultimately served by CloudFront.

This story is based on the real fun I’m having spending my days writing YAML and booting more containers to handle a relatively simple process which is Heroku’s Docker Builds, and how we’re ending up with more things not directly related to what we need to be able to support that.`