第4章 ピア Pod を使用して IBM Z および IBM LinuxONE に機密コンテナーをデプロイする

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

ピア 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 の文字列を、次のいずれかの方法でワークロードに適用します。