Linkerd でトラフィック分割を実装する

Linkerd では、カナリア リリースはトラフィック分割を通じて管理されます。これは、動的に構成可能な重みに基づいて、リクエストをさまざまな Kubernetes サービス オブジェクトに分散できる機能です。トラフィック分割は任意のサービス オブジェクトに適用できますが、通常はサービスの着信トラフィックをサービスの異なるバージョンに分割します。

トラフィック分割は、Linkerd の TrafficSplit CRD​ を介して制御されます (TrafficSplit CRD​ は、Linkerd が実装するいくつかの SMI API の 1 つである Service Mesh Interface (SMI) で定義された仕様に準拠しています)。 TrafficSplit CRD を作成すると、TrafficSplit によって参照されるサービスへのトラフィックを Linkerd がプロキシする方法を制御できます。

TrafficSplit CRD​ は、Kubernetes サービス オブジェクトに基づいて記述されています。 TrafficSplit​ は、トラフィックが送信される中央のルート サービスまたは頂点サービスと、 TrafficSplit で指定された重みに比例して実際にトラフィックを受信する 1 つ以上のバックエンド サービスを表します。

また、Kubernetes サービス オブジェクトには必ずしもバックグラウンド ワークロードがあるわけではないことにも注意してください。これは通常のサービスではまれですが、TrafficSplits​ を使用した Apex サービスではこの機能を頻繁に使用します。これは、TrafficSplit​ により、Apex​ 宛てのトラフィックが実際にバックエンド サービスに送信されるため、Apex には実際に独自の Deployment が必要なくなるためです。

アップデートサービス

次に、Emojivoto アプリケーションを例として 2 つの新しい Service オブジェクトを作成します。頂点サービスには関連付けられたデプロイメント リソースはなく、2 番目のサービスは Emojivoto Web サービスの更新バージョンとなり、ページの上部にテキスト情報を追加します。

両方のサービスが作成されたら、Apex サービスに送信されるトラフィックを Web サービスの元のバージョンと更新されたバージョンの間で分割する TrafficSplit​ リソースを作成します。

Web サービス リソース オブジェクトの更新バージョンは次のとおりです。

 # ウェブ- SVC - 2.yaml
 APIバージョン: v1
 種類: サービスアカウント
メタデータ:
 名前: ウェブ- 2
 名前空間: emojivoto
 ---
 APIバージョン: v1
 種類: サービス
メタデータ:
 名前: web - svc - 2
 名前空間: emojivoto
 仕様:
 ポート:
 - 名前: http
 ポート: 80
 ターゲットポート: 8080
 セレクター:
 アプリ: Web - SVC - 2
 タイプ: ClusterIP
 ---
 apiバージョン: アプリ/ v1
 種類: デプロイメント
メタデータ:
 ラベル:
 アプリ。 Kubernetes 。 io / 名前: web - svc - 2
 アプリ。 Kubernetes 。 io / 一部: emojivoto ​
 アプリ。 Kubernetes 。 io / バージョン: Linux - トレーニング- v2
 名前: web - svc - 2
 名前空間: emojivoto
 仕様:
 セレクター:
 マッチラベル:
 アプリ: Web - SVC - 2
 バージョン: Linux - トレーニング- v2
 テンプレート：
 メタデータ:
 注釈:
 linkerd.io/inject:enabled # 自動注入のアノテーションを設定する
ラベル:
 アプリ: Web - SVC - 2
 バージョン: Linux - トレーニング- v2
 仕様:
 コンテナ:
 -env :環境変数
- 名前: WEB_PORT
 値: "8080"
 - 名前: EMOJISVC_HOST
 値: emoji - svc 。 絵文字: 8080
 - 名前: VOTINGSVC_HOST
 値: 投票- svc 。 絵文字: 8080
 - 名前: INDEX_BUNDLE
 値: dist / index_bundle .js
 - 名前: 今日のメッセージ
