|
この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。 |
|
これは未公開の文書です Admission Controller 1.34-dev. |
SUSE Security Admission Controller大規模環境における
このセクションでは、要求の厳しい大規模環境におけるSUSE Security Admission Controllerの実際のデプロイメントについて詳述します。高可用性とパフォーマンスのためにAdmission Controllerを構成する方法と、重負荷時に何を期待するかを示しています。
|
本番環境でAdmission Controllerを運用するためのヒントをもっと見たい場合は、本番デプロイメントのドキュメントをチェックしてください。 |
環境の概要
インフラストラクチャは、約20のKubernetesクラスターで構成されています。これらのクラスターの中で最も大きいものは、サイズとリソース量が大きいことが特徴です:
-
ノード: 約400
-
ネームスペース: 約4,000
-
管理対象リソース:
-
ポッド:10,000
-
ロールバインディング:13,000
-
Ingress:12,000
-
デプロイメント:8,000
-
サービス:13,000
-
Admission Controllerの設定
この環境の要求に応えるために、Admission Controllerはワークロードの分離と高可用性に重点を置いて構成されています。
-
ポリシーの実施:22 `ClusterAdmissionPolicies`がクラスター全体で実施されており、ネームスペース特有の`AdmissionPolicies`はありません。
-
ポリシーサーバーアーキテクチャ:ワークロードを分離するために、2つの別々の`PolicyServer`デプロイメントが使用されています:
-
1つの`PolicyServer`は、コンテキスト対応ポリシー専用に割り当てられています。
-
2つ目の`PolicyServer`は、すべての他の非コンテキスト対応ポリシーを処理します。
-
-
スケーラビリティとリソース:
-
Replicas:各`PolicyServer`デプロイメントは、高いリクエスト量を処理するために15のレプリカを実行します。
-
リソースの割り当て:各レプリカには300MBのメモリと4つのCPUコアが割り当てられています。
-
パフォーマンスメトリック
この構成は、高いアドミッションリクエスト率を管理しながら、予測可能なパフォーマンスを維持します。
-
アドミッションリクエストのスループット:クラスターは、1秒あたり最大300のアドミッションリクエストを処理します(ウェブフックの検証と監査スキャンの両方を含む)。
-
ポリシーのレイテンシ:
-
典型的なレイテンシ:コンテキスト対応ポリシーは、一般的に実行に約500msかかります。
-
タイムアウト:この高スループット環境では、ウェブフックのタイムアウトは2.5秒に設定されており、`PolicyServer`のタイムアウトは10秒に設定されています。ほとんどのリクエストは迅速ですが、インフラストラクチャはAPIサーバーの安定性を損なうことなく、時折の遅い操作を処理できるように構築されています。
-