CCE集群选型建议
当您使用云容器引擎CCE创建Kubernetes集群时，常常会面对多种配置选项以及不同的名词，难以进行选择。本文将从不同的关键配置进行对比并给出选型建议，帮助您创建一个满足业务需求的集群。
集群类型
云容器引擎支持CCE Turbo集群与普通CCE集群两种类型，以满足您各种业务需求，如下为CCE Turbo集群与CCE集群区别：
|
维度 |
子维度 |
CCE Turbo集群 |
CCE Standard集群 |
|---|---|---|---|
|
集群 |
定位 |
面向云原生2.0的新一代容器集群产品，计算、网络、调度全面加速 |
标准版本集群，提供商用级的容器集群服务 |
|
节点形态 |
支持虚拟机和裸金属服务器混合 |
支持虚拟机和裸金属服务器混合 |
|
|
网络 |
网络模型 |
云原生网络2.0：面向大规模和高性能的场景。 组网规模最大支持2000节点 |
云原生网络1.0：面向性能和规模要求不高的场景。
|
|
网络性能 |
VPC网络和容器网络融合，性能无损耗 |
VPC网络叠加容器网络，性能有一定损耗 |
|
|
容器网络隔离 |
Pod可直接关联安全组，基于安全组的隔离策略，支持集群内外部统一的安全隔离。 |
|
|
|
安全 |
隔离性 |
|
普通容器，Cgroups隔离 |
集群版本
由于Kubernetes社区版本迭代较快，新版本中通常包含许多Bug修复和新功能，而旧版本会根据时间推移逐渐淘汰。建议您在创建集群时，选择当前CCE支持的最新商用版本。
集群网络模型
云容器引擎支持以下几种网络模型，您可根据实际业务需求进行选择。
集群创建成功后，网络模型不可更改，请谨慎选择。
|
对比维度 |
容器隧道网络 |
VPC网络 |
云原生网络2.0 |
|---|---|---|---|
|
适用场景 |
|
|
|
|
核心技术 |
OVS |
IPVlan，VPC路由 |
VPC弹性网卡/弹性辅助网卡 |
|
适用集群 |
CCE Standard集群 |
CCE Standard集群 |
CCE Turbo集群 |
|
容器网络隔离 |
Pod支持Kubernetes原生NetworkPolicy |
否 |
Pod支持使用安全组隔离 |
|
ELB对接Pod |
ELB对接Pod需要通过节点NodePort转发 |
ELB对接Pod需要通过节点NodePort转发 |
使用独享型ELB时可直接对接Pod 使用共享型ELB对接Pod需要通过节点NodePort转发 |
|
容器IP地址管理 |
|
|
容器网段从VPC子网划分，无需设置单独的容器网段 |
|
网络性能 |
基于VxLAN隧道封装，有一定性能损耗。 |
无隧道封装，跨节点通过VPC路由器转发，性能较好，可媲美主机网络，但存在NAT转换损耗。 |
容器网络与VPC网络融合，性能无损耗。 |
|
组网规模 |
最大可支持2000节点 |
受限于VPC路由表能力，适合中小规模组网，建议规模为1000节点及以下。 VPC网络模式下，集群每添加一个节点，会在VPC的路由表中添加一条路由（包括默认路由表和自定义路由表），因此集群本身规模受VPC路由表上限限制，创建前请提前评估集群规模。路由表配额请参见使用限制。 |
最大可支持2000节点 由于云原生网络2.0集群中的容器从VPC网段内分配IP地址，消耗VPC的地址空间，实际支持规模受限于VPC子网网段大小，因此创建前请提前评估集群规模。 |
如需了解更多信息，请参见容器网络模型对比。
集群网段
集群中网络地址可分为节点网络、容器网络、服务网络三块，在规划网络地址时需要从如下方面考虑：
- 三个网段不能重叠，否则会导致冲突。且集群所在VPC下所有子网（包括扩展网段子网）不能和容器网段、服务网段冲突。
- 保证每个网段有足够的IP地址可用。
- 节点网段的IP地址要与集群规模相匹配，否则会因为IP地址不足导致无法创建节点。
- 容器网段的IP地址要与业务规模相匹配，否则会因为IP地址不足导致无法创建Pod。
如业务需求复杂，如多个集群使用同一VPC、集群跨VPC互联等场景，需要同步规划VPC的数量、子网的数量、容器网段划分和服务网段连通方式，详情请参见集群网络地址段规划实践。
服务转发模式
kube-proxy是Kubernetes集群的关键组件，负责Service和其后端容器Pod之间进行负载均衡转发。
CCE当前支持iptables和IPVS两种转发模式，各有优缺点。
- IPVS：吞吐更高，速度更快的转发模式。适用于集群规模较大或Service数量较多的场景。
- iptables：社区传统的kube-proxy模式。适用于Service数量较少或客户端会出现大量并发短链接的场景。
对稳定性要求极高且Service数量小于2000时，建议选择iptables，其余场景建议首选IPVS。
如需了解更多信息，请参见iptables与IPVS如何选择。
节点规格
- 小规格节点的网络资源的上限较小，可能存在单点瓶颈。
- 当容器申请的资源较大时，一个小规格节点上无法运行多个容器，节点剩余资源就无法利用，存在资源浪费的情况。
- 网络带宽上限较大，对于大带宽类的应用，资源利用率高。
- 多个容器可以运行在同一节点，容器间通信延迟低，减少网络传输。
- 拉取镜像的效率更高。因为镜像只需要拉取一次就可以被节点上的多个容器使用。而对于小规格的ECS拉取镜像的次数就会增多，在节点弹性伸缩时则需要花费更多的时间，反而达不到立即响应的目的。
另外，还需要根据业务需求选择合适的CPU/内存配比。例如，使用内存较大但CPU较少的容器业务，建议选择CPU/内存配比为1:4的节点，减少资源浪费。
节点容器引擎
CCE当前支持用户选择Containerd和Docker容器引擎，其中Containerd调用链更短，组件更少，更稳定，占用节点资源更少。并且Kubernetes在v1.24版本中移除了Dockershim，并从此不再默认支持Docker容器引擎，详情请参见Kubernetes即将移除Dockershim，CCE v1.27版本中也将不再支持Docker容器引擎。
因此，在一般场景使用时建议选择Containerd容器引擎。但在以下场景中，仅支持使用Docker容器引擎：
- Docker in Docker（通常在CI场景）。
- 节点上使用Docker命令。
- 调用Docker API。
节点操作系统
由于业务容器运行时共享节点的内核及底层调用，为保证兼容性，建议节点的操作系统选择与最终业务容器镜像相同或接近的Linux发行版本。
