腾讯云TKE原生节点完全对接指南：从集群创建到生产级调度运维

apphuang2026年06月24日 19:44:129

引言：为什么需要原生节点

在云原生技术大规模落地的今天，Kubernetes 集群的节点管理已成为运维团队的核心挑战之一。传统节点在资源利用率、调度灵活性和运维自动化方面存在诸多瓶颈——CPU 实际利用率往往仅维持在 10% 到 15% 之间，大量资源处于闲置状态。腾讯云 TKE 原生节点（TKE Native Node）正是为解决这一问题而推出的全新节点类型，它依托腾讯云千万核容器运维的技术沉淀，为用户提供原生化、高稳定、快响应的 K8s 节点管理能力。

与普通节点相比，原生节点在管理模式、调度能力、故障自愈和节点管理等多个维度做了全方位增强。它搭载 FinOps 理念，通过 HouseKeeper 可视化资源大盘助力提升节点资源利用率；提供智能 Request 推荐，减少资源闲置；支持 Pod 原地升降配、内核参数调优、节点故障自愈等普通节点不具备的高级能力。本文将从零开始，系统讲解 TKE 原生节点的完整对接使用流程。

需要先登录腾讯云控制台，点击：腾讯云控制台，还没有账号，点击：注册后再关联，已有账号点击：登录后再关联

一、前置条件：创建 TKE 标准集群

原生节点无法独立存在，必须依托于 TKE 标准集群。因此，对接原生节点的第一步是创建一个标准集群。

1.1 集群创建步骤

登录容器服务控制台后，在左侧导航栏中选择"集群"，单击集群列表上方的"新建"按钮。在集群类型中选择"标准集群"，单击创建。创建过程中需要配置以下核心参数：

集群名称：自定义，便于后续管理
Kubernetes 版本：建议选择当前最新稳定版本，原生节点对 Kubernetes 版本有一定要求（如 Node-Healing 组件要求 >= 1.18）
运行时组件：支持 Docker 和 Containerd，建议选择 Containerd
容器网络插件：可选择 Global Router 或 VPC-CNI。如需使用 Pod 独立安全组等高级网络能力，需选择 VPC-CNI 共享网卡 + 固定 IP 模式
容器网络 CIDR：建议不与集群所在 VPC 网络冲突，可按 1024 个 Service/集群、128 个 Pod/节点、504 个节点/集群的规模进行规划

1.2 集群创建后的验证

集群创建完成后，在集群列表页中单击集群 ID 进入集群详情页。此时集群尚无工作节点，需要下一步通过节点池来添加原生节点。

二、创建原生节点池

原生节点仅支持通过节点池进行管理。节点池是 TKE 引入的集群节点管理概念，借助节点池可以方便快捷地创建、管理和销毁节点，以及实现节点的动态扩缩容。

2.1 通过控制台创建原生节点池

在集群详情页中，选择左侧菜单栏中的"节点管理"，在节点池页面中单击"新建"。在新建页面中，节点类型选择"原生节点"，单击创建。

接下来需要配置以下关键参数：

节点池名称：自定义，建议按业务或环境命名
计费模式：支持按量计费（PostpaidByHour）和包年包月（PrepaidCharge）两种模式。按量计费适合潮汐型业务或测试环境，包年包月单价更低，适合长期稳定的生产业务
机型配置：根据业务需求选择 CPU 或 GPU 实例类型。如需使用 qGPU 能力，需选择支持的 GPU 机型
系统盘与数据盘：配置磁盘类型（如 CloudPremium）、大小和挂载路径。数据盘通常挂载到 /var/lib/containerd 作为容器运行时存储目录
安全组：绑定安全组以控制节点的网络访问策略
节点数（replicas）：初始节点数量
自动扩缩容策略（scaling）：可配置最大节点数（maxReplicas）和创建策略（如 ZonePriority 可用区优先）

在"高级设置"中还可以配置自定义脚本（preInit/postInit）、污点（taints）、标签（labels）和注解（annotations）等。配置完成后单击"创建节点池"即可。

2.2 通过 YAML 声明式创建原生节点池

原生节点支持基础设施声明式 API，可以像管理 workload 一样通过 Kubernetes API 管理节点。以下是一个完整的原生节点池 YAML 示例：

