🏃‍♂️

Kubernetesが選ばれる理由【2025年師走に駆け込む:概念から実践まで紹介】

2025/11/20に公開

はじめに

現代のソフトウェア開発において、コンテナ化されたアプリケーションの管理は避けて通れない課題となっています。Kubernetes（K8s）は、その課題を解決するためのデファクトスタンダードとして、多くの企業や開発者に選ばれています。

本記事では、Kubernetesがなぜ選ばれるのかを、以下の観点から紹介します。

Kubernetesの概念と歴史的背景
主要なオブジェクトとその役割
クラスターアーキテクチャの理解
ワークロード管理の仕組み

1. Kubernetesの概念と歴史

1.1 Kubernetesとは

Kubernetes（K8s）は、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するオープンソースのプラットフォームです。名称はギリシャ語で「操舵手」や「パイロット」を意味し、コンテナの「船」を操舵するという意味が込められています。

1.2 デプロイメントの進化

Kubernetesが解決する課題を理解するために、デプロイメントの進化を見てみましょう。

Traditional Deployment（物理サーバー時代）

初期の頃は、組織は物理サーバー上にアプリケーションを実行していました。この方式には以下の課題がありました：

リソースの無駄: 1つのアプリケーションがリソースの大半を消費すると、他のアプリケーションのパフォーマンスが低下
スケーラビリティの欠如: 物理サーバーを追加する必要があり、コストが高い
環境の一貫性: 開発、テスト、本番環境で異なる設定になりがち

Virtualized Deployment（仮想化時代）

仮想化技術の導入により、1台の物理サーバー上で複数の仮想マシン（VM）を実行できるようになりました：

リソースの効率化: 物理リソースの使用率が向上
分離性: アプリケーション間の分離が可能
柔軟性: VMの追加・削除が容易

しかし、VMは完全なOSを含むため、起動が遅く、リソース消費も大きいという課題がありました。

Container Deployment（コンテナ時代）

コンテナはVMと似ていますが、OSを共有できるため軽量です：

高速起動: VMと比較して起動が非常に速い
リソース効率: OSを共有するため、リソース消費が少ない
ポータビリティ: クラウドやOSディストリビューションを越えて移動可能

しかし、コンテナが増えると管理が複雑になります。

Kubernetes（コンテナオーケストレーション）

Kubernetesは、コンテナの管理を自動化します：

自動スケーリング: 負荷に応じて自動的にスケール
自己修復: 障害発生時の自動復旧
ローリングアップデート: ダウンタイムなしでの更新
サービスディスカバリ: 動的なサービス発見と負荷分散

1.3 Kubernetesの歴史

Kubernetesの起源:

Borg: Googleが2003年から使用していた社内コンテナ管理システム
Omega: Borgの後継システム
Kubernetes: BorgとOmegaの経験を基に、2014年にオープンソースとして公開

CNCFとの関係:

2015年、KubernetesはCloud Native Computing Foundation（CNCF）の最初のプロジェクトとして採用されました。CNCFは、クラウドネイティブなソフトウェアの開発と普及を促進する組織です。

1.4 Kubernetesが選ばれる理由

Kubernetesが多くの企業に選ばれる理由をまとめます：

理由	説明
自動化	デプロイ、スケーリング、復旧を自動化
ポータビリティ	クラウドプロバイダーに依存しない
拡張性	小規模から大規模まで対応可能
エコシステム	豊富なツールとコミュニティサポート
宣言的API	望ましい状態を宣言するだけで管理
自己修復	障害発生時の自動復旧機能

2. Kubernetesの主要なオブジェクト

Kubernetesは、オブジェクトと呼ばれるエンティティを使用してクラスターの状態を管理します。オブジェクトは、クラスターの望ましい状態を記述する設定です。

2.1 オブジェクトの基本概念

オブジェクトの特徴:

Spec（仕様）: オブジェクトの望ましい状態を記述
Status（状態）: オブジェクトの現在の状態を記録
Controller: SpecとStatusの差分を検出し、望ましい状態に近づける

2.2 主要なオブジェクト一覧

2.3 Pod - 最小のデプロイ単位

Podは、Kubernetesでアプリケーションを実行する最小の単位です。1つ以上のコンテナを含み、同じネットワークとストレージを共有します。

Podの特徴:

エフェメラル: Podは一時的な存在で、削除・再作成される
IPアドレス: 各Podには一意のIPアドレスが割り当てられる
ライフサイクル: 作成、実行、削除のライフサイクルを持つ

