71–80 of 216 posts
Oh boy. Please, please stop using Medium for anything. I have lost count of how many potentially interesting or informative articles are published behind the Medium sign-in wall. At least for me, if you aren't publishing blog articles in public then what's the point of me trying to read them.
> "Create an account to read the full story." Why is this required?
Earlier quoted context omitted.
We ran only two (very small) clusters for some time in the past and even then it introduced some unnecessary overhead on the ops side and some headaches on the dev side. Maybe they were just growing pains, but if I have to run Kubernetes again I will definitely opt for a single large cluster. After all Kubernetes provides all the primitives you need to enforce separation. You wouldn't create separate VMWare productio…
Kubernetes upgrades? Don't those risk bricking everything with just 1 environment?
Why exactly did they have 47 clusters? One thing I noticed (maybe because I’m not at that scale) is that companies are running 1+ clusters per application. Isn’t the point of kubernetes that you can run your entire infra in a single cluster, and at most you’d need a second cluster for redundancy, and you can spread nodes across regions and AZs and even clouds? I think the bottleneck is networking and how much crossta…
We ran only two (very small) clusters for some time in the past and even then it introduced some unnecessary overhead on the ops side and some headaches on the dev side. Maybe they were just growing pains, but if I have to run Kubernetes again I will definitely opt for a single large cluster. After all Kubernetes provides all the primitives you need to enforce separation. You wouldn't create separate VMWare productio…
I completely agree with keeping everything as simple as possible though. No extra clusters if not absolutely necessary, and also no extra namespaces if not absolutely necessary.
The thing with Kubernetes is that it was designed to support every complex situation imaginable. All these features make you feel as though you should make use of them, but you shouldn't. This complexity leaked into systems like Helm, which why in my opinion it's better to roll your own deployment scripts rather than to use Helm.
How do you end up with 200 yaml file “basic deployments” without anyone looking up from their keyboard and muttering “guys what are we doing”? Honestly they could have picked any stack as next one because the key win here was starting from scratch
This is not that surprising. First, it depends on how big the YAML files were and what was in them. If you have 200 services, I could easily see 200 YAML files. Second, there are non-service reasons to have YAML files. You might have custom roles, ingresses, volumes, etc. If you do not use something like Helm, you might also have 1 YAML file per environment (not the best idea but it happens). My suspicion is the orig…
Out of curiosity, in what case would you _not_ see 200 files for 200 services? Even with Helm, you'd write a chart per app wouldn't you?
> In short, organizational decisions and an overly cautious approach to resource isolation led to an unsustainable number of clusters.
And while I emphasize with how they could end up in this situation, it feels like a lot of words were spent blaming the tool choice vs being a cautionary tail about for example planning and communication.
Either your pre profit or some other bogus entity, or your company streamlined moving to k8s and then further streamlined by cutting away things you don't need.
I'm frankly just alarmed at the thought of wasting that much revenue, I could bring up a fleet of in house racks for that money!
Earlier quoted context omitted.
I don't think this is a fair comment. This happens sometimes but usually people go with Kubernetes because they really do need its power and scalability. Also, any technology can be misused and abused. It's not the technology's fault. It's the people who misuse the technology's fault ( ). ( ) Even here, a lot of it comes from ignorance and human nature. 99.9% of people do not set out to fail. They usually do the best…
The pointy is most organisations reach for container orchestration before they attempt to build fast software on a single machine.
Performance isn’t the only reason to use container orchestration tools: they’re handy for just application lifecycle management.
Oh boy. Please, please stop using Medium for anything. I have lost count of how many potentially interesting or informative articles are published behind the Medium sign-in wall. At least for me, if you aren't publishing blog articles in public then what's the point of me trying to read them.
Earlier quoted context omitted.
> "Create an account to read the full story." Why is this required?
They are also misleading the users with that message. I signed up, but now I got a message that I have to upgrade to a paid account... If they had told me that from the start, I would not bother with creating an account at all. The message implies that a free account would be enough
Why exactly did they have 47 clusters? One thing I noticed (maybe because I’m not at that scale) is that companies are running 1+ clusters per application. Isn’t the point of kubernetes that you can run your entire infra in a single cluster, and at most you’d need a second cluster for redundancy, and you can spread nodes across regions and AZs and even clouds? I think the bottleneck is networking and how much crossta…