How to Choose the Right Kubernetes Worker Nodes and Cluster Architecture on Alibaba Cloud

Worker Node Instance Selection

Survey data (Dimanti 2019) shows that >55% of customers prefer bare‑metal servers for container workloads because virtualization adds significant I/O overhead. Additional motivations include cost reduction (≈36% avoid VM license fees), lower resource overhead (≈30%), higher deployment density (≈24%) and flexibility in networking/storage choices (≈28%).

Alibaba Cloud provides:

Elastic Bare Metal (ECS Bare Metal) instances with a lightweight custom hypervisor that offloads most virtualization functions to dedicated hardware, delivering near‑full CPU and memory resources and improved I/O.

Sixth‑generation VM instances built on the “Shenlong” architecture (Cascade Lake CPUs, up to 3.2 GHz) offering VM elasticity with bare‑metal‑level performance.

General guidance :

Use bare‑metal for latency‑sensitive, high‑performance computing or when Intel SGX / secure enclaves are required.

Choose sixth‑generation VM instances for flexible, cost‑effective scaling with enhanced I/O.

Leverage VM hot‑migration to reduce operational overhead.

CPU and NUMA Tuning on Large‑Spec Nodes

On nodes with many CPUs, the default kubelet CFS quota can cause pods to migrate across cores, hurting cache affinity and increasing scheduling latency. For large‑spec instances, configure cpuset to pin containers to specific CPUs. Example:

apiVersion: v1
kind: Pod
metadata:
  name: cpu‑pinned-pod
spec:
  containers:
  - name: app
    image: myapp:latest
    resources:
      limits:
        cpu: "4"
    securityContext:
      capabilities:
        add: ["SYS_NICE"]
  nodeSelector:
    kubernetes.io/hostname: "node‑large"
  # Pin to CPUs 0‑3
  cpuManagerPolicy: static
  cpuManagerReconcilePeriod: "5s"
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: myapp

NUMA awareness is also critical. Improper memory placement on NUMA‑enabled bare‑metal or large VM instances can reduce throughput by up to 30%. Kubernetes topology manager provides basic NUMA support, but full exploitation may require additional tooling (e.g., custom CGroup controllers).

Reference: https://kubernetes.io/docs/tasks/administer-cluster/topology-manager/

Container Runtime Choices

Market share (Sysdig 2019): Docker 79%, containerd and cri‑o gaining traction. Docker offers a rich developer toolchain (image build, logging, networking, Swarm) and is convenient as a default runtime. containerd has a smaller footprint and is preferred for security‑focused, lightweight deployments.

Alibaba Cloud and Ant Financial introduced the RunV security sandbox, which runs each container on an isolated kernel. RunV achieves ~90% of native RunC performance while providing strong isolation against kernel‑level attacks.

Terway CNI delivers lossless network performance.

DeviceMapper‑based graph driver offers high‑speed, stable storage.

Optimized FlexVolume and CSI plugins move mount‑bind operations into the sandbox, avoiding 9pfs overhead.

ACK supports both RunC and RunV side‑by‑side, allowing per‑workload runtime selection.

Cluster Size and Multi‑Cluster Strategies

Enterprises often choose between a single large cluster and multiple smaller clusters. Multiple clusters reduce blast radius, improve availability, and enable resource isolation (development vs. testing, department‑level, application‑specific, different K8s versions).

Best‑practice recommendations:

Use multi‑region clusters for cross‑region workloads, connecting VPCs via Cloud Enterprise Network (CEN).

Adopt multi‑cluster isolation for high‑security domains.

For SaaS workloads, a single cluster with strong tenant isolation (PodSecurityPolicy, NetworkPolicy, security sandbox) can be sufficient.

Large‑scale workloads (online services, AI training, real‑time analytics) benefit from dedicated clusters tuned to specific resource profiles.

Serverless Kubernetes (ASK) and ACK on Elastic Container Instances (ECI)

ASK (Alibaba Cloud Serverless Kubernetes) removes the node abstraction. Pods run on Elastic Container Instances (ECI), lightweight VMs that provide sandbox isolation and full compatibility with Kubernetes Pod semantics. Key characteristics:

Pay‑per‑use pricing based on actual container consumption.

Zero node management; developers focus on application code.

On‑demand provisioning eliminates capacity planning.

ASK uses an extended Virtual‑Kubelet to create virtual nodes that instantiate ECI pods on demand. Node‑specific features such as NodePort and DaemonSet‑based system components must be re‑architected as sidecars.

ACK on ECI combines managed K8s control plane with the ability to run workloads on either traditional ECS instances or ECI, offering flexibility for bursty, batch, or security‑isolated workloads.

Planning Checklist

Assess I/O intensity and decide between bare‑metal and VM instances.

For large‑spec nodes, configure cpuset and NUMA policies to preserve cache affinity.

Select container runtime: Docker for developer convenience, containerd for lightweight security, RunV for strong isolation.

Determine cluster topology (single vs. multiple) based on isolation, scalability, and operational overhead.

Consider serverless options (ASK) for bursty or batch workloads.

Adopt GitOps (e.g., Flux: https://github.com/fluxcd/flux) and service mesh (ASM/Istio) for unified configuration and traffic management across clusters.