孙洁:“集装箱技术在企业落地的探索与实践”

本篇文章8613字，读完约22分钟

孙洁:“集装箱技术在企业落地的探索与实践” 如今，容器技术受到广泛关注，越来越多的企业开始规划或采用容器技术来构建自己的云基础设施。为了以正确的姿势拥抱容器，更好地使用容器，企业需要了解容器的相关特性和功能，以便更好地为企业服务。这是企业在实现容器平台时必须考虑的。集装箱在企业的落地不是一蹴而就的，而是一个渐进的增值过程。 近年来，开源技术逐渐成为云计算发展的重要支撑和导向。它改变了以往信息技术的演进模式，引领了软件技术标准的发展和创新，深刻影响了整个信息技术产业的发展模式。为了进一步探索我国云计算开源技术的发展模式，加快云计算与各行业的深度融合，更好地发挥云计算在经济社会创新发展中的支撑和引领作用，促进我国云计算产业快速健康发展。

由中国信息通信研究院主办、中国通信标准协会支持的“奥斯卡”将于2018年3月21日至22日在国家会议中心举行。在22日下午举行的工业应用开源论坛上，北京钟繇瑞飞信息技术有限公司高级建筑师孙洁发表了题为“集装箱技术落地企业的探索与实践”的演讲！

以下是这次演讲的文字记录:

孙洁:如今，集装箱技术受到广泛关注，越来越多的企业开始规划或采用集装箱技术来构建自己的云基础设施。与互联网企业相比，许多传统行业在集装箱技术方面起步较晚。然而，在过去的两年中，随着对集装箱的关注度达到0+，企业取得了快速的进步，并大力推进了集装箱相关能力的建设。基于Docker的容器是一种较轻的虚拟化。我们称之为CaaS，这是一种容器级服务。它涵盖了IaaS和PaaS的优点，可以解决应用程序部署、开发、操作和维护以及微服务等问题，并可以加快业务交付速度。集装箱可以说是一项先进的技术，但是如何将其转化为先进的生产力，企业能否很好的利用这项技术，如何很好的利用它，大约有九个问题，这也是我们长期的思考和探索实践。

为了以正确的姿势拥抱容器并很好地使用它，企业在应用容器技术时需要考虑以下九个关键问题:

1.企业容器云设计应该遵循什么原则？

2.如何选择集装箱云技术产品？

3.集装箱云网络应该如何设计？

4.如何选择和设计容器的持久存储方案？

5.如何设计集装箱云日志的集中管理？

6.如何设计集装箱应用的监控方案？

7.如何为容器云设计多租户和权限？

8.容器与OpenStack和Kubernetes集成的能力？

9.集装箱云如何实现高可用性和跨区域部署？

因此，首先，第一个问题:企业容器云设计应该遵循什么原则？

首先，我们需要明确容器云在企业中的用途。集装箱服务于商业。任何技术都是为了更好地服务于商业。这是我们的起点。其次，根据业务的特点选择合适的容器框架，比如我们的业务本身是否可以基于新的微服务架构进行改造，业务是否具有变化快、灵活性大、更新迭代快等特点。还需要与现有系统进行更好的对接和集成。在装载集装箱之前，企业通常拥有其他成熟稳定的信息技术系统，如网络系统、集中监控系统、安全防护系统等。

为了避免重复构建，并使容器平台更易于接受和使用，容器平台应该集成到企业原有的整个信息技术系统中，而不是从新的起点重新构建。为了开展生产业务，容器平台还需要满足安全法规遵从性要求，如隔离不同安全级别的应用程序，支持应用程序容器的安全漏洞扫描，以及安全有效的防火墙策略管理。生产环境的业务需要高可用性和连续性，还应考虑整个容器应用程序级别的高可用性和数据连续性、安全性和可靠性。

构建容器平台的目的是为应用程序带来灵活性、灵活性、资源节约等优势，这就要求应用程序具有微服务架构、无状态等特点，以便更好地发挥这些优势。然而，不适合集装箱化的应用不能被强制。否则，集装箱平台建成后，如果不能给应用和业务带来预期的价值，不仅会浪费大量的企业投资，还会使集装箱平台的价值得不到认可。这是每个在构建集装箱平台上投入大量精力和热情的人最不愿意看到的结果。

