Hacker News Reader

Comment by erulabs | Hacker News Reader

I mean, it’s not the best argument to say a system is “one action away from disaster”. If you pull the escape lever in an F16 for no reason you’re also pretty screwed. If you intentionally fly into the ground no one blames General Dynamics for making the plane too complex.

It turns out complex tools for complex tasks require some skilled operators. Yes kubernetes is overkill for your home lab, no it’s not overkill for enterprise-grade AWS orchestration with hundreds of apps and millions of users. News at 11.

View on HN

I want to host a website not bomb the Middle East. Most enterprise apps are still websites that need no more than elastic beanstalk. If your analogy is to compare k8s to f16 then maybe you are not doing your argument any service.

If your dealing with dynamic scaling needs K8s are quite nice. There's a reason why most Telcos have deployed 5G functionality using K8s.

If you are in a situation where you want to follow a decoupled/microservices development pattern (ie. split component ownership across dev teams) as well as manage scalability during high load periods, K8s is hard to beat.

K8s is a useful tool, but can be overkill in a number of situations. Just like a hammer, you can't use it to solve for every usecase.

P.S. F-35s use K8s clusters (or might be K3s) to deploy their EWS.

Well both hosting websites and bombing the middle east make use of Kubernetes. [1]

1. https://www.theregister.com/2020/06/03/kubernetes_b_21_bombe...

I've spent my entire career being on-call for web servers and Elastic Beanstalk is not enough. Deployment failures, deployment speed, deployment safety, upgrades, local testing... There is a reason AWS themselves is pushing EKS and not Elastic Beanstalk, and it's not because Kubernetes is trendy, it's because it's incredibly useful.

I’ve had production SaaS apps running on elastic beanstalk just fine for years now. Better SLA than any of the kube apps I’ve seen. You’re right that if you have highly capable support team and the real need for it go with the pods but if you just have mediocre engineers and a straightforward deployment with no real scaling issues then just stick to simple systems.

Sure, then don’t use k8s. If you need extremely resilient leaf node architecture or high volume communication from distributed machines, then that’s a good time to start looking at k8s. Your lack of charity reveals your naïveté: the analogy is actually a good one because not all software development is equivalent to hosting a website.

It's nothing like that.

Kubernetes was built with no program for how to do important things. Every important thing in Kubernetes is post-hoc, poorly bolted-on patch instead of real solution.

Take for instance upgrades. Don't like upgrades? -- Try downgrades? -- Oh, what do I hear, you seem to not like that either... So, how about user management? -- Also no? -- Well, how about backups and recovery? -- What, again?

Kubernetes solved some easy problems quickly with no program for how to solve hard problems. Security is one of those hard problems Kubernetes has no idea what to do about. The reason? -- Kubernetes, on its own, provides very little. It doesn't know how to do networking -- you need a CNI for it. But there's no good interface in Kubernetes to allow the admin to somehow control in general how the cluster is supposed to behave. Maybe some container somewhere will do something tricky, and will punch a hole in whatever firewall you though you've built around it. And you cannot make sure upfront that's not going to happen. There isn't a single way to punch that kind of hole... and the problem is, often time simply to make things work Kubernetes users will punch those holes. Maybe because they don't know how to do things better, or maybe because there isn't really a better way, or the better way is so tedious and convoluted that nobody will really follow it...

It's unreasonable to expect anyone to be able to deal with this kind of complexity. We need to be able to manage complexity, but Kubernetes gives us no tools to do it. It's the same type of problem as Dijkstra described with "goto" -- it's the tools fault. It creates so much complexity that humans cannot cope. Not only humans, computer programs cannot cope -- too many things to check, to many possible problems to protect yourself against.

I disagree with everything you've said but there isn't enough content to any of your complaints to respond meaningfully.

Upgrades and downgrades work fantastically. Putting "a firewall in front" is trivial - just... put a firewall in front. I don't know what "punch a hole" means, but if you mean "bind a port", yes, there are indeed a lot of ways to do that (on linux, windows, and osx!), and kubernetes provides excellent, organized, standardized and controllable ways to do that.

Kubernetes does not create complexity in my experience. It's the other way around - developers who have never seen the complexity in the world complain about the complexity embodied in the tools. They think "you're not gonna need it", despite an entire industry of operators saying "actually yes, we do need this, and badly".

I've seen developers who've never built a website in their life complain about React, and it sounds exactly the same as this. You might not need these tools, but they're not unneeded. If you can make a simpler and more powerful tool, please, go ahead, you'll be rich and famous, and everyone from the US Navy to telecoms to where I work will celebrate you.

"Punch a hole" is a common idiom in the security and networking space which means "open a port in the firewall".

> Kubernetes does not create complexity

Aaaaaahahhaahhahaha....

.....wait you were serious?

Just one example off the top of my head: ClusterRole vs Role. Two kinds of role. Difference? One applies to a namespace, the other applies to all namespaces, cluster resources, and non-resources. Why not just make "Role" deal with all of them based on metadata or annotations? Because fuck it, that's why. Oh, and permissions cannot include a "deny" section, they can only "allow". Why? Fuck it, that's why.

You can create a secret, but only in one namespace, and there's no way to automatically share it with multiple namespaces. Why? Fuck it, that's why.

K8s is a shitshow of both complexity and a lack of functionality. It's a design-by-committee atrocity that is so bad it created an entire ecosystem to fill in all the bullshit it doesn't do.

Because namespaces are security boundaries? Don't tell me you make a namespace for each and every application or service.

Worth noting that, on their own, namespaces are not security boundaries, they're (IMO) primarily intended to be organizational constructs.

What namespaces do allow for, from a security perspective, is for various controls (e.g. RBAC, Network Policy, Pod Security Admission) to be applied to a given application or group of applications (depending on how you've organized your namespaces) in a relatively controlled fashion.

Reply on news.ycombinator.com