Citrix ADC ingress controller

Citrix Ingress Controllerを使用したマルチクラスタイングレスおよび負荷分散ソリューション

概要

高可用性、近接ベースの負荷分散、およびスケーラビリティを確保するために、複数の分散 Kubernetes クラスタにアプリケーションをデプロイする必要がある場合があります。同じアプリケーションを複数の Kubernetes クラスタにデプロイする場合、クラスタに分散しているアプリケーションインスタンス間で負荷分散を決定する必要があります。

分散 Kubernetes クラスタに負荷分散ソリューションを実装するには、クラスタ全体のアプリケーションの健全性をグローバルに監視する必要があります。アプリケーションの可用性とパフォーマンスを監視し、クラスタ全体でアプリケーションステータスを更新し、データセンターのエンドポイントから統計を収集し、その統計をデータセンター全体で共有する必要があります。

Citrix は、アプリケーションをグローバルに監視し、異なるクラスター間でメトリックを収集および共有し、インテリジェントな負荷分散決定を提供する、マルチクラスターの入力および負荷分散ソリューションを提供します。これにより、Ingress または LoadBalancer タイプを使用して公開される Kubernetes サービスのパフォーマンスと信頼性が向上します。

デプロイトポロジー

次の図は、Kubernetes クラスタのマルチクラスタイングレスおよび負荷分散ソリューションのデプロイトポロジを示しています。

注:

LoadBalancer タイプのサービス(Citrix ADC を使用するベアメタルクラスターで使用可能)もサポートされます。

Multi-cluster-deployment

この図は、2 つのデータセンターがあり、各データセンターに複数の Kubernetes クラスタが含まれるトポロジの例を示しています。データセンター1では、Citrix ADC CPXが各KubernetesクラスターにIngressロードバランサーとして展開されます。データセンター 2 では、HAProxy が各 Kubernetes クラスターにロードバランサーとしてデプロイされます。Citrix マルチクラスタイングレスおよび負荷分散ソリューションで、イングレス間の Kubernetes 負荷分散を実現します。

注:

Istio イングレスゲートウェイや、Citrix ADC MPX、VPX、または BLX を搭載した Citrix Ingress Controller などのサードパーティソリューションを含む、すべてのイングレスソリューションがサポートされます。このトポロジは展開のサンプルにすぎません。

Citrix グローバルサーバー負荷分散(GSLB)デバイスは、データセンターごとに構成されます。グローバルロードバランサーとして機能する各Citrix ADCでは、1つのサイトがローカルデータセンターを表すローカルサイトとして構成されます。その他のサイトは、各リモートデータセンターのリモートサイトとして構成されます。GSLBとして使用されるCitrix ADC(MPXまたはVPX)は、Citrix Ingress Controllerを備えたイングレスアプライアンスとしても使用できます。

Citrix ADC グローバルサーバー負荷分散(GSLB)構成同期オプションは、サイト間で構成を同期するために使用されます。同期を使用するCitrix ADCアプライアンスはマスターノードと呼ばれ、構成がコピーされるサイトは下位サイトと呼ばれます。

展開内の各クラスターは GSLB Kubernetes コントローラーのインスタンスを実行します。GSLBコントローラーは、Citrix ADC GSLBデバイスの構成を担当するモジュールです。GSLB コントローラーは、それぞれのクラスターにデプロイされたアプリケーション用に GSLB マスターデバイスを構成します。GSLB マスターデバイスは、GSLB 同期機能を使用して、残りの GSLB 下位デバイスに GSLB 設定をプッシュします。GSLB 設定を同期すると、GSLB セットアップに参加しているすべての GSLB サイトの構成が、マスターサイトの構成と同様になります。

マルチクラスタイングレスおよび負荷分散ソリューションは、トラフィックをクラスタにルーティングするために使用される任意の Kubernetes オブジェクトに適用できます。

次のグローバル負荷分散方式がサポートされています。

