java 服务 容量评估,容器云平台容量规划及管理优化

随着容器云平台实践的深入，容器基础设施资源的分配和使用也暴露出了前期产品设计的一些意料之外的问题。特别在证券行业，资源的使用时段往往比较集中在上午9点到10点时段前后，过了这个时段，资源的使用量就迅速下来了，所以平时看起来资源利用率很低、很空闲，但各个团队又不敢轻易释放资源，也就导致容器云平台资源的浪费，使平台容量的规划和优化比较困难。在原来各个团队自己管理时，由于没有相应的资源使用监控，也就不关注是否有资源浪费。但在容器云平台，不得不考虑资源的规划、需求预测、增长趋势、意外处理等。既要考虑弹性扩容，又要避免资源过度浪费等，因此做好容器云平台的容量规划和管理，并不是件很轻松的事。

工欲善其事，必先利其器。要做好容量的规划和管理，就必须对容器云平台的资源分配情况和资源使用情况比较了解，并了解和理解用户的需求和关注点等，提升用户体验和满意度。

一、 从用户体验入手

如何让租户用户更好的了解和理解自己的资源使用情况？分配量、使用量、可用量等该怎么展示？不同的对象该面向哪些角色和人员?等等都需要认真的考虑和规划。

从管理员视角，我们需要知道每个租户分配了多少资源、分出去了多少资源、使用了多少资源、可用的资源等。在私有云环境，我们不仅要关心租户用多少资源，还要关心资源的使用效率。不是说资源随便分配随便用，好钢用在刀刃上，因此，虽然私有云环境不进行计费，但要关心资源的使用效率。同时在用户界面上要简洁、一目了然。

从租户视角，我们要能很清晰的看到有多少资源，用了多少资源，可用多少资源，这些资源分布在哪些集群上、哪些分区上，部署了多少应用、多少服务，有多少实例，资源的利用效率多高，请求峰值及资源使用峰值及时点等，在每个服务和实例管理界面要能看到服务的配置和实例的配置及资源使用情况和使用效率。例如如果一个服务分配了大量资源却一直利用率很低，那么就是不合理的，造成了资源浪费，就需要进行调整，给它分配合适的资源。反过来，如果一个服务分配的资源太少而服务可能无法启动，容器就可能不断的尝试重启。因此合理的资源分配和管理是容器云平台重要的事项之一。

总的来说，从用户体验角度，容器云平台要尽可能提供完善的辅助能力，帮助用户提高资源分配和使用效率。

二、 容器云平台资源管理

我们讨论过多集群的设计和管理及适用场景。在初始需求量不是很大时不适合搭建多个集群，当然需要根据业务的要求来确定，比如需要多集群备份，就需要搭建至少两个集群实现关键业务的备份部署。

从容器云平台角度，一定要有全局的顶层的平台资源视角。平台的资源总量、使用量、分配量、可用量等，然后才是每个集群、每个分区、每个租户甚至每个节点的资源总量、分配量和使用量等。在实现容器云平台多集群不能只考虑kubernetes，不是实现Kubernetes集群联邦就ok了，一定要从平台的层次考虑，平台设计一定要高于kubernetes。

很多人可能仅仅是从开发人员的角度来考虑如何使用容器云，也就把容器云平台等同于kubernetes。如果是这样，直接使用kubernetes就好，没必要再画蛇添足封装一层。我们定义的容器云平台是基于容器管理的轻量化PaaS平台，所以仅仅kubernetes是不够的。同时也从顶层设计来考虑容器云平台、云管平台、基础设施资源管理、DevOps平台、服务治理、中台、API网关和 OpenAPI 管理等的建设与融合。因此容器云平台的资源规划、扩容和管理需要结合相关的系统和平台的整合与融合。

三、 需求预测及容量规划

租户的资源需求通常是基于租户的应用部署要求来确定的。为租户分配资源通常也是按照最大的请求量来考虑的。某一阶段内所有租户的需求总和基本上反映了容器云平台的资源需求量，同时可以考虑再预留部分资源以应对意外情况(或者实现按比例自动扩展等能力)，就可以得出并准备这段时间内的资源容量。通过评估应用服务和部署每个实例的CPU／Memory资源分配，可以大致知道所需的计算资源，评估服务持久化数据存储量确认持久化存储资源需求，评估网络部署需求、实例数、访问需求等确认网络资源需求等。

(一) 计算资源

计算资源可能来自于多个集群甚至是多个云平台。基础设施资源由云管来提供，容器云平台只考虑使用资源。不过需要实现资源的自动扩容能力，这需要和云管集成。在设计实现时需要提前规划考虑。

有一个问题可能需要注意，就是平台的组件和kubernetes组件占用的资源。如果平台设计的不好，可能平台组件和kubernetes组件会占用很多资源，造成浪费。很多人追求微服务，把服务分拆成很多小服务。在容器云平台，如果每个服务都部署成一个容器，就需要维护很多这样的容器，会造成大量的资源浪费。所以平台组件服务的设计和整合会是很关键的一个事项。

另外，容器基础镜像的优化也非常重要。比如运行java微服务，是用jdk还是用jre镜像，是用tomcat或别的应用服务器镜像，镜像大小不同，所耗费的资源就不一样。这样的容器部署的量多了，就会带来比较大的不同。

(二) 持久化存储

