Citrix ADC ingress controller

Citrix ADCを使用したKubernetesの高度なコンテンツルーティング

Kubernetes ネイティブ Ingress は、基本的なホストおよびパスベースのルーティングを提供します。ただし、Ingress 構造では、ヘッダー値やクエリ文字列に基づくルーティングなど、他の高度なルーティング手法はサポートされていません。Ingress アノテーションを使用して Kubernetes Ingress でこれらの機能を公開できますが、アノテーションの管理と検証は複雑です。

Citrix ADCが提供する高度なコンテンツルーティング機能を、Kubernetes用のカスタムリソース定義(CRD)APIとして公開できます。

コンテンツルーティング CRD を使用すると、次のパラメータに基づいてトラフィックをルーティングできます。

  • ホスト名
  • URL パス
  • HTTP ヘッダー
  • クッキー
  • クエリパラメーター
  • HTTP メソッド
  • Citrix ADC ポリシー式

注:

Ingress リソースとコンテンツルーティング CRD を同じエンドポイント(IP アドレスとポート)に共存させることはできません。Ingress でのコンテンツルーティング CRD の使用はサポートされていません。

高度なコンテンツルーティング機能は、次の CRD とともに Kubernetes で公開されています。

  • リスナー
  • HTTPRoute

コンテンツルーティング CRD

リスナー CRD

Listener CRD オブジェクトは、仮想 IP アドレス、ポート、証明書、その他のフロントエンド構成などのエンドポイント情報を表します。また、デフォルトトラフィックをバックエンドに送信したり、トラフィックをリダイレクトしたりするなど、デフォルトアクションも定義します。リスナー CRD オブジェクトは、着信 HTTP リクエストの HTTP ルーティングロジックを表す HttpRoute CRD オブジェクトを参照できます。

CRD の完全な定義については、 リスナー CRDを参照してください。 リスナー CRD のすべての属性について詳しくは、 リスナー CRD のドキュメントを参照してください

リスナー CRD は HTTP、SSL、および TCP プロファイルをサポートしています。これらのプロファイルを使用して、デフォルトのプロトコル動作をカスタマイズできます。リスナーCRDは、Citrix ADCがトランザクションまたはデータの種類を異なるエンドポイントにエクスポートできるようにする分析プロファイルもサポートしています。 リスナー CRD のプロファイルサポートの詳細については、「 リスナー CRD のプロファイルサポート」を参照してください。

リスナー CRD の展開

  1. リスナー CRDをダウンロードします。

  2. 以下のコマンドでリスナー CRD をデプロイします。

    Kubectl create -f  Listener.yaml
    

    例:

    root@k8smaster:# kubectl create -f Listener.yaml
    customresourcedefinition.apiextensions.k8s.io/listeners.citrix.com created
    

リスナー CRD オブジェクトの書き方

Citrix が提供する CRD を Kubernetes クラスターにデプロイしたら、YAML ファイルでリスナー構成を定義できます。YAML ファイルのkindフィールドでListenerを使用し、spec セクションで、リスナー設定の要件に基づいてリスナー CRD 属性を追加します。 YAML ファイルをデプロイした後、Citrix イングレスコントローラーは Ingress Citrix ADC デバイスにリスナー構成を適用します。

次に、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"
<!--NeedCopy-->

この例では、リスナーが HTTPS エンドポイントを公開しています。証明書セクションで、エンドポイントの SSL 証明書は、my-secretおよびother-secretという名前の Kubernetes シークレットと、second-secretという名前の certkey を持つデフォルトの ADC 事前構成済み証明書を使用して設定されます。リスナーのデフォルトアクションは Kubernetes サービスとして設定されます。ルートは、ラベルセレクターと name と namespace を使用した個別のルート参照の両方を使用して、リスナーにアタッチされます。

YAML ファイルで Listener CRD オブジェクトを定義したら、次のコマンドを使用して YAML ファイルをデプロイします。この例では、 Listener-crd.yaml は YAML の定義です。

Kubectl create -f  Listener-crd.yaml

httpRoute CRD

HTTProute CRD オブジェクトは、着信 HTTP リクエストの HTTP ルーティングロジックを表します。ホスト名、パス、ヘッダー、クエリパラメータ、Cookie などのさまざまな HTTP パラメータを組み合わせて、着信トラフィックをバックエンドサービスにルーティングできます。HTTProute オブジェクトは、エンドポイント情報を表す 1 つ以上の Listener オブジェクトにアタッチできます。HttpRoute オブジェクトには 1 つ以上のルールを含めることができ、各ルールは関連付けられたアクションを指定します。HttpRoute オブジェクト内のルールの評価順序は、オブジェクトで指定された順序と同じです。たとえば、rule1 と rule2 という順序のルールが 2 つあり、rule1 が rule2 の前に記述されている場合、rule1 は rule2 よりも先に評価されます。

httpRoute CRD の定義は httpRoute.yamlで入手できます。HTTP Route CRD の属性の詳細については、 HttpRoute CRD のドキュメントを参照してください

Ingress with Kubernetes Ingress Ingressバージョンnetworking.k8s.io/v1では、HTTPルートCRDリソースをリソースバックエンドとして構成できるようになりました。この機能により、高度なコンテンツルーティング機能をIngressに拡張できます。詳細については、 httpRoute CRD を使用した Kubernetes Ingress の高度なコンテンツルーティングを参照してください

httpRoute CRD をデプロイする

httpRoute CRD を展開するには、次の手順を実行します。

  1. httpRoute.yamlをダウンロードします。

  2. 以下のコマンドを使用して HTTPRoute CRD をクラスターに適用します。

    Kubectl apply -f HTTPRoute.yaml

    例:

    root@k8smaster:# kubectl create -f HTTPRoute.yaml
    customresourcedefinition.apiextensions.k8s.io/httproutes.citrix.com configured
    

HttRoute 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
<!--NeedCopy-->

この例では、ヘッダー名が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 ファイルをデプロイすると、Citrix イングレスコントローラーは Ingress Citrix ADC デバイスに HTTP ルート構成を適用します。

HTTPRoute CRD オブジェクトをリスナー 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オブジェクトに自動的にリンクされ、ルールはCitrix ADCで作成されます。この方法を使用する場合、複数の HTTProute オブジェクト間で特定の評価順序はありません。唯一の例外は、最後のオブジェクトとして評価されるデフォルトルート (ホスト名または ‘/’ パスのみのルート) を持つ HTTProute オブジェクトです。

たとえば、リスナーリソースのスニペットは次のようになります。

routes:
- labelSelector:
    team: team1
Citrix ADCを使用したKubernetesの高度なコンテンツルーティング