値: "バージョン 2 へようこそ! 単語数が増えました!"
 画像: buoyantio / emojivoto - ウェブ: lf - トレーニング
名前: web - svc - 2
 ポート:
 - コンテナポート: 8080
 名前: http
 リソース：
 リクエスト:
 CPU : 100m
 サービスアカウント名: web - 2

上記のリソース オブジェクトを直接適用します。

 $ kubectl apply -f web -svc - 2.yaml ​ ​
 サービスアカウント/ ウェブ- 2 作成済み
サービス/ Web - svc - 2 作成
デプロイメント.apps / web - svc - 2 が作成されました

デプロイ後、サービスの更新バージョンが正しくデプロイされていることを確認します。

 $ kubectl get po -- セレクターapp = web - svc - 2 - n emojivoto
 名前準備完了ステータス再起動年齢
web - svc - 2 - f9d77474f - hgsg4 2 / 2 実行中0 10 秒
$ kubectl get svc web - svc - 2 - n emojivoto
 名前タイプクラスタ- IP 外部- IP ポート( S ) 年齢
web - svc - 2 ClusterIP 10.102 .99 .153 <なし> 80 / TCP 3 分45秒

デプロイが成功したら、kubectl port-forward コマンドを使用してサービスを公開することもできます。

 $ kubectl ポート転送 svc/web-svc-2 8080:80 -n emojivoto

同様に、ブラウザの localhost:8080 を介してアプリケーションの新しいバージョンにアクセスすることもできます。

ページの上部を見ると、アプリケーションの新しいバージョンには文字情報の行が追加されていることがわかります。

TrafficSplit の作成

次に、apex​ サービスを作成する必要があります。ここでは web-apex と呼びますが、今回は Pod が実行されておらず、エンドポイントがないため、サービスにリクエストを送信できません。

 # ウェブ- apex.yaml
 APIバージョン: v1
 種類: サービスアカウント
メタデータ:
 名前: ウェブ- apex
 名前空間: emojivoto
 ---
 APIバージョン: v1
 種類: サービス
メタデータ:
 名前: ウェブ- apex
 名前空間: emojivoto
 仕様:
 ポート:
 - 名前: http
 ポート: 80
 セレクター:
 アプリ: ウェブ- apex
 タイプ: ClusterIP

上記のリソース オブジェクトを直接適用します。

 $ kubectl apply -f web -apex .yaml
 サービスアカウント/ ウェブ- Apex が作成されました
サービス/ Web - Apex 作成
$ kubectl get svc - n emojivoto - o ワイド
名前タイプクラスタ- IP 外部- IP ポート( S ) 年齢セレクタ
emoji - svc ClusterIP 10.103 .235 .14 < なし> 8080 / TCP 、 8801 / TCP 8d app = emoji - svc
 投票- svc ClusterIP 10.102 .32 .81 < なし> 8080 / TCP 、 8801 / TCP 8d app = 投票- svc
 web - apex ClusterIP 10.104 .12 .249 < なし> 80 / TCP 84 s app = web - apex
 web - svc ClusterIP 10.106 .220 .250 < なし> 80 / TCP 8 d app = web - svc
 web - svc - 2 ClusterIP 10.102 .99 .153 <なし> 80 / TCP 27 m app = web - svc - 2

上記の出力から、web-apex サービスは他の通常のサービスと同じですが、エンドポイントがないことがわかります。

 $ kubectl get ep - n 絵文字
名前エンドポイント年齢
絵文字- svc 10.244 .1 .228 : 8801 , 10.244 .1 .228 : 8080 8d
 投票- svc 10.244 .1 .202 : 8801 , 10.244 .1 .202 : 8080 8 d
 ウェブ- apex <なし> 2 m55s
 ウェブ- サービス10.244 .1 .227 : 8080 8d
 ウェブ- svc - 2 10.244 .1 .233 : 8080 28 m

