Quick Experiment: K3s Cluster (ECS vs. K8s Reality Check)

Why I Built It:

Having spent years managing workloads on AWS ECS, I wanted to understand why Kubernetes remains the dominant platform. Instead of cheating with an AWS EKS managed service, I spent an afternoon setting up a lightweight K3s cluster (1 master, 2 worker nodes) on my homelab to see how Kubernetes handles platform primitives directly.

---

The Realization: A Cloud Inside a Server

Even within a short period of testing, the shift in mindset between ECS and K8s was immediately obvious:

• AWS ECS feels like an opinionated, simplified service that hides the heavy lifting.

• Kubernetes (K3s) behaves less like a container runtime and more like an API-driven cloud provider running inside my own infrastructure.

The concepts mapped over almost perfectly to my AWS experience: Namespaces felt like multi-account isolation, Services mirrored Load Balancers/Route 53, and K8s Secrets replaced AWS Secrets Manager.

---

What I Explored (The 3-Hour Scope)

• Standardizing multi-node deployments and understanding how the K8s scheduler distributes workloads.

• Testing Namespace isolation and internal Service Discovery.

• Deploying applications using Helm charts to evaluate package management compared to AWS Task Definitions.

Pragmatic Takeaways

1. Flexibility is a double-edged sword. Kubernetes exposes raw platform primitives. It gives you ultimate control, but it also instantly introduces an operational and integration tax that ECS completely avoids.

2. Kubernetes is a platform for building platforms. It is inherently designed for an ecosystem of plugins and extensions, making governance and tooling selection critical from Day 1.

3. The Complexity Question: For small to medium teams already embedded in AWS, the operational overhead of managing Kubernetes (even managed EKS) is hard to justify when ECS can handle the same workloads with a fraction of the friction.