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