この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。

これは未公開の文書です 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サーバーの安定性を損なうことなく、時折の遅い操作を処理できるように構築されています。

監査スキャナーのパフォーマンス

監査スキャナーは、膨大なリソースにわたる継続的なコンプライアンスを確保するために利用されます。

  • 頻度:クラスター全体の監査は、4時間ごとに実施されます。

  • 設定:監査ジョブは、ランタイムを短縮するために最大の並列性に調整されています:

--parallel-namespaces: "10"
--parallel-resources: "20"
--parallel-policies: "20"
--page-size: "1000"
  • 監査の所要時間:数万のリソースを持つ最大のクラスターでも、完全な監査ジョブは一定時間内に完了します。