ネットワーク・トラフィック

ネットワーク・トラフィックとは、ネットワーク上を流れるデータのことです。このドキュメントのコンテキストでは、方向に基づくトラフィックと、コンポーネント・タイプ(システムまたはアプリケーション)に関連するトラフィックという2つの観点からネットワーク・トラフィックを考えることが有用です。トラフィックの方向は、南北トラフィック(クラスタへの入出)または東西トラフィック(クラスタ内に留まる)のいずれかです。

最初にトラフィックのクラスタへの進入について説明し、次にトラフィックがクラスタに入った後にどのように流れるかについて説明します。

イングレス

イングレスという用語には複数の意味があるため、コンテキストで理解する必要があります。この用語は、「クラスタへのイングレス」のようにクラスタへの外部アクセスを意味する場合があります。Kubernetes Ingressリソースを指す場合もあります。また、Pod内のコンテナへのネットワーク・イングレスを意味するために使用される場合もあります。ここでは、クラスタへの一般的なイングレスとKubernetes Ingressリソースの両方の意味で使用します。

インストール中、Verrazzanoは、システム・コンポーネントとアプリケーションの両方にアクセスするために必要なネットワーク・リソースを作成します。次のイングレスおよびロード・バランサの説明は、Verrazzanoインストールというコンテキストでの説明です。

LoadBalancerサービス

クラスタの外部からPodに到達するには、LoadBalancerまたはNodePortサービスを使用して外部IPアドレスを公開する必要があります。Verrazzanoは、2つのLoadBalancerサービスを作成します。1つはシステム・コンポーネント・トラフィック用、もう1つはアプリケーション・トラフィック用です。サービスがトラフィックをクラスタに入れる仕様は、基礎となるKubernetesプラットフォームによって異なります。Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)では、LoadBalancerタイプ・サービスを作成すると、Oracle Cloud Infrastructureロード・バランサが作成され、ポッドのセットにロード・バランシングされるように構成されます。

システム・コンポーネントのイングレス

システム・コンポーネントへのイングレスを提供するために、VerrazzanoはNGINXロード・バランサを含むNGINX Ingress Controllerをインストールします。Verrazzanoは、Kubernetes Ingressリソースを作成して、イングレスを必要とするシステム・コンポーネントごとにイングレスを構成します。Ingressリソースを使用して、エンドポイント・ホスト名およびTLS証明書とともにKubernetesサービスへのHTTP/HTTPSルートを指定します。Ingress自体は何もしません。単なるリソースです。サービス・ルーティングを処理するよう基礎となるKubernetesロード・バランサを構成してIngressリソースを監視し、調整するためにイングレス・コントローラが必要です。NGINX Ingress Controllerは、Ingressリソースを処理し、イングレス・ルート情報などを使用してNGINXを構成します。

NGINX Ingress Controllerは、次に示すようにLoadBalancerサービスです:

$ kubectl get service -n ingress-nginx

# Sample output
ingress-controller-ingress-nginx-controller           LoadBalancer

OKEの例を使用すると、Oracle Cloud Infrastructureロード・バランサに入るトラフィックはNGINXロード・バランサにルーティングされ、その後、そこから、イングレスに記述されているサービスに属するポッドにルーティングされます。

アプリケーションのイングレス

Verrazzanoはアプリケーションへのイングレスも提供しますが、NGINXではなくEnvoyプロキシであるIstioイングレス・ゲートウェイを使用します。Istioには、メッシュに入るトラフィック用のホスト、ポート、証明書などのロード・バランサ情報を提供するGatewayリソースがあります。詳細は、Istio Gatewayを参照してください。Ingressに対応するIngressコントローラが必要なのと同様に、Gatewayリソースにもコントローラが必要で、対応するIstioイングレス・ゲートウェイ・コントローラがあります。ただし、Ingressとは異なり、Gatewayリソースにはサービス・ルーティング情報はありません。Istio VirtualServiceリソースによって処理されます。GatewayとVirtualServiceの組合せは、Ingressよりも多くの機能が提供されるため、基本的にはIngressのスーパーセットです。つまり、Istioイングレス・ゲートウェイは、GatewayおよびVirtualServiceリソースの両方の情報を使用してクラスタへのイングレスを提供します。

Verrazzanoはインストール中にアプリケーションを作成しないため、その時点でGatewayおよびVirtualServiceを作成する必要はありません。ただし、インストール時に、Verrazzanoは、LoadBalancerサービスであるIstioイングレス・ゲートウェイおよびClusterIPサービスであるIstioエグレス・ゲートウェイを作成します。

$ kubectl get service -n istio-system

