KubernetesでLLM推論を本番運用するための構成・スケーリング・セキュリティ入門 — GPU割り当てからオートスケールまで

7月20日、Collabnixが「Deploying LLM Inference at Scale on Kubernetes: A Comprehensive Guide」と題した記事を公開した。LLMの推論サービスを実験段階から本番環境へ移行する際、GPUリソースの管理・トラフィック急増への対応・セキュリティの担保という三つの壁が一気に立ちはだかる。本記事はその入口となる構成ガイドとして、Dockerコンテナ化からKubernetesデプロイ・オートスケール・監視・セキュリティまでを一通りカバーしている。

LLMの推論サービスを本番環境で動かすのは、実験段階とは難易度が桁違いだ。GPT-3のように数千億パラメータを持つモデルは膨大なGPUリソースとメモリを必要とし、トラフィックの増減に合わせた柔軟なスケーリングも求められる。さらに2025〜2026年時点では、複数のLLMを連携させるLLMオーケストレーション構成が増え、vLLMやTensorRT-LLMといった推論エンジンの選定、KVキャッシュの効率化、バッチング戦略の最適化まで考慮する必要が出てきた。本記事が扱うのはその手前の「Kubernetes上で推論Podを正しく立ち上げ、スケールさせる」基盤部分だが、実運用の土台として欠かせない知識だ。

DockerでLLMをコンテナ化する

最初のステップはDockerによるモデルのコンテナ化だ。以下のDockerfileは、Pythonベースのモデルを最小構成でパッケージングする例である。

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD [ "python", "inference.py" ]

ベースイメージにpython:3.11-slimを使うことでコンテナサイズを抑え、requirements.txtで依存関係を固定することで再現性を確保している。inference.pyが推論処理の本体となる。

KubernetesへのデプロイとGPUリソース設定

コンテナイメージが完成したら、次はKubernetesのDeployment定義だ。ここが本記事の核心部分で、GPUリソースの明示的な要求がポイントになる。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm-inference-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: llm-inference
  template:
    metadata:
      labels:
        app: llm-inference
    spec:
      containers:
      - name: llm-inference
        image: your-docker-username/llm-model:latest
        resources:
          limits:
            nvidia.com/gpu: 1
          requests:
            cpu: 500m
            memory: 2Gi

nvidia.com/gpu: 1でGPU割り当てを明示し、CPUは500m（0.5コア）、メモリは2GiBをリクエストしている。replicas: 3で3つのPodを並走させ、可用性を確保する構成だ。本番環境ではリクエスト量に応じてレプリカ数とリソース設定を継続的に調整する必要があると記事は強調している。

なお、GPU割り当てにはクラスター側にNVIDIA Device Pluginが導入済みであることが前提となる。クラスターのセットアップにはAWS EKS、GKE、Azure AKSといったマネージドKubernetesサービスの利用が推奨されている。

サービスメッシュ（Istio）でトラフィック制御とセキュリティを強化

スケールしたシステムでは、Pod間通信の管理が複雑になる。Istioはサービスメッシュ（※マイクロサービス間の通信を専門に管理するインフラ層）として、以下の機能を提供する。

トラフィック管理: ルーティングルールによるサービス間のフロー制御
セキュリティ: mTLS（相互TLS）による暗号化・認証済み通信
オブザーバビリティ: Prometheusと連携したメトリクス収集

curl -L https://istio.io/downloadIstio | sh -
cd istio-1.x.x
export PATH=$PWD/bin:$PATH
istioctl install --set profile=demo -y

demoプロファイルは検証用で、本番では用途に合わせたプロファイルを選択する。

PrometheusとGrafanaによる監視

モニタリングにはPrometheusとGrafanaの組み合わせが推奨されている。kube-prometheusリポジトリを使うことで、まとめてデプロイできる。

git clone https://github.com/prometheus-operator/kube-prometheus.git
cd kube-prometheus
kubectl create namespace monitoring
kubectl apply -f manifests/setup
kubectl apply -f manifests/

GrafanaのダッシュボードでPodごとのCPU・メモリ使用率、ネットワークIOなどを可視化する。LLM推論の監視においては、GPUメモリ使用率やモデルのスループット（トークン/秒）も重要指標となるが、それらの収集には別途DCGM Exporterなどの導入が必要になる点も押さえておきたい。

セキュリティ：RBAC・ネットワークポリシー・Secrets管理

記事ではセキュリティについても3つの柱を示している。

RBAC（ロールベースアクセス制御）: ユーザーやサービスアカウントに対して、必要な権限だけを付与する
ネットワークポリシー: Pod間の通信を制限し、不要なアクセスを遮断する
Secrets管理: APIキーやモデルの認証情報をKubernetes Secretsで暗号化して保管する

スケーリング戦略：HPAとGPUノードの動的追加

高トラフィック時の対応として、記事はHPA（Horizontal Pod Autoscaler）とGPUノードのスケーリングを組み合わせるアプローチを取り上げている。

ただし、一点注意が必要だ。記事ではHPAの指標としてCPU・メモリ使用率に言及しているが、LLM推論ワークロードではCPUよりGPU使用率がボトルネックになるケースがほとんどであり、CPUベースのHPAは実効性が低い場合がある。実運用ではnvidia.com/gpu使用率やリクエストキュー長などをカスタムメトリクスとしてPrometheusから取得し、KEDA（Kubernetes Event-driven Autoscaling）と組み合わせてスケーリングトリガーとする構成が現実的だ。GPU不足が発生した場合はノード自体を追加するクラスターオートスケーラーと連携することで、リソース不足を防ぎながらコストを抑えられる。

モデルの具体的なサイズ（パラメータ数やVRAM要件）やベンチマーク数値は元記事には記載がなく、自分の環境に合わせた調整が必要だ。また本記事はあくまで入門レベルのガイドであり、バッチング戦略やKVキャッシュ管理、推論エンジン選定といった本番運用のより深い課題は別途検討が求められる。

詳細はDeploying LLM Inference at Scale on Kubernetes: A Comprehensive Guideを参照していただきたい。