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 上記のリソース オブジェクトを直接適用します。 $ kubectl apply -f web -svc - 2.yaml デプロイ後、サービスの更新バージョンが正しくデプロイされていることを確認します。 $ kubectl get po -- セレクターapp = web - svc - 2 - n emojivoto デプロイが成功したら、kubectl port-forward コマンドを使用してサービスを公開することもできます。 $ kubectl ポート転送 svc/web-svc-2 8080:80 -n emojivoto 同様に、ブラウザの localhost:8080 を介してアプリケーションの新しいバージョンにアクセスすることもできます。 ページの上部を見ると、アプリケーションの新しいバージョンには文字情報の行が追加されていることがわかります。 TrafficSplit の作成次に、apex サービスを作成する必要があります。ここでは web-apex と呼びますが、今回は Pod が実行されておらず、エンドポイントがないため、サービスにリクエストを送信できません。 # ウェブ- apex.yaml 上記のリソース オブジェクトを直接適用します。 $ kubectl apply -f web -apex .yaml 上記の出力から、web-apex サービスは他の通常のサービスと同じですが、エンドポイントがないことがわかります。 $ kubectl get ep - n 絵文字 先に進む前に、現在のアプリケーション トラフィックの状態を確認してみましょう。 $ linkerd viz stat po - n emojivoto 更新されたバージョンの Web サービスを展開したにもかかわらず、現在はトラフィックが生成されていないことがはっきりとわかります。次に、TrafficSplit オブジェクトを作成し、トラフィックの一部を新しいサービスに分割する必要があります。 次のように TrafficSplit リソース オブジェクトを作成します。 # ウェブ- サービス- ts.yml 上記のリソース オブジェクトには、主に次の 2 つのプロパティが含まれます。
次に、上記のリソース オブジェクトを適用します。 $ kubectl apply -f web -svc -ts .yaml 作成すると、linkerd viz stat コマンドの trafficsplit サブコマンド (省略形は ts) を使用して、すべてのトラフィック分割統計を表示できます。 $ linkerd viz stat ts - n emojivoto 投票ボットはトラフィックを 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 更新後、新しい vote-bot サービスが web-apex サービスにリクエストを送信します。上記の trafficsplit サブコマンドを使用してこれを再度確認できます。 $ linkerd viz stat ts - n emojivoto 上記の出力から、web-apex サービスは、それ自体が LEAF サービスである web-svc サービスと web-svc-2 サービスの APEX サービスであることがわかります。出力には各サービスの重みの分布も表示されます。 重みを調整する次に、linkerd viz stat コマンドを使用してアプリケーション トラフィックを確認します。前回確認したとき、web-svc-2 サービスに関連付けられた Pod はトラフィックを受信していませんでした。 $ linkerd viz stat pod - n emojivoto 今回は、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 上記のリソース オブジェクトを更新した後、トラフィック分割状況を再度確認してください。 $ linkerd viz stat ts - n emojivoto 出力では、WEIGHT 列が上記の変更と一致し、web-svc-2 の場合は 750、web-svc の場合は 250 であることがわかります。次に、すべてのトラフィックを web-svc-2 サービスに送信するように TrafficSplit オブジェクトを変更します。 # web - svc - ts - 3.yml 更新後、トラフィックの分割を再度確認します。 $ linkerd viz stat ts - n emojivoto 通常、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 のインジケーターとトラフィック分割機能に基づいて構築されており、プログレッシブ配信を実行します。 |
<<: プライムデーは米国の消費者市場の信頼を回復し、アマゾン ウェブ サービスがプライムデーの新たな成功に貢献
>>: IaC に関しては、Terraform と CloudFormation のどちらが優れていますか?
良いランキングを得るには、ウェブサイトの適切な内部構造に加えて、外部リンクも非常に重要な要素です。外...
インテルが今年の第3四半期に、コードネーム「Calpella」の次世代 Centrino モバイル ...
導入Kubernetes によって報告されたエラーは次のとおりです。 Failed to creat...
Jindouyun (jdouu) の活動: 米国サンノゼの双方向 cn2 gia 回線、50Mbp...
1. 公式Weiboプロモーションの背後にある闇の食物連鎖これは「メディア」の混沌とした時代であ...
Prometheus は Pull モードを使用して監視インジケーターをプルすることがわかっています...
9 月 9 日は「テスターの日」であり、friendhosting は 8 つのコンピュータ ルーム...
インターネットは、多くの草の根起業家にとって人気のプラットフォームです。誰もが、インターネットでビジ...
1. 株式公開は、Baofeng Video が最後に話題になったときですか?馮鑫は今回の上場に向け...
DA International Group Ltd. の子会社である alphavps.bg は ...
digitalocean が最後にプロモーションを行ったのはいつだったか思い出せませんが、少なくとも...
現在(2018年4月)、locvpsは香港の自社葵湾データセンターのVPSのプロモーションを実施して...
インターネットの健全な発展に伴い、検索エンジンは医薬品業界に対してますます高い基準を設定してきました...
アマゾンウェブサービスは2021年3月25日、北京でメディアコミュニケーション会議を開催し、「3つの...
調査結果に基づいて、クラウド コンピューティング戦略とリアルタイム継続的インテグレーションの実装が絡...