Search for a command to run...
Bringing It All Together: K8s Hackathon
No comments yet. Be the first to comment.
A dev-friendly crash course you can finish before burnout kicks in.
Or how to tame the container beast without selling your soul to YAML
I recently watched a short video by Carly Taylor on gamer mindset. In that 1 minute video, she talks about Chris Sawyer and how he wrote the awesome game of Roller Coaster Tycoon entirely in assembly (all by himself) because the compute power at the ...
I recently published an article on how to build an MCP server in C# (https://tjgokken.com/building-your-first-model-context-protocol-server-in-c). On that article, we built a simple MCP-style server. It remembered things, stored context in memory. Th...
Because APIs Aren't Confusing Enough Already
Or how to tame the container beast without selling your soul to YAML
We’ve done the deep dives, spun up pods, set configs, scaled deployments, and opened the front doors with services. Now it’s time to pull everything together into a mini project you can actually use - or at least show off proudly. It even makes a great talk for your local User Group.
Something simple. Something clear.
We’re going to deploy a tiny three-tier web app:
Frontend (nginx serving a static HTML page)
Backend API (dummy Node.js app returning JSON)
Redis (caching layer, but makes us feel super fancy - and also good to wow your audience during those user group talks)
Everything will:
Use deployments with probes
Be organized with labels
Be grouped with namespaces
Use services for communication
Have config managed via ConfigMaps and Secrets
It may sound complicated but we actually have gone through all of these individually in the past 6 days. We are just bringing them together now.
Before we start, let’s visualize how this is all going to fit together using a Mermaid diagram:
Well, then, let’s go.
Step 1: Create a new namespace
kubectl create namespace demo-stack
Step 2: Deploy the Redis pod
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis
namespace: demo-stack
spec:
replicas: 1
selector:
matchLabels:
app: redis
template:
metadata:
labels:
app: redis
spec:
containers:
- name: redis
image: redis:latest
kubectl apply -f redis-deployment.yaml
And expose it:
kubectl expose deployment redis --port=6379 -n demo-stack
Step 3: Deploy the backend
Use a dummy image like ealen/echo-server
apiVersion: apps/v1
kind: Deployment
metadata:
name: backend
namespace: demo-stack
spec:
replicas: 1
selector:
matchLabels:
app: backend
template:
metadata:
labels:
app: backend
spec:
containers:
- name: backend
image: ealen/echo-server
ports:
- containerPort: 80
kubectl apply -f backend-deployment.yaml
kubectl expose deployment backend --port=80 -n demo-stack
Step 4: Deploy the frontend
Use nginx + a ConfigMap with an index.html
kubectl create configmap frontend-html --from-file=index.html -n demo-stack
apiVersion: apps/v1
kind: Deployment
metadata:
name: frontend
namespace: demo-stack
spec:
replicas: 1
selector:
matchLabels:
app: frontend
template:
metadata:
labels:
app: frontend
spec:
containers:
- name: nginx
image: nginx:latest
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html
volumes:
- name: html
configMap:
name: frontend-html
kubectl apply -f frontend-deployment.yaml
kubectl expose deployment frontend --type=NodePort --port=80 -n demo-stack
Step 5: Access the App
Get the frontend NodePort:
kubectl get service frontend -n demo-stack
Open it in a browser:
http://localhost:<your-port>
This is a screenshot of what you will see in your browser:
Congratulations — you did it.
7 Days ago, Kubernetes was a just a word we saw in memes, and maybe in some LinkedIn posts. Today, you just built a living, breathing Kubernetes app stack from scratch.
We started out with pods and containers, scratching our heads over why everything had so many moving parts. Then we added deployments, labels, configmaps, secrets, services, autoscaling... and somehow it all started to make sense.
You’ve seen how Kubernetes keeps things running even when individual parts break. You’ve seen how apps talk to each other without caring where they physically live. You’ve seen how scaling happens automatically when you need it, not when you beg it. We even witnessed firsthand why using Linux sometimes just makes life easier (looking at you, windows 👀). I’m not a Linux zealot either — just a pragmatist. best tool for the job, always.
Is this DevOps?
Yeah, you could say that. But honestly, it’s just good engineering.
As developers, we don’t have to become Kubernetes admins or experts overnight. But knowing how our apps actually live and breathe inside a cluster? That makes you a better developer — plain and simple.
You’re no longer just writing code and throwing it over the wall, hoping someone else figures out deployment, scaling, health checks, and resilience.
Now you understand it. Now you can build better apps that belong in production. Apps that behave nicely when the going gets rough.
And even if you don't work directly with Kubernetes every day, just having this knowledge under your belt changes how you think about building software.
You don’t fear the cluster anymore.
You speak its language.
You know where your app fits in.
And that?
That’s power.
That’s a wrap for Kubernetes without the tears.
If you made it this far — thank you. i hope this series made Kubernetes feel a little less scary and a lot more doable.
This was just the beginning. there’s so much more we can build — dev containers, more real-world apps, advanced scaling patterns — and I plan to keep writing about all of it.
If you liked this series, feel free to share it with a friend, a colleague, or that one person still afraid of YAML files.
And if you ever want to swap ideas, ask questions, or just nerd out — you can always find me at tjgokken.com.
Until next time — happy building.