kubectl デプロイ（くべくてるでぷろい）

2025年11月17日

kubectl デプロイ（くべくてるでぷろい）

英語表記: kubectl Deployments

概要

kubectl デプロイとは、コンテナオーケストレーションシステムであるKubernetesに対し、アプリケーションの実行方法や管理方法を指示するための中心的な操作です。これは、私たちがDockerやPodmanで作成・準備したコンテナイメージを、実際にクラスター上で安定稼働させるための「最終指示書」を適用するプロセスだと理解してください。具体的には、Kubernetesの管理ツールであるkubectlコマンドを用いて、Deployment（デプロイメント）と呼ばれるリソースを作成・更新・管理することを指します。この操作は、「イメージビルドとデプロイ」という一連の流れの、まさにデプロイ部分を担う非常に重要なステップなのです。

詳細解説

デプロイの目的と位置づけ

この概念を理解するためには、まず私たちが今いる階層、コンテナ技術（Docker, Podman） → Docker と Kubernetes の連携 → イメージビルドとデプロイ、を意識することが大切です。

DockerやPodmanを使ってアプリケーションをコンテナイメージとしてパッケージ化する作業（イメージビルド）は、美味しい料理を作るための「材料の準備」に例えられます。しかし、その料理を大勢のお客様に提供し、常に温かい状態を保ち、もし焦げ付いたら自動で入れ替える、といった「レストランの運営管理」を行うのがKubernetesの役割です。

kubectl デプロイは、この運営管理をKubernetesに任せるための命令です。デプロイメントリソースは、以下の目的を達成するために利用されます。

安定稼働の保証（Desired Stateの維持）: アプリケーションのコンテナを「常に3つ動かしておきたい」といった目的の状態（Desired State）を定義します。もしコンテナがクラッシュしても、Kubernetesが自動的に再起動させ、定義された状態を維持してくれます。
自動化された更新（ローリングアップデート）: アプリケーションに新しいバージョンを適用する際、古いバージョンを停止してから新しいものを起動するのではなく、サービスを中断させずに少しずつ入れ替える安全な更新方法（ローリングアップデート）を自動で実行します。
スケーリングの管理: アクセスが増加した際に、手動でコンテナの数を増やすのではなく、デプロイメントの設定を変更するだけで瞬時にスケールアウト（拡張）が可能になります。

動作の仕組み：Deploymentリソースの役割

kubectl デプロイの核心は、Deploymentリソースを操作することにあります。このリソースは、Kubernetesクラスター内で実行されるPod（コンテナの最小実行単位）の集合を管理する上位概念です。

Deploymentリソースを定義する際には、YAML形式の設定ファイルを使用するのが一般的です。このファイルには、どのコンテナイメージを使うのか（Dockerでビルドした成果物）、いくつのPodを起動するのか、どのように更新するのか、といった詳細が宣言的に記述されます。

処理の流れは以下の通りです。

宣言: 技術者はYAMLファイルに目的の状態を記述し、kubectl apply -f deployment.yamlを実行します。これは「この設計図通りに動かしてね」という宣言です。
中間管理: デプロイメントは、直接Podを管理するのではなく、ReplicaSet（レプリカセット）という中間リソースを作成・管理します。ReplicaSetは、指定された数のPodが常に実行されていることを監視する責任を負います。
実行: ReplicaSetの指示に基づき、Kubernetesのマスターノード（特にコントローラーマネージャー）がワーカーノードに対し、コンテナイメージをプル（取得）し、Podとしてアプリケーションを実行するよう指示します。

このように、私たちは具体的なPodの起動・停止といった煩雑な作業を意識することなく、kubectl デプロイを通じて「目的の状態」だけをKubernetesに伝えるだけで済むのです。これは、イメージビルド後のデプロイ作業を劇的に簡素化し、信頼性を高める素晴らしい仕組みだと感じます。

具体例・活用シーン

1. ローリングアップデートの実行

私たちがWebサービスを運用していて、バグ修正を含む新しいバージョンのコンテナイメージ（例: myapp:v2.0）をリリースしたいとします。

従来のデプロイ: サービスを停止し、古いサーバーを落とし、新しいサーバーを立ち上げる必要がありました。
kubectl デプロイ: デプロイメントのYAMLファイル内のイメージタグをv1.0からv2.0に書き換え、再度kubectl applyを実行します。

Kubernetesは、サービスを停止することなく、ゆっくりと新しいPod（v2.0）を立ち上げ、正常に動作することを確認してから古いPod（v1.0）を落とします。この自動的で段階的な切り替えこそが、kubectl デプロイが「イメージビルドとデプロイ」の文脈で極めて重要とされる理由です。

2. 例え話：自動運転タクシーの配車システム

kubectl デプロイを理解するための比喩として、「自動運転タクシーの配車システム」を考えてみましょう。

あなたはタクシー会社のオーナーで、自分のアプリケーションを「タクシー」として利用者に提供したいと考えています。

Dockerイメージビルド: これは、タクシーのボディ、エンジン、内装など、タクシーそのもの（アプリケーション）を設計し組み立てる作業です。
kubectl デプロイ: これは、配車システムに「常に都心部に5台のタクシーを待機させなさい。もし故障したタクシーが出たら、すぐに新しいタクシーを自動で補充しなさい」と命令する行為です。

デプロイメントファイルは、この配車システムの運用マニュアルにあたります。あなたが「タクシーの台数を5台から10台に増やしたい」とマニュアルを書き換えてシステムに適用する（kubectl apply）だけで、システムは自動で残りの5台を用意し、管理を始めます。オーナー（開発者）は、個々のタクシー（Pod）を気にすることなく、全体の台数と状態（Desired State）だけを管理できる、というわけです。

3. スケーリングへの対応

年末商戦やテレビCMによる一時的なアクセス増加が予想される場合、kubectl scaleコマンドを使って、デプロイメントが管理するPodの数を一時的に増やすことができます。アクセスが落ち着いたら、再び元の数に戻すのも簡単です。この柔軟性と迅速な対応能力は、現代のWebサービス運用において不可欠な要素となっています。