要做好容器云平台性能架构设计，先了解这10个知识

Posted 2021-04-10 twt企业IT社区

Kubernetes起初作为用于容器调度的平台，其虽然实现了从容器到应用、从网络到存储的诸 多基础架构抽象，但其本身还是运行于传统OS的诸多应用进程，仍然需要通过必要的设计，来加强自身可靠性。以下是社区组织的“云架构师容器云平台的性能架构设计在线辅导答疑”中，大家提出的一些典型问题和专家解答，供参考。

相关课程可点击此处了解>>>

1、容器平台性能优化包含哪几方面？

@edwin1986 上汽通用汽车 系统架构师： 

通过 Kubernetes 架构，我们可以注意到一个完整的集群主要包含 Master （包括 ETCD 集群）、应用 Node 、 Infra Node 等若干部分。具体职责上 Master 主要提供 API Server 进行集群容器调度、应用 Node 负责应用容器本身运行、 Infra Node 负责监控、日志、 Ingress 等基础设施容器运行。他们之间通过 CNI 接口实现的虚拟网络实现网络按需互联。因此，性能优化主要包含：

1、针对不同特点主机的 OS 优化。

比如针对 Master 本身 OS 优化、是否和与 ETCD 分离运行、相关 OS 参数设置等等。

不同 Infra 节点的 OS 优化。如 ES 对 OS 文件句柄具有一定要求、 ES 及 P8S 等对存储的优化、 Ingress 节点对网络的优化等等。

Kubernetes 应用层优化。如 CPU 是否密集型调度处理、 QoS 处理等等。

2、针对不同主机的 OS 常规监控。

这点很多 SA 都非常熟悉， 包括 CPU 、内存、 IO 、磁盘、网卡等等。

3、针对不同基础服务的应用层监控。

针对不同基础服务需要制定不同监控方案。比如 Prometheus 监控及高可用性（包括其本身是否需要交叉监控等等）

4、针对不同节点的容量评估和容量管理。

包括对集群的整体容量规划、集群内不同 Infra 服务的容量规划等等。

2、Kubernetes集群多纬度如何优化？

Kubernetes集群优化，一般是从集群负载工作所涉及的最核心的三个纬度进行，分别是：网络优化(CNI插件、入口方案)、存储优化(块存储、文件存储、对象存储)、节点优化(master节点、worker节点)。针对以上几个纬度的优化如何展开，并可量化优化后的效果？

@edwin1986 上汽通用汽车 系统架构师： 

CNI由于和物理网络环境有关需要按需进行选型和验证、一般性能差异会在10%左右。

CSI优化和数据中心具体存储实现也有关系，一般需要存储支持CSI接口。但后者只是存储attach、mount等步骤的标准实现接口，其性能不应和非容器环境有较大差异。

节点优化具体可参考本章节教材。

验证上，CNI和CSI的优化可以直接通过常见workload工具进行压力测试验证。

3、Kubernetes集群针对不同应用的性能优化和配置调整包含哪些？

@edwin1986 上汽通用汽车 系统架构师： 

首先需要进行集群容量规划，对未来投入的计算资源规模和应用类型特点做显性评估。针对应用特点主要在如下几部分做评估：

CPU：

如果应用属于 CPU 密集型，需要通过 CPU Manager 进行静态配置。当然部分密集型场景需要考虑是不是可以使用 GPU 更高效完成需求。这部分 Kuberneteske 可以通过 Device Manager 扩展下层计算资源类型。

另一方面，需要平衡节点资源利用率和 Pod QoS 等级。这部分需要注意部分类型的应用（如 Java ）对于 request CPU 和内存是有一定要求的，过小的值会导致应用启动缓慢。

存储：

针对不同应用存储需求需要设置不同的存储方案。虽然 Kubernetes 本身倡导的是无状态应用，但针对有状态应用的持久化需要平衡运维管理成本和架构耦合性。比如针对轻量型的配置持久化，可以考虑外挂网络存储或通过 Kubernetes Configmap 等对象进行支持。这样满足应用需求同时也能保证架构的低耦合。但对于重量存储需求需要使用 SAN 的，应避免 SAN 与工作节点 Docker 本身文件系统复用，可能的 IO 瓶颈导致节点影响。当然如果技术支持的话可以通过 CSI 接口进而实现主机 SAN-PVC-PV 的调度和使用。

