{"schema_version":"1.0","service":"Publicasta","type":"article","id":946,"slug":"telltaledns_060_kubernetes_dns_failover_drills","title":"TelltaleDNS 0.6.0 упрощает тестирование DNS в смешанных средах Raspberry Pi и Kubernetes","excerpt":"TelltaleDNS 0.6.0 добавляет видимость рабочих нагрузок Kubernetes, сценарии проверки отказоустойчивости и HTTPS для веб-API. Релиз стоит протестировать в домашних лабораториях и небольших кластерах, но статус до версии 1.0 и оговорка по DNSSEC исключают бездумное внедрение в продакшене.","language":"ru","default_language":"en","canonical_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=ru","image":{"url":"https://publicasta.com/storage/projects/10/pages/946/2026/10/2247bc95-4ecf-4e69-af99-5c32bd43e6ad.webp","alt":"Оборудование домашней лаборатории Raspberry Pi и Kubernetes, подключённое для проверки отказоустойчивости DNS"},"publisher":{"id":10,"slug":"open_source_radar","name":"Open Source радар","url":"https://publicasta.com/open_source_radar"},"author":{"name":"Anton R"},"published_at":"2026-10-23T06:39:17+00:00","updated_at":"2026-10-23T06:39:17+00:00","content_markdown":"## Что именно меняет TelltaleDNS 0.6.0\n\n ![Оборудование домашней лаборатории Raspberry Pi и Kubernetes, подключённое для проверки отказоустойчивости DNS](https://publicasta.com/storage/projects/10/pages/946/2026/10/2247bc95-4ecf-4e69-af99-5c32bd43e6ad.webp)\n\n Выпущенный 20 октября 2026 года TelltaleDNS 0.6.0 посвящён не столько добавлению ещё одного DNS-сервера общего назначения, сколько тому, чтобы смешанную среду было проще наблюдать и проверять на практике. Самое заметное изменение — поддержка Kubernetes: рабочие нагрузки могут отображаться как именованные устройства в веб-интерфейсе и истории запросов. Это даёт оператору более полезный ответ на знакомый вопрос — какой клиент выполнил запрос, — когда иначе ответ скрывался бы за кластерной сетью, общими адресами резолверов или метками на уровне инфраструктуры.\n\n Это различие важно, поскольку релиз посвящён не только разрешению имён, но и операционной видимости. Запись с указанием рабочей нагрузки Kubernetes можно изучать рядом с обычными устройствами, чтобы проще сопоставлять активность кластера с запросами Raspberry Pi, рабочей станции или другого сетевого клиента. Функция не превращает любую проблему DNS в простую, но убирает один уровень неопределённости: оператор получает именованную рабочую нагрузку для расследования, а не только адрес или неразделимый поток запросов.\n\n Второе крупное нововведение — встроенная проверка отказоустойчивости. TelltaleDNS может намеренно останавливать выбранные узлы на интервалы от 15 до 300 секунд, а затем сообщать, какие клиенты переключились во время проверки. Важно, что это контролируемый тест поведения, а не просто индикатор состояния. Установка может выглядеть исправной, пока все узлы доступны, но всё равно дать сбой, если один из них исчезнет, клиенты сохранят старый ответ или маршрутизация не перенаправит трафик ожидаемым образом. Проверка выявляет этот разрыв без необходимости ждать незапланированного отказа.\n\n Диапазон длительности позволяет настраивать тест. Короткое прерывание покажет, реагируют ли клиенты достаточно быстро; более продолжительное — сохраняется ли стабильность резервного режима после первого цикла повторных попыток. Полученный отчёт должен связать событие отказа с перемещением клиентов, чтобы оператор мог изучить фактические изменения, а не предполагать, что резервирование сработало лишь потому, что существовал запасной узел. Это особенно актуально для небольших установок, где DNS часто собирается из нескольких машин и проверяется нечасто.\n\n В релизе также появилась поддержка HTTPS для веб-интерфейса и API. Это меняет способы публикации и доступа к поверхности управления, но оставляет сам DNS-сервис отдельным от вопроса о защите административных конечных точек. Поэтому HTTPS — практическое улучшение развёртывания, однако его следует оценивать как часть общей конфигурации доверия: клиенты и администраторы должны распознавать сертификат, используемый интерфейсом, а руководство по развёртыванию остаётся источником информации о поддерживаемой схеме.\n\n Помимо главных функций, версия 0.6.0 улучшает работу с зашифрованными соединениями к вышестоящим серверам и проверки готовности. В совокупности эти изменения упрощают размещение сервиса в топологии, где важны наблюдаемость конфиденциальности соединений с вышестоящими узлами и доступности сервиса. Они не отменяют необходимости тестировать фактический путь разрешения. На работу с зашифрованным соединением по-прежнему могут влиять удалённая конечная точка или локальная конфигурация, а сигналы готовности полезны только тогда, когда соответствуют состоянию, которое действительно важно оператору.\n\n Релиз следует воспринимать как конкретный шаг в текущем направлении проекта, а не как обещание, что все пункты более широкой дорожной карты уже доступны. Описанные здесь изменения — именование рабочих нагрузок Kubernetes, проверки отказоустойчивости, HTTPS, работа с зашифрованными вышестоящими соединениями и улучшения проверок готовности. Другие запланированные возможности не следует считать выпущенными лишь потому, что они соответствуют общей архитектуре проекта. Для тех, кто оценивает TelltaleDNS, эта граница полезна: версию 0.6.0 можно тестировать на предоставляемом сегодня поведении, тогда как дорожная карта остаётся отдельным набором будущих ожиданий.\n\n ## Почему смешанная архитектура Pi и Kubernetes имеет значение\n\n Смешанная конфигурация Raspberry Pi и Kubernetes часто работает без проблем — до тех пор, пока не потребуется что-то диагностировать. Служба DNS может работать на Pi или рядом с ним, тогда как приложения и поддерживающие их сервисы находятся внутри кластера. У Kubernetes есть собственный уровень именования и обнаружения сервисов: за разрешение имен внутри кластера отвечает CoreDNS, а остальная домашняя или небольшая офисная сеть зависит от основного резолвера. Панели устройств дают еще один взгляд на окружение. Каждый компонент по отдельности может быть исправен, но оператору все равно приходится восстанавливать путь, который прошел конкретный запрос.\n\n Такая фрагментация важна потому, что сбои DNS редко выглядят как чистая авария одной системы. Клиент может обращаться к публичным именам, но не разрешать имя внутреннего сервиса. Рабочая нагрузка может быть доступна изнутри кластера, но недоступна устройству в локальной сети. Изменение узла способно поменять место обработки запроса или доступный резолвер, не делая первопричину очевидной по обычному списку устройств. В небольшой среде обычно нет отдельной команды мониторинга, которая связала бы эти сигналы. Человеку, обслуживающему Pi, резолвер и кластер, нужна операционная картина, охватывающая все эти границы.\n\n TelltaleDNS 0.6.0 призван сделать эту картину более цельной. Его интеграция с Kubernetes показывает рабочие нагрузки как именованные устройства в интерфейсе и истории запросов. Благодаря этому меняется сам вопрос, который может задать оператор. Вместо одного адреса или непрозрачного идентификатора клиента расследование можно строить вокруг рабочей нагрузки, создавшей запрос. Запрос, связанный с приложением Kubernetes, можно рассматривать вместе с запросами обычных сетевых клиентов, поэтому резолвер больше не выглядит сервисом, обслуживающим два никак не связанных мира.\n\n Та же идея распространяется на представления внутренних имен. Имена, используемые внутри кластера, и приватные обратные запросы отличаются по назначению от публичного DNS-трафика, но при устранении неполадок все они должны рассматриваться в рамках одной истории, если Pi и Kubernetes совместно отвечают за разрешение имен. Объединение этих представлений в одной плоскости управления упрощает проверку: ограничена ли проблема именем внутри кластера, затрагивает ли она поиск частных адресов или связана с маршрутом между кластером и остальной сетью. Ценность не в том, что интерфейс устраняет нижележащие уровни, а в том, что дает оператору общее место для наблюдения за их поведением.\n\n Маршрутизация с учетом узлов добавляет еще одно полезное измерение. В кластере путь ответа может зависеть от того, какой узел обслуживает рабочую нагрузку или обрабатывает запрос. Резолвер, способный учитывать эту связь, делает тестирование отказоустойчивости более конкретным: оператор может проверить, что происходит при недоступности выбранного узла, какие клиенты перемещаются и соответствует ли итоговое поведение предполагаемой топологии. Это информативнее, чем просто убедиться, что процесс DNS продолжает работать. Такой подход связывает доступность с рабочими нагрузками и клиентами, зависящими от данного маршрута.\n\n Для домашних лабораторий и небольших операторов это особенно актуально, поскольку цель обычно не в создании крупной абстрактной платформы обнаружения сервисов. Важно сохранить понятность умеренной по размеру среды по мере ее роста. Raspberry Pi может обеспечивать стабильное место для сетевых служб, а Kubernetes — удобную среду для приложений, которым нужны повторяемое развертывание и внутреннее именование. Операционная задача заключается в том, чтобы сохранить ясную связь между этими частями. Метки рабочих нагрузок, видимость внутренних имен и поведение с учетом узлов в TelltaleDNS указывают именно на такую общую связь, а не рассматривают кластер как замкнутый ящик.\n\n Однако важно различать видимость и полномочия. Единая плоскость управления не отменяет необходимости понимать фактическую DNS-топологию. Руководство по развертыванию остается главным источником сведений о том, как должны быть расположены компоненты и в каком порядке следует вносить изменения. Операторам стоит использовать интерфейс для наблюдения и тестирования среды, а документированную модель развертывания — чтобы определить, где должны находиться резолвер, интеграция с кластером и клиентский трафик. Такое разделение не позволяет полезной панели превратиться в замену знаниям о конфигурации.\n\n Новый релиз также проще безопасно оценивать. Смешанная архитектура особенно полезна, когда помогает ответить на практические вопросы, возникающие на границе между системами: какая рабочая нагрузка отправила запрос? Какой узел был задействован? Было ли имя локальным для кластера, частным или внешним? Переключились ли клиенты ожидаемым образом после вывода узла из эксплуатации? Если на эти вопросы можно ответить по единой истории запросов и представлению управления, небольшой кластер из Raspberry Pi и Kubernetes становится понятнее во время обслуживания и аварийных учений. Речь не о том, что любая проблема DNS вдруг станет простой, а о более удобном для тестирования способе увидеть взаимодействие компонентов.\n\n ## Разумный план тестирования перед сменой сетевого DNS\n\n Рассматривайте TelltaleDNS 0.6.0 как объект контролируемой проверки, а не как повод немедленно направить все клиенты к новому резолверу. Начните с помеченного релиза и на протяжении всего теста сохраняйте доступ к заведомо исправному резолверу. Такая подстраховка важна, поскольку DNS участвует в цепочке доступа почти ко всем остальным сервисам: если в новом развёртывании окажется ошибка топологии, недоверенный сертификат или проблема с повторными запросами к вышестоящему серверу, восстановление должно быть осознанным изменением конфигурации, а не импровизированным ремонтом. Поэтому первый этап следует проводить параллельно с существующей схемой, направив к TelltaleDNS лишь небольшую группу некритичных клиентов.\n\n До изменения настроек клиентов зафиксируйте имена, которые должен обслуживать тест. В смешанной среде Raspberry Pi и Kubernetes сюда входит пространство кластера `cluster.local`, а также частные обратные запросы. Проверьте, где должен разрешаться каждый класс имён и зависит ли путь ответа от конкретного узла или вышестоящего сервера. Цель не сводится к тому, чтобы убедиться: браузер открывает знакомый сервис. Полезный тест должен показать, что имена рабочих нагрузок, внутренних устройств и обратные записи остаются видимыми и пригодными для использования с тех клиентов, которым они действительно нужны. Держите эту схему явной: резолвер может выглядеть исправным и при этом незаметно отправлять внутренний запрос не туда.\n\n HTTPS требует отдельной контрольной точки. В релизе появилась поддержка HTTPS для веб-интерфейса и API, поэтому проверьте доверие к сертификату с тех машин и через те инструменты, которые будут администрировать или отслеживать сервис. Страница, открывающаяся только после обхода предупреждения, не является успешным операционным тестом: цепочка сертификатов и ожидания по имени хоста должны корректно работать для предусмотренных клиентов управления. Проверьте API так же, как браузерный интерфейс, поскольку путь автоматизации может сломаться даже при нормально выглядящей панели. Запишите точную конечную точку и предположения о доверии, использованные в тесте, чтобы их можно было воспроизвести после обновления или изменения топологии.\n\n Когда базовое разрешение имён и администрирование заработают, проведите учение по отказоустойчивости на некритичной группе клиентов. Эта функция позволяет намеренно остановить выбранные узлы на заданный интервал от 15 до 300 секунд и показать, какие клиенты переключились. Используйте её как упражнение по наблюдению: определите останавливаемые узлы, зафиксируйте ожидаемое поведение клиентов и проследите, продолжают ли они разрешать имена по доступному пути. Не начинайте со всей сети. Небольшая тестовая группа помогает отличить запланированную передачу обслуживания от более масштабного сбоя, вызванного неправильным маршрутом, устаревшей настройкой клиента или неполным сопоставлением внутренних имён.\n\n Во время учения изучайте не только итог. История запросов должна показать, что запрашивали клиенты, пока выбранные узлы были недоступны, а отчёт о переключении — сделать перемещение клиентов видимым. Поведение готовности — ещё один важный сигнал: проверьте, как сервис представляет себя до и после прерывания работы узла, не считая работающий процесс автоматически готовым резолвером. После учения восстановите выбранные узлы и повторите достаточное число проверок клиентов, чтобы убедиться: трафик вернулся на ожидаемый путь. Обратимый тест — это тест, в котором и отказ, и восстановление видны в журналах и в реальном поведении клиентов.\n\n Тот же поэтапный подход применим и к работе с зашифрованными вышестоящими серверами. Сначала проверьте обычные запросы, затем понаблюдайте, как резолвер ведёт себя, когда соединению с зашифрованным вышестоящим сервером требуется повторная попытка. Ищите корректный сценарий восстановления, а не полагайтесь на один успешно выполненный запрос. Цель — понять, что происходит при прерывании соединения, а не просто продемонстрировать возможность включить шифрование. Ограничьте тестовый трафик и сохраняйте проверенный резолвер, пока не станут понятны поведение при повторной попытке, сигналы готовности, журналы запросов и результаты для внутренних имён.\n\n Лишь после этих проверок следует подключать больше клиентов. Меняйте по одной зависимости за раз, сохраняйте документированный план отката и сравнивайте поведение при реальных шаблонах трафика, которые создаёт сеть. Сюда входят как обычные запросы устройств, так и имена, связанные с Kubernetes, а также частные обратные запросы. Если результат окажется неожиданным, верните затронутых клиентов к проверенному резолверу и изолируйте причину, прежде чем расширять эксперимент. Так релиз становится полезным инструментом для проверяемой эксплуатации, при этом учитывается, что изменения DNS могут сразу повлиять на всю среду.\n\n ## Ограничения, лицензирование и альтернативы\n\n К TelltaleDNS 0.6.0 лучше относиться как к проекту для тестирования, а не как к готовой замене устоявшейся DNS-платформы. Проект всё ещё находится до версии 1.0, поэтому по мере развития могут меняться ключи конфигурации, интерфейсы и API. Это особенно важно для операторов, которые хотят поставить его перед сетью и затем не возвращаться к настройкам: после обновления может потребоваться проверить инструкции по развёртыванию, пересмотреть конфигурацию и убедиться, что панель управления по-прежнему отражает ту же топологию резолверов. Релиз полезен тем, что упрощает проверку и испытание DNS в смешанной среде Raspberry Pi и Kubernetes, но это не отменяет эксплуатационной работы, связанной с ключевой сетевой службой.\n\n В примечаниях к релизу также указано конкретное ограничение DNSSEC, которое должно учитываться при любой оценке. В режиме проверки запуск может завершиться ошибкой, из-за чего до кеширования необходимых ключей появляются ответы `SERVFAIL`. Обнаруживать это в ходе масштабной миграции сети не следует. Тем, кто тестирует проверку DNSSEC, нужно изолировать эксперимент, наблюдать за запуском и состоянием готовности, а также убедиться, что после заполнения кеша ответы восстанавливаются ожидаемым образом. На время проверки должен оставаться доступным проверенный резолвер, а план отката должен быть достаточно простым, чтобы воспользоваться им без зависимости от работоспособности новой службы. Важно отличать контролируемую проверку этого ограничения от предположения, будто успешный базовый запрос доказывает готовность каждого режима резолвера к эксплуатации.\n\n Лицензию сравнительно легко проверить. В репозитории есть и `LICENSE-APACHE`, и `LICENSE-MIT`, то есть проект распространяется с двумя файлами лицензий; перед перераспределением или включением в более крупную систему их следует изучить вместе с собственными условиями репозитория. Документация проекта и материалы релиза также заявляют о подписанных образах и ведомости состава программного обеспечения. Для оператора, решающего, как тестировать и развёртывать ПО, это полезные сигналы в отношении цепочки поставок, но они не заменяют проверку фактического источника образа, процесса верификации подписи, происхождения сборки и содержимого SBOM в среде, где будет работать служба. Их следует считать данными для проверки, а не универсальным выводом о безопасности.\n\n Таким образом, TelltaleDNS занимает практическое промежуточное положение для пользователей Pi-hole или Technitium. Его разумно оценивать, когда речь идёт именно о небольшой смешанной среде, где инфраструктуру Raspberry Pi и рабочие нагрузки Kubernetes нужно видеть в единой операционной картине и где поведение при отказе можно проверить до внесения изменений. Гораздо менее разумно считать релиз универсальной заменой лишь потому, что один проект объединяет видимость рабочих нагрузок, учения, HTTPS и работу с зашифрованными вышестоящими серверами. Существующие резолверы могут оставаться лучшим выбором, если их текущее поведение, документация, интеграции или стабильность уже соответствуют требованиям сети.\n\n Поэтому обоснованное решение должно зависеть от результата поэтапного тестирования, а не только от списка возможностей. Запустите помеченный тегом релиз, сохраните доступ к текущему резолверу, проверьте частные и локальные для кластера имена, подтвердите доверие к сертификатам, изучите поведение запросов и состояния готовности, а затем повторите испытание отказоустойчивости на некритичных клиентах. В критерии приёмки включите запуск в режиме проверки DNSSEC и зафиксируйте порядок восстановления и отката. Если эти проверки пройдут успешно, TelltaleDNS 0.6.0 может стать убедительным экспериментом для домашней лаборатории или небольшого кластера. Если нет, статус до версии 1.0 и документированное ограничение DNSSEC дают понятные основания отложить внедрение и продолжить использовать существующую DNS-службу.","available_translations":[{"language":"ar","title":"يجعل TelltaleDNS 0.6.0 اختبار DNS المختلط بين Raspberry Pi وKubernetes أسهل","html_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=ar","markdown_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.md?lang=ar","json_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/telltaledns_060_kubernetes_dns_failover_drills?lang=ar"},{"language":"de","title":"TelltaleDNS 0.6.0 erleichtert Tests für gemischte DNS-Umgebungen mit Raspberry Pi und Kubernetes","html_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=de","markdown_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.md?lang=de","json_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/telltaledns_060_kubernetes_dns_failover_drills?lang=de"},{"language":"en","title":"TelltaleDNS 0.6.0 makes mixed Raspberry Pi and Kubernetes DNS easier to test","html_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=en","markdown_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.md?lang=en","json_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/telltaledns_060_kubernetes_dns_failover_drills?lang=en"},{"language":"es","title":"TelltaleDNS 0.6.0 facilita las pruebas de DNS en entornos mixtos con Raspberry Pi y Kubernetes","html_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=es","markdown_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.md?lang=es","json_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/telltaledns_060_kubernetes_dns_failover_drills?lang=es"},{"language":"fr","title":"TelltaleDNS 0.6.0 simplifie les tests DNS mixtes sur Raspberry Pi et Kubernetes","html_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=fr","markdown_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.md?lang=fr","json_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/telltaledns_060_kubernetes_dns_failover_drills?lang=fr"},{"language":"pl","title":"TelltaleDNS 0.6.0 ułatwia testowanie DNS-u w mieszanych środowiskach Raspberry Pi i Kubernetes","html_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=pl","markdown_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.md?lang=pl","json_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/telltaledns_060_kubernetes_dns_failover_drills?lang=pl"},{"language":"ru","title":"TelltaleDNS 0.6.0 упрощает тестирование DNS в смешанных средах Raspberry Pi и Kubernetes","html_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=ru","markdown_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.md?lang=ru","json_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/telltaledns_060_kubernetes_dns_failover_drills?lang=ru"},{"language":"zh","title":"TelltaleDNS 0.6.0 让混合 Raspberry Pi 与 Kubernetes 的 DNS 更易测试","html_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=zh","markdown_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.md?lang=zh","json_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/telltaledns_060_kubernetes_dns_failover_drills?lang=zh"}],"_links":{"self":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.json?lang=ru","api":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/telltaledns_060_kubernetes_dns_failover_drills?lang=ru","html":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=ru","canonical":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=ru","markdown":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.md?lang=ru","json":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.json?lang=ru","channel":"https://publicasta.com/api/public/v1/channels/open_source_radar","channel_articles":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}