kubernetes - Istio (1.0) 内 ReplicaSet ルーティング - Kubernetes デプロイメント内のポッド間のトラフィックをサポート

Question

Istio は、同じサービス (より具体的には ReplicaSet) 内のポッド間の IP ベースのルーティングをどのようにサポートしますか?

Istio メッシュ内でレプリカ > 1 の Tomcat アプリケーションをデプロイしたいと考えています。このアプリは、JGroups を使用して通信とクラスタリングを整理する Infinispan を実行します。JGroups はそのクラスター メンバーを識別する必要があり、その目的のために KUBE_PING (JGroups の Kubernetes 検出プロトコル) があります。kubectl get podsに匹敵するルックアップで K8S API を調べます。クラスター メンバーは、他のサービスのポッドと同じサービス/デプロイ内のポッドの両方になることができます。

私たちの問題はかなり特定のニーズによって推進されていますが、トピックは一般的です。ポッドがレプリカ セット内で相互に通信できるようにするにはどうすればよいですか?

例: ショーケースとして、デモ アプリケーション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なしで実行すると、3 つのポッドが互いを検出し、クラスターを形成します。my-istio-namespaceでIstioと同じものをデプロイし、基本的な Service 定義を追加します。

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に従って、ポッドの 1 つの Envoy conf の結果を見てみましょう。

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 doc では、上記のリスナーについて次のように説明しています。

関連する IP:PORT ペアのアウトバウンドの非 HTTP トラフィックをリスナーから受信します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 はリスナー間に存在しないため、2 つの「兄弟」ポッドはispn-perf-test-558666c5c6-g9jb5 では到達できません。

今日、Istio はこれをサポートできますか?