Kubernetes入門ガイド2026──コンテナオーケストレーションの基本からGitOps運用まで

Kubernetesとは──なぜコンテナオーケストレーションが必要か

Kubernetesは、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するオープンソースのプラットフォームだ。Googleが社内で使用していた「Borg」の設計思想をもとに開発され、2014年にオープンソースとして公開された。

課題	Dockerだけの場合	Kubernetesを使う場合
複数コンテナの管理	手動でdocker runを実行	宣言的なYAMLで一括管理
スケーリング	手動でコンテナを追加	自動スケーリング（HPA）
ロードバランシング	外部ツールが必要	Service / Ingressで組み込み
障害復旧	コンテナが落ちたら手動再起動	自動再起動・自己修復
ローリングアップデート	ダウンタイムが発生	ゼロダウンタイムデプロイ
シークレット管理	環境変数の手動管理	Secretリソースで暗号化管理
リソース制御	制限なし	CPU/メモリの上限設定

1つのDockerコンテナを動かすだけなら、Kubernetesは不要だ。だが、複数のマイクロサービスを連携させ、負荷に応じてスケールし、障害時に自動復旧させたいなら、コンテナオーケストレーションは避けて通れない。

アーキテクチャ──コントロールプレーンとデータプレーン

Kubernetesクラスタは「コントロールプレーン」（管理層）と「データプレーン」（実行層）の2層で構成される。

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

コンポーネント	役割
kube-apiserver	すべてのAPI操作の窓口。kubectlの通信先
etcd	クラスタの状態を保存する分散KVストア
kube-scheduler	Podの配置先ノードを決定
kube-controller-manager	望ましい状態を維持するコントローラ群
cloud-controller-manager	クラウドプロバイダ固有の操作を管理

データプレーン（ワーカーノード）のコンポーネント

コンポーネント	役割
kubelet	ノード上のPod管理。コントロールプレーンと通信
kube-proxy	Serviceのネットワークルールを管理
Container Runtime	コンテナの実行（containerd、CRI-O）

マネージドKubernetes（EKS / GKE / AKS）を使う場合、コントロールプレーンはクラウドプロバイダが管理するため、ユーザーはデータプレーン（ワーカーノード）の運用に集中できる。

主要リソース──Pod、Deployment、Service

Kubernetesでは、あらゆる構成要素を「リソース」としてYAMLファイルで宣言する。

Podとは

PodはKubernetesの最小デプロイ単位だ。1つ以上のコンテナをまとめたグループで、同じネットワーク空間とストレージを共有する。

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

ただし、Podを直接作成することは稀だ。通常はDeploymentを通じて管理する。

Deployment──宣言的なアプリ管理

Deploymentは「どのコンテナを何個動かすか」を宣言するリソースだ。レプリカ数の維持、ローリングアップデート、ロールバックを自動で行う。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: app
          image: my-app:1.0.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"

replicas: 3と宣言すれば、Kubernetesが常に3つのPodを維持する。Podが1つ落ちれば自動的に新しいPodが起動する。

Service──ネットワークの抽象化

Serviceは、複数のPodに対する安定したネットワークエンドポイントを提供する。Podは起動するたびにIPアドレスが変わるが、Serviceを使えば固定のDNS名でアクセスできる。

Serviceタイプ	用途	アクセス範囲
ClusterIP	クラスタ内部通信	クラスタ内のみ
NodePort	外部からノードIP経由	開発用途
LoadBalancer	クラウドLBと連携	本番の外部公開

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080
  type: LoadBalancer

その他の重要リソース

リソース	用途
Ingress	HTTP/HTTPSルーティング（パスベース、ホストベース）
ConfigMap	設定データの管理（環境変数、設定ファイル）
Secret	機密情報の管理（パスワード、APIキー）
PersistentVolumeClaim	永続ストレージの要求
HorizontalPodAutoscaler	CPU/メモリ使用率に基づく自動スケーリング
CronJob	定期実行タスク
Namespace	リソースの論理的な分離

ローカルで試す──Minikubeとkind

本番環境のKubernetesを試す前に、ローカル環境で体験することを強く勧める。

ツール	特徴	推奨用途
Minikube	軽量なローカルクラスタ。アドオン豊富	学習、機能検証
kind（Kubernetes in Docker）	DockerコンテナでKubernetesを動かす	CI/CD、テスト
Docker Desktop	GUIで簡単にKubernetes有効化	macOS/Windowsユーザーの入門
k3s	軽量Kubernetes（Rancher製）	本番対応の軽量環境

# Minikubeの場合
brew install minikube
minikube start
kubectl get nodes   # ノード一覧を確認

# アプリのデプロイ
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl get pods    # Pod一覧を確認

kubectlはKubernetesのCLIツールで、クラスタとのすべてのやり取りに使う。以下はよく使うコマンドだ。

コマンド	説明
kubectl get pods	Pod一覧
kubectl describe pod <name>	Pod詳細情報
kubectl logs <pod>	コンテナログ
kubectl exec -it <pod> -- /bin/sh	コンテナにシェル接続
kubectl apply -f <file>	リソースの作成/更新
kubectl delete -f <file>	リソースの削除
kubectl port-forward <pod> 8080:80	ポートフォワーディング

