随着国内越来越多的企业在生产环境中使用容器技术，在技术选型和问题处理上，他们的经验分享会对更多的公司和开发者起到借鉴作用，为了在应用过程中尽量避免踩坑，在9月9-10号由InfoQ主办的CNUTCon 2016容器大会上（可下载讲义），我们邀请了多位来自该领域经多见广的讲师，分享他们在容器实践过程中遇到的坑以及解决方案。

讲师阵容包括才云科技CTO邓德源、好雨云联合创始人周悦秋、DaoCloud联合创始人兼CEO陈齐彦、轻元科技首席架构师王昕、时速云联合创始人CTO王磊、博云CTO李亚琼，和有容云联合创始人兼研发副总裁江松。

基于Kubernetes的容器云平台的落地与实践

在开讲之前，邓德源老师先简单介绍了 Kubernetes 里的组件 master 和 node，此外内容主要分为三大部分：外部访问问题，日志收集和集群升级。

外部访问大家应该非常清晰，主机节点端口利用主机提供外部访问，在不同的节点上运行几个容器，这几个容器组成了一个 server，在不同的跨主机组成了一个 server，将它定义为一个 node pod，定义好之后就可以把端口打开，如果收到一个端口是31080的 TCP 请求，这就是实现的一个类似于虚拟 IP 的功能，如果主机节点 server 不利用主机节点就是一个虚拟的 IP。

采集目录文件采用 sidecar，那么 sidecar 如何知道从何处采集日志？邓老师给出的答案是从环境变量 FILES_TO_COLLECT 获得数据。但是如何确保日志 tag 完整性？从以下三点确保完整性：

• 通过 downward API 注入环境变量 POD_NAME, POD_NAMESPACE。
• 注入固定的环境变量 CONTAINER_NAMES。
• 通过 FILES_TO_COLLECT tag 产生日志的源文件。

如何确保多个容器写入相同的路径不冲突？sidecar中mount 路径以容器名作为命名空间，例如：container1 -> /var/log/log.log, container2 -> /var/log/log.log；sidecar -> /mnt/container{1,2}/var/log/log.log。sidecar 资源消耗如何管理呢，其实根据经验，需要分配大约0.1核，128M 内存资源，根据日志量大小调整。

对于集群升级这一点，邓老师说有如下几个方案：1. 删除重来。2. rolling update 节点。3. partially self hosted。4. fully self hosted。

基于容器技术的平台化 SaaS 软件的设计与实践

周悦秋老师分享的内容分为四部分：软件的发展、平台化 SaaS 软件设计思路、技术架构和技术问题及解决方案。

可能大家觉平台化 SaaS 软件看似很不错，可是平台化 SaaS 软件如何设计和思考呢？平台化 SaaS 软件主要有两点，一个是平台，另一个是软件，平台是支撑层，软件作为应用层，它们加起来就等于平台化的一个 SaaS 软件。

容器化平台的设计原则有三点，一个是基于容器的技术，隔离、封装、微服务、快速伸缩的性质。第二是支持容器高可用机制。第三支持持续集成和发布机制。它的技术架构如下图，最底层的是 IaaS 和虚拟机，这是平台实现的功能，比如运维平台，应用管理平台，自动构建之类的，但是这里边又提到了一个 Kubernetes，上面暴露的是一个对应用层的负载均衡。这个是平台的部署结构，平台部署分三类，最下层算是计算层，就是真实的一些计算资源，包括虚拟机、服务器，这是一层分布式的存储，再上边是集群的管理。最后这层是计算节点，就是真正跑业务的一些机器，最后是负载均衡。

在实施这个项目的时候遇到一些日志处理、持久化存储、资源控制、监控问题如何解决呢？

日志处理确实是一个比较麻烦的问题，周老师说他们是通过自己写了一个扩展，这个扩展是基于 Docker，没有把容器的日志以文件的形式处理，而是将容器里面的日志以 ZMQ 库，以 pub/sub 的形式送到容器处理中心。关于持久化存储问题主要有两种方案，第一种是共享，比如用 NFFS 的协议去做的，NFFS 支持两种，一个 CEPH FS，还有一个 Gluste rFS。关于资源控制，资源控制主要是硬件资源和应用层，控制公共存储资源。

基于 Kubernetes 的模板化应用编辑

为什么会有应用模板的要求呢？王昕老师说，因为容器技术火爆以来，基于微服务的架构的应用也火爆了起来。那么 Kubernetes 的应用模型包含哪些东西呢？

