Почему Metadata API важна для облачных инстансов
В любой публичной или приватной облачной инфраструктуре, построенной на OpenStack, виртуальные машины нуждаются в доступе к служебному сервису Metadata API. Этот сервис предоставляет инстансам информацию о конфигурации, ключах доступа, пользовательских данных и других параметрах, необходимых при первом запуске. Доступ к метаданным реализуется через HTTP‑запросы к адресу 169.254.169.254, который должен быть доступен из каждой виртуальной машины без участия внешних маршрутизаторов.
При традиционном стеке Neutron, основанном на Linux‑bridge или OVS, доступ к Metadata API достигается с помощью NAT‑правила и router‑gateway, которые подменяют запросы к 169.254.169.254 на реальный IP‑адрес сервиса (metadata‑service). При переходе к OVN (Open Virtual Network) как бэкенду для Neutron появляется необходимость адаптировать эту схему под модель логических переключателей и маршрутизаторов, которыми управляет OVN.
Архитектурные особенности OVN, влияющие на Metadata API
OVN представляет собой набор контроллеров (ovn-northd, ovn-controller) и базу данных (OVN_Northbound, OVN_Southbound), в которых описываются логические сети, логические роутеры и ACL. В отличие от традиционного OVS, где правила пишутся непосредственно в таблицы коммутатора, OVN генерирует конфигурацию на лету, синхронизируя её с гипервизорами. Это накладывает несколько ограничений на реализацию Metadata API:
- Отсутствие прямого доступа к физическому интерфейсу – все пакеты проходят через логический роутер, а не через обычный Linux‑bridge.
- Наличие единой точки NAT – OVN поддерживает только один NAT‑правило на логический роутер, поэтому необходимо правильно разместить правило для
169.254.169.254. - ACL‑фильтрация – по умолчанию OVN блокирует весь входящий трафик, если не заданы соответствующие правила.
Для корректного функционирования Metadata API необходимо создать в OVN логический роутер, который будет выполнять SNAT/DNAT‑преобразования и обеспечивать доступ к сервису из любой подсети проекта.
Пошаговая схема реализации
1. Создание логического роутера и внешней сети
openstack router create ovn-metadata-router
openstack router set --external-gateway public-net ovn-metadata-router
Внутри OVN будет автоматически создан логический роутер lr-<uuid> с привязанным logical switch (LS) для каждой сети проекта.
2. Добавление статической NAT‑правила для Metadata API
OVN поддерживает static NAT через команду ovn-nbctl. Нужно создать правило, которое будет перенаправлять запросы к 169.254.169.254 на реальный IP‑адрес сервиса (обычно 169.254.169.254 на хосте контроллера, но может быть любой доступный адрес).
ovn-nbctl -- --id=@nat create NAT \
type=dnat \
logical_ip=169.254.169.254 \
external_ip=<METADATA_SERVICE_IP> \
logical_port=lr-<router_uuid> \
-- add Logical_Router lr-<router_uuid> nat @nat
Здесь <METADATA_SERVICE_IP> – это IP‑адрес, под которым сервис metadata слушает запросы (часто это IP хоста metadata‑service, доступный из сети управления).
3. Настройка ACL для разрешения трафика к Metadata API
По умолчанию OVN блокирует любые входящие пакеты. Нужно добавить правило, разрешающее HTTP‑трафик (порт 80) от любой VM к 169.254.169.254.
ovn-nbctl -- --id=@acl create ACL \
action=allow \
direction=to-lport \
priority=100 \
match="inport == \"lr-<router_uuid>\" && ip && tcp && tp_dst == 80 && ip4 && ip_src == 169.254.169.254" \
-- add Logical_Router lr-<router_uuid> acls @acl
Если используется HTTPS (порт 443), следует добавить аналогичное правило для tp_dst == 443.
4. Привязка подсетей к роутеру
Для каждой сети проекта необходимо установить связь с роутером, чтобы трафик из VM мог проходить через него.
openstack router add subnet ovn-metadata-router <subnet-id>
После выполнения этой команды OVN автоматически создаст logical switch port на роутере, через который будет осуществляться маршрутизация.
5. Проверка работоспособности
Запустите VM в любой из подключенных подсетей и выполните:
curl http://169.254.169.254/openstack/latest/meta_data.json
Ответ должен содержать JSON‑объект с метаданными инстанса. Если запрос завершился ошибкой, проверьте:
- Правильность NAT‑правила (логический IP и внешний IP).
- Наличие ACL, разрешающих трафик.
- Корректность привязки подсети к роутеру.
Особенности и подводные камни
- Одно NAT‑правило на роутер. Если в инфраструктуре уже используется NAT для других целей (например, доступ к внешнему Интернету), необходимо объединять правила в один объект
NATс несколькими диапазонами, иначе возникнет конфликт. - Служебный IP 169.254.169.254 может конфликтовать с другими сервисами, использующими link‑local адреса. При наличии таких конфликтов рекомендуется переназначить внешний IP сервиса
metadataи обновить NAT‑правило. - Скалирование. При большом количестве проектов каждый роутер будет хранить собственные NAT‑правила и ACL. Это увеличивает размер базы данных OVN, но в большинстве случаев не приводит к заметному падению производительности.
- Обновление OpenStack. Начиная с версии Queens, OpenStack поддерживает встроенный механизм
metadata_proxyв Neutron, который автоматически создаёт нужные правила. При переходе на OVN рекомендуется отключатьmetadata_proxyи использовать описанную схему, чтобы избежать дублирования NAT‑правил.
Интеграция с CI/CD и автоматизацией
Для обеспечения согласованности конфигурации при динамическом создании проектов можно включить вышеописанные команды в Heat‑шаблоны или Terraform‑модули. Пример фрагмента Heat:
resources:
OvRouter:
type: OS::Neutron::Router
properties:
external_gateway_info:
network: public-net
MetadataNAT:
type: OS::Neutron::Port
properties:
network: private-net
device_owner: network:router_interface
Дальнейшее выполнение ovn-nbctl‑команд можно вынести в Ansible‑ролль, которая будет запускаться после создания роутера, гарантируя, что NAT‑правило и ACL всегда находятся в актуальном состоянии.
Вывод
Реализация Metadata API в окружении OpenStack с OVN в роли Neutron‑backend требует создания логического роутера, настройки статического DNAT‑правила и соответствующих ACL. Несмотря на различия в архитектуре, OVN предоставляет гибкие инструменты (ovn-nbctl, ovn-sbctl) для декларативного описания сетевых политик, что упрощает автоматизацию и поддержание консистентности конфигурации. Правильное сочетание NAT, ACL и привязки подсетей обеспечивает надёжный и масштабируемый доступ к служебным метаданным для всех виртуальных машин в облаке.