1、前言

1.1、cinder、glance简介

    存储管理服务cinder主要负责云盘，快照和备份的生命周期管理包括：创建云盘，快照和备份，快照恢复云盘，备份恢复云盘，以及云盘，快照和备份的删除等功能服务。cinder 负责给虚拟机提供块级的持久化卷，本身并不保存卷，主要通过和各类driver来接管各种存储，并通过这些存储给虚拟机提供空间。镜像管理服务glance主要负责对镜像进行管理，完成镜像的注册、发现、删除等操作，glance服务同样支持多种存储后端。天翼云3.0架构下，cinder及glance服务采用rpm包部署管理方式，需要管理各项依赖包以及配置文件。随着容器化应用技术兴起，容器化cinder及glance服务也成了大势所趋。天翼云4.0架构下，计算底座统一采用了k8s编排管理，带来了更加便利的服务管理方式，更加灵活的配置管理，升级变更操作的原子性，以及对客户的影响减少等诸多优势。

1.2、初识k8s

    容器化就是应用程序级别的虚拟化，运行的单个内核上有多个独立的用户空间实例，这些实例就是容器。由于容器技术的兴起，所以就出现了一些用来支持应用程序容器化部署和组织的容器编排技术，一些流行的开源容器编排工具有 Docker Swarm、k8s等。但随着容器化技术发展，k8s也逐渐成为容器编排管理的主流标准。

    下图所示为k8s的架构图，k8s主要是由Master 和 Node 两种节点组成，这两种角色分别对应着控制节点和工作节点。其中 Master 节点由三个独立的组件组成，它们分别是负责整个集群通信的 API 服务的 kube-apiserver、负责容器调度的 kube-scheduler 以及负责维护集群状态的 kube-controller-manager 组件。整个集群的数据都是通过 kube-apiserver 保存到 etcd 数据库中的，而其他所有组件的通信也都是通过 kube-apiserver 和 etcd 数据库进行通信。

图1  k8s架构

k8s编排编排管理服务主要优势如下。

• 敏捷的应用程序创建部署以及应用扩展；
• 持续开发、集成和部署：提供可靠和频繁的容器镜像构建和部署，并提供快速和轻松的回滚。
• 跨开发、测试和生产的环境一致性；
• 开发和操作关注点分离：在构建发布时创建应用服务容器镜像，从而将应用服务与基础架构分离；
• 可以管理大量跨主机的容器，节省资源，优化硬件资源的使用。

2、cinder、glance容器化部署架构

2.1、cinder容器化部署架构

    cinder服务主要分为cinder-api、cinder-scheduler、cinder-volume以及cinder-backup组件，各组件之间通过rabbitmq通信，mysql用于存储相关数据。天翼云4.0架构下，cinder作为AZ级服务提供块储管理服务，其主要模块如下图所示：

图2  cinder组件结构

    cinder服务除自身服务组件外还依赖各类中间件服务，如rabbitmq和mysql等，采用容器化部署后，考虑到此类服务自身具有的高可用设计以及服务数据安全性问题，mysql和rabbitmq不进行容器化。采用k8s部署编排的cinder服务，其架构如图3所示。cinder-api及cinder-scheduler部署在控制节点，采用deployment部署管理，pod通常设置为3副本，保证服务高可用。cinder-volume和cinder-backup则部署在计算节点，采用daemonset编排管理。memcached采用statefulset 容器化部署，mysql服务则通过容器化的haproxy实现服务访问转发，service实现haproxy的负载及高可用。各类服务所需配置文件采用comfigmap形式统一管理并挂载到服务pod内。整个cinder服务由service暴露cinder-api服务端口供其他组件调用。

图3  cinder容器化部署架构

2.2、glance容器化部署架构

2.2.1、glance架构

    天翼云4.0架构下，glance作为region级别服务提供镜像生命周期管理功能，租户在一个Region下的多个AZ内可使用相同的镜像。采用容器化部署后其服务pod主要分布在不同AZ内，其架构如下图4所示。mysql实例集群下三个节点分别分布于三个AZ内，同样采用容器化haproxy负载均衡访问，service暴露服务端口。容器化memcached采用statefulset资源管理编排，节点pod分布于三个AZ内。与cinder服务一样采用configmap管理各类服务的配置文件。

图4  glance架构图

2.2.2、glance就近访问

    镜像管理glance服务提升为Region级别服务后，就会存在跨AZ请求服务场景。由于pod分布在3个不同AZ，默认情况下，发往 glance service ClusterIP 服务的流量可能会被路由到任一pod后端的地址。为了节省网络资源，采用就近访问服务形式。但是对于 ClusterIP 服务，无法完成同节点优先的路由，也无法配置集群优选路由到同一可用区中的端点。 我们通过在service上配置topologyKeys ，以此可以基于来源节点和目标节点的标签来定义流量路由策略。通过对源和目的之间的标签匹配，可以根据节点间彼此“较近”和“较远” 来定义节点集合，实现glance服务的pod后端就近访问，当前AZ内其他组件服务请求glance服务时，流量优先打到本AZ内的glance pod上。

3、总结

总体来说，采用容器化编排部署cinder及glance服务具有诸多优势：

• 部署、恢复速度快：使用k8s的工作负载deployment、daemonset等可实现服务自动化部署和高速回溯；
• 服务高可用、弹性伸缩、快速扩容：k8s支持pod异常重启及pod故障迁移，支持服务副本数快速扩展，弹性伸缩；
• 可视化容器仓库管理：使用harbor作为容器镜像管理仓库，可视化服务镜像版本管理；
• 配置文件统一管理：服务涉及所有配置文件统一由configmap管理，动态修改，由k8s重启服务即可更新配置；
• 日志分析：所有服务日志都由pod内重定向至宿主机/var/log/ 目录下，可配合日志收集管理平台查询相关日志，快速定位问题。

当然，容器化部署cinder、glance服务有也不便之处，例如存在代码调试方式繁琐等问题，不利于测试环境进行代码功能调试，此类问题还有待于进一步优化。