先に進む前に、現在のアプリケーション トラフィックの状態を確認してみましょう。

 $ linkerd viz stat po - n emojivoto
 名前ステータスメッシュ成功RPS LATENCY_P50 LATENCY_P95 LATENCY_P99 TCP_CONN
 絵文字- 696 d9d8f95 - 5 vn9w 実行中1 / 1 100.00 % 2.3 rps 1 ms 1 ms 1 ms 4
 投票- ボット- 6 d7677bb68 - jvxsg 実行中1 / 1 100.00 % 0.3 rps 1 ms 1 ms 1 ms 1
 投票- ff4c54b8d - xhjv7 実行中1 / 1 98.04 % 0.8 rps 1 ms 8 ms 10 ms 4
 web - 5f 86686 c4d - 58 p7k 実行中1 / 1 100.00 % 1.4 rps 1 ms 6 ms 9 ms 2

更新されたバージョンの Web サービスを展開したにもかかわらず、現在はトラフィックが生成されていないことがはっきりとわかります。次に、TrafficSplit オブジェクトを作成し、トラフィックの一部を新しいサービスに分割する必要があります。

次のように TrafficSplit リソース オブジェクトを作成します。

 # ウェブ- サービス- ts.yml
 apiバージョン: 分割します。 smi スペック。 io / v1アルファ2
 種類: TrafficSplit
 メタデータ:
 名前: web - svc - ts
 名前空間: emojivoto
 仕様:
 # クライアントはターゲットアプリケーションのルートサービスに接続するために使用されます
サービス: ウェブ- apex
 # 独自のセレクター、エンドポイント、および構成を持つ名前空間内のサービス。
 バックエンド: # バックエンドサービスを分割する
- サービス: Web -SVC
 重量: 500 #重量
- サービス: Web -SVC -2 ​
 重量: 500

上記のリソース オブジェクトには、主に次の 2 つのプロパティが含まれます。

• service: クライアントがターゲット アプリケーションに接続するために使用するルート サービス。
• バックエンド: 独自のセレクター、エンドポイント、および構成を持つ名前空間内のサービス (これらのサービスはリーフ サービスと考えることができます)。

• service: リクエストを処理できる Pod に関連付けられた特定のサービスの名前。
• 重み: サービスに割り当てられた総トラフィックの割合に関連します。

次に、上記のリソース オブジェクトを適用します。

 $ kubectl apply -f web -svc -ts .yaml
 トラフィック分割。 スプリット。 smi スペック。 io / web - svc - ts が作成されました
$ kubectl get trafficsplit - n 絵文字
ネームサービス
ウェブ- svc - ts ウェブ- apex

作成すると、linkerd viz stat​ コマンドの trafficsplit​ サブコマンド (省略形は ts) を使用して、すべてのトラフィック分割統計を表示できます。

 $ linkerd viz stat ts - n emojivoto
 2.12 以降では、 トラフィック分割にはSMI 拡張が必要になります。 https://linkerd.io/2.10/tasks/linkerd-smi のSMI 拡張機能入門ガイドに従ってください。

 名前頂点葉重み成功RPS LATENCY_P50 LATENCY_P95 LATENCY_P99
 ウェブ- SVC - TS ウェブ- アペックスウェブ- SVC 500 - - - - -
 ウェブ- SVC - TS ウェブ- Apex ウェブ- SVC - 2 500 - - - - -

投票ボットはトラフィックを web-svc.emojivoto:80​ に送信するように設定されているため、現時点ではトラフィック分割の兆候は表示されません。まず、vote-bot サービスを更新して、web-svc ではなく web-apex サービスにトラフィックを送信するようにします。次の kubectl コマンドで使用されるファイルは、vote-bot デプロイメントの WEB_HOST 環境変数を変更してトラフィックを web-apex サービスに送信し、TrafficSplit 構成を有効にします。

 $ kubectl edit deploy vote - bot - n emojivoto
 # ......
 仕様:
 コンテナ:
 - 指示：
 - 絵文字投票- 投票- ボット
