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.

Be aware that viper isn't thread safe. You'd still have to copy config by value and then put a mutex on that, then handle reads and writes separately.

https://github.com/spf13/viper#is-it-safe-to-concurrently-re...

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.

So just to play to your hypothetical. If there were two login methods, and they were separate microservices, if only one failed and the other remained up, that would be the graceful failure scenario.

I'm not telling you that you must to do this. Others may have requirements that go beyond yours.

I have also done extensive work on both (I'm much older than the word microservices) and have found advantages to both approaches depending on requirements.

I've also found that most so-called monoliths still often end up breaking apart components anyway. I've only seen true monoliths as described above in the mom and pop type IT shops where there's only a couple support staff and they don't have the resources or experience to properly break things out into separate resilient components. And yes supportability is definitely a valid part of that design call.

Again that was just one example of a potential advantage to it while admitting there are trade offs. Others here have given better examples such as at larger orgs where multiple independent teams get involved with a single app.

I don't disagree with you at all. There are certainly different ways of thoughtfully building things.

The point being you don't need to be a paying subscriber to microservices(tm) to recognize there can be positives to the approach, which you describe in your last paragraph

A monolith that can handle component level failures is very close to the same idea infrastructure-wise minus a lot of baggage implied by the buzzword microservices.

You don't need to "buy into" an idea to realize that there are advantages and disadvantages to a given approach.

Take one example: The single server idea is going to suffer outages. You could at the very least have two monoliths either load balanced or in some kind of failover setup.

But, what distributing some of the components into so-called microservices would give you is a graceful failure scenario where even if all the instances of a specific component fail, the rest of the application still works. Maybe only one function stops working temporarily but most work continues on.

This doesn't mean everything must be microservice koolaid all the time all the way, but I'm sure you can conceive of that being an advantage under certain use cases that would be worth other possible trade-offs.

Incorrect. If a node has 2 cores and the pods on it have request of 2000m nothing else will schedule on that node even if total actual usage is 0.

You can overprovision limit.

This is easy to test for yourself.

Of course, you're missing the point. Depending on your application a little throttling doesn't hurt, and it can save other applications running on the same nodes that DO matter.

In the meantime you can monitor rate of throttling and rate of CPU usage to limit ratio. Nothing stops you from doing this while also monitoring response latency.

On the other hand CPU request DOES potentially leave unused CPU cycles on the table since it's a reservation on the node whether you're using it or not.

Again needs may vary.

Effective monitoring. Prometheus is free and open source. There are other paid options.

Kubernetes is not really that complex. It has primitives that cover a huge number of needs, so it can be complex when needed to solve complex problems, or simple when you're solving a simple problem.

I get the feeling people glance over the documentation and assume that you MUST use every single feature. Most of the features are only there when you need them for supporting advanced use.

It's a bug in the linux kernel that was introduced in 4.18 and later fixed. You might be ok if you're on a later or newer version.

The symptom primarily seems to manifest that you get heavy throttling even though you haven't actually gotten to your cpu limit yet.

If you're just seeing heavy throttling AND its pegged at the limit, you haven't necessarily hit the issue and should raise the limit first and observe.

Also don't forget to eliminate other possibilities. We initially thought we were experiencing this issue and later discovered the app was just memory constrained and extremely heavy GC during certain operations was causing the throttling.

Ok so it's just the API servers. Not every node which is what it sounded like. Typically you wouldn't run normal workloads on the same host as the API. Although these quick "how I did it" articles have a tendency to skip best practice. Still sounds like something isn't right in your environment. They shouldn't be hammered that hard unless you have a very large cluster.

Because this is literally what "Hacker News" should be about.

That makes no sense. Try looking at logs and such at least.

I would go as far as to say I think the vast majority of people don't need a specialized service mesh. We unfortunately started with Linkerd and it actually is the cause of most reliability/troubleshooting issues. I don't think lack of complexity is actually a good selling point for it, because it's inherently more complex that not using a service mesh.

Istio may appear more complex but that's because it has a superior abstraction model and supports greater flexibility. We're beginning to migrate from Linkerd to Istio at this point. I had the same initial frustrations with podsecuritypolicy (and linkerd suffers from the same), but istio-cni solves the superuser problem, and I believe even the istio control plane is now much more locked down in the latest release.

However if I had my way I would be telling every team they don't need service mesh. We don't have any particular service large and complex enough to really take advantage of its sold features.

Except in Japan it really is just a cute cartoon. There is very little actual police presence and they rarely carry firearms or project a forceful posture.

Not through lack of trying. It's just that iAds was unsuccessful.

Not sure if anyone's mentioned this yet, but the old original Mac OSX boot screen had a progress bar that was based on the exact length of the previous boot time.

I think the real question then is why are people running apps that need to be k8s-aware at all? K8s already provides a number of primitives to solve many problems without reinventing the wheel and going "cloud-native" within the application. There should be a very strong reason for any need to access the api directly.