Вы можете настроить весь свой трафик c на go через istio-egressgateway.
Затем вы можете манипулировать istio-egressgateway, чтобы он всегда был развернут на одном узле кластера и занесите этот IP-адрес в белый список.
Плюсы: супер просто. НО. Если вы еще не используете Istio, настройка Istio только для этого может убить москита базукой.
Минусы: Необходимо убедиться, что узел не меняет Айпи адрес. В противном случае сам istio-egressgateway может не быть развернут (если вы не добавили метки к новому узлу), и вам нужно будет перенастроить все для нового узла (новый IP-адрес). Еще один недостаток может заключаться в том, что если трафик c возрастет, появится HPA, который развернет больше реплик шлюза, и все они будут развернуты на одном узле. Итак, если у вас будет много трафика c, возможно, было бы неплохо изолировать один узел только для этой цели.
Другой вариант будет таким, как вы предлагаете; прокси. Я бы порекомендовал напрямую прокси Envoy. Я имею в виду, что Istio все равно будет использовать Envoy, верно? Итак, просто получите прокси напрямую, поместите его в модуль и сделайте то же самое, что я упоминал ранее; привязка узла, поэтому он всегда будет работать на одном и том же узле, поэтому он будет go с одним и тем же IP.
Плюсы: Вы не устанавливаете весь сервис me sh control самолет для одной крошечной вещи.
Минусы: То же, что и раньше, поскольку у вас все еще есть проблема со сменой IP-адреса узла, если что-то пойдет не так, плюс вам нужно будет управлять своим Deployment объект, HPA, настройте прокси Envoy и т.д. c. вместо использования объектов Istio (например, Gateway и VirtualService).
Наконец, я вижу третий вариант; для настройки шлюза NAT за пределами кластера и настройки вашего трафика c на go через него.
Плюсы: Вам не нужно настраивать какой-либо объект kubernetes, поэтому нет необходимости устанавливать какое-либо сходство узлов, поэтому не будет переполнения узлов или изменения IP. Кроме того, вы можете удалить внешние IP-адреса из своего кластера, чтобы он был более безопасным (если у вас нет других рабочих нагрузок, которым необходимо напрямую обращаться к inte rnet). Кроме того, вероятно, наличие одного узла, настроенного как NAT, будет более устойчивым, чем модуль kubernetes, работающий на узле.
Минусы: Может быть немного сложнее настроить?
И есть этот общий недостаток, что вы можете занести в белый список только 1 IP-адрес, поэтому у вас всегда будет единственная точка отказа. Даже шлюз NAT; он все равно может выйти из строя.
GCP stati c IP вам не поможет. В другом сообщении предлагается зарезервировать IP-адрес, чтобы вы всегда могли использовать его повторно. Но дело не в том, что этот IP-адрес будет автоматически добавляться к случайному выходящему из строя узлу. Необходимо вмешательство человека. Я не думаю, что у вас может быть один конкретный c узел, чтобы иметь статический c IP-адрес, и если он выйдет из строя, новый созданный узел выберет тот же IP-адрес. Насколько мне известно, такой службы не существует.
Теперь GCP действительно предлагает очень устойчивый шлюз NAT. Он управляется Google, поэтому не должен потерпеть неудачу. Но не дешево.