在帮助企业进行基于私有环境的云原生转型的过程中,帮客户把存量应用迁移到 Kubenrnetes 上,是个常规任务。通常说来,在解决了初步的技术可行性之后,接下来要解决的就是资源分配的问题,我们已经讨论过,在近乎同样的资源总量情况下,少量大节点构成的集群和大量小节点构成的集群的一些差异,然而这里还是缺少一个完整的方法——如何把现有应用的需求转换为资源设计呢?
要为应用分配资源,首先要明确资源所包含的项目,除了显而易见的 CPU 和内存之外,往往还会包含一些因地制宜的项目,例如:
在把各种资源分门别类都罗列清楚之后,就可以给业主方设计一份应用资源问卷了,其中应包含如下要素:
这里对资源需求部分还有一个需要注意的点就是 Sidecar 以及一些“隐藏”进程,例如监控 Agent 等,这些东西同样会占用系统资源,有时用量还比较大,并且这些进程是随着应用组件实例进行伸缩的,因此其资源需求应该并入到所在的主要进程。
实践过程中,这个步骤会占用相当多的时间,在独占虚拟机/物理机运行时,很多业务方其实并不清楚应用的具体资源需求,是否能够构建镜像、是否能够在 Kubernetes 中运行也都是未知数,因此在调研过程中可能需要进行更多的沟通和培训工作。关于应用自身对 Kubernetes 的适应性,我通常会有几个简单的问题:
这些问题本身的答案并不重要,重要的是能够提醒对方,对于自身应用行为应该有一个深入且诚实的了解。
在得到调研结果之后,就可以据此进行设计了。除了调研结果中的几个变量之外,Kubernetes 的实施过程中还包含些隐含的约束条件,这些约束条件一方面限制了对于集群的设计规模,另一方面也能够辅助我们对集群进行资源配置。
在有了这一系列的文档之后,基本上是可以设计出来一个有理有据的合适规模的集群的。
在应用成功在集群上试运行成功之后,应该有一段重点观察期,我们可以用 Prometheus 对新晋应用进行监控,有几个指标需要重点关注:
这里提到的内容都是非常基础的内容,针对的也是基础的业务应用容器化转型工作。相信在实际工作中,还会有更多的资源考量、监控指标以及非功能性限制加入到这个设计过程中,帮助读者更好地进行集群规模的设计。