次の展開タイプがサポートされています。

  • ローカルファースト:ローカルファースト展開では、アプリケーションが別のアプリケーションと通信する場合、同じクラスタ内のローカルアプリケーションが優先されます。アプリケーションがローカルで使用できない場合、リクエストは他のクラスターまたはリージョンに送信されます。

  • Canary: Canary リリースは、最初に一部のユーザーに変更をロールアウトすることで、新しいソフトウェアバージョンが実稼働環境に導入されるリスクを軽減する手法です。このソリューションでは、Canary Deployment は、アプリケーションを実稼働環境に移行する前に、選択したクラスターに新しいバージョンのアプリケーションをロールアウトする場合に使用できます。

  • フェイルオーバー:フェイルオーバー展開は、アクティブ/アクティブモードでデプロイできないアプリケーションをアクティブ/パッシブ構成でデプロイする場合に使用します。

  • ラウンドトリップ時間 (RTT): RTT 展開では、ネットワークのリアルタイムステータスが監視され、RTT 値が最も小さいデータセンターにクライアント要求が動的に送信されます。

  • 静的近接性:静的近接展開では、IP アドレスベースの静的近接データベースを使用して、クライアントのローカル DNS サーバーと GSLB サイト間の近接性を判断します。リクエストは、近接条件に最も一致するサイトに送信されます。

  • ラウンドロビン:ラウンドロビン展開では、GSLB デバイスはバインドされているサービスのリストを継続的にローテーションします。要求を受け取ると、接続を一覧の最初のサービスに割り当て、そのサービスを一覧の一番下に移動します。

注:

現在、IPv6 はサポートされていません。

Kubernetes クラスタのマルチクラスタイングレスおよび負荷分散ソリューションを構成するための CRD

KubernetesアプリケーションのGSLBを実行するためのCitrix ADC構成をサポートするために、次のCRDが導入されました。

  • グローバルトラフィックポリシー (GTP)
  • グローバルサービスエントリー (GSE)

GTP CRD

GTP CRDは、展開タイプ(Canary、フェイルオーバー、ローカルファースト)、GSLBドメイン、Ingressのヘルスモニター、サービスタイプなど、Citrix ADCでGSLBを構成するためのパラメーターを受け入れます。

GTP CRD 仕様は、Citrix Ingress Controller GitHub リポジトリ( grp-crd.yaml)で入手できます。

GSE CRD

GSE CRD は、各クラスターのエンドポイント情報 (トラフィックをクラスターにルーティングする任意の Kubernetes オブジェクト) を決定します。

GSE CRD 仕様は、Citrixのイングレスコントローラー GitHub リポジトリ( gse-crd.yaml)で入手できます。

Ingress リソースで指定されたサービスが GTP CRD インスタンスで参照され、status-loadbalancer-ip/hostname フィールドがすでに入力されている場合、Ingress オブジェクトに対して GSE CRD が自動生成されます。タイプLoadBalancerのサービスの場合、サービスが GTP CRD インスタンスで参照され、status-loadbalancer-ip/hostnameフィールドがすでに入力されている場合、GSE CRD は自動生成されます。

注: Ingress の場合の GSE CRD 自動生成では、ホスト名は GTP CRD インスタンスで指定されたホスト名と正確に一致する必要があります。Ingress と service of タイプLoadBalancerの両方で 、GSE CRD は指定された最初のポートに対してのみ生成されます。

Citrix マルチクラスタイングレスおよび負荷分散ソリューションを展開する

Citrix グローバル負荷分散ソリューションを展開する手順を実行する前に、次の前提条件が適用されます。

  • GSLBデバイスとして機能するCitrix ADCでGSLBサイトを構成する必要があります。
  • コンテンツスイッチングや SSL などの機能は、GSLB デバイスで有効にする必要があります
  • 静的近接では、ロケーションデータベースを外部から適用する必要があります。

