Kubernetesとは？コンテナオーケストレーション・Docker連携・使い方入門

Kubernetesとは何か？基本概念をわかりやすく解説

Kubernetes（クバネティス、k8sとも略称）は、コンテナ化されたアプリケーションのデプロイ・スケーリング・管理を自動化するオープンソースのコンテナオーケストレーションプラットフォームです。2014年にGoogleが社内システム「Borg」の知見をもとにオープンソース化し、現在はCloud Native Computing Foundation（CNCF）が管理しています。

コンテナ技術の普及とともに、「どうやって数十・数百のコンテナを安定して動かし続けるか」という課題が生まれました。その答えとして登場したのがKubernetesです。2026年時点では本番環境での採用率が82%に達し、クラウドネイティブ開発の事実上の標準基盤として定着しています。

DockerとKubernetesの違い・連携関係

Dockerは「コンテナを作って動かす」ツールであり、Kubernetesは「そのコンテナ群を管理・自動化する」プラットフォームです。両者は競合関係ではなく、補完・連携関係にあります。

項目	Docker	Kubernetes
主な役割	コンテナのビルド・実行	コンテナ群のオーケストレーション
スケール	単一ホスト向け	複数ノード・クラスタ規模
自己修復	限定的	自動再起動・再スケジューリング
負荷分散	手動設定が必要	Serviceリソースで自動化
ローリング更新	手動操作	Deploymentで宣言的に実行

実際の開発フローでは、DockerfileでコンテナイメージをビルドしてDockerレジストリ（Docker Hub、Azure Container Registry等）にプッシュし、そのイメージをKubernetesがクラスタ上で管理・実行するという流れが一般的です。Renueの社内プロジェクトでも、GitHub ActionsでDockerイメージをビルドしてACR（Azure Container Registry）にプッシュし、KubernetesベースのAzure Container AppsがそのイメージをPull・実行する構成が採用されています。

Kubernetesのアーキテクチャ：クラスタ・ノードの仕組み

Kubernetesの基本単位は「クラスタ」です。クラスタは以下の要素で構成されています。

コントロールプレーン（マスターノード）

クラスタ全体の状態を管理する頭脳部分です。主なコンポーネントは以下のとおりです。

• kube-apiserver：すべての操作を受け付けるAPIゲートウェイ。kubectlやCI/CDパイプラインはここに命令を送ります。
• etcd：クラスタの状態（どのPodがどこで動いているか等）を保存する分散KVストア。
• kube-scheduler：新しいPodをどのノードに配置するかを決定します。
• kube-controller-manager：Deploymentの台数維持、Serviceの更新などを常時監視・調整します。

ワーカーノード

実際にコンテナ（Pod）を動かす実行ノードです。

• kubelet：コントロールプレーンの指示を受け、コンテナの起動・停止を担当するエージェント。
• kube-proxy：ノード内のネットワークルーティングを管理します。
• コンテナランタイム：containerd等、実際にコンテナを動かすエンジン。

主要リソースオブジェクト詳解

Pod（ポッド）：Kubernetesの最小デプロイ単位

Podは1つ以上のコンテナをグループ化した最小デプロイ単位です。同一Pod内のコンテナはネットワーク名前空間とIPアドレスを共有し、localhostで相互通信できます。

典型的な例として、メインアプリケーションコンテナとログ収集用サイドカーコンテナを同一Podに配置するパターンがあります。Podは基本的に「一時的なもの」であり、障害発生時は自動的に新しいPodが再生成されます。

Deployment（デプロイメント）：宣言的なアプリ管理

Deploymentは「このアプリを3台のPodで動かし続けること」といった望ましい状態を宣言的に定義するリソースです。主な機能は以下のとおりです。

• レプリカ管理：指定した台数のPodを常時維持（自己修復）
• ローリングアップデート：ダウンタイムなしで新バージョンに段階的に切り替え
• ロールバック：問題発生時に直前のバージョンへ即座に戻せる

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-registry/my-app:v1.2.0
        ports:
        - containerPort: 8080

Service（サービス）：Podへの安定したアクセス口

PodはIPアドレスが起動のたびに変わるため、直接アクセスすると不安定です。Serviceは複数Podへの仮想的なエンドポイントを提供し、ロードバランシングも担います。主なServiceタイプは以下のとおりです。

• ClusterIP（デフォルト）：クラスタ内部からのみアクセス可能な内部IPを割り当て
• NodePort：ノードの特定ポートを外部に公開
• LoadBalancer：クラウドプロバイダのロードバランサーと連携し、外部からのアクセスを受け付ける
• ExternalName：外部DNSへのエイリアスとして機能

