Как Istio поддерживает маршрутизацию на основе IP между модулями в одной и той же службе (или, если быть более точным, ReplicaSet)?
Мы хотели бы развернуть приложение Tomcat с репликой> 1 в сетке Istio.Приложение запускает Infinispan, который использует JGroups для сортировки коммуникаций и кластеризации.JGroups необходимо идентифицировать членов своего кластера, и для этого существует KUBE_PING (протокол обнаружения Kubernetes для JGroups).Он будет обращаться к API K8S с поиском, сравнимым с kubectl get pods .Члены кластера могут быть как модулями в других службах, так и модулями в одной и той же службе / развертывании.
Несмотря на то, что наша проблема связана с довольно специфическими потребностями, тема носит общий характер.Как нам разрешить модулям взаимодействовать друг с другом в наборе реплик?
Пример: в качестве витрины мы развернем демонстрационное приложение https://github.com/jgroups-extras/jgroups-kubernetes. Соответствующий материал:
apiVersion: v1
items:
- apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: ispn-perf-test
namespace: my-non-istio-namespace
spec:
replicas: 3
< -- edited for brevity -- >
Запустив без Istio , три модуля найдут друг друга и сформируют кластер.Развертывание того же с Istio в my-istio-namespace и добавление базового определения службы:
kind: Service
apiVersion: v1
metadata:
name: ispn-perf-test-service
namespace: my-istio-namespace
spec:
selector:
run : ispn-perf-test
ports:
- protocol: TCP
port: 7800
targetPort: 7800
name: "one"
- protocol: TCP
port: 7900
targetPort: 7900
name: "two"
- protocol: TCP
port: 9000
targetPort: 9000
name: "three"
Обратите внимание, что вывод ниже широкий - вам может понадобитьсяпрокрутите вправо, чтобы получить IP-адреса
kubectl get pods -n my-istio-namespace -o wide
NAME READY STATUS RESTARTS AGE IP NODE
ispn-perf-test-558666c5c6-g9jb5 2/2 Running 0 1d 10.44.4.63 gke-main-pool-4cpu-15gb-98b104f4-v9bl
ispn-perf-test-558666c5c6-lbvqf 2/2 Running 0 1d 10.44.4.64 gke-main-pool-4cpu-15gb-98b104f4-v9bl
ispn-perf-test-558666c5c6-lhrpb 2/2 Running 0 1d 10.44.3.22 gke-main-pool-4cpu-15gb-98b104f4-x8ln
kubectl get service ispn-perf-test-service -n my-istio-namespace
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ispn-perf-test-service ClusterIP 10.41.13.74 <none> 7800/TCP,7900/TCP,9000/TCP 1d
Руководствуясь https://istio.io/help/ops/traffic-management/proxy-cmd/#deep-dive-into-envoy-configuration,, давайте заглянем в итоговую конфу посланника одного из модулей:
istioctl proxy-config listeners ispn-perf-test-558666c5c6-g9jb5 -n my-istio-namespace
ADDRESS PORT TYPE
10.44.4.63 7900 TCP
10.44.4.63 7800 TCP
10.44.4.63 9000 TCP
10.41.13.74 7900 TCP
10.41.13.74 9000 TCP
10.41.13.74 7800 TCP
< -- edited for brevity -- >
Документ Istio описываетпрослушиватели выше как
Получает исходящий не HTTP-трафик для соответствующей пары IP: PORT от слушателя 0.0.0.0_15001
, и все это имеет смысл.Модуль pod ispn-perf-test-558666c5c6-g9jb5 может достичь себя 10.44.4.63, а сервис - через 10.41.13.74.Но ... что, если модуль отправляет пакеты на 10.44.4.64 или 10.44.3.22?Эти IP-адреса отсутствуют среди слушателей, так что на самом деле два «родных» модуля недоступны для ispn-perf-test-558666c5c6-g9jb5 .
Может ли Istio поддержать это сегодня - тогдакак?