this post was submitted on 10 Oct 2023
42 points (76.9% liked)
Programming
17669 readers
171 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Kubernetes is not intended to provide anything like a single system image. It's a workload orchestration system, not an operating system. Given a compatible interface (a runtime) Kubernetes can in theory distribute workloads to any OS.
I'm not going to argue that Kubernetes is not complex. But as I stated previously Kubernetes as a bespoke ecosystem is less complex than configuring the same features with decoupled systems. The requirements for an orchestrator and the challenges (technical, security, human, etc) to manage said orchestrator are higher. All else being equal, Kubernetes has implemented this in a very lean way, delegating networking, storage, and runtime to pluggable providers on the left, and delegating non-basic workload aspects to operators on the right. It's this extensibility that makes it both popular with operators and makes it appear daunting to a layperson. And going back to security, is has provably shown to have a reduced attack surface when managed by a competent operator.
So you're... what, dismissing HTTP because it has been adopted by capitalist market systems? Are you going to dismiss the Fediverse for using HTTP? What about widely adopted protocols? DNS, BGP, IPv4/6, etc?
How about we bring this part of the discussion back to the roots? You said that HTTP and REST as communication protocols seemed strange to you because Unix has other primitives. I pointed out that those primitives do not address many modern client-server communication requirements. You did not refute that, but you said, and I paraphrase "9P did it better". I refrain from commenting on that because there's no comparative implementation of complex Internet-based systems in 9P. I did state though that even if 9P is superior, as you claim, it did not win out in the end. There's plenty of precedents for this: Betamax-VHS, git-mercurial, etc.
(My emphasis) It's not free though. There's an overhead for doing this, and you end up doing things in-filesystem that have no business being there.
*Ahem*:
That is not an experience, it's a provably wrong statement.
That's a very weird assumption, and it's the first time I've heard it. Can you provide a source? Because in my experience the opposite is the case - there's no community more critical of Kubernetes' flaws than their developers/users themselves.
I dismissed the criticism because it makes an appeal to pathos, not to logos. Like I said, there's plenty of valid technical criticisms of Kubernetes, and even an argument on the basis of ethics (like you're making) is more engaging.
No my Kubernetes. I use it because it's academically interesting, and because it does the tasks it is meant to do better than most alternatives. But if CNCF were to implode today and Kubernetes became no longer practical to use then I would just pivot to another system.
I'm not going to argue whether it's a harmful way of doing distributed computing based on their maintainers/pedrigee. That's a longer philosophical discussion than I suspect neither you or I have time for.