apiVersion: node.tke.cloud.tencent.com/v1beta1
kind: MachineSet
spec:
  autoRepair: false  # 故障自愈开关
  displayName: production-worker-pool
  healthCheckPolicyName: ""  # 自愈规则名称
  instanceTypes:
    - S5.MEDIUM4  # 机型规格
  replicas: 3  # 初始节点数
  scaling:
    createPolicy: ZonePriority
    maxReplicas: 10  # 最大节点数
  subnetIDs:
    - subnet-xxxxxxxx  # 节点池子网 ID
  template:
    metadata:
      annotations:
        node.tke.cloud.tencent.com/machine-cloud-tags: '[{"tagKey":"env","tagValue":"production"}]'
    spec:
      displayName: tke-worker
      deletePolicy: Random
      metadata:
        labels:
          node-role: worker
          environment: production
      providerSpec:
        type: Native
        value:
          dataDisks:
            - deleteWithInstance: true
              diskSize: 100
              diskType: CloudPremium
              fileSystem: ext4
              mountTarget: /var/lib/containerd
          instanceChargeType: PostpaidByHour
          keyIDs:
            - skey-xxxxxxxx
          lifecycle:
            preInit: "echo 'before node init'"
            postInit: "echo 'after node init'"
          management: {}
          securityGroupIDs:
            - sg-xxxxxxxx
          systemDisk:
            diskSize: 50
            diskType: CloudPremium
          runtimeRootDir: /var/lib/containerd
          taints: []
          type: Native

通过 kubectl apply 该 YAML 文件即可创建原生节点池。这种方式特别适合基础设施即代码（IaC）场景，可与 GitOps 工作流无缝集成。

三、原生节点专用调度器：突破资源利用率瓶颈

原生节点最核心的能力之一是其专用调度器。传统 Kubernetes 调度器基于 Pod 的 Request 进行调度决策，而实际资源利用率往往远低于 Request 值，导致"装箱率高但利用率低"的困境。原生节点专用调度器通过虚拟放大节点规格和基于真实负载的调度，从根本上解决了这一问题。

3.1 安装原生节点专用调度器

在 TKE Insight 的 Node Map 页面中，鼠标悬浮到任意原生节点上并单击详情。在节点详情页右上角打开"原生节点专用调度器"开关即可完成安装。该能力为全局能力，一个集群只需开启一次即可。

3.2 配置节点放大系数与水位线

安装完成后，在 Node Map 页面单击需要进行节点放大的原生节点进入详情页，点击原生节点专用调度器右侧的编辑按钮。在编辑页面可配置以下核心参数：

规格放大：虚拟放大原生节点规格，使节点可以调度更多 Pod，让装箱率突破 100%。但需注意风险——若节点上调度的 Pod 实际使用总资源量超过节点物理规格，会触发 Pod 驱逐和重新调度
静态放大系数-CPU：支持输入 1 到 3 之间的数字（保留小数点后一位）。例如设置为 3，意味着节点可调度的 CPU 资源被虚拟放大为物理规格的 3 倍
静态放大系数-内存：支持输入 1 到 2 之间的数字（保留小数点后一位）
调度时水位控制：设定节点目标资源利用率。Pod 调度时，近 5 分钟平均利用率和 1 小时最大利用率高于该水位的节点将不被选中
运行时水位控制：节点运行时，近 5 分钟平均利用率高于该水位的节点可能触发驱逐

调度时水位同时作为驱逐停止水位线和低负载节点判断水位线。例如运行时水位设为 80、调度时水位设为 60，则节点利用率达到 80 后开始驱逐，按可驱逐 Pod 利用率高低依次驱逐，直到水位降到 60 以下。

需要注意的是，默认情况下业务 Pod 不会被驱逐。对于允许驱逐的 Pod，需在工作负载（如 Deployment、StatefulSet）上添加 annotation：descheduler.alpha.kubernetes.io/evictable: 'true'。同时，驱逐操作要求至少有三个原生节点的利用率低于调度时水位，以保证 Pod 有处可去。

在生产实践中，通过规格放大（CPU 放大 3 倍、内存放大 2 倍），CPU 分配率可以从 60% 提升至 110%，同时节点数下降 30%。这正是原生节点 FinOps 理念的核心价值——用更少的资源承载更多的工作负载。

四、AI 场景的 GPU 调度：qGPU 组件

对于 AI 训练和推理等 GPU 密集型场景，TKE 原生节点提供了 qGPU 组件，实现 GPU 资源的共享和精细化管理。

4.1 qGPU 的使用前提

qGPU 仅支持原生节点。支持的 GPU 卡架构包括 V100、T4、A100、A10、L40、L40s 等主流型号。驱动版本支持 450/470/515/525/535/550/570 系列，CUDA 版本支持 11.4/12.2/12.4/12.8。

4.2 安装 qGPU 组件

在集群详情页的"组件管理"中安装 qGPU 组件。安装后，集群内会部署以下 Kubernetes 对象：

