My First Time with K8s, Helm, and Terraform
Starting from Zero
When I joined Seaional, I'd deployed to Vercel and Railway. Docker was comfortable. But Kubernetes? Terraform? Helm? These were things I'd read about but never touched in production.
Three months in, I'm not an expert-far from it. But I've learned enough to be dangerous, and I want to share what that journey looked like.
Kubernetes: The Mental Model That Clicked
For weeks, Kubernetes felt like arbitrary YAML incantations. Deployments, Services, Ingresses, ConfigMaps-each resource type seemed disconnected.
The mental model that finally clicked: Kubernetes is a declarative state machine. You don't tell it what to do; you tell it what you want the world to look like, and it figures out how to get there.
A Deployment isn't "run these pods." It's "I want 3 instances of this container running at all times." Kubernetes handles the how-scheduling, health checks, restarts.
Once I understood this, the pieces fell into place. Services are "I want these pods reachable at this name." Ingresses are "I want external traffic to route here." It's all declarative state.
Helm: Package Management for YAML
My first reaction to Helm: why do I need a package manager for YAML files? Can't I just... write YAML?
The answer became clear when we needed the same service deployed across dev, staging, and production with different configurations. Copy-pasting YAML files and changing values manually? That's how mistakes happen.
Helm templates let you parameterize everything. The same chart deploys to any environment-just swap the values file. And when you need to update something across all environments, you change it once.
The learning curve is the Go templating syntax. It's powerful but not intuitive. I still copy-paste from Stack Overflow more than I'd like to admit.
Terraform: Infrastructure as Actual Code
Terraform clicked faster because it's closer to programming. You define resources, they have dependencies, Terraform figures out the order.
What surprised me: how much state management matters. Terraform's state file is the source of truth for what exists. If you mess with infrastructure manually, Terraform gets confused. I learned this the hard way when I deleted a test resource through the Azure portal and spent an hour figuring out why Terraform was angry.
The workflow that works: never touch infrastructure directly. Everything goes through Terraform. Treat the state file as sacred.
What I'm Still Learning
Networking in Kubernetes. I can get things working, but I don't deeply understand CNI plugins, network policies, or why certain things need ClusterIP vs LoadBalancer.
Helm chart best practices. My charts work, but I'm sure they're not idiomatic. I need to read more examples from experienced teams.
Cost optimization. We're probably over-provisioned, but I don't yet have the intuition for right-sizing resources.
Disaster recovery. What happens if our cluster dies? I've read about backup strategies but haven't implemented one.
Advice for Fellow Beginners
Start with a managed Kubernetes. Don't try to run your own control plane. AKS, EKS, or GKE handle the hard parts.
Learn kubectl commands early. kubectl get, kubectl describe, kubectl logs-these are your debugging tools. Get comfortable with them.
Use k9s. It's a terminal UI for Kubernetes that makes exploration so much easier than raw kubectl.
Don't be afraid to break things in dev. I learned more from debugging broken deployments than from tutorials.
Read the error messages. Kubernetes errors are verbose but usually tell you exactly what's wrong. Don't skip them.
I'm still early in this journey. Ask me again in a year and I'll probably cringe at this post. But that's how learning works-you have to be willing to be wrong in public.