高度な概念

Red Hat OpenShift 3.11 検証済みリファレンスデザイン用のCitrix Cloudネイティブネットワーキング

Citrix ADC Stackはアプリケーション可用性機能(ADC)、セキュリティ機能の分離(WAF)、アジャイルアプリケーショントポロジ(SSLとGSLB)のスケーリング、および積極的な観察性(サービスグラフ)の高度に調整されたCloud Native Era環境での基本的な要件を満たします。

デジタルトランスフォーメーションにより、最新のアプリケーション展開をマイクロサービスベースのアーキテクチャに移行する必要性が高まっています。これらのクラウドネイティブアーキテクチャは、アプリケーションコンテナ、マイクロサービス、Kubernetes を活用します。

最新のアプリケーションに対するクラウドネイティブのアプローチは、アジャイルなワークフロー、自動展開ツールセット、開発言語とプラットフォームなどの開発ライフサイクルも変革しました。

最新アプリケーション展開の新時代により、月次および年次ソフトウェアのリリースと契約、サイロコンピューティングリソースと予算、ベンダー消費モデルなど、従来のデータセンターのビジネスモデルの分野も変わりつつあります。

そして、このような近代化はすべてエコシステムで行われていますが、アプリケーション可用性機能(ADC)、セキュリティ機能の分離(WAF)、アジャイルアプリケーショントポロジ(SSLとGSLB)のスケーリング、および積極的な観察性(サービスグラフ)の高度に調整された環境で使用します。