地理的に分散したKubernetesクラスターにCitrix グローバル負荷分散ソリューションを展開するには、次の手順を実行します。

  1. gslb-rbac.yaml ファイルを使用して、GSLB コントローラーのデプロイに必要な RBAC パーミッションを作成します。

    kubectl apply -f gslb-rbac.yaml
    
  2. GSLB コントローラーが GSLB デバイスに接続するために必要なシークレットを作成し、GSLB コントローラーから設定をプッシュします。

    kubectl create secret generic secret-1 --from-literal=username=<username for gslb device1> --from-literal=password=<password for gslb device1>
    kubectl create secret generic secret-2 --from-literal=username=<username for gslb device2> --from-literal=password=<password for gslb device2>
    

    注:

    これらのシークレットは、各サイトの GSLB コントローラー YAML ファイルで使用されます。コマンドのusernameおよびpasswordは、Citrix GSLB ADCのユーザー名とパスワードを指定します。

  3. GSLB コントローラー YAML ファイル gslb-controller.yamlをダウンロードします。

  4. GSLB コントローラーの YAML ファイルを編集し、各クラスターの要件に従って以下の値を更新します。

    • LOCAL_REGION と LOCAL_CLUSTER: このコントローラーがデプロイされるリージョンとクラスター名を指定します。
    • SITENAMES: サイト名をカンマで区切って指定します。構成は GSLB デバイスで構成されたサイトと同じにする必要があります。
    • 各サイトの IP アドレス、リージョン、ユーザー名、およびパスワードは、対応するサイト名で始まる必要があります。 たとえば、SITENAMESのsite1の場合、フィールドはsite1_ipsite1_regionsite1_usernameおよびsite1_passwordになります 。
    • 仕様の引数セクションには--config-interfacegslb-endpointを含める必要があります。

    以下は、GSLB コントローラーをデプロイするための YAML ファイルのスニペットです。

    env:
     - name: "LOCAL_REGION"
       value: "east"
     - name: "LOCAL_CLUSTER"
       value: "cluster1"
     - name: "SITENAMES"
       value: "site1,site2"
     - name: "site1_ip"
       value: "x.x.x.x"
     - name: "site1_region"
       value: "east"
     - name: "site1_username"
       valueFrom:
         secretKeyRef:
           name: secret-1
           key: username
     - name: "site1_password"
       valueFrom:
         secretKeyRef:
           name: secret-1
           key: password
     - name: "site2_ip"
       value: "x.x.x.x"
     - name: "site2_region"
       value: "west"
     - name: "site2_username"
       valueFrom:
         secretKeyRef:
           name: secret-2
           key: username
     - name: "site2_password"
       valueFrom:
         secretKeyRef:
           name: secret-2
           key: password
    args:
    - --config-interface
        gslb-endpoints
    

    注:

    GSLB サイト情報の順序は、すべてのクラスタで同じにする必要があります。注文の最初のサイトが、構成をプッシュするマスター・サイトと見なされます。そのマスター・サイトがダウンすると、リスト内の次のサイトが新しいマスターになります。したがって、サイトの順序はすべての Kubernetes クラスタで同じにする必要があります。たとえば、 cluster1 でサイトでsite1site2の順序の場合、他のすべてのクラスタは同じ順序に従う必要があります。

  5. 対応するクラスター上の各クラスターに固有の、変更された GSLB コントローラーの YAML ファイルをデプロイします。

    kubectl apply -f gslb-controller.yaml
    
  6. 次のコマンドを使用して、 GTP CRD 定義 YAML ファイルをデプロイします。

    kubectl create -f  gtp-crd.yaml
    
  7. 次のコマンドを使用して GSE CRD 定義 YAML ファイルをデプロイします。

    kubectl create -f  gse-crd.yaml
    
  8. ドメインの GTP を YAML ファイルとして定義し、GTP インスタンスを適用します。

    kubectl create -f  gtp-example.yaml
    

    注:

    GTP CRD は、同じドメインに対して同じ設定を持つすべてのクラスタに適用する必要があります。

    次に、トラフィックポリシーがドメインapp2.comの local first として指定されているグローバルトラフィックポリシーの設定例を示します。アプリケーションでローカルなサービスが優先される場合は、このオプションを使用できます。ローカルクラスター (cluster1) の CIDR は、CIDR フィールドを使用して指定します。weightフィールドは、Citrix ADC が GSLB の決定を下したときに、他のクラスターよりも多くのクライアント要求を特定のクラスターに送信するために使用されます。 負荷分散方式は、secLbMethod フィールドをラウンドロビンとして使用して指定されます。

    注:

    ローカル First、Canary、およびフェイルオーバー展開の負荷分散方法を指定できます。

    apiVersion: "citrix.com/v1beta1"
    kind: globaltrafficpolicy
    metadata:
      name: gtp1
      namespace: default
    spec:
      serviceType: 'HTTP'
      hosts:
      - host: 'app2.com'
        policy:
          trafficPolicy: 'LOCAL-FIRST'
          secLbMethod: 'ROUNDROBIN'
          targets:
          - destination: 'app2.default.east.cluster1'
            CIDR: '10.102.217.69/24'
            weight: 1
          - destination: 'app2.default.west.cluster2'
            weight: 1
          monitor:
          - monType: tcp
            uri: ''
            respCode: 200
    

    Canary やフェールオーバーなど、その他の GTP 展開オプションの詳細については、「 例:グローバルトラフィックポリシーの展開」を参照してください。

  9. 進入の GSLB に対して GSE インスタンスを手動で適用します。

    kubectl create -f  gse-example.yaml
    

    注:

    GSE CRD は、クラスタエンドポイント情報に基づいて特定のクラスタに適用されます。グローバルサービスエントリ名は、グローバルトラフィックポリシーのターゲット宛先名と同じにする必要があります。

    グローバルサービスエントリの例を次に示します。

    apiVersion: "citrix.com/v1beta1"
    kind: globalserviceentry
    metadata:
      name: 'app2.default.east.cluster1'
      namespace: default
    spec:
      endpoint:
        ipv4address: 10.102.217.70
        monitorPort: 33036
    

    この例では、グローバルサービスエントリ名app2.default.east.cluster1は、ステップ 8 で作成したグローバルトラフィックポリシーのターゲット宛先名の 1 つです。

  10. LoadBalancer タイプのサービスの GSLB にサービス YAML を適用します。

     kubectl create -f  service-example.yaml
    

    以下はサンプルサービスです。

     apiVersion: v1
     kind: Service
     metadata:
       name: cold
       namespace: default
     spec:
       type: LoadBalancer
       ports:
       - name: port-8080
         port: 8090
         targetPort: 8080
       selector:
         dep: citrixapp
     status:
       loadBalancer:
         ingress:
         - ip: 10.102.217.72
    

