今天就跟大家聊聊有关 instance如何从 nova-api-metadata 获取信息,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。我们将通过实验详细分析 instance 从 nova-api-metadata 获取信息的完整过程。1. 一个 all-in-one 环境(多节点类似)。
2. 已创建 neutron 网络test_net,DHCP 已启动。在这个 metadata 实验中,test_net的 type 不重要,flat、vlan、vxlan 都可以。3. 暂无 neutron router。准备就绪,开始实验。上面的 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是个什么地址?这是 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。现在控制节点上已经能够看到test_router管理的 neutron-ns-metadata-proxy 了。重启 instancec1,看会发生怎样的变化。instance 成开发云主机域名功访问到169.254.169.254。从结果看,cloud-init 已经获取到 metadata,因为 hostname 已经设置为c1。看完上述内容,你们对 instance如何从 nova-api-metadata 获取信息有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注开发云行业资讯频道,感谢大家的支持。
本篇文章为大家展示了为什么网站可以不用虚拟主机,内容简明扼要并且容易理解,绝对能使你眼前一亮,通过这篇文章的详细介绍希望你能有所收获。对于建站来说,虚拟主机是比较早的空间产品,价格便宜。但并不是所有的网站都适合使用虚拟主机,有的网站可以不用虚拟主机,而选择云服…
免责声明:本站发布的图片视频文字,以转载和分享为主,文章观点不代表本站立场,本站不承担相关法律责任;如果涉及侵权请联系邮箱:360163164@qq.com举报,并提供相关证据,经查实将立刻删除涉嫌侵权内容。