こんにちは。今回は Kubernetes における Canary リリースのラベル設計と Service 設定のポイント について、実践的な観点から解説します。

🚀 はじめに：Canary リリースとは？

Canary リリースとは、本番環境において一部のトラフィックだけを新しいバージョンのアプリケーションに流し、段階的に切り替えていくデプロイ手法です。
Kubernetes では、Deployment とラベル、Service の組み合わせによってこの仕組みを実現できます。

🧩 Step 1：既存の Deployment に `version=v1` を追加

まず、今動いている Deployment（例：my-app）に以下のようなラベルを追加します。

両方に version: v1 を明示的に追加しましょう。

（※metadata.labels は任意ですが、selector と template は一致している必要があります）

例：

selector:
  matchLabels:
    app: my-app
    version: v1
template:
  metadata:
    labels:
      app: my-app
      version: v1

この状態で Service がすでに存在している場合は、Pod と Service のマッピングが崩れないように注意が必要です。

Service の spec.selector を以下のように設定します：

selector:
  app: my-app

❗ここがポイント：
version ラベルは Service の selector に入れないこと！

なぜなら、Canary 用の v2 Pod（後で出てきます）も app: my-app を共有することで、トラフィックを分岐できるからです。

次に、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 の設計を明確に分けて考えることです。

このように設計すれば、トラフィックの分岐やロールバックも柔軟にコントロールできます！

Canary リリースを使いこなして、より安全な本番運用を目指しましょう 😄
ご質問やコメントはお気軽にどうぞ！