Citrix ADC を使用した Amazon EKS および Microsoft AKS クラスター用のマルチクラウドイングレスおよび負荷分散ソリューションの設定例については、 Amazon EKS および Microsoft AKS クラスターを使用したマルチクラウドおよびマルチクラスターのイングレスおよび負荷分散ソリューションを参照してください

ポッドのDNS解決をCitrix GSLB ADCに指示する方法

注:

この手順はオプションであり、クラスター内のポッドがCitrix GSLB ADCを介してDNSを解決する必要がある場合にのみ必要です。

ポッドが Kubernetes クラスタ内にある場合

Kubernetes クラスター内のポッドで GSLB ソリューションを使用する場合は、DNS プロバイダーの ConfigMap を更新して、ドメイン(GSLB が必要)の要求を Citrix GSLB ADC に転送する必要があります。

次の例は、DNS プロバイダーが CoreDNS である場合に ConfigMap を更新する方法を示しています。

  # kubectl edit configmap coredns -n kube-system

    apiVersion: v1
    data:
      Corefile: |
        cluster.local:53 {
              errors
              health
              kubernetes cluster.local in-addr.arpa ip6.arpa {
                  pods insecure
                  upstream
                  fallthrough in-addr.arpa ip6.arpa
                  ttl 60
              }
              prometheus :9153
              forward . /etc/resolv.conf
              cache 90
              loop
              reload
              loadbalance
        }
        app2.com.:53 {
            errors
            cache 30
            forward . 10.102.217.149
        }
    kind: ConfigMap
    metadata:
      creationTimestamp: "2019-08-30T10:59:36Z"
      name: coredns
      namespace: kube-system
      resourceVersion: "43569751"
      selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
      uid: ac1d92e4-260f-45bd-8708-5f8194482885

