Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is K8s Too Complicated? 

jmoiron.net

Post reply on HN
Print view View original

21–30 of 171 posts

Re: Is K8s Too Complicated? 

#21

Post by anoncoward1234 »

Ok, I'll bite.

I posted this in another thread, but check this out: https://stackoverflow.com/questions/50195896/how-do-i-get-on.... That's the amount of crap I waded through trying to rubber-ducky myself into figuring out how to get two pods to talk to each other. In the end, I copied a solution my friend had gotten, and it's still not great. I'd love to be able to use Ingress or Calico or Fabric or something to get path routing to work in Kubernetes, but unfortunately all the examples I've seen online suffer from too much specificity. Which is the Kubernetes problem - it can do everything so trying to get it to do the one thing you want is hard.

Here is the kubernetes cluster I ended up building. If anyone has any ideas on how to add path routing let me know - https://github.com/patientplatypus/KubernetesMultiPodCommuni...

Re: Is K8s Too Complicated? 

#22

Post by hinkley »

hacknat wrote: post #5

Right tool for the right job. Is K8s too complicated? For some use cases it is. They probably should do a better job of discouraging certain use cases, but calling their elevator pitch “bullshit” is hyperbolic. There are exceptions to every rule, but a good rule of thumb is cluster size. If you’re managing less than 25 servers than K8s is probably over kill. As you start to creep north of 40 servers K8s really starts…

Docker compose can handle simple container situations and many PoCs just fine, and part of the work will be analogous to the Kubernetes solution.

If all you have is a handful of load balanced web servers and a database you can hold off on kube for a while.

Re: Is K8s Too Complicated? 

#23

Post by znpy »

hacknat wrote: post #5

Right tool for the right job. Is K8s too complicated? For some use cases it is. They probably should do a better job of discouraging certain use cases, but calling their elevator pitch “bullshit” is hyperbolic. There are exceptions to every rule, but a good rule of thumb is cluster size. If you’re managing less than 25 servers than K8s is probably over kill. As you start to creep north of 40 servers K8s really starts…

Interesting, what do you think should be used to manage a cluster of less than 25 machines?

Re: Is K8s Too Complicated? 

#24

Post by fear91 »

nimbius wrote: post #12

disclosure: im an engine mechanic with a lot of interest in Linux as a hobby. Kubernetes seems like a great alternative to stuff like openstack that seems like it requires an entire datacenter to get going properly, but I feel like the hype (k8s? really?) is outliving the reality. youre also bucking up against a problem where on smaller scales, it just seems easier to use something else. Maybe not "agile" and all tha…

OpenStack is used mostly for the layer beneath Kubernetes. We use it to provision the VM's/networking for the Kubernetes cluster itself.

Kubernetes might not make sense for your small scale projects but it's great when used for enterprise scale microservices. It makes deployments easier, faster and more secure (with things like network policies, namespacing and RBAC).

Re: Is K8s Too Complicated? 

#25

Post by sidlls »

hacknat wrote: post #5

Right tool for the right job. Is K8s too complicated? For some use cases it is. They probably should do a better job of discouraging certain use cases, but calling their elevator pitch “bullshit” is hyperbolic. There are exceptions to every rule, but a good rule of thumb is cluster size. If you’re managing less than 25 servers than K8s is probably over kill. As you start to creep north of 40 servers K8s really starts…

If no one person in you company has a complete mental model of the application architecture or it is impossible because it is so complex,

One caveat to this: architectures that are complex because of poor design should probably be redone rather than hidden behind yet another layer of complexity.

Re: Is K8s Too Complicated? 

#26

Post by dilatedmind »

jaequery wrote: post #10

what are some of the downsides of K8? any horror stories?

They recently added namespaces to specs, and I think they should add context as well.

Not really a horror story, but we ran into some mysterious behavior when one of our services appeared to alternate between two difference instances of an app. It was amusing to find someone had deployed prod specs to both prod and dev clusters, The only difference being their dns. The result was a fight between the two clusters' dns controllers to sync the A record to their respective endpoints.

Re: Is K8s Too Complicated? 

#27

Post by fear91 »

jaequery wrote: post #10

what are some of the downsides of K8? any horror stories?

You need to hire people who are competent with a new, quickly evolving technology. That means it's hard to hire someone good and it's expensive.

The upside is that you can replace multiple "normal" ops people with just a few K8 folks but that also requires a bit of culture change of how you do development.

Re: Is K8s Too Complicated? 

#29

Post by jchw »

anoncoward1234 wrote: post #21

Ok, I'll bite. I posted this in another thread, but check this out: https://stackoverflow.com/questions/50195896/how-do-i-get-on... . That's the amount of crap I waded through trying to rubber-ducky myself into figuring out how to get two pods to talk to each other. In the end, I copied a solution my friend had gotten, and it's still not great. I'd love to be able to use Ingress or Calico or Fabric or something to ge…

I think part of the problem is that I can't immediately understand what is actually being done. You say you want a per se React frontend to talk to a Node.js backend. But that's not really a pod-to-pod communication issue; both frontend and backend will be communicating with the user's browser, outside the cluster.

Secondly, you deployed an Nginx ingress controller. You don't need to deploy more than one of these in your whole cluster, so you can go ahead and separate this from your program's deployment manifests. Typically, cluster add-ons are installed by running kubectl -f with a URL to a GitHub raw URL, or, if you want to be much cleaner, using Helm (basically, a package manager. It installs with one command and then you can use it to install things into your Kubernetes cluster easily, such as an Nginx ingress controller.)

If you're wondering why the process is such a mess, it's probably just because Ingress is still new. In the future, support for more environments will probably come by default, without needing to install third party controllers. Already, in Google Cloud, GKE clusters come ready with an Ingress Controller that creates a Google Cloud load balancer.

As a side note, I found that the nginx ingress controller was not working by default in my cluster. I noticed some errors in the logs and had to change a parameter with Helm. Don't recall what it was, unfortunately.

Re: Is K8s Too Complicated? 

#30

Post by hacknat »

znpy wrote: post #23
hacknat wrote: post #5

Right tool for the right job. Is K8s too complicated? For some use cases it is. They probably should do a better job of discouraging certain use cases, but calling their elevator pitch “bullshit” is hyperbolic. There are exceptions to every rule, but a good rule of thumb is cluster size. If you’re managing less than 25 servers than K8s is probably over kill. As you start to creep north of 40 servers K8s really starts…

Interesting, what do you think should be used to manage a cluster of less than 25 machines?

It wasn’t a hard rule. It depend on the app and the use case, but probably just docker on all the machines with some static cloud loadbalancers in between everything. Or just straight config management.
Post reply on HN