Microservices Engine (MSE) は、ダウンタイムなしでセルフマネージドの NGINX Ingress ゲートウェイから MSE クラウドネイティブゲートウェイへトラフィックを移行するための UI ベースの移行ツールを提供します。
仕組み
MSE クラウドネイティブゲートウェイは Ingress 構成をコピーしません。代わりに、それらを直接監視します。移行中、NGINX Ingress Controller と MSE Ingress ゲートウェイの両方がリアルタイムで同じ Ingress リソースを監視します。トラフィックは重みに基づいて徐々にシフトされ、移行完了前の任意の時点でロールバックできます。
前提条件
作業を開始する前に、以下の要件を満たしていることを確認してください。
NGINX Ingress Controller がデプロイ済みの ACK クラスター、ACK Serverless クラスター、または ACS クラスター
V1.2.22 以降の MSE クラウドネイティブゲートウェイ。詳細については、「クラウドネイティブゲートウェイの作成」をご参照ください。
MSE クラウドネイティブゲートウェイとクラスターが同一の仮想プライベートクラウド (VPC) 内にあること
注意事項
移行後も、現在利用中のすべての NGINX Ingress 構成は保持し、削除しないでください。MSE Ingress ゲートウェイはこれらの構成を監視・解析します。
移行後、すべての Ingress 構成(既存および新規)は引き続き NGINX Ingress クラスに関連付けられたままにしておく必要があります。たとえば、
ingressClassNameがnginxに設定されている場合、その設定は変更しないでください。
トラフィック切り替え方法の選択
次の 2 種類のトラフィック切り替え方法が利用可能です。移行を開始する前に選択してください。
| 方法 | 仕組み | 適用範囲 |
|---|---|---|
| 元のクラスター SLB の再利用 | MSE ゲートウェイを SLB インスタンスのバックエンド vServer グループに追加します。SLB インスタンスは NGINX と MSE 間で重みに基づいてトラフィックを分散します。 | SLB インスタンスが Kubernetes サービスによって管理されているクラスター |
| DNS 解決による SLB 切り替え | DNS レコードを更新して、ドメイン名を MSE ゲートウェイの SLB IP アドレスにマップします。DNS の重みを調整することでトラフィックを徐々にシフトします。 | DNS レベルでのトラフィック制御を希望するシナリオ |
移行ワークフロー
移行は以下の 5 ステップで構成されます。
ルーティングルールの移行
ルートの互換性チェック
トラフィック切り替え方法の選択
トラフィックの切り替え
移行の完了
ステップ 1:ルーティングルールの移行
MSE コンソールにログインします。上部のナビゲーションバーでリージョンを選択します。
左側のナビゲーションウィンドウで、クラウドネイティブゲートウェイ > クラウドへの移行 を選択します。
クラウドへの移行ページで、タスクの追加 をクリックします。
移行構成の作成パネルで、パラメーターを設定します。
重要MSE クラウドネイティブゲートウェイがすでにクラスターに関連付けられており、Ingress 監視が有効になっている場合、ここで設定するソース Ingress クラスは、そのクラスターに対して設定済みの Ingress クラスと一致している必要があります。一致しない場合、移行がブロックされます。
パラメーター 説明 クラウドネイティブゲートウェイ 移行先の MSE クラウドネイティブゲートウェイ。バージョンは V1.2.22 以降である必要があります。 ACK マネージドクラスター / ACK Serverless クラスター / ACS クラスター NGINX Ingress Controller がデプロイされているクラスター。MSE ゲートウェイとこのクラスターは同一の VPC 内に存在する必要があります。 ソース Ingress クラス 移行対象の Ingress リソースに関連付けられている Ingress クラス。Ingress クラスは 1 つだけサポートされます。空白の場合は、MSE ゲートウェイがクラスター内のすべての Ingress リソースを監視します。 
次へ をクリックします。
次へ をクリックすると、MSE クラウドネイティブゲートウェイは自動的に設定されたソース Ingress クラスに関連付けられたすべての Ingress リソースを監視します。これらの Ingress リソースからドメイン名とルートがゲートウェイに同期されます。MSE コンソールで Ingress リソースが表示され、ドメイン名とルートが正しく生成されていることを確認してください。
ステップ 2:ルートの互換性チェック
MSE コンソールは、Ingress リソースに設定されたアノテーションがクラウドネイティブゲートウェイと互換性があるかどうかをチェックします。
すべてのアノテーションが互換性を持つ場合、ステップ 3 に進みます。

