Shulou(Shulou.com)06/01 Report--

Today, I will talk to you about how instance gets information from nova-api-metadata. Many people may not know much about it. In order to make you understand better, the editor has summarized the following content for you. I hope you can get something from this article.

We will analyze in detail the complete process of instance obtaining information from nova-api-metadata through experiments.

Environment introduction

1. An all-in-one environment (similar to multiple nodes).

two。 Neutron network created test_net,DHCP has been started. In this metadata experiment, the type of test_net is not important, flat, vlan and vxlan are all fine.

3. There is no neutron router for now.

Ready to start the experiment.

Start instance to deploy an instance through the cirros image, named C1, and select the network test_net. During the startup process, view the startup log of instance.

We see two messages in the log above:

① instance got IP 17.17.17.5 from DHCP, which is easy to understand because of the DHCP service we started on test_net.

② instance will visit http://169.254.169.254/2009-04-04/instance-id and 20 attempts have failed.

The magical 169.254.169.254

What address is 169.254.169.254?

This is metadata service's IP.

This address comes from AWS. When Amazon designed the public cloud, in order to enable instance to access metadata, it used the special IP of 169.254.169.254 as the address of the metadata server. When instance started, it would request metadata from 169.254.169.254. OpenStack has followed this design since then.

The problem we have now is that 169.254.169.254 cannot be accessed. Cirros's cloud-init obviously didn't get the metadata, at least from the fact that instance's hostname wasn't set to C1.

As we described earlier in the Metadata Service architecture section, instance first sends metadata requests to DHCP agent or neutron-ns-metadata-proxy managed by L3_agent. So who is running neutron-ns-metadata-proxy right now? Let's take a look at the progress of neutron-ns-metadata-proxy on the control node.

There is no neutron-ns-metadata-proxy running at all!

The reason is that by default, neutron-ns-metadata-proxy is managed by L3_agent (DHCP will be discussed later). Since the current test_net is not attached to neutron router, neutron-ns-metadata-proxy is not started.

Adding router to solve this problem is simple: create a virtual router test_router and connect to test_net.

The neutron-ns-metadata-proxy managed by test_router can now be seen on the control node.

Restart instance C1 to see what happens.

Instance successfully accessed 169.254.169.254. As a result, cloud-init has got the metadata because hostname has been set to C1.

After reading the above, do you have any further understanding of how instance gets information from nova-api-metadata? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.