摘要：模式选择是中的关键组件其主要功能是在和其后端之间进行负载均衡。详见后续测试数据对于集群规模中等，数量不多的，推荐选择。模式下，使用负载均衡代替了。
Master规格跟集群规模有关，集群规模越大，所需要的Master规格也越高，不同集群规模的，Master节点配置推荐如下：
| 节点规模 | Master规格 |
|---|---|
| 1-10个节点 | >=2核4G |
| 10-100个节点 | >=4核8G |
| 100-250个节点 | >=8核16G |
| 250-500个节点 | >=16核32G |
| 500-1000个节点 | >=32核64G |
| 1000个以上节点 | 联系我们 |
关于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是kubernetes中的关键组件其主要功能是在Service和其后端Pod之间（Endpoint）进行负载均衡。kube-proxy 有三种运行模式，每种都有不同的实现技术：userspace、iptables或者IPVS。
userspace模式由于性能问题已经不推荐使用。这里主要介绍iptables和IPVS两种模式的比较及选择。
备注：在使用IPVS模式的kubernetes集群中进行滚动更新，期间如果有一个客户端在短时间内（两分钟）内发送大量短链接，客户端端口会被复用，导致node收到的来自于该客户端的请求报文网络五元组相同，触发IPVS复用Connection，有可能导致报文被转发到了一个已经销毁的Pod上，导致业务异常。
官方issue：https://github.com/kubernetes/kubernetes/issues/81775
iptables是一个Linux内核功能，是一个高效的防火墙，并提供了数据包处理和过滤方面的能力。它可以在核心数据包处理管线上用Hook挂接一系列的规则。iptables模式中kube-proxy在NAT pre-routing Hook中实现它的NAT和负载均衡功能。这种方法简单有效，依赖于成熟的内核功能，并且能够和其它跟 iptables 协作的应用融洽相处。
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的性能优势则越发明显。
实时文档欢迎访问https://docs.ucloud.cn/uk8s/introduction/vulnerability/cve2019-9512-9514
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/126121.html
摘要：完全兼容原生的，以私有网络为基础，并整合了等云产品。综合资源有效利用率错误容忍度两个因素，在不考虑业务混合部署业务总体规模大小的情况下，我们建议生产环境的节点应该介于核至核之间。模式是一个用于负载均衡的内核功能。产品概念UCloud Container Service for Kubernetes （UK8S）是一项基于Kubernetes的容器管理服务，你可以在UK8S上部署、管理、扩展你...
摘要：详细请见产品价格产品概念使用须知名词解释漏洞修复记录集群节点配置推荐模式选择产品价格操作指南集群创建需要注意的几点分别是使用必读讲解使用需要赋予的权限模式切换的切换等。UK8S概览UK8S是一项基于Kubernetes的容器管理服务，你可以在UK8S上部署、管理、扩展你的容器化应用，而无需关心Kubernetes集群自身的搭建及维护等运维类工作。了解使用UK8S为了让您更快上手使用，享受UK...
摘要：创建集群如果你是初次接触，我们建议你预先创建好一个新的和子网，与生产环境隔离。节点的可用区选择会根据的可用区选择变化，现已支持针对节点的平台硬件隔离组最大数标签等设置。创建集群如果你是初次接触Kubernetes，我们建议你预先创建好一个新的VPC和子网，与生产环境隔离。创建集群之前，你需要先了解下Kubernetes中的Node CIDR、Pod CIDR、Service CIDR等基本概...
摘要：已如下集群为例，集群模式默认是。我们在此修改为模式。切换集群节点的模式我们采用新增新节点，新节点后删除一个老节点的循环操作进行集群全部节点的模式切换。节点不在调度范围内，不用进行切换。kube-proxy模式切换在UK8S集群创建时我们会对集群创建生成默认的kube-proxy模式，在集群中新增的Node节点都会依赖这个集群默认kube-proxy模式进行新增，您可以参考以下操作进行集群ku...
阅读 3162·2023-04-25 20:09
阅读 3357·2022-06-28 19:00
阅读 2711·2022-06-28 19:00
阅读 2714·2022-06-28 19:00
阅读 2657·2022-06-28 19:00
阅读 2515·2022-06-28 19:00
阅读 2628·2022-06-28 19:00
阅读 2322·2022-06-28 19:00