我不会重复容器本身的特点和优点。每个人都清楚地知道，一个容器成本低、重量轻、易于迁移并且启动非常快。它可以直接构建在物理主机的操作系统上，就像以前的虚拟化可能需要多一层，然后您的虚拟机的操作系统会在此之上。将容器和虚拟机占用的CPU资源进行比较，Docker约占1.6%，KVM约占14.6%，内存资源被占用。码头工人平均每个集装箱只占用46兆字节，KVM基本上是185兆字节。在相同的规格下，Docker的性能是您的KVM的两倍。Docker的镜像非常小，而虚拟机的镜像基本上是3G、4G，甚至是5G、6G，如窗口。通过这种方式，容器可以相对节省大量资源并提高性能。

集装箱技术的应用带来的挑战和变化是有目共睹的。首先，它可以通过镜像直接封装您的应用程序。它可以根据您的dockerfile命令行直接构建您需要的应用程序，提供一个相对广泛接受的交付协议。其次，资源提供商可以不加区别地对待您的资源需求，为构建统一的IT支持平台提供了可行性。此外，R&D过程自动化(CI)、应用建模(微服务、灵活性)、标准化和自动化都可以更快地响应业务变化。

容器面临的主要挑战是平台可以产生效益，但是标准并不统一。还需要入侵平台的应用程序结构。大量的传统应用遗产需要更新，这消耗了大量的人力和资源。

第二，如何选择集装箱云技术产品的类型？有许多复杂的因素影响着技术的选择，包括技术和非技术方面，不同的组织情况也是不同的。

在企业应用新技术之前，信息技术还需要考虑自身的技术能力，包括开发能力、操作和维护能力，以及从开发平台、开发过程、开发规范等方面确定自身业务系统的能力。如果企业自身的开发和运营能力不强，采用成熟的方案如PCF和OpenShift是一个不错的选择。如果考虑现有系统的对接要求，包括监控、网络、安全要求等。，尤其是当现有的网络架构对容器的网络方案有较大影响时，开源方案如Kubernetes、Mesos、Swarm等。应被视为更便于定制和更好地集成到现有的信息技术系统中。

Kubernetes、Mesos和Swarm是业界相对热门的三种开源解决方案。然而，他们各自的观点是不同的。从应用程序发布的角度来看，很难直接确定Docker的群功能、Kubenetes安排和Mesos调度管理之间的区别。换句话说，添加企业应用程序场景来帮助选择容器技术会更有意义。

企业规模不大，应用也不太复杂。

此时，码头工人群体模式仍然相对容易使用。集群的维护不需要动物园管理员。Etcd是内置的。命令行和码头工人一样方便。服务发现和域名系统是内置的。覆盖网络是内置的。

企业的规模更大，应用程序也足够复杂。

此时，集群规模有几百个节点，所以许多人不想使用多克虫群模式，而是使用介子和马拉松。因为Mesos是一个非常优秀的调度器，它的双层调度机制可以使集群规模更大。Mesos的优势在于，第一层调度将整个节点分配给一个框架，而框架的调度器面向更小的集群规模，然后在其中执行二次调度。如果有多个框架，如多个马拉松，并行调度是不冲突的，并且Mesos在传统数据计算中有许多情况，这被认为是企业选择中考虑的因素之一。

企业规模大，业务复杂，应用粒度更细。

Kubenetes现在更合适，因为Kuberntes模块比Marathon和Mesos更细分，功能更多，并且模块完全松散耦合，可以非常方便地定制。另一方面，Kubernetes提供了强大的自动化机制，大大降低了后期系统运行和维护的难度和成本。此外，Kubernetes社区的流行可以使使用Kubernetes的公司快速获得帮助，并促进问题和错误的解决。

第三个问题是关于集装箱云的网络设计。这是关键。因为每个人都知道容器最初是基于单个主机设计的。当集装箱技术逐渐成熟时，Socketplane，一家网络解决方案公司，被收购了。原来的网络部分被分离，成为doc的网络libnetwork。用户可以根据自己的需求通过插件实现网络驱动。然而，libnetwork组件只是将doc平台中的网络子系统模块化成一个独立库的简单尝试，离成熟和完善还有很长的路要走。

随着容器技术在企业生产系统中的逐步实施，用户对容器云的网络特性要求越来越高，跨主机容器的网络互通已经成为最基本的要求。跨主机的容器网络解决方案分为三大类:

隧道方案

