こんにちは。今回は Kubernetes における Canary リリースのラベル設計と Service 設定のポイント について、実践的な観点から解説します。
🚀 はじめに：Canary リリースとは？
Canary リリースとは、本番環境において一部のトラフィックだけを新しいバージョンのアプリケーションに流し、段階的に切り替えていくデプロイ手法です。
Kubernetes では、Deployment とラベル、Service の組み合わせによってこの仕組みを実現できます。
🧩 Step 1：既存の Deployment に version=v1 を追加
まず、今動いている Deployment（例：my-app）に以下のようなラベルを追加します。
spec.selector.matchLabelsspec.template.metadata.labels
両方に version: v1 を明示的に追加しましょう。
（※metadata.labels は任意ですが、selector と template は一致している必要があります）
例：
selector:
matchLabels:
app: my-app
version: v1
template:
metadata:
labels:
app: my-app
version: v1
この状態で Service がすでに存在している場合は、Pod と Service のマッピングが崩れないように注意が必要です。
🧩 Step 2：v1 を expose（Service を設定）
Service の spec.selector を以下のように設定します：
selector:
app: my-app
❗ここがポイント：
versionラベルは Service の selector に入れないこと！
なぜなら、Canary 用の v2 Pod（後で出てきます）も app: my-app を共有することで、トラフィックを分岐できるからです。
🧪 Step 3：新しい Deployment（v2）を作成
次に、Canary 用の新しい Deployment を作ります。
ここでは version: v2 というラベルを付けて、新しい Pod を別に起動します。
例：
selector:
matchLabels:
app: my-app
version: v2
template:
metadata:
labels:
app: my-app
version: v2
この状態で、v1 Pod と v2 Pod の両方が同時に存在します。
Service は app: my-app というラベルにマッチするすべての Pod にトラフィックを分配するので、v1 と v2 に並行してトラフィックが届く構成になります。
✅ 補足：ラベル整理の要点
| ラベルの種類 | どこに使うか | 設定値 | 説明 |
|---|---|---|---|
metadata.labels |
Deployment 自身の識別 | 任意（不要でもOK） | デプロイ名表示など |
selector.matchLabels |
対象 Pod のラベルを指定 |
app, version など |
Service や ReplicaSet に重要 |
template.metadata.labels |
実際の Pod に付けるラベル |
app, version など |
Service の selector とマッチする必要あり |
🎯 おわりに
Canary デプロイを Kubernetes で構成する際に重要なのは、
ラベルと selector の設計を明確に分けて考えることです。
- Deployment の selector と Pod のラベルは必ず一致させる
- Service の selector には version を入れない（すべてのバージョンに流したいから）
- バージョンごとにラベル（例：
version: v1,version: v2）で区別する
このように設計すれば、トラフィックの分岐やロールバックも柔軟にコントロールできます！
Canary リリースを使いこなして、より安全な本番運用を目指しましょう 😄
ご質問やコメントはお気軽にどうぞ！