例に示すように、ドメインの背後でホストされるアプリケーションに対して Pod が GSLB を決定できるようにするには、ドメインに必要な設定を追加する必要があります。ここで、ドメイン名はapp2.comです。

  app2.com.:53 {
      errors
      cache 30
      forward . 10.102.217.149
  }

指定されたIPアドレス(forward . 10.102.217.149)は、Citrix GSLB ADCで構成されたDNSサービスです。異なる GSLB サイトの複数の IP アドレスは、次のようにスペースで区切って指定できます。

  forward . ip1 ip2 ip3

Pod が OpenShift クラスター内にある場合

OpenShift クラスター内の Pod で GSLB ソリューションを使用する場合は、DNS オペレーターを更新して、ドメイン(GSLB が必要)の要求を Citrix GSLB ADC に転送する必要があります。

  # oc edit dns.operator/default

  apiVersion: operator.openshift.io/v1
  kind: DNS
  metadata:
    name: default
  spec:
    servers:
      - name: gslb-app2
        zones:
          - app2.com
        forwardPlugin:
          upstreams:
            - 10.102.217.149
            - 10.102.218.129:5353

例に示すように、ドメインの背後でホストされるアプリケーションに対して Pod が GSLB を決定できるようにするには、ドメインに必要な設定を追加する必要があります。ここで、ドメイン名はapp2.comです。

  servers:
      - name: gslb-app2
        zones:
          - app2.com
        forwardPlugin:
          upstreams:
            - 10.102.217.149
            - 10.102.218.129:5353

指定されたIPアドレス(10.102.217.149 および 10.102.218.129:5353)は、Citrix GSLB ADCで構成されたDNSサービスです。

この設定は、次のコマンドを使用して確認できます。

  # oc get configmap/dns-default -n openshift-dns -o yaml

  apiVersion: v1
  kind: ConfigMap
  metadata:
    labels:
      dns.operator.openshift.io/owning-dns: default
      manager: dns-operator
    name: dns-default
    namespace: openshift-dns
  data:
    Corefile: |
      # gslb-app2
      app2.com:5353 {
          forward . 10.102.217.149 10.102.218.129:5353
          errors
          bufsize 512
      }
      .:5353 {
          bufsize 512
          errors
          health {
              lameduck 20s
          }
          ready
          kubernetes cluster.local in-addr.arpa ip6.arpa {
              pods insecure
              fallthrough in-addr.arpa ip6.arpa
          }
          prometheus 127.0.0.1:9153
          forward . /etc/resolv.conf {
              policy sequential
          }
          cache 900 {
              denial 9984 30
          }
          reload
      }

GTP CRD の定義

GTP CRD の定義は gtp-crd.yamlで入手できます)

次の表に、GTP CRD 属性を示します。

