openstack metadata和cloudinit的原理和使用_cloudbase-init原理

实现 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-metadata

1.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<UP,LOOPBACK,RUNNING> mtu 65536
    inet 127.0.0.1 netmask 255.0.0.0
    inet6 ::1 prefixlen 128 scopeid 0x10<host>
    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<UP,BROADCAST,RUNNING,MULTICAST> 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<link>
    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: <LOOPBACK,UP,LOWER_UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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