Hacker News new | past | comments | ask | show | jobs | submit login

What's wrong with Kubernetes from day one? I'd use it from day one everywhere. Avoiding kubernetes is a sign of technical incompetence.



Nah, statements like the above are a sign of lack of experience, missing business understanding and/or hubris.


> What's wrong with Kubernetes from day one? I'd use it from day one everywhere. Avoiding kubernetes is a sign of technical incompetence.

Everywhere? Sounds like you're cargo culting.

There's a use-case for it, and that use-case is when your load is so high you need the orchestration.


Kunerbetes works just fine on a single node. And it provides a lot of good things over docker run scripts or docker-compose. Kubernetes basically is an OS for OCI images. Even if you don't need orchestration, it still provides great experience. And when you would need orchestration, you will grow organically.

Right now I'm using cluster of 2 nodes (master, worker). No reliability, but convenience is good and we have very simple path to more nodes when we would need it.


I strongly agree. Having Docker images of your application is very convenient gor deployment and fairly easy to set up for anyone who has done so before. Then once you have these images anyway, hosting in (managed) k8s in the cloud is a breeze.

I'm not sure why you are getting downvoted. It would be great to hear of some of the bad experiences of those that disagree. Were they running their own cluster instead of a managed one? Or doing k8s with a team where nobody had any experience? Or run into some helm-chart spaghetti from hell?


> Kunerbetes works just fine on a single node.

But ... no one claimed it didn't, did they?

The claim was that the unnecessary complexity (of which Kubernetes was just one) from day 1 consumes valuable time that could be spent on making the product better.


Kubernetes brings very little unnecessary complexity and does not consume valuable time (if there's at least one person in the team who knows it well enough).

Kubernetes might start consume valuable time if you would start to bring niceties. Like GitOps, CI, and so on. Those things are good but not necessarily justify time spent from the start. So you can start with simple deployment yaml which you can write with 10 minutes and apply it manually whenever you need to update it.

Kubernetes almost out of the box brings to you:

ingress. You don't need to set up your own nginx reverse router. This task alone could consume days of setting up and maintaining. I work with organization which spends 2-3 hours to update their nginx if they need new route. It must be done in off-hours because they break it every single time they touch it and then they need to fix it. Kubernetes ingress is a breeze of fresh air after this nightmare.

cert-manager. Again, I work with organization which failed at setting up certbot. Their certs break all the time. cert-manager just works.

zero-downtime rollout restart. This is absolutely nice thing which works from the box and hard to achieve manually.

kubernetes-dashboard. There're other dashboards as well. I think that lens is very popular although I didn't use it. It allows for people who know very little about kubernetes to interact with it productively. For example in my team we have developers who use kube-dashboard to view logs, to exec into pod and check things, to update deployment, change envs. They just push buttons in GUI, they have no idea about any yamls or kubectl. And it works.

And those things in my experience so far do not bring any unnecessary complexities. Quite the opposite. They solve lots of inevitable complexities for very little cost.


Is hosting in kubernetes really more time consuming than one of the proprietary PaaS cloud hosting options? What better alternative would you propose?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: