0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kiik5
in

コンポーザブルKubernetes（Composable Kubernetes）とは？

0
Posted at

GPU不足とコスト高を解決！ LIQID CDI × Kubernetesで実現する「コンポーザブルKubernetes」

生成AI（LLM）やデータ分析、機械学習ワークロードの急増に伴い、GPUをはじめとする計算リソースの確保と効率的な運用が企業の大きな課題となっています。

本記事では、近年注目を集めるコンポーザブルKubernetesのコンセプトについて、以下の3つの観点から技術的に分かりやすく解説します。

  1. Kubernetes の利点 ※
  2. LIQID CDI（Composable Disaggregated Infrastructure） の利点
  3. 両者を組み合わせた コンポーザブルKubernetes がもたらす真の価値

※参考資料：Kubernetes公式ドキュメント より主要なメリットを抜粋・再構成しています。

1. Kubernetes の利点

Kubernetesは、コンテナ化されたアプリケーションのデプロイ、スケーリング、および運用管理を自動化するオープンソースのコンテナオーケストレーションプラットフォームです。

主な技術的メリット

  • 宣言的構成とセルフヒーリング（自己修復）
    アプリケーションの「あるべき状態」をYAML等で宣言的に定義することで、Podの作成・スケジューリング・障害発生時の自動再起動や再配置（セルフヒーリング）を自動的に実行。
  • 高いポータビリティと開発運用の効率化
    オンプレミスからマルチクラウド環境、開発環境から本番環境まで、下層の物理インフラ構成を意識することなく、同一の構成情報でシームレスにアプリケーションを運用可能。
  • 柔軟なオートスケーリング
    CPU/メモリ等のリソース使用量に応じてPod数を動的に増減させる水平Pod自動スケーリング（HPA：Horizontal Pod Autoscaler）などを活用し、需要の変化に応じた柔軟なリソース最適化を実現します。

2. LIQID CDI の利点

LIQID CDI（Composable Disaggregated Infrastructure）は、サーバからGPU、ストレージ、NICなどの各種PCIeデバイスを個別のプールとしてPCIe接続された拡張シャーシに集約し、高速PCIeファブリック経由でソフトウェアで動的に接続（Compose）／解放(Disaggregate)する技術です。

主な技術的メリット

  • 物理ハードウェアの動的な接続（Compose）と解放（Disaggregate）
    PCIe Gen5の高速ファブリックを介し、必要な時に必要な数だけのGPUやNVMeストレージを特定のワーカーノード（サーバ）へ即座に接続し、ベアメタルレベルで構成できます。
  • サイロ化の解消とリソース利用率の最大化
    「ノードAではGPUが余っているが、ノードBでは不足している」といった従来の物理的制約を解消します。タスク完了後はGPUをフリープールへ返却（Disaggregate）し、別タスクを実行する他のノードへ再割り当て（Compose）が可能です。
  • LIQID Matrixソフトウェアによる構成変更
    サーバ筐体を開けてPCIeカードを挿し直したり、ケーブルを物理的に繋ぎ替えたりすることなく、WebUIやREST API操作のみで各ノードのGPU枚数やシステム構成を即座に変更できます。

3. コンポーザブルKubernetes がもたらす利点（インフラとコンテナの融合）

従来のKubernetesは「ノードに固定配置された静的な物理リソース」に対してPodをスケジューリングします。そのため、コンテナが使用できるリソースの上限は、配置先ノードの物理スペックに制約されていました。

一方、LIQID CDIを適用することで「ノードに存在する物理リソースそのもの」を動的に変更できるようになります。さらに両者を連携させるコントロール層「LIQID Kubernetes Composer」を導入することで実現するのが　コンポーザブルKubernetesです。これにより、アプリケーション層の要求と物理インフラ層の自動化が融合し、リソースの極限的な有効利用が可能となります。

【コンポーザブルKubernetesの動作フロー】
[Podデプロイ (GPU要求)] ──> [k8s: Pending状態]
                                │
                                ▼
                      [LIQID Composerが検知]
                                │
                                ▼
                     [CDI: PCIeプールからGPUを
                      対象ノードへ物理コンポーズ]
                                │
                                ▼
                    [GPU Operator: ノード認識]
                                │
                                ▼
                        [Podの実行開始]
                                │
                                ▼
                      [処理完了 & アイドル化]
                                │
                                ▼
                    [CDI: GPUをプールへ自動解放]

なぜ「コンポーザブルKubernetes」なのか？（統合のメリット）

① 物理インフラの完全自動オンデマンド化

通常のKubernetesでは、GPUを要求するPodをデプロイした際、利用可能なGPUノードが存在しなければPodはPending状態のまま停止します。
コンポーザブルKubernetesでは、nvidia.com/gpu: 2 や nodeSelector 等を指定してPodを投入すると、LIQID ComposerがPending状態を検知し、フリープールから必要なGPUを対象ノードへコンポーズします。処理完了後に一定時間アイドル状態が続くと、GPUは解放されてプールへ戻ります。

② 設備投資（CAPEX）の劇的な削減

「各ワーカーノードにGPUを4枚ずつ固定搭載する」従来のアプローチでは、夜間や低負荷時に大量のGPUが遊休化します。
コンポーザブルKubernetesであれば、必要最小限のGPUプールを複数のワーカーノード間で動的に共有・割り当てできるため、高稼働率とコスト最適化（ROI向上）を高い次元で両立します。

③ 高度なGPUスプリッティング（MIG / MPS / Time-Slicing）との統合

物理的なGPU単位の着脱にとどまらず、NVIDIA GPU Operatorと連携した「MIG（空間分割）」「MPS（プロセス多重）」「Time-Slicing（時分割）」といった細粒度なリソース共有技術も、Kubernetesマニフェスト（YAML）から一元的に制御・運用できます。

4. コントロールプレーン側とワーカーノード側での実装・役割分担

コンポーザブルKubernetes環境を構築する際は、コントロールプレーンとワーカーノードでそれぞれ役割が異なります。

4.1 コントロールプレーン側の設定

コントロールプレーンには、クラスター全体を監視するコントローラーPodとして LIQID Kubernetes Composer をデプロイします。Helm経由でマニフェストを適用することで、Kubernetesが適切なノードへComposer Podを自動スケジューリングして稼働させます。

① 設定ファイル（composer-deploy.yaml）の作成例

作業ディレクトリにて設定ファイルを作成します。Liqid DirectorのIPアドレスや認証情報、タイムアウト値等を定義します。

image:
  repository: liqid/composer
  tag: 0.1.1
  pullPolicy: Always
liqidConfig:
  qomposerJson: |-
    {
      "debug": false,
      "namespaces": [ "default" ],
      "nvidia_namespace": "nvidia-gpu-operator",
      "gpu_plugin_timeout": 420,
      "pod_timeout": 480,
      "idle_timeout": 120,
      "max_compose_retries": 3,
      "directors": [
        {
          "address": "10.10.11.9",
          "group": "kube-cluster-9",
          "username": "xxxx",
          "password": "yyyy"
        }
      ]
    }
persistence:
  enabled: false
  hostPath:
    enabled: true
    path: /mapping-store

Note : 実際の環境に合わせた内容が必要です。

② Helmによる Kubernetes Composer のデプロイ

公式Helmチャートを取得し、作成した設定ファイルを適用してデプロイします。

# 1. Helmチャートの取得
helm fetch https://liqid-composer-URL

# 2. リソース永続化用ディレクトリの作成（HostPathを利用する場合）
sudo mkdir -p /mapping-store

# 3. Helmによるデプロイ実行
helm install liqid-composer liqid-composer-filename -n liqid -f composer-deploy.yaml

4.2 ワーカーノード側の前提セットアップ

ワーカーノード側では、コントロールプレーンからの指示を受け取れるよう、あらかじめ以下のセットアップを済ませておく必要があります。

  • Kubernetes コンポーネントのインストール（kubelet, kube-proxy 等）
  • NVIDIA ドライバー、プラグイン、および NVIDIA GPU Operator のインストール
  • LIQID CDI Stackのセットアップ

4.3 全体の導入フロー

  1. ワーカーノードのセットアップ: ハードウェア配線およびNVIDIAドライバ等の基本環境を準備します。
  2. クラスターの構築: コントロールプレーン側でクラスターを初期化し、ワーカーノードをジョイン（参加）させます。
  3. LIQID Composerの適用: コントロールプレーン側からHelmで liqid-composer をデプロイします。

このステップを踏むことで、KubernetesクラスターとLIQID CDIが密に連携し、自動的にGPUを着脱する「コンポーザブルKubernetes」環境が完成します。

まとめ：次世代AIインフラのスタンダード

階層 テクノロジー 役割
アプリケーション層 Kubernetes コンテナのライフサイクル管理・自動スケーリング
ハードウェア層 LIQID CDI PCIeファブリックによる物理リソースの動的分割・結合
統合オーケストレーション Kubernetes Composer Podの需要に応じてハードウェア構成を自動追従

コンポーザブルKubernetesは、AI/ML時代の「計算リソース不足」と「ハードウェア運用コスト（CAPEX/OPEX）の高騰」という二大課題を同時に解決する、極めて有力かつ実用的なインフラアーキテクチャです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?