Cloud Native 11 min read

Key Configuration Options and Selection Guidance for Tencent Cloud TKE Clusters

This article explains the most important configuration choices for Tencent Cloud TKE—including Kubernetes version, network modes (GlobalRouter vs VPC‑CNI), container runtimes (Docker vs containerd), service forwarding (iptables vs ipvs), cluster types, node operating systems, node pools, and startup scripts—providing comparisons and practical recommendations to help users avoid common pitfalls.

Cloud Native Technology Community
Cloud Native Technology Community
Cloud Native Technology Community
Key Configuration Options and Selection Guidance for Tencent Cloud TKE Clusters

Author Chen Peng, a Tencent engineer responsible for TKE technical support, shares practical guidance and best‑practice recommendations to help customers build reliable Kubernetes clusters on Tencent Cloud.

When creating a TKE Kubernetes cluster, many configuration options must be considered; this article highlights the most critical ones and offers comparison and selection advice.

Kubernetes Version

Because Kubernetes releases evolve quickly, it is recommended to select the latest version supported by TKE when creating a cluster, with the ability to upgrade both master and node versions later.

Network Mode: GlobalRouter vs VPC‑CNI

GlobalRouter architecture: Uses CNI and a bridge to provide container networking, with container routing implemented directly on the underlying VPC. Containers share the same network plane as nodes, but the container CIDR does not overlap with the VPC CIDR, providing ample address space.

VPC‑CNI architecture: Uses CNI together with elastic VPC network cards; container routing goes through the elastic NIC, offering about 10% higher performance than GlobalRouter. Containers share the VPC CIDR and can have fixed IPs.

Three usage modes are supported: (1) create the cluster with GlobalRouter; (2) create the cluster with VPC‑CNI; (3) start with GlobalRouter and later enable VPC‑CNI for specific workloads. Recommendation: Choose GlobalRouter for most cases; enable VPC‑CNI only if a subset of workloads requires it, or select VPC‑CNI directly when you fully understand its constraints.

Runtime: Docker vs containerd

Docker architecture: kubelet uses the built‑in dockershim to adapt Docker to the CRI interface, then dockershim talks to dockerd via the Docker HTTP API, and dockerd further communicates with containerd (gRPC) for container creation and deletion. This long call chain exists because Docker was originally the only supported runtime and did not implement CRI directly.

containerd architecture: Since version 1.1, containerd includes a CRI plugin, allowing it to speak CRI natively. The call chain is shorter because dockershim and dockerd are bypassed.

Recommendation: Use Docker when maximum stability and compatibility with Docker‑specific tools (Docker‑in‑Docker, direct Docker commands, Docker API) are required; otherwise, prefer containerd for its lighter footprint and shorter call chain.

Service Forwarding Mode: iptables vs ipvs

kube‑proxy watches the API server, converts Service and Endpoint objects into either iptables or ipvs rules, and writes them to each node. Client traffic to a ClusterIP Service is then load‑balanced to backend Pods according to those rules.

Comparison: ipvs offers higher performance but still has some unresolved bugs; iptables is more mature and stable.

Recommendation: Use iptables for workloads requiring the highest stability and with fewer than 2000 Services; otherwise, default to ipvs.

Cluster Type: Managed vs Independent

Managed clusters: Master components are hidden and managed by Tencent Cloud, receive new features first, automatically scale resources, and are free of charge for the user.

Independent clusters: Users have full control over Master components and must purchase the underlying machines.

Recommendation: Generally prefer managed clusters; choose independent clusters only when you need full Master control for custom extensions.

Node Operating System

TKE supports Ubuntu and CentOS, with a “TKE‑Optimized” kernel based on the long‑term supported 4.14.105 version, tuned for containers and cloud workloads. The optimized kernel offers better performance, stability, and defect fixes, and its source is fully open‑source.

Recommendation: Use the TKE‑Optimized OS for the best stability and support; select a non‑optimized OS only if a newer kernel version is required.

Node Pool

This feature (currently in gray‑scale) allows batch management of nodes, including label and taint configuration, component start‑up parameters, custom start‑up scripts, and (future) OS/runtime selection. It is useful for heterogeneous node grouping, complex scheduling rules, frequent scaling, and routine maintenance.

Typical usage: create a node pool for I/O‑intensive workloads, assign a specific instance type, set appropriate labels/taints, and let HPA automatically scale the pool as demand grows.

Startup Scripts and Component Custom Parameters

During cluster creation, you can customize Master component start‑up parameters in the “Advanced Settings” of the cluster information page (see screenshot). When adding nodes, you can customize kubelet parameters in the “Advanced Settings” of the cloud server configuration page.

Node start‑up scripts can be added via the “Node Start‑up Configuration” option when creating a cluster or adding nodes, allowing you to modify component parameters, kernel settings, etc.

These customizations help tailor the cluster to specific workload requirements and operational policies.

References

Official documentation: How to Choose Container Service Network Mode , How to Choose Containerd and Docker , Node Pool Feature .

Kubernetestkecontainer runtimeCluster TypeNetwork ModeNode ManagementService Forwarding
Cloud Native Technology Community
Written by

Cloud Native Technology Community

The Cloud Native Technology Community, part of the CNBPA Cloud Native Technology Practice Alliance, focuses on evangelizing cutting‑edge cloud‑native technologies and practical implementations. It shares in‑depth content, case studies, and event/meetup information on containers, Kubernetes, DevOps, Service Mesh, and other cloud‑native tech, along with updates from the CNBPA alliance.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.