Funny, I know a decent amount about k8s these days, but I've never really used AWS. I think there's a lot of systems that try to solve the same problems: "define these services, keep them running, here's how to check if they're down, here's how to restart them, keep resource usage to this level." Systemd, kubernetes, and individual cloud providers all have their own way to describe these.

One of the upsides of k8s is that it gives you a general, platform-agnostic way to describe this, on AWS or GCP or self-hosted or whatever. The downside is that it's more flexible and therefore more abstract than any particular provider. The upside is that you only have to learn one set of concepts (in theory).

Closet one from your list is ECS.

AWS ECS is basically a docker swarm cluster customised by AWS to include auto-scaling of service containers/nodes and generally integrating better with other AWS services.

k8s is that orchestration layer, but on anabolic steroids. Plus a standardised interface on any cloud platform you might need to run on.

With bigger muscles comes more complexity, more maintenance work etc. (was designed for orchestrating millions of containers, so way more complexity)

which is why everyone always moans about it. (including me)

It’s a very cool and very useful piece of tech when yielded correctly. Just don’t expect it to work like a “kitchen sink”.

Sort of.

Each of those have their own k8s implementation.

It's a standard way to define and run container workloads (jobs, services, etc) and related resources like storage, configs, secrets, etc.

Yes, although a slightly higher abstraction layer that can be implemented by those things. So one can theoretically describe a complex environment in a way that can be run on prem or by a variety of cloud vendors.

(don't @ me just to say it's more complicated than that)