OpenShift 検証済みリファレンスデザインのルートを使用した Citrix ADC へのサービス移行

OpenShift クラスターの静的ルートと自動ルート

静的ルート (デフォルト)-OpenShift HostSubnet を静的ルート経由で外部 ADC にマッピングします

静的ルートは、HAProxy を使用するレガシー OpenShift デプロイメントでは一般的です。静的ルートは、Citrix ノードコントローラー (CNC)、Citrix ingress controller (CIC)、CPX と並行して使用でき、あるサービスプロキシから別のサービスプロキシにサービスを移行するときに、機能しているクラスターにデプロイされている名前空間を中断する必要はありません。

Citrix ADC 静的ルート構成例:

    oc get hostsubnet (Openshift Cluster) snippet
        oc311-master.example.com 10.x.x.x 10.128.0.0/23
        oc311-node1.example.com 10.x.x.x 10.130.0.0/23
        oc311-node2.example.com 10.x.x.x 10.129.0.0/23

    show route (external Citrix VPX) snippet
        10.128.0.0 255.255.254.0 10.x.x.x STATIC
        10.129.0.0 255.255.254.0 10.x.x.x STATIC
        10.130.0.0 255.255.254.0 10.x.x.x STATIC
<!--NeedCopy-->

自動ルート-CNC(Citrix Node Controller)を使用して、定義済みのルートシャードへの外部ルートを自動化します

Citrix ADC を OpenShift と 2 つの方法で統合できます。どちらも OpenShift ルーターのシャーディングをサポートしています。

ルートタイプ

  • unsecured-CICルーターへの外部ロードバランサー、HTTPトラフィックは暗号化されません。
  • secured-edge-TLS を終端する CIC ルータへの外部ロードバランサ。
  • secured-passthrough-TLSを終了する宛先への外部ロードバランサー
  • セキュアな再暗号化-TLS を終了する CIC ルータへの外部ロードバランサー。TLS を使用して宛先に暗号化する CIC ルーター。

Citrix ingress controller 展開ソリューションのさまざまなルートタイプの詳細を参照してください

Citrix Ingress Controllerの展開と OpenShiftのルーターシャーディングのサポート

Citrix Ingress Controller(CIC)はルーターとして機能し、トラフィックをさまざまなポッドにリダイレクトして、着信トラフィックをさまざまな利用可能なポッドに分散します。

この移行プロセスは、従来のOpenShiftトポロジーからCitrix CNC、CIC、CPXコンポーネントによる自動デプロイメントへのクラスタ移行およびアップグレード手順へのクラスタアップグレードプロセスの一部としても使用できます。

この解決策は、次の 2 つの方法で実現できます。

  • CIC ルータプラグイン (ポッド)
  • OpenShift 内部の CPX ルーター (サイドカー)

両方の方法を、移行例とともに以下で説明します。

OpenShift ルーターのシャーディングにより 、複数の OpenShift ルーター間で一連のルートを分散できます。デフォルトでは、OpenShift ルーターはすべての名前空間からすべてのルートを選択します。ルーターシャーディングでは、ルートまたは名前空間にラベルが追加され、ルートをフィルタリングするためにラベルセレクターがルーターに追加されます。各ルーターシャードは、ラベル選択パラメーターと一致する特定のラベルを持つルートのみを選択します。

OpenShift 上の Citrix ADC デプロイメント用にルーターシャーディングを構成するには、シャードごとに Citrix ingress controller インスタンスが必要です。Citrix ingress controller インスタンスは、シャーディングに必要な条件に応じて、ルートまたは名前空間のラベル、あるいはその両方を環境変数としてデプロイします。Citrix ingress controller はルートを処理するときに、ルートのラベルまたはルートの名前空間ラベルを、そのルートに構成された選択基準と比較します。ルートが基準を満たす場合、適切な構成がCitrix ADCに適用されます。それ以外の場合は構成が適用されません。

ルーターシャーディングでは、ルートのプール全体からルートのサブセットを選択するのは、選択式に基づきます。選択式は、複数の値と演算を組み合わせたものです。式、値、演算の詳細については、 このCitrix ブログを参照してください

Bookinfoの展開

