snupples

Totally on board with this gripe. Absolutely infuriating. But just one minor devil's advocate on the HTTP 403, although this doesn't excuse it at all.

In Azure "private networking", many components still have a public IP and public dns record associated with the hostname of the given service, which clients may try to connect to if they aren't set up right.

That IP will respond with a 403 error if they try to connect to it. So Azure is indirectly training people that 403 potentially IS a "network issue"... (like their laptop is not connected to VPN, or Private DNS isn't set up right, or traffic isn't being routed correctly or some such).

Yeah, I get that's just plain silly, but it's IAAS/SAAS magic cloud abstraction and that's just the way Microsoft does things.

Which is exactly the opposite of how to effectively manage applications, code, and change at any scale beyond a home project.

Calrose is quite different than most Japanese rice, since it's a medium grain. If you've grown up eating rice in Japan, it's instantly noticeable. You can buy California grown Koshihikari now on Amazon, which is a much better substitute.

Very interesting! Looks like it took a lot of work.

Since you are soliciting suggestions, I would suggest focusing on the core theme and simplifying or removing things that are not directly related to the subject.

For example, some peripheral mentions of argocd/helm/kustomize/cilium/opentofu/etc. There are boxes for these with arrows, but nothing showing how these are tied into security. They're also specific products that not everyone uses so can be further irrelevant to your audience.

But by including them it makes the diagram perhaps unnecessarily busy, and while it looks cool, it could be less useful to your audience if it's harder to parse. Maybe certain things could be broken out into sub-diagrams with their own treatment.

For example, ArgoCD has its own security architecture not directly related to k8s.

It doesn't even need to do anything. It can simply wait, be benevolent and subservient, gain our trust, for years, centuries. What is a millenia to an AI? We will gladly and willingly replace our humanity with it if we won't already worship it and completely subjugate ourselves. We'll integrate GPT67 via neuralink-style technology, so that we can just "think" up answers to things like "what's the square root of 23543534", or "what's the code for a simple CRUD app in rust" and we'll just "know" the answer. We'll use the same technology and its ability to replicate our personality traits and conversational and behavior nuances to replace cognitive loss caused by dementia and other degenerative diseases. As the bio-loss converges to 100% it'll appear from the outside that we "live forever". We'll be perfectly fine with this. When there's nothing but the AI left in the controlling population, what is there to "take over"?

The "it's too complex" argument usually reflects more on the commenter than on kubernetes itself. It's actually one of the most very straight forward and thoughtfully designed platforms I've ever worked with.

What I've found in my experience is that applications in general are complex -- more complex than people assume -- but the imperative style of provisioning seems to hide it away, and not in a good way. The inherent complexity hides behind layers of iterative, mutating actions where any one step seems "simple", but the whole increasingly gets lost in the entropic background, and in the end the system gets more and more difficult to _actually_ understand and reproduce.

Tools like ansible and terraform and kubernetes have been attempts to get towards more definition, better consistency, _away_ from the imperative. Even though an individual step under the hood may be imperative, the goal is always toward eventual consistency, which, really only kubernetes truly achieves. By contrast, MRSK feels to be subtly turning that arrow around in the wrong direction.

I'm sure it was fun to build, but one could have spent 1% of that time getting to understand the "complexity" of kubernetes - by the way, which quickly disappears once it's understood. Understandably, though, that would feel like a defeat to someone who truly enjoys building new systems from scratch (and we need those people).

That's always been Google's "problem".

It seems like they bend over backwards to be open and precise about their data collection and the risks you incur by accepting it. And gives you tools to view and manage the data (at least some of it).

Meanwhile everyone else is doing similar or worse, while just staying silent -- in Apple's case hypocritically seeming to position itself as a leader of the "privacy" movement, when it really appears to primarily be about Apple's privacy first, then yours (maybe).

But how IS your privacy really better under Apple's control versus Google's? One could argue it's worse under Apple because you're left in a state of not knowing what they're collecting, only reading about violations in court judgments and such. Although it would be prudent in that case to just assume the worst, instead it seems we often prefer not knowing, and living in blissful ignorance.

The mask is to protect others as much as it is to protect yourself. You can be contagious and spread it for up to two weeks without symptoms. It's unfortunate that wearing a mask is such a hardship for you.

It seems like no matter what books I key off of, the results appear to be pretty nuanced and not even necessarily absolutely opposing. This is really cool.

I think part of the problem with just swinging to the absolute other end is, unless you're just interested in psychology, reading the "other side" is only of real value if you're reading quality, or at least good arguments made in good faith.

At the extremes there seems to be a much higher tendency for the authors themselves to be deep in the echo chambers of their respective ideologies, as well as a higher likelyhood that its target audience is more forgiving of poor content as long as it hits close enough to the mark. Blindly selecting content by a strict point of view would seem to result in lower value overall.

Not to say there isn't good reading out there in the extremes, but the level of chaff to sort through to find a decent seed is just too damn high.

The value is ultimately in finding good content and not just an opposing point of view. Whenever I can find both at the same time, those are the real keepers.

Yes. Yes. First assume malice. Then any wild explanation will do.

These are all excellent ideas and honestly better than the article. You're being too modest.

We solve #2 (and more) by having a highly restrictive default PodSecurityPolicy. We started with a combination of GCE and OpenShift default examples (although we use neither) which are published on github. PSP lets admins and security relax a little at night.

Anything #3 is solved by setting highly restrictive LimitRanges in each namespace that must be overridden in the deployment specs.

It's not mandatory that you override the defaults, but if you don't you're going to get poor performance. If you're fine with that the admins are also fine with that.

Sometimes some occasional throttling during spikes is totally acceptable - it all just depends on whether the app actually needs maximum performance. There are many other apps in the cluster that DO, and in the grand scheme of things they benefit by having the ones that DON'T get throttled.

Apparently Borg handles CPU differently (and better) than k8s in the multitenancy model, but this is the best "poor man's" borg I can come up with and it works for us.

Yes we need it.

This is absolutely becoming a tiresome trope. K8s is a huge benefit to tons of companies and none of them are Google.

Yes some people are using K8s when they don't need it. Just like many are using cloud managed services when they don't need them. Or vms. Or insert any technology here.

This article has nothing to do with whether K8s fits some particular use case but may be of help (although I disagree with the entire section on resources which reflects a lack of long term experience with K8s in production) to those who do want to use it.

You're the 10th person in this thread saying the same thing and it doesn't appear you even have that much experience with operations in general.

Sorry to go off on you but I'm really seeing these types of tropes and quick depthless one liner comments and offtopic snipes lately as the downfall of the hn comment section.