NGINX Ingress ゲートウェイから MSE Ingress ゲートウェイへのトラフィックの移行 - Microservices Engine

このトピックでは、マイクロサービスエンジン（MSE）が提供する UI ベースの移行ツールを使用して、セルフマネージド NGINX Ingress ゲートウェイから MSE Ingress ゲートウェイにトラフィックを移行する方法について説明します。

前提条件

Container Service for Kubernetes（ACK）クラスター、Serverless Kubernetes クラスター、または ACS クラスターが作成され、クラスターに NGINX Ingress Controller がデプロイされています。
クラウドネイティブゲートウェイが作成されています。クラウドネイティブゲートウェイがない場合は、「クラウドネイティブゲートウェイを作成する」をご参照ください。

注意事項

このトピックでは、MSE Ingress ゲートウェイは移行中に Ingress の構成を再利用します。 Ingress の構成はコピーされません。ゲートウェイは、既存の Ingress 構成の変更をリアルタイムでリッスンし、リッスンした構成を解析します。
移行中、NGINX Ingress Controller と MSE Ingress ゲートウェイの両方が Ingress 構成の変更を認識できます。
移行が完了した後、使用中のオンライン NGINX Ingress 構成を削除しないでください。移行の目的は、MSE Ingress ゲートウェイが既存および新規の Ingress 構成をリッスンして解析できるようにすることです。
移行が完了した後も、既存および新規の Ingress 構成は、NGINX Ingress ゲートウェイの Ingress クラスに関連付けられている必要があります。たとえば、NGINX Ingress ゲートウェイの spec の ingressClassName の値が nginx の場合、この設定は移行後も既存および新規の Ingress 構成で変更されません。

移行方法と原則

詳細の表示

MSE Ingress ゲートウェイとは

MSE Ingress ゲートウェイは、MSE クラウドネイティブゲートウェイに基づいて Ingress トラフィックを管理するための強力な方法を提供します。トラフィックゲートウェイ、マイクロサービスゲートウェイ、およびセキュリティゲートウェイは、MSE Ingress ゲートウェイに統合されています。 MSE Ingress ゲートウェイは、Kubernetes Ingress API 標準と互換性があります。 MSE Ingress ゲートウェイは、3 層ゲートウェイアーキテクチャの独立した設計と O&M によって発生する問題を解決します。問題には、高いリソース使用量、大きなパフォーマンス損失、低い安定性、および複雑なセキュリティ保護が含まれます。

MSE Ingress ゲートウェイの利点

従来のゲートウェイと比較して、MSE Ingress ゲートウェイは、リソースコスト、パフォーマンス、セキュリティ保護、使いやすさの点で次の利点を提供します。

標準準拠：MSE Ingress ゲートウェイは、Kubernetes Ingress API 標準に厳密に準拠しています。 networking.k8s.io/v1beta1 および networking.k8s.io/v1 バージョンがサポートされています。
高い互換性：MSE Ingress ゲートウェイは、NGINX Ingress アノテーションが使用されるシナリオの 90% 以上に適しています。 NGINX Ingress 構成は、変更なしで MSE Ingress ゲートウェイに直接反映できます。 MSE Ingress ゲートウェイでサポートされているアノテーションの詳細については、「MSE Ingress ゲートウェイでサポートされているアノテーション」をご参照ください。
アノテーション拡張：NGINX Ingress ゲートウェイで定義されているアノテーションに加えて、MSE Ingress ゲートウェイは、認証、ヘッダー制御、速度制限、セキュリティ保護などの機能に関連する専用のアノテーションを提供します。 MSE Ingress ゲートウェイでサポートされている専用アノテーションの詳細については、「MSE Ingress の高度な使用方法」をご参照ください。
安全なアーキテクチャ：データプレーンはコントロールプレーンから分離されており、リソースを分離し、アーキテクチャ設計のセキュリティを向上させます。
高パフォーマンス：HTTPS ハードウェアアクセラレーションがサポートされており、クエリ/秒（QPS）のパフォーマンスが向上しています。

背景情報

NGINX Ingress ゲートウェイを使用すると、次の問題が発生する可能性があります。