qgpu-manager：DaemonSet，每 GPU 节点一个，负责 GPU 设备管理
qgpu-scheduler：Deployment，基于 Kubernetes Scheduler Extender 机制开发的 GPU 资源扩展调度器

4.3 GPU 资源共享粒度

qGPU 支持细粒度的资源分配：

显存：最小分配 1G，精度单位为 1G
算力：最小分配 5（代表一张卡算力的 5%），最大 100，精度单位为 5（即 5、10、15、20……100）
整卡分配：可按 tke.cloud.tencent.com/qgpu-core: 100 | 200 | ...（N * 100，N 为整卡个数）的方式分配整卡
单卡最大 qGPU 设备数：一个 GPU 卡上最多可创建 16 个 qGPU 设备

在 Pod 的 YAML 中声明 qGPU 资源如下：

resources:
  limits:
    tke.cloud.tencent.com/qgpu-core: 30   # 30% 算力
    tke.cloud.tencent.com/qgpu-memory: 4  # 4GB 显存

通过 qGPU 的两层调度策略（节点级和 GPU 卡级），结合 binpack 或 spread 策略组合，可有效解决 GPU 资源碎片问题。在智能辅助驾驶等实际场景中，利用算力错峰复用，700 多张 GPU 卡即可完成原本需要 1600+ TB/天的数据处理任务，总成本降低 30%。

五、节点自愈：Node-Healing 组件

生产环境最怕节点故障，TKE 原生节点提供了 Node-Healing 节点自愈组件，可实现从故障检测到自动修复的完整闭环。

5.1 组件概述

Node-Healing 与 Node Problem Detector（NPD）配合使用。NPD 负责检测节点异常，Node-Healing 根据预定义策略执行自动化修复操作。该组件支持 40 种故障类型的自愈策略，涵盖：

内核/系统类故障
资源压力类故障
服务健康类故障
K8s 组件扩展类故障
GPU 监控类故障

Node-Healing 仅支持原生节点，不支持超级节点、第三方节点（注册节点）和普通节点。

5.2 安装与权限

在集群详情页的"组件管理"中安装 Node-Healing 组件。组件需要以下核心权限：

获取、监听、更新节点状态和标签
获取 Pod 信息并执行驱逐操作
管理自愈模板、自愈策略和自愈任务等 CRD 资源

部署后集群内会创建 machinehealingtemplates、nodehealers、healingtasks 三个 CRD。

5.3 自愈配置示例

在创建原生节点池时，可通过 YAML 中的 autoRepair 和 healthCheckPolicyName 字段开启自愈功能：

spec:
  autoRepair: true
  healthCheckPolicyName: gpu-health-policy

对于 GPU 节点，TKE 还提供了完整的 GPU 故障检测与自愈方案，通过 NPD 实时检测 GPU 异常，结合 Node-Healing 自动执行隔离、排空、重启等操作。

六、网络增强：Pod 独立安全组（SGP）

原生节点支持 Pod 独立安全组能力（SecurityGroupPolicy，简称 SGP），实现 Pod 级别的网络安全策略控制。

6.1 SGP 的原理与优势

SGP 利用 VPC 侧的中继网卡（Trunking ENI）能力，为每个 Pod 单独分配中继出来的子网卡，子网卡单独绑定安全组。其核心优势包括：

Pod 级别安全隔离：每个 Pod 可绑定独立安全组，实现最小粒度的网络安全策略控制
减少攻击面：让 Pod 配置最小暴露面，增强安全性
传统架构迁移友好：从虚拟机架构迁移到容器架构时，可直接复用已有的安全组策略
不占用额外资源：基于中继网卡实现，不占用弹性网卡辅助 IP 资源和独立网卡资源

6.2 使用前提与限制

使用 SGP 需要满足以下条件：

集群需为 VPC-CNI 共享网卡 + 固定 IP 模式
需向 VPC 侧申请开启 client-token 白名单（否则有资源泄露风险）
节点上使用中继网卡的 Pod 数量受配额限制，默认为 100，最大 64C 机型支持 256
目前默认仅支持特定机型：ITA5、M8、MA4、MA5、S8、S9、SA4、SA5

使用前需在访问管理控制台创建自定义策略，授予 vpc:CreateSubNetworkInterface、vpc:DeleteSubNetworkInterface 等权限。

七、节点运维与监控

7.1 基础监控能力

原生节点支持子机相关指标监控，涵盖 CPU、内存、网络、磁盘、存储、LB、GPU 等维度。在 TKE Insight 的 Node Map 页面可直观查看各节点的资源使用情况。

