容器技术一线专家实践经验谈

随着国内越来越多的企业在生产环境中使用容器技术，在技术选型和问题处理上，他们的经验分享会对更多的公司和开发者起到借鉴作用，为了在应用过程中尽量避免踩坑，在 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 容器大会官网，查看讲师们的讲义，或者后续观看讲师们的演讲视频。