# Sample output
istio-ingressgateway   LoadBalancer

OKEユース・ケースを再度使用すると、別のOracle Cloud Infrastructureロード・バランサが作成され、トラフィックがIstioイングレス・ゲートウェイ・ポッド(Envoyプロキシなど)にルーティングされます。

外部DNS

Verrazzanoをインストールするときに、オプションでドメインの外部DNSを指定できます。その場合、VerrazzanoはExternalDNSを使用してDNSレコードを作成するだけでなく、Ingressリソースにホスト名を構成します。そのホスト名を使用して、NGINX Ingress Controllerからシステム・コンポーネントにアクセスできます。

システム・トラフィック

システム・トラフィックには、システムPodに入出するすべてのトラフィックが含まれます。

南北システム・トラフィック

南北トラフィックには、Kubernetesクラスタに入出するすべてのシステム・トラフィックが含まれます。

イングレス

次に、NGINX Ingress Controllerを介してクラスタ外部のクライアントからアクセスされるVerrazzanoシステム・コンポーネントの一覧を示します:

• argoCD
• OpenSearch
• Keycloak
• OpenSearchダッシュボード
• Grafana
• Prometheus
• Rancher
• Verrazzanoコンソール
• Verrazzano API

エグレス

次の表に、クラスタ外部の宛先へのリクエストを開始するVerrazzanoシステム・コンポーネントを示します。

東西システム・トラフィック

次の表に、クラスタ内の宛先にトラフィックを送信するVerrazzanoシステム・コンポーネントを示します。ただし、次の例外があります:

• CoreDNSの使用: クラスタ内のすべてのPodがCoreDNSにアクセスして名前解決できると想定されます。
• EnvoyからIstiod: Envoyプロキシはすべて、Istioコントロール・プレーンにリクエストして動的構成などを取得します。これには、ゲートウェイとメッシュ・サイドカー・プロキシの両方が含まれます。そのトラフィックは示されません。
• コンポーネント内のトラフィック(OpenSearch Pod間のトラフィックなど)は表示されません。
• Prometheusのスクレイピング・トラフィックは2つ目の表に示します。

Prometheusスクレイピング・トラフィック

この表は、各システム・コンポーネント・スクレイピング・ターゲットのPrometheusトラフィックを示しています。

Webフック

システム・コンポーネントのいくつかはコントローラで、一部はWebフックです。Webフックは、コンポーネントHTTPSポートでKubernetes APIサーバーによってコールされ、APIペイロードがAPIサーバーに到達する前に検証または変更されます。

次のコンポーネントはWebフックを使用します:

• cert-manager
• Coherenceオペレータ
• Istio
• Rancher
• Verrazzanoアプリケーション・オペレータ
• Verrazzanoプラットフォーム・オペレータ

アプリケーション・トラフィック

アプリケーション・トラフィックには、Verrazzanoアプリケーションとの間のすべてのトラフィックが含まれます。

南北アプリケーション・トラフィック

Verrazzanoのインストール後に、アプリケーションをIstioメッシュにデプロイできます。その際、アプリケーションへのイングレスが必要になる可能性があります。前述したように、これはGatewayおよびVirtualServiceリソースを使用してIstioで実行できます。ApplicationConfigurationでIngressTraitを使用すると、Verrazzanoによってこれらのリソースが作成されます。インストール中に作成されたIstioイングレス・ゲートウェイは、メッシュ内のすべてのアプリケーションによって共有され、Gatewayリソースは、インストール中に作成されたIstioイングレス・ゲートウェイにバインドされます。これは、Gatewayのセレクタ・フィールドによって行われます

   selector:
     istio: ingressgateway

Verrazzanoは、IngressTraitごとにGateway/VirtualServiceペアを作成します。次に、Verrazzanoによって作成されるこの2つのリソースの例を示します。

Gatewayを次に示します。ここでは、ホスト名と証明書はどちらもVerrazzanoによって生成されます。

apiVersion: v1
items:
- apiVersion: networking.istio.io/v1beta1
  kind: Gateway
  metadata:
   ...
    name: hello-helidon-hello-helidon-gw
    namespace: hello-helidon
  ...
  spec:
    selector:
      istio: ingressgateway
    servers:
    - hosts:
      - hello-helidon-appconf.hello-helidon.1.2.3.4.nip.io
      port:
        name: HTTPS
        number: 443
        protocol: HTTPS
      tls:
        credentialName: hello-helidon-hello-helidon-appconf-cert-secret
        mode: SIMPLE

VirtualServiceを次に示します。Gatewayを参照し、サービス・ルーティング情報が含まれることに注意してください。