互換性のないアノテーションが存在する場合、チケットを送信してサポートを依頼してください。
空文字列 ("") の値を持つアノテーションnginx.ingress.kubernetes.io/service-weightは無視できます。これは古いバージョンの ACK コンソールでデフォルトで追加されるもので、実際の動作には影響しません。
移行中に互換性のないアノテーションを削除しないでください。NGINX Ingress Controller は引き続きこれらのアノテーションを解析し、トラフィックに適用します。MSE Ingress ゲートウェイで同様の動作を実現するには、Ingress リソースに同等の MSE 拡張アノテーションを追加してください。すべてのトラフィックが MSE ゲートウェイに移行された後、必要に応じて互換性のないアノテーションを削除できます。
ステップ 3:トラフィック切り替え方法の選択
トラフィックを切り替える前に、MSE ゲートウェイをローカルでテストします。
ローカルホストファイルを編集し、MSE クラウドネイティブゲートウェイに関連付けられた SLB インスタンスの IP アドレスを関連ドメイン名にマップします。
curl または Postman を使用して、トラフィックが期待通りにルーティングされることを確認します。
その後、「トラフィック切り替え方法の選択」で説明されている 2 つのトラフィック切り替え方法のいずれかを選択します。
元のクラスター SLB の再利用 を選択した場合、以下のパラメーターを設定します。
| パラメーター | 説明 |
|---|---|
| ACK クラスターネームスペース | NGINX Ingress ゲートウェイに関連付けられた SLB インスタンスに対応する Kubernetes サービスの名前空間。 |
| ACK クラスター SLB サービス | NGINX Ingress ゲートウェイに関連付けられた SLB インスタンスに対応する Kubernetes サービスの名前。 |
| SLB ID | トラフィックを切り替えたい SLB インスタンスの ID。 |
| ポートとバックエンドサーバー | SLB インスタンスのリスナーポートおよびゲートウェイプロトコル (HTTP または HTTPS)。ポートとプロトコルを選択すると、vServer グループが自動的に表示されます。選択したポートとプロトコルが有効であることを確認してください。そうでない場合、トラフィック損失が発生する可能性があります。 |
ステップ 4:トラフィックの切り替え
元のクラスター SLB の再利用
SLB ベースの方法では、SLB インスタンスの vServer グループの重みを調整することでトラフィックをシフトします。以下の 4 つのサブステップを順番に実行してください。
サブステップ 1:SLB 構成の変更
SLB の変更 をクリックします。これにより、SLB インスタンスがクラスター管理から外れ、リスナーのスケジューリングアルゴリズムが重み付きラウンドロビンに変更されます。
SLB の変更 をクリックした後、SLB インスタンスは NGINX Ingress Controller の Pod IP アドレスの変更を検出できなくなります。サブステップ 2 を直ちに実行して、Kubernetes サービスを再度 SLB インスタンスに関連付けてください。
サブステップ 2:サービスアノテーションの上書き
ACK コンソールにログインします。
元のクラスター SLB の再利用 を選択した際に指定した Kubernetes サービスを見つけます。
そのサービスに設定されているすべての既存アノテーションを削除します。
トラフィックの切り替え タブで自動生成されたアノテーションをコピーし、Kubernetes サービスに適用します。この操作により、サービスが再度 SLB インスタンスに関連付けられます。
事前チェック をクリックします。チェックが完了するまで待ち、その後に続行します。
同一クラスター内の Pod が NGINX Ingress ゲートウェイにアクセスする場合、Kubernetes サービスにアノテーション service.beta.kubernetes.io/alibaba-cloud-loadbalancer-hostname: mse-ingress-migration を追加してください。このアノテーションを追加する前に、SLB インスタンスで IP アドレスベースのアクセスの制御が有効になっていないことを確認してください。これにより、クラスター内 Pod からのアクセスが SLB インスタンス経由で強制的に NGINX Ingress ゲートウェイにルーティングされ、kube-proxy 経由の SLB インスタンスバイパスが無効になります。サブステップ 3:重みによるトラフィックのシフト
MSE クラウドネイティブゲートウェイにルーティングされるトラフィックの重みを設定します。有効値は 1~100 です。
重みの動作原理:
設定する重みは、MSE ゲートウェイの全ノードにわたる合計重みとなります。NGINX Ingress ゲートウェイの全ノードのデフォルト合計重みは 100 です。SLB インスタンスはトラフィックを比例的に分散します。
| MSE ゲートウェイの重み | MSE ゲートウェイへのトラフィック |
|---|---|
| 100 | 50%(合計 200 中の 100) |
| 50 | 33%(合計 150 中の 50) |
| 0 | 0%(ロールバック) |
初期シフトでは 1~10 の値から開始してください。
重みのモニタリングと調整:
MSE コンソールのダッシュボードで、MSE ゲートウェイのヘルス状態およびビジネスメトリックをモニタリングします。
メトリックが期待通りの場合、徐々に重みを増やします。重みの変更は非同期で反映されるため、調整間隔は少なくとも 3 分以上空けてください。
メトリックが期待通りでない場合、重みを 0 に設定して MSE ゲートウェイへのトラフィックを停止します。
MSE ゲートウェイへのトラフィックを増やすには、Kubernetes サービスのアノテーション
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weightの値を減らすこともできます。このアノテーションを 0 に設定すると、SLB トラフィックがすべて MSE ゲートウェイにルーティングされます。
SLB はレイヤー 4 で接続レベルの速度制限を使用して動作します。重みは個別のリクエストではなく接続の分散を制御するため、実際の比率は概算値となります。
トラフィックの動作が期待通りであり、ロールバックが不要であることを確認できるまでは、このステップに留まってください。トラフィック検証の完了 をクリックすると、重みを変更できなくなります。
サブステップ 4:すべてのトラフィックを MSE ゲートウェイに切り替え
ACK コンソールで、Kubernetes サービスのアノテーション service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight を 0 に設定するか、Kubernetes サービスを完全に削除します。これにより、NGINX Ingress Controller が自動的に SLB インスタンスから削除され、すべてのトラフィックが MSE クラウドネイティブゲートウェイにルーティングされます。
移行の完了 をクリックして終了します。
SLB への DNS 名前解決
DNS プロバイダーの管理コンソールで、移行対象のすべてのドメイン名を MSE クラウドネイティブゲートウェイに関連付けられた SLB インスタンスの IP アドレスにマップするレコードを追加します。DNS の重み値を調整することで、トラフィックを徐々にシフトします。
ロールバック
トラフィックの動作が予期しないものになった場合は、直ちにロールバックしてください。
元のクラスター SLB の再利用: MSE ゲートウェイの重みを
0に設定します。DNS 解決による SLB 切り替え: ビジネスドメイン名を MSE ゲートウェイの SLB IP アドレスにマップする DNS レコードを削除します。
ステップ 5:移行の完了
元のクラスター SLB の再利用
すべての SLB トラフィックが MSE クラウドネイティブゲートウェイにルーティングされていることを確認します。その後、必要に応じて Kubernetes サービスおよび NGINX Ingress Controller を削除します。
DNS 解決による SLB 切り替え
すべてのドメイン名が MSE クラウドネイティブゲートウェイに関連付けられた SLB インスタンスの IP アドレスに解決されることを確認します。その後、必要に応じて Kubernetes サービスおよび NGINX Ingress Controller を削除します。
よくある質問
エラー mse.backend.gw.MIGRATE_INGRESS_CLASS_CONFLICT が表示されます。修正方法を教えてください。
このエラーは、MSE クラウドネイティブゲートウェイがすでにクラスターに関連付けられており Ingress 監視が有効になっているにもかかわらず、そのゲートウェイが監視するように設定されている Ingress クラスが、移行しようとしているソース Ingress クラスと一致していないことを意味します。
これを修正するには、Ingress クラスの構成を更新してください。
MseIngressConfigリソースを使用して MSE Ingress を管理している場合、「ACK クラスター内のアプリケーションへの 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 サービスがまだトラフィックを受信しているため、移行を完了できません。ACK コンソールで、Kubernetes サービスのアノテーション service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight を 0 に設定するか、Kubernetes サービスを削除してください。