Recommended cluster node configurations

Cluster planning

Some customers prefer to configure small-capacity nodes when they create a Kubernetes cluster. Small-capacity nodes have the following disadvantages:

• Network resources of the small-capacity nodes are limited.
• If a small-capacity node is occupied by a container, the available resources of the node cannot be used to, for example, create another container or recover a failed container. When the number of small-capacity worker nodes increases, resources are wasted.

Large-capacity nodes have the following advantages:

• Large-capacity nodes are assigned high network bandwidth. If your applications require high network bandwidth, the resource utilization is increased.
• Container communication inside a node increases, resulting in decreased network transmission.
• Image pull efficiency increases. Images can be used by multiple containers after they are pulled. On small-capacity nodes, images must be pulled frequently, affecting the speed of starting containers.

Recommended master node configurations

The capacity of a master node is subject to the cluster scale. A large cluster requires large-capacity master nodes. The following table describes the recommended master node configurations in different cluster scales.

Worker node selection

• To ensure stability of nodes, KCE reserves some resources on the nodes based on the node specifications for Kubernetes components, such as kubelet, kube-proxy, and docker. For more information, see Reserve resources in a cluster. We recommend that you select node configurations based on the reserved resources and your business requirements.

• Determine the CPU-memory ratio based on your business type. If you need to run applications that require much memory, for example, Java applications, we recommend that you select KEC instances with a CPU-memory ratio of 1:8. If your applications are CPU intensive, you can select KEC instances with a CPU-memory ratio of 1:2. If you deploy different business applications together, we recommend that you attach labels to nodes of different instance types or configurations and schedule pods based on nodeAffinity.