摘要：完全兼容原生的，以私有网络为基础，并整合了等云产品。综合资源有效利用率错误容忍度两个因素，在不考虑业务混合部署业务总体规模大小的情况下，我们建议生产环境的节点应该介于核至核之间。模式是一个用于负载均衡的内核功能。

产品概念

UCloud Container Service for Kubernetes （UK8S）是一项基于Kubernetes的容器管理服务，你可以在UK8S上部署、管理、扩展你的容器化应用，而无需关心Kubernetes集群自身的搭建及维护等运维类工作。

UK8S完全兼容原生的Kubernetes API，以UCloud私有网络为基础，并整合了ULB、UDisk、EIP、VPC等云产品。

使用须知

集群

1. 使用UK8S服务，必须通过UCloud实名认证服务；
2. 集群中master节点为管理节点，不建议服务调度到管理集群运行；
3. 单个UK8S集群最多添加5000个Node节点，生产集群建议不超过1000个；
4. 支持的Kubernetes版本会落后社区2个版本，具体以产品页面为准；
5. 如果的云账户开启了API白名单则需要在白名单中配置10.10.10.10/32网段，详见API白名单配置

节点

1. Node节点使用的云主机镜像默认为 Centos7.6，如果重装系统或擅自修改系统配置，可能导致集群不可用；
2. Node节点使用的云主机系统盘默认为SSD，支持添加数据盘，添加数据盘后，容器启动后默认运行在数据盘；
3. 云主机默认使用N机型，您也可以选择其他机型（如O型、C型)；
4. 节点标签UhostID=xxx为主机管理使用标签，请勿删除修改，以免导致集群数据不正常；

存储卷

1. 当前支持SATA、SSD UDisk以及UFS；

   在UK8S中使用UDisk

   在UK8S中使用UFS

   在UK8S中使用UFile

2. 当前支持共享存储的地域：

其他

当你创建UK8S集群后，UK8S会以你的名义在当前项目下创建UHost、ULB、UDisk、EIP等资源，更改配置或删除可能导致集群不可用，请谨慎操作。主要如下：

1、由UK8S管理服务创建的资源，其命名规范如下：

1.1、 uk8s-trd3u-master-3或uk8s-trd3u-m-xsdaf为UHost名称，作为集群的Master节点；

1.2、 uk8s-trd3u-node-3或uk8s-trd3u-n-xsa2f为UHost名称，作为集群的Node节点；

1.3、 uk8s-trd3u-master-ulb为ULB名称，作为ApiServer的内网入口；

1.4、 uk8s-trd3u-master-ulb-external为ULB名称，作为ApiServer的外网入口；

1.5、 数据盘_uk8s-sr0xsohz-node-6或数据盘_uk8s-sr0xsohz-n-xsa2f为UDisk名称，作为集群的Node节点数据盘；

1.6、 系统盘_uk8s-sr0xsohz-node-6或系统盘_uk8s-sr0xsohz-n-xsa2f为UDisk名称，作为集群的Node节点系统盘；

2、由UK8S插件创建的资源，其命名规范如下：

2.1、 ULB名称为ingress-nginx.ingress.svc.uk8s-xy7udsa的，由UK8S的ULB插件创建，用于LoadBalancer类型的Service，且其备注为UID-xx-xxx，实为Service在UK8S中的uuid。其命名规范为svc-name.namespace.svc.uk8s-id。

2.2、 Vserver名称为TCP_443_xxx-xxxxx的，由UK8S的ULB插件创建，对应LoadBalancer类型的Service中不同的端口。其命名规范为service-protocol_service-port_service_uuid。

2.3、 UDisk名称为pvc-9393f66f-c0b5-11e9-bd6d-5254001935f2的，由UK8S的存储插件创建，对应UK8S中的PVC。其命名规范为pvc-pvc_uuid。

名词解释

为了帮助你更好地使用UK8S，你需要对Kubernetes的相关组件有一个大致的了解，本文会对基础组件及概念做一个简要的介绍，如果你希望了解更多内容，请移步Kubernetes官方文档

Kubernetes基础架构

上图是一个概要性的Kubernetes架构，包含了ApiServer，Master、Node、Hub（镜像仓库）等概念，下面我们依次做个简要介绍。

ApiServer： ApiServer是操作集群的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制，ApiServer作为一个组件运行在Master上。

Node：Node是Kubernetes的工作节点，其上包含运行Pod所需要的服务。Node可以是虚拟机也可以是物理机，在UK8S，目前只支持虚拟机即UHost。

Master： Master也是Kubernetes的工作节点，与Node不同的是，Master通常不运行业务Pod，而是安装了用于控制和管理集群的如ApiServer、Scheduler、Controller Manager、Cloud Controller Manager、ETCD等组件。

Hub镜像仓库 Hub提供Docker镜像的管理、存储、分发能力。

漏洞修复记录

• HTTP/2漏洞升级说明
• Runc容器逃逸漏洞修复说明
• cloudprovider更新20.10.1

集群节点配置推荐

1、Master配置推荐

Master规格跟集群规模有关，集群规模越大，所需要的Master规格也越高，不同集群规模的，Master节点配置推荐如下：

2、如何选择Node配置大小

关于Node节点的资源预留策略

在确定UK8S的Node节点配置之前，您需要知道，UK8S Node默认预留1G内存，0.2核CPU以保障系统稳定运行。这些预留的资源是给系统及kubernetes相关服务进程使用的。

且当可用内存小于5%时会根据pod资源优先级开始驱逐，pod实际可使用的内存约为{memeroy of Node}-1G-5% (例如：4G内存，可用约为2.8G)，同时，单个节点可创建Pod和Node CPU核数有关。pods数量=CPU核数 x 8 (例如：2核=16 pods， 4核=32 pods)。