Podの使用例:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.21
    ports:
    - containerPort: 80

2.4 Deployment - レプリカ管理

Deploymentは、Podのレプリカセットを管理し、ローリングアップデートやロールバックを提供します。

Deploymentの機能:

レプリカ管理: 指定した数のPodを維持
ローリングアップデート: ダウンタイムなしでの更新
ロールバック: 以前のバージョンへの復帰
スケーリング: レプリカ数の増減

Deploymentの例:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

2.5 Service - サービスディスカバリと負荷分散

Serviceは、Podの集合に対するネットワークサービスを定義し、安定したIPアドレスとDNS名を提供します。

Serviceの種類:

種類	説明	使用例
ClusterIP	クラスター内部のみアクセス可能	内部サービス
NodePort	ノードのIPとポートでアクセス可能	開発環境
LoadBalancer	クラウドプロバイダーのロードバランサー	本番環境
ExternalName	外部サービスのエイリアス	外部API

Serviceの例:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: ClusterIP

2.6 ConfigMapとSecret - 設定管理

ConfigMapとSecretは、設定情報と機密情報を管理するオブジェクトです。

ConfigMap: 設定データを保存（例: 設定ファイル、環境変数）

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database_url: "postgresql://localhost:5432/mydb"
  log_level: "info"

Secret: 機密情報を保存（例: パスワード、APIキー）

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  username: YWRtaW4=  # base64エンコード
  password: cGFzc3dvcmQ=

2.7 Namespace - リソースの分離

Namespaceは、クラスター内のリソースを論理的に分離します。

Namespaceの用途:

環境分離: 本番、ステージング、開発環境の分離
チーム分離: 異なるチーム間のリソース分離
リソース制限: Namespace単位でのリソース制限

3. クラスターアーキテクチャ

Kubernetesクラスターは、コントロールプレーンとワーカーノードで構成されます。

3.1 クラスター全体のアーキテクチャ

3.2 コントロールプレーンのコンポーネント

API Server

API Serverは、Kubernetesクラスターのフロントエンドです。

API Serverの役割:

RESTful API: Kubernetes APIを提供
認証・認可: リクエストの認証と認可
バリデーション: リソースの検証
状態管理: etcdへの読み書き

etcd

etcdは、クラスターの状態を保存する分散キーバリューストアです。

etcdの特徴:

分散システム: 複数のノードでレプリケーション
一貫性: 強整合性を保証
永続化: クラスターの状態を永続的に保存

Scheduler（スケジューラー）

Schedulerは、新しく作成されたPodを適切なノードに割り当てます。

Schedulerの考慮事項:

リソース要件: CPU、メモリの要求
アフィニティ: Pod間の配置関係
アンチアフィニティ: Pod間の分散
ノードの状態: ノードの準備状況

Controller Manager（コントローラーマネージャー）

Controller Managerは、複数のコントローラーを実行し、クラスターの状態を管理します。

主要なコントローラー:

Deployment Controller: Deploymentの管理
ReplicaSet Controller: ReplicaSetの管理
Node Controller: ノードの状態監視
Endpoint Controller: ServiceとPodの紐付け

3.3 ワーカーノードのコンポーネント

kubelet

kubeletは、各ノードで実行されるエージェントです。

kubeletの役割:

Pod管理: Podのライフサイクル管理
コンテナ実行: Container Runtimeとの連携
状態レポート: ノードとPodの状態をAPI Serverに報告
ヘルスチェック: コンテナの健全性チェック

kube-proxy

kube-proxyは、ネットワークプロキシとして機能し、Serviceの負荷分散を実現します。

kube-proxyの機能:

負荷分散: 複数のPodへのトラフィック分散
ネットワークルール: iptablesまたはIPVSルールの管理
サービスディスカバリ: Serviceのエンドポイント管理

Container Runtime

Container Runtimeは、コンテナの実行環境を提供します。

主要なContainer Runtime:

containerd: CNCFプロジェクト、デファクトスタンダード
CRI-O: Kubernetes専用の軽量ランタイム
Docker: 従来から使用されているランタイム

3.4 ノード間の通信

ネットワークモデル:

Podネットワーク: 各Podに一意のIPアドレス
Serviceネットワーク: クラスター内部の仮想IP
CNI: ネットワークプラグインの標準インターフェース