最新のアプリケーション配信に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/秒から100 Gb/秒までのパフォーマンスを提供します。
    • MPX — Citrix ADC MPXは、500Mb/秒から200 Gb/秒までのパフォーマンスを提供するハードウェアベースのアプリケーションデリバリアプライアンスです。
    • SDX — Citrix ADC SDXアプライアンスは、複数の仮想Citrix ADCマシン(インスタンス)をプロビジョニングおよび管理できるマルチテナントプラットフォームです。
    • BLX — Citrix ADC BLX アプライアンスは、Citrix ADC のソフトウェアフォームファクタです。市販の市販サーバ(COTS)上のベアメタルLinux上でネイティブに動作するように設計されています。 コンテナー化された環境-オーバーレイを作成し、Kubernetes Ingressを中心に構築されたCitrix ADCを自動的に構成し、
    • Citrix Ingress Controller入力リソースの構成
    • Citrix Node Controller-Kubernetesノードと入力Citrix ADC の間にVXLANベースのオーバーレイネットワークを作成する
    • Citrix IPAM Controller-Citrix ADC 上の負荷分散仮想サーバーをIPアドレス(仮想IPアドレスまたはVIP)で自動的に割り当てます。 プール容量ライセンス — 1つのグローバルライセンス
    • ユビキタスグローバルライセンスプールプラットフォームとライセンスを分離し、設計とパフォーマンスの完全な柔軟性を実現 Application Delivery Manger(一元管理機能
    • フリートの管理、ポリシーとアプリケーションの調整、リアルタイムの 柔軟なトポロジーでの監視とトラブルシューティング-従来のデータセンターまたはモダンクラウド
    • 単一層、2 層、サービスメッシュライト

Citrix ADC ADCの価値

  • KubernetesとCNCFオープンソースツールの統合
  • Perfect Proxy — 最新アプリケーション向けの定評のあるLayer7アプリケーションデリバリController
    • ポッドまたはサイドカー展開での高性能ADCコンテナ
    • 複数のオプションを使用した Kubernetes クラスターへの低遅延アクセス
  • 豊富な機能を備えた API — セキュリティ機能を制限なく簡単に実装およびオーケストレーション
  • CI/CD 用の高度なトラフィックステアリングとカナリア展開
  • TLS/SSL、WAF、DoS、API 保護による実証済みのセキュリティ
  • 豊富なレイヤー7機能
  • レガシーおよびモダンアプリケーション展開の統合監視
  • 可視化のための実用的なインサイトとサービスグラフ

Citrix ADC ADCのメリット

  • レガシーアプリケーションを書き直さずに移動
  • 開発者は、Kubernetes API を使用して Citrix ADC ポリシーでアプリケーションを保護できます (CRD を使用 — 開発者向け)。
  • North-Southおよびサービスメッシュ向けの高性能マイクロサービスの展開
  • すべてのマイクロサービスに 1 つのアプリケーションサービスグラフを使用
  • TCP、UDP、HTTP/S、SSL でのマイクロサービスの問題のトラブルシューティングを高速化
  • API を保護し、Kubernetes API を使用して設定する
  • カナリア展開でのCICDプロセスの強化

アーキテクチャコンポーネント

クラウドネイティブアプリケーション向けCitrix ソリューションポートフォリオ

Citrix ADC ADCスイートの利点

Citrix は選択肢です。 従来のデータセンターやコンポーネントを使用する場合でも、新しいクラウドネイティブの最新アプリケーションを立ち上げた場合でも、Citrix ADCは、あらゆるプラットフォーム要件にシームレスに統合します。サブスクリプションベースのクラウドプラットフォームとツール用のクラウドネイティブADC機能を提供し、簡単なIngressController オーケストレーションでオンプレミスKubernetesクラスターへのトラフィックの転送とオーケストレーションを可能にし、サービスメッシュアーキテクチャをシンプルから複雑なものまで対応します。

Citrix は検証済みです。 検証済みの設計テンプレートとサンプルアプリケーションにより、望ましい状態とビジネス要件を簡単に参照でき、迅速かつ完全に対処できます。DevOps、SecOps、プラットフォームの各チームで参照しやすいように、設定例を文書化して一元的に公開しています。

Citrix はアジャイルでモダンです。 既存のADCと新しいモジュール(CNC、IPAMなど)を使用して、Citrix Cloudネイティブスタックの新機能を利用するための基盤アーキテクチャを作成します。

Citrix はオープンです。 パートナーエコシステムとの統合についてお客様が理解できるよう支援します。このドキュメントでは、オープンソースのCNCFツールとCitrix エンタープライズグレード製品の両方を使用しています.

パートナーエコシステム

このトピックでは、さまざまなKubernetesプラットフォーム、展開トポロジ、機能、およびCitrix ADCおよびCitrix Ingress Controllerを含むクラウドネイティブ展開でサポートされるCNIについて詳しく説明します。

Citrix Ingress Controllerは、次のプラットフォームでサポートされています

  • Kubernetes v1.10 をベアメタルで使用するか、AWS、GCP、Azure などのパブリッククラウドでセルフホストします。
  • Google Kubernetes Engine (GKE)
  • Elastic Kubernetes Service (EKS)
  • Azure Kubernetes Service (AKS)
  • Red Hat OpenShift version 3.11以降
  • Pivotal Container Service (PKS)
  • Diamanti Enterprise Kubernetes Platform

パートナーエコシステムには、次のものも含まれています。

  • Prometheus — 指標、アラート、洞察のための監視ツール
  • Grafana — 分析とモニタリングのためのプラットフォーム
  • Spinnaker — マルチクラウドの継続的デリバリーとカナリア分析のためのツール
  • Elasticsearch — アプリケーションまたはサイト検索サービス
  • Kibana — 弾性検索データと弾性スタックナビゲーションツールのための視覚化ツール
  • Fluentd — データ収集ツール

次のセクションでは、OpenShift を使用した設計/アーキテクチャを中心に説明します。

OpenShiftの概要

Red Hat OpenShift は Kubernetes プラットフォームで、マイクロサービスとコンテナーを使用してアプリケーションをより迅速に構築およびスケーリングすることに重点を置いています。OpenShift は、コンテナースタックの自動化、インストール、アップグレード、管理によって Kubernetes を合理化し、日々の DevOps タスクを容易にします。

  • 開発者は、合理化されたワークフローを介して本番稼働にプッシュされる検証済みのソリューションおよびパートナーへのアクセスをアプリケーションにプロビジョニングします。
  • 運用では、Web Consoleと組み込みのログと監視を使用して、環境を管理および拡張できます。

図1-6:OpenShift の高レベルアーキテクチャ

OpenShift の利点とコンポーネントには、次のようなものがあります。

  • インフラストラクチャの選択
  • マスターノードとワーカーノード
  • イメージレジストリ
  • ルーティングとサービスレイヤ
  • 開発者の操作(導入されていますが、このドキュメントの範囲を超えています)

Red Hat OpenShift と Citrix ネイティブスタックを統合するユースケースには、次のようなものがあります。

  • レガシーアプリケーションのサポート
  • API として展開されたリライト/レスポンダーポリシー
  • マイクロサービスのトラブルシューティング
  • セキュリティパッチと機能強化による日常的な運用

この文書では、Citrix ADCがルーティング/サービス層の堅牢な統合を提供する方法をカバーしています。

OpenShiftプロジェクト

OpenShift で追加された最初の新しい概念は project です。プロジェクトによって制御される名前空間へのアクセスを持つ名前空間を効果的にラップします。アクセスは、ユーザーおよびグループに基づく認証および認可モデルによって制御されます。したがって、OpenShift のプロジェクトは、名前空間間の壁を提供し、ユーザーまたはアプリケーションは、許可されているもののみを表示およびアクセスできるようにします。

OpenShift名前空間

Kubernetes のグループ化の主要な概念は名前空間です。名前空間は、クラスターリソースを複数の用途に分割する方法でもあります。つまり、Kubernetesの名前空間の間にセキュリティはありません。Kubernetes クラスター内の「ユーザー」であれば、すべての異なる名前空間とそれらで定義されているリソースを見ることができます。

「tier-2-adc」という名前の名前空間を作成するYAMLファイルの例。

OpenShift Software Defined Networking (SDN)

OpenShift Container Platform は、ソフトウェア定義ネットワーキング (SDN) アプローチを使用して、OpenShift Container Platform クラスター全体でポッド間の通信を可能にする統合クラスターネットワークを提供します。このポッドネットワークは OpenShift SDN によって確立され、管理されます。OpenShift SDN は Open vSwitch (OVS) を使用してオーバーレイネットワークを設定します。

OpenShift SDN には、ポッドネットワークを設定するための 3 つの SDN プラグインが用意されています。

  • ovs-subnet プラグインは元のプラグインで、すべての ポッドが他のすべてのポッドおよびサービスと通信できる「フラット」ポッドネットワークを提供します。
  • ovs-multitenant プラグインは、ポッドとサービスのプロジェクトレベルの分離を提供します。各プロジェクトは、プロジェクトに割り当てられた ポッドからトラフィックを識別する一意の仮想ネットワーク ID (VNID) を受け取ります。異なるプロジェクトの ポッドは、異なるプロジェクトの ポッドおよびサービスとの間でパケットを送信したり、ポッドおよびサービスからパケットを受信したりすることはできません。
  • ただし、VNID 0 を受け取るプロジェクトは、他のすべてのポッドとの通信が許可され、その他のすべての ポッドがそれらと通信できるということで、より特権があります。OpenShift Container Platform クラスターでは、デフォルトのプロジェクトには VNID 0 があります。これにより、ロードバランサーなどの特定のサービスがクラスター内の他のすべてのポッドと通信しやすくなり、その逆も同様です。
  • ovs-networkpolicy プラグインを使用すると、プロジェクト管理者は NetworkPolicy オブジェクトを使用して独自の分離ポリシーを設定できます。

OpenShift ルーティングとプラグイン

OpenShift 管理者は、OpenShift クラスター内でルータの展開ができます。これにより、外部クライアントで使用するために開発者が作成したルートが有効になります。OpenShift のルーティングレイヤーはプラガブルで、デフォルトで 2 つの利用可能なルータープラグインが提供され、サポートされています。

OpenShift ルーターは、識別情報をルーターに直接渡すプロトコルに対して、外部ホスト名マッピングとservicesに対する負荷分散を提供します。ルータがどこに送信するかを決定するためにホスト名は必要です。

ルータプラグインは、ホストポート 80 および 443 にバインドできることを前提としています。これは、外部トラフィックがホストにルーティングされ、その後ルータを経由することを許可するためです。また、ルーターは、クラスター内のすべての ポッドにアクセスできるようにネットワーキングが設定されていることを前提としています。

OpenShiftルーターは、OpenShift インストールでservicesあてに送信されるすべての外部トラフィックの入力ポイントです。OpenShift は、次のルータープラグインを提供およびサポートします。

  • HAProxy テンプレートルーターが既定のプラグインです。OpenShift3/ose-haproxy-routerimage を使用して、OpenShift のコンテナ内でテンプレートルータープラグインと共に HAProxy インスタンスを実行します。現在、HTTP (S) トラフィックと SNI 経由の TLS 対応トラフィックをサポートしています。ルーターのコンテナは、プライベートIPでのみリッスンするほとんどのコンテナとは異なり、ホストネットワークインターフェースでリッスンします。ルーターは、ルート名に対する外部要求を、ルートに関連付けられたサービスによって識別される実際のポッドの IP にプロキシします。
  • Citrix Ingress Controller OpenShiftクラスターにルータープラグインとして展開し、環境に展開されたCitrix ADCと統合することができます。Citrix Ingress Controllerを使用すると、OpenShiftクラスターでCitrix ADCの高度な負荷分散機能とトラフィック管理機能を使用できます。「Citrix Ingress Controller ルータープラグインとして OpenShift クラスターに展開する」を参照してください。

OpenShift ルートと入力メソッド

OpenShift クラスターでは、外部クライアントは ポッドが提供するサービスにアクセスする方法が必要です。OpenShift は、クラスターで実行されているサービスと通信するための 2 つのリソースを提供します:ルートおよびIngress

ルート

OpenShift クラスターでは、ルートは指定されたドメイン名上のサービスを公開するか、ドメイン名をサービスに関連付けます。OpenShift ルーターは、ルートで指定されたルールに従って、OpenShift クラスター内のサービスに外部要求をルーティングします。OpenShift ルーターを使用する場合は、外部 DNS を設定して、トラフィックがルーターに着陸していることを確認する必要があります。

Citrix Ingress Controller OpenShiftクラスターにルータープラグインとして展開し、環境に展開されたCitrix ADCと統合することができます。Citrix Ingress Controllerを使用すると、OpenShiftクラスターでCitrix ADCの高度な負荷分散機能とトラフィック管理機能を使用できます。 OpenShift ルートは、セキュアまたは非セキュアにできます。セキュアなルートは、ルートの TLS 終端を指定します。

Citrix Ingress Controller は、以下のOpenShiftルートをサポートしています。

  • セキュリティで保護されていないルート: セキュリティで保護されていないルートの場合、HTTP トラフィックは暗号化されません。
  • エッジ終端:エッジ終端の場合、TLS はルータで終端されます。内部ネットワーク経由でルータからエンドポイントへのトラフィックは暗号化されません。
  • パススルー終了:パススルー終了では、ルータは TLS オフロードに関与せず、暗号化されたトラフィックは宛先に直接送信されます。
  • 再暗号化の終了: 再暗号化の終了時に、ルーターは TLS 接続を終了しますが、エンドポイントへの別の TLS 接続を確立します。

Citrix ADCの使用方法に基づいて、Citrix Ingress ControllerをOpenShift クラスターのルータープラグインとしてデプロイする方法には、クラスター内のCitrix ADC CPXとして、またはクラスター外のCitrix ADC MPX/VPXとしてデプロイする方法があります。

Citrix ADC CPX を OpenShift クラスター内でルーターとして展開する

Citrix IngressController は、同じポッド内のCitrix ADC CPXコンテナーとともにサイドカーとしてデプロイされます。このモードでは、Citrix 入力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クラスター外のルーターとして展開する」を参照してください。

Ingress

KubernetesIngressは、リクエストのホストまたはパスに基づいてリクエストをサービスにルーティングし、多数のサービスを単一のエントリポイントに集中させる方法を提供します。

Citrix Ingress ControllerはKubernetes入力を中心に構築され、入力リソースに基づいて1つまたは複数のCitrix ADCアプライアンスを自動的に構成します。

入力によるルーティングは、次の方法で行うことができます。

  • ホスト名ベースのルーティング
  • パスベースのルーティング
  • ワイルドカードベースのルーティング
  • 完全パス一致
  • 非ホスト名ルーティング
  • デフォルトのバックエンド

例と詳細については、Ingress構成を参照してください。

Citrix Ingress Controller OpenShiftルータープラグインとして展開する

Citrix ADCの使用方法に基づいて、OpenShiftクラスターにルータープラグインとしてCitrix Ingress Controllerを展開する方法は2つあります。

推奨アーキテクチャ

マイクロサービスアーキテクチャを設計する際には、次のアーキテクチャをお客様に推奨します。

  • Citrix Unified Ingress
  • Citrix 2-Tier Ingress
  • Citrix Service Mesh Lite

図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など)によって処理されます。

