获取 metadata 的完整例子 - 每天5分钟玩转 OpenStack(166)

信息
の324
cpongo8808

我们将通过实验详细分析 instance 从 nova-api-metadata 获取信息的完整过程。

 

环境介绍

 

1. 一个 all-in-one 环境(多节点类似)。
 

2. 已创建 neutron 网络 test_net,DHCP 已启动。在这个 metadata 实验中, test_net 的 type 不重要,flat、vlan、vxlan 都可以。

 

 

3. 暂无 neutron router。

 

准备就绪,开始实验。

 

启动 instance

 

通过 cirros 镜像部署一个 instance,命名为 c1,选择网络 test_net。启动过程中,查看 instance 的启动日志。

 

上面的 log 中我们看到两个信息:

 

① instance 从 DHCP 拿到了 IP 17.17.17.5,这个好理解,因为我们在test_net 上开启的 DHCP 服务。

 

② instance 会去访问 http://169.254.169.254/2009-04-04/instance-id,尝试了 20 次都失败了。

 

神奇的 169.254.169.254

 

169.254.169.254 是个什么地址?

 

这是 metadata service 的 IP。

 

这个地址来源于 AWS,当年亚马逊在设计公有云的时候,为了让 instance 能够访问 metadata,就将 169.254.169.254 这个特殊的 IP 作为 metadata 服务器的地址,instance 启动时就会向 169.254.169.254 请求 metadata。OpenStack 之后也沿用了这个设计。

 

我们现在遇到的问题是 169.254.169.254 没法访问啊!cirros 的 cloud-init 显然是没有拿到 metadata 的,这点至少可以从 instance 的 hostname 没有被设置为 c1 判断出来。

 

 

前面我们在 Metadata Service 架构部分介绍了,instance 首先会将 metadata 请求发送给 DHCP agent 或者 L3_agent 管理的 neutron-ns-metadata-proxy。那目前到底是谁在管理 neutron-ns-metadata-proxy 呢?我们先在控制节点上查看一下 neutron-ns-metadata-proxy 的进程。

 

 

 

 

尽然没有 neutron-ns-metadata-proxy 在运行!

 

其原因是:默认配置下,neutron-ns-metadata-proxy 是由 L3_agent 管理的(后面会讨论让 DHCP 来管理),由于当前 test_net 并没有挂在 neutron router 上,所以没有启动 neutron-ns-metadata-proxy。

 

添加 router

 

要解决这个问题很简单:创建虚拟路由器 test_router 并连接 test_net。

 

 

现在控制节点上已经能够看到 test_router 管理的 neutron-ns-metadata-proxy 了。

 

 

 

重启 instance c1,看会发生怎样的变化。

 

 

instance 成功访问到 169.254.169.254。从结果看,cloud-init 已经获取到 metadata,因为 hostname 已经设置为 c1。

 

 

下一节我们详细分析 c1 是如何拿到 metadata 的。

 

展开阅读全文
评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值