Kubernetes(k8S)環境で活躍するCitrix ADC　その２

前回のブログに続き、再度の告知となります。Kubernetes環境におけるADC活用の貴重な実用例についてのセミナーですので、奮ってご参加ください。

2020年06月24日(水) 13:00スタートとなりますので、是非お早めにお申し込み下さい！

https://citrix.omniattend.com/seminar/networkjune24

皆様のご聴講をお待ちしております。

---

さてこのブログ記事のパート1ではIstio Gateway、仮想サービスリソース、Citrix Istio Adaptor、およびIstioサービスメッシュ内でさまざまな形態のCitirix ADCを、どのようにIngress Gatewayとして展開するかについて学びました。このパート2では、さまざまなアプリケーションにおいてCitrix ADC Ingress Gatewayのコンフィグレーションをどのように設定するかを引き続きUSのブログを日本語化してお届けします。

Istio Ingress GatewayとしてのCitrix ADC：パート2 – コンフィグレーション

https://citrixblogs.wpengine.com/2019/11/14/citrix-adc-as-an-istio-ingress-gateway-part-2-configuration/

Citrix ADCをIngress Gatewayとして動作させるためのリソース展開方法はすでに説明しました。しかしIngress Gatewayデバイス経由でExposeする必要のあるそれぞれのアプリケーションについては、アプリケーションの名前空間内でGatewayとVirtualServiceリソースを作成する必要があります。Citrix ADCのコンフィグレーションにおいては、VirtualServiceについては「gateways」フィールド内で適切なGatewayリソース名を、Gatewayについては「selector」フィールド内で「app: citrix-ingressgateway」を指定します。

HTTPベースとTCPベースの両方のアプリケーションを展開可能です。いずれの場合にもアプリケーションがエンドユーザーのトラフィックに対してExposeするようIngress Gatewayを設定します。またこのアプリケーションはセキュリティが確保された形態と通常の両方でExposeが可能です。言い換えればCitrix ADCはHTTPまたはHTTPSまたはその両方を使ってHTTPベースのアプリケーションをExposeし、TCPベースのアプリケーションはTCPまたはSSL-TCPまたはその両方を使ってExposeします。

HTTPアプリケーションのためのゲートウェイ設定

ここでは事例として、Istio Ingress GatewayとしてのCitirix ADCを通じてbookinfoをExposeします。セキュリティの確保された（HTTPS）ものと、確保されていない（HTTP）ものとの両方の取り込みゲートウェイについて検証してみます。アプリケーションのExposeにはGatewayとVirtualServiceが必要です。Citrix ADCを通じてbookinfoアプリケーションをExposeするため必要な、YAMLファイルのスニペットを以下に示しています。

ゲートウェイ

このYAMLファイルはbookinfoアプリケーションのHTTPとHTTPS両方のエンドポイントを同一ファイル内でExposeします。これらは別々のファイルに分割することも可能です。

# Source: bookinfo-citrix-ingress/templates/bookinfo_https_gateway.YAML apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata:   name: bookinfo-gateway spec:   selector:     app: citrix-ingressgateway   servers:   – port:       number: 443       name: https       protocol: HTTPS     tls:       mode: SIMPLE       serverCertificate: /etc/istio/ingressgateway-certs/tls.crt       privateKey: /etc/istio/ingressgateway-certs/tls.key     hosts:     – “www.bookinfo.com”   – port:       number: 80       name: http       protocol: HTTP     hosts:     – “www.bookinfo.com”

VirtualService

しかしGatewayだけでは不十分であり、これはVirtualServiceと連携して動作します。Citrix ADCはGatewayとVirtualServiceが作成された後にのみbookinfoアプリケーションをExposeするよう設定されています。

VirtualServiceは、リクエストルーティング、トラフィックシフト、およびフォールトインジェクションを含む、サービスメッシュ内でのトラフィックマネジメント設定のための手段を提供します。

下記のYAMLファイルはVirtualServiceを作成し、それを先に作成した「bookinfo-gateway」と関連付けます。ここではwww.bookinfo.com、「http[s]://vserverIP/productpage」、または「http[s]://vserverIP」を宛先とするサービスがproductpageサービスに送られます。productpageはbookinfoアプリケーションのフロントエンドサービスです。

# Source: bookinfo-citrix-ingress/templates/productpage_vs.YAML apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata:   name: productpage spec:   hosts:   – “www.bookinfo.com”   gateways:   – bookinfo-gateway   http:   – match:     – uri:         exact: /productpage     – uri:         prefix: /     route:     – destination:         host: productpage

GatewayとVirtualServiceリソースに加え、メッシュ内のトラフィックマネジメントをさらに詳細にコントロールするためDestination Ruleを追加することができます。これはトラフィックを最終的な宛先に送り出す前に、LBアルゴリズム、セッションアフィニティ、最大接続数、あるいはその他のポリシーを適用することによって行えます。