重大なセキュリティの脆弱性：CVE-2021-25745、CVE-2021-25746、および CVE-2021-25748。
MSE Ingress ゲートウェイは、Ingress API バージョンと Kubernetes クラスターバージョンと緊密に結合されています。これは、Kubernetes クラスターのアップグレードプロセスに悪影響を及ぼします。 Kubernetes V1.24 を実行する ACK マネージドクラスター、Kubernetes V1.24 を実行する Serverless Kubernetes クラスター、および Kubernetes V1.26 を実行する ACS クラスターでは、API バージョンが networking.k8s.io/v1beta1 の Ingress リソースは使用されなくなりました。 API バージョンが networking.k8s.io/v1 の Ingress リソースは、NGINX Ingress Controller V1.0.0 以降でサポートされています。上記のクラスターをアップグレードするには、NGINX Ingress Controller をアップグレードする必要があります。
NGINX Ingress Controller のアップグレードプロセスは複雑であり、アップグレードプロセス中にトラフィック損失が発生する可能性があります。
- 新しいバージョンの NGINX Ingress Controller の追加セットをデプロイする必要があります。
- アプリケーションバージョンをアップグレードするには、テンプレートパラメータを手動で変更する必要があります。
- 古いゲートウェイから新しいゲートウェイにトラフィックを移行する場合、DNS 解決のみがサポートされています。適時性は低く、問題が発生した場合のロールバックは許可されていません。

NGINX Ingress ゲートウェイから MSE Ingress ゲートウェイにトラフィックを移行すると、Ingress ゲートウェイを Ingress API バージョンと Kubernetes クラスターバージョンから分離できます。これにより、ACK クラスターのアップグレード中に NGINX Ingress Controller にバージョン要件が課されることはありません。 MSE Ingress ゲートウェイは、移行シナリオ用のツールを提供します。 Server Load Balancer（SLB）インスタンスを再利用して、きめ細かいトラフィック切り替えを実行できます。これにより、移行の適時性と安定性が向上します。

移行方法

MSE Ingress ゲートウェイは、次の移行方法を提供します。

SLB インスタンスの再利用
原則：MSE Ingress ゲートウェイは、ACK マネージドクラスター、Serverless Kubernetes クラスター、または ACS クラスターの NGINX Ingress Controller のサービスに関連付けられている SLB インスタンスを再利用します。 MSE Ingress ゲートウェイのノードは、リスナーと元の SLB インスタンスを持つ vServer グループに自動的に追加されます。トラフィックは、構成されたトラフィックの重みに基づいて移行されます。
MSE Ingress ゲートウェイは、元のトラフィック処理プロセスに基づいて既存の SLB インスタンスを再利用し、NGINX Ingress ゲートウェイの元のルールを自動的に同期します。検証が成功すると、トラフィックは徐々に MSE Ingress ゲートウェイに切り替えられます。元のトラフィックイングレス SLB インスタンスは、移行プロセス全体で変更されません。トラフィック切り替えのために DNS サーバーを変更する必要はありません。
DNS 解決の使用
原則：MSE Ingress ゲートウェイに関連付けられている SLB インスタンスの解決結果は、DNS サーバーのすべての NGINX Ingress ゲートウェイに関連付けられているサービスドメイン名に追加されます。一部の DNS サービスプロバイダーは、NGINX Ingress ゲートウェイに関連付けられている SLB インスタンスと MSE Ingress ゲートウェイに関連付けられている SLB インスタンスのトラフィックの割合を制御するための重み値を提供します。

方法の比較

移行方法	適時性	トラフィック切り替えレベル	重みベースの切り替え	操作の複雑さ
SLB インスタンスの再利用	高速	SLB レベル	サポートされています	簡単
DNS 解決の使用	低速	ドメイン名レベル	DNS サービスプロバイダーによって異なります	ドメイン名の数に比例

移行ソリューションの概要

MSE は、プロンプトに従ってルート構成とトラフィックを移行するための移行ツールを提供します。

ステップ 1：ルーティングルールの移行

MSE コンソールにログインします。上部のナビゲーションバーで、リージョンを選択します。
左側のナビゲーションウィンドウで、[クラウドネイティブゲートウェイ] > [クラウドへの移行] を選択します。
[クラウドへの移行] ページで、[タスクの追加] をクリックします。

[移行構成の作成] パネルで、パラメータを構成します。

MSE クラウドネイティブゲートウェイは、クラスター内のソース Ingress クラスに関連付けられているすべての Ingress リソースの変更を自動的にリッスンし、Ingress リソースのドメイン名とルートの構成を有効にします。

