企业容器云建设及推广的一点 Tips

容器云平台功能虽然强大，但是要在企业落地，却不是一件容易的事。一方面，容器云技术最近几年发展得非常快，比如容器编排引擎，之前有多个主流的选择，如 Swarm、Mesos 及 Kubernetes，然而现在 Kubernetes 已成为首选，但是 Kubernetes 的周边生态仍然很复杂而且变化很快。另一方面，容器云平台相对于传统企业来说，还是一个比较重量级的、较新的东西，如何与之前的技术、工具和流程对接，也是很大挑战。

下面从容器云平台的选型和搭建以及分阶段推广实施两方面谈一谈思路。

1、选型和搭建

容器云平台的底层设施，倾向于选择 Docker+ Kubernetes。目前此二者属于标配，其中 Docker 提供系统容器化能力，而 Kubernetes 提供容器编排能力及标准。但是仅有这两个底层设施还不够，还需要完善上层生态。对 Docker 来说，需要一个私有镜像仓库，来存放和管理企业内部的 Docker 镜像。对 Kubernetes 来说，一方面，使用原始命令和 API 操作不够方便，需要一个图形化管理系统，来降低使用成本；另一方面 Kubernetes 自身定义了许多插件接口及标准，需要引入第三方组件才能实现，比如容器存储、网络、域名解析、负载均衡等。除此之外，一些配套功能也必不可少，包括基于容器的 CI/CD、监控、日志采集等。

那么需要围绕 Docker 和 Kubernetes 组合多种工具，才能形成一个完整的、综合性的容器应用及管理平台。关于这个平台，其组成部分、常用开源组件如下所示。

• 底层：Docker + Kubernetes。

• 私有镜像仓库：常用 Harbor、Sonatype Nexus。

• Kubernetes UI 界面及综合管理：比如 Kuboard、Kubesphere、Rancher 等。

• 基于容器的 CI/CD 平台：比如 Rancher Pipeline、Jenkins Pipeline、Drone 等。

• 容器存储（Storage Class）：可选 NFS、CephFS、GlusterFS、OpenEBS 等。

• 服务发现（Service Discovery）、内部域名解析：常用 CoreDNS。

• 负载均衡（Ingress Controller）：Nginx Ingress、F5/HAProxy/Kong Ingress、Traefik 等。

• 容器网络（Networking）：Flannel、Calico、Weave、Canal 等。

• 监控告警：Prometheus、cAdvisor、Grafana 等。

除了上面列举的这些开源产品，还有一些商业化的容器云产品，由于起步比较早，并且经历过实践的检验，所以相对更加成熟。对企业来说，首先面临一个问题：容器云平台，是自研（基于开源产品）还是采购商业化产品？

前期做过不少调研，并对多家厂商的产品进行了 PoC 测试及试用，得出的结论是：厂商的产品比较成熟，但是有些定制化的功能并没有集成到通用版本中来，如果想要使用这些功能，需要等待更新和定制。如果选择自研，就基础组件来说，很多都是开源的，和商业产品差别不大，只是像管理平台、CI/CD 流水线、网络组件等需求集中的地方，开源产品一般不如商业化产品强大。

另外，在自研的过程中，由于缺少实践经验，在某些技术细节上，难免会踩一些“坑”。当然，自研的好处也显而易见，首先是免费，能节约一笔资金，另外，企业能够自己掌握技术细节，灵活地定制开发。具体怎么选择，还得结合企业自身情况考虑，具备较强研发实力又不急于全面实施的企业，可以先在开源产品上做一些尝试和实践。对于容器云平台的实施，经过一定的探索研究和实践，形成了一套基于开源组件二次开发的容器云平台。

2、分阶段推广实施

容器云平台确立之后，想在短期内全面推广实施并不现实，因为要考虑如何平滑过渡及与现有流程、工具整合，以及如何以影响最小的方式逐步推进等问题。生产环境和测试环境相对独立，而且生产环境稳定性要求高，容不得半点差错，所以容器云平台的实施通常是先在测试环境中进行，积累了丰富经验后，再推广到生产环境。在具体实施过程中，无论哪个环境，都应该遵循先小规模试用、再逐步扩大的原则。

将实施分成了四个阶段：测试环境体验试行阶段（小规模）、测试环境使用验证阶段（中规模）、测试环境替换实施阶段（大规模）、生产环境部署阶段。其中，前三个阶段是针对测试环境，目标是将传统测试环境整体迁移到容器云平台上来，最后一个阶段才轮到生产环境，是仿照测试环境的实施过程对生产环境进行应用迁移。

第一阶段，即小规模的体验试行阶段。选择一个易于管控的测试环境来实施，这套环境中的各项操作最好不那么频繁，同时要相对规范，这样运维对它的可控程度会高一些。在该环境将容器云平台搭建好之后，先在内部小团队的项目上做实验性部署，比如在运维开发团队的项目上测试。在这些项目成功部署和稳定运行一段时间后，再考虑选择重要性较低、影响较小的业务项目，在技术专家的指导下，由业务团队的开发、测试人员共同来试用容器云平台，解决他们的疑问，满足他们的需求。在这个阶段，可以根据试用情况，继续增加不同特点的团队及项目来试用，以确保容器云平台在功能性和易用性上没有大的问题，并且服务能长时间稳定运行。

在第一阶段中，要解决的关键问题包括容器云环境和虚拟机环境的网络互通，以及原有运维流程和使用容器之后新的运维流程之间的衔接等。在具体实施上，采取的策略是：只迁移无状态的应用，数据库及中间件等暂时在虚拟机上保持不动；原来的应用服务器暂时断网隔离、资源不释放，一旦有异常情况也方便随时回切；测试、上线等流程与原来保持一致或者变得更简单，尽量不增加使用者的负担。

第二阶段，就是扩大规模，进行中等规模的测试验证。经过第一阶段的试运行，容器云平台已经比较稳定，可以被业务团队正常使用，项目接入和团队配合上也积累了一定经验，但是规模还不够大，经验还不够多。所以，接下来考虑在第一阶段所选的测试环境中将能接入容器云平台的项目全部接入，并将以前基于虚拟机的发布部署全部切换为基于容器的发布部署。经过一段比较长时间的使用和磨合，待所有人员（包括开发、测试、运维等）都熟悉容器云平台之后，就可以释放掉原来的虚拟机资源，进入下一个实施阶段了。

第三阶段，就是在测试环境大规模地部署实施。最终的效果是，所有测试环境的大部分应用都部署在容器云平台上，原来的虚拟机只会保留小部分，用来部署那些比较难迁移的特殊应用和一些中间件服务，比如数据库、消息队列等。

第四阶段，就是针对生产环境的容器化部署。出于内部规范化和安全方面的需要，生产环境一般要搭建独立的容器云平台，与测试环境完全隔离。生产环境的应用接入，同样也不是一步到位，可以参照之前测试环境的推进策略，先选择一些次要的、影响不大的项目部署试用，待调试完善、长时间稳定运行之后，再逐步替换其他应用。那些不适合容器环境的特殊应用和服务，一般仍保持原样，不做迁移。