用户指南

文档中心 > 容器服务 > 最佳实践 > 组建集群选型推荐

组建集群选型推荐

最近更新时间:2020-06-01 10:17:32

当您使用腾讯云容器服务 TKE 组建 Kubernetes 集群时,会面对多种配置选项,难以进行选择。本文介绍以下功能选型,进行对比并给出选型建议。您可参考本文,选择更适用于您业务的配置选型。

Kubernetes 版本

Kubernetes 版本迭代较快,新版本通常包含许多 bug 修复和新功能,而旧版本会逐渐淘汰。建议您在创建集群时,选择当前 TKE 支持的最新版本。后续可通过升级已有 Master 和节点版本,更换迭代产生的新版本。

容器网络插件:GlobalRouter 及 VPC-CNI

网络模式架构

TKE 支持以下两种网络模式架构,如需了解更多信息,请参见 如何选择容器服务网络模式

  • GlobalRouter 模式架构

    • 基于 CNI 和网桥实现的容器网络能力,容器路由直接通过私有网络 VPC 底层实现。
    • 容器与节点在同一网络平面,但网段不与私有网络网段重叠,容器网段地址充裕。
  • VPC-CNI 模式架构

    • 基于 CNI 和 VPC 弹性网卡实现的容器网络能力,容器路由通过弹性网卡,性能相比 Global Router 约提高10%。
    • 容器与节点在同一网络平面,网段在 VPC 网段内。
    • 支持 Pod 固定 IP。

使用方式

TKE 支持以下三种网络模式使用方式:

  • 创建集群时指定 GlobalRouter 模式。
  • 创建集群时指定 VPC-CNI 模式,则后续所有 Pod 都必须使用 VPC-CNI 模式创建。
  • 创建集群时指定 GlobalRouter 模式,在需要使用 VPC-CNI 模式时为集群启用 VPC-CNI 的支持,即两种模式混用。

选型建议

  • 通常情况下应该选择 GlobalRouter,容器网段地址充裕、扩展性强且能适应规模较大的业务。
  • 若后期部分业务需使用 VPC-CNI 模式,可在 GlobalRouter 集群中再开启 VPC-CNI 支持,即 GlobalRouter 与 VPC-CNI 混用,仅部分业务使用 VPC-CNI 模式。
  • 若完全了解并接受 VPC-CNI 的使用限制,且集群内所有 Pod 都需用 VPC-CNI 模式,则可在创建集群时选择 VPC-CNI 模式。

运行时组件: Docker 及 Containerd(beta)

运行时架构

TKE 支持以下两种运行时架构,如需了解更多信息,请参见 如何选择 Containerd 和 Docker

  • Docker 作为运行时架构

    • 调用链如下:
      1. Kubelet 内置的 dockershim 模块帮助 docker 适配了 CRI 接口。
      2. Kubelet 通过 socket 文件自行调用 dockershim.
      3. Dockershim 调用 dockerd 接口(Docker HTTP API)。
      4. Dockerd 调用 docker-containerd(gRPC)来实现容器的创建与销毁等。
    • 调用链过长原因分析:
      Kubernetes 起初仅支持 Docker,后来引入了 CRI,并将运行时抽象化以支持多种运行时。Docker 与 Kubernetes 存在竞争关系,未在 dockerd 中实现 CRI 接口,故 Kubernetes 需自行在 dockerd 中实现 CRI。Docker 本身内部组件模块化及 CRI 适配。
  • Containerd(beta) 作为运行时架构

    • Containerd 1.1 之后支持了 CRI Plugin,即 containerd 自身即可适配 CRI 接口。
    • 相比 Docker 方案,调用链少了 dockershim 和 dockerd。

运行时对比

  • Containerd 方案由于绕过了 dockerd,具备调用链更短、组件更少、占用节点资源更少、绕过 dockerd 本身的一些 bug 等优点,但 containerd 自身也还存在一些 bug,目前 containerd 在 beta 阶段,已修复部分 bug。
  • Docker 方案历史较悠久、相对更成熟、支持 Docker API 且功能丰富,符合大多数人的使用习惯。

