Kubernetes中为何要限制单节点最大Pod数量？

Great question! It makes total sense to wonder why Kubernetes caps the number of Pods you can run—scaling out is a core use case for orchestration, so these limits aren’t arbitrary. Let’s dive into the main bottlenecks that drive these constraints:

• API Server Overload
  The Kubernetes API Server is the central hub for all cluster operations. Every Pod creation, update, or status check hits the API Server. When you have thousands of Pods, the server has to handle a flood of requests, which strains its CPU, memory, and request queue capacity. Default configurations set limits on concurrent connections and QPS (queries per second); exceed these, and you’ll see slow responses, timeouts, or even API Server crashes.

• etcd Performance and Storage Limits
  etcd stores all cluster state, including every Pod’s metadata (labels, annotations, status, etc.). It’s a distributed key-value store optimized for consistency, not high-throughput writes. A large number of Pods means:

  • Frequent write operations (e.g., Pod status updates) that push etcd’s IO and CPU to its limits.
  • Increased storage usage—too much metadata can slow down read queries and force you to scale etcd, which adds complexity.
    etcd also has built-in throttling to protect itself, so excessive Pod churn can trigger this and block new Pod creation.

• Node-Level Resource and System Constraints
  Each node can only run so many Pods, and this is limited by more than just CPU/memory:

  • Kernel Limits: Linux has hard limits on system resources like the number of process IDs (each Pod has at least one process), network namespaces (each Pod gets its own), and file descriptors. Exceed these, and the kernel will refuse to create new Pods.
  • Resource Quotas: Even if you have spare CPU/memory, Kubernetes lets you set node-level Pod limits to prevent overloading the node’s kubelet or system services. The default limit is 110 Pods per node, but this varies by cloud provider and node size.

• Network Plugin Overhead
  CNI (Container Network Interface) plugins handle Pod networking—assigning IPs, setting up routes, and managing network policies. With hundreds or thousands of Pods:

  • The CNI plugin has to process a massive number of network configuration requests, leading to delays in Pod readiness.
  • Network bandwidth becomes a bottleneck: too many Pods communicating simultaneously can saturate the node’s network interface, causing latency or dropped packets.

• Kubelet Capacity
  The kubelet runs on every node and is responsible for managing local Pods—starting containers, running health checks, reporting status to the API Server. If a node has too many Pods, the kubelet’s CPU and memory usage skyrockets. It can’t keep up with health checks or status updates, leading to false positive failures or unresponsive Pods.

• Scheduler Latency
  The Kubernetes scheduler has to evaluate every available node for each new Pod, checking resource availability, taints/tolerations, affinity rules, and more. As the number of Pods (and nodes) grows, the scheduler’s work becomes exponentially more intensive. This leads to longer wait times for Pods to be scheduled, or even scheduler timeouts.

These constraints work together—you can’t just crank up the Pod limit without checking if your API Server, etcd, nodes, and network can handle the load. Most clusters start with the default limits and adjust them incrementally based on real-world usage.

内容的提问来源于stack exchange，提问作者Gal A.