4 ms·
nightmares (if anything went wrong i had to blow helm stuff away and start over) ontop of nightmares (kubernetes when i was trying it was tons of namespaces cal
by beefnugs 11mo ago
nightmares (if anything went wrong i had to blow helm stuff away and start over) ontop of nightmares (kubernetes when i was trying it was tons of namespaces called beta, then you never knew what to update to or when you had to update, or what was incompatible) ontop of the realization that no one should be using kubernetes unless you have over 50 servers running many hundreds of services. Otherwise its just a million times simpler using docker compose
- mch82 11mo agoCan you recommend any articles about minimum scale necessary to make Kubernetes worth it?
- wvh 11mo agoIf you count 3 control plane nodes and at least one or two extra servers worth of space for pods to go when a node goes down, I'd say don't bother for anything less than 6-7 servers worth of infrastructure. Once you're over 10 servers, you can start using node affinity and labels to have some logical grouping based on hardware type and/or tenants. At that point it's just one big computer and the abstraction starts to really pay off compared to manually dealing with servers and installation scripts. I'd say the abstraction is not worth it when you have only a steady 2-3 servers worth of infrastructure. Don't do it at "Hello, world!" scale, you win nothing. (I work for a company that helps other companies set up and secure larger projects into environments like Kubernetes.)
- wavesquid 11mo agoThe answer today is more than one node (instance/kernel running)
- vbezhenar 11mo agoI would always use Kubernetes, if you have 4 or more GB RAM on your server. It's just better than docker compose in every imaginable way. The only issue with Kubernetes is that it wants around 2 GB RAM for itself.