4 ms·

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 fantastic

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.

superq 3y ago
"Punch a hole" is a common idiom in the security and networking space which means "open a port in the firewall".
- deleted 3y ago
  [deleted]
throwawaaarrgh 3y ago
> 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.
- uberduper 3y ago
  Because namespaces are security boundaries? Don't tell me you make a namespace for each and every application or service.
  - raesene9 3y ago
    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.
crabbone 3y ago
[flagged]
- erulabs 3y ago
  You can disagree without ad hominem. Your points make little to no sense, even beyond your sneer. Pods can’t be “upgraded” individually becuase pods are ephemeral. Downgrades work fine - replace newer binaries with older binaries. Upgrades work great too - replace older binaries with newer binaries. Single node is the correct context for upgrades because a node is the failure domain in kubernetes (and in every single other Linux based orchestration system). 1.28 even includes an automated way of doing this in a highly available way per host. CSIs and CNIs are binaries, which can be upgraded and downgraded like with any other system. Yes, if you upgrade or downgrade major versions there may be breaking changes. I’ve been a sysadmin and a devops engineer and a cloud platform engineer for approaching 20 years. I’ve flagged your reply as I don’t think it’s appropriate, but I wanted to reply to you anyways because I’m sure beyond your anger and rudeness and lack of empathy, you’re intelligent enough to do a bit of reading and double check that you’re not absolutely wrong on all counts. At some point you’ll be surrounded only by what you think are idiots, and they’ll exclude you. At that point you might investigate if just possibly you’re not by far the smartest person on earth. It’s possible other people know what they’re doing too.

superq 3y ago

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

deleted 3y ago
[deleted]

throwawaaarrgh 3y ago

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

uberduper 3y ago
Because namespaces are security boundaries? Don't tell me you make a namespace for each and every application or service.
- raesene9 3y ago
  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.

crabbone 3y ago

[flagged]

erulabs 3y ago
You can disagree without ad hominem. Your points make little to no sense, even beyond your sneer. Pods can’t be “upgraded” individually becuase pods are ephemeral. Downgrades work fine - replace newer binaries with older binaries. Upgrades work great too - replace older binaries with newer binaries. Single node is the correct context for upgrades because a node is the failure domain in kubernetes (and in every single other Linux based orchestration system). 1.28 even includes an automated way of doing this in a highly available way per host. CSIs and CNIs are binaries, which can be upgraded and downgraded like with any other system. Yes, if you upgrade or downgrade major versions there may be breaking changes. I’ve been a sysadmin and a devops engineer and a cloud platform engineer for approaching 20 years. I’ve flagged your reply as I don’t think it’s appropriate, but I wanted to reply to you anyways because I’m sure beyond your anger and rudeness and lack of empathy, you’re intelligent enough to do a bit of reading and double check that you’re not absolutely wrong on all counts. At some point you’ll be surrounded only by what you think are idiots, and they’ll exclude you. At that point you might investigate if just possibly you’re not by far the smartest person on earth. It’s possible other people know what they’re doing too.