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

291–300 of 338 posts

Re: The Cult of Kubernetes

#291

Post by malkia »

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…

It's a cult as much using source control system, build system, and editor (IDE) is.

e.g. you can always code, and zip-up files, and build directly using command-line (we still can do it, right?), but when you need to deliver that automation bit, and most importantly hand-off to the next person what you've done - e.g. codified for real, then it becomes a must to have a system like this.

Re: The Cult of Kubernetes

#292

Post by cweagans »

dkarl wrote: post #288
tnolet wrote: post #251

Earlier quoted context omitted.

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

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?

Re: The Cult of Kubernetes

#293

Post by mavelikara »

vonmoltke wrote: post #110
twic wrote: post #83

Earlier quoted context omitted.

Is this really true? There are plenty of job openings for people who are good at maintaining Java Spring apps!

They also pay a fraction of what the jobs "hip" companies pay, and often come along with developers Being treated as second-class citizens.

Lots of hip companies use the JVM, and sometimes, Java.

Re: The Cult of Kubernetes

#294

Post by StavrosK »

mst wrote: post #245
atq2119 wrote: post #231

Earlier quoted context omitted.

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 l…

I think k3s is sort of trying to do that?

Have you tried it? Is it any good? I've been looking for a simpler Kubernetes, although I don't know how much simpler it can be in practice and still do the same things.

Re: The Cult of Kubernetes

#295

Post by geggam »

013a wrote: post #282
geggam wrote: post #268

Earlier quoted context omitted.

Quick read didnt show Azure or GCP cluster creates. Did I miss that ?

They're not included in the base binary, and are instead provided as plugins. You can find a list of them here [1]; they've got AWS, Azure, GCP, DigitalOcean, vSphere, Docker, OpenStack, maybe a couple others. [1] https://github.com/kubernetes-sigs?utf8=%E2%9C%93&q=cluster-...

At what point down the rabbit hole of abstraction do we pull back and look at the complexity required to do simple things ?

Re: The Cult of Kubernetes

#296

Post by aprdm »

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 running in docker (without kubernetes), consul is ultimately responsible for, based on service metadata, hooking containers to the ingress traffic through the Fabio load balancer.

I would like to understand what we are missing by not using kubernetes, every time I think about it and talk with developers I feel it isn't worth it.

My team would have to maintain an extra layer of complexity that can get us called at night for no clear business gain.

Would love to know what we're missing.

Re: The Cult of Kubernetes

#297

Post by t0astbread »

collyw wrote: post #99
usgroup wrote: post #12

I think devs often make bad decision makers because in some sense tech is often an addiction rather than a pragmatic choice. The cycle of picking a tech, jumping ship to it, religiously evangelising it, riding the wave and then jumping ship to the next related tech is typical in my opinion. I try hard to correct for this bias but sometimes struggle with exactly the same thing. There's just something about wanting to…

Part of the problem is the hiring process (plus attitudes seen on here). Your resume needs to have lots of fashionable buzzwords rather than pragmatic good enough / keep it simple choices. You must keep on learning (lots of things rather than mastering any one thing). I can write a really nice site in standard Django with some JQuery, and it will take me half the time that adding React to it will. But adding React wi…

It seems to me that the requirements for personal infrastructure and professional service-grade infrastructure have drifted so far apart that essentially, if you know one world you don't (automatically) know the other at all.

Tbh, I have no real world experience in this, so it might just be my own delusion. However, I've recently started getting into self-hosting some of the services I use. I'm using a simpler infrastructure than what OP described and while it is the right choice for me and a useful skill to have, I feel like it absolutely won't get me anything in the sysadmin/ops/etc. job space. I've actually considered adding more "enterprisey" tech to it (like Ansible or comparable stuff) just to make it more sexy for recruiters.

Re: The Cult of Kubernetes

#298

Post by Turbots »

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

Use Pivotal Container Service to create, manage, update and scale your k8s clusters, in any cloud ;-)

Re: The Cult of Kubernetes

#299

Post by jeremyjh »

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…

It sounds like you've written your own Kubernetes. Congratulations, I guess.

Re: The Cult of Kubernetes

#300

Post by xorcist »

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…

So you think application delivery was less "as code" before Kubernetes?

From my standpoint, Kubernetes is a lot more manipulating state and a lot less code than what pretty much anything it replaces. In fact, almost nothing is "as code" until you introduce third party products such as Helm into the mix.

But that matters little, since the point of using it is not technology but standardization. It has the potential to commodify cloud infrastructure. A bit tongue in cheek perhaps and a far from accurate technical statement, but Kubernetes looks more and more like what Openstack should have been.

Post reply on HN