Citrix ADC VPX/MPXとのUnified Ingress図

さまざまなカテゴリで提供される機能

Unified Ingress アーキテクチャの機能は、3 つのグループに分類されます。

最初のグループの機能は、パフォーマンスを最適化します。

  • 負荷分散
  • 低遅延の接続
  • 高可用性

2 番目のグループの機能は、セキュリティを向上させ、アプリケーション管理を容易にします。

  • レート制限
  • SSL/LSターミネーション
  • HTTP/2 のサポート
  • ヘルスチェック

最後のグループの機能は、マイクロサービスに固有のものです。

  • サービスの中央通信ポイント
  • API Gateway 機能

概要

Unified Ingressモデルの機能には、サービスに対する堅牢な負荷分散、中央通信ポイント、動的サービス検出、低遅延接続、高可用性、レート制限、SSL/TLS 終了、HTTP/2 などが含まれます。

Unified Ingress モデルを使用すると、トラフィックの管理、要求のロードバランシング、バックエンドマイクロサービスアプリケーションの変更への動的応答が容易になります。

次のようなメリットがあります。

  • North-Southのトラフィックフローはスケーラブルで、観察と監視のために可視であり、SpinnakerやCitrix ADMなどのツールによる継続的な配信を提供します。
  • 単一の階層により、ネットワークおよびプラットフォームサービスを管理するインフラストラクチャチームを統合し、ホップを短縮して遅延を短縮
  • Web App Firewall と SSL オフロードを必要としないが、後で追加できる内部アプリケーションに適しています。