Bookinfo アプリケーションのアーキテクチャを下の図に示します。CICは第1層にOpenShiftルータープラグインとして展開され、North-Southトラフィックを製品ページにルーティングするようにCitrix ADC VPXを構成します。2番目の層では、Citrix ADC CPXがOpenShiftルーターとして展開され、詳細と製品ページのマイクロサービスの間でEast-Westトラフィックをルーティングします。一方、製品ページ、レビュー、および評価マイクロサービス間のEast-Westトラフィックは、デフォルトのHAProxyルーターを介してルーティングされます。

サービスメッシュライトアーキテクチャとしてデプロイされた Bookinfo アプリのルートシャーディング図

Citrix コンポーネント

  • VPX-DNS にクラスターサービスを提示する入力ADC。
  • CIC-CNCルートを介して外部Citrix ADCにROUTE_LABELSとNAMESPACE_LABELSを提供します。
  • CPX-OpenShift クラスター内で OpenShift ルーティングを提供します。

展開手順

  1. デプロイ用の名前空間を作成します。 oc create ns sml
  2. Bookinfo アプリケーションを名前空間にデプロイします。 oc apply -f bookinfo.yaml

    ##################################################################################################
    # Details service
    ##################################################################################################
    apiVersion: v1
    kind: Service
    metadata:
      name: details
      labels:
        app: details
        service: details
    spec:
      ports:
      - port: 9080
        name: http
      selector:
        app: details
    ---
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: details-v1
      labels:
        app: details
        version: v1
    spec:
      replicas: 1
      template:
        metadata:
          annotations:
            sidecar.istio.io/inject: "false"
          labels:
            app: details
            version: v1
        spec:
          containers:
    "bookinfo.yaml" 224L, 5120C
    
    <!--NeedCopy-->
    
  3. 製品ページサービスにマップされるルートファイルをデプロイします。frontend-ipを指定(これはTier 1 ADCのコンテンツスイッチングVIPです) oc apply -f routes-productpage.yaml

    apiVersion: v1
    kind: Route
    metadata:
       name: productpage-route
       namespace: sml
       annotations:
        ingress.citrix.com/frontend-ip: "X.X.X.X"
       labels:
        name: productpage
    spec:
       host: bookinfo.com
       path: /
       port:
         targetPort: 80
       to:
         kind: Service
         name: productpage-service
    <!--NeedCopy-->
    
  4. CIC に実行に必要な権限を与える sml 名前空間の RBAC ファイルをデプロイします。RBAC ファイルは既に名前空間が設定されています。 oc apply -f rbac.yaml

     kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: cpx
    rules:
      - apiGroups: [""]
        resources: ["endpoints", "ingresses", "services", "pods", "secrets", "nodes", "routes", "namespaces","tokenreviews","subjectaccessreview"]
        verbs: ["get", "list", "watch"]
      # services/status is needed to update the loadbalancer IP in service status for integrating
      # service of type LoadBalancer with external-dns
      - apiGroups: [""]
        resources: ["services/status"]
        verbs: ["patch"]
      - apiGroups: ["extensions"]
        resources: ["ingresses", "ingresses/status"]
        verbs: ["get", "list", "watch"]
      - apiGroups: ["apiextensions.k8s.io"]
        resources: ["customresourcedefinitions"]
        verbs: ["get", "list", "watch"]
      - apiGroups: ["apps"]
        resources: ["deployments"]
        verbs: ["get", "list", "watch"]
      - apiGroups: ["citrix.com"]
        resources: ["rewritepolicies", "canarycrds", "authpolicies", "ratelimits"]
        verbs: ["get", "list", "watch"]
      - apiGroups: ["citrix.com"]
        resources: ["vips"]
        verbs: ["get", "list", "watch", "create", "delete"]
      - apiGroups: ["route.openshift.io"]
        resources: ["routes"]
        verbs: ["get", "list", "watch"]
    
    ---
    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: cpx
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: cpx
    subjects:
    - kind: ServiceAccount
      name: cpx
      namespace: sml
    ---
    apiVersion: v1
    kind: ServiceAccount
    metadata:
    "rbac.yaml" 51L, 1513C
     <!--NeedCopy-->
    
  5. CICを展開して、ルート構成をVPXにプッシュします。パラメータ ROUTE_LABELS をroute-productpage.yamlで指定されたラベルに一致させます。ROUTE_LABELS の構文の詳細については、 このブログを参照してくださいoc apply -f cic-productpage-v2.yaml

    apiVersion: v1
    kind: Pod
    metadata:
      name: cic
      labels:
        app: cic
    spec:
      serviceAccount: cpx
      containers:
      - name: cic
        image: "quay.io/citrix/citrix-k8s-ingress-controller:1.7.6"
        securityContext:
           privileged: true
        env:
        - name: "EULA"
          value: "yes"
        # Set NetScaler NSIP/SNIP, SNIP in case of HA (mgmt has to be enabled)
        - name: "NS_IP"
          value: "X.X.X.X"
        # Set NetScaler VIP that receives the traffic
    #    - name: "NS_VIP"
    #      value: "X.X.X.X"
        - name: "NS_USER"
          value: "nsroot"
        - name: "NS_PASSWORD"
          value: "nsroot"
        - name: "NS_APPS_NAME_PREFIX"
          value: "BOOK"
        - name: "ROUTE_LABELS"
          value: "name in (productpage)"
    #    - name: "NAMESPACE_LABELS"
    #      value: "app=hellogalaxy"
        # Set username for Nitro
    #    - name: "NS_USER"
    #      valueFrom:
    #       secretKeyRef:
    #        name: nslogin
    #        key: nsroot
    #    # Set user password for Nitro
    #    - name: "NS_PASSWORD"
    #      valueFrom:
    #       secretKeyRef:
    #        name: nslogin
    #        key: nsroot
        args:
    #    - --default-ssl-certificate
    #      default/default-cert
        imagePullPolicy: Always
    ~
    "cic-productpage-v2.yaml" 48L, 1165C
    <!--NeedCopy-->
    
  6. 次に、クラスター内のDNS Podを使用して、詳細を探しているユーザーをCPXに誘導するヘッドレスサービスを作成する必要があります。 oc apply -f detailsheadless.yaml

    ##################################################################################################
    # Details service
    ##################################################################################################
    apiVersion: v1
    kind: Service
    metadata:
      name: details
    spec:
      ports:
      - port: 9080
        name: http
      selector:
        app: cpx
    <!--NeedCopy-->
    
  7. 新しいサービスをデプロイして、詳細コンテナーを公開します。 oc apply -f detailsservice.yaml

    ##################################################################################################
    # Details service
    ##################################################################################################
    apiVersion: v1
    kind: Service
    metadata:
      name: details-service
      labels:
        app: details-service
        service: details-service
    spec:
      clusterIP: None
      ports:
      - port: 9080
        name: http
      selector:
        app: details
    <!--NeedCopy-->
    
  8. 作成した詳細サービスの前にある新しいルート定義をデプロイします。ラベルが「名前:詳細」になっていることに注意してください。 oc apply -f detailsroutes.yaml

    apiVersion: v1
    kind: Route
    metadata:
       name: details-route
       namespace: sml
       annotations:
        ingress.citrix.com/insecure-port: "9080"
       labels:
        name: details
    spec:
       host: details
       path: /
       port:
          targetPort: 9080
       to:
         kind: Service
         name: details-service
    <!--NeedCopy-->
    
  9. E/WトラフィックにCPXを導入します。CIC はサイドカーとして展開され、detailsroutes.yaml のラベルと一致するように ROUTE_LABEL パラメータで設定されます。 oc apply -f cpx.yaml

    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: cpx
      labels:
        app: cpx
        service: cpx
    spec:
      replicas: 1
      template:
        metadata:
          name: cpx
          labels:
            app: cpx
            service: cpx
          annotations:
            NETSCALER_AS_APP: "True"
        spec:
          serviceAccountName: cpx
          containers:
            - name: cpx
              image: "quay.io/citrix/citrix-k8s-cpx-ingress:13.0-36.28"
              securityContext:
                 privileged: true
              env:
              - name: "EULA"
                value: "yes"
              - name: "KUBERNETES_TASK_ID"
                value: ""
              - name: "MGMT_HTTP_PORT"
                value: "9081"
              ports:
              - name: http
                containerPort: 9080
              - name: https
                containerPort: 443
              - name: nitro-http
                containerPort: 9081
              - name: nitro-https
                containerPort: 9443
    # readiness probe?
              imagePullPolicy: Always
            # Add cic as a sidecar
            - name: cic
              image: "quay.io/citrix/citrix-k8s-ingress-controller:1.7.6"
              env:
              - name: "EULA"
                value: "yes"
              - name: "NS_IP"
    "cpx.yaml" 75L, 1939C
    <!--NeedCopy-->
    

