第2章 Azure への機密コンテナーのデプロイ

ピア Pod がパブリックインターネットなどの外部ネットワークと通信できるようにするには、Pod 仮想マシン (VM) サブネットの送信接続を設定する必要があります。これには、NAT ゲートウェイの設定と、オプションでサブネットを Azure のクラスターの仮想ネットワーク (VNet) と統合する方法の定義が含まれます。

送信接続は次の 2 つの方法で設定できます。

クラスターに十分なリソースがあることを確認する。

ピア Pod 仮想マシン (VM) には、次の 2 つの場所にリソースが必要です。

Kubernetes ワーカーノードで使用される CPU およびメモリーリソースは、ピア Pod の作成に使用される RuntimeClass (kata-remote) 定義に含まれる Pod オーバーヘッド によって処理されます。

クラウド内で実行されているピア Pod VM の合計数は、Kubernetes ノード拡張リソースとして定義されます。この制限はノードごとに設定され、peer-pods-cm config map の PEERPODS_LIMIT_PER_NODE 属性によって設定されます。

拡張リソースの名前は kata.peerpods.io/vm で、Kubernetes スケジューラーが容量の追跡とアカウンティングを処理できるようにします。

OpenShift sandboxed containers Operator のインストール後に、環境の要件に基づいてノードごとの制限を編集できます。

mutating Webhook により、拡張リソース kata.peerpods.io/vm が Pod 仕様に追加されます。また、リソース固有のエントリーが存在する場合は、Pod 仕様から削除されます。こうすることで、Kubernetes スケジューラーがこれらの拡張リソースを考慮できるようになり、リソースが利用可能な場合にのみピア Pod がスケジュールされるようになります。

mutating Webhook は、次のように Kubernetes Pod を変更します。

initdata 仕様は、実行時に機密データまたはワークロード固有のデータを使用してピア Pod を初期化する柔軟な方法を提供し、そのようなデータを仮想マシン (VM) イメージに埋め込む必要性を回避します。このアプローチにより、機密情報の漏洩が減り、セキュリティーが強化され、カスタムイメージビルドがなくなることで柔軟性が向上します。たとえば、initdata には次の 3 つの設定を含めることができます。

initdata コンテンツは次のコンポーネントを設定します。

initdata.toml ファイルを作成し、それを gzip 形式の Base64 エンコード文字列に変換します。この initdata の文字列を、次のいずれかの方法でワークロードに適用します。

次に、initdata ファイルからハッシュを作成します。このハッシュは、Red Hat build of Trustee の Reference Value Provider Service (RVPS) config map の参照値として必要です。