Live data from Hacker News

Kubernetes Failure Stories

srcco.de

101–110 of 242 posts

Re: Kubernetes Failure Stories

#101
post #49

I am a developer and I find k8s frustrating. To me, its documentation is confusing and scattered among too many places (best example: overlay networks). I have read multiple books and gazillions of articles and yet I have the feeling that I am lacking the bigger picture. I was able to set it up successfully a couple of times, with more or less time required. Last time, I gave up after four days because I realized tha…

Kubernetes has always had an identity crisis. Who is aimed at, app developers or platform operators? Clear, obvious contracts between the two roles are valuable, even if you decide to combine them. I'm moderately hopeful that Knative will help in that regard, as it is more conclusively oriented towards the developer. But I am wary that since it leaves the implementation details completely visible, it may not achieve…

> app developers or platform operators

Definitely not the former. The YAML-based configuration is not a pleasant app deployment experience. Companies end up needing to do some sort of auto-generation for it to make it sane for app devs.

App developers want experiences similar to heroku. They want to git push and have applications safely roll out without downtime or configuration.

Re: Kubernetes Failure Stories

#102

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 kubeadm api for ”phases” going beta in 1.12 -> 1.13 has actually made rolling k8s clusters (almost) a breeze.

It used to be really clunky, but these days all you need is a simple bash script or ansible play (or whatever you’re comfortable with) to get going.

But yeah, no unix philosphy vibes from k8s as a whole...

Re: Kubernetes Failure Stories

#103
post #43

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…

Digital Ocean's K8S offering is out of beta now: https://www.digitalocean.com/products/kubernetes/

Migrated my very small cluster from GKE to DigitalOcean's K8s a few weeks ago. I was using 3 nodes on GKE with 1 core & 3.75GB RAM per node, and the cost was around 100 $ per month including load balancer for the cheapest region, `us-central1-a`. Now, on DigitalOcean, I have 3 nodes with 1 core & 2GB RAM per node. The cost is exactly 40$ including load balancer.

I am a pretty basic user, I have started using k8s on this project as a learning and 100$ was too much for the learning price, but now on DO I get a similar cluster for less than half of GKE price and I feel like it is worth it, considering all the simplicity and observability of deployments. Also, DO allows me to select regions without any price difference, so I was able to select Amsterdam to get 10 times better latency from where I live. My setup is quite basic, my app with aroud 8-10 pods, + additional stuff such as cert-manager and prometheus.

YMMV, but so far I am really happy with DO's offering, both in terms of performance, simplicity and performance. I am not a power user and definitely operate at no scale, but using DO in general is much simpler than using GCP with GKE.

Re: Kubernetes Failure Stories

#104
post #49

I am a developer and I find k8s frustrating. To me, its documentation is confusing and scattered among too many places (best example: overlay networks). I have read multiple books and gazillions of articles and yet I have the feeling that I am lacking the bigger picture. I was able to set it up successfully a couple of times, with more or less time required. Last time, I gave up after four days because I realized tha…

Perhaps there is a good plural sight course? Sounds like a tech you have to invest many hours to learn.

Re: Kubernetes Failure Stories

#105
post #100

Earlier quoted context omitted.

"a lot of techies live in areas with exorbitant cost of living," And what do you think is the primary driver of said cost of living? I believe there is a ton of arbitrary complexity in the system, and though it's not specifically created, it definitely grows if it's not checked and entities with power have no reason to do that. Google, Oracle, MS, Governments, Banks - have very little incentive to clear the weeds, us…

>> 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.

Re: Kubernetes Failure Stories

#106
post #38
post #29

Earlier quoted context omitted.

Out of curiosity, why do you need RHEL or subscription from Canonical for the production Kubernetes setup? What's wrong with plain Ubuntu or CentOS?

You probably don't want to configure kubernetes manually... Kops is a thing though, but it's still a lot error potential, if you want to go to production

This. We use Rancher within our data center, because configuring and managing k8s is not trivial. Rancher eases a lot of that pain for our small team.

Re: Kubernetes Failure Stories

#107

Earlier quoted context omitted.

It’s common to pay for things to make them easier to configure/manage. Red Hat OpenShift on RHEL, Pivotal Container Service on Ubuntu, Red Hat’s nextgen CoreOS based Kubernetes, Canonical’s Charmed Kubernetes Distribution on Ubuntu, etc. all have different config management , install, upgrade, patching mechanisms that vary from Ansible, to Terraform, to BOSH, to Juju. Some handle PXE bare metal, some don’t. Etc. Ther…

> It’s common to pay for things to make them easier to configure/manage. Yes but in the case of RedHat specifically those goals are not achieved.

I’m sure IBM will make it better.

Re: Kubernetes Failure Stories

#108
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.

You make it sound like people enjoy paying millions for dilapidated shacks, which I can assure you is not the case. The reason housing costs so much is limited supply coupled with high demand. There could be a 10-story 40-apartment building in place of that one shack. Place a few thousand of those strategically through Bay Area, and the price per square foot would come down big time even if the cost of land stays high. But, NIMBY. Can't reduce the "value" of all that (mostly dilapidated) real estate people already own.

Re: Kubernetes Failure Stories

#109
post #87

Earlier quoted context omitted.

> If you achieve this scale of teams suggested, it means you have a lot of implicit gains here as well, right? > Such as higher quality, higher "velocity", separation of concern and hopefully a clear sense of ownership. No, it means you pay a huge overhead. Quality and velocity both drop as your day-to-day development requires a lot more setup and faff to do anything, and counterintuitively so does separation of conc…

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.

Re: Kubernetes Failure Stories

#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?
Post reply on HN