В подключении GCP Memorystore Redis отказано после включения Istio - PullRequest
Новая
       52

В подключении GCP Memorystore Redis отказано после включения Istio

0 голосов
/ 09 июля 2020

У нас есть существующий кластер GKE (1.16.9-gke.6) с некоторыми службами, взаимодействующими с экземпляром GCP Memorystore Redis. Однако после включения Istio (версия 1.16.3) на этих модулях мы начали видеть ошибки отказа в подключении к экземпляру redis. Поскольку мы только начинаем работу с Istio, мы разрешаем весь внешний трафик c из Службы внутри меня sh, используя: 

meshConfig:
 outboundTrafficPolicy:
      mode: ALLOW_ANY

При этом весь исходящий трафик c идет в PassthroughCluster , как ожидалось и наблюдалось в журналах Kiali + Istio Proxy.

Кроме того, я могу успешно войти в свой контейнер приложения, контейнер istio proxy и netcat в экземпляр redis.

Я также попытался добавить запись службы для экземпляра redis в наших шаблонах диаграмм управления: 

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: gcp-memorystore-redis
spec:
  # note, host field is ignored for tcp
  hosts:
    - gcp-memorystore-redis
  addresses:
    - {{ .Values.redis.cidr }}
  endpoints:
    - address: {{ .Values.redis.nodeAddress }}
  ports:
    - number: 6379
      name: tcp-redis
      protocol: TCP
  resolution: STATIC
  location: MESH_EXTERNAL

Однако я продолжаю получать ошибки отказа в соединении. Мы используем клиентскую библиотеку Redisson java, не уверены, имеет ли это значение.

В качестве обходного пути я обхожу прокси-сервер Istio, добавляя наш диапазон ip cidr, используя global.proxy.includeIPRanges, и устанавливаю enableProtocolSniffingForOutbound: false, что пока работает, но Я бы действительно хотел, чтобы это было настроено как ServiceEntry, потому что я в конечном итоге хочу, чтобы мой трафик c направлялся через шлюз Egress.

Каков правильный формат для указания redis uri / nodeAddresses в нашем приложении с помощью ServiceEntry о. Кажется, это не работает: redis://gcp-memorystore-redis:6379

Благодарю за любую помощь!

1 Ответ

0 голосов
/ 17 июля 2020

Для всех, кто приходит сюда, я смог решить эту проблему, добавив предложенный хак https://github.com/istio/istio/issues/11130 перед запуском контейнера приложения. Аналогичным образом добавление хука preStop в контейнер прокси, как уже упоминалось: https://github.com/istio/istio/issues/7136

values:
  global:
    proxy:
      lifecycle:
          preStop:
            exec:
              command: [
                "/bin/sh", "-c",
                "while [ $(netstat -plunt | grep tcp | grep -v envoy | wc -l | xargs) -ne 0 ]; do printf 'Waiting for App Server to shutdown'; sleep 1; done; echo 'App server shutdown, shutting down proxy...'"
              ]

В будущем, если / когда этот PR: https://github.com/istio/istio/pull/24737 будет объединен, все будет немного менее хакерским.

...