ConfigMap / Secret：設定と機密情報の分離

ConfigMapは環境変数や設定ファイルをコンテナイメージから切り離して管理するリソースです。Secretは同様の仕組みをパスワードやAPIキーなど機密情報に適用し、Base64エンコード（実運用ではExternal SecretsやVault等との連携推奨）で保管します。

Namespace（ネームスペース）：クラスタの論理分割

1つのクラスタを複数の仮想クラスタに分割する仕組みです。開発・ステージング・本番環境を同一クラスタ内で分離したり、チーム別にリソース制限を設けたりする際に活用します。

Ingress（イングレス）：HTTP/HTTPSルーティング

クラスタ外からのHTTP/HTTPSトラフィックをPodにルーティングするリソースです。ドメイン名やパスによるルーティング振り分け、TLS終端などを担います。nginx-ingress-controllerやAWS ALB Controllerなど各クラウド・OSS実装があります。

Kubernetesのスケーリング機能

Kubernetesのスケーリングは、手動と自動の2段階で提供されています。

水平Pod自動スケーラー（HPA）

CPU使用率やカスタムメトリクスに基づいてPodの台数を自動増減させます。アクセス急増時に自動でスケールアウトし、負荷が落ち着けばスケールインしてコストを最適化します。

垂直Pod自動スケーラー（VPA）

個々のPodに割り当てるCPU・メモリリクエストを自動調整します。リソース設定の最適化に活用できます。

クラスタオートスケーラー

PodをスケジュールできるリソースがなくなったとPodが判断した場合に、ワーカーノード自体を自動追加するクラウドプロバイダ連携の機能です。

主要なKubernetesディストリビューション・マネージドサービス

Kubernetesをゼロから構築・運用するのは高コストなため、多くの企業はマネージドサービスを活用しています。

サービス名	提供元	特徴
GKE（Google Kubernetes Engine）	Google Cloud	Kubernetes発祥のGoogleが提供。Autopilotモードで運用負荷を大幅削減
EKS（Amazon Elastic Kubernetes Service）	AWS	AWSエコシステムとの豊富な統合。IAMとの連携が強力
AKS（Azure Kubernetes Service）	Microsoft Azure	Azure DevOpsやActive Directoryとの統合が充実
Azure Container Apps	Microsoft Azure	Kubernetesをより抽象化したサーバーレス志向のコンテナ実行環境
OpenShift	Red Hat	エンタープライズ向け強化版。セキュリティポリシーが厳格

Renueの社内インフラでは、Azure Container Apps（Kubernetesベース）を活用してバッチジョブや定期処理を実行するアーキテクチャを採用しており、Terraformとのコード管理・GitHub Actionsによる自動デプロイで運用しています。

Kubernetesの実践入門：インストールから初回デプロイまで

ローカル環境での試し方

本番クラスタを用意する前に、ローカルで試す方法がいくつかあります。

• minikube：ローカルマシン上に1ノードのKubernetesクラスタを構築。最も学習コストが低い。
• kind（Kubernetes IN Docker）：Dockerコンテナをノードとして使う軽量環境。CI/CDでも使われる。
• Docker Desktop：Kubernetesを内蔵。設定1つで有効化できる。

kubectlの基本コマンド

# クラスタ情報確認
kubectl cluster-info

# Podの一覧表示
kubectl get pods -n default

# Deploymentの作成・適用
kubectl apply -f deployment.yaml

# Podのログ確認
kubectl logs <pod-name>

# Podにアクセスしてシェル実行
kubectl exec -it <pod-name> -- /bin/bash

# Serviceの外部公開（開発用）
kubectl port-forward svc/my-app 8080:80

Helmによるパッケージ管理

HelmはKubernetesのパッケージマネージャーです。複数のKubernetesマニフェストをチャートとしてまとめ、バージョン管理・インストール・アップグレードを容易にします。NginxやPrometheus等のOSSコンポーネントはHelmチャートとして公開されており、数コマンドで本番品質の設定を導入できます。

KubernetesとAI/ML基盤：2025-2026年のトレンド

KubeCon + CloudNativeCon 2026 EUでは「AI、AI、そしてAI」がテーマとなり、LLMやAIエージェントのインフラ基盤としてKubernetesが急速に重要性を増しています。具体的には以下の活用が進んでいます。