環境:
 - 名前: WEB_HOST
 値: web - apex 。 絵文字: 80
 イメージ: docker 。 15d 。 io / buoyantio / emojivoto - Web : v11
 imagePullPolicy : IfNotPresent
 名前: 投票ボット
# ......

更新後、新しい vote-bot サービスが web-apex サービスにリクエストを送信します。上記の trafficsplit サブコマンドを使用してこれを再度確認できます。

 $ linkerd viz stat ts - n emojivoto
 2.12 以降では、 トラフィック分割にはSMI 拡張が必要になります。 https://linkerd.io/2.10/tasks/linkerd-smi のSMI 拡張機能入門ガイドに従ってください。

 名前頂点葉重み成功RPS LATENCY_P50 LATENCY_P95 LATENCY_P99
 ウェブ- SVC - TS ウェブ- Apex ウェブ- SVC 500 90.32 % 1.0 rps 3 ms 9 ms 10 ms
 ウェブ- SVC - TS ウェブ- Apex ウェブ- SVC - 2 500 96.49 % 0.9 rps 1 ms 5 ms 5 ms

上記の出力から、web-apex​ サービスは、それ自体が LEAF サービスである web-svc​ サービスと web-svc-2​ サービスの APEX​ サービスであることがわかります。出力には各サービスの重みの分布も表示されます。

重みを調整する

次に、linkerd viz stat​ コマンドを使用してアプリケーション トラフィックを確認します。前回確認したとき、web-svc-2 サービスに関連付けられた Pod はトラフィックを受信して​​いませんでした。

 $ linkerd viz stat pod - n emojivoto
 名前ステータスメッシュ成功RPS LATENCY_P50 LATENCY_P95 LATENCY_P99 TCP_CONN
 絵文字- 696 d9d8f95 - 5 vn9w 実行中1 / 1 100.00 % 2.3 rps 1 ms 2 ms 3 ms 5
 投票- ボット- 646 b9fd6fd - js526 実行中1 / 1 100.00 % 0.3 rps 1 ms 1 ms 1 ms 1
 投票- ff4c54b8d - xhjv7 実行中1 / 1 89.74 % 1.3 rps 1 ms 7 ms 9 ms 5
 web - 5f 86686 c4d - 58 p7k 実行中1 / 1 97.33 % 1.2 rps 2 ms 9 ms 10 ms 3
 web - svc - 2 - f9d77474f - hgsg4 実行中1 / 1 92.31 % 1.3 rps 1 ms 6 ms 9 ms 3

今回は、web-svc​ と web-svc-2 に関連付けられた両方の Pod がリクエストを処理していることがわかります。トラフィック分割構成が正しいことを証明します。

TrafficSplit 定義では、トラフィックを均等に分散するために、各サービスの重みを 500 に設定します。実際の作業では、エラーが発生しないことを保証するために、まず web-svc-2 の重みを 1% または非常に低い重みに設定することができます。その後、新しいバージョンに問題がないことが確認できたら、すべてのトラフィックが新しいバージョンに切り替わるまで、各サービスの重みを徐々に調整することができます。

TrafficSplit​ オブジェクトを手動で編集することで、これら 2 つのサービスの重みを手動で調整できます。トラフィックの 75% を web-svc-2 に送信し、25% を web-svc に送信します。

 # web - svc - ts - 2.yml
 apiバージョン: 分割します。 smi スペック。 io / v1alpha2
 種類: TrafficSplit
 メタデータ:
 名前: web - svc - ts
 名前空間: emojivoto
 仕様:
 # クライアントはターゲットアプリケーションのルートサービスに接続するために使用されます
サービス: ウェブ- apex
 # 独自のセレクター、エンドポイント、および構成を持つ名前空間内のサービス。
 バックエンド: # バックエンドサービスを分割する
- サービス: Web -SVC
 重量: 250 #重量
- サービス: Web -SVC -2 ​
 重量: 750

