模板机规划设置：
系统优化
启动实例
Openstack 版本
Openstack 主要组件（核心服务）
Openstack架构图
Cinder：
提供网络服务的核心组件。
kolla项目初步认知
**
什么是Kolla
项目源代码
kolla简介

模板机规划设置：

最小化模式部署

controller-node-192.168.116.10
network-node-192.168.111.11 192.168.222.11
compute-node-192.168.111.12

VMnet1：

VMnet8

网络节点添加2张网卡：

计算节点开启嵌套虚拟化

系统优化

Linux系统优化：

https://www.yuque.com/liweiming/nvdrn7/ugqvdg

关闭防火墙

systemctl disable firewalld.service
systemctl stop firewalld.service
setenforce 0

关闭NetworkManger

systemctl disable NetworkManger
systemctl stop NetworkManager

关闭selinux

sed -i “s/^SELINUX=enforcing/SELINUX=disabled/g” /etc/sysconfig/selinux
sed -i “s/^SELINUX=enforcing/SELINUX=disabled/g” /etc/selinux/config
sed -i “s/^SELINUX=permissive/SELINUX=disabled/g” /etc/sysconfig/selinux
sed -i “s/^SELINUX=permissive/SELINUX=disabled/g” /etc/selinux/config

控制节点上设置ssh key 免密钥登陆

ssh-keygen -q -N “” -f ~/.ssh/id_rsa
分发key
ssh-copy-id 192.168.111.11
ssh-copy-id 192.168.111.12
ssh-copy-id 192.168.111.10

设置本地yum源：

挂载本地镜像

mount /dev/cdrom /mnt
rz 上传openstack.tar.gz到/opt，并解压
tar xf openstack_Q.tar.gz

分发的其他节点

scp -r openstack 192.168.111.11:/opt/
scp -r openstack 192.168.111.12:/opt/

清空本地repo

