このトピックでは、Microservices Engine (MSE) が提供する UI ベースの移行ツールを使用して、セルフマネージド NGINX Ingress ゲートウェイから MSE Ingress ゲートウェイにトラフィックを移行する方法について説明します。
前提条件
Container Service for Kubernetes (ACK) クラスタ、ACK Serverless クラスタ、または 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 は、プロンプトに従ってルート設定とトラフィックを移行するための移行ツールを提供します。
ステップ 1: ルーティング規則の移行
MSE コンソールにログインします。トップナビゲーションバーで、リージョンを選択します。
左側のナビゲーションペインで、クラウドネイティブゲートウェイ > クラウドへの移行 を選択します。
クラウドへの移行ページで、タスクの追加をクリックします。
移行設定の作成パネルで、パラメータを設定します。
MSE クラウドネイティブゲートウェイは、クラスタ内のソース Ingress クラスに関連付けられているすべての Ingress リソースの変更を自動的にリッスンし、Ingress リソースのドメイン名とルートの設定を有効にします。
重要宛先クラウドネイティブゲートウェイがクラスタに関連付けられており、クラスタの既存の Ingress クラスがこのステップで設定された Ingress クラスと同じでない場合、移行は許可されません。このステップで設定された Ingress クラスが、関連付けられたクラスタに設定された Ingress クラスと同じであることを確認する必要があります。
パラメータ
説明
クラウドネイティブゲートウェイ
ルーティング規則を移行する MSE クラウドネイティブゲートウェイ。MSE クラウドネイティブゲートウェイのバージョンは V1.2.22 以降である必要があります。
ACK マネージドクラスタ/ACK Serverless クラスタ/ACS クラスタ
NGINX Ingress ゲートウェイが属するクラスタ。MSE クラウドネイティブゲートウェイとクラスタが同じ仮想プライベートクラウド (VPC) にあることを確認する必要があります。
ソース Ingress クラス
移行する Ingress リソースが関連付けられている Ingress クラス。
説明サポートされる Ingress クラスは 1 つだけです。
このパラメータを指定しない場合、MSE クラウドネイティブゲートウェイはクラスタ内のすべての Ingress リソースをリッスンします。
次へをクリックします。
MSE クラウドネイティブゲートウェイは、クラスタ内のソース Ingress クラスに関連付けられているすべての Ingress リソースの変更を自動的にリッスンし、Ingress リソースのドメイン名とルートの設定を有効にします。
この例では、httpbin という名前の Ingress がクラスタにデプロイされています。
MSE コンソールでは、クラスタの Ingress が MSE クラウドネイティブゲートウェイに自動的に同期され、Ingress のドメイン名とルートが生成されていることがわかります。
ステップ 2: ルートの確認
クラウドネイティブゲートウェイがリッスンする Ingress リソースの互換性を確認します。
すべての Ingress アノテーションがクラウドネイティブゲートウェイと互換性がある場合は、次のステップに進みます。
クラウドネイティブゲートウェイと互換性のない Ingress アノテーションがある場合は、リンクをクリックしてチケットを送信してください。
重要値が二重引用符 ("") のアノテーション
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 インスタンスを再利用できます。操作が完了したら、事前チェックをクリックします。チェックに合格したら、次のステップに進みます。
同じクラスタ内のアプリケーションポッドが 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 インスタンス上のすべてのトラフィックがクラウドネイティブゲートウェイに切り替えられます。移行の完了をクリックして移行タスクを完了します。
SLB への DNS 解決
DNS ベンダーが提供する DNS サービスの場合、ルート移行に関係するすべてのドメイン名と、クラウドネイティブゲートウェイに関連付けられた SLB インスタンスの IP アドレス間のマッピングを追加します。設定された重み値に基づいて徐々にトラフィックを切り替えるために 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 を管理する場合は、ACK クラスタおよび ACS クラスタ内のサービスにアクセスするための MSE Ingress ゲートウェイの使用の手順に従います。
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 サービスを削除します。