高度な概念

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

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

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

静的ルートは、HAProxy を使用するレガシー OpenShiftの展開では一般的です。静的ルートは、あるサービスプロキシから別のサービスプロキシにサービスを移行する場合に、機能しているクラスターに展開された名前空間を中断することなく、Citrix Node Controller(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

自動ルート-CNC(Citrix ノードコントローラ)を使用して、定義されたルートシャードへの外部ルートを自動化します

Citrix ADC を OpenShift と統合するには、2 つの方法があります。どちらの方法も OpenShift ルーターのシャーディングをサポートします。

ルートタイプ

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

さまざまなルートタイプについて詳しくは、Citrix 入力Controller 展開ソリューションを参照してください 。

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

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

この移行プロセスは、従来のOpenShiftトポロジーからCitrix CNC、CIC、CPXコンポーネントを使用した自動展開へのクラスターアップグレードプロセスの一部でもあります。

このソリューションは、次の 2 つの方法で実現できます。

  • CIC ルータープラグイン (Pod)
  • OpenShift 内にある CPX ルーター (サイドカー)

どちらの方法も、移行例とともに以下で説明します。

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

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

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

Bookinfoの展開

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

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

Citrix コンポーネント

  • VPX-DNS にクラスタサービスを提示する入力ADC。
  • CIC-CNCルートを介して外部Citrix ADC にルートラベルと名前空間のラベルを提供します。
  • 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
    
    
  3. 製品ページサービスにマップするルートファイルを展開します。指定 frontend-ip (これはティア1ADCのコンテンツスイッチング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
    
  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
    
  5. CICを展開して、ルート設定をVPXにプッシュします。パラメータ ROUTE_LABELS をroute-productpage.yamlで指定されたラベルに一致させます。ROUTE_LABERS の構文ついて詳しくは、こちら(ブログ)を参照してください。 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
    
  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
    
  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
    
  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
    
  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
    

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

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

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

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

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

参考資料

Citrix GitHub:「OpenShift routes and ingress」

Citrix Developer Docs:「Deployment solutions」

Citrixブログ:「Enable OpenShift router sharding support with Citrix ADC」

OpenShift ルートドキュメント:

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