容器云平台物理集群配置实践.docx

前言

最初建设容器云平台的时候，笔者也讨论过容器虚拟集群和物理集群的优缺点。在容器云平台应用实践过程中，也逐渐部署了虚拟节点和物理节点。随着实践的深入，虚拟节点和物理节点的不同资源配置，也带来了一些问题和思考。起初觉得容器既然是轻量化的，每个节点其实是不需要配置那么高的资源的。不过很快就被现实打脸，不合适的节点资源配置不但增加了管理的复杂度，也带来了资源的浪费。另外由于容器云平台自身功能的限制，以及总体架构和总体资源受限，难以实现真正的弹性调度、按需扩展。比如说经常会出现一台宿主机上的虚拟机资源争抢现象，但从容器云平台看到的却是容器节点资源使用不高但应用出现请求异常等问题。所以这并不是一个简单的容器云问题，需要实现各个层次的联动，比如实现虚拟化平台与容器云平台的联动，基础设施资源管理平台与容器云平台的联动以实现异构资源调度等。

从虚拟机节点到物理机节点

基于虚拟化平台来部署容器云则相对容易实现容器节点的扩缩容，但由于缺乏统一的监控平台和囿于单体竖井系统建设思路，虚拟化层宿主机的信息往往在容器云平台无法看到，无法及时有效平衡容器节点在虚拟化宿主机上的负载。

笔者一直建议通过多云管理平台（也管理虚拟化平台）来实现不同基础设施资源的管理，但目前市面上的云管平台基本都是一个大杂烩，没有真正理解云管的定位和范围。等等诸多原因，使难以实现基础设施资源的自动化弹性扩容和平衡调度。

另外，虚拟化层也导致了机器性能损失约20%，造成很大的浪费。比如Java应用对资源的需求相对比较大，基于SpringCloud框架开发的微服务，如果部署在资源配置比较小的虚拟机上，容器经常会因为资源不足而被驱逐，会看到很多Evicted状态的容器。

再者，随着容器节点的增多，很多问题就暴露出来了，比如说Master节点配置（随着节点增多，Master节点资源不足响应变慢）、ETCD配置（pod、service等对象越来越多）、Ingress配置（高可用、负载均衡等不同需求所带来配置的不同）、Portal配置（Portal组件划分、组件集中部署或分布式部署、组件资源配额）问题等。

一方面可能国内很多容器平台的应用都是浮于表面，缺乏真正的实践经验，没有太多可以借鉴的，也导致很多功能不完善；另一方面，传统单体竖井的建设思路，已经完全不适应云计算和云原生的理念，从而也导致冲突，制约容器云的深度应用和实践。

为了更好的实现可见性和可管理性，为了更好的性能和资源节省，经过一段实践之后，我们将一些物理服务器部署到了容器虚拟集群，用于部署运行重要的业务应用，形成虚实节点混合部署集群。

混合节点集群

私有云环境往往无法充分配置各种类型的资源，所以大都是通用性资源，用于部署各种业务应用。容器云平台既要考虑节点的敏捷扩容，也要考虑重点业务应用的稳定运行和执行效率。物理服务器的采购往往需要一个周期，需要提前准备相应的资源。物理节点扩容相对于虚拟化来说就没那么方便，也难以实现资源的复用，这是物理节点不足的地方。但物理节点没有性能损失，适合运行一些比较重要的业务，或对处理性能要求比较高的业务。因此可以在容器集群中同时部署虚拟节点和物理节点，实现混合节点的集群。在业务应用部署的时候，根据业务应用特点调度到合适的节点上。

节点配置多大的资源是合适的？坦率说到目前为止也没有一个明确的标准，往往和具体的业务密切相关。笔者所在场景中虚拟机可以配置16C64G、16C48G或者32C64G，磁盘200G，CPU和内存的比为1:4、1:3、1:2。根据业务运行对资源的消耗需求，经过一段时间的运行观察，可以根据实际资源使用再调整节点资源配置、容器资源配置。在交易高峰时段，CPU经常是满负荷的，但其他时段CPU往往用的又比较低。共享分区、独享分区、节点容量、资源碎片、纵向扩容能力、横向扩容能力、迁移规则、服务优先级、甚至异构资源的费用等等，都可能会影响到pod的调度。这其实带来了一个物理节点资源配置的问题。物理机不做虚拟化，就无法从虚拟层来实现复用（不过也减少了虚拟化损耗），另外，物理节点如果出现异常，需要维护重启，其上面的服务都会受到影响。如果部署的服务比较多，带来的影响就比较大。所以一个容器节点的资源配置也不是越大越好，需要基于实践和实际找到一个平衡。

容器物理集群配置

物理集群中节点什么样的配置比较合适？可能需要从几个方面来考虑。最初笔者也想当然觉得可以用很多低配PC机，不过从机房的使用效率来说，低配PC明显不是很合适，毕竟需要占据很多机房机位的，这个成本其实很高的。但如果配置过高，一个容器节点通常也不适合部署很多个容器，k8s建议不超过110个pod。另外，配置过高，节点数量相对就比较少，弹性调度的范围就比较小。特别多个重要的容器部署到同一个节点上，一旦节点出现异常，影响可能会非常大。不过物理节点相