HI version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
67% Positive
Analyzed from 223 words in the discussion.
Trending Topics
#usually#trying#kube#avoid#why#kubernetes#manage#server#otherwise#hard

Discussion (5 Comments)Read Original on HackerNews
Something like this allows unconstrained config drift with no audit trail.
That's tongue in cheek but a pretty hard check too, imo. The thing of it is, I like kubernetes, I think you'd have to be mad to opt to re-figure this all out, to get adequate parity. But but but I do want there to be competition, evolution, I want people trying things.
Usually though the competition is trying to do far less. When people eskew Kube, it's usually because they think they are right sizing their approach, "you might not need Kube". Usually they are trying to avoid building an API based platform that scales across different concerns (no CRD, no api-server). Usually they are trying to avoid autonomics, avoid OODA loops, avoid self healing. Usually the desired state management is fairly limited.
I'd like to see more attacks on kubernetes that are from above, and not below. Why is yours better? Being smaller, doing less, is so far the only reason I've heard, the only reason I've seen people go for, what to me, is their own personal tilt at the windmills that Kube has done. This is a hard foe to try to tilt at, and I wish yee tilters the best, I just think it needs to be a more principled still general approach to actually be meaningful. Otherwise: you should Kube.