网络和隔离性：

针对应用网络 IO 应做好不同节点间网络监控以及 Ingress 等复用节点的监控。必要时可以通过节点亲和性规划不同 Ingress 节点用来进行不同应用的外部访问。

隔离性上， Kubernetes 倡导的 NetworkPolicy 是一个非常好的隔离模型。一般在集群规划阶段就应定义默认 Namespaces 的 Network Policy 规则，从而实现“半”多租户隔离，降低后续的管理成本。

4、kubernetes计算节点性能调优包含哪些部分？

@edwin1986 上汽通用汽车 系统架构师： 

首先要进行整体集群容量评估，考虑到 ETCD 本身的性能，需要对 Node 数量、 Pod 数量 Namespace 数量、每个 Namespace 中对象数量、 Service 数量等容量进行规划。同时需要留意的是集群节点数量和 Master CPU 性能是呈线性增长的，需要合理配置 Master 节点计算资源。

其次，针对 CPU Manager 的调度策略，需要针对不同应用特点进行规划和定义。比如 CPU 密集型的应用和常规应用的调度策略就有所不同，一般通过设置节点亲和性进行区别对待。

再则，对于节点使用的不同类型存储，针对每个存储的特点和使用场景需要进行不同的设计。比如 Prometheus 应避免使用文件存储来实现持久化。

在性能调优方面，除去本身 OS 的一些参数调优，也需要注意所运行应用的特性和要求。如果 ES 需要作为应用容器运行，则需要进行部分 ES 对应 OS 参数调优。

在监控方面，传统 OS 的监控和容器应用的监控应同时支持。OS 监控包括 CPU 、内存、 IO 、磁盘、网卡等等。但需要注意的是，由于应用节点通常无状态，应用进行随机调度，需要规避节点调度的雪崩效应，即假设一个节点 Down ，其上面容器被调度到其他节点，进而导致这些节点因为 IO 异常而雪崩，最终影响整个集群。这点上可以通过适当的监控和调度处理规避。应用层监控除去传统的外部监控方案也可以使用 Prometheus 进行，目前其已经实现越来越多的外部 exporter 或 sdk 支持集成越来越多中间件。但需要注意其本身监控失效，这点可以通过交叉监控规避。

5、kubernetes整体容量规划的实际场景案例？比如计算密集型的，比如内存密集型的？或者业务场景的？

@edwin1986 上汽通用汽车 系统架构师： 

可以根据几个维度看待：

1.对于底层资源的绑定和依赖情况：如计算密集与否、gpu、大IO等等

2.应用有状态无状态。是否涉及持久化，如san实现的local storage pv

3.应用行为：针对不同应用特点进行隔离，注意东西流量

6、应用进行容器化改造后性能有多少损失，该如何进行评价？

@俞黎敏 IBM广州  软件开发工程师：

如果对网络IO要求不是很高的话，还好。

当然现在有多网络的方案可以进行选择，根据需要进行安装配置并测试之。

@sknife 开云空间 软件架构设计师：

会有一部分损失，但是相比较而言，可以获得更好的运维管理服务，自动伸缩，cicd或者devops，灰度发布，蓝绿部署......

@mtming333 甜橙金融翼支付 系统运维工程师：

如果用隧道网络方案会有一点性能损失，但这些可以靠扩容堆回来，毕竟硬件便宜，总体还是获益更多。

7、Kubernetes组件优化？

Kubernetes平台稳定性优化，K8S做为一种基础设施，其优化一般是分为组件优化与节点优化，针对组件优化，如何进行etdc、kube-apiserver的优化？

@edwin1986 上汽通用汽车 系统架构师： 

由于etcd的先天特性，除去硬件相关优化（IO、内存等）还可以进行etcd本身代码级别优化、在使用场景上进行优化，包括避免大对象频繁变更（如crd设计不合理），具体参考本章节教程。

除此之外，k8s官方的一篇文章有一定启示意义。https://kubernetes.io/blog/2015/09/kubernetes-performance-measurements-and/

8、容器云平台选择底层计算资源时的性能评测？

请教两个问题：

1、容器云平台选择物理机还是虚拟机作为底层计算资源，各有怎样的优劣势？

