The current trend goes to multi-cluster environments, because it's way too easy to destroy a single k8s cluster due to bugs, updates or human mistake. Just like it's not an very unlikely event to kill a single host in the network e.g. due to updates/maintenance. For instance, we had several outages when upgrading the kubernetes version in our clusters. If you have many small cluster it's much easier and more save to…
Sounds like madness. Should we expect a new tool that orchestrates all of your Kubernetes clusters?
Kubernetes Failure Stories
71–80 of 203 posts
Re: Kubernetes Failure Stories
#72The Istio one hits home. It is the single scariest thing to work with in our kubernetes clusters. We've caused several outages by changing the smallest things.
Re: Kubernetes Failure Stories
#73Earlier quoted context omitted.
I've got a different read on this. It's always been complicated, it's just that each.. I don't want to say "generation", but roughly the same concept, grew up with and internalized and knew about the complexities of the tech stacks they learned, and so when something comes about that moves the abstraction one level higher than what people are used to, it's seen as unstable crap. This isn't some ageist kids-these-days…
Wow you must be old. Like probably retiring now? VM/370 came out 49 years ago. So assuming you did a master's at university (I guess math at the time) I'd say you are definite retired by now. https://en.m.wikipedia.org/wiki/VM_(operating_system) (yes this is tongue in cheek sort of since you said average but you also said 'enterprise' which my cheek reads as large company :))
Re: Kubernetes Failure Stories
#74Earlier quoted context omitted.
The tech churn cycle is getting more and more insane. It's the same process repeating endlessly. 1. Identify one problem you want to fix and ignore everything else. 2. Make a tool to manage the problem while still ignoring everything else. 3. Hype the tool up and shove it in every niche and domain possible. 4. Observer how "everything else" bites you in the ass. 5. Identify the worst problem from #4, use it to start…
I've got a different read on this. It's always been complicated, it's just that each.. I don't want to say "generation", but roughly the same concept, grew up with and internalized and knew about the complexities of the tech stacks they learned, and so when something comes about that moves the abstraction one level higher than what people are used to, it's seen as unstable crap. This isn't some ageist kids-these-days…
Re: Kubernetes Failure Stories
#75Earlier quoted context omitted.
Wow you must be old. Like probably retiring now? VM/370 came out 49 years ago. So assuming you did a master's at university (I guess math at the time) I'd say you are definite retired by now. https://en.m.wikipedia.org/wiki/VM_(operating_system) (yes this is tongue in cheek sort of since you said average but you also said 'enterprise' which my cheek reads as large company :))
Bruv. You're catching downvotes for two reasons. A: ageism and B: also not realising that tools like the "old ones" used lasted decades. Release dates are a poor metric here.
... the ancient equivalent of Kubernetes was released in 1973 (JES3)
Re: Kubernetes Failure Stories
#76Earlier quoted context omitted.
Sounds like madness. Should we expect a new tool that orchestrates all of your Kubernetes clusters?
That's what Federation in Kubernetes was for, sort of, but it has never really come to fruition. The closest I've seen is Admiralty, but I'm not sure how it actually works out in reality.
Unfortunately, all my clusters are either confined locally anyway, or are deliberately supposed to be separated in all ways :(
Re: Kubernetes Failure Stories
#77The Istio one hits home. It is the single scariest thing to work with in our kubernetes clusters. We've caused several outages by changing the smallest things.
Re: Kubernetes Failure Stories
#78Re: Kubernetes Failure Stories
#79Re: Kubernetes Failure Stories
#80For anyone who thinks running a database in a container environment is a neat idea, think again. I am guilty of using containers for temporary test databases, but the thought of running production databases in containers sends shivers down my spine.