openstack metadata和cloudinit的原理和使用
实现 instance 定制化，cloud-init（或 cloudbase-init）只是故事的一半，metadata service 则是故事的的另一半
metadata service 为 cloud-init 提供自定义配置数据，cloud-init 完成配置工作
最高频的应用应用场景：将 ssh public key 添加到 instance。
1.首先在 “Project -> Compute -> Access & Security” 中创建 Key Pair。
2.public key 存放在 OpenStack 数据库中，private key 会在我们点击 “Create Key Pair” 按钮时自动下载
3.部署 instance 时，选择 公钥。
4.可以看到这个 cloudman 的 public key 已经保存到 .ssh/authorized_keys 中了
服务组件介绍： nova-api-metadata1.nova-api-metadata 是 nova-api 的一个子服务，它是 metadata 的提供者，instance 可以通过 nova-api-metadata 的 REST API 来获取 metadata 信息
2.nova-api-metadata 运行在控制节点上，服务端口是 8775，通过进程 ID 13415 查看该启动程序
3..nova-api-metadata 与常规的 nova-api 服务是合并在一起的。不过在 OpenStack 的其他发行版中可能有单独的 nova-api-metadata 进程存在
例如：
[root@controller1 neutron]# lsof -i:8775
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
nova-api 21913 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24369 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24371 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24373 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24375 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24376 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24380 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24382 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24385 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24386 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24388 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24391 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24393 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24394 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24395 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24396 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24399 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24401 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24402 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24404 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24405 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24408 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24409 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24410 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24412 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24413 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24416 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24419 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24422 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24423 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24424 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24428 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
nova-api 24432 nova 7u IPv4 2251998 0t0 TCP *:8775 (LISTEN)
可见，此环境是由nova-api来进行服务的
4.nova.conf通过参数 enabled_apis 指定是否启用 nova-api-metadata:
enabled_apis = osapi_compute,metadata
osapi_compute 是常规的 nova-api 服务，metadata 就是 nova-api-metadata 服务
neutron-metadata-agent
nova-api-metadata 在控制节点上，走 OpenStack 内部管理网络，instance 是无法通过 http://controller_ip:8775 直接访问 metadata service 的，因为网络不通
借助 neutron-metadata-agent
1.neutron-metadata-agent 运行在网络节点上,instance 先将 metadata 请求发给 neutron-metadata-agent，neutron-metadata-agent 再将请求转发到 nova-api-metadata
2.实际上 instance 是不能直接与 neutron-metadata-agent 通信的，因为 neutron-metadata-agent 也是在 OpenStack 内部管理网络上的。
3.不过好在网络节点上有另外两个组件，dhcp agent 和 l3 agent，它们两兄弟与 instance 可以位于同一 OpenStack network 中，这样就引出了下一个组件： neutron-ns-metadata-proxy
neutron-ns-metadata-proxy
1.neutron-ns-metadata-proxy 是由 dhcp-agent 或者 l3-agent 创建的，也运行在网络节点.更精确的说法是：运行在网络节点的 namespace 中
2.如果由 dhcp-agent 创建，neutron-ns-metadata-proxy 就运行在 dhcp-agent 所在的 namespace 中
3.如果由 l3-agent 创建，neutron-ns-metadata-proxy 就运行在 neutron router 所在的 namespace 中
4.neutron-ns-metadata-proxy 与 neutron-metadata-agent 通过 unix domain socket 直接相连
虚拟机获取元数据的流程：
这样整个链路就打通了：
1. instance 通过 neutron network（Project 网络）将 metadata 请求发送到 neutron-ns-metadata-proxy。
2. neutron-ns-metadata-proxy 通过 unix domain socket 将请求发给 neutron-metadata-agent。
3. neutron-metadata-agent 通过内部管理网络将请求发送给 nova-api-metadata。
神奇的 169.254.169.254
这是 metadata service 的 IP
这个地址来源于 AWS，当年亚马逊在设计公有云的时候，为了让 instance 能够访问 metadata，就将 169.254.169.254 这个特殊的 IP 作为 metadata 服务器的地址，instance 启动时就会向 169.254.169.254 请求 metadata。OpenStack 之后也沿用了这个设计
默认配置下，neutron-ns-metadata-proxy 是由 L3_agent 管理的
l3-agent方式：
虚拟机获取元数据的流程：
1.虚拟机访问169.254.169.254，从路由表中获取走向（qroute-路由的IP）。这条路由是 OpenStack 自动添加到 instance 中的，这样就将 metadata 的请求转发到 neutron router
2.qroute-路由器收到请求，会通过iptables规则转发到9697端口
3.9697端口是neutron-ns-metadata-proxy的监听端口
4.neutron-ns-metadata-proxy将请求通过unix domain socket发给neutron-metadata-agent
5.neutron-metadata-agent通过管理网络发给nova-api-metadata
那么如果将neutron-ns-metadata-proxy由dhcp-agent来进行管理呢？
1.配置dhcp配置文件
vim /etc/neutron/dhcp_agent.ini
[DEFAULT]
enable_isolated_metadata = True
2.重启neutron-dhcp-agent.service服务
systemctl restart neutron-dhcp-agent.service
3.查看控制节点上是否多了一个neutron-ns-metadata-proxy进程以networkID为26a7c666-5783-4697-b7e7-6bc96658d096 为例：
[root@controller1 neutron]# ip netns |grep 26a7c666
qdhcp-26a7c666-5783-4697-b7e7-6bc96658d096 (id: 0)
[root@controller1 neutron]#
[root@controller1 neutron]# ip netns exec qdhcp-26a7c666-5783-4697-b7e7-6bc96658d096 ifconfig
lo: flags=73 mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1 (Local Loopback)
RX packets 55907 bytes 22623425 (21.5 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 55907 bytes 22623425 (21.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ns-306e6c6e-5b: flags=4163 mtu 1500
inet 172.16.38.150 netmask 255.255.255.0 broadcast 172.16.38.255
inet6 fe80::f816:3eff:fe7a:6661 prefixlen 64 scopeid 0x20
ether fa:16:3e:7a:66:61 txqueuelen 1000 (Ethernet)
RX packets 423102184 bytes 42297849397 (39.3 GiB)
RX errors 0 dropped 6563 overruns 0 frame 0
TX packets 5890284 bytes 280241039 (267.2 MiB)
TX errors 0 dropped 4 overruns 0 carrier 0 collisions 0
4.查看该网段的一台虚拟机的路由：
[root@host-172-16-38-246 ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.16.38.254 0.0.0.0 UG 0 0 0 eth0
169.254.169.254 172.16.38.150 255.255.255.255 UGH 0 0 0 eth0
172.16.38.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
可看到访问169.254.169.254的路由是该dhcp-agent的地址
5.正是因为这条路由的存在，即便 l3-agent 与 dhcp-agent 同时提供 neutron-ns-metadata-proxy 服务，metadata 请求也只会发送给 dhcp-agent
同时我们也看到，dhcp-agent 已经将 IP 169.254.169.254 配置到了自己身上
[root@controller1 neutron]# ip netns exec qdhcp-26a7c666-5783-4697-b7e7-6bc96658d096 ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ns-306e6c6e-5b@if11: mtu 1500 qdisc noqueue state UP qlen 1000
link/ether fa:16:3e:7a:66:61 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 172.16.38.150/24 brd 172.16.38.255 scope global ns-306e6c6e-5b
valid_lft forever preferred_lft forever
inet 169.254.169.254/16 brd 169.254.255.255 scope global ns-306e6c6e-5b
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe7a:6661/64 scope link
valid_lft forever preferred_lft forever
dhcp-agent方式：
虚拟机获取metadata的流程：
1. 虚拟机请求metadata访问 http://169.254.169.254 实际上是发送了给dhcp-agent。
2 dhcp-agent的80端口是由neutron-ns-metadata-proxy监听。
3.neutron-ns-metadata-proxy 将请求通过 unix domain socket 发给 neutron-metadata-agent
4.neutron-metadata-agent通过管理网络发给nova-api-metadata
综上两种方式获取metadata的流程来看，instance必须首先能够正确获取DHCP IP，否则请求发送不到169.254.169.254
假如实例无法获取到IP或者metadata服务来获取元数据，实例还可以通过config drive的方式获取metadata
config drive的两种使用方式：
1.创建instance的时候通过 --config-drive true指定
2.使用iso9660或vfat ，没有实验过，暂不讨论这种方式
第一种方式的配置：
计算节点的nova.conf中需要配置force_config_drive = true
参考文档：https://www.cnblogs.com/CloudMan6/p/6648039.html
作者：YiRanMengJiangHu