2、从性能角度考虑，该如何设计测试案例来对物理机和虚拟机作为底层资源时的容器云的性能进行评价？

@edwin1986 上汽通用汽车 系统架构师： 

我理解虚拟机的整体SLA会比物理机高，比如应用有状态（指对底层资源的绑定和依赖），则VM可提供更多的可用性。但同时由于虚拟化会损失10%左右性能。

而物理机单节点SLA有限，需要通过容器平台和必要的监控手段合理进行容器调度。但充当容器计算节点使用时需要考虑爆炸半径和雪崩效应。

@宁科 博云 架构师：

第一个问题，容器云平台基于VM的优势有：

1.相比物理机，VM的扩容，重建和迁移更方便。

这一点也是“云”的优势，借助于云平台管理系统，基于VM的计算资源在扩容，迁移等方面操作的便捷性是很明显的。

2.屏蔽底层硬件，容器部署更容易。

VM对于网络，存储以及计算资源都进行了抽象，部署在上面的容器不用再关心具体的硬件能力，很方便容器的部署以及资源管理。

而物理机的优势主要是 减少了更多损耗，硬件资源利用率更高。

第二个问题，容器云的部署以及运行本身需要消耗资源，因此对容器云的性能测试是非常重要的。

测试可分项进行，对网络流量，存储性能以及计算性能分别测试。可预先不上业务应用，只构造使用简单的单项测试用例，必要时对比在物理机 和 虚拟机底层资源时容器云的性能。

@mtming333 甜橙金融翼支付 系统运维工程师：

物理机还是虚拟机 ，用过几千台虚机也用过几百台物理机，建议根据现有基础设施情况有啥用啥，区别甚小。

@penganxiang 某互联网企业 系统架构师：

个人感觉用物理机还是虚拟机是需要根据场景来，公有云上的K8S 服务基本上都是基于虚拟机的，阿里、腾讯才能提供服务物理机的K8S 服务，并且物理机的成本很明显要比虚拟机高。

如果自己有IDC和物理机的话 那就直接跑物理机了，没必要在物理机和虚拟机之间再加一层，网络架构也会变得稍微复杂一点

9、容器平台在多租户，容器隔离、安全的解决与性能损耗是否存在矛盾？如何平衡性能与其他功能之间的矛盾。

@edwin1986 上汽通用汽车 系统架构师： 

非常好的问题，所以俗话说架构是平衡的。

方案上，容器可实现不同颗粒度的隔离，包括by ns、by pod等。具体需要根据组织管理颗粒度进行选择，可适当对标vm管理方案。但方案上需要注意，即使是by ns，其本质是还只是弱多租户隔离，可靠性和vm有较大差异。

另外，由于容器往往通过覆盖网络方案实现网络虚拟化，是否需要使用一个警察管理整个网络平面这个是需要定义的。当然新的方案有新的灵活手段解决，这也需要组织适当的平衡

@俞黎敏 IBM广州 软件开发工程师：

找平衡，并择优而用之，扬长避短之。

不可能有一个方案是百分百无缺点，我们需要用的是其优势的地方。

10、K8S pod 的性能监控？

1、对于部署企业信息化系统的容器云，工作节点配置建议？2、K8S pod 的性能监控，监控工具，资源调配？3、数据库容器化后的性能如何？

@edwin1986 上汽通用汽车 系统架构师：

问题1，工作节点和infra节点必须分开（包括ingress、efk等）。workload节点配置根据应用同质化情况（比如是否对下层计算资源有要求、io要求、网络要求、cpu内存要求等等）适当区分。但需要避免节点资源过少导致容器不能有效调度和节点资源过多引起爆炸半径较大的问题。

问题2，node exporter等工具可以将节点指标聚合到Prometheus中。前者还支持开箱即用的监控KPI扩展。pod内部可以在应用层或sidecar通过exporter监控。至于资源调度，k8s默认调度器功能一般够用，可通过节点污点等手段调整容器亲和性。如果有能力，可以通过schedule framework实现自定义调度实现。

问题3，该少的不能少。原先数据库应用层监控的工具或功能虽然实现容器化了，也需要通过自动化方式实现。

更多交流内容可点击阅读原文

觉得本文有用，请转发、点赞或点击“在看”，让更多同行看到

 资料/文章推荐：

• 
  

---

https://www.talkwithtrend.com/Topic/3937