I Advocated for Containers in 2019 — They Rolled It Out in 2022

Back in 2018, I took on a freelance role at a large organization. Together with one other engineer, we were responsible for keeping dozens of short-lived websites up and running — all the underlying infrastructure, coordination with development agencies, and the bridge between internal IT and external infrastructure providers.

The websites themselves were built by agencies. Our job was everything around it: deployments, environments, scaling, stability, and being ready when something broke.

The Setup

At the time, the system ran on a traditional LAMP stack — Apache, PHP, and large autoscaling nodes. Multiple website vhosts lived side-by-side on the same physical servers. If one crashed, it risked taking down others. It worked, but it wasn’t isolated, nor flexible.

I thought there is room for improvement.

I started suggesting: „What if each site ran in its own container? Small, isolated, easily restarted, easily scaled. And what if we transitioned to a Kubernetes-based setup?“

The Reaction

The idea wasn’t rejected — but it was too early.

We were at the bottom of the chain. Most architectural decisions came from centralized IT, and change moved slowly. Some of the stakeholders preferred the familiar stack. Others simply didn’t see the need. And frankly, the incentives to modernize weren’t strong at the time.

So we stayed with Apache. We stayed with full-node scaling. And we kept handling incidents the old way: reviewing logs, identifying which site caused issues, and reacting.

Still, I documented the containerization proposal. I outlined why it mattered — not just for scalability, but for reliability, security, and maintainability.

Then I let it go.

What Changed

By 2022, years after I had left the role full-time, the company began rolling out containers. Kubernetes. CI/CD pipelines. Site isolation.

I wasn’t involved in the rollout. But I smiled when I saw it happen.

Not because it proved me right.
But because it reminded me:
Sometimes, technical clarity doesn’t need immediate confirmation. It just needs time.

What I Took From It

This wasn’t a glamorous project. There were no shiny products, no launch announcements. I wasn’t there to force change. I was there to keep things running, improve what I could, and plant seeds when I had the chance. Some of those seeds took years to grow. But they did.

Final Thought

You don’t always need to win the argument to know you’re on the right path.

Sometimes, your best work is the kind that takes years to be seen — and still holds up when it finally is.

Accessing remote minikube UI via SSH port-forwarding

tl;dr

Get the k8s node’s IP address (the one which runs the dashboard), with:

minikube dashboard --url

Use this IP and do a local port-forwarding, with:

ssh cgiehl@server -L 30000::30000

Today, I was trying out minikube, a simple way to setup a k8s „cluster“ locally and play around with it. Unfortunately, „locally“ didn’t quite work out for me since I was heavily running out of disk space 😀 I’ve heard a lot of ppl and their excitement about running minikube locally, but as soon as you ask them how to quickly run it on a server to mess around, it’s always the same: „On a server you want to setup kubernetes fully!“. Since this was not the answer I was looking for, I took a quick glimpse at my Ubuntu home-server in the corner and gave it a shot!

The installation was super easy and super fast (as expected), however, the moment the official docs stated:

To access the Kubernetes Dashboard, run this command in a shell after starting minikube to get the address:

minikube dashboard

Nothing openend in my SSH login shell 😉 Of course, you can enable X11-forwarding but since the dashboard is accessible via a browser, I wanted to use my local browser anyways. But…

What is the dashboard’s IP?

Now things get interesting and I want to show some ways on how to obtain them. The first thing I tried was

http://192.168.99.100:30000

https://github.com/kubernetes/minikube/blob/09f683bb1d5ea74f649d2829b68227c4ddc8b0eb/cmd/minikube/cmd/dashboard.go#L72-L77

server:~ cgiehl$ kubectl get services --all-namespaces

NAMESPACE     NAME                   TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)         AGE

default       kubernetes             ClusterIP   10.0.0.1     <none>        443/TCP         41m

kube-system   kube-dns               ClusterIP   10.0.0.10    <none>        53/UDP,53/TCP   41m

kube-system   kubernetes-dashboard   NodePort    10.0.0.36    <none>        80:30000/TCP    41m

Now we have the exposed port running on 30000. Still we need the IP address!

A search in the repo gave me, that port 30000 is the default port, specified in the service.yaml.

server:~cgiehl$ kubectl describe nodes minikube
[...]
Addresses:
  InternalIP:  192.168.99.100
  Hostname:    minikube
[...]

After figuring that out, I thought this needs to be easier. It turned out, that there even exists a CLI flag for minikube dashboard it (idk since which version).

server:~ cgiehl$ minikube dashboard --url

which directly gives

http://192.168.99.100:30000

Further reading: