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…
Common mistakes using Kubernetes
111–120 of 149 posts
Re: Common mistakes using Kubernetes
#112Earlier quoted context omitted.
This was my thought exactly. The article is great assuming you need to use k8s, but does leave out the important question: does your project or product require k8s and all the overhead it unavoidably entails? Amazon's Elastic Container Service (ECS) on Fargate deployment type is probably a better option much of the time. Until you maintain your own k8s cluster (including the hosted variants on AWS, GCP, etc.) you mig…
Unless something has changed recently, Fargate is a terrible choice for something that you want up 24x7. IIRC it’s like 2x the cost of similar on demand EC2 instances. It’s better for discrete tasks that can’t run in Lambda because timeout or possibly peak load (although EC2 is probably just as easy if not easier to scale). But I generally agree with the premise that ECS is a better starting point for people just dip…
Re: Common mistakes using Kubernetes
#113I actually disagree with the first recommendation as written - specifically, not to set a CPU resource request to a small amount. It's not always as harmful as it might sound to the novice. It's important to understand that CPU resource requests are used for scheduling and not for limiting. As the author suggests, this can be an issue when there is CPU contention, but on the other hand, it might not be. That's becaus…
The example you are describing is probably not super common but I will try to rephrase my blogpost so that it reflects this comment:)
Re: Common mistakes using Kubernetes
#114The guaranteed QoS example in the article is wrong. Kubernetes only sets the Guaranteed QoS if the CPU count is an integer (which 0.5 is not). Also, to take full benefit of the QoS you need to configure the Kubelet with "--cpu-manager-policy static"[0]. [0]: https://kubernetes.io/blog/2018/07/24/feature-highlight-cpu-...
Re: Common mistakes using Kubernetes
#115I'm glad readers are liking the article, but please read and follow the site guidelines. Note this one: If the title begins with a number or number + gratuitous adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids." The submitted title was "10 most common mistakes using kube…
Re: Common mistakes using Kubernetes
#116Re: Common mistakes using Kubernetes
#117Earlier quoted context omitted.
> 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…
I wonder if we're on the same page. Should a book on a programming language discuss compilation errors and how to interpret them? Should a book like Effective C++ (afaik the most popular series of books on C++) exist?
Re: Common mistakes using Kubernetes
#118Earlier quoted context omitted.
> 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…
> Let's say you go to get a surgery. Shouldn't that be more like "Let's say you're learning to be a surgeon."? For that situation, the person they're learning from discussing problems they hit and how they solved them does sound like it would be very useful.
No. It is an exaggerated example, because I am illustrating a psychological effect.
The point is that you are consulting an expert, and you don't want that expert to tell you about all their mistakes, because your mind is now occupied with doubting that expert. It's not rational.
> For that situation, the person they're learning from discussing problems they hit and how they solved them does sound like it would be very useful.
It's useful to present common mistakes, but mentioning who made the mistake is both irrelevant and damaging.
Re: Common mistakes using Kubernetes
#119Well, nobody asked me, and I'm no expert, but here's my list of what (not) to do in Kubernetes (if I had the authority). 1. There. Is. No. Machine. (Insert matrix meme here.) Before you open up your cluster to the rest of company, drill it down to them. Maybe even create a Google Form where they have to sign "I hereby acknowledge that there is no machine in k8s and any attempt to tie my job to a particular machine me…
This piece of advice is so underrated, it's hard to put into words. Every senior developer/architect should know that.
Re: Common mistakes using Kubernetes
#120Earlier quoted context omitted.
> 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…
I sure do want that surgeon to have been presented/instructed on the common ways that surgeons before them have made mistakes and how to avoid or overcome them. That they won’t tell me (the patient) is quite a different question from whether they got the material from someone more experienced in their primary or continuing medical education.