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

The Cult of Kubernetes

christine.website

Post reply on HN
Print view View original

311–320 of 338 posts

Re: The Cult of Kubernetes

#311

Post by dkarl »

cweagans wrote: post #292
dkarl wrote: post #288

Earlier quoted context omitted.

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…

There are lots of tools that give you "infrastructure as code". Why is Kubernetes special?

It's also directly supported by multiple first-tier cloud providers.

Re: The Cult of Kubernetes

#312

Post by tracker1 »

tnolet wrote: post #251
root_axis wrote: post #244

This is another case of "I have never encountered and don't deeply understand the problems this tool was built to solve, thus the tool is totally unnecessary and the people who use it are part of a cult". This is the same kind of flawed reasoning you see in the front-end world where a bunch of people complain that they do all their work in jQuery so React must be a cult. Pasting what I wrote in another comment: The g…

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

I'm in the situation that Kubernetes does solve the problem I have... deploying application stacks across varied configurations for purposes of testing at a PR level. Working on software that is customized and delivered to multiple downstream clients is hard to test against. Yes, there are other options, but K8s is a very good fit, and the best option we have.

YMMV... I've also been in a scenario where I just did separate pushes to dokku boxes behind a load balancer. There's plenty of room for in between.

Right now, I feel kind of like I'm treading water though.

Re: The Cult of Kubernetes

#315

Post by dragonwriter »

cweagans wrote: post #306
honkycat wrote: post #303

Earlier quoted context omitted.

What is the point of this question? Why are the other tools special?

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.

Re: The Cult of Kubernetes

#316

Post by aprdm »

jacques_chester wrote: post #307
aprdm wrote: post #296

My team maintains a platform that runs in datacenters across four continents, a private cloud. 1000s of VMs We use VMware and have its API hooked up to Ansible as well as Consul and monitoring. We then make Ansible playbooks available for devs to create services which takes around 5 minutes to run. Since it has consul and monitoring hooked in we automatically create entries in DNS and can auto scale. We have services…

> Would love to know what we're missing. Having an upstream who isn't you.

Sorry what do you mean by that? Consul, Ansible, Prometheus and other parts of the stack we maintain all have their upstreams.

If you mean running a managed Kubernetes in the cloud, would love to that but for our workflows we have to run on prems for most of the infrastructure. It's a lot of data and compute. A bit like saying google should use aws for their internal services.

Re: The Cult of Kubernetes

#317

Post by jacques_chester »

aprdm wrote: post #316
jacques_chester wrote: post #307

Earlier quoted context omitted.

> Would love to know what we're missing. Having an upstream who isn't you.

Sorry what do you mean by that? Consul, Ansible, Prometheus and other parts of the stack we maintain all have their upstreams. If you mean running a managed Kubernetes in the cloud, would love to that but for our workflows we have to run on prems for most of the infrastructure. It's a lot of data and compute. A bit like saying google should use aws for their internal services.

I mean assembling the stack yourself, basically, especially since you're adding features by creating particular arrangements out of the ensemble. There are always more edge cases. It's easier to let someone else handle them.

You'll note that Google don't manufacture their own RAM, don't operate hydroelectric plants, buy CPUs from Intel and so on. That they could plausibly do any of these things themselves satisfactorily, possibly even better than their suppliers can, doesn't make it the right choice. There is an opportunity cost for doing so.

It's economics 101: gains from trade.

Re: The Cult of Kubernetes

#318

Post by jcalabro »

root_axis wrote: post #238
tootie wrote: post #224

Earlier quoted context omitted.

The fundamental flaw with Kubernetes is that the UI is so bad. The abstraction is leaky and the naming is confusing. It certainly didn't stop git adoption.

kubectl has the ideal UI for managing a k8s cluster.

I wouldn't go so far as to call it "ideal", but it certainly beats the web UI.

Re: The Cult of Kubernetes

#319

Post by aprdm »

jacques_chester wrote: post #317
aprdm wrote: post #316

Earlier quoted context omitted.

Sorry what do you mean by that? Consul, Ansible, Prometheus and other parts of the stack we maintain all have their upstreams. If you mean running a managed Kubernetes in the cloud, would love to that but for our workflows we have to run on prems for most of the infrastructure. It's a lot of data and compute. A bit like saying google should use aws for their internal services.

I mean assembling the stack yourself, basically, especially since you're adding features by creating particular arrangements out of the ensemble. There are always more edge cases. It's easier to let someone else handle them. You'll note that Google don't manufacture their own RAM, don't operate hydroelectric plants, buy CPUs from Intel and so on. That they could plausibly do any of these things themselves satisfactor…

Right and I would love to leverage Kubernetes instead of our own plumbing of the OSS solutions, I just feel that operating it on prems requires a lot of overhead that simpler tools arranged together do not have, also, when they fail it isn't catastrophic for the most part (except for Consul).
Post reply on HN