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ルーターを介してルーティングされます。
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」