作者：徐桂林
众所周知，容器及容器云作为一项开源基础设施技术已经被企业关注很长时间了。伴随着“Docker + Kubernetes”逐步成为该领域的主流选型，其技术框架也逐步走向成熟。业内几乎所有的主流IT厂商都或多或少地参与其中，正在共同构建一个丰富的生态。
一切看上去似乎都很美好，但是如果我们深入到企业内部，你大概率会发现容器云在中国企业的落地境况并不乐观，甚至在部分场景下已经陷入进退两难的困境。这个现象非常值得我们去思考和探讨。
容器：新时代的普惠技术
如今，经历了容器运行时和容器编排引擎两场重要战争之后，容器的核心技术框架选型已经基本成熟，容器生态也在蓬勃发展。对比之前的基础设施平台技术，容器算得上是一项普惠的基础设施技术。容器技术的普惠性主要体现在以下两个方面：
■ 当前，构建容器基础设施平台的核心技术组件和框架几乎都是开源技术，而这一场景在IT基础设施领域还是第一次出现。不像之前VMware虚拟化平台等是专属技术，由少数企业所垄断；
■ 未来，得益于开源社区日益成熟的项目运营管理机制，以CNCF（云原生计算基金会，Cloud Native Computing Foundation）为代表的独立第三方基金会得以成立，并且持续推进整个容器云生态向着开源、开放的方向发展；另一方面，以Operator为代表的新型开源框架又进一步将大量的PaaS层公共组件供应商拉入这个领域，更加夯实了整个生态进一步向普惠方向发展的基础。
中国企业落地容器技术的困境
尽管容器技术将发展成为一种普惠技术，也有很多企业用户对容器表现出了浓厚的兴趣，乃至将其用于企业内部的开发、测试乃至生产环境。但是，容器在中国企业环境的落地之旅其实不容乐观。过去几年，FIT2CLOUD飞致云有幸和众多企业IT部门进行了比较深入的沟通。通过这些交流，我们发现了一些相对关键的问题：
■ 首先，当前市场上的容器云解决方案不断向“全能”方向发展，希望在一个解决方案中囊括容器生态的方方面面（例如运行时、调度引擎、微服务框架、CI/CD流水线等）。
但是，当下中国企业IT部门的组织架构基本都是按数据中心运行部门和业务研发部门分开进行管理的。这种“全能型”解决方案在企业内部落地时遇到的第一个问题就是应该由哪个部门牵头建设。
如果是研发部门牵头建设，通常会更多地关注解决方案中研发支持部分，容易忽略容器云的日常运行管理需求，最终建设方案在交付运行部门上生产环境运行就面临着巨大的挑战和不确定性；如果是数据中心运行部门牵头建设，这些“全能型”解决方案中又包含了大量面向研发部门的能力和框架工具。这些能力和框架工具是否合适企业内部实际的研发流程和现状也变成一个未知数。
这种纠结导致了一种尴尬的局面——企业内部现在建设的容器云平台经常会出现要么上不了生产，要么没有足够负载。所以说，“全能型”容器云解决方案在企业落地过程中面临的第一个大的挑战就是其设计思路和中国企业用户现有IT管理体系的冲突问题。
■ 第二，当前市场上容器云的解决方案过于求“新”，缺少对企业内部存量投资的关切和适配。企业因为建设容器云而需要重新采购计算、存储乃至网络设备，再考虑到软件部分的独立采购流程和费用，这些都无形中拉升了容器云的落地门槛。
与此同时，大部分企业内部都有一定的存量x86物理机以及若干虚拟化平台，很多情况下上面运行的业务负载也不一定会很高。所以，我们需要认真考虑如何充分“利旧”这些存量的投资，并在其上循序渐进地推进容器云落地战略。
■ 第三，当前容器云落地的技术门槛也不低。尽管容器云是开源技术，任何人都可以免费从互联网获取这些技术。但是，一旦企业一线的技术人员开始尝试，很多具体的技术问题就变成了实实在在的拦路虎。
例如，如何在企业内部搭建一个完整的Kubernetes集群（包括版本选择的困难、企业防火墙限制外网访问、安装部署操作不友好等）、如何与企业内存储和网络资源对接、如何搭建高可用集群等。这些问题都会挫败一线技术人员的信心，让容器云这个普惠技术的落地无法从企业内部生长出来，达到生产就绪的状态，进而得以广泛采纳。
要解决这些困扰，我们还需要在“降低门槛”和“生产就绪”这两个方面更进一步。
“降低门槛”是首要目标
目前，中国企业用户落地容器云的门槛还是太高了。那么，在“降低门槛”方面，我们可以做的事情有哪些呢？
1、解耦容器云落地方案。面对任何一个复杂的技术问题或者解决方案，解耦都是一个最常见的思路。根据容器技术特点和国内企业IT部门的组织架构，我们认为，应该将企业容器解决方案解耦成为三大能力域，其中包括面向数据中心的容器集群运营（RUN）、面向研发测试的容器应用构建（BUILD）以及连接两者的管理界面（MANAGE）。（注：VMware近期发布的VMware Tanzu也进一步佐证了我们对这一问题的看法）。
附图1 容器解决方案解耦的三大功能域
如附图1所示，“RUN”关注为企业数据中心部门提供一个能够高效部署、运维生产级别Kubernetes容器集群的能力。该能力包括部署规划、集群创建、集群运维等；
“BUILD”关注为研发部门提供一个构建适合在容器云上开发、测试和部署业务应用的完整框架和流程，包括微服务框架选型、业务微服务化改造支持、业务CI/CD交付流水线建设，以及相关的开发测试环境支持工具等。
“MANAGE”起到连接两者的作用。它将数据中心部门构建的多地分散的Kubernetes容器集群能力开放给业务用户自助申请使用，并在其中落实一系列的管理实践（例如用户租户管理、安全管理、配额管理等）。
通过这样的解耦之后，企业内部容器云解决方案的落地可以分步骤、专人专项地落地，各个环节的建设进度可以按照自己的实际情况进行推进。
2、复用企业内现有基础设施。目前，企业内部广泛存在的IT基础设施包括VMware、OpenStack、x86物理机、集中存储和负载均衡器等。解耦后的容器云方案应该重点关注对于VMware和OpenStack环境的深度集成。最好用户只需要配置好VMware和OpenStack环境的相关管理账号信息，就可以调用这些平台的API，完成计算、存储和网络资源的自动申请、配置和初始化。
这样可以带来两个明显的好处。一是可以复用企业内部现有的VMware和OpenStack环境资源（这些资源本身就是数据中心内部人员掌控和管理的）；二是由于VMware和OpenStack环境已经提供了非常好的计算、存储和网络解决方案并具备弹性，容器云建设可以复用这些能力，快速建设并充分发挥容器云的弹性调度能力。
3、高度关切企业一线员工在尝试容器云时的现实问题。例如，能否针对企业用户的实际情况简化企业内部构建容器云基础设施的外部依赖，最好能够实现全离线安装。同时，为了降低操作门槛，最好能够提供全Web UI的操作界面，以营造更加友好的客户操作体验。
总结来说，解决方案应该通过解耦、复用、简化等手段来降低企业用户采纳容器云的门槛。
“生产就绪”是核心价值诉求
“降低门槛”是容器解决方案企业环境落地的出发点和首要目标。但如果无法提供核心价值，即使是零门槛也难以在企业环境立足。而容器技术落地目前的核心诉求还是“生产就绪”。对数据中心部门来说，就是需要能够满足企业内部数据中心生产业务的运行需求。为此，应该重点投入以下几个方面工作：
KubeOperator：从这里开启您的Kubernetes之旅
基于以上的思考，FIT2CLOUD飞致云在2019年11月正式对外发布了容器领域第一个项目——KubeOperator。
KubeOperator是一个开源项目（https://github.com/KubeOperator/KubeOperator），旨在帮助用户在离线网络环境下，通过可视化UI在VMware、OpenStack或者物理机上规划、部署和管理生产级别的Kubernetes集群。该项目仅关注提供生产级别Kubernetes集群全生命周期管理这个领域，即前文提到的“RUN”部分。KubeOperator的产品架构如附图2所示。
附图2 KubeOperator 产品架构
KubeOperator项目希望能够通过接近零门槛的方式，为中国企业用户在其IT基础设施环境中提供生产级别的容器云运行环境，让容器这项普惠的基础设施技术能够成为中国企业用户的普遍选择。
我们希望，企业的数据中心管理团队能够通过KubeOperator项目轻松、快捷地进入美妙的容器世界，同时我们也真诚地欢迎大家一起加入到KubeOperator项目中来，一起完善和发展这个项目。您可以访问我们的项目主页（www.kubeoperator.io）获取该项目的GitHub主页地址、下载免费安装包。也欢迎您加入我们的技术支持微信群献计献策，共同推动KubeOperator发展。
编者注：本文作者徐桂林为FIT2CLOUD飞致云首席布道师、东区总经理。
KubeOperator技术交流QQ群：825046920；
KubeOperator微信群：搜索微信号 wh_it0224，添加好友，备注（城市-github用户名）, 验证通过可加入群聊。