次のような欠点があります。

  • kube-proxyではEast-Westセキュリティはありませんが、L4セグメンテーションにCalicoを追加することができます
  • kube-proxyのスケーラビリティが不明です
  • kube-proxyは可視性、制御、ログを提供しないため、East-Westトラフィックの可視性に制限があり、オープンツールの統合と継続的な配信を緩和します。
  • プラットフォームチームはネットワークに精通している必要があります

Citrix 2-Tier Ingress

2-Tier Ingressアーキテクチャモデルは、クラウドネイティブの初心者にとって最適なソリューションです。このモデルでは、Tier 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 ポッドのサイドカーController は、関連付けられた 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-proxyのスケーラビリティが不明です
  • kube-proxy は可視性、制御、ログを与えず、オープンツールの統合と継続的な配信を緩和するため、East-Westトラフィックの可視性に制限があります。

Citrix Service Mesh Lite

Service Mesh Liteは、3 つのモデルの中で最も豊富な機能です。内部的に安全で、高速、効率的で、耐障害性があり、インバウンドおよびコンテナ間のトラフィックにポリシーを適用するために使用できます。

Service Mesh Liteモデルは、次のようないくつかのユースケースに適しています。

  • 医療および金融アプリ — 規制およびユーザー要件では、金融および医療アプリのセキュリティと速度の組み合わせが義務付けられています。財務および評判の価値は数十億ドルにも及んでいます。
  • Eコマースアプリ — ユーザーの信頼はeコマースにとって大きな問題であり、スピードは競争上の重要な差別化要因です。だから、スピードとセキュリティを組み合わせることが重要です。

