サービスメッシュライト
Ingressソリューション（ハードウェア、仮想化、またはコンテナ化のいずれか）は通常、南北（N-S）トラフィックに対してL7プロキシ機能を実行します。サービスメッシュライトアーキテクチャは、同じIngressソリューションを使用して東西トラフィックも管理します。
標準的なKubernetesデプロイメントでは、東西（E-W）トラフィックは各ノードにデプロイされた組み込みのkube-proxyを通過します。Kube-proxyはL4プロキシであり、TCP/UDPベースの負荷分散しか実行できず、L7プロキシが提供する利点を提供できません。
NetScaler（MPX、VPX、またはCPX）は、E-Wトラフィックに対してL7プロキシの利点を提供できます。例えば、以下のようなものです。
-
相互TLSおよびSSLオフロード。
-
コンテンツベースのルーティング、HTTPおよびHTTPSヘッダーパラメータに基づくトラフィックの許可またはブロック。
-
高度な負荷分散アルゴリズム（最小接続数または最小応答時間）。
-
ゴールデンシグナル（エラー、遅延、飽和、トラフィック量）の測定による東西トラフィックの可観測性。NetScaler Console Service Graphは、マイクロサービスを監視およびデバッグするための可観測性ソリューションです。
サービスメッシュアーキテクチャ（IstioやLinkerDなど）は管理が複雑です。サービスメッシュライトアーキテクチャは軽量版であり、同じ要件を達成するために開始するのがはるかに簡単です。
サービスメッシュライトアーキテクチャでNetScaler CPXを使用して東西通信を構成するには、まずkube-proxyが東西トラフィックを管理するためにどのように構成されているかを理解する必要があります。
kube-proxyによる東西通信
マイクロサービス用にKubernetesデプロイメントを作成すると、Kubernetesはレプリカ数に基づいて一連のPodをデプロイします。これらのPodにアクセスするには、それらのPodにアクセスするための抽象化を提供するKubernetesサービスを作成します。この抽象化は、サービスにクラスターIPアドレスを割り当てることによって提供されます。
Kubernetes DNSには、サービス名をクラスターIPアドレスにマッピングするアドレスレコードが設定されます。そのため、例えば
teaというアプリケーションがcoffeeというマイクロサービスにアクセスしたい場合、DNSはcoffeeサービスのクラスターIPアドレスをteaアプリケーションに返します。teaアプリケーションは接続を開始し、その接続はkube-proxyによって傍受され、一連のcoffee Podに負荷分散されます。
サービスメッシュライトアーキテクチャにおけるNetScaler CPXによる東西通信
目標は、NetScaler CPXを東西パスに挿入し、Ingressルールを使用してこのトラフィックを制御することです。
NetScaler CPXとの東西通信を構成するには、次の手順を実行します。
ステップ1：コーヒーサービス定義をNetScaler CPXを指すように変更する
NetScaler CPXが東西トラフィックを管理するには、マイクロサービス（例:
coffee）のFQDNが、ターゲットマイクロサービス（coffee）のクラスターIPではなく、NetScaler CPXのIPアドレスを指す必要があります。（このNetScaler CPXの展開は、Ingress NetScaler CPXデバイスと同じにすることができます。）この変更後、Kubernetesクラスター内のPodがコーヒーサービスのFQDNを解決すると、NetScaler CPXのIPアドレスが返されます。
注記：
オブザーバビリティのためにNetScaler Consoleでサービスグラフを起動するためにサービスメッシュライトを展開している場合は、サービスを変更した後、NetScaler CPX IPアドレスを指すすべてのアプリケーションサービスにラベル
citrix-adc: cpx を追加する必要があります。
ステップ2：コーヒーマイクロサービスPod用に coffee-headless という名前のヘッドレスサービスを作成する
coffee サービスをNetScaler CPXを指すように変更したため、コーヒーマイクロサービスの展開を表すサービスをもう1つ作成する必要があります。
以下は、ヘッドレスサービスリソースのサンプルです。
apiVersion: v1
kind: Service
metadata:
name: coffee-headless
spec:
#headless Service
clusterIP: None
ports:
- name: coffee-443
port: 443
targetPort: 443
selector:
name: coffee-deployment
ステップ3： coffee-headless サービス用のルールを含むIngressリソースを作成する
前の手順での変更により、NetScaler CPXを構成してコーヒーマイクロサービスPodへの東西トラフィックを制御するIngressオブジェクトを作成する準備が整いました。
以下は、Ingressリソースのサンプルです。
これらの変更を伴う通常のIngressロードバランシング手法を使用すると、NetScaler CPXは東西トラフィックをロードバランスできるようになります。次の図は、NetScaler CPXサービスメッシュライトアーキテクチャがIngressルールを使用して
tea と coffee マイクロサービス間の東西通信にL7プロキシを提供する方法を示しています。
サンプル(/en-us/netscaler-k8s-ingress-controller/media/coffee-micro-summary.png)
Service Mesh liteアーキテクチャにおけるNetScaler MPXまたはVPXとのEast-west通信
Ingressとして機能するNetScaler MPXまたはVPXは、前のセクションで述べたのと同様の方法で、わずかな変更を加えてEast-westマイクロサービス通信を負荷分散することもできます。以下の手順で、これを実現する方法を示します。
ステップ1: coffeeホスト名をNetScaler MPX/VPX IPアドレスに解決する外部サービスを作成する
これには2つの方法があります。ホスト名をマッピングする外部サービスを追加するか、IPアドレスを使用することができます。
ホスト名によるマッピング (CNAME)
-
NetScaler MPXまたはVPXでIngressエンドポイントIPアドレス（コンテンツスイッチング仮想サーバーIPアドレス）のドメイン名を作成し（例:
myadc–instance1.us-east-1.mydomain.com）、それをDNSサーバーで更新します。 -
coffeeのKubernetesサービスをexternalNameをmyadc–instance1.us-east-1.mydomain.comとして作成します。 -
これで、任意のPodが
coffeeマイクロサービスを検索すると、CNAME(myadc–instance1.us-east-1.mydomain.com)が返されます。
kind: Service
apiVersion: v1
metadata:
name: coffee
spec:
type: ExternalName
externalName: myadc–instance1.us-east-1.mydomain.com
ホスト名をIPアドレスにマッピングする
アプリケーションでホスト名
coffeeを使用し、それがNetScaler MPXまたはVPXでホストされている仮想IPアドレスにリダイレクトされるようにしたい場合は、以下を作成できます。
---
kind: "Service"
apiVersion: "v1"
metadata:
name: "coffee"
spec:
ports:
-
name: "coffee"
protocol: "TCP"
port: 80
---
kind: "Endpoints"
apiVersion: "v1"
metadata:
name: "coffee"
subsets:
-
addresses:
-
ip: "1.1.1.1" # Ingress IP in MPX
ports:
-
port: 80
name: "coffee"
ステップ2: マイクロサービスPod用のヘッドレスサービスを作成する
coffeeサービスをNetScaler MPXを指すように変更したため、coffeeマイクロサービスデプロイメントを表すもう1つのサービスを作成する必要があります。
ステップ3: Ingressリソースを作成する
ingress.citrix.com/frontend-ipアノテーションを使用してIngressリソースを作成します。このアノテーションの値は、NetScaler MPXまたはVPXのIngressエンドポイントIPアドレスと一致する必要があります。
これで、NetScaler MPX または VPX を構成して、コーヒーマイクロサービスポッドへの東西トラフィックを制御する Ingress オブジェクトを作成できます。
以下は、Ingress リソースのサンプルです。
サンプル(/en-us/netscaler-k8s-ingress-controller/media/coffee-headless-ingress.png)
これらの変更により、通常の Ingress ロードバランシング手法を使用することで、NetScaler MPX は東西トラフィックをロードバランスできるようになります。次の図は、Ingress ルールを使用して N-S および E-W プロキシとして構成された NetScaler MPX または VPX を示しています。
サンプル(/en-us/netscaler-k8s-ingress-controller/media/image006.png)
Service Mesh lite でのアプリケーションの自動展開
Service Mesh lite アーキテクチャでアプリケーションを展開するには、複数のタスクを手動で実行する必要があります。ただし、複数のマイクロサービスで構成される複数のアプリケーションを展開したい場合は、Service Mesh lite アーキテクチャでサービスを展開するより簡単な方法があります。NetScaler® は、展開準備ができた YAML を自動的に生成する方法を提供します。
このドキュメント は、NetScaler が提供するスクリプトを使用して、既存の YAML から Service Mesh lite 展開に必要なすべての YAML を生成する方法に関する情報を提供します。