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

231–240 of 338 posts

Re: The Cult of Kubernetes

#231

Post by atq2119 »

meowface wrote: post #191
dkhenry wrote: post #184

Earlier quoted context omitted.

Kubernetes is the new Java Application Server for people who didn't realize that Java Applicaiton Servers were a terrible idea. Despite a long track record of failure individuals are trying to introduce the complexity of J2EE onto kubernetes. It doesn't need to be that way. Kubernetes can be very simple and it has been up until recently. Once the Enterprise Architects got their hands on it and decided everything need…

Odds are someone / some people will create some kind of simpler solution with an easy default setup within the next ~5 years. Maybe as a wrapper over Kubernetes, or maybe as something new and interoperable with it. Maybe it'll involve a bunch of "serverless" buzzwords or some newly invented buzzwords. That's how things usually go historically. A lot of value can still be extracted if you're careful to ignore the cult…

Or perhaps somebody will evolve Kubernetes itself into becoming simpler?

I know that's a pipe dream, but really, why does it have to be? What would have to happen for people to actually work on making existing things simpler and better factored rather than reinventing the wheel?

My personal theory is that it's largely because that kind of work simply isn't being valued highly enough. Reinventing the wheel is a much lower friction path to take and has a higher chance of being rewarded highly. It shouldn't be like that, though.

Re: The Cult of Kubernetes

#232

Post by lukasLansky »

asdfman123 wrote: post #220
lukasLansky wrote: post #29

Kubernetes is our one shot at having the universal vendor-neutral cluster interface. The fact that it's time consuming to do simple things directly against it doesn't surprise me in the same way I'm not surprised that writing todo app directly against POSIX abstraction would be time consuming. It's a great way to learn how these interfaces work though.

Question: why hasn't someone come up with a simple interface that abstracts away the tricky bits if you just want to deploy a blog? I think MS is trying to make tools like this for the C# world, but I haven't seen them yet.

Knative[0] pushes in that direction from the side of "complicated" Kubernetes. It's still far away from easy, but I expect that the solution will look like this -- a software that uses Kubernetes base to provide high-level primitives. Helpful cloud provider will give you a cluster with such thing already installed, as Google already does for Knative with the Cloud Run offering.

Microsoft allows you to publish a web application from Visual Studio project to Azure.[1] It's very simple, but more much opinionated. It's a great trade-off for an individual developer who needs to focus on functionality. In the context of this discussion, there's an important distinction -- it's not an interface, it's just a feature. It's tightly coupled to Azure from one side and to Microsoft dev stack from the other.

[0] https://knative.dev/ [1] https://tutorials.visualstudio.com/aspnet-azure/publish

Re: The Cult of Kubernetes

#234

Post by root_axis »

parasubvert wrote: post #196
wayoutthere wrote: post #148

Earlier quoted context omitted.

Oh I get the author’s point, but her use case was “basically a Heroku replacement for easy deployment”. It’s just the wrong use case for Kubernetes and it is well known that deploying to Kubernetes is a bit of a nightmare.

Except Kubernetes has sucked all the oxygen up in the industry and has had a subset of adherents that trash the alternatives such as Heroku, Cloud Foundry, etc. As such, people do expect it to replace Heroku.

Anyone who suggests k8s as an alternative to Heroku is wrong. Heroku is a product that manages infrastructure so that the programmer doesn't have to, k8s is a solution for operational engineers that want a code-driven approach to managing their own infrastructure. Suggesting k8s as a replacement for Heroku is like suggesting docker as a replacement for EC2.

Re: The Cult of Kubernetes

#235

Post by asdfman123 »

lukasLansky wrote: post #232
asdfman123 wrote: post #220

Earlier quoted context omitted.

Question: why hasn't someone come up with a simple interface that abstracts away the tricky bits if you just want to deploy a blog? I think MS is trying to make tools like this for the C# world, but I haven't seen them yet.

Knative[0] pushes in that direction from the side of "complicated" Kubernetes. It's still far away from easy, but I expect that the solution will look like this -- a software that uses Kubernetes base to provide high-level primitives. Helpful cloud provider will give you a cluster with such thing already installed, as Google already does for Knative with the Cloud Run offering. Microsoft allows you to publish a web a…

Oh yeah, as a C# developer I definitely am familiar with app services.

But many organizations would rather not directly pay the costs of app services and instead indirectly pay the costs by making their developers tool around with Kubernetes.

Re: The Cult of Kubernetes

#236

Post by orf »

naringas wrote: post #204

I once set up an Elasticsearch cluster in Kubernetes. My conclusion was that it was totally redundant because in the end I made a few super-nodes that each run one super-pod (which is basically just one node from the elasticsearch cluster) I was confusing to think about the nodes of the cluster. is it a kubernetes-node? or an elasticsearch-node? after I was done, I felt terrible, but it was already working so I had t…

Kubernetes isn’t fantastic for running heavily stateful applications like a database. You won’t have much fun if you try.

It’s for stateless services that can be killed, scars down and scaled up at will with minimal disruption.

Re: The Cult of Kubernetes

#237

Post by root_axis »

asdfman123 wrote: post #219
humbleMouse wrote: post #178

These posts about kubernetes are so ridiculous. Installing kubernetes on multiple servers is not difficult, and understanding the components is pretty straightforward if you've ever worked on a distributed system. If you don't want to be in the "cult", dont use it. Meanwhile i'll be writing service and deployment yamls and avoiding all the proprietary expensive aws bs.

It's not difficult if it's your full time job. The learning curve is punishing though if you're trying to learn it from 9-12 AM on Saturday.

So what? It wasn't designed to make it easier for hobbyists to deploy their weekend projects, it's meant to provide ops-engineers with an infrastructure-as-code abstraction for distributed applications.

Re: The Cult of Kubernetes

#238

Post by root_axis »

tootie wrote: post #224
asdfman123 wrote: post #219

Earlier quoted context omitted.

It's not difficult if it's your full time job. The learning curve is punishing though if you're trying to learn it from 9-12 AM on Saturday.

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.

Re: The Cult of Kubernetes

#239

Post by brifee »

I was trying to get airflow (https://airflow.apache.org/) up and running in the cloud. It has a few moving pieces that I didn't want to worry about. So I used a helm chart to install it - https://github.com/helm/charts/blob/master/stable/airflow Maybe this is overkill but it was reasonably quick to get up and running, scaling workers will be trivial, and the Airflow Kubernetes Operator opens up a lot of options for tasks. The vanilla install was pretty quick. Understanding the configurations took a bit more time. I would like to hear other thoughts about simpler ways to deploy this that don't require Kubernetes.

Re: The Cult of Kubernetes

#240

Post by q3k »

mirceal wrote: post #135

step 1) keeping a service up and running is hard. we have all these issues and it seems like we are struggling to do simple things step 2) only if there was some magic tech that could solve all these issues. and have a cool name. and we could put it on out resumes... drum roll: K8Sssssss step 3) bro. it’s working. i don’t really understand what it’s doing but look at all the containers we are running. and the config.…

You do realize that one of those cloud services you can use is k8s, right?

GKE is pretty amazing. They manage the k8s control plane for you, offer worker node scalability and you can use a decent, intent based, automatable API for declarative deployments. No need to mess around with VMs or proprietary lambda/serverless stacks.

Post reply on HN