Citrix Service Mesh Liteモデルの図は、East-WestプロキシのためのTier-1のCitrix ADC VPX/MPXとTier-2のCitrix ADC CPXコンテナを使用しています。

概要

次のようなメリットがあります。

  • ロードバランサー CPX がインバウンドおよびコンテナ間のトラフィックにポリシーを適用し、完全な L7 ポリシーをデプロイする、ネットワークに対するより堅牢なアプローチ
  • North-SouthおよびEast-Westトラフィックに対するより高度な観察性、分析、継続的配信、およびセキュリティ
  • 組み込みCitrix ADCを搭載した各コンテナのカナリア
  • 単一の階層により、ネットワークおよびプラットフォームサービスを管理するインフラストラクチャチームを統合し、ホップを短縮して遅延を短縮

次のような欠点があります。

  • 複雑なモデルの展開
  • プラットフォームチームはネットワークに精通している必要があります

アーキテクチャの選択の概要

Citrix Unified Ingress

  • North-South(NS)アプリケーショントラフィック - 1 つの Citrix ADC が、K8s クラスター外の L4 および L7 NS トラフィック、セキュリティ、外部負荷分散を担当します。

  • East-West(EW) アプリケーショントラフィック - kube-proxy は L4 EW トラフィックを処理します。

  • セキュリティ : ADCは、NSトラフィックの保護とユーザーの認証を担当します。kube-proxyは、L4 EWトラフィックを担当しています。

  • スケーラビリティとパフォーマンス : NSトラフィックは拡張性に優れ、クラスタリングはオプションです。EWトラフィックとkube-proxyのスケーラビリティは不明です。

  • 観測性 : ADCはNSトラフィックに対して優れた観測性を提供しますが、EWトラフィックには観測性はありません。

