すべてのプロダクト
Search
ドキュメントセンター

Container Service for Kubernetes:サンドボックスコンテナの利点

最終更新日:Nov 14, 2024

このトピックでは、Sandboxed-Containerの利点と使用シナリオについて説明します。 このトピックでは、Container Service for Kubernetes (ACK) のSandboxed-ContainerをオープンソースのKata Containersと比較します。 これは、サンドボックスコンテナの利点を理解するのに役立ちます。

背景情報

Sandboxed-Containerは、Dockerランタイム環境に代わるものです。 Sandboxed-Containerは次の機能をサポートします。

  • Sandboxed-Containerを使用すると、アプリケーションをサンドボックス化された軽量の仮想マシンで実行できます。 この仮想マシンには専用のカーネルが装備されており、より優れた分離と強化されたセキュリティを提供します。

  • Sandboxed-Containerは、オープンソースのKata Containersと比較して、ストレージ、ネットワーク、および安定性の点で最適化されています。

  • Sandboxed-Containerを使用して、信頼できないアプリケーションと異なるテナントのアプリケーションを分離し、セキュリティを強化できます。 Sandboxed-Containerを使用して、障害のあるアプリケーションとパフォーマンスが低下したアプリケーションを分離することもできます。 これにより、サービスへの悪影響が最小限に抑えられます。 さらに、Sandboxed-Containerは、ロギング、モニタリング、およびエラスティックスケーリングの点でDockerと同じユーザーエクスペリエンスを提供します。

メリット

Dockerと比較して、Sandboxed-Containerには次の利点があります。

  • サンドボックス化された軽量の仮想マシンに基づく強力な分離。

  • Apsara File Storage NAS (NAS) ファイルシステムとディスクをサンドボックスコンテナにマウントできます。 これにより、ホストにマウントされるストレージボリュームと同じストレージパフォーマンスが提供されます。

  • アプリケーション管理の面でのrunCとの互換性。

  • runCの90% までの高性能。

  • ログ、モニタリング、およびストレージの点でrunCと同じユーザーエクスペリエンス。

  • RuntimeClassをサポートします。

  • 仮想マシンを使用するための技術的な専門知識とスキルに対する要件が少なくなります。

  • カタの容器より高い安定性。

サンドボックスコンテナとカタコンテナの比較

サンドボックス-コンテナはカタコンテナよりも優れています。 サンドボックスコンテナとカタコンテナの違いを次の表に示します。

項目

カテゴリ

サンドボックス-コンテナV2

カタコンテナ

サンドボックスの開始にかかる時間

150 msについて

500 msについて

サンドボックスの追加オーバーヘッド

低い

高い

ルートファイルシステム

virtio-fs。 パフォーマンス: ☆ ☆ ☆ ☆

9pfs。 パフォーマンス: ☆

ボリューム

HostPath/EmptyDir

virtio-fs。 パフォーマンス: ☆ ☆ ☆ ☆

ブロックストレージ付きディスク

virtio-fs。 パフォーマンス: ☆ ☆ ☆ ☆

NAS

  • virtio-fs (デフォルト) 。 パフォーマンス: ☆ ☆ ☆ ☆

  • 特定のコンテナ環境変数を設定すると、ディスクはSandboxed-Containerにマウントされます。 パフォーマンス: ☆ ☆ ☆ ☆ ☆

Object Storage Service (OSS)

virtio-fs。 パフォーマンス: ☆ ☆ ☆ ☆

ネットワークプラグイン

  • Terwayネットワークプラグインが使用されます。 そのネットワークパフォーマンスはFlannelよりも高い30% が20% です。 TerwayはNetworkPolicyなどの機能をサポートしています。 これにより、ネットワークポリシーを定義し、ポッドの帯域幅調整を有効にできます。 詳細については、「ネットワークの概要」をご参照ください。

  • 仮想プライベートクラウド (VPC) ルートをサポートするFlannel。

Flannel

モニタリングとアラート

  • Sandboxed-Containerを使用するポッドのディスクとネットワーク状態の監視を強化しました。

  • CloudMonitorと統合。 これにより、クラスタの監視とアラートが容易になります。

Sandboxed-Containerを使用するポッドでは、ディスクとネットワークの状態を監視できません。

安定性

☆☆☆☆☆

☆☆

Sandboxed-Containerの使用シナリオ

このセクションでは、Sandboxed-Containerの使用シナリオについて説明します。

