81–90 of 149 posts
It misses the biggest one: using it. I ranted about the cloud a decade ago http://drupal4hu.com/node/305 and there's nothing new under the Sun. Still most companies doing cloud and Kubernetes doesn't need it... practice YAGNI ferociously.
This also needs a companion post called "common mistakes: using kubernetes". I feel like it's a weekly occurrence now where I hear of a startup launching their mvp on kubernetes having spent 8 months too long on Dev as a result. The other day in an interview someone bragged to me how he had convinced his team to spend 12 months moving to K8s. Upper management thought it was a waste of time but eventually agreed. I as…
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.
Earlier quoted context omitted.
>They said the reader wants to see an expert talking, as if experts never make mistakes or need to shift from one tact to another. Your editor was very fucking wrong.
> Your editor was very fucking wrong. The editor is completely right in what they were saying. You just want them to be wrong, because you'd prefer to live in the fantasy world where they are wrong. Let's say you go to get a surgery. You don't want the doctor to tell you about all the times they fucked up and what the awful consequences were. It doesn't matter that they're probably a better surgeon now, having learne…
... requiredDuringSchedulingIgnoredDuringExecution: ... This instantly remembered me of this: https://thedailywtf.com/articles/the-longest-method Kubernetes sometimes shows its Java roots.
That Java link in the article goes to a completely not-Java Chinese site btw
This also needs a companion post called "common mistakes: using kubernetes". I feel like it's a weekly occurrence now where I hear of a startup launching their mvp on kubernetes having spent 8 months too long on Dev as a result. The other day in an interview someone bragged to me how he had convinced his team to spend 12 months moving to K8s. Upper management thought it was a waste of time but eventually agreed. I as…
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…
> You can't expect kubernetes scheduler to enforce anti-affinites for your pods. You have to define them explicitly. Why isn't this the default behavior? Why don't I have to go in and tell it that it's okay to have multiple instances on the same node? Why? So that I somehow feel like I've contributed to the whole process by fixing something that never should break in the first place? I know of a few pieces of code wh…
If configured as suggested, and for some reason you lose enoguh nodes in your cluster for not having single node for each of your replicas, you will have less replicas than you intended, since the scheduler can't schedule a pod to a node where identical pod is already running.
Additionally, the affinity and anti affinity features are costly from the cluster perspective, so the configuration recommended by the author cost you performance.
And why isn't Kubernetes doing the obvious thing and spread apart your pods? well, it's simple - it does the right thing:
https://v1-15.docs.kubernetes.io/docs/concepts/scheduling/ku...
The first scoring parameter is SelectorSpreadPriority.
This also needs a companion post called "common mistakes: using kubernetes". I feel like it's a weekly occurrence now where I hear of a startup launching their mvp on kubernetes having spent 8 months too long on Dev as a result. The other day in an interview someone bragged to me how he had convinced his team to spend 12 months moving to K8s. Upper management thought it was a waste of time but eventually agreed. I as…
Maybe on GCP (I don't see a lot of companies on GCP) it makes sense, but ECS is AWS native and on bare hardware I immediately go to docker swarm since it ships with the container runtime (instead of a bolted on sidecar container thing).
I like the primitives and features of Kubernetes, but the implementation doesn't give me warm fuzzies and it always gets passed over for safer bets for me. Even very early on in it's development I always went to Mesos over Kubernetes (though Mesos is P dead at this point).
I wish there was a way to upvote something 10x once a month here. This would be the post I use that on. When I was writing my book my editor asked me to remove any writing about mistakes and changes I made in the project for each chapter. I had a bug that appeared and I wanted to write about how I determined that and fixed it. They said the reader wants to see an expert talking, as if experts never make mistakes or n…
I was told not to mention the caveats, instead, render a confident image for the team many times in my career.
It's like doctors suggest their patients to use some drugs without mentioning any side effects.
It reminds me of the video[0] which asks the developer to draw red lines with blue ink, while the project manager keeps pushing the developer like "You're the expert, of course you can do draw red lines with blue ink!".