Citrix 2-Tier Ingress

  • North-South(NS)アプリケーショントラフィック - Tier-1 ADC は、SSL オフロード、Web App Firewall、および L4 NS トラフィックを処理します。モノリスとCNの両方のアプリケーションに使用されます。Tier-2 CPXは、k8および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 Service Mesh Lite

  • North-South(NS)アプリケーショントラフィック - Tier-1 ADC は、SSL オフロード、Web App Firewall、および L4 NS トラフィックを処理します。モノリスとCNの両方のアプリケーションに使用されます。Tier-2 CPXは、k8および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でサンプルの「hello-world」アプリケーションを使用します。OpenShift のデフォルトの名前空間「default」がこの展開に使用されます。

  1. Citrix ADCインスタンスは、手で構築され、NSIP/SNIPを使用して構成されています。ここでXenServer上のCitrix ADCのインストールを見つけることができます。

  2. 次の 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
    
  3. アプリケーションを展開します。 oc apply -f application.yaml

  4. ポッドが実行されていることを確認します。 oc get pods

  5. 次の 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
    
  6. サービスを使ってNodePort経由でアプリケーションを公開します。 oc apply -f service.yaml

  7. サービスが作成されたことを確認します。 oc get service

  8. 次の YAML ファイルの例をOpenShift ディレクトリにコピーし、.yaml という名前を付けます。「ingress.citrix.com/frontend-ip」という注釈を、Citrix ADC の VIP として使用するフリーの 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
    
  9. Ingress YAMLファイルを展開します。 oc apply -f ingress.yaml

  10. 現在、サービスを使用して公開したアプリケーションポッドがあり、Ingressを使用してトラフィックをルーティングできます。Citrix 入力コントローラをインストールします (CIC) 私たちの層にこれらの構成をプッシュします 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: ["\*"]
    
    
    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
    
    
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: cpx
      namespace: default
    
  11. RBAC ファイルを配備します。 oc apply -f rbac.yaml

  12. CIC を展開する前に、YAML ファイルを編集します。仕様の下で、Tier 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
    
  13. CIC を展開します。 oc apply -f cic.yaml

  14. すべてのポッドが実行されていることを確認します。 oc get pods

  15. ローカルマシン上のhostsファイルを編集します。helloworld.comのエントリと、入力YAMLファイルで指定されたCitrix ADC上のVIPを使用します。

  16. ブラウザーで helloworld.com に移動します。 「Hello 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-Tier Ingress