重要

宛先クラウドネイティブゲートウェイがクラスターに関連付けられており、クラスターの既存の Ingress クラスがこのステップで構成された Ingress クラスと同じでない場合、移行は許可されません。このステップで構成された Ingress クラスが、関連付けられたクラスターに構成された Ingress クラスと同じであることを確認する必要があります。

パラメータ	説明
クラウドネイティブゲートウェイ	ルーティングルールを移行する MSE クラウドネイティブゲートウェイ。 MSE クラウドネイティブゲートウェイのバージョンは V1.2.22 以降である必要があります。
ACK/ASK/ACS クラスター	NGINX Ingress ゲートウェイが属するクラスター。 MSE クラウドネイティブゲートウェイとクラスターが同じ VPC にあることを確認する必要があります。
ソース Ingress クラス	移行する Ingress リソースが関連付けられている Ingress クラス。説明 1 つの Ingress クラスのみがサポートされています。このパラメータを指定しない場合、MSE クラウドネイティブゲートウェイはクラスター内のすべての Ingress リソースをリッスンします。

[次へ] をクリックします。
MSE クラウドネイティブゲートウェイは、クラスター内のソース Ingress クラスに関連付けられているすべての Ingress リソースの変更を自動的にリッスンし、Ingress リソースのドメイン名とルートの構成を有効にします。
1. クラスターに httpbin という名前の Ingress をデプロイします。
2. MSE コンソールで、クラスターの Ingress が MSE クラウドネイティブゲートウェイに自動的に同期され、Ingress のドメイン名とルートが生成されていることを確認します。

ステップ 2：ルートの確認

クラウドネイティブゲートウェイがリッスンする Ingress リソースの互換性を確認します。

すべての Ingress アノテーションがクラウドネイティブゲートウェイと互換性がある場合は、次のステップに進みます。
Ingress アノテーションがクラウドネイティブゲートウェイと互換性がない場合は、リンクをクリックして、チケットを送信してください。
重要
- 値が二重引用符（""）の annotation nginx.ingress.kubernetes.io/service-weight は無視できます。このアノテーションは、古い ACK コンソールにデフォルトで追加され、意味がありません。
- 移行中は、使用中の互換性のないアノテーションを削除しないでください。これらの互換性のないアノテーションは、引き続き NGINX Ingress Controller によって解析され、ビジネストラフィックに影響を与えます。 MSE 拡張アノテーションを Ingress リソース構成に追加して、MSE Ingress ゲートウェイで同じ機能を実装できます。すべてのトラフィックが MSE Ingress ゲートウェイに移行された後、ビジネス要件に基づいて互換性のないアノテーションを削除できます。

ステップ 3：トラフィック切り替え方法の選択

トラフィック切り替え前のテストトラフィック分散

トラフィックを切り替える前に、次の操作を実行してローカルテストを実行することをお勧めします。ローカルの hosts ファイルを変更し、DNS サービスのクラウドネイティブゲートウェイに関連付けられた Server Load Balancer（SLB）インスタンスの IP アドレスのマッピングを追加してから、curl や Postman などのツールを使用して、トラフィック分散が期待どおりであるかどうかを確認します。

トラフィック切り替え方法の選択

元のクラスター SLB の再利用

この方法では、NGINX Ingress ゲートウェイに関連付けられた SLB インスタンスのバックエンド vServer グループに MSE クラウドネイティブゲートウェイを追加する必要があります。移行中、SLB インスタンスは、構成された重みに基づいてビジネストラフィックを MSE クラウドネイティブゲートウェイに分散します。移行が完了すると、SLB インスタンス上のすべてのビジネストラフィックが MSE クラウドネイティブゲートウェイに切り替えられます。

次の表に、この方法を選択した場合のパラメータを示します。

パラメータ	説明
ACK クラスターの名前空間	NGINX Ingress ゲートウェイに関連付けられた SLB インスタンスに対応する Kubernetes サービスの名前空間。
ACK クラスター SLB サービス	NGINX Ingress ゲートウェイに関連付けられた SLB インスタンスに対応する Kubernetes サービスの名前。
SLB ID	切り替えるトラフィックが通過する SLB インスタンスの ID。
ポートとバックエンドサーバー	クラスター内の SLB インスタンスのリスナーポートとゲートウェイプロトコル（HTTP または HTTPS）。ポートとプロトコルを選択すると、vServer グループが自動的に表示されます。説明選択したポートとプロトコルが有効であることを確認してください。そうしないと、トラフィック損失が発生する可能性があります。