因此，我们建议Node的配置>=2C4G，这是保证集群正常运行的基础配置。

至于生产环境的Node配置选项，可根据整个集群的日常使用的总核数以及故障容忍度、业务类型综合考量，具体如下：

假设集群总核数设定为240核（基于过往运营数据而定），可以容忍10%的错误。那么可以选择10台24核UHost，并且高峰运行的负荷不要超过240*90%=216核。如果容忍度小于5%，那么可以选择15台16核的UHost，这样就算有一台节点出现故障，剩余节点仍可以支持现有业务正常运行（工作负载自动迁移）。

从提供错误容忍度的角度看，节点配置越低，节点会更多，那可用性也会相应地提高。但也存在另外两个弊端，一是需要预留给K8S的资源过多，造成浪费；二是不便于容器调度，甚至会导致部分容器无法被注册。一个极端的例子，3台8核的节点，可创建6个需要预留4核的Pod，但12台2C的节点，却无法响应一个需要预留4核资源的Pod请求。

综合资源有效利用率、错误容忍度两个因素，在不考虑业务混合部署、业务总体规模大小的情况下，我们建议生产环境的Node节点CPU应该介于4核至32核之间。

至于CPU：Memory比例，建议根据自身的应用类型申请合适的机型，例如CPU密集型的业务可以申请1：2的机型，Java类的应用可以申请1:4或1:8的机型，如果是不同业务混合部署，最好给Node打好标签，配合nodeAffinity合理调度Pod。

最后是系统盘，UK8S的Node节点默认40G系统盘，节点创建时可选择数据盘挂载，这个盘是专门提供给docker存放本地镜像的。节点创建完成后依然可以在主机侧挂载数据盘（请保证磁盘空间充足，当磁盘空间不足时，将会随机删除docker镜像与pod）。

kube-proxy模式选择

kube-proxy是kubernetes中的关键组件其主要功能是在Service和其后端Pod之间（Endpoint）进行负载均衡。kube-proxy 有三种运行模式，每种都有不同的实现技术：userspace、iptables或者IPVS。

userspace模式由于性能问题已经不推荐使用。这里主要介绍iptables和IPVS两种模式的比较及选择。

如何选择

• 对于集群规模较大，特别是Service数量可能超过1000的，推荐选择IPVS。（详见后续测试数据）
• 对于集群规模中等，Service数量不多的，推荐选择iptables。
• 如果客户端会出现大量并发短链接，目前建议选择iptables，原因见下方备注。

备注：在使用IPVS模式的kubernetes集群中进行滚动更新，期间如果有一个客户端在短时间内（两分钟）内发送大量短链接，客户端端口会被复用，导致node收到的来自于该客户端的请求报文网络五元组相同，触发IPVS复用Connection，有可能导致报文被转发到了一个已经销毁的Pod上，导致业务异常。

官方issue：https://github.com/kubernetes/kubernetes/issues/81775

如何切换

请参考kube-proxy模式切换

iptables模式

iptables是一个Linux内核功能，是一个高效的防火墙，并提供了数据包处理和过滤方面的能力。它可以在核心数据包处理管线上用Hook挂接一系列的规则。iptables模式中kube-proxy在NAT pre-routing Hook中实现它的NAT和负载均衡功能。这种方法简单有效，依赖于成熟的内核功能，并且能够和其它跟 iptables 协作的应用融洽相处。

IPVS模式

IPVS是一个用于负载均衡的Linux内核功能。IPVS模式下，kube-proxy使用IPVS负载均衡代替了iptables。IPVS的设计思路就是用来为大量服务进行负载均衡的，它有一套优化过的API，使用优化的查找算法，而不是从列表中查找规则，在大规模场景下相对IPVS性能更好。

模式对比

无论是iptables模式还是IPVS模式，转发性能都与Service及对应的Endpoint数量有关，原因是Node上iptables或IPVS转发规则的数量与svc和ep的数目成正比。

IPVS和iptables转发性能主要差异体现在TCP三次握手连接建立的过程，因此在大量短连接请求的场景下，两种模式的性能差异尤为突出。

在Service和Endpoint的数量较少的情况下(Service数十到数百，Endpoint数百到数千)，iptables模式转发性能要略优于IPVS。

随着Service和Endpoint的数量逐渐提升，iptables模式转发性能明显下降，IPVS模式转发性能则相对稳定。

Service数量1000左右，Endpoint数量到20000左右时，iptables模式转发性能开始低于IPVS，随着Service和Endpoint的数量继续增大（Service数千，Endpoint数万），IPVS模式性能略微下降，iptables模式性能则大幅下降。

测试用例

我们使用了2台Node作为测试节点，一台节点KubeProxy使用iptables模式，记为N1；另一台KubeProxy使用IPVS模式，记为N2。

在N1和N2上准备好压测客户端ab，并发连接数1000，一共需要完成10000次短连接请求。

在N1和N2上分别但不同时执行测试命令，观察ab返回的结果：

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1   38   8.4     38      59
Processing:    10   41   9.7     40      67
Waiting:        1   28   9.0     28      56
Total:         51   79   7.5     78     101

不断变化Service数量100，500，1000，2000，3000，4000，观察结果采集数据。

以下为UK8S团队针对IPVS和iptables进行的性能测试数据。

可以看出，在Service数量为100和500时，iptables转发性能要优于IPVS；Service数量达到1000时，两者大体持平；Service数量继续增大，IPVS的性能优势则越发明显。