複数のホストを対象とするセキュリティの確保されたゲートウェイ設定

上記の例ではbookinfoアプリケーション（URL：www.bookinfo.com）のポート80と443に向かうトラフィックのためのゲートウェイ作成手順を示しています。

同一クラスター内に展開されている複数のアプリケーションをExposeする場合は、Citrix ADCでサポートされるServer Name Indication (SNI) を使って行えます。この場合には各アプリケーションについてそれぞれ別のゲートウェイを作成する必要があります。また各アプリケーションの証明書を使ってIstio Ingress Gatewayを再度展開する必要もあります。

サービスメッシュ内でbookinfoアプリケーションに加えて「httpbin」も展開し、これはURL：httpbin.example.comを使ってアクセスされるものとします。このhttpbinアプリケーションもCitrix ADCの同じvserverIPによるポート443を使ってExposeすることができます。この場合、Citrix ADCはハンドシェーク時にSSL「Client Hello」内に示されたホスト名を確認し、呼び出し側に適切な証明書を返します。SSLハンドシェークが正しく実行された後、その要求は該当するバックエンドサービスに転送されます。

複数のホストを対象としたゲートウェイ設定の詳細についてはこちらをクリックしてください。

TCPアプリケーションのためのゲートウェイ設定

これまではHTTPベースのアプリケーションをExposeする手段を見てきました。これに加え、TCPベースのアプリケーションもセキュリティの確保された、あるいは確保されていない両方の形態でExposeすることが可能です。ここではIstioサーバーメッシュ内において、ポート9000上にtcp-echoサーバーが展開されているものと仮定します。

TCPベースのIngress Gateway

下記のYAMLファイルにはサービスメッシュ内で実行されているtcp-echoサーバーをExposeするためのGatewayとVirtualServiceが含まれています。ここではCitrix ADCがtcpポート8000上で要求を受領し、それをポート9000のtcp-echoサーバーに転送します。

apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata:   name: tcp-echo-gateway spec:   selector:     istio: ns-ingressgateway   servers:   – port:       name: tcp-echo       number: 8000       protocol: TCP     hosts:     – “*” — apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata:   name: tcp-echo spec:   hosts:   – “*”   gateways:   – tcp-echo-gateway   tcp:   – match:     – port: 8000     route:     – destination:         host: tcp-echo         port:           number: 9000

USサイトにはTLSベースのIngress Gateway用YAMLも掲載してますのでご覧ください。

Citirix ADCがサポートするその他の機能

Citrix ADCはIstio Ingress Gatewayとしての機能に加え、他のさまざまな機能をサポートすることのできる多用途のアプリケーションデリバリーコントローラーです。これによってサポートされる機能には以下のものが含まれます。

• 負荷分散（ロードバランシング）
• セキュリティなIngress
•  重み付けされたクラスター
•  HTTPリライト
•  HTTPリダイレクト
•  mTLS
•  認証ポリシー（JWT Authを使用したエンドユーザーの認証やオリジンの認証、mutual TLSを使用したトランスポートの認証やサービス間の認証）

これらの機能の詳細についてはこちらをご覧ください。

まとめ

ここではHTTPアプリケーションのためのGateway設定と、複数のホストを対象としたセキュリティの確保されたGatewayの設定について説明しました。それではCitrix ADC Ingress Deviceがクラスター外からの要求を受信した場合はどうなるでしょうか？異なるリソースが互いにやり取りを行う場合の手順は以下のとおりです。

1. クライアントがIngress Gateway Device上でExposeしているポートに要求を送ります。これがCitrix ADC MPXまたはVPXデバイスの場合、その要求はvserverIPとIngress Gateway Serviceに示されているポートに送られます。Citrix ADC CPXの場合には、その要求はKubernetesクラスターのどのノードのIP（マスターかワーカーかは問題になりません）、およびIngress Gateway Serviceに示されているnodePortに送られます。
2. Citrix ADCは要求をKubernetes Service Port上のワーカーノードのひとつ（つまりGateway Serviceに示されているポート）に送ります。
3. このサービスは要求をVirtualServiceに示されているポート上のアプリケーションポッドに送ります。
4. 返信は上記と同じ経路を逆に辿って行われます。

さらに詳細を学ぶには

テンプレートから展開用YAMLファイルを生成するためのHelmチャートとスクリプトは、Citrix Istio Adaptor githubページのYAMLsに掲載されています。ここにはCitrix ADCをIngress Gatewayとして展開するための詳細な手順（およびそれを簡単に行うための手順）に加え、booinfoアプリケーションを展開し、それをCitrix ADCを使ってExposeするためのHelmチャートのサンプルが掲載されています。

Istioサービスメッシュ内でのCitirix ADC展開を試してみてください。問題が生じた場合にはCitrix Istio Adaptor githubページにリンクが掲載されているディスカッションフォーラムとSlackチャンネルをご覧ください。