SLB への DNS 解決

DNS ベンダーが提供する DNS サービスの場合、ルート移行に関係するすべてのドメイン名と、クラウドネイティブゲートウェイに関連付けられた SLB インスタンスの IP アドレス間のマッピングを追加します。構成された重み値に基づいて、DNS レコードを使用してトラフィックを徐々に切り替えることをお勧めします。

ステップ 4：トラフィックの切り替え

元のクラスター SLB の再利用

ステップ 1：SLB の変更をクリックします

[SLB の変更] をクリックすると、SLB インスタンスはクラスターによって管理されなくなり、リスナーのスケジューリングアルゴリズムは重み付きラウンドロビンに変更されます。

重要

変更後、SLB インスタンスは NGINX Ingress Controller のポッド IP アドレスの変更を検出できません。 Kubernetes サービスを SLB インスタンスに再関連付けるには、できるだけ早く次のステップを完了してください。

ステップ 2：サービスアノテーションを上書きします

ステップ 1 が完了したら、ACK コンソールにログインして、[元のクラスター SLB の再利用] を選択したときに指定した Kubernetes サービスのすべてのアノテーションを手動で削除し、[トラフィックの切り替え] タブで自動的に生成されたアノテーションを Kubernetes サービスのアノテーションにコピーします。このステップにより、Kubernetes サービスは SLB インスタンスを再利用できます。操作が完了したら、[事前チェック] をクリックします。チェックに合格したら、次のステップに進みます。

编辑yaml.png

同じクラスター内のアプリケーションポッドが NGINX Ingress ゲートウェイにアクセスする場合は、アノテーション service.beta.kubernetes.io/alibaba-cloud-loadbalancer-hostname: mse-ingress-migration を Kubernetes サービスに追加します。アノテーションを追加する前に、Kubernetes サービスに対応する SLB インスタンスに対して IP アドレスベースのアクセス制御が有効になっていないことを確認してください。このアノテーションは、アプリケーションポッドが SLB インスタンスを介して NGINX Ingress ゲートウェイにアクセスすることを強制的に有効にします。アノテーションが追加されると、kube-proxy に基づく SLB インスタンスバイパスは使用されません。

ステップ 3：構成された重みに基づいてトラフィックを切り替えます

MSE クラウドネイティブゲートウェイにトラフィックを切り替えるための重みを指定します。ビジネス要件に基づいて、重みを 1 ～ 100 の範囲の値に設定できます。最初は重みを 1 ～ 10 の範囲の値に設定することをお勧めします。

値は、MSE クラウドネイティブゲートウェイ内のすべてのノードの重みの合計です。 SLB インスタンスは、MSE クラウドネイティブゲートウェイ内の各ノードの重みと、vServer グループ内の NGINX Ingress ゲートウェイ内の各ノードの重みに基づいてトラフィックを分散します。 NGINX Ingress ゲートウェイ内のすべてのノードのデフォルトの合計重みは 100 です。クラウドネイティブゲートウェイの重みを 100 に設定すると、トラフィックの半分がクラウドネイティブゲートウェイにルーティングされます。同様に、クラウドネイティブゲートウェイの重みを 50 に設定すると、トラフィックの 1/3 がクラウドネイティブゲートウェイにルーティングされます。
移行中は、MSE コンソールのダッシュボードでクラウドネイティブゲートウェイのメトリックを表示できます。クラウドネイティブゲートウェイのヘルスステータスを監視し、ビジネスメトリックが期待どおりであるかどうかを確認できます。
- ビジネスメトリックが期待どおりである場合は、クラウドネイティブゲートウェイの重みを徐々に増やすことができます。重み構成はバックグラウンドで非同期的に有効になります。 したがって、3 分以上の間隔で重みを変更してください。
- ビジネスメトリックが期待どおりでない場合は、重みを 0 に設定して移行を終了します。
クラウドネイティブゲートウェイの重みを増やすには、[元のクラスタ SLB を再利用する] を選択したときに指定した Kubernetes サービスのアノテーション service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight の値を減らすこともできます。アノテーションを 0 に設定すると、SLB インスタンス上のすべてのトラフィックがクラウドネイティブゲートウェイにルーティングされます。
SLB は、接続レベルの速度制限を使用するレイヤー 4 ロードバランサーとして機能します。重みは、リクエスト分散の割合を正確に制御することはできません。
トラフィック切り替え後に成功率が低下した場合は、重みを 0 に設定して迅速なトラフィックロールバックを実行できます。

