トラフィック管理

Knativeサービスの異なるRevisionへのトラフィックルーティングは、Serviceリソースのtraffic仕様を変更することで管理できます。

Knativeサービスを作成すると、デフォルトのtraffic仕様設定はありません。traffic仕様を設定することで、任意の数の固定Revisionにトラフィックを分割したり、Serviceの仕様でlatestRevision: trueを設定することで、最新のRevisionにトラフィックを送信できます。

タグを使用してターゲットURLを作成する

次の例では、仕様でtagという属性が定義されています。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
...
  traffic:
  - percent: 0
    revisionName: example-service-1
    tag: staging
  - percent: 40
    revisionName: example-service-2
  - percent: 60
    revisionName: example-service-3

tag属性がRouteに適用されると、特定のトラフィックターゲットのアドレスが作成されます。

この例では、staging-<route name>.<namespace>.<domain>にアクセスすることで、ステージングターゲットにアクセスできます。example-service-2とexample-service-3のターゲットには、メインルート<route name>.<namespace>.<domain>を使用してのみアクセスできます。

トラフィックターゲットにタグが付けられると、そのサービス用の新しいKubernetesサービスが作成され、他のサービスがクラスタ内でアクセスできるようになります。前の例では、staging-<route name>という新しいKubernetesサービスが同じ名前空間に作成されます。このサービスは、値cluster-localでラベルnetworking.knative.dev/visibilityを適用することで、この特定のRouteの可視性をオーバーライドできます。プライベートサービスに関するドキュメントで、特定のRouteの可視性を制限する方法の詳細を確認してください。

トラフィックルーティングの例

次の例は、トラフィックの100％がサービスのlatestRevisionにルーティングされるtraffic仕様を示しています。statusの下に、latestRevisionが解決された最新のRevisionの名前が表示されます。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
...
  traffic:
  - latestRevision: true
    percent: 100
status:
  ...
  traffic:
  - percent: 100
    revisionName: example-service-1

次の例は、トラフィックの100％がcurrentRevisionにルーティングされ、そのRevisionの名前がexample-service-1として指定されているtraffic仕様を示しています。最新のレディRevisionは、トラフィックがルーティングされていなくても利用可能なままです。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
...
  traffic:
  - tag: current
    revisionName: example-service-1
    percent: 100
  - tag: latest
    latestRevision: true
    percent: 0

次の例は、traffic仕様のRevisionリストを拡張して、トラフィックを複数のRevisionに分割する方法を示しています。この例では、トラフィックの50％をcurrentRevisionのexample-service-1に、50％をcandidateRevisionのexample-service-2に送信します。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
...
  traffic:
  - tag: current
    revisionName: example-service-1
    percent: 50
  - tag: candidate
    revisionName: example-service-2
    percent: 50
  - tag: latest
    latestRevision: true
    percent: 0

Knative CLIを使用したトラフィックのルーティングと管理

次のkn CLIコマンドを使用して、Revision間のトラフィックを分割できます。

kn service update <service-name> --traffic <revision-name>=<percent>

ここで

• <service-name>は、トラフィックルーティングを設定するKnativeサービスの名前です。
• <revision-name>は、トラフィックの割合を受け取るように設定するRevisionの名前です。
• <percent>は、<revision-name>で指定されたRevisionに送信するトラフィックの割合です。

たとえば、exampleという名前のサービスのトラフィックを、トラフィックの80％をRevisiongreenに、20％をRevisionblueに送信することで分割するには、次のコマンドを実行できます。

kn service update example-service --traffic green=80 --traffic blue=20

Revisionにタグを追加し、設定したタグに従ってトラフィックを分割することも可能です。

kn service update example --tag revision-0001=green --tag @latest=blue

@latestタグは、blueがサービスの最新のRevisionに解決されることを意味します。次の例では、トラフィックの80％を最新のRevisionに、20％をv1という名前のRevisionに送信します。

kn service update example-service --traffic @latest=80 --traffic v1=20

青/緑のデプロイメントを使用したトラフィックのルーティングと管理

青/緑のデプロイメント戦略を使用することで、アプリケーションのライブバージョンから新しいバージョンへのトラフィックの安全なリルーティングを行うことができます。

手順

1. Knativeサービスとしてアプリを作成してデプロイします。

