How is it blatantly arguing for this thing when it literally calls it extreme and something that doesn’t exist? I think a more fair criticism would be the fact they don’t call out vendor lock-in as a tradeoff
> to throw Kubernetes into the mix just to run some controllers that deploy those services will pointlessly add to your monthly bill.
I think you have a valid point it may be dubious but the article does outline purported reasons it could make sense for some people. I dont think there is a “right way” and a “wrong way” here, rather there is the way “you would do it” and “the way they’re proposing as an option”
> Someone defines Kubernetes as “a well-designed and extensible API with programmable reconciliation logic, that happens to come with a container orchestrator built in.” I like that definition.
I think this is an unfair summary of the post. Of course, using Kubernetes to orchestrate other AWS services is going to be a go-to example on the _AWS_ blog, but there is plenty of vendor-agnostic software doing similar things: DNS Records[1], Databases[2], even using Kubernetes CRDs to deploy Kubernetes[3].
The idea of using Kubernetes as an API to orchestrate external resources doesn't inherently lock you into any single vendor.
1: https://github.com/kubernetes-sigs/external-dns 2: https://github.com/kubedb/operator 3: https://cluster-api.sigs.k8s.io/
Overhead is as follows (/month):
1 x load balancer: $20
3 x master servers: 4GB RAM, 2 CPU, 15 GB SSD: 3 * $20 = $60
also on every worker server around 15% of RAM is dedicated to kubernetes pods (kubelet). So slightly higher price for RAM and CPU.
So basically overhead is like $100/month. Or $50/month with one master server which is not very reliable but acceptable for small workloads. If your project runs on $5/months VPS, Kubernetes is pure overhead. If you're paying $500/month, Kubernetes is something to consider.
That would mean you need the K8s API for your control plane but not necessarily that you have to run a K8s cluster or clusters as long as the API layer is the same. Maybe the control plane is a managed service too and you just interact with it.
I'm a bit skeptical of these single pane of glass type solutions since the abstractions always end up being somewhat leaky. The abstraction turtle stack is so high at this point you have to know 11 different technologies just to start a process on a Linux box.
But I get the operational appeal of having a central control plane rather than a million control planes all with their own AuthN/AuthZ, logging, custom YAML DSL, APIs, security configurations, integration points etc.
One of the big benefits of Kubernetes is the cloud-agnostic API for running pretty much any application. CustomResources can help blur that boundary and make it easier to use some managed services, but actually arguing in favor of that approach for everything is a pure advertising tactic.
It's no secret that managed services are several times more expensive than equivalent EC2 time. Sometimes it's worth it. But to throw Kubernetes into the mix just to run some controllers that deploy those services will pointlessly add to your monthly bill. Running any Kubernetes cluster is not cheap, even if it's just a bunch of controllers.