孙杰：“容器技术在企业落地的探索和实践”

这时 Kubenetes 就更适合了，因为 Kubernetes 模块划分得更细更多，比 Marathon 和 Mesos 功能丰富，而且模块之间完全的松耦合，可以非常方便地进行定制化。还有就是 Kubernetes 提供了强大的自动化机制，从而使后期的系统运维难度和运维成本大幅降低，而且 Kubernetes 社区的热度，可以使得使用 Kubernetes 的公司能够很快地得到帮助，方便问题和 Bug 的解决。

第三个问题，关于容器云的网络设计，这一块是关键。因为大家知道容器它最早是基于单主机这种来设计的。当容器技术逐步成熟之后，收购了一家网络解决方案公司 Socketplane，将原有的网络部分抽离，单独成了 Docker 的网络库，即 libnetwork.libnetwork 实现了 5 种驱动，通过插件的形式允许用户根据自己的需求来实现 network driver，但 libnetwork 组件只是将 Docker 平台中的网络子系统模块化为一个独立库的简单尝试，离成熟和完善还有一段距离。

随着容器技术在企业生产系统的逐步落地，用户对于容器云的网络特性要求也越来越高，跨主机容器间的网络互通已经成为最基本的要求。跨主机的容器网络解决方案不外乎三大类：

隧道方案

比如 Flannel 的 VxLan，特点是对底层的网络没有过高的要求，一般来说只要是三层可达就可以，只要是在一个三层可达网络里，就能构建出一个基于隧道的容器网络。不过问题也很明显，一个得到大家共识的是随着节点规模的增长、复杂度会提升，而且出了网络问题跟踪起来比较麻烦，大规模集群情况下，这是需要考虑的一个点。

路由方案

路由技术从三层实现跨主机容器互通，没有 NAT，效率比较高，和目前的网络能够融合在一起，每一个容器都可以像虚拟机一样分配一个业务的 IP.但路由网络也有问题，路由网络对现有网络设备影响比较大，路由器的路由表应该有空间限制，一般是两三万条，而容器的大部分应用场景是运行微服务，数量集很大。如果几万新的容器 IP 冲击到路由表里，会导致下层的物理设备没办法承受；而且每一个容器都分配一个业务 IP，业务 IP 会很快消耗。

VLAN

所有容器和物理机在同一个 VLAN 中。

综合来看Calico 的方案和基于 HOST 的网络解决方案性能较好。但基于 HOST 的端口冲突和网络资源竞争比较麻烦，相对来说 Calico 的是纯三层的 SDN 实现，它基于 BPG 协议和 Linux 自己的路由转发机制，不依赖特殊硬件，没有使用 NAT 或 Tunnel 等技术。它能够方便的部署在物理服务器、虚拟机（如 OpenStack）或者容器环境下，同时它自带的基于 Iptables 的 ACL 管理组件非常灵活，能够满足比较复杂的企业安全隔离需求。关于容器应用的网络隔离还有多种解决方案，基本上就是把不同的应用容器放置在不同的 vlan/vxlan 中，通过让不同的 vlan/vxlan 不能互访而实现隔离。企业里应用目前是 OVS/Linux-bridge +VLAN 方案的比较多，但长远看来 Calico 方案前景不错。

第四个问题就是容器的持久化存储如何设计？在讨论持久化存储之前，首先声明，运行容器并不意味着完全摒弃数据持久化。在容器中运行的应用，应用真正需要保存的数据，也可以写入持久化的 Volume 数据卷。在这个方案中，持久层产生价值，不是通过弹性，而是通过灵活可编程，例如通过优秀设计的 API 来扩展存储。目前，主要支持 Docker 或 Kubernetes 的 Volume.Docker 发布了容器卷插件规范，允许第三方厂商的数据卷在 Docker 引擎中提供数据服务。这种机制意味着外置存储可以超过容器的生命周期而独立存在，而且各种存储设备只要满足接口 API 标准，就可接入 Docker 容器的运行平台中。现有的各种存储可以通过简单的驱动程序封装，从而实现和 Docker 容器的对接。另外一个就是K8S 的数据卷。K8S 的每个 Pod 包含一个或多个容器。Pod 可部署在集群的任意节点中，存储设备可通过数据卷提供给 Pod 的容器使用。为了不绑定特定的容器技术，K8S 没有使用 Docker 的 Volume 机制，而是制定了自己的通用数据卷插件规范，以配合不同的容器运行来使用（如 Docker 和 rkt）。数据卷分为共享和非共享两种类型，其中非共享型只能被某个节点挂载使用（如 iSCSI、AWS EBS 等网络块设备）；共享型则可让不同节点上的多个 Pod 同时使用（如 NFS、GlusterFS 等网络文件系统，以及可支持多方读写的块设备）。对有状态的应用来说，共享型的卷存储能够很方便地支持容器在集群各节点之间的迁移。为了给容器提供更细粒度的卷管理，K8s 增加了持久化卷的功能，把外置存储作为资源池，由平台管理并提供给整个集群使用。K8S 的卷管理架构使用存储可用标准的接入方式，并且通过接口暴露存储设备所支持的能力，在容器任务调度等方面实现了自动化管理。

从2017年3月1号开始，容器出了两个版本，一个是Docker的CE，一个是Docker的EE，Docker的EE是企业版，也可以说是商业版，另外一个EE是它的社区版，也就是开源版。它的CE和EE版里的数据卷都已经可以支持持久化的存储了。

第5个问题日志的集中管理。容器常被用来运行需要快速故障迁移、弹性伸缩的应用或微服务，因此容器中运行的应用随着迁移、弹性伸缩的发生，应用日志很可能会在不同的运行节点中产生，这对容器应用的日志监控和问题排查带来了很大的麻烦。相对来说，和大多数传统应用把日志写在本地文件系统不同的是，容器应用需要考虑把日志进行集中收集，然后写入外部的集中日志管理系统中。传统的日志汇总收集方案主要有商业软件 Splunk、开源软件栈 ELK 和 Facebook 开源的 Scribe 等，其中以 ELK 最为广泛使用。典型的 ELK 架构，优点是搭建简单、易于上手，缺点是 Logstash 耗费资源较大，运行占用 CPU 和内存高，另外没有消息队列缓存，存在数据丢失隐患，建议小规模集群使用。如果大规模使用，则可以引入 Kafka（或者 Redis），增加消息队列缓存，均衡网络传输，再把 Logstash 和 Elasticsearch 配置为集群模式，以减轻负荷压力。Logstash 占用系统资源过多，后来又有了 Fluentd，替代了 Logstash，被称作是社区方案中的 EFK，相比 Logstash 等传统日志收集工具，Fluentd 的日志收集功能对容器支持的更加完备。

（编辑：辽源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!