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

111–120 of 242 posts

Re: Kubernetes Failure Stories

#111

Post by pquerna »

dankohn1 wrote: post #40
dvnguyen wrote: post #21

Having used Docker Compose/Swarm for last two years, I remember having problems with them twice. One of which was an MTU setting which I didn't really understand why, but overall I was relatively happy with them. Since Kubernetes seems to have won, I decided to learn it but got some disappointments. The first disappointment is setting up a local development environment. I failed to get minikube running on a Macbook A…

> The only easy and reliable ways to have a production grade Kubernetes cluster are to lock yourself into either a big player cloud provider, or an enterprise OS (Redhat/Ubuntu), or introduce a new layer on top of Kubernetes [1] I think you might have misunderstood that page. The standard and universal way to deploy Kubernetes on to either your own bare metal or any cloud provider is to use kubeadm. However, if you w…

The point is not about the minimum conformance, but rather the lock-in provided by the maximum configuration / extensions of each vendor.

Take AWS EKS as an example. Their feature page[1] does mention conformance. Then it mentions 20 other non-conformance focused features that create an effective lock-in.

k8s is becoming like OpenStack in this regards. You need to embrace a vendor version of k8s in order to have a functional cluster without a massive team.

[1] - https://aws.amazon.com/eks/features/

Re: Kubernetes Failure Stories

#112

Post by manigandham »

stunt wrote: post #50

Kubernetes solves a problem that most of the companies don't have. That is why I don't understand why the hype around it is so big. For the majority, it just adds a little value when you compare to added complexity to infrastructure and the cost of a learning curve and the ongoing operation and maintenance.

Because you can run your apps using simple YAML files with monitoring, logging, rolling updates, load balancing, failover, persistence built in?

Re: Kubernetes Failure Stories

#113

Post by marktolson »

stingraycharles wrote: post #28
lucidone wrote: post #18

Earlier quoted context omitted.

I'm consulting on a micro services back end right now with mostly prior experience with monoliths. What is the selling point that drives companies down this direction? It's insane, and my client keeps trying to hire new developers and bring on more consultants to build this thing, but the amount of knowledge required is more than any one person can handle. I have similar issues with their choice of db (nosql) and its…

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.

Re: Kubernetes Failure Stories

#114

Post by WillPostForFood »

sonnyblarney wrote: post #105
m0zg wrote: post #100

Earlier quoted context omitted.

>> And what do you think is the primary driver of said cost of living? Mostly NIMBY-driven refusal to build more housing and transportation infrastructure. It's not like the US is lacking for land. There's no reason a dilapidated teardown-ready shack should cost $2M, no matter where it is.

No, there is NIMBY-ism in most places, the reason Valley prices are sky high is the salaries. " There's no reason a dilapidated teardown-ready shack should cost $2M, no matter where it is." The cost is not the shack, it's the land it's sitting on. The higher the salaries in the valley, the more that dilapidated shack will cost.

It is both. There is more money buying a relatively fixed number of homes, so price goes up. But if you could buy a piece of land with one home. And put 10 units on it, then that could be offset.

Re: Kubernetes Failure Stories

#115

Post by mirceal »

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?

this is too broad. i think that may actually be the problem: in theory it can do a lot of things, but in the real world it’s hard to get all those theoretical benefits.

for me, if you’re in the cloud you don’t need k8s. your favorite cloud provider has already figured out logging and monitoring and the basic things you need to get going. (another story if you run on bare metal)

if you’re not running a legacy app you don’t really need containers either. containers are great for legacy apps, for poorly written software or if you like overengineering. the abstraction you need is called a vm. use it. (again if you are in the cloud).

your app/service/thing is not as complicated as you think it is (or at least it should not be). I see a lot of people feeling like they need to experiment with new technology, on the job, on whatever they are doing now. actually building something that works and is simple as fuck seems to take a backseat and these types of people will create a narrative around using the new flashy thing. this is how you end up with production systems leveraging tools in beta and you end up closing shop when you finally figure out that you don’t have the resources to understand and maintain what you’ve created.

there is a time and place to experiment and learn. on small projects or on your own time. it takes experience to understand the hype cycle and to distinguish good tech from the hype.

as for k8s? yes, it solves some problems but it also creates others. do you like basically spending the time you’ve saved on setup and deployment to maintain/troubleshoot/upgrade your cluster? knock yourself out.

Re: Kubernetes Failure Stories

#116

Post by pgwhalen »

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?

I very much agree that kubernetes is useful in an environment that doesn’t need to scale, but do tell how it enables consolidated logging and monitoring, since my medium/small shop is spending quite some time setting up our own infrastructure for it.

Re: Kubernetes Failure Stories

#117

Post by jordanbeiber »

lmm wrote: post #109
jordanbeiber wrote: post #91

Earlier quoted context omitted.

Which is why you’ll need the input and help from experienced sysadmins that like to do development, which actually is ”automation”. This done right reduces overhead and gives you an edge in repeatability and quality. Both are required to scale.

Automated deployment and the like is worthwhile whether your system is microservice or monolith. But no amount of automation can eliminate the overhead a network boundary brings to local development.

We view this a bit different, and that’s fine (not the automation part, here we agree).

Automation in this context is for me more than just the deploy bit, it’s also about testing and service management which includes for example service relationships and discovery.

If you could do local dev on that app as a monolith, it can most likely be done broken up in smaller services as well.

There are no silver bullets to be had anywhere, right? Just use whatever processes and tools that work, until they don’t I guess.

Re: Kubernetes Failure Stories

#118

Post by mooreds »

jordanbeiber wrote: post #37
lucidone wrote: post #18

Earlier quoted context omitted.

I'm consulting on a micro services back end right now with mostly prior experience with monoliths. What is the selling point that drives companies down this direction? It's insane, and my client keeps trying to hire new developers and bring on more consultants to build this thing, but the amount of knowledge required is more than any one person can handle. I have similar issues with their choice of db (nosql) and its…

Microservices requires proper, structured systems management. Most seem to think "devops" and microservices are ways to ignore this, when in fact the complete opposite applies. Make sure you have a true service delivery and service management pipeline in place where it is real easy for dev and ops to deploy and decommission services. Service metadata is key in my experience. Not too much though, just enough (such as…

> Granted, this was within a multibillion turnaround enterprise.

> Most businesses would benefit from this transformation...

That is a great story from the front lines. Thank you for sharing.

My worry is when I see small companies or startups using microservices. That seems nutty to me

Re: Kubernetes Failure Stories

#119

Post by atombender »

dilyevsky wrote: post #69
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…

Re configuration: ksonnet is an option (although I personally find jsonnet a “lipstick on a pig” kind of solution). There’s some work going on to have something more user-friendly (think Google’s Piccolo) - https://github.com/stripe/skycfg (disclaimer - I contributed to this project)

There's also Kubecfg [1], which uses Jsonnet, but has a much smaller surface area than Ksonnet.

[1] https://github.com/ksonnet/kubecfg

Re: Kubernetes Failure Stories

#120

Post by cookiecaper »

threeseed wrote: post #66
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…

> leaving no option but to move somewhere else Many of the major infrastructure/platform vendors are rolling out their own distribution of Kubernetes either as a cloud service e.g AWS, Azure, GCP or on premise e.g. RedHat. So I suspect they are going to try and differentiate on features and ease of use and make it as hard as possible to move anywhere else.

k8s is meant to be hard to use. You're supposed to rent space on a k8s cluster from Google. Google has been pumping millions into marketing k8s as a mechanism to improve GCP adoption and establish a foothold in the cloud provider space.
Post reply on HN