7.2 异常告警与事件持久化

平台监控到异常情况会生成异常事件，记录在原生节点池运维记录和事件日志中。建议为集群配置事件持久化和事件告警，当平台监控到异常情况时可立即向用户推送受影响实例的故障或隐患通知。

7.3 节点操作接口

TKE 提供了原生节点实例的启动接口 StartMachines（接口请求域名：tke.tencentcloudapi.com），用于启动一个或多个原生节点实例。只有状态为 Stopped 的实例才可进行此操作，调用成功后等待约一分钟实例进入 Running 状态。

八、成本优化策略

8.1 计费模式选择

原生节点支持按量计费和包年包月两种模式：

包年包月：预付费，单价较低，最少使用一个月，适合节点资源需求量长期稳定的成熟业务
按量计费：后付费，按秒计费、按小时结算，随时购买随时释放，适合转码、大数据、电商抢购等周期性计算场景或开启 HPA 的潮汐型在线服务

8.2 通过原生节点特性降本

节点规格放大：通过虚拟放大可调度资源，用更少节点承载更多 Pod，直接降低节点数量
动态内存压缩：通过洁净内存压缩技术，某客户集群内存使用率从 80% 优化至 60%，且性能无明显变化
智能 Request 推荐：基于历史负载自动推荐合理的 Request 值，减少资源闲置
算力错峰：在线业务与离线任务分时复用资源，提升资源周转率

在某客户集群实践中，通过规格放大和调度优化，集群整体利用率提升至 65%，节点数下降 30%，核数下降 30%。

九、总结与最佳实践建议

腾讯云 TKE 原生节点通过自研内核增强、FinOps 理念融合和智能运维体系，为 Kubernetes 集群提供了远超普通节点的管理能力。在对接使用时，建议遵循以下最佳实践：

集群规划阶段：根据业务规模合理规划 VPC 子网、容器网络 CIDR 和节点池可用区分布
节点池创建：优先使用 YAML 声明式方式管理节点池，便于版本控制和自动化
调度策略：为生产环境开启原生节点专用调度器，根据业务特征合理设置放大系数和水位线
GPU 场景：安装 qGPU 组件实现 GPU 资源共享，通过算力错峰策略降低成本
高可用保障：部署 Node-Healing 组件实现节点故障自愈，配置事件告警及时感知异常
成本优化：长期稳定业务选择包年包月，潮汐业务选择按量计费，结合规格放大和智能推荐持续优化

常见问题解答

问：原生节点和普通节点的主要区别是什么？
答：原生节点包含普通节点的全部能力，并在管理模式、调度器、故障自愈、节点管理等方面做了全方位增强。原生节点支持基础设施声明式管理、Pod 原地升降配、内核参数调优、节点故障自愈，以及原生节点专用调度器的虚拟放大能力，而普通节点不具备这些特性。

问：节点放大系数设置多少合适？
答：CPU 放大系数支持 1 到 3 之间，内存放大系数支持 1 到 2 之间。建议从较小的放大系数（如 CPU 1.5、内存 1.2）开始，观察节点实际负载情况后逐步调整。放大系数过高可能导致节点实际资源超卖，触发 Pod 驱逐。

问：qGPU 支持哪些 GPU 型号？
答：qGPU 支持 V100（Gn10x）、T4（Gn7）、A100（GT4）、A10（Pnv4）、L40（Pnv5i）、L40s（Pnv5）、Pnv5b、Pnv6 等架构。驱动支持 450/470/515/525/535/550/570 系列，CUDA 支持 11.4/12.2/12.4/12.8。

问：Node-Healing 能自动修复哪些故障？
答：Node-Healing 支持 40 种故障类型的自愈策略，涵盖内核/系统类故障、资源压力类故障、服务健康类故障、K8s 组件扩展类故障及 GPU 监控类故障。与 NPD 配合使用可实现从故障检测到自动修复的完整闭环。

问：Pod 独立安全组（SGP）的使用有什么限制？
答：使用 SGP 要求集群为 VPC-CNI 共享网卡 + 固定 IP 模式，需向 VPC 侧申请 client-token 白名单。目前默认仅支持特定机型（ITA5、M8、MA4、MA5、S8、S9、SA4、SA5），节点中继网卡 Pod 数量默认为 100。

问：原生节点的计费模式如何选择？
答：包年包月为预付费，单价较低，最少使用一个月，适合长期稳定的业务。按量计费为后付费，按秒计费、按小时结算，适合潮汐型或测试场景。实际生产中可采用混合策略——核心业务用包年包月保障成本，弹性部分用按量计费应对突发流量。