Общий ресурс NGINX RTMP + в автоматическом масштабировании Google Cloud

Я создаю масштабируемую инфраструктуру для своего RTMP-сервера nginx. Я: nginx + arut-rtmp-модуль + ffmpeg на сервере. Это схема первой архитектуры внутри экземпляра управляемой группы.

Проблема в этой схеме проста: поток ввода только на сервере, зрители на Сервере 2 не смогут смотреть потоковую передачу.

РЕДАКТИРОВАТЬ2: В этом случае мой браузер работает нормально: получите напрямую весь файл .ts с сервера, и он работает! Очевидно, что это решение, как уже было сказано, не масштабируемо.

Итак ... Я думаю, нам нужно что-то общее для всех новых экземпляров. Я использовал ведро Google, установленное с помощью gcsfuse на каждом экземпляре. (я всегда использую экземпляр управляемой группы)

Проблема в этом сценарии: в то время как сервер, который получает входные потоки, создает сегменты .ts, каждый раз, когда создается сегмент, корзина обновляется с помощью 0-байтового .ts. Когда сервер завершит запись .ts, сегмент получит обновленный файл .ts. Так что на самом деле это не "общий" ...

РЕДАКТИРОВАТЬ2: В этом случае мой браузер загружает только первые 1/2 .ts сегментов, чем застрял при загрузке m3u8 в цикле.

Итак, я протестировал эти решения, но не работают. Я что-то здесь не прав? Ковш не подходит?

Спасибо

P.s. Я добавил облачный CDN в корзину, поэтому из моего приложения я могу получить сегмент .ts прямо из CDN. Проблема в том, что после 2 / 3.ts мое приложение получает только m3u8, но не может получить другие .ts (мой компакт-диск имеет .ts!)

РЕДАКТИРОВАТЬ1: Это похоже на то, что после первой загрузки m3u8 он берет первый уже загруженный .ts .... но после не может получить следующий .ts!

РЕДАКТИРОВАТЬ3: Это то, что загружает мой браузер:

m3u8 загружен в цикл:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-TARGETDURATION:10
#EXT-X-DISCONTINUITY
#EXTINF:4.167,
0.ts
#EXTINF:4.167,
1.ts
#EXTINF:6.666,
2.ts
#EXTINF:4.167,
3.ts

Настоящий m3u8 на ковше:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-TARGETDURATION:10
#EXT-X-DISCONTINUITY
#EXTINF:4.167,
0.ts
#EXTINF:4.167,
1.ts
#EXTINF:6.666,
2.ts
#EXTINF:4.167,
3.ts
#EXTINF:6.133,
4.ts
#EXTINF:4.734,
5.ts
#EXTINF:10.016,
6.ts
#EXTINF:6.450,
7.ts
#EXTINF:8.317,
8.ts
#EXTINF:7.183,
9.ts
#EXTINF:5.850,
10.ts
#EXTINF:2.050,
11.ts

РЕДАКТИРОВАТЬ3: Умммм .... это может проблема с кешем CDN? В таком случае, где я могу редактировать конфигурации кеша?

EDIT4: Это текущая схема, которая дает мне проблему с файлом m3u8, неправильно обновленным на моем плеере

ОБНОВИТЬ:

Пробовал оба приложения одновременно (просто меняя источник, который я получаю на своем плеере):

1. Указывая на m3u8 прямо на сервере (где у меня установлена ​​корзина с gcsfuse)
2. Указывая на m3u8 на CDN

1-й случай работает: m3u8 обновляется каждый раз. 2-й случай m3u8 загружает 1-ю конфигурацию (например, попытался открыть после того, как 20 сегментов ts уже созданы). Он загружает первый m3u8 ... затем повторно загружает ту же версию файла в цикле.

Стриминг, как я уже сказал, был таким же: просто исходный код в m3u8 был получен разными способами: непосредственно из корзины, установленной на сервере, или непосредственно с cdn (то есть в той же корзине).

ОБНОВЛЕНИЕ2: Все перепробовал, если я загружу m3u8 со своего компакт-диска ... я тоже получаю не обновленный файл. Если я возьму тот же файл из ведра, он обновится !! Я попытался направить свой плеер на storage.google, но на моем веб-сайте я получаю сообщение об ошибке cors ... пытался изменить настройку cors с консоли (с помощью gsutil), но делать нечего. Как я могу предотвратить кеширование на CDN? Я уже установил заголовок без кеширования и без хранения: /

Вот мой коэффициент попадания в облачный CDN кеш ....