マイクロサービス環境における継続的デリバリーの選択肢

継続的インテグレーション (CI) は、開発者が 1 日に数回コードを共有リポジトリに統合することを要求する開発手法です。

継続的デリバリー(CD)は、継続的インテグレーションの自然な拡張です。これは、チームがシステムに対するすべての変更がリリース可能であり、ボタンを押すだけで任意のバージョンをリリースできることを保証するアプローチです。

さまざまなCDの選択肢と、その長所と短所は次のとおりです。

  • 再作成 -バージョン 1 (V1) が終了し、バージョン 2 (V2) がロールアウトされます。
    • 長所
      • 簡単にセットアップできます。
      • アプリケーションの状態が完全に更新されました。
    • 短所
      • ユーザーに大きな影響を与えます。シャットダウンと起動時間の両方に依存するダウンタイムが予想されます。
  • Ramped/Rolling Update -V2 はゆっくりロールアウトされ、V1 を置き換えます。
    • 長所
      • 簡単にセットアップできます。
      • バージョンはインスタンス間でゆっくりリリースされます。
      • データのリバランスを処理できるステートフルなアプリケーションに便利です。
    • 短所
      • ロールアウト/ロールバックには時間がかかる場合があります。
      • 複数の API をサポートするのは難しいです。
      • 交通の制御がほとんどない。
  • ブルーグリーン -V2 が V1 とともにリリースされ、トラフィックが V2 に切り替わります。
    • 長所
      • 即時ロールアウト/ロールバック。
      • アプリケーション全体が一度に変更されるため、バージョンの問題は避けてください。
    • 短所
      • 2倍のリソースが必要なため、高価です。
      • 本番環境にリリースする前に、プラットフォーム全体を適切にテストする必要があります。
      • 複数のステートフルアプリケーションを処理するのは難しい場合があります。
  • Canary -V2は一部のユーザーにリリースされ、その後フルロールアウトに進みます。
    • 長所
      • 一部のユーザー向けにリリースされたバージョン。
      • エラー率とパフォーマンスの監視に便利です。
      • 高速ロールバック。
    • 短所
      • ロールアウトが遅い。
      • 複数のステートフルアプリケーションを処理するのは難しい場合があります。
  • A/B テスト -V2 は特定の条件下で一部のユーザーにリリースされます。
    • 長所
      • 複数のバージョンが並行して実行されます。
      • トラフィック分散を完全に制御します。
    • 短所
      • インテリジェントなロードバランサーが必要です。
      • 特定のセッションのエラーのトラブルシューティングが難しいため、分散トレーシングが必須になります。
  • シャドウ -V2 は V11 とともに現実世界のトラフィックを受信し、応答に影響を与えません。
    • 長所
      • 本番トラフィックを含むアプリケーションのパフォーマンステスト。
      • ユーザーには影響しません。
      • アプリケーションの安定性とパフォーマンスが要件を満たすまで、ロールアウトは行われません。
    • 短所
      • 2倍のリソースが必要なため、高価です。
      • 真のユーザーテストではなく、誤解を招く可能性があります。
      • 設定が複雑です。
      • 特定のケースではモックサービスが必要です。

参考資料

Citrix GitHub:「OpenShift ルートとイングレス」

Citrix Developer パードキュメント:「導入ソリューション」

シトリックスのブログ:「Citrix ADC で OpenShift ルーターのシャーディングサポートを有効にする」

OpenShift ルートのドキュメント:

OpenShift 検証済みリファレンスデザインのルートを使用した Citrix ADC へのサービス移行