前言

随着业务不断的扩张，所依赖的微服务架构的日益庞大，所带来的相关部署工作也越来越重型。

近年来，容器技术快速更新，为降级部署微服务庞大的架构提供了可能。同时，云计算强大资源管控和弹性调度能力，为容器提供了非常好的运行环境。越来越多的企业把自己的微服务架构装进了容器并搬上了云；

相关前言的技术，开源的云：openstack，容器：k8s，docker

第一步我们先搭建一套属于自己的云

openstack搭建指引

这一块不做过多的介绍，openstack官网有非常完整的搭建指引，网上也有很多个人的搭建经验可以参考

相关文档：https://docs.openstack.org/ocata/install-guide-rdo/environment.html

在此我们仅介绍下部署中遇到的问题，在分析问题前，我们先介绍下openstack的相关概念

openstack概念解析

下面引用官网的openstack逻辑架构图

openstack依赖的核心基础服务

• apache：

Apache HTTP Server（简称Apache）是Apache软件基金会的一个开放源代码的网页服务器软件，可以在大多数电脑操作系统中运行，由于其跨平台和安全性被广泛使用，是最流行的Web服务器软件之一。它快速、可靠并且可通过简单的API扩充，将Perl／Python等解释器编译到服务器中。

• memcached

Memcached是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载，最初由LiveJournal的Brad Fitzpatrick开发，目前得到了广泛的使用。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提高动态、数据库驱动网站的速度。

• rabbitmq

RabbitMQ是一个在AMQP基础上完成的，可复用的企业消息系统。

• mysql

几乎所有OpenStack核心组件都会用到数据库组件, OpenStack支持的数据库后端有SQlite, MySQL, PostGreSQL。

• MongoDB

MongoDB是一个基于分布式文件存储的数据库，旨在为Web应用提供可扩展的高性能数据存储解决方案。

• Ceph

Ceph是一个分布式存储系统，诞生于2004年，是最早致力于开发下一代高性能分布式文件系统的项目。随着云计算的发展，ceph乘上了OpenStack的春风，进而成为了开源社区受关注较高的项目之一。

Ceph基本结构

openstack核心组件

• horizon：

Horizon是OpenStack Dashbaord项目，为用户提供了Web图形化的管理界面来完成一些常见的虚拟资源操作，例如创建虚拟机实例，管理网络，设置访问权限等等。下图给出了Horizon的预览页面的样例。

• keytone

身份认证管理服务，用于配置和管理Keystone，其中包括:服务，软件包，Keystone user，role，service，endpoint等等。其中keystone user, role, service, endpoint等资源的管理是通过自定义的resource type来实现。

• nova

nova模块用于配置和管理Nova服务，包括服务，软件包，配置文件，flavor，nova cells等等。其中 nova flavor, cell 等资源的管理是使用自定义的resource type来实现的。

• glance 

Glance是OpenStack Image Service项目，用于注册、管理和检索虚拟机镜像。 Glance并不负责实际的镜像存储。它提供了对接简单文件系统，对象存储，块存储等多种存储后端的能力。除了磁盘镜像信息，它还能够存储描述镜像的元数据和状态信息。

• neutron

neutron 组件是 OpenStack 各组件中最为复杂的组件，puppet-neutron 模块提供了 neutron 各个组件的部署和管理，包括 neutron plugins 的管理和 neutron agents 的管理。

• cinder

它是一个资源管理系统，负责向虚拟机提供持久块存储资源(云硬盘)。

主要核心是对卷的管理，允许对卷，卷的类型，卷的快照进行处理

它把不同的后端存储进行封装，向外提供统一的API。

它不是新开发的块设备存储系统，而是使用插件的方式结合不同后端存储的驱动提供块存储服务。

#cinder架构

 

• swift

Swift最初源自于Rackspace公司开发的高可用分布式对象存储服务CloudFiles，于2010年贡献给OpenStack开源社区作为最早的核心项目，为用户提供了对象存储，虚机镜像存储，块设备快照存储等诸多功能。Swift可以运行在廉价的标准X86硬件存储上，无需配置RAID（磁盘冗余阵列），通过在软件层面引入一致性哈希算法和数据冗余性，以牺牲一定的数据一致性来最终达到高可用性和可伸缩性，支持多租户模式、容器和对象读写操作，适合解决非结构化数据存储问题。

• ceilometer

ceilometer是openstack的数据收集模块，它把收集OpenStack内部发生的大部分事件，为计费和监控以及其它服务提供数据支撑。ceilometer的架构如下：

 

转存失败重新上传取消

搭建openstack中遇到的问题

• 问题1：搭建完网络组件后，执行验证命令：openstack network agent list，找不到 Linux bridge agent 类型的agent

检查对比相关配置后，发现配置bridge时，linuxbridge_agent.ini配置漏掉了修改项

physical_interface_mappings项的PROVIDER_INTERFACE_NAME 未替换为本机的物理网卡接口，修改为

改完后再次启动，发现neutron-linuxbridge-agent服务还是无法启动，查看日志发现这个错误：

CRITICAL neutron [-] ConfigFileValueError: Value for option local_ip is not valid: controller is not IPv4 or IPv6 address

由于配置local_ip时，误以为可以配置hostname，所以配置为controller。修改local_ip为实际的物理网卡ip，到此问题解决。

• 问题2：绑定浮动ip后，外网无法访问实例

登陆Dashboard，发现没有绑定浮动ip的入口，只能执行命令（openstack server add floating ip instance floating-ip）绑定浮动ip。但是为实例绑定好浮动ip后，外网还是无法访问。

执行命令neutron router-port-list router，发现绑定的外网网关ip无法ping通。

分许问题，排查缺失的环境条件因素。最终定位，由于是通过VMWARE搭建的虚拟机，controller和compute需要能为起提供外网ip的网络接口，所以在vmware上分配为controller和compute添加桥接的网卡，controller和compute拥有两张网卡，一张为管理网络层提供服务，一张为浮动ip绑定提供物理ip。

重启服务systemctl restart neutron-linuxbridge-agent后，外网成功登陆进实例。

 

这里再分析下openstack两种网络模式的区别

openstack创建的云实例运行环境，支持两种网络模式。

Provider networks：

提供者网络，只支持实例连接到公有网络（外部网络）。没有私有网络（个人网络），路由器以及浮动IP地址。只有``admin``或者其他特权用户才可以管理公有网络

Self-service networks：

自服务网络，支持实例连接到私有网络。``demo``或者其他没有特权的用户可以管理自己的私有网络，包含连接公网和私网的路由器。另外，浮动IP地址可以让实例使用私有网络连接到外部网络，例如互联网

同时，上面两种网络又存在依赖关系：self-service里面的实例需要provider网络层提供浮动ip，才能被外网直接访问。

 

至此，openstack告一段落，后面继续Kubernetes...