本文介绍了集装箱化在业务方面的成本，并探讨了如何降低这些成本，从而使集装箱化过程更加顺利。企业方的准入成本主要有四种类型： 　　

　　

　　业务迁移和转型的成本：K8S形象的制作和管理成本；K8s的学习和使用成本；容器环境下改变一些习惯的成本；业务迁移和转型的成本；业务迁移的成本主要体现在业务从物理机或虚拟机迁移到容器的过程中。用户需要在线完成容器，测试业务功能，通知相关上下游，切断流量，最后离线业务，回收旧机。鉴于迁移过程中的许多步骤和漫长的过程，并且为了避免对业务的影响，很难使整个过程自动化。似乎没有特别好的流程或技术来降低迁移成本。 　　

　　

　　此外，一些用户需要转换和分离他们的服务。这些转化主要体现在项目组织的无状态、基于容器的优化，比如配置文件、启动脚本等。这通常需要PaaS团队来支持用户进行转换。然后，改造的人工和时间成本往往比较大，对于这类业务，可以降低集装箱化的优先级。 　　

　　

　　镜像制作和管理的成本：镜像制作是容器化的必要步骤，Dockerfile的准备和维护以及镜像制作是镜像模块的重要组成部分。客观来说，Dockerfile的学习成本很高，制作一面精美的镜子往往需要丰富的经验；另外，镜像制作环境的维护也是一个问题。如果每个用户都有一个生产环境，必然会造成大量的资源浪费。如果大家共用一个环境，可能会造成环境混乱。 　　

　　

　　对于大型资源，建议PaaS团队支持和教育业务方编写Dockerfile，并规定一定的规则。这些Dockerfile最好用git来维护，方便管理和维护。 　　

　　

　　对于标准化服务，它们的目录组织，如启动方法、部署脚本、配置文件、依赖包等。所有这些都遵循一定的规则，因此自动化此类服务的镜像生产相对容易。根据这些规则可以自动生成Dockerfile并完成镜像制作，最终用户对镜像制作过程没有感知。 　　

　　

　　对于资源要求不高的非标准化服务，因为应用环境和组织比较混乱，编写和镜像Dockfile的成本会很高，大量访问容易造成很多不良后果。对于这类用户，可以把容器化的优先级安排在最底层。同时建议先标准化再集装箱化。 　　

　　

　　从PaaS的角度，需要维护语言层面的基础形象；其次，做好引导措施，防止用户写复杂的图片；对于标准化服务，实现了自动生成Dockerfile的模块。 　　

　　

　　K8S学用成本业务容器化后，用户可以通过K8S API或Portal完成生命周期管理。K8S有十几个API。这些API需要很多参数，它们的用法很复杂。用户通常需要长时间的练习才能掌握这些参数的含义。 　　

　　

　　对于拥有大量资源的客户，往往会在K8S的基础上搭建自己的平台，所以通常会直接使用K8S API来实现生命周期管理。对于这类用户，建议PaaS团队做一定的介绍，让业务方掌握正确的姿势，规避潜在的风险。 　　

　　

　　对于使用发布系统发布的用户，可以打通发布系统和K8S。每当用户发布时，都要先做一个镜像，然后根据镜像更新原来的容器实例。这样用户几乎感知不到K8S，大大降低了学习成本。 　　

　　

　　对于其他机器资源较少的用户，建议使用Portal完成生命周期管理。 　　

　　

　　从PaaS的角度来说，首先要做好API认证授权，避免安全隐患，采取限流措施。其次，采用完全扁平化的互通网络，非常有利于业务接入。完全扁平化意味着容器、虚拟机和物理机可以互操作，从而避免引入服务和其他模块。 　　

　　

　　集装箱环境下的一些习惯改变成本。很多用户反馈一些体验问题，比如缺少一些常用工具，free看到的是主机内存，容器重启后文件丢失等等。这些问题可以归纳为三类： 　　

　　

　　富容器vs瘦容器docker的隔离不完整。如何保存状态数据或工具？瘦容器原则上更符合K8S和Docker的设计理念，也符合Unix的理念：做一件事，把它做好；其次，瘦容器业务流程是容器内部的pid 1流程，容器的状态基本反映了业务流程的真实状态，为K8S提供了更详细的信息和故障决策依据；最后，薄容器节省存储空间。从实用的角度来看，瘦容器给服务访问带来了很大的困难。首先，如何适应公司现有的运维体系。如果容器中没有装满运维相关代理，可能需要重新实现大量的运维相关模块，开发和推广的工作量可想而知。其次，如果没有SSH之类的功能，会很大程度上影响用户定位的问题。所以从落地的角度来说，使用富容器更有利于业务方的接入。实时，阿里等行业也采用了富容器的做法。 　　

　　

　　虽然命名空间，cgroup等。奠定了容器隔离的基础，有些/proc下的文件，包括sysconf之类的系统调用，就不隔离了。当用户使用free、df等一些命令时。他们经常会看到主持人的内容，这是非常容易引起误解的。对于java 9以下的应用，由于sysconf是用来获取可用资源的，所以非常容易造成OOM。解决这些问题需要具体问题具体分析，比如修改free、df等命令，jvm启动时设置xms、xmx等参数。 　　

　　

　　此外，业务端有时会存储一些配置文件、工具等。在集装箱里。当容器重新启动时，这些数据通常会丢失，并且很容易被业务方创建。 　　

成困惑，关于这点，需要告知业务方数据需要存入持久化存储中，对于常用工具，可以写在镜像的 Dockerfile 或者业务初始化脚本中。

　　

小结总而言之，除了迁移和改造成本没有特别好的办法外，其它成本都可以通过技术或者流程使业务的成本降到最低。从另外一个角度来说，这些成本并不能给容器化带来质的阻碍。

　　

此外，对于非标准化且占用资源少的业务，建议其先做标准化，再做容器化。

　　

来源：koala bear ，

　　

wsfdl.com/kubernetes/2018/09/28/migrate_to_k8s_costs.html

　　

江苏立维成立于2015年，核心团队来自焦点、华为、中兴，专注于企业信息化领域的安全、运维产品的开发和服务，为企业提供包含业务迁移上云、业务稳定性保障、安全运维是国内首批专注于企业业务安全稳定运行服务保障的公司。