OpenShiftを使用してCitrix 2-Tier Ingress展開を検証するには、Citrix ADC VPX またはMPXでサンプルの「hello-world」アプリケーションを使用します。この展開には、既定の名前空間「tier-2-adc」が使用されます。**注:Pod、サービス、および Ingress をデプロイする場合、名前空間は「-n (名前空間名)」パラメーターを使用して指定する必要があります。

  1. Citrix ADCインスタンスは、手で構築され、NSIP/SNIPを使用して構成されています。XenServer上のCitrix ADCをインストールすることは見つけることができます [ここ. インスタンスがすでに設定されている場合は、ロードバランシングまたはコンテンツスイッチングで、Unified Ingressとして hello-world を展開して ADC にプッシュされた仮想サーバーをすべてクリアします。

  2. 「tier-2-adc」という名前の名前空間を作成します。 oc create namespace tier-2-adc

  3. 次の 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
    
    
  4. 名前空間にアプリケーションを展開します。 oc apply -f application-2t.yaml -n tier-2-adc

  5. ポッドが実行されていることを確認します。 oc get pods

  6. 次の 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
    
    
  7. サービスを使ってNodePort経由でアプリケーションを公開します。 oc apply -f service-2t.yaml -n tier-2-adc

  8. サービスが作成されたことを確認します。 oc get service -n tier-2-adc

  9. 次の 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
    
    
  10. Ingress YAMLファイルを展開します。 oc apply -f ingress-2t.yaml -n tier-2-adc

  11. 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
    
  12. RBAC ファイルを配備します。 oc apply -f rbac-2t.yaml

  13. CPX を作成するには、サービスアカウントに昇格したアクセス許可が必要です。 oc adm policy add-scc-to-user privileged system:serviceaccount:tier-2-adc:cpx

  14. 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
    
    
  15. CPXを展開します。 oc apply -f cpx-2t.yaml -n tier-2-adc

  16. ポッドが実行中で、サービスが作成されたことを確認します。 oc get pods -n tier-2-adc oc get service -n tier-2-adc

  17. VPXからCPXにルーティングする入力を作成します。フロントエンド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
    
  18. 入力を展開します。 oc apply -f ingress-cpx-2t.yaml -n tier-2-adc

  19. CIC を展開する前に、YAML ファイルを編集します。仕様の下で、Tier 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
    
  20. CIC を展開します。 oc apply -f cic-2t.yaml -n tier-2-adc

  21. すべてのポッドが実行されていることを確認します。 oc get pods -n tier-2-adc

  22. ローカルマシン上のhostsファイルを編集します。helloworld.comのエントリと、VPXからCPXにルーティングする入力YAMLファイルで指定されたCitrix ADC VIPを使用します。

  23. ブラウザーで helloworld.com に移動します。 「Hello Kubernetes!」が表示されます。

Citrix Service Mesh Lite

Service Mesh Liteは、組み込みのHAProxy機能の代わりに、CPX(または他のCitrix ADCアプライアンス)を展開することができます。これにより、KubernetesのN/S機能を拡張し、E/Wトラフィックのロードバランシング、ルーティング、および監視機能も提供することができます。 Citrix ADC(MPX、VPX、またはCPX)は、E-Wトラフィックに次のような利点があります。

  • 相互 TLS または SSL オフロード
  • HTTP または HTTPS ヘッダーパラメータに基づいてトラフィックを許可またはブロックするコンテンツベースのルーティング
  • 高度なロードバランシングアルゴリズム(最小接続数、最小応答時間など)。
  • ゴールデンシグナル(エラー、レイテンシー、飽和、トラフィック量)の測定による東西方向のトラフィックの観測性。Citrix ADMのサービスグラフは、マイクロサービスを監視およびデバッグするための監視ソリューションです。
  • この展開シナリオでは、Bookinfo アプリケーションを展開し、デフォルトでどのように機能するかを観察します。次に、デフォルトのKubernetesサービスをリッピングして置き換え、CPXとVPXを使用してE/Wトラフィックをプロキシします。

CPXを使用したCitrix Service Mesh Lite

OpenShiftを使用してCitrix Unified Ingress展開を検証するには、Citrix ADC VPX またはMPXでサンプルの「hello-world」アプリケーションを使用します。OpenShift のデフォルトの名前空間「default」がこの展開に使用されます。

  1. Citrix ADCインスタンスは、手で構築され、NSIP/SNIPを使用して構成されています。ここでXenServer上のCitrix ADCのインストールを見つけることができます。

  2. この展開の名前空間を作成します。この例では、sml が使用されます。 oc create namespace sml

  3. 以下の 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
    ---
  1. sml 名前空間に bookinfo.yaml を展開します。 oc apply -f bookinfo.yaml -n sml

  2. 製品ページサービスにマップされる 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
    

oc apply -f ingress-productpage.yaml -n sml

  1. 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
    

oc apply -f rbac-cic-pp.yaml -n sml

  1. サービスアカウント権限を昇格して、CIC および CPX を展開します。 oc adm policy add-scc-to-user privileged system:serviceaccount:sml:cpx

  2. ingress-productpage.yamlで指定されているフロントエンド IP に bookinfo.com がマッピングされているローカルマシンの hosts ファイルを編集します。

  3. CIC を使用して製品ページをコピーして展開します。ファイルにcic-productpage.yamlという名前を付けます。NS_IPは、Tier-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
    

oc apply -f cic-productpage.yaml -n sml

  1. bookinfo.comに移動し、通常のユーザーをクリックします。製品ページには、その他のマイクロサービスである詳細、レビュー、評価が表示されます。HAProxy は、マイクロサービス(East-West)間のトラフィックをルーティングする責任があります。

  2. 詳細の前にサービスを削除します。Bookinfo Web ページを更新し、製品ページで詳細情報についてマイクロサービスをプルできなかったことに注目してください。 oc delete service details -n sml

  3. 製品ページから詳細へのトラフィックが CPX を通過するように、ヘッドレスサービスをコピーして展開します。このファイルにdetailsheadless.yamlという名前を付けます。

    apiVersion: v1
    kind: Service
    metadata:
      name: details
    spec:
      ports:
      -  port: 9080
        name: http
      selector:
        app: cpx
    

oc apply -f detailsheadless.yaml -n sml

  1. 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
    

oc apply -f detailsservice.yaml -n sml

  1. 詳細サービスを入力とともに公開し、展開します。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
    

oc apply -f detailsingress.yaml -n sml

  1. 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
    

oc apply -f CPXEastWest.yaml -n sml

  1. bookinfo.comを更新し、詳細マイクロサービスから詳細をプルする必要があります。CPXはプロキシEWトラフィックに正常に展開されました。

VPX/MPXを使用したCitrix Service Mesh Lite

  1. 次のコマンドを実行して、EW プロキシとして使用されている CPX を削除します。新しいファイルが展開され、製品ページと詳細マイクロサービス間のEWプロキシとしてVPXを構成します。 oc delete -f detailsheadless.yaml -n sml oc delete -f detailsservice.yaml -n sml oc delete -f detailsingress.yaml -n sml oc delete -f CPXEastWest.yaml -n sml

  2. サービスをコピーして展開し、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"
    

oc apply -f detailstoVPX.yaml -n sml

  1. 詳細マイクロサービスの前に detailsservice.yaml を再展開します。 oc apply -f detailsservice.yaml -n sml

  2. 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
    

oc apply -f detailsVPXingress.yaml

  1. 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 ホストサブネット (Openshift クラスター) スニペットの取得
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

ルート(外部Citrix VPX)スニペットを表示する
10.128.0.0 255.255.254.0 10.x.x.x 静的
10.129.0.0 255.255.254.0 10.x.x.x 静的
10.130.0.0 255.255.254.0 10.x.x.x 静的

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

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

ルートタイプ

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

デプロイの例 #1: OpenShift ルータープラグインとしてデプロイされた CIC

ルートについては、ルートシャーディングの概念を使用します。ここで、CIC はルーターとして機能し、トラフィックをさまざまな Pod にリダイレクトして、さまざまな利用可能な Pod 間で着信トラフィックを分散します。CICは、Citrix ADC MPXまたはVPXのルータープラグインとしてインストールされ、クラスターの外部に展開されます。

Citrix コンポーネント:

  • VPX-DNS にクラスターサービスを提示する入力ADC。
  • CIC-CNCルートを介して外部Citrix ADC にルートラベルと名前空間のラベルを提供します。

ルートシャードの YAML ファイルパラメータの例:

Citrix のOpenshiftソースファイルは、ここGithubにあります

  1. 次の環境変数 ROUTE_LABELS と NAMESPACE_LABELS を kubernetes ラベル形式で追加します。CIC の NAMESPACE_LABELS のルートシャーディング式は、オプションのフィールドです。使用する場合は、route.yaml ファイルに記載されている名前空間ラベルと一致する必要があります。
        env:
         - name: "ROUTE_LABELS"
           value: "name=apache-web"
         - name: "NAMESPACE_LABELS"
           value: "app=hellogalaxy"

  1. route.yaml を介して作成されたルートには、CIC 内のルートシャーディング式と一致するラベルが設定されます。
        metadata:
            name: apache-route
            namespace: hellogalaxy
            labels:
                name: apache-web
  1. service.yamlでサービスを公開します。
        metadata:
            name: apache-service
        spec:
        type: NodePort
        #type=LoadBalancer
        ports:
            - port: 80
        targetPort: 80
        selector:
            app: apache
  1. service.yaml内のセレクタラベルと一致する単純なWebアプリケーションをデプロイします。

デプロイの例 #2: OpenShift ルーターとしてデプロイされた Citrix ADC CPX

Citrix ADC CPXは、クラスター内のCitrix Ingress Controllerとともに、OpenShift ルーターとして展開できます。クラスター内のルーターとして CPX または CIC を展開する手順については、Citrix ADC でOpenShiftルーティングシャーディングサポートを有効にするを参照してください。

Citrix コンポーネント:

  • VPX-DNS にクラスターサービスを提示する入力ADC。
  • CIC-ルートシャードを定義するために、外部Citrix ADC にルートラベルとネームスペースラベルを提供します。
  • CNC-シャードの自動ルート設定を外部ロードバランサーに提供します。
  • CPX-Openshift クラスター内で Openshift ルーティングを提供します。

入力クラスアノテーションを使用したサービス移行

入力クラスアノテーションは、入力クラスアノテーションの概念を使用して、入力クラス情報を持つ入力にアノテーションを追加します。これは、外部ADCから特定のPOD/ノードにトラフィックをリダイレクトするのに役立ちます。

入力クラスの YAML ファイルパラメータの例:**

Citrix Ingressのソースファイルは、ここにあるGithubにあります

    env:
        args:
          - --ingress-classes
            vpx

入力設定ファイルには、メタデータ内に kubernetes.io/ingress.class アノテーションフィールドも必要です。このフィールドは、作成時に CIC 入力クラス args フィールドと照合されます。

「ingress.classes」の例を含む入力VPX展開の例**

        kind: Ingress
            metadata:
                name: ingress-vpx
                annotations:
                    kubernetes.io/ingress.class: "vpx"

Citrix メトリックスエクスポータ

Citrix ADCメトリックスエクスポーターとPrometheus-Operatorを使用して、Citrix ADC VPXまたはCPX入力デバイスおよびCitrix ADC CPX(East-West)デバイスを監視できます。「PrometheusとGrafanaを使用したCitrix ADCのメトリックの表示」を参照してください。