Комментарии 5
А что скажите по поводу скорости переключения в случае отказа ноды?
Проводили замеры ?
На мой взгляд эту технологию лучше обходить стороной по следующим причинам:
- Весь траффик идет через одну ноду.
- В случае отказа ноды с egress ip у Вас гарантированно будет разрыв всех сетевых соединений не зависимо от того сколько реплик приложения вы запустили.
Специально замеров не делали, навскидку это секунды. То есть после выключения узла немедленно запускали тест, все работало.
Если говорить про обрыв соединений, то они всегда будут при отказе узла, и приложение в идеале должно это нормально переживать.
В случае фиксированного Egress IP масштаб «потерь» будет больше, согласны с вами.
По поводу нужно это или нет — это вопрос требований от ИБ. Если можно обойтись Network Policy внутри кластера, то, конечно, лучше не затевать привязку к адресам, это вообще противоречит «облачной» природе Kubernetes. Но если по другому не выходит, то потеря сессий при отказе узла — типичное «наименьшее зло».
Если говорить про обрыв соединений, то они всегда будут при отказе узла, и приложение в идеале должно это нормально переживать.
В случае фиксированного Egress IP масштаб «потерь» будет больше, согласны с вами.
По поводу нужно это или нет — это вопрос требований от ИБ. Если можно обойтись Network Policy внутри кластера, то, конечно, лучше не затевать привязку к адресам, это вообще противоречит «облачной» природе Kubernetes. Но если по другому не выходит, то потеря сессий при отказе узла — типичное «наименьшее зло».
Странная особенность, что присваивается два разных адреса двум узлам, но второй адрес используется только при недоступности первого.
Почему бы не использоваться для ограничения исходящего траффика EgressNetworkPolicy?
Почему бы не использоваться для ограничения исходящего траффика EgressNetworkPolicy?
Конечно, можно использовать Egress Policy в кластере. Но представьте ситуацию:
1. У вас коммунальный кластер, в котором «живут» две независимые организации (A и B). Они получают namespace в кластере, но расположены удаленно за своими корпоративными МЭ.
2. Они присылают запрос: сообщить все адреса, с которых будут выходить их POD, чтобы создать правила доступа на их МЭ.
В этом случае вы можете:
1. Убедить всех, что вы правильно настроили Network Policy и POD организации A никогда не смогут получить доступ в сети организации B и наоборот. Также от вас потребуется клятва, что вы будете поддерживать Network Policy в актуальном состоянии, потому что требования к доступам будут меняться.
2. Зафиксировать за A и B набор IP-адресов (через Egress IP) и сообщить их А и В
Первый вариант мало реалистичен, так как в этом случае контроль доступа организации А и В полностью передают вам. А они могут и будут вам не доверять. И предвосхищая комментарии — да, выделенный кластер под каждую организацию лучше. Но и дороже)
1. У вас коммунальный кластер, в котором «живут» две независимые организации (A и B). Они получают namespace в кластере, но расположены удаленно за своими корпоративными МЭ.
2. Они присылают запрос: сообщить все адреса, с которых будут выходить их POD, чтобы создать правила доступа на их МЭ.
В этом случае вы можете:
1. Убедить всех, что вы правильно настроили Network Policy и POD организации A никогда не смогут получить доступ в сети организации B и наоборот. Также от вас потребуется клятва, что вы будете поддерживать Network Policy в актуальном состоянии, потому что требования к доступам будут меняться.
2. Зафиксировать за A и B набор IP-адресов (через Egress IP) и сообщить их А и В
Первый вариант мало реалистичен, так как в этом случае контроль доступа организации А и В полностью передают вам. А они могут и будут вам не доверять. И предвосхищая комментарии — да, выделенный кластер под каждую организацию лучше. Но и дороже)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Все об OpenShift Egress. Часть 1