Live data from Hacker News

The Cult of Kubernetes

christine.website

331–338 of 338 posts

Re: The Cult of Kubernetes

#331

I am one of these guys who is using K8S at home. The reason is a unified platform for work and home environment.

Same here, I run K8s both locally and on GKE for a project. My GKE cluster is just 2 nodes that have 2vCPU & 3.75GB RAM each. Performance is great and it has saved me an insane amount of time. I have also created an open source project that does one thing - updates your deployments :) https://keel.sh . Previously I tried several different hosting options but nothing is easier/more convenient than k8s for me.

Thanks a lot ! Keel looks exactly like something I would need!

Re: The Cult of Kubernetes

#332
post #288
post #251

Earlier quoted context omitted.

...and the crux of the problem is where people who have never encountered the problem Kubernetes solves, still start using Kubernetes.

I think the crux of the problem is that everyone encounters the problem Kubernetes solves. As the GP states, Kubernetes gives you "infrastructure as code" so that application infrastructure can be managed in a way similar to application source code (e.g. PRs, blame, code reviews, CI, rollbacks etc). This helps ops people because it allows them to think about infrastructure as abstract resources rather than as a colle…

> Who doesn't want that? Of course you want that.

If you only have a couple of servers you probably want to think of them as individual machines rather than abstract resources. A lot of equations simplify when you set x to 1.

Re: The Cult of Kubernetes

#333
post #245

Earlier quoted context omitted.

I think k3s is sort of trying to do that?

Have you tried it? Is it any good? I've been looking for a simpler Kubernetes, although I don't know how much simpler it can be in practice and still do the same things.

I've tried k3s, and while I was impressed, it leaves out several important features.

RKE is a great alternative, and kubespray is quite stable well.

Re: The Cult of Kubernetes

#334

Earlier quoted context omitted.

My point is that if "infrastructure as code" is your sole requirement, Kubernetes doesn't seem like the first choice. Adopting Kubernetes is not a small task, but it seems to be the go-to answer for a lot of the HN crowd. Don't get me wrong: it's a great tool for some things. But IMO, for 80% of projects it's completely overkill.

K8s is the only IaC platform with heavy buy in by all the major public clouds.

I'm not particularly interested in limiting myself to using only the tools that large companies have deemed worthy.

There are plenty of tools out there that can get the job done at the scale that the vast majority of businesses operate in with lower operational and cognitive overhead than Kubernetes.

Re: The Cult of Kubernetes

#336
So many red flags in this article.

So the author was previously using dokku. Dokku was cool, and was basically a docker-based heroku clone. The keyword here is heroku, because dokku basically brings away a lot of the operations work that is needed to actually run a service, at a small scale, with reasonably good results. Dokku was cool, but it didn't really scale beyond one node (unless you have multiple machines running dokku, of course)

So with dokku gone, the author still wants the features of heroku, and still doesn't work to peform all the operations work. So the author goes to Kubernetes and realises that there's operations work to do.

Guess what? Somebody still has to do the Operations part. If you don't want to do pay for some managed hosting (like, as per previous keyword, heroku) you'll have to do it yourself. Have fun.

Now, kubernetes is complex and the learning curve is steep. Kubernetes is designed to scale up to hundreds of nodes. Needless to say, complex tasks require complex tools.

Complexity has to be paid somehow. Either you pay in money (Heroku) or you pay with your own time and efforts.

Once again, there's nothing new under the sun: there's no free lunch.

Re: The Cult of Kubernetes

#337

Earlier quoted context omitted.

My point is that if "infrastructure as code" is your sole requirement, Kubernetes doesn't seem like the first choice. Adopting Kubernetes is not a small task, but it seems to be the go-to answer for a lot of the HN crowd. Don't get me wrong: it's a great tool for some things. But IMO, for 80% of projects it's completely overkill.

+1. Infrastructure as code is exactly that, code. For AWS it is Cloudformation template code, Cloudformation service and some CI/CD on top, like jenkins or ansible. Or Terraform for unlucky ones. K8s is container orchestration, like AWS ECS, totally different beast.

CloudFormation is for the lucky ones and Terraform the unlucky ones? I'm thinking you've never used one of the two...

Re: The Cult of Kubernetes

#338

Earlier quoted context omitted.

+1. Infrastructure as code is exactly that, code. For AWS it is Cloudformation template code, Cloudformation service and some CI/CD on top, like jenkins or ansible. Or Terraform for unlucky ones. K8s is container orchestration, like AWS ECS, totally different beast.

CloudFormation is for the lucky ones and Terraform the unlucky ones? I'm thinking you've never used one of the two...

On AWS, Cloudformation is far more reliable and lean (less LOC) than TF. No corrupted state issues, all resource properties are supported, parallel (fast) resource creation just for starters. And TF sales pitch about "multi-cloud" is nonsence, resources are too different between different clouds.
Post reply on HN