例如，法兰绒的VxLan的特点是对底层网络没有高要求。一般来说，构建基于隧道的集装箱网络是可能的，只要它在三层可达网络中是可达的。然而，问题也很明显。人们普遍认为，随着节点大小的增加，复杂性会增加，跟踪网络问题会更加麻烦。在大规模集群的情况下，这是需要考虑的一点。

路由方案

路由技术从三个层次实现主机间容器的互通，没有网络地址转换，效率较高，可以与当前网络集成，每个容器可以像虚拟机一样分配服务的IP。但是，路由网络也存在问题，路由网络对现有网络设备有很大影响，路由器的路由表应该有一个空的限制，一般在20，000到30，000之间，并且大多数应用场景的容器都运行微服务，有大量的集合。如果成千上万个新容器的IP影响到路由表，底层物理设备将无法承受。此外，每个容器都被分配了一个服务IP，它将被快速使用。

虚拟局域网

所有的集装箱和物理机器都在同一个VLAN。

总的来说，Calico的解决方案和基于HOST的网络解决方案具有更好的性能。然而，基于主机的端口冲突和对网络资源的竞争更加麻烦。Calico是一个纯三层SDN实现。它基于BPG协议和Linux自身的路由转发机制，不依赖于特殊的硬件，也不使用NAT或隧道等技术。它可以方便地部署在物理服务器、虚拟机(如OpenStack)或容器环境中。同时，它自己的基于Iptables的ACL管理组件非常灵活，可以满足更复杂的企业安全隔离需求。容器应用程序的网络隔离有许多解决方案。基本上，不同的应用程序容器被放置在不同的虚拟局域网/VX局域网中，并且通过防止不同的虚拟局域网/VX局域网之间的交换访问来实现隔离。目前，OVS/Linux-bridge +VLAN方案在企业中得到广泛应用，但从长远来看，Calico方案具有良好的前景。

第四个问题是如何设计容器的持久存储。在讨论持久存储之前，让我们先声明运行一个容器并不意味着完全放弃数据持久化。对于在容器中运行的应用程序，应用程序真正需要保存的数据也可以写入持久卷数据卷。在这个方案中，持久层不是通过弹性而是通过灵活的可编程性来产生价值，例如通过设计良好的API来扩展存储。目前，卷。主要支持Docker或Kubernetes的Docker发布了一个容器卷插件规范，允许第三方供应商的数据卷在Docker引擎中提供数据服务。这种机制意味着外部存储可以在容器的生命周期之外独立存在，并且各种存储设备可以连接到码头集装箱的操作平台，只要它们满足接口API标准。现有存储可以通过简单的驱动程序打包，从而实现与Docker容器的对接。另一个是K8S数据量。K8S的每个吊舱包含一个或多个容器。Pod可以部署在集群的任何节点上，存储设备可以通过数据卷提供给Pod的容器。为了不束缚特定的容器技术，K8S没有使用Docker的卷机制，而是开发了自己的通用数据卷插件规范来配合不同的容器操作(如Docker和rkt)。数据卷分为共享和非共享类型，其中非共享类型只能由某个节点安装和使用(例如网络块设备，如iSCSI、AWS EBS等)。)；共享类型允许同时使用不同节点上的多个PODs(例如，网络文件系统，如NFS和GlusterFS，以及可以支持多方读写的块设备)。对于有状态应用程序，共享卷存储可以轻松支持集群中节点之间的容器迁移。为了给容器提供更细粒度的卷管理，K8s增加了持久卷的功能，并使用外部存储作为资源池，由平台管理并提供给整个集群使用。K8S的卷管理体系结构使用标准的存储访问方法，并通过接口公开存储设备支持的功能，从而实现容器任务调度等方面的自动化管理。

从2017年3月1日开始，该容器已经发布了两个版本，一个是Docker's CE，一个是Docker's EE，Docker's EE是企业版或商业版，另一个EE是其社区版或开源版。其CE和EE版本中的数据卷已经可以支持持久存储。

