アーキテクチャ

この共有インフラストラクチャのため、CNIはホストクラスターに設定されたものと同じです。利用可能なストレージについても同様で、ストレージクラスとボリュームはホストクラスターのものです。

必要な分離を提供するために、K3kはネットワークポリシーを活用します。

*共有*モードでは、K3kはKubernetesの「ResourceQuotas」と「LimitRanges」を活用してリソースの共有を管理し、制限を強制します。すべての仮想クラスターのワークロードがホストクラスターの同じ名前空間内で実行されるため、ResourceQuotasはこの名前空間に適用され、仮想クラスターによって消費される総リソースを制限します。LimitRangesは、ポッドのデフォルトのリソース要求と制限を設定するために使用され、ワークロードが明示的に指定しなくても合理的なリソース割り当てを持つことを保証します。

仮想クラスター内の各ポッドには、ポッド名、名前空間、クラスター名を組み合わせた一意の名前が割り当てられます。これにより、共有ホストクラスターの名前空間内での名前の衝突が防止されます。

ResourceQuotasは名前空間レベルで適用されることを理解することが重要です。これは、仮想クラスター内のすべてのポッドが同じクォータを共有することを意味します。これは仮想クラスター全体の制限を提供しますが、リソースの割り当てが動的であることも意味します。1つのワークロードがそのリソース割り当てを完全に使用していない場合、_同じ_仮想クラスター内の他のワークロードは、異なるデプロイメントやサービスに属していても、そのリソースを利用できます。

この動的な共有は、利点でもあり、課題でもあります。効率的なリソース利用を可能にしますが、ワークロードのリソース要求が異なる場合、予測不可能なパフォーマンスにつながる可能性もあります。さらに、このアプローチは、同じ仮想クラスター内のワークロード間で厳密なリソースの隔離を保証することを難しくします。

共有モードの仮想クラスター間の隔離は、Kubernetesネットワークポリシーに大きく依存しています。ネットワークポリシーは、ポッドへのおよびポッドからのネットワークトラフィックを制御するルールを定義します。K3kはネットワークポリシーを構成し、1つの仮想クラスター内のポッドが他の仮想クラスターのポッドやホストクラスター自体のポッドと通信できないようにし、ネットワーク隔離の強固な基盤を提供します。

ネットワークポリシーは堅牢な隔離機能を提供しますが、その特性を理解することが重要です：

K3kはまた、Kubernetesポッドセキュリティアドミッション（PSA）を利用して、ポッドセキュリティ基準（PSS）に基づいて仮想クラスター内のセキュリティポリシーを強制します。PSSはポッドのために異なるセキュリティレベルを定義し、ポッドが実行できるアクションを制限します。PSAを構成して特定のPSSレベル（例えば、baseline`または`restricted）を仮想クラスターに適用することで、K3kはポッドが確立されたセキュリティのベストプラクティスに従うことを保証し、特権機能を使用したり、潜在的に危険な操作を実行したりすることを防ぎます。

PSA統合の重要な側面には以下が含まれます：

共有モードアーキテクチャはセキュリティを考慮して設計されています。K3kは、ネットワークポリシーやPSAを含む複数のセキュリティ制御層を採用し、仮想クラスターとホストクラスターを保護します。共有ネームスペースモデルは慎重な構成と管理を必要としますが、これらの制御はマルチテナント環境でのワークロード実行のための堅牢なセキュリティ基盤を提供します。K3kは、進化する脅威に対処し、ユーザーに対して最高レベルの保護を確保するために、セキュリティメカニズムを継続的に評価し、強化しています。

`virtual`モードの仮想クラスターはそれぞれ独自のネットワーキング設定を持ち、それぞれのK3sサーバーによって管理されています。各仮想クラスターは独自のCNIプラグインを実行し、それがK3sサーバー内で構成されており、他の仮想クラスターおよびホストクラスターから完全にネットワーク分離を提供します。仮想クラスターネットワークは最終的にホストクラスターのネットワークインフラストラクチャの上で動作しますが、ネットワーキングの設定とトラフィック管理は完全に分離されています。

`virtual`モードでのリソース共有は、仮想クラスターを構成するポッド（K3sサーバーポッドとK3sエージェントポッドの両方）にリソース制限を適用することによって管理されます。各ポッドには、特定のCPU、メモリ、およびその他のリソースが割り当てられます。仮想クラスター内で_within_実行されるワークロードは、これらの割り当てられたリソースを利用します。これは、仮想クラスター全体がその構成ポッドの制限によって決定される定義されたリソースプールを持つことを意味します。

このアプローチは、各仮想クラスターに利用可能なリソースを制御する明確で直接的な方法を提供します。ただし、各仮想クラスターがそのワークロードに対して十分な容量を持つことを確保するために、慎重なリソース計画が必要です。

`virtual`モードは、各仮想クラスターのために展開された専用のK3sクラスターにより、強力な分離を提供します。各仮想クラスターが独自の制御プレーンとワーカーノードを実行するため、ワークロードは互いに、またホストクラスターから効果的に分離されています。このアーキテクチャは、1つの仮想クラスターが他の仮想クラスターやホストクラスターに影響を与えるリスクを最小限に抑えます。

`virtual`モードのセキュリティは、別々のK3sクラスターによって提供される固有の分離の恩恵を受けます。ただし、標準的なKubernetesのセキュリティベストプラクティスは依然として適用され、K3kは階層化されたセキュリティアプローチを強調しています。K3sサーバーポッドは、システムリソースへのアクセスを必要とする機能の性質上、しばしば特権を持って実行されますが、K3kは可能な限りこれらの特権を最小限に抑え、最小特権の原則に従うことを推奨しています。これは、完全な`privileged`モードに依存するのではなく、必要な機能を慎重に構成することによって達成できます。K3sのセキュリティベストプラクティスに関する詳細情報は、公式のK3sドキュメントにあります： https://docs.k3s.io/security（このリンクは、機能やその他の関連トピックに関する議論を含む一般的なセキュリティガイダンスを提供します）。

現在、仮想モードのセキュリティには、サーバーポッドがその機能の性質上、システムリソースへのアクセスを必要とするため、特権昇格のリスクがあります。