mv /etc/yum.repos.d/*.repo /tmp/

生成repo配置文件

touch /etc/yum.repos.d/local.repo
echo ‘[local]
name=local
baseurl=file:///mnt
gpgcheck=0
[openstack]
name=openstack
baseurl=file:///opt/openstack
gpgcheck=0’ >/etc/yum.repos.d/local.repo

yum clean all
yum makecache
echo ‘mount /dev/cdrom /mnt’ >>/etc/rc.local
chmod +x /etc/rc.d/rc.local
yum repolist

同步时间设置：

yum install chrony -y
systemctl enable chronyd.service
systemctl start chronyd.service

控制节点：

vim /etc/chrony.conf
修改第26行
allow 192.168.111.0/24

systemctl restart chronyd
查看端口：123
netstat -lutnp

其他节点：

vim /etc/chrony.conf
修改第3行
server 192.168.111.10 iburst
systemctl restart chronyd

查看时区

date -R

查看时间同步状态

timedatectl
timedatectl set-local-rtc 1
timedatectl set-ntp yes
chronyc tracking
chronyc sourcestats -v

计算节点卸载不兼容包

rpm -qa |grep libvirt-daemon-config-network
yum remove libvirt-daemon-config-network-4.5.0-23.el7.x86_64 -y

开始自动化部署

控制节点部署自动化工具

清空自动生成的系统repo包

rm -rf /etc/yum.repos.d/CentOS-*

自定义组件部署

安装自动化部署工具

yum install openstack-packstack -y

生成自动部署应答文件

packstack —gen-answer-file=openstack.txt

修改应答文件

cp /root/openstack.txt{,.bak}

修改内容如下

vim /root/openstack.txt

Web界面登陆密码

第11行
CONFIG_DEFAULT_PASSWORD=123456

关闭对象存储安装

第41行
CONFIG_SWIFT_INSTALL=n

关闭告警服务

第50行
CONFIG_AODH_INSTALL=n

配置控制节点IP

第94行
CONFIG_CONTROLLER_HOST=192.168.111.10

配置计算节点IP

第97行
CONFIG_COMPUTE_HOSTS=192.168.111.12

配置网络节点IP

第101行
CONFIG_NETWORK_HOSTS=192.168.111.11

配置认证服务的密码

第326行
CONFIG_KEYSTONE_ADMIN_PW=123456

修改存储卷大小（根据系统空间调整）

第557行
CONFIG_CINDER_VOLUMES_SIZE=10G

配置外部网卡桥接网络（网络节点）

第873行
CONFIG_NEUTRON_OVS_BRIDGE_IFACES=br-ex:ens34

关闭demo环境需要联网下载

第1185行
CONFIG_PROVISION_DEMO=n

在控制节点使用应答文件开始部署openstack（puppet）

[root@controller-node ~]# packstack —answer-file=openstack.txt

[root@controller-node ~]# packstack —answer-file=openstack.txt
Welcome to the Packstack setup utility

The installation log file is available at: /var/tmp/packstack/20200212-215140-HVEDaW/openstack-setup.log

Installing:
Clean Up [ DONE ]
Discovering ip protocol version [ DONE ]
Setting up ssh keys [ DONE ]
Preparing servers [ DONE ]
Pre installing Puppet and discovering hosts’ details [ DONE ]
Preparing pre-install entries [ DONE ]
Setting up CACERT [ DONE ]
Preparing AMQP entries [ DONE ]
Preparing MariaDB entries [ DONE ]
Fixing Keystone LDAP config parameters to be undef if empty[ DONE ]
Preparing Keystone entries [ DONE ]
Preparing Glance entries [ DONE ]
Checking if the Cinder server has a cinder-volumes vg[ DONE ]
Preparing Cinder entries [ DONE ]
Preparing Nova API entries [ DONE ]
Creating ssh keys for Nova migration [ DONE ]
Gathering ssh host keys for Nova migration [ DONE ]
Preparing Nova Compute entries [ DONE ]
Preparing Nova Scheduler entries [ DONE ]
Preparing Nova VNC Proxy entries [ DONE ]
Preparing OpenStack Network-related Nova entries [ DONE ]
Preparing Nova Common entries [ DONE ]
Preparing Neutron LBaaS Agent entries [ DONE ]
Preparing Neutron API entries [ DONE ]
Preparing Neutron L3 entries [ DONE ]
Preparing Neutron L2 Agent entries [ DONE ]
Preparing Neutron DHCP Agent entries [ DONE ]
Preparing Neutron Metering Agent entries [ DONE ]
Checking if NetworkManager is enabled and running [ DONE ]
Preparing OpenStack Client entries [ DONE ]
Preparing Horizon entries [ DONE ]
Preparing Gnocchi entries [ DONE ]
Preparing Redis entries [ DONE ]
Preparing Ceilometer entries [ DONE ]
Preparing Puppet manifests [ DONE ]
Copying Puppet modules and manifests [ DONE ]
Applying 192.168.111.10_controller.pp
192.168.111.10_controller.pp: [ DONE ]
Applying 192.168.111.11_network.pp
192.168.111.11_network.pp: [ DONE ]
Applying 192.168.111.12_compute.pp
192.168.111.12_compute.pp: [ DONE ]
Applying Puppet manifests [ DONE ]
Finalizing [ DONE ]

Installation completed successfully **

Additional information:

Time synchronization installation was skipped. Please note that unsynchronized time on server instances might be problem for some OpenStack components.
File /root/keystonerc_admin has been created on OpenStack client host 192.168.111.10. To use the command line toolsyou need to source the file.
To access the OpenStack Dashboard browse to http://192.168.111.10/dashboard .
Please, find your login credentials stored in the keystonerc_admin in your home directory.
The installation log file is available at: /var/tmp/packstack/20200212-215140-HVEDaW/openstack-setup.log
The generated manifests are available at: /var/tmp/packstack/20200212-215140-HVEDaW/manifests

查看安装输出日志：
[root@controller-node ~]# tail -f /var/log/messages

访问地址：
http://192.168.111.10/dashboard

Horizon主界面

项目

管理员

身份管理

环境变量加载：

常用命令：

检查Keystone

openstack token issue

检查glance服务

openstack image list
glance image-list

检查nova服务

openstack compute service list
nova service-list

检查neutron服务

openstack network agent list

启动实例

管理员：

1创建项目
2创建用户组
3创建租户
关联用户和组
4创建规格（实例类型）
5上传镜像
6创建网络（创建外部网络）

命令查看实例类型：

openstack flavor list
nova flavor-list

镜像：
https://docs.openstack.org/image-guide/obtain-images.html
http://cloud.centos.org/centos/7/images/

测试镜像：
http://download.cirros-cloud.net/

手动制作镜像：

命令查看镜像：

openstack image list

命令行：
openstack image create —disk-format qcow2 —file /root/cirros-0.3.4-x86_64-disk.img —container-format bare cirros-0.3.4-x86_64

租户：

1租户登陆切换到相应的项目

2检查镜像

3检查网络

创建租户虚拟网络：<br />    3.1无软件路由器出口内网（网络隔离）<br />    3.2有软件路由器出口的路由网络（网络互通）：创建路由（选择外部网络）---创建网络（创建子网）---路由器添加子网接口

管理员创建外部网络：
external network
external_subnet

uat_network
uat_network_subnet
uat_network_router

4申请主机

安全组：

浮动IP：

Openstack 版本

Openstack 主要组件（核心服务）

Keystone：认证服务

Nova：计算服务

Glance：镜像服务

Cinder：块存储服务

Swift：对象存储

Neutron：网络服务

Openstack架构图

Openstack R版部署 - 图11

Kubernetes：容器编排调度管理平台

CloudFoundry：CloudFoundry是一个提供夸平台、多语言应用框架的开源PaaS，可运行于私有云和公有云

Terraform：Terraform 是一种安全有效地构建、更改和版本控制基础设施的工具(基础架构自动化的编排工具)

Openstack逻辑架构

Openstack R版部署 - 图13

a) 终端用户通过和nova-api对话来与OpenStack Compute交互。
b) OpenStack Compute守护进程之间通过队列(行为)和数据库(信息)来交换信息，以执行API请求。（交换信息的方式我们以后会讲）
c) OpenStack Glance基本上是独立的基础架构，OpenStack Compute通过Glance API来和它交互。
其各个组件的情况如下：
a) nova-api守护进程是OpenStack Compute的中心。它为所有API查询(OpenStack API 或 EC2 API)提供端点，初始化绝大多数部署活动(比如运行实例)，以及实施一些策略(绝大多数的配额检查)。
因此很多相对于openstack独立的基础架构是跟nova-api交换信息的，而不是向其他进程那样使用队列和数据库；
b) nova-compute进程主要是一个创建和终止虚拟机实例的Worker守护进程。基本原理：从队列中接收行为，然后在更新数据库的状态时，执行一系列的系统命令执行他们。
c) nova-volume管理映射到计算机实例的卷的创建、附加和取消。这些卷可以来自很多提供商，比如，ISCSI和AoE。
d) Nova-network worker守护进程类似于nova-compute和nova-volume。它从队列中接收网络任务，然后执行任务以操控网络，比如创建bridging interfaces或改变iptables rules。
e) Queue提供中心hub，为守护进程传递消息。当前用RabbitMQ实现。但是理论上能是python ampqlib支持的任何AMPQ消息队列。
f) SQL database存储云基础架构中的绝大多数编译时和运行时状态。当前广泛使用的数据库是sqlite3(仅适合测试和开发工作)，MySQL和PostgreSQL。
g) OpenStack Glance，是一个单独的项目，它是一个compute架构中可选的部分，分为三个部分：
glance-api:glance-api接受API调用;
glance-registry: glance-registry负责存储和检索镜像的元数据，实际的Image Blob存储在Image Store中;
the image store:Image Store可以是多种不同的Object Store，包括OpenStack Object Storage (Swift);
h) 最后，user dashboard是另一个可选的项目。OpenStack Dashboard提供了一个OpenStack Compute界面来给应用开发者和devops staff类似API的功能。当前它是作为Django web Application来实现的。当然，也有其他可用的Web前端。（说白了就是个UI）

Openstack R版部署 - 图14

Openstack R版部署 - 图15

Openstack R版部署 - 图16

Opensatck概念图

Openstack R版部署 - 图17

注释：
Openstack R版部署 - 图18

Openstack R版部署 - 图19

运算套件Nova：openstack中的核心，负责计算和实施一些策略，很多组件都要通过他进行调度（Nova中的nova-api负责所以API的调度，初始化大多数部署，执行部分策略）
对象储存套件Swift：分布式对象存储，功能类似于hadoop，可是跟hadoop又有很大不同；在openstack中，swift用于存储创建虚拟机的镜像文件
区块储存套件Cinder：配分块存储，给虚拟机增加一个块存储设备（有点类似于移动硬盘）；
网通套件Quantum：通过API来管理的网络架构系统；
身分识别套件Keystone：身份认证功能；
镜像檔管理套件Glance：对镜像文件进行管理；
仪表板套件Horizon：就是一个UI；

Openstack思维导图

Openstack R版部署 - 图20

虚拟机创建过程：
界面或命令行通过RESTful API向keystone获取认证信息。
keystone通过用户请求认证信息，并生成auth-token返回给对应的认证请求。
界面或命令行通过RESTful API向nova-api发送一个boot instance的请求（携带auth-token）。
nova-api接受请求后向keystone发送认证请求，查看token是否为有效用户和token。
keystone验证token是否有效，如有效则返回有效的认证和对应的角色（注：有些操作需要有角色权限才能操作）。
通过认证后nova-api和数据库通讯。
初始化新建虚拟机的数据库记录。
nova-api通过rpc.call向nova-scheduler请求是否有创建虚拟机的资源(Host ID)。
nova-scheduler进程侦听消息队列，获取nova-api的请求。
nova-scheduler通过查询nova数据库中计算资源的情况，并通过调度算法计算符合虚拟机创建需要的主机。
对于有符合虚拟机创建的主机，nova-scheduler更新数据库中虚拟机对应的物理主机信息。
nova-scheduler通过rpc.cast向nova-compute发送对应的创建虚拟机请求的消息。
nova-compute会从对应的消息队列中获取创建虚拟机请求的消息。
nova-compute通过rpc.call向nova-conductor请求获取虚拟机消息。（Flavor）
nova-conductor从消息队队列中拿到nova-compute请求消息。
nova-conductor根据消息查询虚拟机对应的信息。
nova-conductor从数据库中获得虚拟机对应信息。
nova-conductor把虚拟机信息通过消息的方式发送到消息队列中。
nova-compute从对应的消息队列中获取虚拟机信息消息。
nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求glance-api获取创建虚拟机所需要镜像。
glance-api向keystone认证token是否有效，并返回验证结果。
token验证通过，nova-compute获得虚拟机镜像信息(URL)。
nova-compute通过keystone的RESTfull API拿到认证k的token，并通过HTTP请求neutron-server获取创建虚拟机所需要的网络信息。
neutron-server向keystone认证token是否有效，并返回验证结果。
token验证通过，nova-compute获得虚拟机网络信息。
nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求cinder-api获取创建虚拟机所需要的持久化存储信息。
cinder-api向keystone认证token是否有效，并返回验证结果。
token验证通过，nova-compute获得虚拟机持久化存储信息。
nova-compute根据instance的信息调用配置的虚拟化驱动来创建虚拟机。

Keystone：认证服务

主要的功能：

身份验证

授权

服务目录

User
OpenStack最基本的用户。
User即用户，他们代表可以通过keystone进行访问的人或程序。Users通过认证信息（credentials，如密码、API
Keys等）进行验证。
Project（Tenant）
指分配给使用者的资源的集合。
Tenant即租户，它是各个服务中的一些可以访问的资源集合。例如，在Nova中一个tenant可以是一些机器，在Swift和Glance中一个tenant可以是一些镜像存储，在Neutron中一个tenant可以是一些网络资源。Users默认的总是绑定到某些tenant上。
Role
Role即角色，Roles代表一组用户可以访问的资源权限，例如Nova中的虚拟机、Glance中的镜像。Users可以被添加到任意一个全局的或租户的角色中。在全局的role中，用户的role权限作用于所有的租户，即可以对所有的租户执行role规定的权限；在租户内的role中，用户仅能在当前租户内执行role规定的权限。
Service
Service即服务，如Nova、Glance、Swift。根据前三个概念（User，Tenant和Role）一个服务可以确认当前用户是否具有访问其资源的权限。但是当一个user尝试着访问其租户内的service时，他必须知道这个service是否存在以及如何访问这个service，这里通常使用一些不同的名称表示不同的服务。
Endpoint
服务的URL路径，暴露出来的访问点。
Endpoint，翻译为“端点”，我们可以理解它是一个服务暴露出来的访问点，如果需要访问一个服务，则必须知道他的endpoint。因此，在keystone中包含一个endpoint模板，这个模板提供了所有存在的服务endpoints信息。一个endpoint template包含一个URLs列表，列表中的每个URL都对应一个服务实例的访问地址，并且具有public、private和admin这三种权限。public url可以被全局访问，private url只能被局域网访问，admin url被从常规的访问中分离。
Domain
定义管理边界，可以包含多个project,user,role.
Token
Token是访问资源的钥匙。它是通过Keystone验证后的返回值，在之后的与其他服务交互中只需要携带Token值即可。每个Token都有一个有效期，Token只在有效期内是有效的。
Policy
OpenStack对User的验证除了OpenStack的身份验证以外，还需要鉴别User对某个Service是否有访问权限。Policy机制就是用来控制User对Tenant中资源(包括Services)的操作权限。对于Keystone service来说，Policy就是一个JSON文件，默认是/etc/keystone/policy.json。通过配置这个文件，Keystone Service实现了对User基于Role的权限管理。
Credentials
用于确认用户身份的凭证。
Authentication：
确定用户身份的过程。

Nova：计算服务

OpenStack云中的计算组织控制器。
管理OpenStack云中示例的生命周期。
管理计算资源资源、网络、认证所需的可扩展平台。
计算管理(codenamed “Nova”)基于用户需求为VM提供计算资源管理. 基于Python语言编写。
计算服务：计算节点–运行虚拟机的Hypervisor。
分布式控制器：负责处理器调度策略及API调用等。

Nova常用术语：

KVM
内核虚拟化，OpenStack中默认的Hypersvisor。
Qemu
KVM的替补角色，没有KVM执行效率高，不支持虚拟化。
Flavor
新建虚拟机的配置列表，虚拟机模板。
安全组
用来控制实例访问策略的容器。
安全组规则
用来控制实例访问的具体策略。

Nova中的一些基本概念：

Nova-API
对外统一提供标准化接口，接受和响应最终用户Compute
API的请求,同时还实现与Openstack其他各逻辑模块的通讯与服务提供。
Nova-Scheduler
从队列上得到一个虚拟机实例请求并且决定它应该在哪里运行(使用多种过滤器或算法调度)。即负责调度将实例分配到具体的计算节点。
Queue
提供了一个守护进程之间传递消息的中央枢纽。消息队列系统作用还可以实现与Openstack其他各逻辑模块之间的通信建立连接枢纽。
Nova-Datebase
存储云基础设施的编译时和运行时的状态,从理论上讲，OpenStack Nova可以支持任何SQL-Alchemy支持的数据库，但是目前被广泛使用的数据库有sqlite3（只适用于测试和开发工作），MySQL和PostgreSQL。
Nova-Compute
主要是一个人工守护进程，它可以通过虚拟机管理程序的API（XenAPIfor XenServer/XCP,libvirtfor KVM or QEMU, VMwareAPIfor VMware等）来创建和终止虚拟机实例。支持多种虚拟化平台。
Nova-conductor
主要负责与Nova数据库进行交互。
Nova还提供控制台的服务
让最终用户通过代理服务器访问他们的虚拟实例的控制台。这涉及到多个守护进程(nova-console，nova-novncproxy、nova-xvpnvncproxy和nova-consoleauth)

Nova功能特性：

实例的生命周期管理。
管理平台的计算资源。
统一风格的RestAPI。
支持透明的hypervisor。
各个模块通过消息队列实现交互。

Glangce 镜像服务

Glance简介：

为Nova提供镜像服务。
通常不负责镜像的本地存储。
实现对镜像的管理。
Glance是OpenStack镜像服务,用来注册、登陆和检索虚拟机镜像。Glance服务提供了一个REST API，使你能够查询虚拟机镜像元数据和检索的实际镜像。通过镜像服务提供的虚拟机镜像可以存储在不同的位置，从简单的文件系统对象存储到类似OpeenStack对象存储系统。

镜像服务组件:

Glance-API ：
负责提供镜像服务的rest api。
接收最终用户或Noav对镜像的请求,检索和存储镜像的相关API调用。
Glance-registry：存储,处理和检索有关镜像的元数据,元数据大小、类型等等。
Database ：存储镜像元数据,可以支持多种数据库,现在使用比较广泛的是mysql和sqlite.

Glance支持的镜像格式：

raw –非结构化的镜像格式
vhd– 一种通用的虚拟机磁盘格式，可用于Vmware、Xen、Microsoft Virtual PC/VirtualServer/Hyper-V、VirtualBox等
vmdk– Vmware的虚拟机磁盘格式，同样也支持多种Hypervisor
vdi– VirtualBox、QEMU等支持的虚拟机磁盘格式
qcow2 –一种支持QEMU并且可以动态扩展的磁盘格式
aki– Amazon Kernel 镜像
ari– Amazon Ramdisk 镜像
ami– Amazon 虚拟机镜像

Cinder：存储服务

Cinder：

Cinder简介：

为虚拟机示例提供volume卷的块存储服务。
一个volume可以同时挂载到多个实例上。
共享的卷同时只能被一个示例进行写操作。
Cinder主要核心是对卷的管理，允许对卷、卷的类型、卷的快照进行处理。它并没有实现对块设备的管理和实际服务，而是为后端不同的存储结构提供了统一的接口，不同的块设备服务厂商在Cinder中实现其驱动支持以与OpenStack进行整合。
块存储管理模块(codenamed “Cinder”)提供到虚拟机的永久性块存储卷.类似AWS的EBS块存储服务。
多个卷可以被挂载到单一虚拟机实例，同时卷可以在虚拟机实例间移动，单个卷在同一时刻只能被挂载到一个虚拟机实例。
块存储系统管理块设备到虚拟机的创建，挂载以及卸载。
块设备卷完全与OpenstackCompute集成,并支持云用户在Dashboard中管理数据自己的存储。
除了支持简单的Linux服务器本地存储之外，还支持众多的存储平台,包括Ceph,NetApp, Nexenta,SolidFire,Zadara。
快照管理提供了强大的在块存储上实现数据备份的功能可以用来作为引导卷使用。
块存储适合性能敏感性业务场景,例如数据库存储大规模可扩展的文件系统或服务器需要访问到块级裸设备存储。

常用术语：

Volume备份：volume卷的备份。
Volume快照：卷在某个时间点的状态。
Cinder API：为Cinder请求提供的统一风格的Rest API服务。
Cinder Schedule：负责为新建卷指定块存储设备。
Cinder Volume：负责与存储的块设备交互，实现卷的创建、删除、修改等操作。
Cinder Backup：备份服务负责通过驱动和后端的备份设备打交道。

Neutron网络服务

提供网络服务的核心组件。

基于软件定义网络的的思想。
网络服务(codenamed “Quantum/Neutron”)提供在被管理设备之间的网络连接服务.
允许用户自己创建自己的网络并attach端口使用.
通过开发的Plugins支持SDN和OpenFlow
用户自定义子网地址,私有网络/公有网络以及FloatingIP分配规则
基于插件的模型。

常用术语：

Bridge-int
实现内部网络功能的网桥。
Br-ex：
跟外部网络通信的网桥。
Neutron-server：
提供API接口。
Neutron-L2-agent：
实现二层网络通信的代理。
Neutron-DHCP-agent：
为子网自动分发IP地址。
Neutron-L3-agent：
租户网络和floating IP间地址的转换。
Neutron-metadate-agent：
响应Nova的metadate请求。
LBaas agent：
为多台实例和Open vswitch agent提供负载均衡服务。

服务组件：

Neutron API
l提供Openstack其他服务或管理员及用户访问的接口.
抽相层
网络资源抽象化,包括网络，子网，端口及路由。将底层各种各样的网络资源按照openstack定义的网络描述规则化。
Plug-in
通过Plug-in方式可以整合更多的高级的功能以及与底层网络厂商的设备实现更好的集成。

网络Agent：

Plug-in agent:本地虚拟交换配置。
Dhcp agent:为tenant网络提供DHCP服务。
L3agent:提供l3/NAT转发功能，为tenant网络中的vm提供外网访问。
Meteringagent:提供l3流量监控和计量。

网络描述：

管理网络：用于OpenStack各组件之间的内部通信。
数据网络：用于云部署中虚拟数据之间的通信。
外部网络：公共网络，外部或internet可以访问的网络。
API网络：暴露所有的OpenStackAPIs,包括OpenStack网络 API给租户

Neutron服务网络管理的三种模式，两种IP：

两种IP：
固定IP(Fixed-IP)：分配给虚拟机实例使用
浮动IP(FloatingIP)：分配给虚拟机实例的外网地址,通过NAT方式实现。
三种模式：
Flat模式
Flat 模式是最简单的一种联网模式。每个实例接收一个来自池的固定IP。所有实例均默认附加到相同的桥
(br100)。桥必须进行手动配置。联网配置在实例引导前插入到实例中。在这种模式中，没有浮动IP特性。
Flat DHCP模式
用于测试环境。
这种模式下与Flat模式不同的地方在于有一个DHCP进程，每一个运行nova-network进程的节点（网络控制节点/nove-network主机）就是一个单独的网络。Nova会在 nova-network主机建立网桥（默认名称br100，配置项 flat_network_bridge=br100），并给该网桥指定该网络的网关IP，同时 Nova在网桥处起一个DHCP进程，最后，会建立iptables规则（SNAT/DNAT）使虚拟机能够与外界通信，同时与一个metadata服务器通信以取得cloud内的信息。
计算节点负责创建对应节点的网桥，此时的计算节点网卡可以不需要IP地址，因为网桥把虚拟机与nove-network主机连接在一个逻辑网络内。虚拟机启动时会发送dhcpdiscover以获取 IP地址。虚拟机通往外界的数据都要通过nova-network主机，DHCP在网桥处监听，分配fixed_range指定的 IP段。
这种部署方式的缺点—-单节点故障、无二层隔离（即所有的虚拟机都在一个广播域）。
VLAN模式
用于生产环境。
VLAN模式的目的是为每个项目提供受保护的网段，具有以下特点：
NAT实现public ip。
除了public NAT外没有其它途径进入每个lan。
受限的流出网络，project-admin可以控制。
受限的项目之间的访问，同样project-admin控制。
所以实例和api的连接通过vpn。

网络节点网卡接口

[root@network-node ~]# ifconfig -a
br-ex: flags=4163 mtu 1500
inet 192.168.222.11 netmask 255.255.255.0 broadcast 192.168.222.255
inet6 fe80::20c:29ff:fe2c:6f79 prefixlen 64 scopeid 0x20
ether 00:0c:29:2c:6f:79 txqueuelen 1000 (Ethernet)
RX packets 8305 bytes 994509 (971.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 22 bytes 1460 (1.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
br-int: flags=4098 mtu 1500
ether 5e:35:a2:6e:bf:4b txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 142 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
br-tun: flags=4098 mtu 1500
ether ca:be:b7:d9:d1:4a txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ens32: flags=4163 mtu 1500
inet 192.168.111.11 netmask 255.255.255.0 broadcast 192.168.111.255
inet6 fe80::20c:29ff:fe2c:6f6f prefixlen 64 scopeid 0x20
ether 00:0c:29:2c:6f:6f txqueuelen 1000 (Ethernet)
RX packets 511738 bytes 38455908 (36.6 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 507227 bytes 83095421 (79.2 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ens34: flags=4163 mtu 1500
inet6 fe80::20c:29ff:fe2c:6f79 prefixlen 64 scopeid 0x20
ether 00:0c:29:2c:6f:79 txqueuelen 1000 (Ethernet)
RX packets 38009 bytes 17412159 (16.6 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 13 bytes 1100 (1.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73 mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 786983 bytes 79500258 (75.8 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 786983 bytes 79500258 (75.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ovs-system: flags=4098 mtu 1500
ether 1a:48:8b:0d:23:d0 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
vxlan_sys_4789: flags=4163 mtu 65000
inet6 fe80::7031:5cff:fe43:40c5 prefixlen 64 scopeid 0x20
ether 72:31:5c:43:40:c5 txqueuelen 1000 (Ethernet)
RX packets 93 bytes 3818 (3.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 19 bytes 1413 (1.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[root@network-node ~]#

[root@network-node ~]# ovs-vsctl show
528589a0-c8ca-4f3d-a7c5-0295a5a6dfe5
Manager “ptcp:6640:127.0.0.1”
is_connected: true
Bridge br-ex
Controller “tcp:127.0.0.1:6633”
is_connected: true
fail_mode: secure
Port “ens34”
Interface “ens34”
Port br-ex
Interface br-ex
type: internal
Port phy-br-ex
Interface phy-br-ex
type: patch
options: {peer=int-br-ex}
Bridge br-int
Controller “tcp:127.0.0.1:6633”
is_connected: true
fail_mode: secure
Port int-br-ex
Interface int-br-ex
type: patch
options: {peer=phy-br-ex}
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Port br-int
Interface br-int
type: internal
Bridge br-tun
Controller “tcp:127.0.0.1:6633”
is_connected: true
fail_mode: secure
Port br-tun
Interface br-tun
type: internal
Port “vxlan-c0a86f0c”
Interface “vxlan-c0a86f0c”
type: vxlan
options: {df_default=”true”, in_key=flow, local_ip=”192.168.111.11”, out_key=flow, remote_ip=”192.168.111.12”}
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
ovs_version: “2.9.0”
[root@network-node ~]#

[root@network-node ~]# tree /etc/neutron/
/etc/neutron/
├── conf.d
│ ├── common
│ ├── neutron-dhcp-agent
│ ├── neutron-l3-agent
│ ├── neutron-linuxbridge-cleanup
│ ├── neutron-metadata-agent
│ ├── neutron-metering-agent
│ ├── neutron-netns-cleanup
│ ├── neutron-openvswitch-agent
│ ├── neutron-ovs-cleanup
│ ├── neutron-server
│ └── README
├── dhcp_agent.ini
├── l3_agent.ini
├── metadata_agent.ini
├── metering_agent.ini
├── neutron.conf
├── plugins
│ └── ml2
│ └── openvswitch_agent.ini
├── policy.json
└── rootwrap.conf
13 directories, 9 files
[root@network-node ~]#

[root@network-node ~]# egrep -v “^#|^$” /etc/neutron/neutron.conf
[DEFAULT]
bind_host=0.0.0.0
auth_strategy=keystone
core_plugin=neutron.plugins.ml2.plugin.Ml2Plugin
service_plugins=qos,trunk,router,metering
allow_overlapping_ips=True
debug=False
log_dir=/var/log/neutron
transport_url=rabbit://guest:guest@192.168.111.10:5672/
control_exchange=neutron
[agent]
root_helper=sudo neutron-rootwrap /etc/neutron/rootwrap.conf
[cors]
[database]
[keystone_authtoken]
[matchmaker_redis]
[nova]
[oslo_concurrency]
lock_path=$state_path/lock
[oslo_messaging_amqp]
[oslo_messaging_kafka]
[oslo_messaging_notifications]
[oslo_messaging_rabbit]
ssl=False
[oslo_messaging_zmq]
[oslo_middleware]
[oslo_policy]
[quotas]
[ssl]
[root@network-node ~]#

[root@network-node ~]# egrep -v “^#|^$” /etc/neutron/plugins/ml2/openvswitch_agent.ini
[DEFAULT]
[agent]
tunnel_types=vxlan
vxlan_udp_port=4789
l2_population=False
drop_flows_on_start=False
[network_log]
[ovs]
integration_bridge=br-int
tunnel_bridge=br-tun
local_ip=192.168.111.11
bridge_mappings=extnet:br-ex
[securitygroup]
firewall_driver=neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
[xenapi]
[root@network-node ~]#

https://www.cnblogs.com/clsn/p/8366611.html

kolla项目初步认知

https://blog.csdn.net/Moolight_shadow/article/details/51317441

kolla架构

**

什么是Kolla

(In Theory) “Kolla” is Greek for glue（还没查到希腊与克拉的关系，直接说（（理论上）克拉是希腊的胶水）感觉有点不合语境）
一个源代码托管在 github上的开源项目
遵从ASL2开源协议

项目源代码

https://github.com/openstack/kolla

kolla简介

kolla项目起源于TripleO项目，聚焦于使用docker容器部署OpenStack服务。该项目由Cisco于2014年9月提出，是OpenStack 社区Big Tent开发模式下的孵化项目

Openstack R版 部署

模板机规划设置：

最小化模式部署

VMnet1：

VMnet8

网络节点添加2张网卡：

计算节点开启嵌套虚拟化

系统优化

Linux系统优化：

关闭防火墙

关闭NetworkManger

关闭selinux

控制节点上设置ssh key 免密钥登陆

设置本地yum源：

挂载本地镜像

分发的其他节点

清空本地repo

生成repo配置文件

同步时间设置：

控制节点：

其他节点：

查看时区

查看时间同步状态

计算节点卸载不兼容包

开始自动化部署

控制节点部署自动化工具

清空自动生成的系统repo包

自定义组件部署

安装自动化部署工具

生成自动部署应答文件

修改应答文件

修改内容如下

Web界面登陆密码

关闭对象存储安装

关闭告警服务

配置控制节点IP

配置计算节点IP

配置网络节点IP

配置认证服务的密码

修改存储卷大小（根据系统空间调整）

配置外部网卡桥接网络（网络节点）

关闭demo环境 需要联网下载

在控制节点使用应答文件开始部署openstack（puppet）

Horizon主界面

项目

管理员

身份管理

环境变量加载：

常用命令：

检查Keystone

检查glance服务

检查nova服务

检查neutron服务

启动实例

管理员：

命令查看实例类型：

命令查看镜像：

租户：

1租户登陆切换到相应的项目

2检查镜像

3检查网络

4申请主机

安全组：

浮动IP：

Openstack 版本

Openstack 主要组件（核心服务）

Keystone：认证服务

Nova：计算服务

Glance：镜像服务

Cinder：块存储服务

Swift：对象存储

Neutron：网络服务

Openstack架构图

Kubernetes：容器编排调度管理平台

CloudFoundry：CloudFoundry是一个提供夸平台、多语言应用框架的开源PaaS，可运行于私有云和公有云

Terraform：Terraform 是一种安全有效地构建、更改和版本控制基础设施的工具(基础架构自动化的编排工具)

Openstack逻辑架构

Opensatck概念图

Openstack思维导图

Keystone：认证服务

Openstack R版部署

关闭demo环境需要联网下载

网络节点网卡接口