2. 次のコマンドを実行して、サービスをデプロイしたときに作成された最初のRevisionの名前を見つけます。

   kubectl get configurations <service-name> -o=jsonpath='{.status.latestCreatedRevisionName}'
   

   ここで、<service-name>はデプロイしたサービスの名前です。

3. Revisionにインバウンドトラフィックを送信するRouteを定義します。

   Routeの例

   apiVersion: serving.knative.dev/v1
   kind: Route
   metadata:
     name: <route-name>
     namespace: default
   spec:
     traffic:
       - revisionName: <first-revision-name>
         percent: 100 # All traffic goes to this revision
   

   ここで;

   • <route-name>は、Routeに選択した名前です。
   • <first-revision-name>は、前のステップの最初のRevisionの名前です。

4. 次のコマンドを使用して取得したURLでアプリを表示できることを確認します。

   kubectl get route <route-name>
   

   ここで、<route-name>は前のステップで作成したRouteの名前です。

5. サービスリソースのtemplate仕様の少なくとも1つのフィールドを変更することで、アプリの2番目のRevisionをデプロイします。たとえば、サービスのimageまたはenv環境変数を変更できます。

6. サービスYAMLファイルを使用するか、kn CLIをインストールしている場合はkn service updateコマンドを使用して、更新されたサービスリソースを適用することでサービスを再デプロイします。

7. サービスを再デプロイしたときに作成された2番目の最新のRevisionの名前は、次のコマンドを実行して見つけることができます。

   kubectl get configurations <service-name> -o=jsonpath='{.status.latestCreatedRevisionName}'
   

   ここで、<service-name>は再デプロイしたサービスの名前です。

   この時点で、サービスの最初のRevisionと2番目のRevisionの両方がデプロイされ、実行されています。

8. 既存のRouteを更新して、他のトラフィックはすべて最初のRevisionに送信したまま、2番目のRevisionに対して新しいテストエンドポイントを作成します。

   更新されたRouteの例

   apiVersion: serving.knative.dev/v1
   kind: Route
   metadata:
     name: <route-name>
     namespace: default
   spec:
     traffic:
       - revisionName: <first-revision-name>
         percent: 100 # All traffic is still being routed to the first revision
       - revisionName: <second-revision-name>
         percent: 0 # 0% of traffic routed to the second revision
         tag: v2 # A named route
   

   このRouteをYAMLリソースを再適用することで再デプロイすると、アプリの2番目のRevisionがステージングされます。

   メインURLには2番目のRevisionへのトラフィックはルーティングされず、Knativeは新しくデプロイされたRevisionをテストするためのv2という名前の新しいRouteを作成します。

9. 次のコマンドを実行して、2番目のRevisionの新しいRouteのURLを取得します。

   kubectl get route <route-name> --output jsonpath="{.status.traffic[*].url}"
   

   このURLを使用して、トラフィックをルーティングする前に、アプリの新しいバージョンが期待通りに動作していることを検証できます。

10. 既存のRouteリソースを再度更新して、トラフィックの50％を最初のRevisionに、50％を2番目のRevisionに送信します。

    更新されたRouteの例

    apiVersion: serving.knative.dev/v1
    kind: Route
    metadata:
      name: <route-name>
      namespace: default
    spec:
      traffic:
        - revisionName: <first-revision-name>
          percent: 50
        - revisionName: <second-revision-name>
          percent: 50
          tag: v2
    

11. アプリの新しいバージョンにすべてのトラフィックをルーティングする準備ができたら、ルートを再度更新して、トラフィックの100％を2番目のリビジョンに送信してください。

    更新されたRouteの例

    apiVersion: serving.knative.dev/v1
    kind: Route
    metadata:
      name: <route-name>
      namespace: default
    spec:
      traffic:
        - revisionName: <first-revision-name>
          percent: 0
        - revisionName: <second-revision-name>
          percent: 100
          tag: v2
    

    ヒント

    リビジョンをロールバックする予定がない場合は、トラフィックの0％に設定する代わりに、最初のリビジョンを削除できます。ルーティングできないリビジョンオブジェクトは、その後ガベージコレクションされます。

12. 最初のリビジョンのURLにアクセスして、古いバージョンのアプリにトラフィックが送信されなくなっていることを確認してください。