image
  • シナリオ1: サンドボックス-コンテナは、分離されたコンテナで信頼できないコードとアプリケーションを実行できます。 これはrunCのコンテナーではサポートされません。

    • runCのセキュリティリスク

      image
      • runCは、名前空間とコントロールグループ (cgroups) を使用してコンテナーを分離します。 これにより、コンテナはセキュリティリスクにさらされます。

      • ノード上のすべてのコンテナはホストカーネルを共有します。 カーネルに脆弱性がある場合、悪意のあるコードがホストに逃げ、バックエンドネットワークに侵入する可能性があります。 不正なコードの実行は、特権のエスカレーション、機密データの侵害、システムサービスやその他のアプリケーションの破壊を引き起こす可能性があります。

      • 攻撃者は、アプリケーションの脆弱性を悪用して内部ネットワークに侵入する可能性もあります。

      次の対策を実装して、runCのコンテナーのセキュリティリスクを軽減できます。

      • Seccomp: システムコールをフィルタリングします。

      • SElinux: コンテナープロセス、ファイル、およびユーザーの権限を制限します。

      • 機能: コンテナプロセスの機能を制限します。

      • Rootlessモード: ユーザーがコンテナーランタイムとコンテナーをルートロールとして実行できないようにします。

      上記の対策により、runCのコンテナのセキュリティを強化し、悪意のあるコンテナを使用してホストカーネルへの攻撃を軽減できます。 ただし、コンテナーエスケープとホストカーネルの脆弱性は未解決のままです。

    • サンドボックス-コンテナはコンテナの分離に基づいて潜在的なリスクを防ぎます

      image

      Sandboxed-Containerランタイム環境では、潜在的なセキュリティリスクを持つアプリケーションが、サンドボックス化された軽量の仮想マシンにデプロイされます。 各仮想マシンは、専用のゲストOSカーネルを有する。 ゲストOSカーネルでセキュリティの脆弱性が検出された場合、攻撃は1つのサンドボックスに限定され、ホストカーネルや他のコンテナーには影響しません。 Terwayネットワークプラグインを使用すると、ポッドのネットワークポリシーを定義できます。 これにより、サンドボックスコンテナのシステム分離、データ分離、およびネットワーク分離が可能になります。

  • シナリオ2: サンドボックス-コンテナは、障害の拡散、リソースの競合、パフォーマンスの干渉など、runCコンテナの一般的な問題を解決します。故障隔离

    Kubernetesを使用すると、単一のノードにさまざまなコンテナを簡単にデプロイできます。 ただし、cgroupsはリソースの競合に対処するために最適化されません。 CPU集中型アプリケーションおよびI/O集中型アプリケーションなどのリソース集中型アプリケーションは、同じリソースを求めて競合する可能性があります。 これは、応答時間の著しい変動を引き起こし、全体の応答時間を増加させる。 アプリケーションの例外または障害がホストノードに広がり、クラスターの実行が中断される可能性があります。 たとえば、アプリケーションのメモリリークや頻繁なコアダンプがノードに過負荷をかける可能性があり、コンテナ上の例外がホストカーネルのバグを引き起こし、システム全体の障害を引き起こす可能性があります。 Sandboxed-Containerは、専用のゲストOSカーネルとハイパーバイザーを使用して、runCコンテナーに共通する問題を解決します。 問題には、障害の拡散、リソースの競合、およびパフォーマンスの干渉が含まれます。

  • シナリオ3: Sandboxed-Containerはマルチテナントサービスをサポートしています。

    複数のビジネスラインまたは部門で構成される企業のアプリケーションを分離する必要がある場合があります。 例えば、財務部門は、高セキュリティアプリケーションを必要とする。 しかしながら、他のセキュリティに敏感でないアプリケーションは、高いセキュリティ要件を有していない。 runCのコンテナは、信頼できないアプリケーションで発生する潜在的なリスクを排除できません。 このシナリオでは、次の対策を実装できます。

    • 複数の独立した単一テナントクラスターをデプロイします。 たとえば、金融ビジネスとその他のセキュリティに依存しないビジネスを異なるクラスターにデプロイします。

    • マルチテナントクラスターをデプロイし、名前空間を使用して異なる業務ラインのアプリケーションを分離します。 ノードのリソースは、単一のビジネスライン専用です。 このソリューションでは、リソースのクォータとネットワークポリシーを調整して、マルチテナント分離を実装するためのデータ分離を提供します。 複数のシングルテナントクラスターと比較して、このソリューションはより少ない管理プレーンに重点を置いているため、管理コストが削減されます。 ただし、このソリューションでは、一部のテナントのリソース使用率が低いことによるノードのリソースの浪費を防ぐことはできません。

      image

    Sandboxed-Containerを使用すると、サンドボックス仮想マシンを使用して信頼できないアプリケーションを分離できます。 これにより、コンテナが逃げるリスクが防止される。 これにより、各ノードに異なるコンテナ化されたアプリケーションをデプロイすることもできます。

    • リソーススケジューリングが簡略化される。

    • ノードはもはやサービス専用ではありません。 これにより、ノードリソース使用量が改善され、リソースフラグメントとクラスターリソースコストが削減されます。

    • サンドボックスコンテナは、軽量の仮想マシンを使用して、runCのコンテナとほぼ同じパフォーマンスを提供します。

    image