説明

移行状態を維持し、NGINX Ingress ゲートウェイと MSE Ingress ゲートウェイの重みをいつでも調整できるようにするには、このステップに長時間留まることをお勧めします。トラフィックが期待どおりであり、トラフィックロールバックが不要であることを確認したら、[トラフィック検証の完了] をクリックして次のステップに進みます。

重要

[トラフィック検証の完了] をクリックすると、重みを変更できなくなります。

ステップ 4：すべてのトラフィックをクラウドネイティブゲートウェイに切り替えます

ACK コンソールで、ステップ 3：トラフィック切り替え方法の選択で指定した Kubernetes サービスのアノテーション service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight の値を 0 に設定します。 Kubernetes サービスリソースを直接削除することもできます。 NGINX Ingress Controller は、SLB インスタンスから自動的に削除されます。 SLB インスタンス上のすべてのトラフィックは、クラウドネイティブゲートウェイに切り替えられます。 [移行の完了] をクリックして、移行タスクを完了します。

迁移走了.png

SLB への DNS 解決

ロールバックを実行する

トラフィック分散が期待どおりでない場合は、次のいずれかの方法を使用して、トラフィックを NGINX Ingress Controller にすぐにロールバックできます。

元のクラスター SLB の再利用：重みを 0 に設定して移行を終了します。
SLB への DNS 解決：DNS ベンダーが提供する DNS サービスの場合、ビジネスドメイン名と MSE クラウドネイティブゲートウェイに関連付けられた SLB インスタンスの IP アドレス間のマッピングを削除します。

ステップ 5：移行の完了

元のクラスター SLB の再利用

この方法を選択した場合は、SLB インスタンス上のすべてのトラフィックが MSE クラウドネイティブゲートウェイに分散されていることを確認してください。その後、ビジネス要件に基づいて Kubernetes サービスと NGINX Ingress Controller を削除できます。

SLB への DNS 解決

この方法を選択した場合は、すべてのドメイン名が MSE クラウドネイティブゲートウェイに関連付けられた SLB インスタンスの IP アドレスとして解析されていることを確認してください。その後、ビジネス要件に基づいて Kubernetes サービスと NGINX Ingress Controller を削除できます。

FAQ

エラーメッセージ mse.backend.gw.MIGRATE_INGRESS_CLASS_CONFLICT が報告された場合はどうすればよいですか？

MSE クラウドネイティブゲートウェイはクラスターに関連付けられており、Ingress リッスンが有効になっています。ただし、MSE クラウドネイティブゲートウェイの Ingress クラスは、ソース Ingress クラスとは異なります。その結果、このエラーメッセージが返されます。

Ingress クラスを変更するには、次の操作を実行します。

MseIngressConfig リソースを使用して MSE Ingress を管理する場合は、「MSE Ingress ゲートウェイを使用して ACK クラスターおよび ACS クラスター内のサービスにアクセスする」の手順に従います。
MseIngressConfig リソースを使用して MSE Ingress を管理しない場合は、MSE コンソールでクラスターの Ingress リッスン設定を変更します。

エラーメッセージ mse.backend.gw.MIGRATE_SERVICE_ANNOTATION_NOT_MATCH [annotation is not expected] が報告された場合はどうすればよいですか？

この問題は、Kubernetes サービスのアノテーションが予期したとおりではないために発生します。

エラーメッセージ mse.backend.gw.MIGRATE_SERVICE_NOT_MATCH [weight hasn't be 0 or service hasn't been deleted] が報告された場合はどうすればよいですか？

この問題は、Kubernetes サービスのアノテーション service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight が 0 に設定されていないか、Kubernetes サービスが削除されていないために発生します。この場合、ACK コンソールで Kubernetes サービスのアノテーション service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight の値を 0 に変更するか、Kubernetes サービスを削除します。