Чтобы получить чистое Markdown-содержимое этой страницы, добавьте .md к этому URL. Полный индекс документации см. на https://docs.nvidia.com/dynamo/llms.txt. Полное содержимое, включая справочник API и примеры SDK, см. на https://docs.nvidia.com/dynamo/llms-full.txt.
Плоскость обнаружения
Слой обнаружения сервисов Dynamo позволяет компонентам находить друг друга во время выполнения. Воркеры регистрируют свои конечные точки при запуске, а frontend-компоненты обнаруживают их автоматически. Механизм обнаружения адаптируется к среде развертывания.
Механизмы обнаружения
| Развертывание | Механизм обнаружения | Конфигурация |
|---|---|---|
| Kubernetes (с оператором Dynamo) | Нативный K8s (CRDs, EndpointSlices) | Оператор задает DYN_DISCOVERY_BACKEND=kubernetes |
| Bare metal / локально (по умолчанию) | etcd | ETCD_ENDPOINTS (по умолчанию http://localhost:2379) |
Примечание: Среда выполнения всегда по умолчанию использует etcd. Обнаружение через Kubernetes нужно включить явно; оператор Dynamo делает это автоматически.
Обнаружение в Kubernetes
При работе в Kubernetes с оператором Dynamo обнаружение сервисов использует нативные ресурсы Kubernetes вместо etcd.
Как это работает
- Воркеры регистрируют свои конечные точки, создавая пользовательские ресурсы DynamoWorkerMetadata.
- EndpointSlices сообщают системе о готовности pod.
- Компоненты отслеживают изменения CRD, чтобы обнаруживать доступные воркеры.
Преимущества
- Не требуется внешний кластер etcd.
- Нативная интеграция с жизненным циклом pod в Kubernetes.
- Автоматическая очистка при завершении pods.
- Работает со стандартным RBAC Kubernetes.
Переменные окружения (внедряются оператором)
| Переменная | Описание |
|---|---|
DYN_DISCOVERY_BACKEND | Задается как kubernetes |
POD_NAME | Имя текущего pod |
POD_NAMESPACE | Текущее пространство имен |
POD_UID | Уникальный идентификатор pod |
Обнаружение через etcd (по умолчанию)
Если DYN_DISCOVERY_BACKEND не задана (или задана как etcd), для обнаружения сервисов используется etcd.
Конфигурация подключения
| Переменная | Описание | Значение по умолчанию |
|---|---|---|
ETCD_ENDPOINTS | URL etcd, разделенные запятыми | http://localhost:2379 |
ETCD_AUTH_USERNAME | Имя пользователя для basic auth | Нет |
ETCD_AUTH_PASSWORD | Пароль для basic auth | Нет |
ETCD_AUTH_CA | Путь к сертификату CA (TLS) | Нет |
ETCD_AUTH_CLIENT_CERT | Путь к клиентскому сертификату | Нет |
ETCD_AUTH_CLIENT_KEY | Путь к клиентскому ключу | Нет |
Пример:
export ETCD_ENDPOINTS=http://etcd-0:2379,http://etcd-1:2379,http://etcd-2:2379
Регистрация сервисов
Воркеры регистрируют свои конечные точки в etcd с такой иерархией ключей:
/services/{namespace}/{component}/{endpoint}/{instance_id}
Например:
/services/vllm-agg/backend/generate/694d98147d54be25
Frontend-компоненты и маршрутизаторы обнаруживают доступные воркеры, отслеживая соответствующий префикс и получая обновления в реальном времени, когда воркеры присоединяются или уходят.
Очистка на основе lease
Каждая среда выполнения поддерживает lease в etcd (TTL по умолчанию: 10 секунд). Если воркер аварийно завершает работу или теряет соединение:
- Keep-alive heartbeats прекращаются.
- Lease истекает после TTL.
- Все зарегистрированные конечные точки автоматически удаляются.
- Клиенты получают события удаления и перенаправляют трафик на здоровые воркеры.
Это гарантирует очистку устаревших конечных точек без ручного вмешательства.
KV Store
Dynamo предоставляет абстракцию KV store для хранения метаданных (экземпляров конечных точек, карточек развертывания моделей, каналов событий). Поддерживается несколько механизмов хранения:
| Backend | Сценарий использования |
|---|---|
| etcd | Production-развертывания |
| Memory | Тестирование и разработка |
| NATS | Развертывания только с NATS |
| File | Локальное постоянное хранение |
Операционные рекомендации
Используйте обнаружение Kubernetes в K8s
Оператор Dynamo автоматически задает DYN_DISCOVERY_BACKEND=kubernetes для pods. Дополнительная настройка не требуется.
Разверните кластер etcd для bare metal
Для production-развертываний на bare metal разверните кластер etcd из 3 узлов для высокой доступности.
Настраивайте TTL для lease
Найдите баланс между скоростью обнаружения сбоев и накладными расходами:
- Короткий TTL (5s) — более быстрое обнаружение сбоев, больше keep-alive-трафика.
- Длинный TTL (30s) — меньше накладных расходов, более медленное обнаружение.
Значение по умолчанию (10s) — разумная отправная точка для большинства развертываний.
Связанная документация
- Плоскость событий — Pub/sub для событий KV cache и метрик воркеров
- Distributed Runtime — архитектура среды выполнения
- Плоскость запросов — конфигурация транспорта запросов
- Отказоустойчивость — обработка сбоев