apiVersion: v1
items:
- apiVersion: networking.istio.io/v1beta1
  kind: VirtualService
  metadata:
  ...
    name: hello-helidon-ingress-rule-0-vs
    namespace: hello-helidon
  spec:
    gateways:
    - hello-helidon-hello-helidon-gw
    hosts:
    - hello-helidon-appconf.hello-helidon.1.2.3.4.nip.io
    HTTP:
    - match:
      - uri:
          prefix: /greet
      route:
      - destination:
          host: hello-helidon
          port:
            number: 8080

東西アプリケーション・トラフィック

東西トラフィックを管理するには、メッシュ内の各サービスをVirtualServiceおよびオプションのDestinationRuleを使用してルーティングする必要があります。これらのリソースなしでも東西トラフィックを送信できますが、カスタム・ルーティングやロード・バランシングは行われません。Verrazzanoは東西トラフィックを構成しません。Bob’s Booksの例のbobs-books-comp.yamlのbobbys-front-endについて考えてみます。Bob’s Booksをデプロイすると、IngressTraitのためbobbys-front-endに対してVirtualServiceが作成されますが、アプリケーションの他のサービスにはVirtualServicesはありません。bobbys-front-endがbobbys-helidon-stock-applicationにリクエストを送信する場合、この東西トラフィックは、ソースPodと宛先PodのEnvoyサイドカー・プロキシを介してbobbys-helidon-stock-applicationに送信されますが、カナリア・デプロイメントまたはカスタム・ロード・バランシングを指定できるbobbys-helidon-stock-applicationを表すVirtualServiceはありません。これは手動で設定できるものですが、Verrazzanoでは構成されません。

プロキシ

Verrazzanoはネットワーク・プロキシを複数の場所で使用します。2つのプロキシ製品はEnvoyおよびNGINXです。次の表に、どのプロキシが使用され、どのPodで実行されるかを示します。

マルチクラスタ

一部のVerrazzanoコンポーネントは、Kubernetesクラスタ間でトラフィックを送信します。これらのコンポーネントは、Verrazzanoエージェント、Verrazzano認証プロキシおよびPrometheusです。

マルチクラスタ・エグレス

次の表に、管理クラスタと管理対象クラスタの間のリクエストを開始するVerrazzanoシステム・コンポーネントを示します。これらのリクエストはすべて、それぞれの宛先クラスタのNGINX Ingress Controllerを経由します。

ポート443のトラフィックは、管理対象クラスタから管理クラスタと、管理クラスタから管理対象クラスタへの両方向で許可する必要があります。また、管理クラスタでRancherが有効になっていない場合、管理対象クラスタは管理クラスタのKubernetes APIサーバー・ポート(通常はポート6443)にアクセスする必要もあります。

Verrazzanoエージェント

マルチクラスタ・トポロジでは、Verrazzanoプラットフォーム・オペレータには、管理クラスタのKubernetes APIサーバーにリクエストを送信する、管理対象クラスタで実行されているエージェント・スレッドがあります。管理クラスタのKubernetes APIサーバーのURLは、ユーザーによって管理対象クラスタに登録されます。

Verrazzano認証プロキシ

マルチクラスタ・トポロジでは、Verrazzano認証プロキシは管理クラスタと管理対象クラスタの両方で実行されます。管理クラスタでは、認証プロキシはKeycloakサービスを使用して、クラスタ内のKeycloakに接続します。管理対象クラスタでは、認証プロキシは、管理クラスタで実行されているNGINX Ingress Controllerを介して管理クラスタのKeycloakに接続します。

シングル・サインオン(SSO)の場合、認証プロキシは、クラスタ内またはクラスタ・イングレスを介して、Keycloakにリクエストを送信する必要もあります。リクエストが認証ヘッダーなしで認証プロキシに入ると、プロキシはNGINX Ingress Controllerを介してKeycloakにリクエストを送信し、リクエストはクラスタから退出します。それ以外の場合は、認証プロキシが管理クラスタ上にある場合、リクエストはクラスタ内のKeycloakに直接送信されます。認証プロキシが管理対象クラスタ上にある場合は、管理クラスタのKeycloakにリクエストを送信する必要があります。

Prometheus

クラスタ内の単一のPrometheusサービスは、システム・コンポーネントとアプリケーションのPodからメトリックをスクレイピングします。HTTPSを使用したIstioメッシュ内のPodのスクレイピング、およびHTTPを使用したメッシュ外のPodのスクレイピングも行います。マルチクラスタの場合、管理クラスタのPrometheusは、管理対象クラスタのNGINX Ingress Controllerを介して、管理対象クラスタのPrometheusからメトリックをスクレイピングします。