公司容器云，企业落地的困境与出路思考
众所周知，容器及容器作为一项开源基础设施技术已经被企业关注很长时间了。伴随着“Docker Kubernetes”逐步成为该领域的主流选型，其技术框架也逐步走向成熟。业内几乎所有的主流IT厂商都或多或少地参与其中，正在共同构建一个丰富的生态。今天就由的小编来讲一讲公司容器云，企业落地的困境与出路思考。
创新互联公司于2013年创立，先为虹口等服务建站，虹口等地企业，进行企业商务咨询服务。为虹口企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。
一切看上去似乎都很美好，但是如果我们深入到企业内部，你大概率会发现容器云在中国企业的落地境况并不乐观，甚至在部分场景下已经陷入进退两难的困境。这个现象非常值得我们去思考和探讨。
当前，构建容器基础设施平台的核心技术组件和框架几乎都是开源技术，而这一场景在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也进一步佐证了我们对这一问题的看法）。
容器解决方案解耦的三大功能域
“RUN”关注为企业数据中心部门提供一个能够高效部署、运维生产级别Kubernetes容器集群的能力。该能力包括部署规划、集群创建、集群运维等；
“BUILD”关注为研发部门提供一个构建适合在容器云上开发、测试和部署业务应用的完整框架和流程，包括微服务框架选型、业务微服务化改造支持、业务CI/CD交付流水线建设，以及相关的开发测试环境支持工具等。
“MANAGE”起到连接两者的作用。它将数据中心部门构建的多地分散的Kubernetes容器集群能力开放给业务用户自助申请使用，并在其中落实一系列的管理实践（例如用户租户管理、安全管理、配额管理等）。
通过这样的解耦之后，企业内部容器云解决方案的落地可以分步骤、专人专项地落地，各个环节的建设进度可以按照自己的实际情况进行推进。
2. 复用企业内现有基础设施。目前，企业内部广泛存在的IT基础设施包括VMware、OpenStack、x86物理机、集中存储和器等。解耦后的容器云方案应该重点关注对于VMware和OpenStack环境的深度集成。最好用户只需要配置好VMware和OpenStack环境的相关管理账号信息，就可以调用这些平台的API，完成计算、存储和网络资源的自动申请、配置和初始化。
这样可以带来两个明显的好处。一是可以复用企业内部现有的VMware和OpenStack环境资源（这些资源本身就是数据中心内部人员掌控和管理的）；二是由于VMware和OpenStack环境已经提供了非常好的计算、存储和网络解决方案并具备弹性，容器云建设可以复用这些能力，快速建设并充分发挥容器云的弹性调度能力。
3. 高度关切企业一线员工在尝试容器云时的现实问题。例如，能否针对企业用户的实际情况简化企业内部构建容器云基础设施的外部依赖，最好能够实现全离线安装。同时，为了降低操作门槛，最好能够提供全Web UI的操作界面，以营造更加友好的客户操作体验。
总结来说，解决方案应该通过解耦、复用、简化等手段来降低企业用户采纳容器云的门槛。
三、“生产就绪”是核心价值诉求
“降低门槛”是容器解决方案企业环境落地的出发点和首要目标。但如果无法提供核心价值，即使是零门槛也难以在企业环境立足。而容器技术落地目前的核心诉求还是“生产就绪”。对数据中心部门来说，就是需要能够满足企业内部数据中心生产业务的运行需求。为此，应该重点投入以下几个方面工作：
1. 提供生产级别的容器云计算、存储和网络基础设施解决方案。企业为了满足自身业务发展，已经在自己数据中心或者云上建设了完整的计算、存储和网络基础设施。容器云同样需要建设在这些基础设施之上，复用这些生产级的能力。只有这样，容器云才能满足企业生产级运营的要求，并且融入企业数据中心的运营管理体系。这其中包括计算、存储、网络以及负载均衡等全方面的对接。而且，这些对接方案需要通过严格的生产环境测试。
2. 整合运行生产级容器云的配套组件，包括监控、运维、管理等一系列工具。具体来说，一个生产环境的Kubernetes集群正式投入运行当然需要包括核心组件，但还需要包括很多不可缺少的外围支撑组件，例如集群访问、集群运行状况监控、集群业务运行监控、集群镜像仓库、集群内业务反向代理等。所有这些组件最好能够在Kubernetes集群创建时随同集群一同安装配置，实现一键创建完整生产级别Kubernetes容器集群的目标。
3. 支持集群高可用部署模式。故障节点重建和Multi-AZ支撑应该是生产级别Kubernetes集群所必备的能力。
4. 全生命周期管理的能力。容器集群全生命周期的管理是生产环境Kubernetes容器集群所必须要解决的问题。例如容器集群无缝升级、容器集群弹性伸缩、容器集群备份支持等。
四、KubeOperator：从这里开启您的Kubernetes之旅
基于以上的思考，FIT2CLOUD飞致云在2019年11月正式对外发布了容器领域第一个项目——KubeOperator。
KubeOperator是一个开源项目（https://www.cdcxhl.com/
KubeOperator 产品架构
KubeOperator项目希望能够通过接近零门槛的方式，为中国企业用户在其IT基础设施环境中提供生产级别的容器云运行环境，让容器这项普惠的基础设施技术能够成为中国企业用户的普遍选择。
本文名称：公司容器云，企业落地的困境与出路思考
网站URL：http://pwwzsj.com/article/cpcdej.html
