Red Hat OpenShift 3.11 検証済みリファレンスデザイン用のCitrix Cloudネイティブネットワーキング
Citrix ADC Stackは、高度にオーケストレーションされたクラウドネイティブ時代の環境へのアプリケーション可用性機能（ADC）、セキュリティ機能の分離（WAF）、アジャイルアプリケーショントポロジ（SSLとGSLB）のスケーリング、およびプロアクティブなオブザーバビリティ（Service Graph）の基本的な要件を満たします。
デジタルトランスフォーメーションにより、最新のアプリケーションデプロイメントをマイクロサービスベースのアーキテクチャに移行する必要性が高まっています。これらのクラウドネイティブアーキテクチャは、アプリケーションコンテナ、マイクロサービス、Kubernetes を活用します。
最新のアプリケーションへのクラウドネイティブアプローチは、アジャイルワークフロー、自動化デプロイツールセット、開発言語とプラットフォームなどの開発ライフサイクルも変革しました。
現代のアプリケーション導入の新時代は、月次および年次のソフトウェアリリースと契約、サイロコンピューティングリソースと予算、ベンダー消費モデルなど、従来のデータセンターのビジネスモデルの分野も変化させました。
そして、このような近代化はすべてエコシステムで行われていますが、アプリケーション可用性機能（ADC）、セキュリティ機能の分離（WAF）、アジャイルアプリケーショントポロジ（SSLとGSLB）のスケーリング、およびプロアクティブなオブザーバビリティ（Service Graph）を高度にオーケストレーションされたものにするための基本的な要件がまだあります。環境。
最新のアプリケーションデリバCitrix が選ばれる理由
最新のアプリケーション展開に対するCitrix ソフトウェアのアプローチでは、組織内の多くのチームにアジャイルワークフローを組み込む必要があります。アジャイルアプリケーションの開発と配信の利点の 1 つは、CI/CD として知られるフレームワークです。
CI/CD は、現代のアプリケーションライフサイクルにスピード、安全性、信頼性を提供する方法です。
継続的インテグレーション (CI) により、1 日に数回リアルタイムで更新し、自動ビルドプラットフォームに統合できる共通のコードベースが可能になります。 継続的インテグレーションの3つのフェーズは、プッシュ、テスト、修正です。
Continuous Delivery (CD) は、デプロイメントパイプラインをCI開発プロセスに直接統合することで、モダンアプリケーションのソフトウェア配信モデルを最適化および改善します。
Citrix ADCは、自動カナリア分析のプログレッシブロールアウトを実装することにより、継続的デリバリープロセスと連携
すべてのステークホルダー向けのソリューション
Citrix は、最新のアプリケーションを展開する際の機能横断的な要件に対応し、可観測性スタック、セキュリティフレームワーク、CI/CDインフラストラクチャのさまざまなコンポーネントを統合する、専用のソフトウェアベースのソリューションを作成しました。
最新のアプリケーションを導入するためにCI/CD技術を採用している従来の組織は、CI/CDに関わるすべてのメンバーに共通の配信と可用性のフレームワークを提供する必要性を認識していました。これらのリソースは一般にビジネスユニットの「利害関係者」として定義され、各利害関係者は組織の全体的な成功に投資し、各利害関係者は一般的に明確な要件と相違点を持っています。
現代のデリバリーアクティビティにおけるステークホルダーの一般的な例としては、次のものがあります。
- プラットフォームチーム — IaaS、PaaS、SDN、ADC、WAFなどのデータセンターインフラストラクチャを導入
- DevOpsとエンジニアリングチーム—統一されたコードリポジトリ、自動化ツール、ソフトウェアアーキテクチャの開発と保守
- サービス信頼性エンジニアリング (SRE) チーム — 組織のサイロ化、エラー管理、導入の自動化、測定を削減
- セキュリティ運用チーム — 積極的なセキュリティポリシー、インシデント管理、パッチ導入、ポートフォリオ強化
Citrix ソフトウェアスタックの説明
シングルコードベース-すべて同じコード - オンプレミス展開、パブリッククラウド展開、プライベートクラウド展開、GOVクラウド展開
-
プラットフォームの選択-あらゆるアジャイル要件を満たすため、あらゆるCitrix ADCモデルを選択
- CPX — Citrix ADC CPXはコンテナとして提供されるCitrix ADCです
- VPX — Citrix ADC VPX製品は、10 MB/sから100 Gb/sの範囲のパフォーマンスを提供するさまざまな仮想化およびクラウドプラットフォームでホストできる仮想アプライアンスです。
- MPX — Citrix ADC MPXは、500 MB/秒から200 GB/秒の範囲のパフォーマンスを提供するハードウェアベースのアプリケーション配信アプライアンスです。
- SDX — Citrix ADC SDXアプライアンスは、複数の仮想Citrix ADC マシン（インスタンス）をプロビジョニングおよび管理できるマルチテナントプラットフォームです。
- BLX — Citrix ADC BLXアプライアンスは、Citrix ADC ソフトウェアフォームファクタです。市販の市販サーバ（COTS）上のベアメタルLinux上でネイティブに動作するように設計されています。 コンテナ化された環境-オーバーレイを作成し、Citrix ADC
- Citrix Ingress Controller -Kubernetes Ingress を中心に構築され、Ingressリソース構成に基づいて1つ以上のCitrix ADCを自動的に構成します
-
Citrix Nodeコントローラー — KubernetesノードとIngress Citrix ADC
（ Citrix IPAMコントローラー）の間にVXLANベースのオーバーレイネットワークを作成し、IPアドレス （仮想IPアドレスまたはVIP）
プール容量を持つCitrix ADC上の負荷分散仮想サーバーを自動的に割り当てますライセンス —
1つのグローバルライセンス — ユビキタスグローバルライセンスプールは、プラットフォームとライセンスを分離し、設計とパフォーマンスの完全な柔軟性を実現します。
Application Delivery Manager — 一元管理
-フリートを管理し、ポリシーを調整し、アプリケーション、監視、
トラブルシューティングをリアルタイムで行う柔軟なトポロジ — 従来のデータセンターまたはモダンクラウド - 単一層、2層、およびサービスメッシュライト
Citrix ADC の価値
- Kubernetes と CNCF オープンソースツールの統合
- パーフェクトプロキシ — 最新のアプリケーション向けの実績のあるレイヤー 7 アプリケーションデリバリーコントローラー
- PodまたはSidecarデプロイメントの高性能ADCコンテナ
- 複数のオプションを使用した Kubernetes クラスターへの低遅延アクセス
- 豊富な機能を備えたAPI — セキュリティ機能を制限なく簡単に実装およびオーケストレーションできます
- CI/CD 用の高度なトラフィックステアリングと Canary の展開
- TLS/SSL、WAF、DoS、およびAPI保護による実証済みのセキュリティ
- 豊富なレイヤー 7 機能
- レガシーアプリケーションとモダンアプリケーションの導入のための統合監視
- 可視性のための実用的な洞察とサービスグラフ
Citrix ADC のメリット
- レガシーアプリを書き直すことなく移行
- 開発者はKubernetes APIを使用してCitrix ADCポリシーでアプリを保護できます（CRDを使用 — 開発者に優しい）
- North-South およびサービスメッシュ向けの高性能マイクロサービスの導入
- 1 つのアプリケーションサービスグラフをすべてのマイクロサービスに使用
- TCP、UDP、HTTP/S、SSL全体でマイクロサービスの問題をより迅速にトラブルシューティング
- Kubernetes API を使用して API を保護し、設定を行う
- カナリアへの配備のための CICD プロセスの強化
アーキテクチャコンポーネント
Citrix ADC スイートの利点
Citrix チョイスです。 従来のデータセンターやコンポーネントを使用している場合でも、新しいクラウドネイティブの最新アプリケーションを立ち上げた場合でも、Citrix ADCはあらゆるプラットフォーム要件にシームレスに統合できます。サブスクリプションベースのクラウドプラットフォームとツール向けのクラウドネイティブADC機能を提供し、Ingressコントローラーのオーケストレーションを簡単に行うことでオンプレミスのKubernetesクラスターへのトラフィックの転送とオーケストレーションを可能にし、シンプルなものから複雑なものまでサービスメッシュアーキテクチャに対応します。
Citrix 検証済みです。 検証済みの設計テンプレートとサンプルアプリケーションにより、希望する状態やビジネス要件を簡単に参照して、迅速かつ完全に対応できます。DevOps、SecOps、プラットフォームの各チームが参照しやすいように、構成例を文書化し、一元的に公開しています。
Citrix アジャイルかつモダンです。 顧客が既存のADCや新しいモジュール（CNC、IPAMなど）でCitrix Cloud Native Stackの新機能を利用できるようにするための基盤となるアーキテクチャを作成します。
Citrix オープンです。 パートナーエコシステムとの統合について、お客様に理解していただけるようお手伝いします。このドキュメントでは、オープンソースのCNCFツールとCitrix エンタープライズグレードの製品の両方を使用しています。
パートナーエコシステム
このトピックでは、Citrix ADCやCitrix Ingress Controller erを含むクラウドネイティブ展開でサポートされるさまざまなKubernetesプラットフォーム、展開トポロジ、機能、CNIについて詳しく説明します。
Citrix Ingress Controller は次のプラットフォームでサポートされています。
- Kubernetes v1.10はベアメタルで、またはAWS、GCP、Azureなどのパブリッククラウドでセルフホストされています。
- グーグル Kubernetes エンジン (GKE)
- Elastic Kubernetes サービス (EKS)
- Azure Kubernetes Service（AKS）
- レッドハット OpenShift バージョン 3.11 以降
- Pivotal Container Service（PKS）
- Diamanti Enterprise Kubernetes プラットフォーム
パートナーエコシステムには、次のものも含まれています。
- Prometheus — メトリクス、アラート、インサイトのためのモニタリングツール
- Grafana — 分析と監視のためのプラットフォーム
- Spinnaker — マルチクラウドの継続的デリバリーとカナリア分析のためのツール
- Elasticsearch — アプリケーションまたはサイト検索サービス
- Kibana — エラスティック検索データの視覚化ツールとエラスティックスタックナビゲーションツール
- Fluentd — データ収集ツール
この次のセクションでは、OpenShift を使用した設計/アーキテクチャに焦点を当てます。
OpenShift の概要
Red Hat OpenShift は、マイクロサービスとコンテナを使用してアプリケーションをより迅速に構築およびスケーリングすることに重点を置いたデプロイ用の Kubernetes プラットフォームです。OpenShiftはコンテナスタックの自動化、インストール、アップグレード、管理を行うことで、Kubernetesを効率化し、日々のDevOpsタスクを円滑にします。
- 開発者は、検証済みのソリューションやパートナーにアクセスできるようにアプリケーションをプロビジョニングし、効率化されたワークフローを通じて本番環境に移行します。
- 運用部門では、Web コンソールと組み込みのロギングとモニタリングを使用して、環境を管理および拡張できます。
図 1-6: OpenShift の高レベルアーキテクチャ。
OpenShift のその他の利点とコンポーネントには以下が含まれます。
- インフラの選択
- マスターノードとワーカーノード
- イメージレジストリ
- ルーティングとサービスレイヤー
- 開発者の操作 (導入しましたが、このドキュメントの範囲外です)
Red Hat OpenShift と Citrix ネイティブスタックを統合するユースケースには以下が含まれます。
- レガシーアプリケーションのサポート
- API としてデプロイされたリライト/レスポンダーポリシー
- マイクロサービスのトラブルシューティング
- セキュリティパッチと機能強化による日常業務
このドキュメントでは、Citric ADCがどのようにルーティング/サービス層をしっかりと統合するかについて説明します。
OpenShift プロジェクト
OpenShiftが最初に追加した新しいコンセプトはプロジェクトです。これは名前空間を効果的にラップし、名前空間へのアクセスはプロジェクトを介して制御されます。アクセスは、ユーザーとグループに基づく認証および承認モデルによって制御されます。そのため、OpenShift のプロジェクトは名前空間の間に壁を設け、ユーザーまたはアプリケーションが許可されているものだけを表示およびアクセスできるようにします。
OpenShift ネームスペース
Kubernetes の主なグループ化概念は名前空間です。名前空間は、クラスターリソースを複数の用途に分割する方法でもあります。とはいえ、Kubernetesの名前空間間のセキュリティはありません。Kubernetes クラスターの「ユーザー」であれば、さまざまな名前空間とそこに定義されているリソースをすべて表示できます。
OpenShift ソフトウェア定義ネットワーク (SDN)
OpenShift Container Platform は、ソフトウェア定義ネットワーク (SDN) アプローチを使用して、OpenShift Container Platform クラスター全体のポッド間の通信を可能にする統合クラスターネットワークを提供します。このポッドネットワークは、Open vSwitch (OVS) を使用してオーバーレイネットワークを構成する OpenShift SDN によって確立および管理されます。
OpenShift SDN には、ポッドネットワークを設定するための 3 つの SDN プラグインが用意されています。
- ovs-subnet プラグインはオリジナルのプラグインで、すべてのポッドが他のすべてのポッドやサービスと通信できる「フラット」なポッドネットワークを提供します。
- ovs-multitenant プラグインは、ポッドとサービスをプロジェクトレベルで分離します。各プロジェクトには、プロジェクトに割り当てられたポッドからのトラフィックを識別する一意の仮想ネットワーク ID (VNID) が割り当てられます。異なるプロジェクトのポッドは、別のプロジェクトのポッドやサービスとの間でパケットを送受信することはできません。
- ただし、VNID 0 を受け取ったプロジェクトは、他のすべての Pod との通信が許可され、その他すべての Pod がそれらと通信できるという点で、より特権的です。OpenShift Container Platform クラスターでは、デフォルトプロジェクトが VNID 0 になっています。これにより、ロードバランサーなどの特定のサービスがクラスター内の他のすべての Pod と通信しやすくなり、その逆も可能になります。
- ovs-networkpolicy プラグインを使用すると、プロジェクト管理者は NetworkPolicy オブジェクトを使用して独自の分離ポリシーを設定できます。
OpenShift ルーティングとプラグイン
OpenShift 管理者は OpenShiftクラスターにルーターをデプロイできます。これにより、 開発者が作成したルートを外部クライアントが使用できるようになります。OpenShift のルーティングレイヤーはプラガブルで、デフォルトで 2つの使用可能なルータープラグインが提供され、サポートされています。
OpenShift ルーターは、識別情報をルーターに直接渡すプロトコルを介して、外部ホスト名マッピングとサービスへの負荷分散を提供します。ルーターが送信先を決定するには、ホスト名がプロトコル内に存在する必要があります。
ルータプラグインは、ホストポート 80 および 443 にバインドできることを前提としています。これは、外部トラフィックがホストにルーティングされ、その後ルーターを通過できるようにするためです。また、ルーターは、クラスター内のすべての ポッドにアクセスできるようにネットワーキングが設定されていることを前提としています。
OpenShiftルーターは、OpenShiftインストール内のサービスを宛先とするすべての外部トラフィックの入力ポイントです。OpenShift は以下のルータープラグインを提供し、サポートします。
- HAProxy テンプレートルーターはデフォルトのプラグインです。OpenShift3/ose-haproxy-routerimage を使用して、OpenShift のコンテナ内でテンプレートルータープラグインと共に HAProxy インスタンスを実行します。現在、SNI 経由の HTTP (S) トラフィックと TLS 対応トラフィックをサポートしています。プライベートIPのみをリッスンするほとんどのコンテナとは異なり、ルーターのコンテナはホストネットワークインターフェースでリッスンします。ルーターは、ルート名の外部リクエストを、ルートに関連付けられたサービスによって識別される実際のポッドの IP に転送します。
- Citrix ingress controller は、OpenShift クラスターにルータープラグインとしてデプロイし、環境にデプロイされた Citrix ADC と統合できます。Citrix ingress controller を使用すると、Citrix ADC の高度な負荷分散およびトラフィック管理機能を OpenShift クラスターで使用できます。 Citrix ingress controller を OpenShift クラスターにルータープラグインとしてデプロイするを参照してください。
OpenShift ルートと入力メソッド
OpenShift クラスターでは、外部クライアントは Pod によって提供されるサービスにアクセスする方法を必要とします。OpenShift は、クラスターで実行されているサービスと通信するための 2 つのリソース、ルートとIngressを提供します。
ルート
OpenShift クラスターでは、ルートは特定のドメイン名のサービスを公開したり、ドメイン名をサービスに関連付けたりします。OpenShift ルーターは、routes で指定されたルールに従って OpenShift クラスター内のサービスに外部リクエストをルーティングします。OpenShift ルーターを使用する場合は、トラフィックがルーターに到達するように外部 DNS も設定する必要があります。
Citrix ingress controller は、OpenShift クラスターにルータープラグインとしてデプロイし、環境にデプロイされた Citrix ADC と統合できます。Citrix ingress controller を使用すると、Citrix ADC の高度な負荷分散およびトラフィック管理機能を OpenShift クラスターで使用できます。 OpenShift ルートはセキュリティで保護されている場合と保護されていない場合がありますセキュアなルートは、ルートの TLS 終端を指定します。
Citrix ingress controller は以下の OpenShift ルートをサポートします。
- セキュリティで保護されていないルート:セキュリティで保護されていないルートの場合、HTTP トラフィックは暗号化されません。
- エッジターミネーション:エッジターミネーションでは、TLS はルーターで終端されます。内部ネットワーク上のルータからエンドポイントへのトラフィックは暗号化されません。
- パススルーターミネーション:パススルーターミネーションでは、ルーターは TLS オフロードに関与せず、暗号化されたトラフィックは宛先に直接送信されます。
- 再暗号化の終了:再暗号化の終了では、ルーターは TLS 接続を終了し、エンドポイントへの別の TLS 接続を確立します。
Citrix ADCの使用方法に基づいて、Citrix Ingress Controller をOpenShiftクラスターにルータープラグインとしてデプロイするには、クラスター内のCitrix ADC CPXとして、またはクラスター外のCitrix ADC MPX/VPXとしてデプロイする2つの方法があります。
Citrix ADC CPX を OpenShift クラスター内のルーターとしてデプロイする
Citrix Ingress コントローラーは、同じポッド内の Citrix ADC CPX コンテナーと一緒にサイドカーとしてデプロイされます。このモードでは、Citrix ingress controller が Citrix ADC CPX を構成します。 Citrix ADC CPX を OpenShift クラスター内のルーターとしてデプロイするを参照してください。
Citrix ADC MPX/VPX を OpenShift クラスターの外部にルーターとしてデプロイする
Citrix Ingress Controllerは、スタンドアロンポッドとして展開され、OpenShift クラスターの外部から Citrix ADC MPX または VPX アプライアンスを制御できます。 Citrix ADC MPX/VPXをOpenShiftクラスター外のルーターとしてデプロイするを参照してください。
イングレス
KubernetesIngress は、リクエストホストまたはパスに基づいてリクエストをサービスにルーティングする方法を提供し、多数のサービスを単一のエントリポイントに集中させます。
Citrix Ingress ControllerはKubernetes入力を中心に構築され、入力リソースに基づいて1つまたは複数のCitrix ADCアプライアンスを自動的に構成します。
Ingress によるルーティングは次の方法で実行できます。
- ホスト名ベースのルーティング
- パスベースルーティング
- ワイルドカードベースのルーティング
- 完全パス照合
- 非ホスト名ルーティング
- デフォルトバックエンド
例と詳細については、 Ingress 設定を参照してください 。
Citrix ingress controller を OpenShift ルータープラグインとしてデプロイする
Citrix ADC の使用方法に基づいて、Citrix Ingress Controller を OpenShift クラスターにルータープラグインとしてデプロイするには、次の 2 つの方法があります。
- 同じポッド内のCitrix ADC CPXとサイドカーコンテナとして：このモードでは、Citrix Ingress ControllerがCitrix ADC CPXを構成します。 Citrix ADC CPX を OpenShift クラスター内のルーターとしてデプロイするを参照してください。
- OpenShiftクラスターのスタンドアロンポッドとして：このモードでは、クラスターの外部にデプロイされたCitrix ADC MPXまたはVPXアプライアンスを制御できます。 Citrix ADC MPX/VPXをOpenShiftクラスター外のルーターとしてデプロイするを参照してください。
推奨アーキテクチャ
マイクロサービスアーキテクチャを設計する際には、以下のアーキテクチャをお客様に推奨します。
- Citrix Unified Ingress
- Citrix 2 層イングレス
- Citrix サービスメッシュライト
図1-2: アーキテクチャは、比較的単純なものから、より複雑で機能豊富なものまでさまざまです。
Citrix Unified Ingress
Unified Ingress展開では、Citrix ADC MPXまたはVPXデバイスが、クライアントからのNorth-Southトラフィックを、クラスター内にマイクロサービスとしてデプロイされたエンタープライズグレードのアプリケーションにプロキシします。Citrix ingress controller、Kubernetesクラスターのポッドまたはサイドカーとしてデプロイされ、マイクロサービスまたはIngressリソースの変更に基づいてCitrix ADCデバイス（MPXまたはVPX）の構成を自動化します。
Unified Ingress モデルの実装は、アプリケーションがまだ一枚岩であるうちに開始できます。Citrix ADCをアプリケーションサーバーの前にリバースプロキシとして配置し、後で説明する機能を実装するだけです。これで、アプリケーションをマイクロサービスに変換する良い立場になります。
マイクロサービス間の通信は、任意のメカニズム (kube-proxy、IPVS など) を介して処理されます。
さまざまなカテゴリで提供される機能
Unified Ingress アーキテクチャの機能は 3 つのグループに分けられます。
最初のグループの機能はパフォーマンスを最適化します。
- 負荷分散
- 低遅延接続
- 高可用性
2 番目のグループの機能は、セキュリティを強化し、アプリケーション管理を容易にします。
- レート制限
- SSL/TLS ターミネーション
- HTTP/2 サポート
- ヘルスチェック
最後のグループの機能はマイクロサービスに固有のものです。
- サービスの中央通信ポイント
- API ゲートウェイ機能
概要
Unified Ingress Modelの機能には、サービスへの堅牢な負荷分散、中央通信ポイント、動的サービス検出、低遅延接続、高可用性、レート制限、SSL/TLSターミネーション、HTTP/2などがあります。
Unified Ingress モデルを使用すると、トラフィックの管理、要求の負荷分散、バックエンドマイクロサービスアプリケーションの変更への動的応答が容易になります。
利点には以下が含まれます。
- North-Southのトラフィックフローはスケーラブルで、可視化されて観測や監視が可能で、Spinnaker や Citrix ADM などのツールを使用して継続的な配信が可能です。
- 単一階層は、ネットワークとプラットフォームサービスを管理するインフラストラクチャチームを統合し、ホップを減らしてレイテンシを低減します
- Web App Firewall や SSL オフロードは必要ないが、後で追加できる社内アプリケーションに適しています
デメリットは以下のとおりです。
- kube-proxyではEast-Westのセキュリティはないが、L4セグメンテーション用にCalicoを追加できる
- Kubeプロキシのスケーラビリティは不明です
- kube-proxyは可視性、制御、ログを提供しないため、East-Westトラフィックの可視性は限られているか、まったくありません。これにより、オープンツールの統合と継続的な配信が妨げられます。
- プラットフォームチームもネットワークに精通している必要があります
Citrix 2 層イングレス
2層Ingressアーキテクチャモデルは、クラウドネイティブ初心者にとって素晴らしいソリューションです。このモデルでは、階層1のCitrix ADCが受信トラフィックを管理しますが、サービスインスタンスに直接送信するのではなく、開発者が管理する2層ADCに要求を送信します。Tier-2 Ingressモデルは、プラットフォームと開発チームが作成したポリシーをインバウンドトラフィックにのみ適用し、クラウドスケールとマルチテナントを可能にします。
図1-4：ティア1のCitrix ADC VPX/MPXおよびティア2のCitrix ADC CPXコンテナを含むCitrix 2層イングレスモデルの図。
Tier-1 によって提供される機能
従来のネットワークチームが管理する第1階層ADCは、L4負荷分散、Citrix Web App Firewall、SSLオフロード、およびリバースプロキシサービスを提供します。Tier-1のCitrix ADC MPXまたはVPXデバイスは、クライアントからTier-2のCitrix ADC CPXにトラフィック（North-South）をプロキシします。
デフォルトでは、Citrix Ingress ControllerはTier-1で次の構成をプログラムします。
- ユーザーへのアプリケーションのリバースプロキシ:
- コンテンツスイッチング仮想サーバー
- 仮想サーバー (フロントエンド、ユーザー向け)
- サービスグループ
- SSLオフロード
- NetScaler ロギング/デバッグ
- サービスのヘルスモニタリング
Tier-2 によって提供される機能
第1層ADCはリバースプロキシサービスを提供しますが、第2層ADCはプラットフォームチームが管理し、マイクロサービスへの通信ポイントとして機能し、以下を提供します。
- ダイナミックサービスディスカバリー
- 負荷分散
- 可視性と豊富な指標
Tier-2 Citrix ADC CPX は、トラフィックをKubernetesクラスター内のマイクロサービスにルーティングします。スタンドアロンポッドとして展開されたCitrix ingress controller は、Tier-1デバイスを構成します。また、1つまたは複数のCitrix ADC CPXポッドのサイドカーコントローラーは、同じポッド内の関連付けられたCitrix ADC CPXを構成します。
概要
2層モデルのマイクロサービスのネットワークアーキテクチャは、異なる役割用に構成された2つのADCを使用します。Tier-1 ADC はユーザー側のプロキシサーバーとして機能し、Tier-2 ADC はマイクロサービスのプロキシとして機能します。
異なるタイプの機能を 2 つの階層に分割することで、スピード、制御、およびセキュリティの最適化が可能になります。第 2 層では、負荷分散は高速、堅牢で、構成可能です。
このモデルでは、ADC 管理者と開発者の間に明確な隔たりがあります。開発者向けの BYOL です。
利点には以下が含まれます。
- North-Southのトラフィックフローはスケーラブルで、可視化されて観測や監視が可能で、Spinnaker や Citrix ADM などのツールを使用して継続的な配信が可能です。
- クラウドネイティブ初心者向けのシンプルで迅速なデプロイメントで、ネットワークチームとプラットフォームチーム向けの新規学習は限られています
デメリットは以下のとおりです。
- kube-proxyではEast-Westのセキュリティはないが、L4セグメンテーション用にCalicoを追加できる
- Kubeプロキシのスケーラビリティは不明です
- kube-proxyは可視性、制御、またはログを提供しないため、East-Westトラフィックの可視性は限られているか、まったくありません。これにより、オープンツールの統合と継続的な配信が妨げられます。
Citrix サービスメッシュライト
サービスメッシュライトは、3 つのモデルの中で最も機能が豊富です。内部的には安全で、高速で、効率的で、回復力があり、インバウンドおよびコンテナ間のトラフィックにポリシーを適用するために使用できます。
Service Mesh Lite モデルは、次のような複数のユースケースに適しています。
- 医療および金融アプリ — 規制やユーザー要件により、金融アプリと医療アプリにはセキュリティとスピードの組み合わせが義務付けられており、数十億ドルもの財務価値と評判価値がかかっています。
- eコマースアプリ — ユーザーの信頼はeコマースにとって大きな問題であり、スピードは競争上の重要な差別化要因です。そのため、スピードとセキュリティを組み合わせることが重要です。
概要
利点には以下が含まれます。
- ロードバランサを使用したネットワーキングへのより堅牢なアプローチ CPX は、インバウンドトラフィックとコンテナ間トラフィックにポリシーを適用し、完全な L7 ポリシーを展開します。
- North-SouthおよびEast-Westのトラフィックの豊富な観測性、分析、継続的配信、およびセキュリティ
- Citrix ADC が埋め込まれた各コンテナ用のカナリア
- 単一階層は、ネットワークとプラットフォームサービスを管理するインフラストラクチャチームを統合し、ホップを減らしてレイテンシを低減します
デメリットは以下のとおりです。
- より複雑なモデルの導入
- プラットフォームチームはネットワークに精通している必要があります
アーキテクチャの選択の概要
Citrix Unified Ingress
-
North-South（NS）アプリケーショントラフィック - 1つのCitrix ADCが、L4およびL7 NSトラフィック、セキュリティ、およびK8sクラスタ外の外部負荷分散を担当します。
-
East-West部 (EW) アプリケーショントラフィック - kube-proxyはL4 EWトラフィックを担当します。
-
セキュリティ - ADC は NS トラフィックの保護とユーザーの認証を行います。Kube-proxyはL4 EWトラフィックを担当します。
-
スケーラビリティとパフォーマンス - NSトラフィックは拡張性が高く、クラスタリングもオプションです。EWトラフィックとkube-proxyのスケーラビリティは不明です。
-
可観測性 - ADC は NS トラフィックの観測性に優れていますが、EW トラフィックの観測性はありません。
Citrix 2 層イングレス
-
North-South (NS) アプリケーショントラフィック - Tier-1 ADC は SSL オフロード、Web App Firewall、および L4 NS トラフィックを担当します。モノリスアプリケーションとCNアプリケーションの両方に使用されます。階層2のCPXは、k8sおよびL7 NSトラフィックの急激な変化を管理します。
-
East-West部 (EW) アプリケーショントラフィック - kube-proxyはL4 EWトラフィックを担当します。
-
セキュリティ - Tier-1 ADC は NS トラフィックのセキュリティを確保します。認証はどちらの ADC でも行うことができます。EWトラフィックはKube-proxyでは保護されていません。L4セグメンテーション用のCalicoを追加してください。
-
スケーラビリティとパフォーマンス - NSトラフィックは拡張性が高く、クラスタリングもオプションです。EWトラフィックとkube-proxyのスケーラビリティは不明です。
-
可観測性 ： Tier-1 ADCはNSトラフィックの観測性に優れていますが、EWトラフィックの観測性はありません。
Citrix サービスメッシュライト
-
North-South (NS) アプリケーショントラフィック - Tier-1 ADC は SSL オフロード、Web App Firewall、および L4 NS トラフィックを担当します。モノリスアプリケーションとCNアプリケーションの両方に使用されます。階層2のCPXは、k8sおよびL7 NSトラフィックの急激な変化を管理します。
-
East-West (EW) アプリケーショントラフィック - Tier-2 CPX または任意のオープンソースプロキシが L4 EW トラフィックを処理します。お客様は、CPXを使用するアプリケーションとkube-proxyを使用するアプリケーションを選択できます。
-
セキュリティ - Tier-1 ADC は NS トラフィックのセキュリティを確保します。認証はどちらの ADC でも行うことができます。Citrix CPXは、認証、SSLオフロード、およびEWトラフィックの保護を担当します。暗号化はアプリケーションレベルで適用できます。
-
スケーラビリティとパフォーマンス ： NSとEWのトラフィックは十分に拡張可能ですが、インラインホップが1つ増えます。
-
観測性 - Tier-1 ADCはNSトラフィックの優れた観測性を提供します。Tier-2 の CPX は EW トラフィックを監視できますが、無効にして CPX メモリまたは CPU フットプリントを減らすことができます。
デプロイ方法
Citrix Unified Ingress
OpenShiftによるCitrix Unified Ingressの展開を検証するには、Citrix ADC VPXまたはMPXを備えたサンプルの「ハローワールド」アプリケーションを使用してください。OpenShift のデフォルトの名前空間「default」がこの展開に使用されます。
-
Citrix ADCインスタンスは、NSIP/SNIPを使用して手動で構築および構成されています。XenServer へのCitrix ADC インストールについては、 こちらを参照してください。
-
次の YAML ファイルの例を OpenShift ディレクトリにコピーし、application.yaml という名前を付けます。
apiVersion: apps/v1 kind: Deployment metadata: name: hello-world spec: selector: matchLabels: run: load-balancer-example replicas: 2 template: metadata: labels: run: load-balancer-example spec: containers: - name: hello-world image: gcr.io/google-samples/node-hello:1.0 ports: - containerPort: 8080 protocol: TCP <!--NeedCopy--> -
アプリケーションを展開します。
oc apply -f application.yaml -
ポッドが動作していることを確認します。
oc get pods -
次の YAML ファイルの例を OpenShift ディレクトリにコピーし、service.yaml という名前を付けます。
apiVersion: v1 kind: Service metadata: name: hello-world-service spec: type: NodePort ports: - port: 80 targetPort: 8080 selector: run: load-balancer-example <!--NeedCopy--> -
NodePort を介してサービスを使用してアプリケーションを公開します。
oc apply -f service.yaml -
サービスが作成されたことを確認します。
oc get service -
次の YAML ファイルの例を OpenShift ディレクトリにコピーし、Ingress.yaml という名前を付けます。Citrix ADC の VIP にするには、アノテーション「ingress.citrix.com/frontend-ip」を空き IP アドレスに変更する必要があります。
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: hello-world-ingress annotations: kubernetes.io/ingress.class: "vpx" ingress.citrix.com/insecure-termination: "redirect" ingress.citrix.com/frontend-ip: "10.217.101.183" spec: rules: - host: helloworld.com http: paths: - path: backend: serviceName: hello-world-service servicePort: 80 <!--NeedCopy--> -
Ingress YAML ファイルをデプロイします。
oc apply -f ingress.yaml -
現在、サービスを使用して公開したアプリケーションポッドがあり、Ingressを使用してトラフィックをそれらにルーティングできます。Citrix Ingress Controller（CIC）をインストールして、これらの構成をTier 1 ADC VPXにプッシュします。CICを展開する前に、CICに正しい実行権限を与えるRBACファイルを展開します。
注:
rbac yaml ファイルは名前空間を指定しているので、どの名前空間が使用されるかまでは名前空間を変更する必要があります。
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: cpx rules: - apiGroups: [""] resources: ["services", "endpoints", "ingresses", "pods", "secrets", "nodes", "routes", "routes/status", "tokenreviews", "subjectaccessreviews"] verbs: ["\*"] - apiGroups: ["extensions"] resources: ["ingresses", "ingresses/status"] verbs: ["\*"] - apiGroups: ["citrix.com"] resources: ["rewritepolicies"] verbs: ["\*"] - apiGroups: ["apps"] resources: ["deployments"] verbs: ["\*"] <!--NeedCopy-->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: default <!--NeedCopy-->apiVersion: v1 kind: ServiceAccount metadata: name: cpx namespace: default <!--NeedCopy--> -
RBAC ファイルをデプロイします。
oc apply -f rbac.yaml -
CIC をデプロイする前に、YAML ファイルを編集します。仕様では、ティア1 ADCのSNIPで管理が有効になっている限り、NSIPまたはSNIPのいずれかを追加します。引数「ingress-classes」は、Ingress YAML ファイルで指定された入力クラス注釈と同じであることに注意してください。
apiVersion: v1 kind: Pod metadata: name: hello-world-cic labels: app: hello-world-cic spec: serviceAccountName: cpx containers: - name: hello-world-cic image: "quay.io/citrix/citrix-k8s-ingress-controller:1.1.3" env: # Set NetScaler NSIP/SNIP, SNIP in case of HA (mgmt has to be enabled) - name: "NS_IP" value: "10.217.101.193" # Set username for Nitro # Set log level - name: "NS_ENABLE_MONITORING" value: "NO" - name: "NS_USER" value: "nsroot" - name: "NS_PASSWORD" value: "nsroot" - name: "EULA" value: "yes" - name: "LOGLEVEL" value: "DEBUG" args: - --ingress-classes vpx - --feature-node-watch false imagePullPolicy: IfNotPresent <!--NeedCopy--> -
CIC をデプロイします。
oc apply -f cic.yaml -
すべてのポッドが動作していることを確認します。
oc get pods -
helloworld.com のエントリと Ingress YAML ファイルで指定された Citrix ADC の VIP を使用して、ローカルマシン上のホストファイルを編集します。
-
ブラウザで helloworld.com に移動します。「こんにちは Kubernetes！」が表示されるはずです。
注: 以下は削除コマンド です
oc delete pods (pod name) -n (namespace name)oc delete deployment (deployment name) -n (namespace name)oc delete service (service name) -n (namespace name)oc delete ingress (ingress name) -n (namespace name)oc delete serviceaccounts (serviceaccounts name) -n (namespace name)
Citrix 2 層イングレス
OpenShiftによるCitrix 2層Ingressデプロイメントを検証するには、Citrix ADC VPXまたはMPXを備えたサンプルの「hello-world」アプリケーションを使用してください。このデプロイでは、デフォルトの名前空間「tier-2-adc」が使用されます。**注:Pod、サービス、および Ingress をデプロイする場合、名前空間は「-n (名前空間名)」パラメーターを使用して指定する必要があります。
-
Citrix ADCインスタンスは、NSIP/SNIP/SNIPを使用して手動で構築および構成されます。XenServer へのCitrix ADC インストールは [こちら] にあります。インスタンスがすでに設定されている場合は、負荷分散またはコンテンツスイッチングで、Unified Ingressとして hello-world を展開して ADC にプッシュされた仮想サーバーをすべてクリアします。
-
「tier-2-adc」という名前の名前空間を作成します。
oc create namespace tier-2-adc -
次の YAML ファイルの例を OpenShift ディレクトリにコピーし、
application-2t.yamlという名前を付けます。apiVersion: apps/v1 kind: Deployment metadata: name: hello-world spec: selector: matchLabels: run: load-balancer-example replicas: 2 template: metadata: labels: run: load-balancer-example spec: containers: - name: hello-world image: gcr.io/google-samples/node-hello:1.0 ports: - containerPort: 8080 protocol: TCP <!--NeedCopy--> -
アプリケーションを名前空間にデプロイします。
oc apply -f application-2t.yaml -n tier-2-adc -
ポッドが動作していることを確認します。
oc get pods -
次の YAML ファイルの例を OpenShift ディレクトリにコピーし、
service-2t.yamlという名前を付けます。apiVersion: v1 kind: Service metadata: name: hello-world-service-2 spec: type: NodePort ports: -port: 80 targetPort: 8080 selector: run: load-balancer-example <!--NeedCopy--> -
NodePort を介してサービスを使用してアプリケーションを公開します。
oc apply -f service-2t.yaml -n tier-2-adc -
サービスが作成されたことを確認します。
oc get service -n tier-2-adc -
次の YAML ファイルの例を OpenShift ディレクトリにコピーし、
ingress-2t.yamlという名前を付けます。apiVersion: extensions/v1beta1 kind: Ingress metadata: name: hello-world-ingress-2 annotations: kubernetes.io/ingress.class: "cpx" spec: backend: serviceName: hello-world-service-2 servicePort: 80 <!--NeedCopy--> -
Ingress YAML ファイルをデプロイします。
oc apply -f ingress-2t.yaml -n tier-2-adc -
CIC と CPX に適切な実行権限を与える RBAC ファイルをデプロイします。
注：
rbac yaml ファイルは名前空間を指定しているので、どの名前空間が使用されるかまでは名前空間を変更する必要があります。
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: cpx rules: -apiGroups: [""] resources: ["services", "endpoints", "ingresses", "pods", "secrets", "nodes", "routes", "routes/status", "tokenreviews", "subjectaccessreviews"] verbs: ["\*"] -apiGroups: ["extensions"] resources: ["ingresses", "ingresses/status"] verbs: ["\*"] -apiGroups: ["citrix.com"] resources: ["rewritepolicies"] verbs: ["\*"] -apiGroups: ["apps"] resources: ["deployments"] verbs: ["\*"] --- 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: tier-2-adc --- apiVersion: v1 kind: ServiceAccount metadata: name: cpx namespace: tier-2-adc <!--NeedCopy--> -
RBAC ファイルをデプロイします。
oc apply -f rbac-2t.yaml -
CPXを作成するには、サービスアカウントに高い権限が必要です。
oc adm policy add-scc-to-user privileged system:serviceaccount:tier-2-adc:cpx -
CPX YAML ファイルを編集して
cpx-2t.yamlと呼びます。これにより、CPX とそれを公開するサービスがデプロイされます。Ingressクラスの引数がingress-2t.yamlファイル内のアノテーションと一致することに注目してください。apiVersion: extensions/v1beta1 kind: Deployment metadata: name: hello-world-cpx-2 spec: replicas: 1 template: metadata: name: hello-world-cpx-2 labels: app: hello-world-cpx-2 app1: exporter annotations: NETSCALER_AS_APP: "True" spec: serviceAccountName: cpx containers: - name: hello-world-cpx-2 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: "" imagePullPolicy: Always # Add cic as a sidecar - name: cic image: "quay.io/citrix/citrix-k8s-ingress-controller:1.1.3" env: - name: "EULA" value: "yes" - name: "NS_IP" value: "127.0.0.1" - name: "NS_PROTOCOL" value: "HTTP" - name: "NS_PORT" value: "80" - name: "NS_DEPLOYMENT_MODE" value: "SIDECAR" - name: "NS_ENABLE_MONITORING" value: "YES" - name: POD_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.namespace args: - --ingress-classes cpx imagePullPolicy: Always apiVersion: v1 kind: Service metadata: name: lb-service-cpx labels: app: lb-service-cpx spec: type: NodePort ports: - port: 80 protocol: TCP name: http targetPort: 80 selector: app: hello-world-cpx-2 <!--NeedCopy--> -
CPX をデプロイします。
oc apply -f cpx-2t.yaml -n tier-2-adc -
Pod が実行中であり、サービスが作成されていることを確認します。
oc get pods -n tier-2-adcoc get service -n tier-2-adc -
VPXからCPXにルーティングするIngressを作成します。フロントエンドIPはADC上の空いているIPでなければなりません。ファイルに名前を付けてください:
ingress-cpx-2t.yaml。apiVersion: extensions/v1beta1 kind: Ingress metadata: name: hello-world-ingress-vpx-2 annotations: kubernetes.io/ingress.class: "helloworld" ingress.citrix.com/insecure-termination: "redirect" ingress.citrix.com/frontend-ip: "10.217.101.183" spec: rules: - host: helloworld.com http: paths: - path: backend: serviceName: lb-service-cpx servicePort: 80 <!--NeedCopy--> -
Ingress をデプロイします。
oc apply -f ingress-cpx-2t.yaml -n tier-2-adc -
CIC をデプロイする前に、YAML ファイルを編集します。仕様では、ティア1 ADCのSNIPで管理が有効になっている限り、NSIPまたはSNIPのいずれかを追加します。
apiVersion: v1 kind: Pod metadata: name: hello-world-cic labels: app: hello-world-cic spec: serviceAccountName: cpx containers: - name: hello-world-cic image: "quay.io/citrix/citrix-k8s-ingress-controller:1.1.3" env: # Set NetScaler NSIP/SNIP, SNIP in case of HA (mgmt has to be enabled) - name: "NS_IP" value: "10.217.101.176" # Set username for Nitro # Set log level - name: "NS_ENABLE_MONITORING" value: "NO" - name: "NS_USER" value: "nsroot" - name: "NS_PASSWORD" value: "nsroot" - name: "EULA" value: "yes" - name: "LOGLEVEL" value: "DEBUG" args: - --ingress-classes helloworld - --feature-node-watch false imagePullPolicy: IfNotPresent <!--NeedCopy--> -
CIC をデプロイします。
oc apply -f cic-2t.yaml -n tier-2-adc -
すべてのポッドが動作していることを確認します。
oc get pods -n tier-2-adc -
helloworld.comのエントリと、VPXからCPXにルーティングするIngress YAMLファイルで指定されたCitrix ADC上のVIPを使用して、ローカルマシン上のホストファイルを編集します。
-
ブラウザで helloworld.com に移動します。「こんにちは Kubernetes！」が表示されるはずです。
Citrix サービスメッシュライト
Service Mesh Lite では、ビルトイン HAProxy 機能の代わりとして CPX (または他の Citrix ADC アプライアンス) を導入できます。これにより、KubernetesのN/S機能を拡張し、E/Wトラフィックの負荷分散、ルーティング、および監視機能も提供することができます。 Citrix ADC（MPX、VPX、またはCPX）は、E-Wトラフィックに次のような利点を提供します。
- 相互 TLS または SSL オフロード
- HTTP または HTTPS ヘッダーパラメータに基づいてトラフィックを許可またはブロックするコンテンツベースのルーティング
- 高度な負荷分散アルゴリズム (最小接続数、最小応答時間など)
- ゴールデンシグナル (エラー、レイテンシー、飽和、トラフィック量) の測定によるEast-Westトラフィックの観測性。Citrix ADMのサービスグラフは、マイクロサービスを監視およびデバッグするための可観測性ソリューションです。
- このデプロイシナリオでは、Bookinfo アプリケーションをデプロイし、デフォルトでどのように機能するかを確認します。次に、デフォルトのKubernetesサービスをリッピングして置き換え、CPXとVPXを使用してE/Wトラフィックをプロキシします。
CPX搭載のCitrixサービスメッシュライト
OpenShiftによるCitrix Unified Ingressの展開を検証するには、Citrix ADC VPXまたはMPXを備えたサンプルの「ハローワールド」アプリケーションを使用してください。OpenShift のデフォルトの名前空間「default」がこの展開に使用されます。
-
Citrix ADCインスタンスは、NSIP/SNIPを使用して手動で構築および構成されています。XenServer へのCitrix ADC インストールについては、 こちらを参照してください。
-
この展開の名前空間を作成します。この例では、
smlが使用されています。oc create namespace sml -
以下の YAML をコピーして、Bookinfo のデプロイメントとサービスを作成します。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:
- name: details
image: docker.io/maistra/examples-bookinfo-details-v1:0.12.0
imagePullPolicy: IfNotPresent
ports:
- containerPort: 9080
---
##################################################################################################
# Ratings service
##################################################################################################
apiVersion: v1
kind: Service
metadata:
name: ratings
labels:
app: ratings
service: ratings
spec:
ports:
- port: 9080
name: http
selector:
app: ratings
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: ratings-v1
labels:
app: ratings
version: v1
spec:
replicas: 1
template:
metadata:
annotations:
sidecar.istio.io/inject: "false"
labels:
app: ratings
version: v1
spec:
containers:
- name: ratings
image: docker.io/maistra/examples-bookinfo-ratings-v1:0.12.0
imagePullPolicy: IfNotPresent
ports:
- containerPort: 9080
---
##################################################################################################
# Reviews service
##################################################################################################
apiVersion: v1
kind: Service
metadata:
name: reviews
labels:
app: reviews
service: reviews
spec:
ports:
- port: 9080
name: http
selector:
app: reviews
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: reviews-v1
labels:
app: reviews
version: v1
spec:
replicas: 1
template:
metadata:
annotations:
sidecar.istio.io/inject: "false"
labels:
app: reviews
version: v1
spec:
containers:
- name: reviews
image: docker.io/maistra/examples-bookinfo-reviews-v1:0.12.0
imagePullPolicy: IfNotPresent
ports:
- containerPort: 9080
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: reviews-v2
labels:
app: reviews
version: v2
spec:
replicas: 1
template:
metadata:
annotations:
sidecar.istio.io/inject: "false"
labels:
app: reviews
version: v2
spec:
containers:
- name: reviews
image: docker.io/maistra/examples-bookinfo-reviews-v2:0.12.0
imagePullPolicy: IfNotPresent
ports:
- containerPort: 9080
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: reviews-v3
labels:
app: reviews
version: v3
spec:
replicas: 1
template:
metadata:
annotations:
sidecar.istio.io/inject: "false"
labels:
app: reviews
version: v3
spec:
containers:
- name: reviews
image: docker.io/maistra/examples-bookinfo-reviews-v3:0.12.0
imagePullPolicy: IfNotPresent
ports:
- containerPort: 9080
---
##################################################################################################
# Productpage services
##################################################################################################
apiVersion: v1
kind: Service
metadata:
name: productpage-service
spec:
type: NodePort
ports:
- port: 80
targetPort: 9080
selector:
app: productpage
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: productpage-v1
labels:
app: productpage
version: v1
spec:
replicas: 1
template:
metadata:
annotations:
sidecar.istio.io/inject: "false"
labels:
app: productpage
version: v1
spec:
containers:
- name: productpage
image: docker.io/maistra/examples-bookinfo-productpage-v1:0.12.0
imagePullPolicy: IfNotPresent
ports:
- containerPort: 9080
---
<!--NeedCopy-->
-
bookinfo.yaml を sml 名前空間にデプロイします。
oc apply -f bookinfo.yaml -n sml -
製品ページサービスにマップされる Ingress ファイルをコピーしてデプロイします。このファイルには
ingress-productpage.yamlという名前を付けることができます。フロントエンドIPは、Citrix ADC VPX/MPX上の無料のVIPでなければなりません。apiVersion: extensions/v1beta1 kind: Ingress metadata: name: productpage-ingress annotations: kubernetes.io/ingress.class: "bookinfo" ingress.citrix.com/insecure-termination: "redirect" ingress.citrix.com/frontend-ip: "10.217.101.182" spec: rules: - host: bookinfo.com http: paths: - path: backend: serviceName: productpage-service servicePort: 80 <!--NeedCopy-->
oc apply -f ingress-productpage.yaml -n sml
-
sml 名前空間の RBAC ファイル用に次の YAML をコピーしてデプロイします。製品ページのマイクロサービスの前に、CICに使用されているためファイル
rbac-cic-pp.yamlに名前を付けます。kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: cpx rules: - apiGroups: [""] resources: ["services", "endpoints", "ingresses", "pods", "secrets", "routes", "routes/status", "nodes", "namespaces"] verbs: ["\*"] - apiGroups: ["extensions"] resources: ["ingresses", "ingresses/status"] verbs: ["\*"] - apiGroups: ["citrix.com"] resources: ["rewritepolicies", "vips"] verbs: ["\*"] - apiGroups: ["apps"] resources: ["deployments"] verbs: ["\*"] - apiGroups: ["apiextensions.k8s.io"] resources: ["customresourcedefinitions"] 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: rbac.authorization.k8s.io/v1 --- apiVersion: v1 kind: ServiceAccount metadata: name: cpx namespace: sml <!--NeedCopy-->
oc apply -f rbac-cic-pp.yaml -n sml
-
サービスアカウント権限を昇格させて、CIC と CPX を展開します。
oc adm policy add-scc-to-user privileged system:serviceaccount:sml:cpx -
bookinfo.com が
ingress-productpage.yamlで指定されたフロントエンド IP にマップされているローカルマシン上のホストファイルを編集します。 -
CIC を使用して製品ページをコピーして展開します。ファイル
cic-productpage.yamlに名前を付けます。NS_IPは階層1のADCのNS_IPでなければなりません。apiVersion: v1 kind: Pod metadata: name: productpage-cic labels: app: productpage-cic spec: serviceAccountName: cpx containers: - name: productpage-cic image: "quay.io/citrix/citrix-k8s-ingress-controller:1.1.3" env: # Set NetScaler NSIP/SNIP, SNIP in case of HA (mgmt has to be enabled) - name: "NS_IP" value: "10.217.101.176" # Set username for Nitro # Set log level - name: "NS_ENABLE_MONITORING" value: "NO" - name: "NS_USER" value: "nsroot" - name: "NS_PASSWORD" value: "nsroot" - name: "EULA" value: "yes" - name: "LOGLEVEL" value: "DEBUG" - name: "NS_APPS_NAME_PREFIX" value: "BI-" args: - --ingress-classes bookinfo - --feature-node-watch false imagePullPolicy: IfNotPresent <!--NeedCopy-->
oc apply -f cic-productpage.yaml -n sml
-
bookinfo.comに移動し、「一般ユーザー」をクリックします。製品ページには、他のマイクロサービスである詳細、レビュー、評価が表示されるはずです。HAProxy はマイクロサービス (East-West) 間のトラフィックをルーティングします。
-
詳細の前に表示されているサービスを削除します。Bookinfo ウェブページを更新すると、製品ページがマイクロサービスをプルして詳細を確認できなかったことがわかります。
oc delete service details -n sml -
ヘッドレスサービスをコピーしてデプロイし、製品ページから詳細までのトラフィックがCPXを経由するようにします。このファイルを detailsheadless.yaml と呼んでください。
apiVersion: v1 kind: Service metadata: name: details spec: ports: - port: 9080 name: http selector: app: cpx <!--NeedCopy-->
oc apply -f detailsheadless.yaml -n sml
-
detailsservice.yaml という名前の新しい詳細サービスをコピーしてデプロイし、詳細マイクロサービスの前に配置します。
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-->
oc apply -f detailsservice.yaml -n sml
-
詳細サービスを Ingress で公開してデプロイします。このファイルをdetailsingress.yamlと呼んでください。
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: details-ingress annotations: kubernetes.io/ingress.class: "cpx" ingress.citrix.com/insecure-port: "9080" spec: rules: - host: details http: paths: - path: backend: serviceName: details-service servicePort: 9080 <!--NeedCopy-->
oc apply -f detailsingress.yaml -n sml
-
cpxEastWest.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: reviews-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 imagePullPolicy: Always # Add cic as a sidecar - name: cic image: "quay.io/citrix/citrix-k8s-ingress-controller:1.2.0" env: - name: "EULA" value: "yes" - name: "NS_IP" value: "127.0.0.1" - name: "NS_PROTOCOL" value: "HTTP" - name: "NS_PORT" value: "80" - name: "NS_DEPLOYMENT_MODE" value: "SIDECAR" - name: "NS_ENABLE_MONITORING" value: "YES" - name: POD_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.namespace args: - --ingress-classes cpx imagePullPolicy: Always <!--NeedCopy-->
oc apply -f CPXEastWest.yaml -n sml
- bookinfo.com を更新すると、詳細マイクロサービスから詳細が取得されるはずです。CPX は EW トラフィックのプロキシに正常にデプロイされました。
VPX/MPX搭載のCitrixサービスメッシュライト
-
次のコマンドを実行して、EW プロキシとして使用されている CPX を削除します。新しいファイルがデプロイされ、VPXを製品ページと詳細マイクロサービスの間のEWプロキシとして構成します。
oc delete -f detailsheadless.yaml -n smloc delete -f detailsservice.yaml -n smloc delete -f detailsingress.yaml -n smloc delete -f CPXEastWest.yaml -n sml -
サービスをコピーしてデプロイし、ファイルにDetailsToVPX.yamlという名前を付けて、製品ページからVPXにトラフィックを送り返します。IPパラメータは、Citrix ADC VPX/MPXのフリーVIPでなければなりません。
--- kind: "Service" apiVersion: "v1" metadata: name: "details" spec: ports: - name: "details" protocol: "TCP" port: 9080 --- kind: "Endpoints" apiVersion: "v1" metadata: name: "details" subsets: - addresses: - ip: "10.217.101.182" # Ingress IP in MPX ports: - port: 9080 name: "details" <!--NeedCopy-->
oc apply -f detailstoVPX.yaml -n sml
-
詳細マイクロサービスの前に detailsservice.yaml を再デプロイします。
oc apply -f detailsservice.yaml -n sml -
Ingressをコピーしてデプロイし、詳細なマイクロサービスをVPXに公開します。これは
detailsVPXingress.yamlという名前です。フロントエンド IP は Tier 1 ADC の VIP と一致する必要があります。apiVersion: extensions/v1beta1 kind: Ingress metadata: name: details-ingress annotations: kubernetes.io/ingress.class: "vpx" ingress.citrix.com/insecure-port: "9080" ingress.citrix.com/frontend-ip: "10.217.101.182" spec: rules: - host: details http: paths: - path: backend: serviceName: details-service servicePort: 9080 <!--NeedCopy-->
oc apply -f detailsVPXingress.yaml
- bookinfo.comを更新すると、詳細マイクロサービスから詳細を取得する必要があります。VPXはEWトラフィックをプロキシするために正常に展開されました。
Openshiftのルートまたはイングレス・クラスを使用したCitrix ADCへのサービス移行
ルートシャーディングによるサービス移行
Citrix Ingress Controller（CIC）はルーターとして機能し、トラフィックをさまざまなポッドにリダイレクトして、着信トラフィックをさまざまな利用可能なポッドに分散します。
この移行プロセスは、従来のOpenshiftトポロジーから、Citrix CNC、CIC、CPXコンポーネントによる自動デプロイメントへのクラスタ移行およびアップグレード手順へのクラスタアップグレードプロセスの一部としても使用できます。
この解決策は、次の 2 つの方法で実現できます。
- プラグイン別 CIC ルーター (Pod)
- Openshift 内の CPX ルーター (サイドカー)
両方の方法を、移行例とともに以下で説明します。
静的ルート (デフォルト) -静的ルートを介して Openshift HostSubnet を外部 ADC にマッピングします。
静的ルートは、HAProxy を使用するレガシー Openshift デプロイメントでは一般的です。静的ルートは、機能しているクラスターにデプロイされた名前空間を中断することなく、あるサービスプロキシから別のサービスプロキシにサービスを移行するときに、Citrix CNC、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 Node Controller）を使用して、定義されたルートシャードへの外部ルートを自動化します。
Citrix ADC を OpenShift と 2 つの方法で統合できます。どちらも OpenShift ルーターのシャーディングをサポートしています。
ルートタイプ
- unsecured-CICルーターへの外部ロードバランサー、HTTPトラフィックは暗号化されません。
- secured-edge-TLS を終端する CIC ルータへの外部ロードバランサ。
- secured-passthrough-TLSを終了する宛先への外部ロードバランサー
- セキュアな再暗号化-TLS を終了する CIC ルータへの外部ロードバランサー。TLSを使用して宛先に暗号化するCICルーター。
デプロイ例 #1: OpenShift ルータープラグインとしてデプロイされた CIC
ルートについては、ルートシャーディングの概念を使用します。ここで、CIC はルーターとして機能し、トラフィックをさまざまな Pod にリダイレクトして、着信トラフィックをさまざまな Pod に分散します。CICは、Citrix ADC MPXまたはVPXのルータープラグインとしてインストールされ、クラスタの外部に展開されます。
Citrix コンポーネント:
- VPX-DNS にクラスターサービスを提示する入力ADC。
- CIC-CNCルートを介して外部Citrix ADCにROUTE_LABELSとNAMESPACE_LABELSを提供します。
ルートシャードのサンプル YAML ファイルパラメーター:
Citrix Openshift のソースファイルはこのGithubにあります
-
次の環境変数 ROUTE_LABELS と NAMESPACE_LABELS を、kubernetes ラベル形式の値で追加します。CIC のルートシャーディング式、NAMESPACE_LABELS はオプションのフィールドです。使用する場合は、route.yaml ファイルに記載されている名前空間のラベルと一致する必要があります。
env: - name: "ROUTE_LABELS" value: "name=apache-web" - name: "NAMESPACE_LABELS" value: "app=hellogalaxy" -
route.yaml を介して作成されたルートには、CIC のルートシャーディング式と一致するラベルが設定されます。
metadata: name: apache-route namespace: hellogalaxy labels: name: apache-web -
service.yaml でサービスを公開します。
metadata: name: apache-service spec: type: NodePort #type=LoadBalancer ports: - port: 80 targetPort: 80 selector: app: apache -
service.yaml のセレクターラベルと一致する単純な Web アプリケーションをデプロイします。
デプロイ例 #2: Citrix ADC CPX は OpenShift ルーターとしてデプロイされました
Citrix ADC CPXは、クラスター内のCitrix Ingress Controllerとともに、OpenShift ルーターとして展開できます。CPXまたはCICをルーターとしてクラスターにデプロイするその他の手順については、「 Citrix ADCでOpenShiftルーティングシャーディングサポートを有効にする」を参照してください。
Citrix コンポーネント:
- VPX-DNS にクラスターサービスを提示する入力ADC。
- CIC-ルートシャードを定義するために、ROUTE_LABELS と NAMESPACE_LABELS を外部の Citrix ADC に提供します。
- CNC-シャードの自動ルーティング構成を外部ロードバランサーに提供します。
- CPX-Openshift クラスター内で Openshift ルーティングを提供します。
Ingress Class アノテーションを使用したサービス移行
イングレスクラスアノテーションはイングレスクラスアノテーションの概念を使用し、イングレスクラス情報を含むアノテーションをイングレスに追加します。これは、トラフィックを外部ADCから特定のポッド/ノードにリダイレクトするのに役立ちます。
Ingress クラスのサンプル YAML ファイルパラメーター:**
Citrix Ingress のソースファイルはこのGithubにあります
env:
args:
- --ingress-classes
vpx
イングレス設定ファイルには、作成時に CIC イングレスクラスの args フィールドと一致するメタデータ内に kubernetes.io/ingress.class アノテーションフィールドも必要です。
「ingress.classes」の例を使用したIngress VPXデプロイの例**
kind: Ingress
metadata:
name: ingress-vpx
annotations:
kubernetes.io/ingress.class: "vpx"
Citrix メトリックスエクスポーター
Citrix ADC メトリックエクスポーターとPrometheusオペレーターを使用して 、Citrix ADC VPX または CPX 入力デバイスと Citrix ADC CPX（east-west）デバイスを監視できます。 PrometheusとGrafanaを使用したCitrix ADCのメトリクスの表示を参照してください。