本文讲的是DockOne微信分享( 一零一）：构建容器服务平台（CaaS）【编者的话】容器技术作为这两年最令人瞩目的技术，在各个行业无论是互联网还是传统行业都得到广大的应用。作为致力于打造金融行业领先的平安云，于今年引进容器技术，研发平安云容器服务平台，吧容器技术应用到业务中，推动业务和技术快速发展。本次分享的核心内容即是从用户 痛点及特征分析想如何构建平安云容器平台。分为4个部分：
- 容器平台定位
- 容器平台设计
- 容器平台架构
- 容器平台设计技术
一、定位
用户
首先平安集团旗下的子公司包含了金融行业各个类别，每个子公司有自己的开发模式，对底层计算资源的需求也各有不同。
对做平台来说，所有需求都是合理的，因此平安云为用户提供不同类型的计算资源。
在提供容器之前，云平台已经存储云主机、云存储，现在云平台将提供容器服务。
定位
因此我们将容器定义为虚拟机式的容器服务。提供符合平安基础架构，用户自助服务的容器服务。
计算服务“三剑客”，满足不同种类的计算需求：物理机+虚拟机+容器
容器入伍作为一种轻量、便捷的计算方式，需要发展其长处。
二、平台的设计
平台建设
1、面向多租户
“内部公有云”，需要满足多租户安全隔离的需求，有足够的权限控制
支持多种计算方式互联互通
2、融合用户体验
- 符合云服务的特征，简化交付流程
- 兼顾用户使用习惯和既有的流程
- 汲取容器的优势进行微创新
下面是我的产品：
平台设计-概念模型
- 租户：对应云门户的租户概念，可以理解为一个部门，或者一个产品开发组。
- 环境：即容器运行的载体，环境中包含若干台主机，环境内的主机共同承担容器的运行。
- 主机：只能属于某个指定的环境，不能跨环境部署。
- 应用：与系统概念相似，对应容器的stack概念
- 编排：即Docker Compose
- 服务：即Docker Service
- 容器：即Docker Container
- 镜像：即Docker Image
平台设计-平台功能
1、 容器环境
租户在一个数据中心拥有一套单独容器服务
用户可以根据需求创建多套容器环境，并将自己的计算节点添加到环境中，实现底层资源的弹性扩容。
环境之间资源、服务等完全隔离，仅在管理态存在关联。
2、应用
支持Docker Compose V1编排方式创建。
提供常见的编排方案，一键式部署应用，应用和编排相互转，个人编排发布到应用商城。
3、服务
支持服务连接、端口映射、环境变量、目录挂载等多种策略等配置。
详细的服务管理：服务信息、服务事件、服务配置。
支持shell、文件上传、镜像制作等扩展功能。
4、镜像管理
镜像商城：提供多种官方镜像，所有租户均可使用。
公共仓库：每个租户拥有自己的公共仓库，租户内用户共享租户内镜像.
个人镜像：支持将容器提交成镜像，下载官方和公开镜像.
支持多区域分布式镜像管理。
上述是我们针对容器领域提供的四大功能。
三、容器部署架构
先整体看我们目前的平台系统架构：
其中上述的各个区是公司针对金融行业所架设的网络架构。
具体考虑如下：
首先，门户部署在云管区中，保证所有租户都能通过门户使用容器服务。
另外，我们的镜像商城也部署在云管区中。
在每个数据中心的都部署一套或者多套容器编排调度系统，针对不同区域和用户需求。
如在开发区域，我们提供一套编排系统，所有租户使用一套容器服务。
而在生产环境，我们会为每个租户搭建一套编排系统，这样租户之间完全隔离。
另外容器平台会和监控平台以及配置管理中心对接。
其中上述的各个区是平安云正对金融行业所架设的网络架构。
介绍完部署组件，再详细介绍每个组件的功能以及使用到的技术。
云管区（对外）
- CaaS Portal 是我们核心，也是用户直接接触的界面。具体介绍就是前一章的功能介绍的界面。
CaaS Portal 后台数据库我们采用mysql集群，使用的Galera Cluster集群技术。
- Pub Hub是我们为平安用户搭建的镜像商城，由于网络以及规范原因，我们采取自行搭建镜像hub。将Docker hub最主要的镜像下载到商城中。
公共服务区（云平台资源区，对内）
- Docker Server：我们在remote docker api的基础上封装了一套java实现的docker api，并将它作为docker server agent部署。
用于执行Docker命令，比如提交镜像为容器，获取镜像数据。
- 编排：我们采用开源容器编排平台rancher，通过调用api方式管理容器。
- Registry Mirror：为了不让租户VPC下的所有docker host一起访问Pub Hub，也减少网络之间的传输以及安全。
我们在每个数据中心搭建了一套Registry，与Pub Hub通信。当用户需要创建容器后。
另外我们配置工具采用Ansible，该工具主要到docker host上执行相应命令。例如将vm变成docker host，并且添加到环境里。
我们将Ansible包装成restful。
四、容器平台技术
整体的架构分享完毕，后面针对容器服务所涉及的技术以及我们的方案进行介绍。
容器领域所涉及的技术包括：
- 容器网络
- 容器存储
- 容器日志
- 容器监控
- 镜像管理
整个容器技术也就这5大块：
容器网络
先介绍容器网络历史，我将容器忘了的发展分为3个阶段：
第一阶段：
容器最早的网络模型，提供了4种方式。bridge桥接模式，即使用主机IP，而将容器端口映射到主机的端口中。缺点在于端口大量使用会导致冲突。
host方式：使用host ip，缺点就是一个容器使用了某个端口后，其他容器再也不能使用该端口。
Container方式：即和主机上的其他容器共享网络。
none方式：不设置网络，需要手工配置、
第二阶段：
为了解决上述问题，涌现了很多方案，比较有名的就下面三种，这三总都是为了解决跨主机通讯，最大程度弥补容器本身的网络模型缺点。
从技术层面讲，这些容器技术可以归为两个技术流派：隧道模式和路由模式。
IPSec，Fannel属于隧道模式，而calico属于路由模式。
第三阶段：
后来Docker公司和Google公司分别为自己的容器网络模型指定标准。
其中Docker公司推出的标准是CNI，可以通过docker命令直接管理网络模型。
介绍完网络知识，我们看看CaaS选择网络。
对外：Container Bridge，采用端口映射
对内：容器之间采用实现的IPsec隧道实现（直接使用编排框架Rancher自带的）
如果某个容器需要对外服务，则采用端口映射方式，连通所在vm，就可以暴露服务。
如果容器不需要对外提供服务，只需要在同个应用内提供服务，那么采用ipsec方式，这样避免浪费过多端口。
容器与容器之间建立私有忘了，只有容器与容器之间可以访问。每个容器都拥有一个私有网络地址：10.42.网段。
下面我是我们通过容器平台创建的一个tomcat容器，同时我将该容器映射到主机上，以便可以从外面访问。
其中，对外的端口占用问题，我们统一分配和回收。
可以看到该容器又主机IP239，以及容器IP10.42.243.155。这里就综合使用的端口银色和ipsec。
容器存储
目标：极快的创建速度，极小的存储资源消耗以及容器迁移的便捷性
技术：分层和写时复制CoW
实现：AUFS，Device Mapper，ZFS，OverlayFS
目前我们容器服务统一运行在CentOS，还没使用其他操作系统。因此我们选择DeviceMapper作为容器存储驱动。
下面是docker官方提供的所有存储驱动的成熟度。可以看到目前比较成熟的是AUFS和DeviceMapper。
目前只有这两个是官方建议的production-ready。我们的容器平台选择DeviceMapper。
Docker存储系统选择发展比较早比较成熟的DeviceMapper，一方面是因为该技术已经纳入linxu内核，稳定成熟，另一方面我们选择VM是CeotOS，其默认使用的是DeviceMapper。
DeviceMapper底层直接使用云磁盘作为pool，采用LVM管理。
除了容器和镜像存储外，另外一块存储是大家所忽视的：应用数据存储，包括配置文件，我们的方案是：采用了volume接口或者直接volume映射
这样解决容器可以自动迁移。
日志
- 容器服务平台日志：本地+云平台ELK日志服务
- 容器自身运行日志：本地云磁盘+云平台ELK日志服务
- 容器内应用（业务方）日志：业务自行规划，已经提供目录挂载
容器监控
这块监控，我们依赖于云平台原有 监控，另外补充了针对容器特有的监控。
1、主机监控
2、容器监控
自研发脚本，提供容器本身的性能监控(cpu/mem/network/storage)，监控平台定时获取，同时，能够在portal上查看。
3、特定的中间件监控
提供常见中间件的性能监控（WebLogic/Tomcat/Nginx等），为中间件镜像制作脚本，中间件监控程序整合到Docker镜像中，容器一启动，就能即时上报性能数据到监控平台，无需任何外部干预。该监控能够到监控平台查看。
监控平台是由本部门另外团队研发。目前采用zabbix/open-falcon。
镜像管理
针对镜像管理，我们从单节点->双节点->跨区域分布式进行演进。
1、镜像管理使用Distribution，前端设置LVS+Keepalived作负载均衡和高可用，镜像存储采用DNAS。
2、Docker Server是我们自行开发的服务组件，每个区域（例如深圳、上海）都部署一套，对接本区域的Registry。一方面监听当前区域的registry事件，然后主动发起同步操作。另一方面：执行Dockcer命令，管理该区域的所有运行容器的机器。
该功能近期才刚刚完成。关于跨区域分布式镜像管理，基本只有三种方式：
- 主动执行同步，比如调用docker remote api，执行docker push /docker pull。
- 事件监听，采用registry的notification监听。
- 底层存储同步。
我们综合三种方案，结合实际，采用的第1和第2中方案。
Q&A
Q：跨区域的容器集群间是否能通信？
A：目前跨区域机器不能通讯。跨区域之间机器是租户完全隔离。如果租户需要通讯，需要针对具体机器进行开墙。
Q：请问使用DeviceMapper其中遇到了那些问题？
A：最常遇到的是device busy。会导致容器无法删除。此时需要人工干预。
Q：镜像管理如果只是基于distribution的话，权限与多租户管理是如何实现的？
A：权限纳入平台管理，由我们自行实现。租户之间的镜像不可共享。租户内的可共享和私有。
租户间的镜像必须通过发布，由平台审核方能在各个区域和各个租户间共享。
Q：监控是用什么语言开发的，是自主开发还是用开源的？
A：监控，我这边针对镜像和容器这块做了一些监控数据的收集，然后提供给监控平台。监控平台由部门另外一组开发。目前基于Zabbix进行开发。
Q：请问：1. DockerHUB只有一个实例吗？如何保证高可用？2. Docker Server间同步的是什么内容呢？Docker事件？
A：所有区域，包括pub和mirror，都是keepalive+lvs搭建。目前使用双registry+共享nas。而这两个Registry所在的vm是跨az。也就是一个Registry宕完全不影响另外一个提供。而nas是双写nas，我们这边的存储组提供的DNAS服务。备份策略也是可以根据自己定义。
Q：pub hub获取docker hub 镜像的方式，目前是自动维护吗？
A：不是，从docker hub进入公司官方镜像仓库，都是人工维护同步。我们需要针对一些镜像做特殊处理。
Q：IPsec的性能传说不是很好，你们有遇到过网络的问题吗？Rancher 的IPsec网络性能怎么样？容器有涉及到弹性伸缩吗？容器间采用Rancher 实现网络通信，为什么没有选择类似组件？
A：这3个问题统一回答。目前是使用IPsec。由于当前每个Rancher对接的容器数目不是特别大，还没产生网络问题。另外对外网络走的是云主机网络。
有考虑过其他组件，由于之前起步阶段，所有直接采取rancher提供的。最近Rancher提供支持CNI的方案。目前正在研究对应的组件。
Q：我能想到的一个方案是自己的用户体系加云平台的租户和云平台的用户体系，多对1的映射，当审核通过后，使用不同的云平台用户，这样权限就不一样了。是这样吗？
A：目前容器服务只针对公司内部开放，直接兼容云平台租户。
Q：请问内核版本是？用4.9的计划吗？平安云是OpenStack吗？用Magnum吗？
A：使用CentOS 7.2，内核版本是3.10.xxx,平安云使用Cloud Foundry，平安云使用了多种虚拟机，VMware和KVM是主要。
Q：容器是跑在物理机上还是虚拟机上，容器所在的操作系统归租户所有还是运营商所有？容器的分配规则由谁决定？一个宿主机跑多少个容器由谁决定？
A：目前资源限制还是交给Rancher来管理，我们对Rancher的规划是：让Rancher管理资源，分配容器。在页面提供Docker目前支持的资源参数。
容器所在的操作系统归租户所有。租户可以任意添加自己的云主机到容器华环境中。
Q：目前这个系统是内部用的吧？安全性有没有考虑？
A：安全：目前针对公司内部，使用公司AD认证登录。而计算资源限制采用租户隔离。镜像这块安全采用主机互信。
Q：很多业务日志是不直接输出到stdout 的，这些业务日志如何搜集？容器日志的采集采用什么方式？容器规模大约有多大呢？当采集方出现采集中断的时候会有报警提示吗？打入到es后，做了哪些比较有效的报表数据呢？
A ：日志需要分为三种：
容器服务平台日志：本地+云平台ELK日志服务
容器自身运行日志：本地云磁盘+云平台ELK日志服务
容器内应用日志：业务自行规划，已经提供目录挂载
平台这边目前集中负责前两个日志。
日志这块也会根据重要程度选择上报告警。
业务日志：我们提供方案。
针对业务方的日志管理：需要帮助业务方将系统容器化，其中一个重要的方面就是日志管理。
目前采用方案：让业务方将日志容器化，这样日志不会打在容器本身的所在的机器上。
以上内容根据2016年12月27日晚微信群分享内容整理。分享人朱玉华，平安科技云平台事业部容器服务平台负责人。14年入职平安，先后担任平安科技架构师软对应用架构师，云平台自身开发工程师，目前负责容器服务平台的架构设计。 DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesz，进群参与，您有想听的话题或者想分享的话题都可以给我们留言。
原文发布时间为：2017-01-03
本文作者：朱玉华
原文标题：DockOne微信分享( 一零一）：构建容器服务平台（CaaS）