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

Kubernetes Failure Stories

srcco.de

Post reply on HN
Print view View original

221–230 of 242 posts

Re: Kubernetes Failure Stories

#221

Post by manigandham »

JeremyNT wrote: post #211
manigandham wrote: post #110

I don't understand all the negative comments here, K8S solves many problems regardless of scale. You get a single platform that can run namespaced applications using simple declarative files with consolidated logging, monitoring, load-balancing, and failover built-in. What company would not want this?

From a developers' perspective, k8s feels like a holy Grail. Having fully embraced it with my latest rails app, I can say confidently that I've never had a more straightforward and enjoyable experience than K8s. It's absolutely the correct abstraction layer for me; it gives me all the power I could ask for in as concise a definition as I could possibly expect. I think a lot of the complaints against K8s are from the…

Agree, although I don't think the Ops portion is that hard either, at least certainly not that different from all the other complex software that used to be installed and maintained. I feel it's just the usual pushback against change and general commoditization of IT that's leading to most of the complaints.

Re: Kubernetes Failure Stories

#222

Post by BretFisher »

lugg wrote: post #96
nisa wrote: post #94

The k8s hype feels like the Hadoop hype from a few years ago. Both solve problems that most don't have and there is a lot of complexity - some due to the nature of the problem, some because everything is new and moving. Of course it's 2019 and you have to migrate Hadoop to run on k8s now :) My impression is that if you are a small shop and have the money, use k8s on google and be happy, but don't attempt to set it up…

Docker swarm is really nice. I wish it had more traction. I fear it's going to be dropped and leave me holding a bag full of bugs.

Swarm isn’t going anywhere. It has a growing community and the team is activly working in the repos. See my updates: https://www.bretfisher.com/the-future-of-docker-swarm/

Re: Kubernetes Failure Stories

#223

Post by drchaos »

plasma wrote: post #148
bdcravens wrote: post #34

I've started the planning phase of a Kubernetes course, geared toward developers more so than the enterprise gatekeepers. As I read stories like these, I jump between different thoughts and feelings: 1) no matter what I think I know, there's too many dark corners to create an adequate course 2) K8S is such a dumpster fire that I shouldn't encourage others 3) there's a hell of an opportunity here Thoughts? Worth pursu…

I think a good course would be setting up a k8s cluster for a simple "hello world" production app, which then includes topics perhaps about monitoring, upgrading, etc all the kind of stuff you want to know for getting an app up and running.

A better example would be a Wordpress installation. Hello World means skipping much of the important stuff, like storage and persistence.

As a bonus, show how to use Gitlab for deploying and managing the app. Gitlab + Kubernetes could be the holy grail for modern, self-hosted development, however a good, complete tutorial/documentation is very hard to come by. One has to pick the pieces from a lot of different places with sometimes conflicting information.

I'd happily pay 100 Euros for such a course.

Re: Kubernetes Failure Stories

#224

Post by jacques_chester »

manigandham wrote: post #220
jacques_chester wrote: post #205

Earlier quoted context omitted.

You can go entirely with YAML in a PaaS. Unless you feel you want it. Just push code. That's it. That's all you need to do.

How is that different though? You have to setup the PaaS the first time, the same as you write the YAML file the first time. After that you push code regardless of destination.

I think we have different ideas of what a PaaS is.

Re: Kubernetes Failure Stories

#225

Post by JeremyNT »

manigandham wrote: post #221
JeremyNT wrote: post #211

Earlier quoted context omitted.

From a developers' perspective, k8s feels like a holy Grail. Having fully embraced it with my latest rails app, I can say confidently that I've never had a more straightforward and enjoyable experience than K8s. It's absolutely the correct abstraction layer for me; it gives me all the power I could ask for in as concise a definition as I could possibly expect. I think a lot of the complaints against K8s are from the…

Agree, although I don't think the Ops portion is that hard either, at least certainly not that different from all the other complex software that used to be installed and maintained. I feel it's just the usual pushback against change and general commoditization of IT that's leading to most of the complaints.

I think I agree with this also, but my experience is limited enough to allow for the likelihood of additional complexity and gotchas that will become evident over time.

