API Gateway:セルフマネージド NGINX Ingress から Cloud-native API Gateway への移行

前提条件

• Container Service for Kubernetes (ACK) クラスターに NGINX Ingress Controller をデプロイ済みです。

• Cloud-native API Gateway インスタンスを作成済みである必要があります。まだ作成していない場合は、「ゲートウェイインスタンスの作成」をご参照ください。

注意事項

• この移行プロセスでは、Ingress 構成をコピーしません。代わりに、Cloud-native API Gateway は既存の Ingress リソースをリアルタイムで変更を解析し、再利用します。

• 移行中、Ingress 構成に対するすべての変更は、NGINX Ingress Controller と Cloud-native API Gateway の両方に反映されます。

• 移行完了後も、本番環境の Ingress 構成を削除しないでください。移行により、Cloud-native API Gateway が既存および今後の Ingress 構成を解析できるようになるだけです。

• 移行後も、既存および今後の Ingress 構成は、Cloud-native API Gateway が監視対象として設定している IngressClass に関連付けられたままにしておく必要があります。たとえば、Ingress 仕様の ingressClassName が nginx/higress/apig であった場合、移行後も既存および新規の Ingress 構成で nginx/higress/apig のままにしておく必要があります。

移行手順

Cloud-native API Gateway の「Migrate to Cloud」ツールを使用すると、ルート構成の移行および最終的なトラフィックスイッチングをガイド付きで実施できます。

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

1. API Gateway コンソール にログインします。

2. 左側のナビゲーションウィンドウで、Cloud Migration を選択します。

3. Cloud Migration ページで、タスクの作成 をクリックします。

4. Create Migration Configuration パネルで、パラメーターを設定します。

   Cloud-native API Gateway は、選択したコンテナクラスター内で指定されたソース IngressClass に関連付けられたすべての Ingress リソースを自動的に監視し、これらの Ingress リソースからドメイン名およびルート構成を適用します。

   重要

   対象の Cloud-native API Gateway がすでにこのコンテナクラスターに関連付けられているものの、そのクラスターで設定されている IngressClass がここで指定するものと異なる場合、移行は失敗します。ここで設定する IngressClass が、関連付け済みクラスターで既に設定されているものと一致することを確認してください。

   パラメーター	説明
   Instance	移行先のゲートウェイインスタンスを指定します。
   Source Cluster	移行対象の NGINX Ingress をホストするコンテナクラスターを選択します。Cloud-native API Gateway とコンテナクラスターが同一の Virtual Private Cloud (VPC) 内にあることを確認してください。
   API Name	インポートされた NGINX Ingress ルートを受信する Cloud-native API Gateway 内の HTTP API の名前です。
   resource	移行先のリソースグループを選択します。
   Namespace	移行対象の Ingress リソースの名前空間を指定します。
   IngressClass	移行対象の Ingress リソースに関連付けられた IngressClass を指定します。 説明 IngressClass は 1 つのみ指定可能です。 このパラメーターを空欄にした場合、ゲートウェイは IngressClass を無視し、クラスター内のすべての Ingress リソースを監視します。

5. 次へ をクリックします。

   この時点で、Cloud-native API Gateway は選択したコンテナクラスター内でソース IngressClass に関連付けられたすべての Ingress リソースの自動監視を開始し、これらの Ingress リソースから取得したドメイン名およびルート構成を新しく作成された API に適用します。

   1. たとえば、ソースコンテナクラスター内に nginx-route という名前の Ingress リソースがあると仮定します。

   2. Cloud-native API Gateway コンソール上では、ゲートウェイがソースクラスターから Ingress を自動同期し、対応するドメイン名およびルート構成を作成したことが確認できます。

ステップ 2：ルートの検証

検出された Ingress リソースの互換性を検証します。

• 互換性のない Ingress アノテーションが見つからない場合は、次のステップに進んでください。

• 互換性のない Ingress アノテーションが存在する場合は、まず HiClaw、CoPaw、または QoderWork などの AI ツールと公式移行スキル「alibabacloud-nginx-ingress-to-api-gateway」をご利用ください。このスキルは Ingress 構成を分析し、互換性のないアノテーションを置き換えるための Wasm プラグインを自動生成し、完全なランブックを作成します。引き続きご不明点がある場合は、チケットを送信してソリューションをご依頼ください。

  重要

  • アノテーション nginx.ingress.kubernetes.io/service-weight の値が空文字列 ("") の場合は、無視しても問題ありません。このアノテーションは旧バージョンの ACK コンソールでデフォルトで追加されており、機能上の効果はありません。

  • 移行中は、稼働中の Ingress 構成から互換性のないアノテーションを削除しないでください。これらのアノテーションは依然として NGINX Ingress Controller によって解析され、本番トラフィックに影響を与えています。

ステップ 3：トラフィックスイッチング方法の選択

トラフィックスイッチング前のテスト

本番トラフィックを切り替える前に、ローカルでのテストを実施することを推奨します。ローカルの hosts ファイルを編集して、サービスのドメイン名を Cloud-native API Gateway の Server Load Balancer (SLB) の IP アドレスに解決するように設定します。curl や Postman などのツールを使用して、すべてのトラフィックが正しくルーティングされることを確認してください。

トラフィックスイッチング方法の選択