3 ms·
> Because Kubernetes itself runs on the machines that are running your databases, it will consume some resources and will slightly impact performance. In our te
by rrdharan 9y ago
> Because Kubernetes itself runs on the machines that are running your databases, it will consume some resources and will slightly impact performance. In our testing, we found an approximately 5% dip in throughput on a simple key-value workload.
5% seems like a surprisingly large overhead. What is k8s doing in this situation that would have that kind of impact?
- smarterclayton 8y agoCPU Cache contention, network overhead introduced by Kubernetes service proxy model, even the liveness checks. We haven’t yet evolved Kubernetes services to prefer specific cores and avoid app workloads quite yet (although cpu management is getting closer). Docker is also somewhat hefty memory wise and you may contend on disk if not careful. 5% seems pretty reasonable to me in general, just as a consequence of having something heavier weight on the same node managing workloads.
- a-robinson 8y agoYeah, it appeared to just be general resource contention from having to share the machine -- CPU interrupts, less memory available, etc. I'll note, though, that the 5% number is when using host networking for both Cockroach and the client load generator. Using GKE's default cluster networking through the Docker bridge is closer to 15% worse than running directly on equivalent non-Kubernetes VMs.
- nimos 8y agoHard to say without knowing what they ran on what. There is a non trivial amount of memory that gets eaten up by the various k8s processes, docker and networking if you are using small nodes. I have a completely empty k8s cluster up right now with 1 worker and 1 master and the worker has about ~230 mb of ram used up.