フィールド 説明
ipType DNS レコードタイプを A または AAAA として指定します。現在、 A レコードタイプのみがサポートされています。
serviceType: マルチクラスタサポートが適用されるプロトコルを指定します。
host マルチクラスタサポートが適用されるドメインを指定します。
trafficPolicy マルチクラスタ展開でサポートされるトラフィック分散ポリシーを指定します。
sourceIpPersistenceId 一意の送信元 IP パーシステンス ID を指定します。この属性により、受信パケットの送信元 IP アドレスに基づくパーシステンスが有効になります。sourceIpPersistenceId 属性は 100 の倍数で、一意である必要があります。 設定例については、「例:送信元 IP パーシステンス」を参照してください。
secLbMethod local-first、Canary、またはフェールオーバーのグループに属するクラスタ間でサポートされるトラフィック分散ポリシーを指定します。
destination 各クラスターの Ingress または LoadBalancer サービスエンドポイントを指定します。宛先名は GSE の名前と一致する必要があります。
weight クラスタ全体に分散するトラフィックの比率を指定します。Canary展開の場合、比率はパーセンテージで指定されます。
CIDR ローカル性の範囲を決定するために local-first で使用する CIDR を指定します。
primary フェイルオーバー配置で、ターゲットが主クラスタかバックアップクラスタかを指定します。
monType マルチクラスタエンドポイントの正常性を判断するプローブのタイプを指定します。 モニタタイプが HTTPS の場合、TLS ハンドシェイク中は SNI がデフォルトで有効になります。
uri HTTP および HTTPS のマルチクラスタエンドポイントのヘルスについてプローブされるパスを指定します。
respCode マルチクラスタエンドポイントを HTTP および HTTPS に対して正常とマークする応答コードを指定します。

GSE CRD 定義

GSE CRD の定義は gse-crd.yamlで入手できます

例:グローバルトラフィックポリシーの展開

Canary 展開

Canary 展開は、アプリケーションを実稼働環境に移行する前に、選択したクラスターに新しいバージョンのアプリケーションをロールアウトする場合に使用できます。

このセクションでは、Canary 展開を使用したグローバルトラフィックポリシーのサンプルを説明します。このポリシーでは、実稼働環境にデプロイする前に、新しいバージョンのアプリケーションを段階的にロールアウトする必要があります。

この例では、アプリケーションの安定バージョンがwestリージョンのクラスターcluster2にデプロイされます。アプリケーションの新しいバージョンがeastリージョンのcluster1にデプロイされます。weight フィールドを使用して、各クラスターにリダイレクトされるトラフィックの量を指定できます。ここで weightは、40 パーセントと指定されています。したがって、トラフィックの 40% だけが新しいバージョンに送信されます。宛先にweightフィールドが記載されていない場合、トラフィックが過半数を占めるプロダクションの一部とみなされます。新しいバージョンのアプリケーションが安定していることが判明した場合は、新しいバージョンを他のクラスターにもロールアウトできます。

  apiVersion: "citrix.com/v1beta1"
  kind: globaltrafficpolicy
  metadata:
    name: gtp1
    namespace: default
  spec:
    serviceType: 'HTTP'
    hosts:
    - host: 'app1.com'
      policy:
        trafficPolicy: 'CANARY'
        secLbMethod: 'ROUNDROBIN'
        targets:
        - destination: 'app1.default.east.cluster1'
          weight: 40
        - destination: 'app1.default.west.cluster2'
        monitor:
        - monType: http
          uri: ''
          respCode: 200

フェイルオーバー展開

フェイルオーバー展開は、アプリケーションをアクティブ/パッシブ構成でデプロイする場合に使用できます。

フェイルオーバー展開では、アプリケーションは複数のクラスターに展開され、これらのクラスターはアクティブなクラスターグループ (group1) とパッシブクラスターグループ (group2) にグループ化されます。どの時点でも、1 つのクラスターセットだけがアクティブになり、もう 1 つのセットはパッシブのままです。group1 のすべてのクラスターが使用できなくなると、group2 のクラスターはアクティブ状態に移行します。group1 のいずれかのクラスターが後で使用可能になると、group1 はアクティブ状態に、group2 はパッシブ状態に移行します。

