21 ms·

I know it's an unpopular opinion but I don't see the point of kubernetes. It's a complexity monster which is not providing any real advantage over way simpler s

by Eikon 7y ago

I know it's an unpopular opinion but I don't see the point of kubernetes. It's a complexity monster which is not providing any real advantage over way simpler solutions. Even pod to pod communication, which would be trivial to do using any sane solution is a huge pain in kubernetes. I would actually be frightened by running kubernetes in production. The simplest things are so hard to do that I don't even want to think about how to fix a weird issue when something goes wrong...

q3k 7y ago
> I know it's an unpopular opinion but I don't see the point of kubernetes. It's a complexity monster which is not providing any real advantage over way simpler solutions. The main selling point of k8s over any other tool is that it provides a single, unified, secured, multi-tenant API endpoint for managing all of production. Your developers updating their production app use the same API as a CI system that wants to spawn some worker containers, and the same API as an operator service maintaining a Redis cluster. All of this results in a single view into production. If things go well, the end result is that you swap daily interaction with a handful of different tools with disparate states (Terraform, Ansible/Chef/Salt/Puppet, shell scripts and proprietary tools) into just managing payloads on k8s. > Even pod to pod communication, which would be trivial to do using any sane solution is a huge pain in kubernetes. How is it a pain? A pod behind a service provides a DNS name that allows running requests to it - this handles the bulk of production traffic. If you want to contact a particular pod that is not behind a service just use the k8s API to retrieve details about it (like Prometheus does via k8s pod service discovery).
emerongi 7y ago
> Even pod to pod communication, which would be trivial to do using any sane solution is a huge pain in kubernetes. You create a service and then use the DNS name? How is that hard?
EdwardDiego 7y ago
The killer feature for us is autoscaling. Allows us to easily adapt to changing load throughout the day without having to overprovision. The ability to scale on custom metrics is really nice.

by Eikon 7y ago

q3k 7y ago

> I know it's an unpopular opinion but I don't see the point of kubernetes. It's a complexity monster which is not providing any real advantage over way simpler solutions. The main selling point of k8s over any other tool is that it provides a single, unified, secured, multi-tenant API endpoint for managing all of production. Your developers updating their production app use the same API as a CI system that wants to spawn some worker containers, and the same API as an operator service maintaining a Redis cluster. All of this results in a single view into production. If things go well, the end result is that you swap daily interaction with a handful of different tools with disparate states (Terraform, Ansible/Chef/Salt/Puppet, shell scripts and proprietary tools) into just managing payloads on k8s. > Even pod to pod communication, which would be trivial to do using any sane solution is a huge pain in kubernetes. How is it a pain? A pod behind a service provides a DNS name that allows running requests to it - this handles the bulk of production traffic. If you want to contact a particular pod that is not behind a service just use the k8s API to retrieve details about it (like Prometheus does via k8s pod service discovery).

emerongi 7y ago

> Even pod to pod communication, which would be trivial to do using any sane solution is a huge pain in kubernetes. You create a service and then use the DNS name? How is that hard?

EdwardDiego 7y ago

The killer feature for us is autoscaling. Allows us to easily adapt to changing load throughout the day without having to overprovision. The ability to scale on custom metrics is really nice.