マネージドKubernetes比較

自前でKubernetesクラスタを構築・運用するのは技術的に可能だが、ほとんどの場合はマネージドサービスを使うべきだ。

項目	AWS EKS	Google GKE	Azure AKS
コントロールプレーン費用	$0.10/時間（約$73/月）	無料（Standard）/ $0.10/時間（Enterprise）	無料（Standard）/ 有料（Premium）
最新K8sバージョン対応	やや遅い	最速	中程度
マネージドノード	EKS Managed Node Groups	GKE Autopilot	AKS Node Pools
サーバーレスコンテナ	Fargate	Cloud Run（GKE統合）	ACI（Azure Container Instances）
GPU対応	あり	あり（最も充実）	あり
日本リージョン	東京、大阪	東京、大阪	東京、大阪

GKE AutopilotはGoogleが推奨する運用モードで、ノードの管理をGoogleに完全に委ねる。ユーザーはPodの仕様だけを定義すれば、ノードのプロビジョニング、スケーリング、セキュリティパッチが自動化される。クラウド比較について詳しくは「クラウド比較ガイド（AWS/GCP/Azure）」も参照してほしい。

本番運用のポイント

Kubernetesを本番で運用する際に押さえるべきポイントを整理する。

カテゴリ	ポイント
リソース管理	requests/limitsを必ず設定。OOMKillを防ぐ
ヘルスチェック	livenessProbe / readinessProbeを設定
セキュリティ	RBAC、NetworkPolicy、Pod Security Standards
モニタリング	Prometheus + Grafana が事実上の標準
ログ管理	Fluent Bit → OpenSearch / CloudWatch
GitOps	ArgoCD / Flux でマニフェスト管理
バックアップ	etcdのバックアップ、Veleroの活用

GitOps──Kubernetesの運用を変えるアプローチ

GitOpsは「Gitリポジトリを信頼できる唯一の情報源とし、クラスタの状態をGitに同期させる」運用手法だ。ArgoCDやFluxが代表的なツールで、以下のフローで運用する。

ステップ	内容
1	開発者がKubernetesマニフェストをGitにpush
2	ArgoCDがGitリポジトリの変更を検知
3	クラスタの実際の状態とGitの宣言を比較
4	差分があれば自動（または手動承認後に）同期

手動でのkubectl applyを排除し、変更の追跡性、ロールバックの容易さ、監査対応を実現する。2026年の本番Kubernetes運用では、GitOpsの採用は事実上の標準になりつつある。

年収とキャリア

市場	年収レンジ	備考
日本（Kubernetesエンジニア）	600万〜1,400万円	SREロールで上限が上がる
日本（フリーランス）	月額70万〜120万円	CKA/CKS取得者は優遇
米国	$110K〜$185K	Platform Engineerとの親和性が高い

Kubernetes関連の認定資格も市場価値に影響する。

資格	内容	難易度
CKA（Certified Kubernetes Administrator）	クラスタの構築・運用	中
CKAD（Certified Kubernetes Application Developer）	アプリ開発者向け	中
CKS（Certified Kubernetes Security Specialist）	セキュリティ特化	高

CKA取得者は日本市場での転職において明確な優位性がある。試験はすべてハンズオン（実技）形式で、ペーパーテストではないため実務能力が直接問われる。

学習ロードマップ

Phase 1：基礎（1-3週間）

学習項目	リソース
コンテナの基礎	Docker公式チュートリアル
Kubernetes概念	Kubernetes公式ドキュメント
ローカル環境構築	Minikube / Docker Desktop
基本操作	kubectl操作の練習

Phase 2：実践（4-8週間）

学習項目	プロジェクト例
マニフェスト作成	Deployment + Service + Ingress
Helm	チャートの利用と作成
モニタリング	Prometheus + Grafana構築
CI/CD連携	GitHub Actions → イメージビルド → デプロイ

Phase 3：応用（9-12週間）

学習項目	目標
GitOps	ArgoCD導入
セキュリティ	RBAC、NetworkPolicy、OPA
CKA試験準備	KillerCoda / Killer.sh
マルチクラスタ	Federation、マルチリージョン

Kubernetesの学習は「まず触ってみること」が最も効率的だ。概念を座学で理解しようとしても抽象度が高く挫折しやすい。Minikubeでクラスタを立て、PodをデプロイしてService経由でアクセスする──この一連の体験が、すべての概念をつなげてくれる。

Kubernetesを学ぶことは、単にツールを覚えるだけではない。分散システムの設計思想、宣言的な運用モデル、可観測性の実践──現代のインフラエンジニアリングの基盤となる考え方を身につけることだ。「Kubernetesは難しい」と言われるが、その難しさの本質はKubernetes自体ではなく、分散システムそのものの複雑さにある。この複雑さとどう向き合うか──それがKubernetesを学ぶ真の価値ではないだろうか。