【Kubernetes実践編 #10】本番への道 — マネージドK8sと、その先の展望
10.1 はじめに
10.1.1 第9回の振り返り — 障害対応を乗り越えた
前回の第9回では、TaskBoardを意図的に壊しました。CrashLoopBackOff、OOMKilled、Node障害、ネットワーク遮断、ストレージ障害、設定ミス——6つのシナリオを通じて、障害の検知から切り分け、復旧、再発防止策の策定、そして障害報告書の作成まで、一連のプロセスを実践しました。
そこで実感したのは、実践編で作成した成果物——構成図、設計書、通信制御マトリクス、運用設計書、変更管理手順書——が障害対応の現場でそのまま「武器」として機能することでした。設計書は作って終わりではなく、壊れたときにこそ価値を発揮する。それを体験で理解できたはずです。
10.1.2 本回の位置づけ — エピローグとしての最終回
第9回がシリーズのクライマックスでした。第10回はエピローグです。
入門編（全11回）→ 応用編（全9回）→ 実践編（全10回）の全30回を通じて、あなたはkind環境上でK8sの基本操作から設計・構築・運用・障害対応までを一周しました。しかし、kind環境はあくまで学習環境です。「本番ではどう変わるのか」という問いに答えないまま、シリーズを閉じるわけにはいきません。
本回では、kindと本番環境の差分を整理し、マネージドK8s（EKS / AKS / GKE）の選択肢を概観し、次のステップへの道標を示します。ハンズオンは最小限にとどめ、知識の整理と次のアクションの明確化に注力します。
【フェーズ1：設計】
✅ 第1回 ── 構成図
✅ 第2回 ── 基本設計
✅ 第3回 ── 詳細設計
【フェーズ2：構築】
✅ 第4回 ── 環境構築
✅ 第5回 ── アプリケーション構築
✅ 第6回 ── ネットワーク構築
【フェーズ3：運用】
✅ 第7回 ── 運用設計
✅ 第8回 ── 日常運用
【フェーズ4：障害対応と発展】
✅ 第9回 ── 障害対応（クライマックス）
☆ 第10回 ── 本番への道 ← 今回（エピローグ・シリーズ最終回）10.1.3 本回のゴールと成果物
本回のゴールは、kindで学んだ知識と本番環境の差分を理解し、次に何をすべきかが明確になることです。
成果物は2つです。
- kind → 本番の差分マッピング表: 「そのまま使えるもの」と「変わるもの」を体系的に整理した表
- 次のステップロードマップ: シリーズ完走後に取るべきアクションの一覧
10.2 kindと本番環境の差分マッピング
応用編第1回で、kindを採用した理由を説明しました。本シリーズの目的は「クラスタの上でリソースをどう設計・運用するか」であり、「クラスタ自体の構築方法」ではない。kindのNodeはDockerコンテナだが、kubectlコマンドやマニフェストは本番でもそのまま使える——そう書きました。
ここで、その約束を果たします。kindで学んだことのうち、何がそのまま使えて、何が変わるのかを具体的に整理しましょう。
10.2.1 「そのまま使えるもの」— kubectl・マニフェスト・設計思想
結論から言えば、本シリーズで学んだことの大半は本番環境でもそのまま活かせます。
kubectlコマンド。入門編の第11回で身につけた「4種の神器」（get / describe / logs / exec）はもちろん、apply、diff、wait、rollout、drain、top——これらはすべて、EKS / AKS / GKEのクラスタに接続しても同じコマンドで同じ結果を返します。kubectlは「K8s API」と対話するクライアントであり、クラスタがkindであろうとEKSであろうと、APIの仕様は同じだからです。
マニフェストの構造。実践編第3回で書いた詳細設計書のマニフェスト——apiVersion、kind、metadata、specの構造はK8sの標準仕様であり、クラスタの種類には依存しません。Deployment、StatefulSet、Service、ConfigMap、Secret、NetworkPolicy、HPA、PDB——すべて同じYAMLで動きます。
設計思想。これが最も重要です。Namespace分離によるマルチテナント設計、RBACによる最小権限アクセス制御、NetworkPolicyによるPod間通信の最小権限制御、SecurityContextによるコンテナ権限の制限、Probe設計による自己修復、HPAによる自動スケーリング、PDBによる可用性保証——これらの設計判断のフレームワークは、どのK8s環境でも共通です。
障害対応の思考フレーム。第9回で実践した「検知 → 切り分け → 調査 → 復旧 → 恒久対策 → 報告」のフローは、プラットフォームに依存しません。kubectl get podsでPodの状態を確認し、describeでEventsを見て、logsでアプリケーションログを確認する——この切り分けアプローチは本番でも同じです。
Helmチャートの構造と運用フロー。第8回で完成させたTaskBoardのHelmチャートは、values.yamlの値を本番環境に合わせて変更すれば、そのまま本番にデプロイできます。helm install、helm upgrade、helm rollback、helm history——操作体系はすべて同じです。
VMの世界で例えるなら、vSphere環境の運用手順書に書いた「VMの作成手順」「リソース設定」「HA設計」の考え方は、オンプレミスでもクラウド上のVMware環境でも変わりません。それと同じことです。
10.2.2 「変わるもの」— クラスタ管理・LB・ストレージ・認証・監視
一方で、kindと本番環境では明確に異なる領域があります。大きく分けると「プラットフォーム層」と「外部連携」の2つです。
クラスタの構築と管理。本シリーズではkind create clusterの1コマンドでクラスタを作りました。本番のマネージドK8sではコンソール画面やIaC（Infrastructure as Code）ツールでクラスタを構築します。しかしこれは「変わる」というより「不要になる」に近い変化です。マネージドK8sの最大の利点は、コントロールプレーン（API Server、etcd、Scheduler、Controller Manager）の管理がクラウドベンダーの責任になることです。etcdのバックアップやAPI Serverの証明書更新といった運用を、利用者が意識する必要はありません。
ノード管理。kindではNodeがDockerコンテナなので、docker stopで停止しdocker startで復旧しました。本番ではNodeはEC2インスタンスやAzure VM、GCEインスタンスなどの実マシンです。マネージドK8sにはノードの自動修復機能があり、異常なNodeを検知して自動的に置き換えます。ただし、PodがNodeから退去する挙動（Taint / Toleration / PDB）は同じです。第8回で学んだkubectl drainの考え方はそのまま活きます。
LoadBalancer。本シリーズではGateway APIをNodePort経由で利用し、kubectl port-forwardで動作を確認しました。本番ではService type: LoadBalancerを作成すると、クラウドベンダーのロードバランサー（AWS ALB/NLB、Azure Load Balancer、GCP Cloud Load Balancing）が自動的にプロビジョニングされます。Gateway APIの設計思想（GatewayClass → Gateway → HTTPRoute）はそのまま使えますが、GatewayClassがクラウド固有の実装に変わります。
ストレージ。kindではデフォルトのlocal-path StorageClassを使いました。本番ではクラウドストレージ（AWS EBS、Azure Disk、GCP Persistent Disk）が動的にプロビジョニングされます。PVCの設計（サイズ、アクセスモード）はそのまま使えますが、StorageClassの名前と性能特性が変わります。クラウドストレージには冗長性があるため、可用性は大幅に向上します。
認証とIAM。kindではkind内蔵の証明書で認証していました。本番ではクラウドのIAMと連携します。AWS IRSA（IAM Roles for Service Accounts）、Azure Workload Identity、GCP Workload Identity——Podがクラウドサービスにアクセスする際の認証がクラウドネイティブになります。ただし、K8s内部のRBACは変わりません。
監視とログ。kubectl topとMetrics Serverで行ったリソース監視は、本番ではPrometheus + Grafana、あるいはクラウドネイティブの監視サービス（Amazon CloudWatch、Azure Monitor、Google Cloud Monitoring）に置き換わります。kubectl logsで確認していたログは、Fluentd / Fluent Bitなどのログ収集エージェントを経由して集約ログ基盤に送られます。応用編第4回で作ったDaemonSetによるログ収集は、まさにこのアーキテクチャの原型です。
CI/CD。本シリーズではdocker build→kind load docker-image→kubectl apply（あるいはhelm upgrade）を手動で実行しました。本番ではCI/CDパイプライン（GitHub Actions、GitLab CI、Jenkins等）やGitOps（ArgoCD、Flux）によって自動化されるのが一般的です。
TLSとDNS。kindではHTTPで通信し、IPアドレスでアクセスしました。本番ではcert-managerやクラウドのACM（AWS Certificate Manager）でTLS証明書を管理し、ExternalDNSやクラウドDNSでドメイン管理を行います。
10.2.3 差分マッピング表
ここまでの内容を1つの表にまとめます。本番環境への移行を検討する際のチェックリストとして活用してください。
| 領域 | kind環境 | マネージドK8s（本番） | 移行時の影響 |
|---|---|---|---|
| kubectlコマンド | 全コマンド利用可能 | 全コマンド利用可能 | 変更なし |
| マニフェスト | 標準K8s API | 標準K8s API | 変更なし |
| Namespace / RBAC | 設計・適用済み | 同じ設計をそのまま適用 | 変更なし |
| NetworkPolicy | Calico CNI | クラウド固有CNI（VPC CNI等） | 設定は同じ。CNIプラグインが異なる場合あり |
| SecurityContext | 設計・適用済み | 同じ設計をそのまま適用 | 変更なし |
| HPA / PDB | 設計・適用済み | 同じ設計をそのまま適用 | 変更なし |
| Probe設計 | 設計・適用済み | 同じ設計をそのまま適用 | 変更なし |
| Helmチャート | 完成済み | values.yamlの環境差分のみ変更 | 軽微な変更のみ |
| 障害対応フロー | 6シナリオ実践済み | 同じ思考フレームを適用 | 変更なし |
| クラスタ構築 | kind create cluster | コンソール / IaC | マネージドサービスに委譲 |
| ノード管理 | Dockerコンテナ | EC2 / VM / GCEインスタンス | 自動修復あり。drain操作は同じ |
| LoadBalancer | NodePort / port-forward | クラウドLB自動プロビジョニング | GatewayClassが変わる |
| StorageClass | local-path | クラウドストレージ（EBS / Azure Disk等） | PVC設計は同じ。StorageClass名が変わる |
| IAM / 認証 | kind内蔵証明書 | クラウドIAM連携（IRSA等） | 新規学習が必要 |
| 監視 | kubectl top（Metrics Server） | Prometheus + Grafana / クラウド監視 | 新規構築が必要 |
| ログ | kubectl logs / DaemonSet | Fluentd → 集約ログ基盤 | ログ収集エージェントの導入 |
| CI/CD | 手動（docker build → kind load） | GitOps / CI/CDパイプライン | 新規構築が必要 |
| TLS | なし（HTTP） | cert-manager / クラウドACM | 新規構築が必要 |
| DNS | なし（IPアクセス） | ExternalDNS / クラウドDNS | 新規構築が必要 |
表を見ると、上半分（kubectlからHelmチャートまで）は「変更なし」が並んでいます。本シリーズで学んだ知識の核心部分は、そのまま本番に持ち込めるということです。下半分は「新規学習が必要」な領域ですが、これらはK8sの上に載る「プラットフォーム層」と「外部連携」であり、K8sそのものの設計力とは別のスキルです。
10.3 マネージドK8sの選択肢
10.3.1 EKS / AKS / GKE — 3大マネージドK8sの概要
本番環境でK8sを運用するなら、マネージドK8sを利用するのが最も現実的な選択肢です。自前でkubeadmクラスタを構築・維持する道もありますが、etcdのバックアップ、API Serverの可用性確保、証明書の更新、K8sバージョンのアップグレード——これらをすべて自分たちで管理するのは、専任のプラットフォームチームがいない限り非現実的です。
2026年現在、主要なマネージドK8sサービスは3つあります。
| Amazon EKS | Azure AKS | Google GKE | |
|---|---|---|---|
| 提供元 | Amazon Web Services | Microsoft Azure | Google Cloud |
| コントロールプレーン | マネージド（課金あり） | マネージド（無料） | マネージド（Autopilotは無料、Standardは課金あり） |
| ノード管理 | Managed Node Groups / Fargate | Node Pools / Virtual Nodes | Node Pools / Autopilot |
| CNI | VPC CNI（デフォルト） | Azure CNI / kubenet | GKE dataplane v2（Cilium） |
| IAM連携 | IRSA / Pod Identity | Workload Identity | Workload Identity |
| 特徴 | AWSエコシステムとの統合 | Azure AD統合、Windows対応 | K8sの開発元Googleが提供。Autopilotモード |
3つのサービスにはそれぞれ特徴がありますが、K8sとしての基本的な動作は同じです。kubectl get podsの結果は、EKSでもAKSでもGKEでも同じ形式で返ってきます。
10.3.2 選定の観点 — 「すでに使っているクラウドから始める」
マネージドK8sの選定で最も実務的なアドバイスは「すでに使っているクラウドベンダーのマネージドK8sを選ぶ」です。
理由はシンプルです。K8s自体の機能差はわずかですが、周辺サービスとの統合（ロードバランサー、ストレージ、IAM、監視、ログ、ネットワーク）はベンダー固有です。AWSをメインで使っている組織がGKEを選ぶと、VPCピアリングの設定、IAMの二重管理、ログの集約先の分散——K8sとは無関係な複雑さが生まれます。
VMの世界で例えるなら、「ストレージがNetAppならNetApp上でVMを動かすのが一番スムーズ」という判断と同じです。技術的な優劣ではなく、運用の一貫性を優先する判断です。
どのクラウドも使っていないなら、以下の観点で選びましょう。
- チームの既存スキル: AWSの経験者が多いならEKS、Azureの認定資格があるならAKS
- 運用負荷の許容度: 運用負荷を最小限にしたいならGKE Autopilot
- コスト: AKSはコントロールプレーンが無料。ノードのコストはどのサービスも同程度
- 既存のサービスとの統合: Active Directoryとの連携が必要ならAKS、BigQueryとの連携が必要ならGKE
10.3.3 マネージドK8sで変わること・変わらないこと
マネージドK8sに移行して変わることを整理します。
提供されるもの（自分で管理する必要がなくなるもの）:
- コントロールプレーン（API Server、etcd、Scheduler、Controller Manager）の構築・運用・可用性確保
- K8sのバージョンアップグレード（クリック1つ、あるいはIaCの値変更で実行）
- ノードの自動修復（異常検知 → 自動置き換え）
- クラウドサービスとのネイティブ統合（LoadBalancer、StorageClass、IAM）
変わらないもの（自分で設計・管理し続けるもの）:
- Namespace設計、RBAC設計、NetworkPolicy設計——本シリーズで学んだ設計スキルのすべて
- マニフェストの作成とHelmによるパッケージ管理
- Probe設計、HPA設計、PDB設計——アプリケーションの可用性設計
- 障害対応の切り分けフローと思考フレーム
- 設計書・手順書・報告書の作成——ドキュメンテーション文化
マネージドK8sは「クラスタの管理」を委譲するサービスであり、「クラスタの上の設計・運用」を委譲するサービスではありません。本シリーズで身につけたスキルは、マネージドK8sで運用する場合にもそのまま求められます。
10.4 GitOpsという次のステップ
10.4.1 手動applyからGitOpsへ — 「Gitが真実の源泉」
本シリーズでは、マニフェストの適用をkubectl apply -fやhelm install / helm upgradeで行いました。第8回で確立した変更管理フロー——dry-run → diff → apply → 検証 → rollback判断——は正しいプロセスです。
しかし、本番環境で複数のエンジニアがこのフローを手動で実行し続けると、問題が生じます。「誰がいつ何を変更したか」の追跡が難しくなり、「クラスタ上の実態」と「設計書の内容」が乖離するリスクが高まります。
GitOpsは、この課題を解決するアプローチです。考え方はシンプルで、「Gitリポジトリに格納されたマニフェスト（あるいはHelmのvalues.yaml）が唯一の真実の源泉（Single Source of Truth）である」と定義し、Gitリポジトリの内容をクラスタに自動的に反映する仕組みを構築します。
| 現在のワークフロー（手動） | GitOpsワークフロー | |
|---|---|---|
| 変更の起点 | エンジニアがkubectlを実行 | GitリポジトリへのPush / マージ |
| 適用の方法 | kubectl apply / helm upgrade | GitOpsツールが自動検知・自動適用 |
| 変更履歴 | helm history / 手動記録 | Gitのコミットログ = 変更履歴 |
| ロールバック | helm rollback | Gitのrevert / 前のコミットに戻す |
| 「真実の源泉」 | クラスタ上の実態 | Gitリポジトリの内容 |
VMの世界で例えるなら、手動でのkubectl applyは「vSphere ClientでVMの設定を直接変更する」運用に相当します。GitOpsは「すべての変更をAnsibleのPlaybookとして管理し、Gitで変更履歴を追跡する」運用に相当します。後者のほうが追跡可能性と再現性が高いのは、VMの世界でも同じです。
10.4.2 ArgoCD / Fluxの概要
GitOpsを実現するツールとして、ArgoCDとFluxが広く使われています。
ArgoCDはWebベースのUIを持つGitOpsツールです。Gitリポジトリとクラスタの状態を比較し、差分をUIで確認できます。「クラスタの現在の状態」と「Gitの定義」の差異を視覚的に把握できるため、初めてGitOpsを導入するチームにとって取り組みやすいツールです。
FluxはCLIベースのGitOpsツールです。K8sのカスタムリソースとして動作し、K8sネイティブな設計思想が特徴です。Helmチャートやkustomizeとの統合が深く、既存のHelm運用フローからの移行がスムーズです。
どちらを選ぶかは、チームの好みとスキルセットに依存します。本回では詳細な設定手順には踏み込みません。重要なのは「GitOpsという概念を知っていること」と「次の学習対象としてリストに入れること」です。
10.4.3 本シリーズのスキルがGitOpsの基盤になる
GitOpsを導入するには、前提条件があります。
- Gitリポジトリに格納するマニフェストが「正しい状態」で存在すること
- マニフェストの構造とパラメータを設計根拠とともに理解していること
- Helmチャートが整理されており、values.yamlで環境差分を管理できること
これらはすべて、本シリーズで身につけたスキルです。実践編第3回の詳細設計書でマニフェストのパラメータを根拠を持って定め、第8回でHelmチャートを完成させ、values.yamlによる環境差分管理を実践しました。GitOpsは「マニフェストの自動適用」を実現する仕組みですが、適用するマニフェストの品質が低ければ意味がありません。
GitOpsの「Git」の部分はGitの操作スキル、「Ops」の部分はK8sの運用スキルです。あなたは後者をすでに持っています。
10.5 組織への導入戦略
10.5.1 スモールスタート — まず1つのワークロードから
組織にK8sを導入する際、最もよくある失敗は「全システムの移行計画を一度に立てようとすること」です。
VMの世界でもそうだったはずです。物理サーバーからvSphereへの移行は、まず開発用のWebサーバーを1台仮想化し、問題がないことを確認してから、次のサーバーに進む。一気に全台を仮想化しようとした組織は、必ずどこかで問題を起こしました。
K8sでも同じです。まず1つの非本番ワークロード——社内ツール、開発環境のAPIサーバー、ステージング環境のフロントエンドなど——をK8sに載せてみてください。その過程で「Dockerイメージのビルドフロー」「マニフェストの管理方法」「監視の設定」「チームのオペレーション」の課題が見えてきます。その課題を1つずつ解決してから、次のワークロードに進む。
本シリーズのTaskBoardは、この「最初の1つのワークロード」のプロセスを疑似体験したものです。構成図を描き、設計書を書き、構築し、運用設計を整え、障害対応まで一周した。このプロセスをそのまま社内の実ワークロードに適用できます。
10.5.2 VMとK8sの共存 — 適材適所の判断基準
全30回を通じて「VMではこうでしたよね」「K8sではこう解決します」と対比してきましたが、最終回でお伝えしたいのは「全部をK8sに移行する必要はない」ということです。
K8sに向いているワークロードと、VMに残すほうが合理的なワークロードがあります。
| K8sに向くワークロード | VMに残すほうが合理的なワークロード | |
|---|---|---|
| アーキテクチャ | ステートレスなWebアプリ、REST API、マイクロサービス | モノリシックなレガシーアプリ、GUIベースのアプリ |
| スケーリング | 水平スケーリングが有効（Web層、API層） | 垂直スケーリングが必要（大規模DB、ERP） |
| デプロイ頻度 | 頻繁にデプロイする（週1回以上） | 年に数回しか変更しない |
| 依存関係 | コンテナ化が容易（Linuxベース、標準的なミドルウェア） | 特定のOS機能やハードウェアに依存（GPUパススルー、USB接続など） |
| チームスキル | コンテナとK8sの知識がある（あるいは学ぶ意欲がある） | 既存のVM運用ノウハウが成熟している |
本番環境では、VMで運用するワークロードとK8sで運用するワークロードが混在するのが現実的な姿です。K8sはVM基盤を置き換えるものではなく、ワークロードの特性に応じて使い分けるツールの1つです。VMの世界で培った設計力・運用力は、K8sの世界でもそのまま活きます。それは全30回を通じて実感したはずです。
10.5.3 チーム育成とナレッジ共有
K8sの導入は技術の問題であると同時に、人の問題です。
本シリーズで作成した成果物——構成図、基本設計書、詳細設計書、運用設計書、変更管理手順書、障害対応手順書——は、チーム内のナレッジ共有に直接活用できます。TaskBoardの具体的な設定値を自社のシステムに読み替えれば、そのまま社内の設計書テンプレートになります。
チーム育成の進め方として、以下のステップが現実的です。
- まず自分がスキルを示す: 本シリーズで学んだ知識を活かし、実際にワークロードをK8sに載せてみせる
- 成果物を共有する: 設計書と手順書をテンプレートとしてチームに展開する
- 学習パスを提示する: 本シリーズの入門編→応用編→実践編の順序は、そのままチームメンバーの学習パスに使える
- 勉強会を主催する: 週1回30分でも、TaskBoardの構築を一緒にやるだけで効果がある
10.6 障害対応手順書の差分整理（ハンズオン）
エピローグとしてのハンズオンは、軽量なものにとどめます。第9回で作成した障害対応手順書を手元に開き、「マネージドK8s環境に移行した場合に何が変わるか」を整理する作業です。
10.6.1 第9回の障害対応手順書を開く
第9回で作成した障害対応手順書を手元に用意してください。6つの障害シナリオとそれぞれの対応手順が記載されているはずです。
[Execution User: developer]
# 第9回の成果物ディレクトリに移動
cd ~/k8s-production/09-incident-response/
# 障害対応手順書を確認
ls -l incident-response-*.mdこれから、各シナリオについて「マネージドK8sではどう変わるか」を差分として整理します。
10.6.2 マネージドK8s環境での差分を整理する
6つの障害シナリオについて、kind環境での対応と、マネージドK8sでの変化を表にまとめます。
| シナリオ | kind環境での対応 | マネージドK8sでの変化 |
|---|---|---|
| 1. CrashLoopBackOff | kubectl describe / logsで切り分け。イメージタグ修正 | 変わらない。Pod層の障害対応は同じ |
| 2. OOMKilled | describe podでOOMKilled確認。limits.memory修正 | 変わらない。resources設計の考え方は同じ |
| 3. Node障害 | docker stopでNode停止。docker startで復旧 | 検知手段が変わる。クラウドの監視アラートで検知。ノードの自動修復があるが、Pod退去の挙動（PDB含む）は同じ |
| 4. NW障害 | NetworkPolicyのラベルセレクタ修正 | 変わらない。NetworkPolicyの設定方法はCNIが異なっても同じ |
| 5. ストレージ障害 | PVC設定修正（StorageClass名修正） | ストレージの冗長性が向上。クラウドストレージは基盤レベルで冗長化されている。ただしPVC設計の考え方は同じ |
| 6. 設定ミス | ConfigMap修正 + rollout restart | 変わらない。設定変更の反映フローは同じ |
10.6.3 「変わるもの」と「変わらないもの」を確認する
表を整理してみると、6シナリオのうち大半は「変わらない」です。
CrashLoopBackOff、OOMKilled、NW障害、設定ミスの4シナリオは、対応手順がそのまま使えます。Node障害とストレージ障害は「プラットフォーム層のサポートが厚くなる」という変化はありますが、切り分けの思考フレーム自体は変わりません。
これが、kindで学んだことの本番への移植性の証明です。kindは学習環境ですが、kindの上で身につけた設計力と障害対応力は、本番環境でもそのまま通用します。プラットフォームが変わっても、K8sのAPI仕様と設計思想は同じだからです。
この差分表を、本番環境への移行計画の出発点として活用してください。
10.7 シリーズ全体の振り返り
10.7.1 入門編 — 「K8sの基本を知る」（全11回）
入門編では、Pod、Deployment、Service（ClusterIP / NodePort）、ConfigMap、Secret、PVC、resourcesというK8sの基本リソースを学びました。kubectl get / describe / logs / execの「4種の神器」でトラブルシュートの初動ができるようになり、K8sの世界に足を踏み入れました。題材はNginx単体。1つのPodを動かすところから始まった旅路です。
10.7.2 応用編 — 「武器を一つずつ手に入れる」（全9回）
応用編では、本番で必要な武器を1つずつ習得しました。Namespace分離とResourceQuota、RBACによるアクセス制御、StatefulSetによるDB運用、DaemonSet / Job / CronJobによる多様なワークロード、Gateway APIによるL7ルーティング、NetworkPolicyによるPod間通信制御、SecurityContextによるコンテナ権限制限、HPAとProbeによる自動スケーリングとヘルスチェック、Helmによるパッケージ管理。TaskBoardに部品を1つずつ追加し、応用編の修了時には全構成が動いている状態になりました。
10.7.3 実践編 — 「プロのプロセスでライフサイクルを回す」（全10回）
実践編では、同じTaskBoardを「白紙から」設計し直しました。構成図を描き（第1回）、基本設計書を書き（第2回）、詳細設計書で全パラメータに根拠を与え（第3回）、基盤を整備し（第4回）、アプリケーションを段階デプロイし（第5回）、ネットワークを構築してE2Eテストを実施し（第6回）、運用設計書を仕上げ（第7回）、Helmで変更管理の実務を確立し（第8回）、障害対応で6つのシナリオを乗り越え（第9回）、本番への道標を整理しました（本回）。設計→構築→運用→障害対応というライフサイクルを一周回した体験です。
10.7.4 あなたが手にしたもの — スキルと成果物の棚卸し
全30回を走破した結果、あなたが手にしたスキルを整理します。
| カテゴリ | 具体的にできること |
|---|---|
| 設計 | K8s構成図を描ける。基本設計書・詳細設計書を書ける。ワークロード・リソースの選定判断を根拠とともに説明できる |
| 構築 | アプリのコンテナイメージをビルドし、マルチノードクラスタ上で設計書に基づく段階的デプロイを実行・検証できる |
| 運用 | 監視・スケーリング・デプロイ戦略・バックアップの運用設計書を書ける。Helmで変更管理ができる |
| 障害対応 | Pod / Node / NW / Storage障害を体系的に切り分け、復旧し、報告書と再発防止策を書ける |
| 判断力 | 初めて見るK8sリソースでも、K8sの設計思想から推論して理解できる |
| AI活用 | AIを道具として活用し、出力を批判的に検証できる |
そして、実践編で作成した成果物は、そのまま実務で流用できます。
| 成果物 | 作成回 | 実務での流用 |
|---|---|---|
| K8s構成図（3階層） | 第1回 | 社内設計書のテンプレートに |
| 基本設計書 | 第2回 | プロジェクトの基本設計に流用 |
| 詳細設計書（パラメータ設計書 + 全マニフェスト） | 第3回 | 構築・変更管理の基盤 |
| 基盤整備チェックリスト | 第4回 | 新規クラスタ構築時のチェックに |
| 構築手順書 | 第5回 | 段階デプロイの手順書テンプレート |
| E2Eテスト結果報告 | 第6回 | 結合テストのレポートテンプレート |
| 運用設計書 | 第7回 | 監視・スケーリング・デプロイ戦略の雛形 |
| 変更管理手順書 + 完成版Helmチャート | 第8回 | 日常運用のベースライン |
| 障害対応手順書 + 障害報告書テンプレート | 第9回 | 障害対応フローに直接適用 |
10.8 おわりに — 「K8sでシステムを回せるエンジニア」として
10.8.1 VMの知識が支えてくれたこと
全30回を通じて、「VMではこうでしたよね」という表現を何度も使いました。vSphereのリソースプールとK8sのResourceQuota、vCenterのアクセス権限とRBAC、データストアとPersistentVolume、F5 BIG-IPのVirtual ServerとGateway API、分散スイッチのポートグループとNetworkPolicy——VMの世界で培った知識が、K8sの概念を理解するための「足場」になったはずです。
これは偶然ではありません。VMもK8sも「コンピューティングリソースを抽象化して管理する」基盤であり、直面する課題——リソース管理、アクセス制御、ネットワーク制御、可用性確保、障害対応——は共通しています。解決手段の形は変わりますが、設計の思考フレームは共通です。
VMで培った知識は無駄にはなりません。むしろ、K8sの世界に来てからも支え続けてくれます。
10.8.2 次のステップロードマップ
シリーズ完走後に進むべき方向を、時間軸で整理します。
次のステップロードマップ
【すぐにできること】
□ 社内の非本番ワークロードをK8sに載せてみる
□ 実践編の成果物をテンプレートとして社内に共有する
□ マネージドK8sの無料枠/トライアルでクラスタを作ってみる
【3ヶ月以内にできること】
□ マネージドK8sでTaskBoard相当の構成を構築してみる
□ GitOps（ArgoCD or Flux）を試してみる
□ Prometheus + Grafanaで監視基盤を構築してみる
【半年〜1年のスパンで取り組むこと】
□ 本番ワークロードのK8s移行を計画する
□ CI/CDパイプラインを構築する
□ チーム内のK8s勉強会を主催するすべてを一度にやる必要はありません。「すぐにできること」から始めて、成果が出たら次のステップに進む。kindで学んだときと同じように、一歩ずつ進めてください。
10.8.3 読者へのメッセージ
入門編の第1回で、初めてPodを起動しました。kubectl get podsでRunningと表示されたとき、K8sの世界に最初の一歩を踏み出しました。
そこから30回。Deployment、Service、ConfigMap、Secret、PVC。Namespace、RBAC、StatefulSet、DaemonSet、Job、CronJob。Gateway API、NetworkPolicy、SecurityContext、HPA、Probe、Helm。構成図、基本設計書、詳細設計書、構築手順書、運用設計書、変更管理手順書、障害対応手順書、障害報告書。
手を動かし、壊し、直し、設計し、書き、また壊し、また直した。
このシリーズで身につけたのは、特定の技術の知識だけではありません。設計・構築・運用・障害対応という「プロの仕事の仕方」です。構成図を描く力、設計判断を文書として残す力、手順に沿って確実に構築する力、障害を体系的に切り分けて復旧する力。これらは、K8sのバージョンが上がっても、新しいリソースが追加されても、変わりません。
次の現場で、あなたはすでに「K8sでシステムを回せるエンジニア」です。まずは1つのワークロードから。次のステップに踏み出してください。
AIコラム — 移行計画の壁打ち
全10回のAIコラム、最終回は「移行計画の壁打ち」です。
組織への K8s導入を検討する段階では、「何から手を付けるべきか」を整理する必要があります。自社のワークロード一覧を前にして、どれをK8sに移行すべきか、どの順番で進めるべきか——この判断にAIを活用できます。
たとえば、以下のようなプロンプトが出発点になります。
💬 プロンプト例:
以下のVMベースのWebアプリケーション群をK8sに移行したい。移行の優先順位と注意点を教えてください。
1. 社内ポータル（PHP + Apache、アクセス数：50人/日、更新頻度：月1回）
2. 顧客向けAPI（Java Spring Boot、アクセス数：10,000req/日、更新頻度：週2回）
3. 基幹DB（Oracle 19c、データ量：500GB、SLA 99.99%）
4. バッチ処理基盤（Python スクリプト群、夜間に10ジョブ実行）
制約条件：チーム5名、K8s経験者は私1名、AWS利用中
AIは一般論としての優先順位（ステートレスなAPI→バッチ処理→社内ポータル→基幹DBの順）と、各ワークロードの移行時の注意点を提示してくれるでしょう。しかし、「チームの5名のうち3名がAWSに詳しいので、EKS前提で進めたい」「基幹DBのOracleライセンスが来年更新で、この機会にPostgreSQLに移行する案もある」といった社内事情は、AIには伝えない限り考慮されません。
AIの提案をたたき台にして、自社の制約条件（予算、チームスキル、既存インフラ、ビジネス優先度）に照らして判断する。これが、シリーズ全体を通じて一貫して伝えてきたAI活用の姿勢です。
振り返ると、実践編のAI活用は次の一貫した流れで進みました。
- 第1回（構成図）: Mermaid構成図のドラフト生成
- 第2回（基本設計）: 設計方針の壁打ち
- 第3回（詳細設計）: マニフェストのドラフト生成 → 批判的レビュー
- 第4回（環境構築）: 手順のダブルチェック
- 第5回（アプリ構築）: 適用順序の相談
- 第6回（NW構築）: Gateway API / NetworkPolicy設定の生成
- 第7回（運用設計）: 運用設計書のドラフト
- 第8回（日常運用）: Helm化の相談、values.yaml設計
- 第9回（障害対応）: エラーメッセージの分析・切り分け補助
- 第10回（本回）: 移行計画の壁打ち
すべてに共通するのは「AIにドラフトを生成させ、自分の知識と環境に照らして検証・修正する」というサイクルです。AIは優秀なアシスタントですが、あなたの環境を知っているのはあなただけです。最終判断は常に、設計書と実データを持つエンジニア自身が下す——この姿勢を、次の現場でも持ち続けてください。