• 微服务实例（微服务豆荚）Pod，其中包括一个或多个容器，多个容器共享一个文件系统，多个容器共享一个网络地址和端口空间，微服务的原子实例，服务伸缩的原子粒度。
• 微服务复制控制器 RC——Replication Controller，主要作用是控制运行同样的 Pod 的数量；提供高可用能力；保证运行的数量：多退少补。
• 微服务的逻辑资源——Service：作为访问微服务的统一入口；对应多个后端 Pod；有一个虚拟 IP: ServiceIP or ClusterIP；CusterIP 只在集群内可见；Service 到Pod 的负载均衡转发由 Kube-proxy 完成；Kube-proxy 运行在每个 Node 上。
• 微服务部署和副本集——Deployment & ReplicaSet (RS)：RS 是下一代 RC，推荐的，支持更多 Selector；Deployment 是 Pod 和 RS 的更新 Transaction，类似于 Transaction 之于 Finance Account；滚动升级，灰度发布，都会用到 Deployment；对应12 factors 的 Deployment。
• 微服务的对外发布——服务入口 Ingress：集群外数据流集群内数据流的映射；协议层——可以是7层（默认 HTTP）或4层负载均衡；对接方式有两种，一是集群外主机有个集群内 IP：例如 LoadBalance+nodePort；二是集群内主机有个集群外 IP：例如给集群内节点分配 Floating IP。

应用模版系统架构组成部分有这些：1. Template Repository－发布存储模板的 HTTP 服务。2. CLI－管理模板和部署应用的命令行。3. Web GUI－管理模板和部署应用的 Web 界面。4. Release Manager－工作在 K8s 集群中；将环境配置与模板集成；部署和管理应用。

最后，关于应用模版的部署问题，王老师做了这样的总结：

• 同一模板，多次应用部署：同一模板可以在多个隔离的 Namespace 部署同名应用；同一模板可以在同一Namespace 部署不同名的 Release；模板更新可以触发同一 Release 的更新。
• 同一模板，部署在多个 Namespace：不同 Namespace，Release 名相同；不同的应用实例，配置一致，彼此隔离；可以分别用于开发、测试、模拟和生产环境。
• 同一模板，部署在同一 Namespace，不同 Release：同一 Namespace，Release 名不同；配置不同，用于不同应用服务。
• 同一模板，同一 Release，模板更新触发应用更新：同一 Namespace，Release 名相同: release=MySQL；模版更新触发服务 MySQL 的滚动升级。

面向容器平台的存储系统

江松老师做IT技术已有20年经验了，很早的时候做嵌入式，后来做系统，也涉及到云计算。本次演讲方向是面向容器平台的存储系统，容器平台的存储相对于传统存储之挑战有哪些呢？首先容器是轻量级的，而且容器时刻在迁移的，非常灵活，这就要求更快的创建删除速度，和更好的支持容器迁移。存储不在是云平台下的单一系统。 支持不同的容器调度平台元数据服务，从单向访问到多向访问。丰富的 API 接口，全开放的资源能力控制。然而，传统的存储系统创建删除往往需要更多时间初始化，也没有全局元数据管理支持容器迁移。

那么实现容器存储的理想特征有哪些呢？

• 容器存储原生方案：容器数据持久化；支持容器迁移与调度；快速创建容器存储卷；高并发容器存储访问。
• 存储系统应用感知：存储 QoS 支持多种应用；根据应用场景进行调度策略配置；不同权限容器卷保证数据安全访问；管理结点高可用。
• 企业级容器存储：数据多副本保障数据高可用；容器卷快照，支持数据备份；支持容器卷精简配置；独立万兆存储网络高性能部署。
• 支持第三方存储系统：支持 Ceph；支持 GlusterFS；支持 NFS；支持 iSCSI SAN。

关于实现容器存储的方式，江老师以 Comet 为例：

• 一种实现方式 Comet–原生 Docker 支持：通过Docker–volumedriver 指定 volume plugin；通过 volume plugin 进行创建/删除/挂载/卸载；将设备挂载在主机上；容器读写卷。
• 一种实现方式 Comet – 全局命名空间和多种存储后端：全局命名空间和元数据服务；支持多种存储后端；CLI and restful API。
• 一种实现方式 Comet – 应用感知和资源调度：容器卷可自定义副本数；容器卷自定义磁盘类型；容器卷自定义强弱一致性；副本尽量分布原则；最近节点优先访问原则。

由于受到篇幅限制，这里只介绍了部分演讲内容，更多细节上的内容，读者可以访问CNUTCon 2016容器大会官网，查看讲师们的讲义，或者后续观看讲师们的演讲视频。