不论私有化或者公有云，容器云平台持久化存储是不可缺少的。对于私有容器云，如果没有特殊的要求，通常使用NFS就可以了。在我们的实践过程中，一个重要的需求就是持久化存储的动态分配。通常，租户在首次申请资源时，会评估资源需求，也包括持久化存储需求。租户分配了一定的存储空间，除了静态创建持久化存储卷之外，某些容器也会动态被创建并且需要动态分配持久化存储卷。不过这倒不存在什么问题，用kubernetes的storageclass、PV、PVC和useraccout，serviceaccount等对象来实现存储和租户的访问控制能力。

(三) 网络资源

容器云调研选型更多的是考虑选择什么网络模型，却比较少提及网络资源的规划和管理。由于选择不同的网络模型，后期运维和管理可能会不一样。比如用underlay网络，就需要提前规划分配网段及IP地址范围，提前规划业务p od 网段以及网络地址类型(B类或C类地址)等，作为容器云平台专用网段，不要和其它业务混用；如果用overlay网络，则不需要考虑规划业务网段。

如果使用underlay两层网络，则需要提前规划独立的业务网段。同时需要考虑部署的容器量，确定选择网络地址类型。不同类型的网络地址可用IP数是不一样的，我们通常使用的C类地址一个网段只有250来个可用地址。所以要提前规划管理网段(也就是节点所在的网段)和业务网段(业务服务容器实例所使用的IP网段)，并确定网络地址类型。为了便于管理和维护，这些网段和IP最好是规划预留给容器云平台独立使用，不要再分配给其他业务或应用系统使用。如果使用overlay三层网络，则容器网络是虚拟的。相对来说所需要规划的网段和IP会少些，但最好对虚拟网络也进行统一规划，选择合适的虚拟网段和虚拟IP地址范围。

不同的网络类型各有优缺点，在企业级容器云平台场景下，不同的集群可能需要部署不同的网络类型，以支持不同业务场景需求。比如一个集群使用underlay网络，另外一个集群可能使用overlay网络。使用underlay网络的容器是全网可达的，对于需要通过固定IP访问或者容器的维护则相对容易些。

四、 弹性扩容

在容器云平台实践过程中，容器的弹性伸缩是一个重要的能力。但由于厂商弹性伸缩设计的不合理，也导致弹性伸缩功能配置和使用复杂化，带来了很多额外的管理工作。主要表现在namespaces资源限额，租户扩容限制等方面。

(一) namespace资源限额

我们知道kubernetes的namespaces可以设置限额，但不是必须设置限额。但是厂商在实现容器平台的时候，以namespaces对应租户下应用，强制必须设置 namespaces 资源限额，也就是应用的资源限额。这就导致到了应用下的服务难以按需实现自动弹性扩展。因为分配的资源可能是不够的，经常导致扩容的服务实例无法启动，不得不去修改namespaces限额。由于很多租户下操作人员不是很熟悉，所以也就导致了很多额外的解释和问题处理事情，给平台管理和运维人员带来了众多不应该有的额外工作量。

(二) 租户自动扩容与限制

在Kubernetes中没有租户的概念，因此无法用kubernetes的特性来实现租户的功能，这就需要在容器云平台来实现。这也是我们一直强调容器云平台一定要有自己的平台层的原因，不能只是简单封装kubernetes就是冒充容器云平台了。

对Kubernetes来说，租户可以是一个逻辑概念。其是Kubernetes一些对象的集合，当然也包括kubernetes之外的对象。比如说我们定义的“资源分区”，配置中心、日志中心等，这些共同来服务于租户。所以一个kubernetes是远远不够的。

那么如果租户资源不足时，如何实现自动扩容？我们曾考虑过租户自动扩容申请审批流程，和云管平台来集成实现。但是从我考虑的角度来说，这依然带来了很多的维护工作量。和云管平台集成实现自动弹性资源扩容是正确的，不过要尽量实现自动化，减少人为的介入和干预。

这里有两层的资源管理。一层是容器云平台层资源，一层是云管平台资源。容器云平台资源是基于云管资源的，这也是容器云或者容器化PaaS和云管平台的合理职责范围划分，不要混在一起使问题复杂化。租户的资源扩容是由容器云平台来分配的。容器云平台资源不足时则由云管平台自动分配。

在多集群环境下，租户可能拥有多个集群的资源，每个集群的资源都可以基于云管来进行扩容。所有这些能力都需要容器云平台层来实现。

(三) 平台扩容方式

可能有个细节是云管往往是虚拟化的，资源管理相对容易些，所以用云管来支撑容器云平台的弹性资源伸缩相对容易实现，可以快速创建虚拟机，增加节点，扩展资源等。但另外一种情况是容器云平台可以直接基于物理服务器来部署容器，每台物理服务器是一个节点。要扩展资源可能就需要增加物理务器节点。节点加入容器云平台容易，但物理服务器的准备通常需要时间，这就需要备份一些机器用于弹性扩容。这些机器可以由云管平台来维护。所以理想的情况可能是由云管管理虚拟化和物理服务器和其他云资源共同为容器云平台提供资源支持。

(四) 自动化、无人化运行

前面我们提到弹性扩容最好实现自动化、无人化，尽量不需要人为介入。这样才能提升效率。虽然说私有云平台体量相对较小，但长期节省的时间精力也可以做更多其他有意义的事情。

容器云平台资源使用管理和优化是一个不断完善的过程。随着实践和认知的提升，需要逐步来改进和完善一些不合理的地方，从而提升客户体验，提高资源利用效率，同时也提高业务效率。