第五题日志的集中管理。容器通常用于运行需要快速故障迁移和弹性扩展的应用程序或微服务。因此，随着容器中运行的应用程序的迁移和弹性伸缩的发生，应用程序日志可能会在不同的运行节点中生成，这给容器应用程序的日志监控和故障排除带来了很大的麻烦。相对而言，与大多数在本地文件系统中写入日志的传统应用程序不同，容器应用程序需要考虑集中收集日志，然后将它们写入外部集中式日志管理系统。传统的日志收集方案主要包括商业软件Splunk、开源软件栈ELK和脸书开源Scribe，其中ELK使用最广泛。典型的ELK架构具有易于构建和使用的优点。它的缺点是日志隐藏消耗大量资源，占用大量的CPU和内存来运行，并且没有消息队列缓存。因此，建议在小规模集群中使用它。如果大规模使用，可以引入Kafka(或Redis)来增加消息队列缓存和平衡网络传输，并且可以将Logstash和Elasticsearch配置为集群模式来降低负载压力。Logstash占用了太多的系统资源，于是引入了Fluent来代替Logstash，在社区方案中称为EFK。与传统的日志收集工具相比，Fluent的日志收集功能更全面地支持容器。

收集集装箱日志时，应注意以下两点:1 .避免写入日志冲突。最简单的方法是让容器在运行时将外部共享存储卷装载为应用程序的日志目录，以便应用程序的日志将被实时写入外部共享存储以供后续处理。这种方法要求我们做好控制工作。不同的容器不能装载相同的外部卷，否则在写入日志时会有冲突，并且在容器迁移时需要重新装载该卷。2.日志标准化不容忽视。当我们使用容器运行微服务架构应用时，一个业务调用往往需要经过多个微服务调用链，整个业务处理过程的日志记录分散在不同的微服务日志中，这给通过日志进行问题诊断带来了极大的不便。通过标准化日志，例如携带唯一的标识信息，可以关联不同微服务中相同服务的处理。通过标准化的应用日志，可以对交易率、成功率、响应时间等关键业务指标进行统一的相关性分析。作为问题预警、诊断分析以及容量扩展和收缩的科学基础。

第六个问题是如何监控集装箱。在虚拟机操作和维护的时代，Nagios和Zabbix是非常经典的性能监控软件。然而，在容器时代，这些曾经熟悉的软件中的大多数都不能提供方便的容器服务监控体验，社区也不积极开发这样的插件和数据收集客户端。相反，许多新的开源监控项目将对容器的支持放在关键特性的位置。新一代取代了老一代。可以说，集装箱的应用定义了监控软件的新时代。在这些新的监测工具中，有三种流行的和成熟的具体方案，即cAdvisor、cAdvisor+InfluxDB+Grafana和Prometheus。其中，基于InfluxDB的方案是多个开源组件的组合方案，而基于Prometheus的方案是一个整体解决方案。与其他特殊的开源组件相比，它收集容器信息和显示图形的能力较弱。它通常被组合成cAdvisor+Prometheus或cAdvisor+Prometheus+ Grafana用于实际实现。然而，它的多维数据模型可以促进数据过滤和聚合。当谈到容器应用程序的监视设计时，这里应该注意监视是分层的，它可以分为系统级、应用程序级和服务级。每个级别都有自己的监控重点。1.在系统级别，它主要旨在监控资源使用、网络连接和节点健康状况。传统的监控系统在这方面已经非常完善。我们可以直接用传统的监控系统在系统级监控集装箱平台的主机，并对接监控大屏幕。主机上的单个容器的性能和资源使用对于外部资源监控几乎没有意义，并且没有必要传输到外部传统监控。2.应用程序级别。容器平台本身通常有一个机制，比如K8S的复制控制，来保持某个服务运行多个实例的能力，因此容器平台通常可以保证应用程序和应用程序下的每个微服务的正常运行。关于应用级的健康监测，仍然需要与传统监测系统接口，并执行适当的警报输出。例如，当应用程序逻辑错误导致多次启动失败或资源不足，导致启动失败时，容器平台本身的复制控制机制无法解决问题。这种情况要求我们将应用故障信息传输到外部监控，并根据问题的严重程度给出不同级别的报警通知。相关应用程序人员将介入解决问题，例如升级补丁或回滚。

3.服务水平。服务级别是监控应用程序提供的服务是否正常运行。例如，虽然应用程序和应用程序中运行的微服务实例的数量是正常的，但在某些情况下，提供网络服务的应用程序会丢失响应或返回不正确的状态，这在大多数容器平台中是无法监控的。传统的方法是使用探测代理，但在集装箱环境下，这种方法不一定可行，这就要求我们丰富集装箱故障的监控手段或编写自己的服务访问+检测逻辑来判断，并将检测问题报告给外部监控，并在监控中设置相应的报警策略和报警级别。

