NetScalerによるKubernetes向け高度なコンテンツルーティング
KubernetesネイティブのIngressは、基本的なホストベースおよびパスベースのルーティングを提供します。しかし、ヘッダー値やクエリ文字列に基づくルーティングのような他の高度なルーティング技術は、Ingress構造ではサポートされていません。これらの機能は、Ingressアノテーションを介してKubernetes Ingress上で公開できますが、アノテーションは管理と検証が複雑です。
NetScaler®が提供する高度なコンテンツルーティング機能を、Kubernetes向けのカスタムリソース定義 (CRD) APIとして公開できます。
コンテンツルーティングCRDを使用すると、次のパラメーターに基づいてトラフィックをルーティングできます。
-
ホスト名
-
URLパス
-
HTTPヘッダー
-
クッキー
-
クエリパラメーター
-
HTTPメソッド
-
NetScalerポリシー式
注:
IngressリソースとコンテンツルーティングCRDは、同じサービス (IPアドレスとポート) に対して共存できません。IngressとコンテンツルーティングCRDの併用はサポートされていません。
高度なコンテンツルーティング機能は、次のCRDを使用してKubernetesで公開されます。
-
リスナー
-
HTTPルート
リスナー CRD
Listener CRDオブジェクトは、仮想IPアドレス、ポート、証明書、その他のフロントエンド構成などのエンドポイント情報を表します。また、デフォルトのトラフィックをバックエンドに送信したり、トラフィックをリダイレクトしたりするなどのデフォルトアクションも定義します。Listener CRDオブジェクトは、受信HTTPリクエストのHTTPルーティングロジックを表すHTTPRoute CRDオブジェクトを参照できます。
完全なCRD定義については、Listener CRDを参照してください。 Listener CRDのすべての属性に関する完全な情報については、Listener CRDドキュメントを参照してください。
Listener CRDは、HTTP、SSL、およびTCPプロファイルをサポートしています。これらのプロファイルを使用すると、デフォルトのプロトコル動作をカスタマイズできます。Listener CRDは、NetScalerがトランザクションまたはデータの種類を異なるエンドポイントにエクスポートできるようにするアナリティクスプロファイルもサポートしています。 Listener CRDのプロファイルサポートの詳細については、Listener CRDのプロファイルサポートを参照してください。
Listener CRDのデプロイ
-
Listener CRDをダウンロードします。
-
次のコマンドでListener CRDをデプロイします。
Kubectl create -f Listener.yaml例:root@k8smaster:# kubectl create -f Listener.yaml
customresourcedefinition.apiextensions.k8s.io/listeners.citrix.com created
Listener CRDオブジェクトの記述方法
KubernetesクラスターにNetScalerが提供するCRDをデプロイした後、YAMLファイルでリスナー構成を定義できます。YAMLファイルでは、kindフィールドに
Listenerを使用し、specセクションにリスナー構成の要件に基づいてListener CRD属性を追加します。 YAMLファイルをデプロイすると、NetScaler Ingress ControllerはNetScalerにリスナー構成を適用します。
以下は、
Listener-crd.yamlという名前のListener CRDオブジェクト定義のサンプルです。
apiVersion: citrix.com/v1
kind: Listener
metadata:
name: my-listener
namespace: default
spec:
certificates:
- secret:
name: my-secret
# Secret named 'my-secret' in current namespace bound as default certificate
default: true
- secret:
# Secret 'other-secret' in demo namespace bound as SNI certificate
name: other-secret
namespace: demo
- preconfigured: second-secret
# preconfigured certkey name in ADC
vip: '192.168.0.1' # Virtual IP address to be used, not required when CPX is used as ingress device
port: 443
protocol: https
redirectPort: 80
secondaryVips:
- "10.0.0.1"
- "1.1.1.1"
policies:
httpprofile:
config:
websocket: "ENABLED"
tcpprofile:
config:
sack: "ENABLED"
sslprofile:
config:
ssl3: "ENABLED"
sslciphers:
- SECURE
- MEDIUM
analyticsprofile:
config:
- type: webinsight
parameters:
allhttpheaders: "ENABLED"
csvserverConfig:
rhistate: 'ACTIVE'
routes:
# Attach the policies from the below Routes
- name: domain1-route
namespace: default
- name: domain2-route
namespace: default
- labelSelector:
# Attach all HTTPRoutes with label route=my-route
route: my-route
# Default action when traffic matches none of the policies in the HTTPRoute
defaultAction:
backend:
kube:
namespace: default
port: 80
service: default-service
backendConfig:
lbConfig:
# Use round robin LB method for default service
lbmethod: ROUNDROBIN
servicegroupConfig:
# Client timeout of 20 seconds
clttimeout: "20"
この例では、リスナーがHTTPSエンドポイントを公開しています。証明書セクションでは、エンドポイントのSSL証明書は、
my-secretとother-secretという名前のKubernetesシークレットと、second-secretという名前のcertkeyを持つデフォルトのADC事前構成済み証明書を使用して構成されます。リスナーのデフォルトアクションは、Kubernetesサービスとして構成されます。ルートは、ラベルセレクターと、名前および名前空間を使用した個別のルート参照の両方を使用して、リスナーにアタッチされます。
YAMLファイルでListener CRDオブジェクトを定義したら、次のコマンドを使用してYAMLファイルをデプロイします。この例では、
Listener-crd.yamlがYAML定義です。
Kubectl create -f Listener-crd.yaml
HTTPRoute カスタムリソース定義
HTTPRoute CRDオブジェクトは、受信HTTPリクエストのHTTPルーティングロジックを表します。ホスト名、パス、ヘッダー、クエリパラメータ、Cookieなど、さまざまなHTTPパラメータを組み合わせて、受信トラフィックをバックエンドサービスにルーティングできます。HTTPRouteオブジェクトは、エンドポイント情報を表す1つ以上のListenerオブジェクトにアタッチできます。HTTPRouteオブジェクトには1つ以上のルールを設定でき、各ルールには関連付けられたアクションが指定されます。HTTPRouteオブジェクト内のルールの評価順序は、オブジェクトに記述されている順序と同じです。例えば、rule1とrule2という順序の2つのルールがあり、rule1がrule2の前に記述されている場合、rule2の前にrule1が最初に評価されます。
HTTPRoute CRDの定義はHTTPRoute.yamlで入手できます。HTTP Route CRDの属性に関する完全な情報については、HTTPRoute CRD documentationを参照してください。
現在、NetScalerは、Kubernetes Ingressバージョン
networking.k8s.io/v1のIngressで、HTTPルートCRDリソースをリソースバックエンドとして構成することをサポートしています。この機能により、高度なコンテンツルーティング機能をIngressに拡張できます。詳細については、Advanced content routing for Kubernetes Ingress using HTTPRoute CRDを参照してください。
HTTPRoute CRD を展開する
HTTPRoute CRD を展開するには、以下を実行します。
-
HTTPRoute.yamlをダウンロードします。
-
次のコマンドを使用して、クラスターにHTTPRoute CRDを適用します。Kubectl apply -f HTTPRoute.yaml を実行します。例:
root@k8smaster:# kubectl create -f HTTPRoute.yaml
customresourcedefinition.apiextensions.k8s.io/httproutes.citrix.com configured
HTTPRoute CRD オブジェクトの記述方法
HTTPRoute CRDを展開したら、YAMLファイルでHTTPルート構成を定義できます。YAMLファイルでは、kindフィールドに
HTTPRouteを使用し、specセクションにHTTPルート構成の要件に基づいてHTTPRoute CRD属性を追加します。
以下は、
Route-crd.yamlという名前のHTTPRoute CRDオブジェクト定義のサンプルです。
apiVersion: citrix.com/v1
kind: HTTPRoute
metadata:
name: test-route
spec:
hostname:
- host1.com
rules:
- name: header-routing
match:
- headers:
- headerName:
exact: my-header
action:
backend:
kube:
service: mobile-app
port: 80
backendConfig:
secureBackend: true
lbConfig:
lbmethod: ROUNDROBIN
- name: path-routing
match:
- path:
prefix: /
action:
backend:
kube:
service: default-app
port: 80
この例では、
my-headerに一致するヘッダー名を持つリクエストはmobile-appサービスにルーティングされ、その他のすべてのトラフィックはdefault-appサービスにルーティングされます。 HTTPRouteの詳細な説明とAPI仕様については、HTTPRoute CRDを参照してください。
YAMLファイルでHTTPルートを定義したら、次のコマンドを使用してHTTPRoute CRDオブジェクトのYAMLファイルを展開します。この例では、
Route-crd.yamlがYAML定義です。
Kubectl create -f Route-crd.yaml
YAMLファイルをデプロイすると、NetScaler Ingress ControllerはIngress NetScalerデバイスにHTTPルート設定を適用します。
HTTPRoute CRDオブジェクトをListener CRDオブジェクトにアタッチする
HTTPRoute CRDオブジェクトをListener CRDオブジェクトにアタッチするには、次の2つの方法があります。
-
名前と名前空間を使用する
-
ラベルとセレクターを使用する
名前と名前空間を使用してHTTPRoute CRDオブジェクトをアタッチする
このアプローチでは、Listener CRDオブジェクトは、
routes セクションで名前と名前空間を指定することにより、1つ以上のHTTPRouteオブジェクトを明示的に参照します。 HTTPRouteオブジェクトの評価順序は、Listener CRDオブジェクトで指定された順序と同じであり、最初のHTTPRouteオブジェクトが最初に評価され、その後も同様です。
例えば、Listener CRDオブジェクトの抜粋を以下に示します。
routes:
- name: route-1
namespace: default
- name: route-2
namespace: default
この例では、route1という名前のHTTPRoute CRDオブジェクトは、route2という名前のHTTPRouteよりも先に評価されます。
ラベルとセレクターを使用してHTTPRoute CRDオブジェクトをアタッチする
ラベルとセレクターを使用して、HTTPRouteオブジェクトをListenerオブジェクトにアタッチすることもできます。Listener CRDオブジェクトに1つ以上のラベルを指定できます。ラベルに一致するHTTPRouteオブジェクトは、自動的にListenerオブジェクトにリンクされ、NetScalerでルールが作成されます。このアプローチを使用する場合、複数のHTTPRouteオブジェクト間に特定の評価順序はありません。唯一の例外は、デフォルトルート（ホスト名のみ、または「/」パスを持つルート）を持つHTTPRouteオブジェクトであり、これは最後のオブジェクトとして評価されます。
例えば、リスナーリソースの抜粋は次のとおりです。
routes:
- labelSelector:
team: team1