• AI推論ワークロードのスケーリング：GPUノードへのPod配置、リクエスト量に応じた自動スケール
• MLOpsパイプライン：Kubeflow・Argo WorkflowsによるML実験管理・モデル学習の自動化
• AIエージェント基盤：複数AIサービスをマイクロサービスとして管理し、KubernetesのServiceで疎結合に連携
• GKE Autopilot：2024年に作成されたアクティブなGKEクラスタの30%がAutopilotモードを採用。AIワークロードのノード管理を自動化

AIコンサルティングの観点から見ると、企業のAI内製化を支援する際にKubernetesは欠かせないインフラ知識です。「AIを動かす」だけでなく「AIを安定して本番運用する」ためのプラットフォームとして、Kubernetes理解はエンジニアだけでなくAIプロジェクトを推進するコンサルタントにも求められています。

Kubernetesの導入メリットと注意点

主なメリット

• 自己修復能力：コンテナ障害時の自動再起動・再スケジューリングで高可用性を実現
• 環境の一貫性：開発・ステージング・本番で同一のコンテナイメージを使用し、「動作環境の差異」問題を解消
• 段階的デプロイ：ローリングアップデートとロールバックでダウンタイムリスクを最小化
• リソース効率化：自動スケーリングで過剰なリソース確保を防ぎ、クラウドコストを最適化
• ベンダー非依存性：各クラウドのマネージドKubernetesは基本APIが共通で、マルチクラウド・移行が容易

導入時の注意点

• 学習コスト：Pod・Service・Deployment・Ingress・ConfigMap等、覚えるべきリソースが多く初期の習得コストが高い
• 小規模には過剰な場合も：シンプルなWebアプリなら、Azure Container AppsやCloud Runなど抽象度の高いサービスで十分なケースも多い
• セキュリティ設定：RBACやネットワークポリシーの適切な設定が必要。デフォルト設定のまま本番運用するのは危険
• ステートフルアプリへの対応：データベース等のステートフルワークロードはStatefulSetやPersistentVolumeの理解が追加で必要

よくある質問（FAQ）

Q1. KubernetesとDocker Composeの使い分けは？

Docker Composeは開発環境やシングルホストでの複数コンテナ管理に適しています。本番環境で複数サーバーにまたがるスケーリングや高可用性が必要な場合はKubernetesが適切です。規模と要件に応じて選択し、小中規模ではAzure Container AppsやCloud RunといったKubernetes上位互換サービスも有力な選択肢です。

Q2. KubernetesはオンプレミスでもAWSでもAzureでも同じYAMLが使えるのか？

基本的なDeployment・Service・ConfigMapなどのコアリソースは共通のYAMLで動作します。ただし、LoadBalancerタイプのServiceやIngressコントローラーはクラウドプロバイダ固有の実装があるため、完全な移植性を確保するにはクラウド固有部分を抽象化する設計が必要です。

Q3. Kubernetesの習得にどれくらい時間がかかる？

基本操作（kubectl、Pod/Deployment/Service）は1〜2週間程度で習得できます。本番運用レベル（セキュリティ、監視、CI/CDとの統合）までは3〜6ヶ月程度が一般的です。CKA（Certified Kubernetes Administrator）やCKAD（Certified Kubernetes Application Developer）の資格取得を目標にすると体系的に学べます。

Q4. KubernetesでAIエージェントを動かすメリットは？

AIエージェントは複数のLLM呼び出し・ベクターDB・APIサーバーを連携させるマイクロサービス構成になりがちです。Kubernetesを使うと、各コンポーネントを独立してスケールさせつつ、ServiceやIngress経由でAPI連携を安定して管理できます。GPU利用のAI推論コンテナとCPUで動くAPIゲートウェイを同一クラスタで管理し、リソースを効率的に割り当てられる点も大きな利点です。

Q5. Kubernetes導入にAIコンサルタントはどう貢献できる？

AIコンサルタントはKubernetes導入の技術実装だけでなく、「どのワークロードをコンテナ化すべきか」「マネージドKubernetesか抽象化サービスかの選択」「AIワークロードのインフラ設計」など、ビジネス要件と技術選定を橋渡しする役割を担います。導入後の運用設計・コスト最適化・チームへの技術移転まで含めたトータルサポートが価値を生みます。

Q6. 小規模スタートアップでもKubernetesは必要か？

必ずしも必要ではありません。初期はDocker + ECR/ACR + Cloud Run/Azure Container Appsで十分なことが多く、スケール要件が生まれてからKubernetes移行を検討するのが現実的です。ただし、AI/MLを本格活用する段階では早期にKubernetes設計を取り入れると後の移行コストを抑えられます。