第七个是容器的多租户和许可设计。事实上，集装箱在这里处理得不是很好。例如，如果您为一个容器分配200兆字节的内存，您看到的实际上是物理机器的64gb内存，而不是您实际分配给容器的内存。顾名思义，多租户意味着许多人租用容器云平台的资源来实现他们自己的应用程序托管和操作需求。这主要涉及多租户、资源管理和分配以及安全权限管理。

1.多租户问题。从多租户的角度来看，租户租用集装箱云平台的资源来托管、开发、部署和运营他们自己的应用程序和服务。集装箱云平台需要提供和维护，以确保租户能够正常使用这些资源，同时为租户托管的应用程序提供服务注册、服务发现、服务配置、日志记录、监控、预警、灵活扩展、负载平衡、安全性和其他功能。我们需要理解的是，租户只租用这些功能，而不运营和维护这些功能。租户关注托管的应用程序和服务，他们需要做的是使用平台提供的这些功能无缝地运行和维护他们的应用程序和服务。总而言之，租户只使用/租用资源，而集装箱云平台管理和运营这些资源。租户专注于运营和维护他们自己的应用程序或服务。资源由租户应用，并由容器云平台管理。

2.资源管理和分配。建议运行和维护团队或系统团队负责这部分功能。在应用系统进入云之前，通常会进行压力测量，并且会有一个容量估算过程。通过容量估计和趋势分析，系统人员可以为相关应用程序规划一个粗略的资源池，这通常可以通过划分底层资源池来实现。如果使用K8S，可以通过标签在计算节点上进行规划。此外，需要在布局文件上设置最小和最大资源，以允许应用程序的灵活扩展。

3、安全权限管理。多租户的安全权限设计涉及到整个集装箱云平台的权限控制框架。最好实现一个权限中心，可以实现对容器云的各个组件和各个功能的动态控制，以满足不同灵活场景的需求。

第八个是容器与OpenStack和Kubernetes集成的能力。在开源云计算技术蓬勃发展的年代，OpenStack、Kubernetes和Container无疑成为改变云计算模式的三大关键技术。然而，这三者之间在技术上仍有一个空白:容器在保持其紧凑的尺寸和轻量级的同时以强安全隔离运行，以及它如何能够容易地与OpenStack和Kubernetes的两个平台集成以获得诸如多租户、统一网络和统一存储的许多好处。这空白色阻碍了用户从中获得更多价值。为了解决这个问题，OpenStack基金会在今年12月5日的KubeCon峰会上发布了一个新的开源项目。卡塔集装箱。Kata使用户既能获得虚拟机的安全性，又能快速、轻松地管理容器技术。该项目可以屏蔽硬件差异，并与OCIspeciaification和Kubernetes容器运行时标准兼容。它支持标准图像格式，并具有强大的隔离、轻量级和快速启动功能。毫无疑问，Kata项目的启动为OpenStack、Kubernetes和Container的更好集成提供了强有力的支持，并为用户从中受益铺平了道路。期待集装箱现代人的到来，但任忠的路还很长。

第九个问题是如何实现容器云的高可用性和跨区域部署。容器云需要考虑平台本身的高可用性，以实现多可用性和多部署。容器上应用程序的高可用性需要结合应用程序架构来实现。目前，微服务架构是最适合云基础设施的应用架构之一。微服务应用通过容错设计(如服务注册发现、全局配置管理、融合、服务跟踪等)确保应用的高可用性。灵活扩展，增加微服务运行实例的数量，配合使用负载均衡策略，减少运行实例因压力过大而造成的停机时间。

最后得出结论，集装箱技术在企业的落地不是一蹴而就的，而是一个渐进的增值过程。通常我们听到一个词，也就是说，第一步是成为烈士，前两步是先驱者。任何新技术出现后，不要跑得太快，因为还有许多坑还没有被完全踩过，我们不知道这条路是否能平稳运行。有时候，如果你跑得太快，你就会成为一个先锋。技术的变化可以是一种微妙的和平演变，也可以是一场激烈的武装革命。集装箱技术应该属于前者。我们可以看到，集装箱化技术已经成为计算模型进化的开端。可以预见，经过更高效、更轻量级的平台实践，集装箱化技术将为整个信息技术领域注入更多的新鲜和活力，在未来生存和发展，成为引领潮流的决定性力量！

这就是我要分享的全部，谢谢你！