选型建议

  • Docker 方案相比 containerd 更成熟,如果对稳定性要求较高,建议选择此方案。
  • 以下场景仅支持使用 docker:
    • Docker in docker(通常在 CI 场景)。
    • 节点上使用 docker 命令。
    • 调用 docker API。

若非以上场景,建议选择 containerd。

Service 转发模式:iptables 及 ipvs

Service 转发原理图如下所示:

  1. 节点上的 kube-proxy 组件 watch apiserver,获取 Service 与 Endpoint,根据转发模式将其转化成 iptables 或 ipvs 规则并写到节点上。
  2. 集群内的 client 访问 Service(Cluster IP),会被 iptable 或 ipvs 规则负载均衡到 Service 对应的后端 pod。

转发模式对比

  • ipvs 模式性能更高,但存在一些已知未解决的 bug。
  • iptables 模式更成熟稳定。

选型建议

对稳定性要求极高且 Service 数量小于2000时,建议选择 iptables,其余场景建议首选 ipvs。

集群类型:托管集群及独立集群

TKE 支持以下两种集群类型:

  • 托管集群

    • Master 组件用户不可见,由腾讯云托管。
    • 会率先支持大部分新功能的托管。
    • Master 的计算资源会根据集群规模自动扩容
    • 用户不需要为 Master 付费。
  • 独立集群

    • 用户可完全掌控 Master 组件。
    • 用户需要为 Master 付费购买机器。

选型建议

建议通常情况下选择托管集群,如需完全掌握 Master,例如对 Master 进行个性化定制实现高级功能,则可选择使用独立集群。

节点操作系统

TKE 支持 Ubuntu 和 CentOS 两类发行版操作系统,TKE-Optimized 版本的操作系统使用了 TKE 定制优化版的内核,其余的操作系统使用了 Linux 社区官方开源内核。如下图所示:

TKE-Optimized 优势

  • 基于内核社区长期支持的 4.14.105 版本定制。
  • 针对容器和云场景进行了优化。
  • 计算、存储和网络子系统均经过性能优化。
  • 对内核缺陷修复支持较好。
  • 完全开源,详情请参见 TencentOS-kernel

选型建议

建议选择 TKE-Optimized 版本的操作系统,稳定性和技术支持较好。如需更高版本内核的操作系统,则可选非 TKE-Optimized 版本的操作系统。

使用节点池

节点池目前为内测发布功能,使用需通过申请。主要用于批量管理节点:

  • 节点 Label 与 Taint。
  • 节点组件启动参数。
  • 节点自定义启动脚本。
    详情请参见 节点池概述

适用场景

  • 异构节点分组管理,减少管理成本。
  • 使集群更好的支持复杂的调度规则(Label 及 Taint)。
  • 频繁扩缩容节点,减少操作成本。
  • 节点日常维护,例如版本升级等。

用法举例

部分 IO 密集型业务需要高 IO 机型,为该业务创建节点池、配置机型并统一设置节点 Label 与 Taint,并配置 IO 密集型业务亲和性。选中 Label,使其调度到高 IO 机型的节点(Taint 可以避免其它业务 Pod 调度上来)。

当业务量快速上升时,该 IO 密集型业务也需要更多的计算资源。在业务高峰时段,HPA 功能自动为该业务扩容了 Pod,而节点计算资源不够用,此时节点池的自动伸缩功能自动扩容了节点,守住了流量高峰。

使用启动脚本

组件自定义参数

说明:

如需使用该功能,请通过 提交工单 进行申请。

  • 在创建集群时,可在配置“集群信息”的“高级设置”中,自定义 Master 组件部分启动参数。如下图所示:
  • 在“选择机型”时,可在 “Worker 配置”的“高级设置”中,自定义 kubelet 部分启动参数。如下图所示:

节点启动配置

  • 在创建集群时,可在“云服务器配置”的“高级设置”中,自定义数据配置节点启动脚本(可用于修改组件启动参数、内核参数等)。如下图所示:
  • 在添加节点时,可“云服务器配置”的“高级设置”中,自定义数据配置节点启动脚本(可用于修改组件启动参数、内核参数等)。如下图所示:
目录