このページで
CN2パイプラインソリューションテストアーキテクチャと設計
概要 クラウドネイティブのContrail® Networking™(CN2)パイプラインのアーキテクチャと設計についてご紹介します。
概要
ソリューション テスト自動化フレームワーク(STAF)は、実際の実稼働シナリオを模倣したソリューションの使用事例を自動化および維持するために開発された共通プラットフォームです。
-
STAF は、ユーザーのペルソナ、アクション、タイミングをきめ細かくシミュレーションして制御できるため、トラフィックが長時間続く現実のシナリオすべてでソフトウェアが公開されます。
-
顧客が GitOps アーティファクトをプラグインし、カスタム テスト ワークフローを作成できるように、STAF アーキテクチャを拡張できます。
-
STAF は Python および Pytest テスト フレームワークに実装されています。
導入事例
STAFは、お客様の環境でDay 0、Day 1、Day 1、Day-to-Dayの運用をエミュレートします。ユースケーステストは、ユーザーごとに一連のテストワークフローとして実行されます。各ユーザーペルソナには、独自の運用範囲があります。
-
オペレータ—クラスタの設定やメンテナンス、CN2の導入など、グローバルな運用を実行します。
-
アーキテクト -オンボーディング、破棄などのテナント関連の運用を実行します。
-
サイト信頼性エンジニアリング(SRE)—単一テナントのスコープ内でのみ運用を実行します。
現在、STAF は IT クラウド Web サービスと Telco の使用事例をサポートしています。
テスト ワークフロー
各テナントのワークフローは、順番にのみ実行されます。複数のテナントのワークフローを並列で実行し、オペレーターテストを除外できます。
Day 0の運用またはCN2の導入は、現在、テストの実行とは独立しています。残りのワークフローは、ソリューションサニティーテストとして実行されます。Pytest では、各ワークフローはテスト スイートで表されます。
テストの説明については、 CN2パイプラインテストケースの説明を参照してください。
プロファイル
プロファイル ワークフローは、プロファイル YAML ファイルで記述されたユース ケース インスタンスに対して実行されます。プロファイル YAML では、名前空間、アプリケーション レイヤー、ネットワーク ポリシー、サービス タイプなどのパラメーターについて説明します。
プロファイル ファイルはテスト コンテナの外部にマウントされるため、拡張性パラメータを自由に選択できます。CN2パイプラインリリース23.1では、ポッドの総数のみを更新できます。
ダウンロードしたCN2パイプラインタールファイルから、フォルダ内の チャート/ワークフローオブジェクト/テンプレートから完全なプロファイルセットにアクセスできます。
プロファイル例
以下のセクションには、プロファイルの例があります。
- 隔離されたロードバランスプロファイル
- 分離された NodePort プロファイル
- マルチネームスペースコンターイングレスロードバランスプロファイル
- 複数の名前空間から分離されたロードバランスプロファイル
- 非絶縁ngginxイングレスロードバランスプロファイル
隔離されたロードバランスプロファイル
分離されたLoadBalancerProfile.yml は、次のように 3 層 Web サービス プロファイルを構成します。
-
フロントエンドポッドは、レプリカ数が2(2)の場合に導入されます。これらのフロントエンド ポッドは、LoadBalancer サービスを介してクラスターの外部からアクセスされます。
-
ミドルウェアポッドは、レプリカ数が2で展開され、許可されたアドレスペアが両方のポッドに設定されます。これらのポッドは、クラスターIPサービスからフロントエンドポッドからアクセスできます。
-
バックエンドポッドは、レプリカ数が2(2)で展開されます。バックエンドポッドは、ClusterIPサービスを介してミドルウェアポッドからアクセスできます。
-
ポリシーは、各階層で構成されたポート上のトラフィックを許可するように作成されます。
分離されたロードバランスRProfile.yml
isl-lb-profile: WebService: isolated_namespace: True count: 1 frontend: external_network: custom n_pods: 2 services: - service_type: LoadBalancer ports: - service_port: 21 target_port: 21 protocol: TCP middleware: n_pods: 2 aap: active-standby services: - service_type: ClusterIP ports: - service_port: 80 target_port: 80 protocol: TCP backend: n_pods: 2 services: - service_type: ClusterIP ports: - service_port: 3306 target_port: 3306 protocol: UDP
分離された NodePort プロファイル
IsolatedNodePortProfile.yml は、次のように 3 層 Web サービス プロファイルを構成します。
-
フロントエンドポッドは、レプリカ数が2(2)の場合に導入されます。これらのフロントエンドポッドは、haproxyノードポートイングレスサービスを使用して、クラスタの外部からアクセスされます。
-
ミドルウェアポッドは、レプリカ数が2で展開され、許可されたアドレスペアが両方のポッドに設定されます。これらのポッドは、クラスターIPサービスからフロントエンドポッドからアクセスできます。
-
バックエンドポッドは、レプリカ数が2(2)で展開されます。バックエンドポッドは、ClusterIPサービスを介してミドルウェアポッドからアクセスできます。
-
ポリシーは、各階層で構成されたポート上のトラフィックを許可するように作成されます。このプロファイルでは、分離された名前空間が有効になっています。
分離されたNodePortProfile.yml
isl-np-web-profile-w-haproxy-ingress: WebService: count: 1 isolated_namespace: True frontend: n_pods: 2 anti_affinity: true liveness_probe: HTTP ingress: haproxy_nodeport services: - service_type: NodePort ports: - service_port: 443 target_port: 443 protocol: TCP - service_port: 80 target_port: 80 protocol: TCP middleware: n_pods: 2 liveness_probe: command services: - service_type: ClusterIP ports: - service_port: 80 target_port: 80 protocol: TCP backend: n_pods: 2 services: - service_type: ClusterIP ports: - service_port: 3306 target_port: 3306 protocol: UDP
マルチネームスペースコンターイングレスロードバランスプロファイル
MultiNamespaceContourressLB.yml は、次のように 3 層 Web サービス プロファイルを設定します。
-
フロントエンドポッドは、レプリカ数が 2(2)のデプロイを使用して起動されます。これらのフロントエンドポッドは、haproxyノードポートイングレスサービスを使用して、クラスタの外部からアクセスされます。
-
ミドルウェアポッドは、レプリカ数が2で、許可されたアドレスペアが両方のポッドに設定された導入を使用して起動されます。これらのポッドは、クラスターIPサービスからフロントエンドポッドからアクセスできます。
-
バックエンドポッドは、レプリカ数が2(2)で展開されます。バックエンドポッドは、ClusterIPサービスを介してミドルウェアポッドからアクセスできます。
-
ポリシーは、各階層で構成されたポート上のトラフィックを許可するように作成されます。このプロファイルでは、分離された名前空間が有効になっています。
マルチネームスペースContourressLB.yml
multi-ns-contour-ingress-profile: WebService: isolated_namespace: True multiple_namespace: True fabric_forwarding: True count: 1 frontend: n_pods: 2 ingress: contour_loadbalancer services: - service_type: ClusterIP ports: - service_port: 6443 target_port: 6443 protocol: TCP middleware: n_pods: 2 services: - service_type: ClusterIP ports: - service_port: 80 target_port: 80 protocol: TCP backend: n_pods: 2 services: - service_type: ClusterIP ports: - service_port: 3306 target_port: 3306 protocol: UDP
複数の名前空間から分離されたロードバランスプロファイル
MultiNamespaceIsolatedLB.yml プロファイルでは、次のように 3 層 Web サービス プロファイルを構成します。
-
フロントエンドポッドは、レプリカ数が2(2)の場合に導入されます。これらのフロントエンド ポッドは、LoadBalancer サービスを使用してクラスターの外部からアクセスされます。
-
ミドルウェアポッドは、レプリカ数が2で展開され、許可されたアドレスペアが両方のポッドに設定されます。これらのミドルウェアポッドは、クラスターIPサービスからフロントエンドポッドからアクセスできます。
-
バックエンドポッドは、レプリカ数が2(2)で展開されます。バックエンドポッドは、ClusterIPサービスを介してミドルウェアポッドからアクセスできます。
-
ポリシーは、各階層で構成されたポート上のトラフィックを許可するように作成されます。このプロファイルでは、フロントエンド、ミドルウェア、バックエンドのデプロイに対して、複数の名前空間に加えて、分離された名前空間が有効になっています。
マルチネームスペースリゾレイトLB.yml
multi-ns-lb-profile: WebService: isolated_namespace: True multiple_namespace: True count: 1 frontend: n_pods: 2 services: - service_type: LoadBalancer ports: - service_port: 443 target_port: 443 protocol: TCP - service_port: 6443 target_port: 6443 protocol: TCP middleware: n_pods: 2 aap: active-standby services: - service_type: ClusterIP ports: - service_port: 80 target_port: 80 protocol: TCP backend: n_pods: 2 services: - service_type: ClusterIP ports: - service_port: 3306 target_port: 3306 protocol: UDP
非絶縁ngginxイングレスロードバランスプロファイル
非IsolatedNginxIngressLB.ymlプロファイルは、次のように3層のWebサービスプロファイルを設定します。
-
フロントエンドポッドは、レプリカ数が2(2)の場合に導入されます。これらのフロントエンドポッドは、NGINXイングレスロードバランスサービスを使用して、クラスタ外部からアクセスされます。
-
ミドルウェアポッドは、レプリカ数が2(2)の場合に導入され、許可されたアドレスペアが両方のポッドに設定されます。これらのミドルウェアポッドは、クラスターIPサービスからフロントエンドポッドからアクセスできます。
-
バックエンドポッドは、レプリカ数が2(2)で展開されます。バックエンドポッドは、ClusterIPサービスを介してミドルウェアポッドからアクセスできます。
-
ポリシーは、各階層で構成されたポート上のトラフィックを許可するように作成されます。
非分離NginxIngressLB .yml
non-isl-nginx-ingress-lb-profile: WebService: isolated_namespace: False count: 1 frontend: ingress: nginx_loadbalancer n_pods: 2 liveness_probe: HTTP services: - service_type: ClusterIP ports: - service_port: 80 target_port: 80 protocol: TCP middleware: n_pods: 2 services: - service_type: ClusterIP ports: - service_port: 443 target_port: 443 protocol: TCP backend: n_pods: 2 is_deployment: False liveness_probe: command services: - service_type: ClusterIP ports: - service_port: 3306 target_port: 3306 protocol: UDP
テスト環境の構成
テスト環境を構成するには、テスト実行環境を記述するパラメーターを含む YAML ファイルをデプロイします。このトピックでは、Kubernetes と OpenShift テスト環境構成の両方の YAML ファイルの例を示します。
Kubernetes 環境
Kubernetes テスト環境のデプロイと構成に使用される YAML ファイルの例を次に示します。
Kubernetes環境におけるCN2パイプライン
次に、Kubernetes テスト環境を構成するための YAML の例を示します。
k8s_clusters: central: authentication: type: cn2_client_cert kubeconfig_file: /root/.kube/config metadata: kubemanager: contrail-k8s-kubemanager multus: False ingress: haproxy_nodeport: ingress_class_name: haproxy-nodeport namespace: haproxy-controller service_name: haproxy-ingress service_port: 80 nginx_loadbalancer: ingress_class_name: nginx-loadbalancer namespace: ingress-nginx service_name: ingress-nginx-controller service_port: 80 contour_loadbalancer: ingress_class_name: contour namespace: projectcontour service_name: envoy service_port: 80 computes: cn2-test-node-1: username: username_is_here password: password_is_here mgmt_ip: ip_is_here data_ip: ip_is_here cn2-test-node-2: username: username_is_here password: password_is_here mgmt_ip: ip_is_here data_ip: ip_is_here cn2-test-node-3: username: username_is_here password: password_is_here mgmt_ip: ip_is_here data_ip: ip_is_here cn2-test-node-4: username: username_is_here password: password_is_here mgmt_ip: ip_is_here data_ip: ip_is_here cn2-test-node-5: username: username_is_here password: password_is_here mgmt_ip: ip_is_here data_ip: ip_is_here cn2-test-node-6: username: username_is_here password: password_is_here mgmt_ip: ip_is_here data_ip: ip_is_here test_config: deployment: type: k8s traffic_image: enterprise-hub.juniper.net/contrail-container-prod/*** registry: type: authenticated
OpenShift 環境
Red Hat OpenShift テスト環境のデプロイと構成に使用される YAML ファイルの例を次に示します。
OpenShift環境におけるCN2パイプライン
OpenShift テスト環境を構成するための YAML の例を次に示します。
k8s_clusters: central: authentication: type: cn2_client_cert kubeconfig_file: /root/.kube/config metadata: kubemanager: contrail-k8s-kubemanager multus: True ingress: haproxy_nodeport: ingress_class_name: haproxy-nodeport namespace: haproxy-controller service_name: haproxy-ingress service_port: 80 nginx_loadbalancer: ingress_class_name: nginx namespace: nginx-ingress service_name: nginxingress-sample-nginx-ingress service_port: 80 contour_loadbalancer: ingress_class_name: contour namespace: projectcontour service_name: envoy service_port: 80 test_config: deployment: type: openshift traffic_image: enterprise-hub.juniper.net/contrail-container-prod/*** registry: type: authenticated ocp_infra: ocp_api_host: ip: ip_is_here name: api.ocp.domain_is_here ocp_native_apps_host: ip: ip_is_here computes: master1: username: username_is_here password: password_is_here mgmt_ip: ip_is_here data_ip: ip_is_here master2: username: username_is_here password: password_is_here mgmt_ip: ip_is_here data_ip: ip_is_here master3: username: username_is_here password: password_is_here mgmt_ip: ip_is_here data_ip: ip_is_here worker1: username: username_is_here password: password_is_here mgmt_ip: ip_is_here data_ip: ip_is_here worker2: username: username_is_here password: password_is_here mgmt_ip: ip_is_here data_ip: ip_is_here
Kubeconfigファイル
kubeconfigファイルデータは、認証に使用されます。kubeconfig ファイルは、Argo ホストの Kubernetes クラスターにシークレットとして格納されます。
kubeconfigファイルに以下のデータを入力します。
-
サーバー: 秘密鍵は、サーバーの IP アドレスまたはホスト名のいずれかを指す必要があります。
-
Kubernetes のセットアップでは、マスター ノードの IP アドレスであるサーバーを指定します。
https://xx.xx.xx.xx:6443
-
OpenShift セットアップでは、OpenShift コンテナ プラットフォーム API サーバー、拡張機能、およびサーバーをポイントします。
https://api.ocp.xxxx.com:6443
-
-
クライアント証明書:Kubernetesクライアント証明書。
ログ作成とレポート作成
各テスト実行中に、2 種類のログ ファイルが作成されます。
-
Pytest セッション ログ ファイル - セッションごとに 1 つ
-
テスト スイート ログ ファイル - テスト スイートごとに 1 つ
デフォルトのファイル サイズは 50 MB です。ログファイルのローテーションがサポートされています。