Hacker News Reader

Comment by striking | Hacker News Reader

That's because, for the vast majority of developers, there's no point in using k8s.

It's really only necessary when you have a big app (or a few instances of a few big apps) that will have lots of containers and lots of management required.

Please. Don't use k8s as a golden hammer. Docker alone (or with docker-compose) will be just fine for most people, especially when paired with a basic CI pipeline like Drone or Jenkins.

(If you're reading this, thinking "but it makes installing and managing services I depend on easier!" it doesn't obviate you of that responsibility entirely, not in production. You still have to make sure those services deploy properly, you still have to manage them to some degree... for some time, it was considered inadvisable to run your DB in-cluster because of how many ways it could fail.)

View on HN

I am a solo developer and I have been running my side projects on Kubernetes (GKE) for several years now.

It helped me a lot to focus on things that I like: development instead of ops. I never had to SSH into any machine or do things manually. I just tag a github release and in few minutes I get my application updated.

With Docker I believe it would be lot more complicated, no zero-downtime upgrades, no load balancing, OS vulnerabilities. Then, when I would need to add a new service into my setup, I would have to yet again go into the host or multiple hosts :)

So no, I don't believe people who say that for small projects you shouldn't use K8s. It saves a lot of time and helps you not to burn out on your side projects as it takes the pain of running a service away.

P.S. I am an author of Keel https://github.com/keel-hq/keel, it's a relatively successful CD solution, I hope it saved a lot of hours for other companies too :)

Question: Why not Heroku or any other hosted service like that? They seem to give you the right compromise for solo developers as well as mid size applications.

If it was a learning experience than I totally get your choice — otherwise I'd be interested in the motivations! Thanks!

I wanted my own ports with non http services as I had a grpc endpoint :) not sure how it is now but heroku only offered http.

Personally, Heroku has too much magic around the build packs and what not.

Kubernetes for stateless apps is easy:

1. Create a Docker image with your app. 2. Write about 20 lines of YAML for a Deployment 3. Write maybe 10 lines of YAML for a Service

Done. You can automate the entire roll out via Travis and using some `sed` replacements on the Deployment.

I have got blue-green roll outs working with two deployments and two service descriptors and maybe 30 lines of `bash`.

For developers, or for operators?

Orchestration makes it trivial to recover from the downtime of individual nodes, unintentional (crashes) or intentional (managing updates of the node's underlying OS). Making load balancing, (basic) service discovery, storage as part of the deployment artifact drastically reduces deployment risk.

We can have a discussion about which orchestration platform is best, and we can have a discussion on whether you need orchestration if you're a two-person startup using mostly a lot of SaaS and you have Really Only One Thing running in your production environment. But doubting the value of orchestration? Really?

Nothing is "trivial" about orchestration. It introduces entire new layers of complexity, new failure modes, as well as second-order effects that are poorly understood. People are not afraid enough of complexity.

I also think that solutions like Kubernetes should be used only when you really have to. And even then very carefully and never without a tool like Chaos Monkey.

Orchestration does introduce complexity but it does so with a large base of users, developers and general ecosystem. As developers and systems implementors we are already sitting on top of a huge stack of what could be an impossibly complex system (CPUs, operating systems, networks) But people have worked on their layer and made it robust and everyone benefits.

With that said we have been running K8s for 2 years now in production and have not once had an issue that we could attribute to it. So yes we do have another abstraction (complexity) layer, but to us the complexity does not equate to complicated problems. The benefits gained from the seamless redundancy, discovery, scalability, encapsulation and resource management have not cost us anything. If we had a shaky hard to understand stack that failed often I'd 100% agree.

One other complexity that k8s (or similar) introduces is more security concerns. If you've been runnning for 2 years now, I'm sure you'll have seen the changes required to secure Kubernetes from the "old days".

Managing the multiple TLS CAs, RBAC, PSP, Network Policy etc is non-trivial.

One thing I never see mentioned in these k8's threads is Openshift. Openshift solves most of the crappy things about k8's, including being much more secure and getting security updates from redhat.

(openshift runs on top of k8's for those who didnt know)

Yep I tend to recommend Openshift if people want a good out of the box security experience.

The only challenge with it is that Redhat have their own naming around various pieces, which I think some people find jarring to move to.

Edited my comment to make it clear that I don't doubt the value of orchestration, but rather that orchestration doesn't always make everything just work especially in prod

Kubernetes still provides easy deployments, monitoring, logging, load-balancing, scaling/high-availability that is easy to take advantage of and can work with even a single app.

But, why do you need k8s to do those things, particularly for a single app?

It seems like a very complex architecture to ensure reliability.

You don't, but K8S has it built-in which removes overhead.

If you're installing K8S yourself then it's probably not worth it, but if you're using managed services with free master nodes, why not take advantage of it? You can use it with a single worker node without problems.

My company is currently struggling a bit with building out a k8s platform. The benefit we seek is to have elastic compute capacity a la any cloud provider and have it be on-prem, strictly governed but also fully self-service. I might have an app with only 100-1000 users total, but I'd still like to get georedundancy and autoscaling to minimize support costs. That's what container orchestration is supposed to provide but it's still a windy path.

Reply on news.ycombinator.com