Hey everyone! I manage a Kubernetes cluster with 16 worker nodes, and we have a lot of services running via a daemonset to help with load distribution. Right now, we're operating with over 75 pods on each node. My question is whether increasing the number of pods on our worker nodes could negatively affect CPU performance due to excessive context switching. What do you all think?
6 Answers
Yes, context switching can impact performance, but it's generally minimal unless you're dealing with very latency-sensitive workloads. If optimization is crucial, consider looking into Kubernetes' CPU Manager and NUMA awareness rather than relying solely on daemonsets. That’s especially key for storage cluster workers.
Ultimately, whether you use deployments or daemonsets won't matter much if you don't measure the actual scale needed. You could apply anti-affinity rules to deployments and still end up in the same situation. Multiple pods per node can work fine for uptimes and rollouts, but you'll need extra nodes for high availability and better performance.
Using daemonsets for load or performance balancing is a big mistake! You should switch to deployments.
Right, using a daemonset for load distribution isn’t really the intended use case. Switching to deployments might make more sense. You could be creating unnecessary pods for smaller apps while not having enough for the larger ones. Your concerns about performance and context switching are valid, but the solution might be fewer pods with more resources to see if that alleviates some of the load.
CPUs are quite fast, so it's worth monitoring your CPU load to see if you need more resources. It seems like the real issue might be your strategy of running a daemonset for everything. Having 16 replicas of every service sounds excessive for most scenarios. Consider using deployments with an appropriate number of replicas per service. This could free up CPU resources for the more intensive workloads. Also, look into pod disruption budgets to help manage node updates better.
Context switching happens due to the nature of the workloads, not just the number of processes. I'd suggest not worrying too much unless you start seeing issues. Typically, a deployment should suffice for scaling, and you might want to explore using HPA for spikes and PDB to keep some pods always running.
Definitely! Implementing pod affinity rules can help the scheduler better distribute workloads across nodes.