3.5 ガベージコレクション

Kubernetesは、不要になったリソースを自動的に削除するガベージコレクション機能を提供します。

ガベージコレクションの対象:

終了したPod: 完了または失敗したPod
孤立したReplicaSet: Deploymentに紐づかないReplicaSet
未使用のConfigMap/Secret: 参照されていない設定

4. ワークロード

Kubernetesは、様々な種類のワークロードを管理するためのコントローラーを提供します。

4.1 ワークロードの種類

4.2 Deployment - ステートレスアプリケーション

Deploymentは、ステートレスなアプリケーションのデプロイと管理を行います。

Deploymentの特徴:

レプリカ管理: 指定した数のPodを維持
ローリングアップデート: 段階的な更新
ロールバック: 以前のバージョンへの復帰
スケーリング: レプリカ数の動的な変更

ローリングアップデートの流れ:

4.3 StatefulSet - ステートフルアプリケーション

StatefulSetは、ステートフルなアプリケーション（データベースなど）のデプロイと管理を行います。

StatefulSetの特徴:

一意の識別子: 各Podに一意の名前とID
順序付きデプロイ: 順番に作成・削除
永続ストレージ: 各Podに専用のPersistentVolume
安定したネットワーク: 一貫したDNS名

StatefulSetの例:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

4.4 DaemonSet - ノード単位のPod

DaemonSetは、各ノードに1つのPodを確実に配置します。

DaemonSetの用途:

ログ収集: 各ノードでログを収集（例: fluentd）
モニタリング: 各ノードでメトリクスを収集（例: Prometheus Node Exporter）
ネットワーク: ネットワークプラグイン（例: Calico）
ストレージ: ストレージデーモン（例: GlusterFS）

DaemonSetの例:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-logging
  template:
    metadata:
      labels:
        name: fluentd-logging
    spec:
      containers:
      - name: fluentd
        image: fluent/fluentd:latest
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      volumes:
      - name: varlog
        hostPath:
          path: /var/log

4.5 JobとCronJob - バッチ処理

Jobは、一度だけ実行されるタスクを管理し、CronJobは定期的に実行されるタスクを管理します。

Jobの特徴:

一度だけ実行: タスクが完了するまで実行
再試行: 失敗時の自動再試行
並列実行: 複数のPodで並列実行可能

CronJobの特徴:

スケジュール実行: Cron形式でスケジュール指定
履歴管理: 実行履歴の保持
同時実行制御: 同時実行数の制限

CronJobの例:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: backup-job
spec:
  schedule: "0 2 * * *"  # 毎日午前2時
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: backup-tool:latest
            command: ["/bin/sh", "-c", "backup.sh"]
          restartPolicy: OnFailure

4.6 オートスケーリング

Kubernetesは、負荷に応じて自動的にスケールする機能を提供します。

オートスケーリングの種類:

種類	説明	対象
HPA	Horizontal Pod Autoscaler	Podのレプリカ数
VPA	Vertical Pod Autoscaler	Podのリソース要求
Cluster Autoscaler	クラスターのノード数	ノード

HPAの例:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

スケーリングの流れ:

5. まとめ

本記事では、Kubernetesがなぜ選ばれるのかを、以下の観点から解説しました：

5.1 Kubernetesが選ばれる理由のまとめ

5.2 主要なポイント

歴史と実績: GoogleのBorgシステムの経験を基に開発され、CNCFの支援を受けて急速に普及
豊富なオブジェクト: Pod、Deployment、Service、ConfigMap、Secretなど、様々なニーズに対応
堅牢なアーキテクチャ: コントロールプレーンとワーカーノードの分離により、スケーラブルで可用性の高いシステム
多様なワークロード: ステートレス、ステートフル、バッチ処理など、あらゆる種類のアプリケーションに対応
自動化機能: オートスケーリング、ローリングアップデート、自己修復など、運用を大幅に簡素化

5.3 次のステップ

Kubernetesを学ぶための次のステップ：

ハンズオン: minikubeやkindでローカル環境を構築
公式ドキュメント: Kubernetes公式ドキュメントを参照
実践: 実際のアプリケーションをKubernetesにデプロイ
監視とObservability: Prometheus、Grafanaなどのツールを学ぶ

Kubernetesは、現代のクラウドネイティブなアプリケーション開発において、不可欠な技術となっています。本記事が、Kubernetesの理解と実践の第一歩となれば幸いです。