上記のリソース オブジェクトを更新した後、トラフィック分割状況を再度確認してください。

 $ linkerd viz stat ts - n emojivoto
 2.12 以降では、 トラフィック分割にはSMI 拡張が必要になります。 https://linkerd.io/2.10/tasks/linkerd-smi のSMI 拡張機能入門ガイドに従ってください。

 名前頂点葉重み成功RPS LATENCY_P50 LATENCY_P95 LATENCY_P99
 ウェブ- サービス- TS ウェブ- アペックスウェブ- サービス250 87.88 % 0.6 rps 6 ミリ秒17 ミリ秒20 ミリ秒
ウェブ- SVC - TS ウェブ- Apex ウェブ- SVC - 2 750 94.12 % 1.4 rps 2 ms 8 ms 10 ms

出力では、WEIGHT​ 列が上記の変更と一致し、web-svc-2​ の場合は 750、web-svc​ の場合は 250 であることがわかります。次に、すべてのトラフィックを web-svc-2 サービスに送信するように TrafficSplit​ オブジェクトを変更します。

 # web - svc - ts - 3.yml
 apiバージョン: 分割します。 smi スペック。 io / v1alpha2
 種類: TrafficSplit
 メタデータ:
 名前: web - svc - ts
 名前空間: emojivoto
 仕様:
 # クライアントはターゲットアプリケーションのルートサービスに接続するために使用されます
サービス: ウェブ- apex
 # 独自のセレクター、エンドポイント、および構成を持つ名前空間内のサービス。
 バックエンド: # バックエンドサービスを分割する
- サービス: Web -SVC
 重量: 0 #重量
- サービス: Web -SVC -2 ​
 重量: 1

更新後、トラフィックの分割を再度確認します。

 $ linkerd viz stat ts - n emojivoto
 2.12 以降では、 トラフィック分割にはSMI 拡張が必要になります。 https://linkerd.io/2.10/tasks/linkerd-smi のSMI 拡張機能入門ガイドに従ってください。

 名前頂点葉重み成功RPS LATENCY_P50 LATENCY_P95 LATENCY_P99
 ウェブ- サービス- ts ウェブ- アペックスウェブ- サービス0 - - - - -
 ウェブ- SVC - TS ウェブ- Apex ウェブ- SVC - 2 1 99.15 % 1.9 rps 2 ms 3 ms 3 ms

通常、web-svc-2​ サービスに対応する WEIGHT​ は 1 で、web-svc​ は 0 であることがわかります。

これまで、Linkerd でのトラフィック分割の使用について学習しました。簡潔にするために、ここでは別の web-apex​ サービスを使用しています。もちろん、apex サービスはバックエンドの 1 つのサービスになることもできます。 Apex の TrafficSplit​ と、同じサービスを持つバックエンドの 1 つは、そのサービスに送信されたトラフィックをそのサービスに送信しますが、残りのバックエンド サービスに比例します。これは動的に実行できるため、既存のサービス上に TrafficSplit を挿入できます。

たとえば、web-apex​ を使用する代わりに、web-svc​ を apex​ として使用し、web-svc-2​ をバックエンドとして引き続き使用することもできます。 TrafficSplit​ が作成された瞬間、web-svc​ への既存のトラフィックは TrafficSplit のルールに従います。削除されるとすぐに、Web サービスへのトラフィックは正常に戻ります。

実際には、リリース プロセスを自動化するために、Linkerd のトラフィック分割機能を CI/CD システムと統合することがよくあります。 Linkerd 自体が関連する指標を提供します。これと組み合わせることで、プログレッシブ配信を実現できます。インジケーターとトラフィック分割をバンドルすることで、新しいコードを増分的、安全、かつ完全に自動化された方法でリリースできます。先ほど、Argo Rollouts を紹介しました。 https://flagger.app/ のようなプロジェクトも使用できます。これは、Linkerd のインジケーターとトラフィック分割機能に基づいて構築されており、プログレッシブ配信を実行します。