My guess: commenter will soon claim that docker containers and yaml manifests are too complicated. That’s what I tend to see when vague comments like this are left.
Now, I saw a straw man somewhere…
Is there a learning curve to adopt k8s? Of course! What tech doesn’t have some sort of learning curve?
If you are an application developer, there’s very little of the underlying systems that you need to know about or be concerned with. Build a container image that runs your process and exposes a port. Some trivial yaml can launch that image and attach storage and network. Everything else is done for you.
Sure, things get more complicated if you have complicated deployment needs or try to run workloads in k8s in a non-standard way, but that’s true of any system.
Before container orchestration systems there was just as much complexity. You had to ship the code to remote machines, maybe with config management, but probably ssh and a git pull. You had to signal a restart, to some process monitor, init.d, systemctl, or something like eye or god. You had to check if the service was available. You had to expose ports and route traffic. You had to handle crashes. You had to reboot. You had to monitor resource usage. You had to secure the network. You had to bubble up events to be visible to operators, you had to handle phased rollouts. You had to be able to rollback failures.
The list goes on…
There’s just as much complexity deploying services at scale with or without k8s. Without k8s though (or nomad to some extent), all that complexity is scattered across various ad-hoc systems that are OS dependent whereas k8s wraps everything and exposes a common and documented api, and an orchestrator that gathers and emits easily digestible events every step of the way. It’s a framework in a sense. The same way you can jump into a rails code base and know generally where to find things, you can ship your container images to any k8s cluster and should be able to get the same results with little to no drift between each cluster.
Does everyone need k8s? Most don’t need it. But, I’ll argue that if you’re deploying services in a highly available and fault tolerant way, you’re going to be just as complex, if not more, without k8s.
But we don't live in the time before container orchestration, we live in the time of managed services that autoscale and deploy our apps in several lines of yaml.
I think when people make the suggestion k8s is overly complicated for their needs they are referring to that comparison.
The choices aren’t k8s or managed cloud offerings.
The choices are k8s, managed cloud offerings, bare vms, or bare metal.
Managed cloud offerings are expensive. Plenty of shops are still provisioning virtual machines from a minimal OS image, or renting cheap metal that can get them much further for a fraction of the cost.
Plenty of people operate in a pre-container orchestration world today and that isn’t going away.
