4

私たちのシステムには多くの安らかなサービスがあります

  • 一部はkubernetesクラスター内にあります
  • その他はレガシーインフラストラクチャ上にあり、VM でホストされています

私たちの安らかなサービスの多くは、互いに同期呼び出しを行います (メッセージ キューを使用して非同期ではありません)。

これらのサービスを利用する多数の UI (ファット クライアントまたは Web アプリ) もあります。

このような単純な k8s マニフェスト ファイルを定義する場合があります。

  1. ポッド
  2. サービス
  3. イングレス
apiVersion: v1
kind: Pod
metadata:
  name: "orderManager"
spec:
  containers:
    - name: "orderManager"
      image: "gitlab-prem.com:5050/image-repo/orderManager:orderManager_1.10.22"
---
apiVersion: v1
kind: Service
metadata:
  name: "orderManager-service"
spec:
  type: NodePort
  selector:
    app: "orderManager"
  ports:
    - protocol: TCP
      port: 50588
      targetPort: 50588
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: orderManager-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - http:
        paths:
          - path: /orders
            pathType: Prefix
            backend:
              service:
                name: "orderManager-service"
                port:
                  number: 50588

クラスター上の安らかなサービスが互いに通信するための最良の方法は何なのか、私にはよくわかりません。

  • イングレス ルールによって構築された URL を使用する、クラスター外の発信者にとって適切なルートは 1 つだけのようです。
  • クラスタ内の 2 つのオプション

これは例でそれをさらに説明するかもしれません

発信者 レシーバー 例の URL
UI クラスタ上 http://clusterip/orders UI はクラスター IP とイングレス ルールを使用してオーダー マネージャーに到達します。
クラスター外のサービス クラスタ上 http://clusterip/orders UIと同じように
クラスタ上 クラスタ上 http://clusterip/orders 上記のアプローチのような進入ルールを使用できます
クラスタ上 クラスタ上 http://orderManager-service:50588/ サービス名とポートを直接使用できます

上記でクラスター ipを数回書いていますが、実際には何かをトップに置くので、http://mycluster/orders のようなわかりやすい名前があります。

したがって、発信者と受信者の両方がクラスター上にある場合、どちらかです

  • クラスター外のサービスやアプリでも使用されるイングレスルールを使用する
  • イングレス ルールで使用されるノードポート サービス名を使用します。
  • またはおそらく何か他のもの！

nodeport サービス名を使用する利点の 1 つは、ベース URL を変更する必要がないことです。

  • イングレスルールは、追加の要素をルートに追加します (上記の場合、orders ) 。
  • Restful サービスをレガシーから k8s クラスターに移動すると、複雑さが増します
4

1 に答える 1

2

これは、イングレス コントローラーを介してリクエストをルーティングするかどうかによって異なります。

Ingress リソースで構成された完全な URL に送信されたリクエストは、イングレス コントローラーによって処理されます。コントローラ自体 (この場合は NGINX) がリクエストをサービスにプロキシします。その後、リクエストは Pod にルーティングされます。

リクエストをサービスの URL に直接送信すると、単にイングレス コントローラーがスキップされます。リクエストは Pod に直接ルーティングされます。

2 つのオプションのトレードオフは、セットアップによって異なります。

イングレス コントローラーを介してリクエストを送信すると、リクエストのレイテンシとリソース消費が増加します。イングレス コントローラーがルーティング リクエスト以外に何もしない場合は、リクエストをサービスに直接送信することをお勧めします。

ただし、イングレス コントローラーを認証、監視、ログ記録、トレースなどの他の目的で使用する場合は、コントローラーで内部要求を処理することをお勧めします。

たとえば、私のクラスターの一部では、NGINX イングレス コントローラーを使用して、リクエストのレイテンシーを測定し、HTTP レスポンスのステータスを追跡しています。その情報を利用できるようにするために、イングレス コントローラーを介して同じクラスターで実行されているアプリ間で要求をルーティングします。可観測性を向上させるために、レイテンシーとリソース使用量の増加の代償を払います。

あなたのケースでトレードオフが価値があるかどうかは、あなた次第です。イングレス コントローラーが基本的なルーティング以外に何もしない場合は、完全にスキップすることをお勧めします。それ以上のことを行う場合は、それを介してリクエストをルーティングすることの長所と短所を比較検討する必要があります。

于 2021-11-17T06:16:05.747 に答える