次の例は、フェールオーバー用の GTP 設定例を示しています。primary フィールドを使用して、どのクラスターがアクティブグループに属し、どのクラスターがパッシブグループに属するかを指定できます。このフィールドのデフォルト値はTrueで、 クラスターがアクティブグループに属していることを示します。設定した方式がラウンドロビンである場合、weightフィールドを使用すると、他のクラスターよりも多くのクライアント要求をグループ内の特定のクラスタに送信できます。グローバルトラフィックポリシーのmonitorパラメータは、Citrix ADCでモニターを構成するために使用されます。モニターを各クラスターのエンドポイントにバインドして、その正常性を調べることができます。

apiVersion: "citrix.com/v1beta1"
kind: globaltrafficpolicy
metadata:
  name: gtp1
  namespace: default
spec:
  serviceType: 'HTTP'
  hosts:
  - host: 'app1.com'
    policy:
      trafficPolicy: 'FAILOVER'
      secLbMethod: 'ROUNDROBIN'
      targets:
      - destination: 'app1.default.east.cluster1'
        weight: 1
      - destination: 'app1.default.west.cluster2'
        primary: false
        weight: 1
      monitor:
      - monType: http
        uri: ''
        respCode: 200

RTT展開

ラウンドトリップタイム展開のグローバルトラフィックポリシーの例を次に示します。

apiVersion: "citrix.com/v1beta1"
kind: globaltrafficpolicy
metadata:
  name: gtp1
  namespace: default
spec:
  serviceType: 'HTTP'
  hosts:
  - host: 'app1.com'
    policy:
      trafficPolicy: 'RTT'
      targets:
      - destination: 'app1.default.east.cluster1'
      - destination: 'app1.default.west.cluster2'
      monitor:
      - monType: tcp

ラウンドロビン展開

ラウンドロビン展開のトラフィックポリシーの例を次に示します。この展開は、トラフィックをクラスター全体に均等に分散する必要がある場合に使用できます。

apiVersion: "citrix.com/v1beta1"
kind: globaltrafficpolicy
metadata
  name: gtp1
  namespace: default
spec:
  serviceType: 'HTTP'
  hosts:
  - host: 'app1.com'
    policy:
      trafficPolicy: 'ROUNDROBIN'
      targets:
      - destination: 'app1.default.east.cluster1'
        weight: 2
      - destination: 'app1.default.west.cluster2'
        weight: 5
      monitor:
      - monType: tcp
        uri: ''
        respCode: 200

静的近接

静的近接展開のトラフィックポリシーの例を次に示します。

apiVersion: "citrix.com/v1beta1"
kind: globaltrafficpolicy
metadata:
  name: gtp1
  namespace: default
spec:
  serviceType: 'HTTP'
  hosts:
  - host: 'app1.com'
    policy:
      trafficPolicy: 'STATICPROXIMITY'
      targets:
      - destination: 'app1.default.east.cluster1'
      - destination: 'app1.default.west.cluster2'
      monitor:
      - monType: http
        uri: ''
        respCode: 200

例:ソース IP パーシステンス

次のトラフィックポリシーは、送信元 IP パーシステンスのサポートを有効にする例を示しています。送信元 IP のパーシステンスは、パラメータsourceIpPersistenceIdを指定することで有効にできます。送信元 IP パーシステンス属性は、サポートされるトラフィックポリシーで有効にできます。

apiVersion: "citrix.com/v1beta1"
kind: globaltrafficpolicy
metadata
  name: gtp1
  namespace: default
spec:
  serviceType: 'HTTP'
  hosts:
  - host: 'app2.com'
    policy:
      trafficPolicy: 'ROUNDROBIN'
      sourceIpPersistenceId: 300
      targets:
      - destination: 'app2.default.east.cluster1'
        weight: 2
      - destination: 'app2.default.west.cluster2'
        weight: 5
      monitor:
      - monType: tcp
        uri: ''
        respCode: 200
Citrix Ingress Controllerを使用したマルチクラスタイングレスおよび負荷分散ソリューション