高度な概念

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

May 18, 2020

寄稿者:

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 ルーティングを提供します。

展開手順

展開の名前空間を作成します。 oc create ns sml

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

製品ページサービスにマップするルートファイルを展開します。指定 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

実行に必要なパーミッションを 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

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

次に、クラスターの 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

新しいサービスをデプロイして、詳細コンテナを公開します。 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

作成した詳細サービスの前にある新しいルート定義を展開します。ラベルが「名前：詳細」の形式になっていることに注意してください。 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

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 ルートドキュメント:

このコンテンツの正式なバージョンは英語で提供されています。Citrix ドキュメントのコンテンツの一部は、お客様の利便性のみを目的として機械翻訳されています。Citrix は機械翻訳されたコンテンツを管理していないため、誤り、不正確な情報、不適切な用語が含まれる場合があります。英語の原文から他言語への翻訳について、精度、信頼性、適合性、正確性、またはお使いの Citrix 製品またはサービスと機械翻訳されたコンテンツとの整合性に関する保証、該当するライセンス契約書またはサービス利用規約、あるいは Citrix とのその他すべての契約に基づき提供される保証、および製品またはサービスのドキュメントとの一致に関する保証は、明示的か黙示的かを問わず、かかるドキュメントの機械翻訳された範囲には適用されないものとします。機械翻訳されたコンテンツの使用に起因する損害または問題について、Citrix は責任を負わないものとします。

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

May 18, 2020

寄稿者:

May 18, 2020

寄稿者:

この記事の概要

OpenShift クラスター内の静的ルートと自動ルート
Citrix Ingress Controllerの展開と OpenShiftのルーターシャーディングのサポート
マイクロサービス環境における継続的デリバリーの選択
参考資料