I'm sympathetic to concerns of ops, having worked in that space before working as a developer. It's tough to dive into a new approach and discard existing, well understood solutions. It's an especially hard sell when the benefits of the new tech are opaque and/or don't solve problems you personally have (until I actually used k8s for my own project, I really didn't understand the hype either).

I'd suggest though that the "usual pushback" is a powerful force on its own that may make k8s a poor fit for an org (right now). If some portion of the staff - especially those responsible for reliably maintaining the infrastructure - is resistant to the approach, rushing adoption is highly likely to lead to failure (if for entirely non-technical reasons). The benefits of k8s will only become more apparent and more easily realized over time, and the opportunity cost of waiting until there are fewer "Kubernetes Failure Stories" on HN might not be all that great.

Re: Kubernetes Failure Stories

#226

Post by romeisendcoming »

manigandham wrote: post #218
romeisendcoming wrote: post #214

Earlier quoted context omitted.

Sales talk. This doesn't reflect reality, sadly.

What's sales talk? What's not reality? K8S can replace quite a lot of sysadmin responsibilities and is currently doing so at thousands of companies.

IMO the commonality at thousands of these companies is a relatively uncomplicated application stack requirement or micro services.

If you have ever had to talk down execs bitten by the k8s hype in a scientific compute or HPC environment you would know that the marketing and sales talk is both prevalent and damaging.

Re: Kubernetes Failure Stories

#227

Post by ecnahc515 »

geggam wrote: post #202
dlor wrote: post #136

Earlier quoted context omitted.

I'm not exactly sure what point you're trying to make here. k8s is not meant to be a paas, but no one is trying to make k8s harder to use. I work at Google on a large team of engineers dedicated to making it as easy as possible to use.

The fact it takes a team of highly skilled engineers from the top of the talent pool trying to make it easy should tell you perhaps the design is wrong ?

Or that to run a secured, highly available platform with the type of features k8s provides is non-trivial beyond basics.

Re: Kubernetes Failure Stories

#228

Post by lykr0n »

m0zg wrote: post #51

It's not for everyone and it has significant maintenance overhead if you want to keep it up to date _and_ can't re-create the cluster with a new version every time. This is something most people at Google are completely insulated from in the case of Borg, because SRE's make infrastructure "just work". I wish there was something drastically simpler. I don't need three dozen persistent volume providers, or the ability…

Nomad is drastically simpler than Kubernetes. All you need is consul and nomad to get a running cluster

Re: Kubernetes Failure Stories

#229

Post by macintux »

marktolson wrote: post #113
stingraycharles wrote: post #28

Earlier quoted context omitted.

The biggest reason for choosing microservices _should_ be scaling development teams: microservices allow multiple teams to work on different code bases, without stepping on each other's toes. What actually happens, tough, is that (uninformed) people choose it because they think it brings them scalability (wrong), it's more cloud compatible (wrong) or the worst offender, it's more modern.

How does a properly designed microservice architecture not achieve greater scalability over a monolith? Of course you can scale up a monolith but with microservices you can independently scale selected services thus increasing your benefit cost ratio.

There's a great deal of overhead when communicating between services that isn't typically present in a more tightly-integrated monolith. Networks are very, very slow relative to RAM, setting aside the other costs involved in serializing/deserializing every communication.

And "properly designed" is very hard to achieve.

It's often much more productive to start with a monolith and experience the pain of extracting a piece that needs horizontal scaling, than to start by horizontally scaling everything.

Microservices can be a good architecture, but it's far from a no-brainer, even for high scalability. Servers are incredibly fast these days and can typically scale very well vertically.

Re: Kubernetes Failure Stories

#230

Post by jordanbeiber »

romeisendcoming wrote: post #215
jordanbeiber wrote: post #88

Earlier quoted context omitted.

I did. As I see it all to often mainly at the larger places. Modern SA is about knowing that your job to help bring business value. Most of the time this is down to automation.

Did you consider that when there is a manual process it is in place to bring combined attention to what surely is (by 2019) a critical section: that needs consensus not provided by some monitoring hook. Sure, everything is about automation and it has been since 1999 in my experience.

Of course. I’ve been employed and consulted enterprise IT&Dev for almost 20 years.

The amount of people heating office spaces at your non-tech large enterprise is astounding in my opinion.

I enjoy discussing the reasons for this, but it’s a lenghty one!

In super-short: lack of competency, meaning IT support and tools are not used even remotely optimal. This lack of competency, which starts at the top, results in laughable lead times for the simplest of tasks and processes. This in turn has resulted in mass outsourcing and off-shoring of a bunch of tasks (processes) that really should have been automated years ago.

Usually the incentive to improve this is 0 with these ”service providers” and things detoriate even further.

The sad state of affairs is that many believe this is the way ”IT” works — slow and error prone.

Awesome example: one place, one of the 500s, built an on-prem ”cloud” within a business unit. Over 2000 physical xen hosts. I wanted them to apply a patch. They refused. The last patch had taken 6 months to roll out. The process was: ssh to server, scp patch, run sudo install patch. The entire operation was bought by a renowned ”service provider”. Ouch.

I could talk about this for weeks! Of course there are those that manage an awesome shop, but my experience is that this is usually isolated teams that are somewhat shielded from the crazyness of big money politics.

Post reply on HN