так никто не делает, это ересь

Это мантейнер того репо, которое ты рекомендуешь.

Ты б хоть внутрь заглянул. Вдруг там бэкдор и тебя поломают завтра? Поаккуратнее с этим.)

ладно, сорян, зря быканул
но тем не менее это скрипт

ну я его знаю

И?

Или символьных. Что не так-то? Вполне вариант

начнем с того что они пропадут после ребута, но для контейнера некритично

Куда-то обсуждение вообще не туда пошло. Вопрос закрыт.

нет, не только блочных. И да, его юзают в 2021

ну на хосте не встречал чтобы юзали

а что с ним не так, чтобы его не юзать в 2021? Этот сискол стал depricated? О таком не слышал

В контейнерах таки норм, но дело в том, что на хосте будет после ребута пропадать tun

Правильно, потому что там все из коробки приезжает )))

Не депрекейтнули

Интересная задачка, если вообще про большие масштабы говорить, то имхо надо кубер перепиливать/не использовать кубер, и в итоге приводить к тому, чтобы избавляться от statefull-сервисов типа nat'а, так как это не гуд при больших объемах трафика. А так наверное все просто будет тогда: Несколько бордеров на входе в DC, они через consistent hash/ecmp в L4/l7 балансеры, которые через health check'и (или нет, если один адрес у всех подов условно) проверяют какие-то группы приложений сразу и сразу туда отправляют трафик (чтобы нормально вернулось, вероятно, надо через SNAT/туннель). Ingress не нужны (ну или точнее они просто вне кубера стоят), service net не нужны, можно через BGP наверх в ToR анонсить один и тот же адрес через BGP на хосте для одних и тех же приложений, и в итоге опять через consistent hash у тебя по ECMP прилетать в нужные поды будет все. Ну и L3 routed IPv6 вариант без всяких L2 stretched и вот этого всего. Но наверное это масштаб должен быть реально большим на тысячи/десятки тысяч серверов

Ну вот я скорее размышлял о приблизительно том же самом, но в пределах одного ДЦ.

ну это в пределах одного DC :)

но эт хз, яндекс ток какой-нить так может делать) так мне кажется - сильно оверкилл