Ingress（ NGINX ）からTraefik Ingressコントローラーへの移行

Ingressの設定を移行し、Ingress- NGINX コントローラーの代わりにTraefikコントローラーを使用するようにしてください。

開始前に

移行を行う前に、これらの前提条件を確認してください。

  1. 必要な権限が与えられていることを確認してください。

    • クラスターに対する管理者のプラットフォーム・アクセス役割
    • すべての名前空間に対するマネージャーのサービス・アクセス役割

  2. Ingress- NGINX に固有の注釈や設定について、既存のIngressリソースを確認してください。 2つのIngressコントローラーの主な違い について、ドキュメントを確認してください。

  3. ワークロードの要件、ダウンタイムの許容範囲、およびリソースの可用性に基づいて、移行戦略を策定してください。 移行中は、両方のコントローラーを同時に実行することができます。

  4. 高可用性を確保するため、クラスタにはゾーンごとに少なくとも2つのワーカーノードが配置されていることを確認してください。

  5. 変更を行う前に、現在のIngressの設定をバックアップしてください。

戦略 1：別のドメインを使用して Ingress の設定を分離する

本番環境をIngressのまま維持しつつ、別の環境でTraefikをテストする - NGINX。 この戦略により、最大限の隔離と安全が確保されます。

次のような場合にこの戦略を活用してください：

  • 本番環境のワークロードを移行する前に、Traefikを徹底的にテストしておく必要があります。
  • テスト用に、別のアプリケーションセットをデプロイすることができます。
  • 追加のALBを稼働させるためのリソースは十分にあります。
  • テスト中は、本番環境へのリスクをゼロにしたいと考えています。

ステップ

  1. 利用可能なTraefikのバージョンを確認する。
    ibmcloud ks ingress alb versions
  2. Traefik を使用して新しい ALB を作成します。

定番のクラスター sh {: pre} ibmcloud ks ingress alb create classic --cluster CLUSTER_NAME --type PUBLIC_OR_PRIVATE --zone ZONE --vlan VLAN_ID --version TRAEFIK_VERSION VPCクラスター sh {: pre} ibmcloud ks ingress alb create vpc-gen2 --cluster CLUSTER_NAME --type PUBLIC_OR_PRIVATE --zone ZONE --version TRAEFIK_VERSION

  1. VPCクラスターについては、テスト用に LoadBalancer サービスを別途手動でデプロイしてください。 spec.selector を設定し、 app.kubernetes.io/vpcComponent: public-cr<cluster_id>-traefik （プライベート ALB の場合は private-cr<cluster_id>-traefik ）を含めるようにします。 Classicクラスターでは、新しいロードバランサーが自動的にプロビジョニングされるため、追加の設定は不要です。

  2. Traefik ALB 用のカスタムドメインを作成し、そのドメインをロードバランサーのホスト名または IP アドレスに設定します。 詳しい手順については、「 カスタムドメインの作成 」をご覧ください。

  3. TraefikのIngressクラスを使用して、テスト用アプリケーションのIngressリソースを作成します。 ステップ 3: Ingress リソースを作成する をフォローし、 ingressClassName: public-iks-traefik （プライベート ALB の場合は private-iks-traefik ）を指定してください。

  4. Traefik ドメイン経由でアプリケーションをテストし、機能が正常に動作することを確認します。

  5. テストが完了したら、「 切り替え 」に進み、本番環境のワークロードを移行してください。

戦略 2：同じワークロードを処理する 2 台のロードバランサー

同じサービスを指す 2 つの Ingress リソースを作成し、両方のコントローラーを同じワークロードでテストします。 本番環境のトラフィックに影響を与えることなく、コントローラーの動作を直接比較することができます。

次のような場合にこの戦略を活用してください：

  • 同じワークロードにおいて、Ingress（ NGINX ）とTraefikの挙動を比較したいと考えています。
  • Traefik が特定のアプリケーションを正しく処理しているかどうかを確認する必要があります。
  • 本番環境以外のドメインを使ってテストすることができます。
  • 必要なテストアプリケーションの数を最小限に抑えたいと考えています。

ステップ

  1. Traefik ベースのバージョンを使用して、新しい ALB を有効にします。

定番のクラスター sh {: pre} ibmcloud ks ingress alb create classic --cluster CLUSTER_NAME --type PUBLIC_OR_PRIVATE --zone ZONE --vlan VLAN_ID --version TRAEFIK_VERSION VPCクラスター sh {: pre} ibmcloud ks ingress alb create vpc-gen2 --cluster CLUSTER_NAME --type PUBLIC_OR_PRIVATE --zone ZONE --version TRAEFIK_VERSION

  1. VPCクラスターについては、テスト用に LoadBalancer サービスを別途手動でデプロイしてください。 spec.selector を設定し、 app.kubernetes.io/vpcComponent: public-cr<cluster_id>-traefik （プライベート ALB の場合は private-cr<cluster_id>-traefik ）を含めるようにします。 Classicクラスターでは、新しいロードバランサーが自動的にプロビジョニングされるため、追加の設定は不要です。

  2. Traefik ALB 用のカスタムドメインを作成し、そのドメインをロードバランサーのホスト名または IP アドレスに設定します。 詳しい手順については、「 カスタムドメインの作成 」をご覧ください。

  3. TraefikのIngressクラスを使用しつつ、既存のIngressリソース（ NGINX ）と同じサービスを指す、2つ目のIngressリソースを作成します。 「 ステップ 3: Ingress リソースの作成 」の手順に従い、以下の点に注意してください：

    • ingressClassName: public-iks-traefik （プライベートALBの場合は private-iks-traefik ）を指定してください
    • 既存の Ingress（ NGINX ）リソースで使用しているのと同じ service.name 値を使用してください
    • 「 host 」および「 tls.hosts 」の各フィールドには、テスト用ドメインを入力してください

  4. 両方のドメインでアプリケーションをテストしてください。

    • Ingressのドメイン「 NGINX 」（本番環境）経由でアクセスしてください
    • Traefik ドメイン（testing）経由でのアクセス

  5. 2つのコントローラーの動作、性能、および機能を比較してください。

  6. 検証が完了したら、「 切り替えの手順 」に進み、本番環境のドメインをTraefikに移行してください。

戦略 3：スプリット DNS のテスト

スプリットDNSの設定を利用して、ユーザーに影響を与えることなく、本番環境に近い環境で本番ドメインを使用してTraefikをテストしてください。

次のような場合にこの戦略を活用してください：

  • 本番環境のドメインを使ってテストしたいですね。
  • テスト環境のDNS設定は、ご自身で管理できます。
  • 正確な本番環境の構成を確認する必要があります。
  • テスト環境と本番環境の差異を最小限に抑えたい。

ステップ

  1. Traefik ベースのバージョンを使用して、新しい ALB を有効にします。

定番のクラスター sh {: pre} ibmcloud ks ingress alb create classic --cluster CLUSTER_NAME --type PUBLIC_OR_PRIVATE --zone ZONE --vlan VLAN_ID --version TRAEFIK_VERSION VPCクラスター sh {: pre} ibmcloud ks ingress alb create vpc-gen2 --cluster CLUSTER_NAME --type PUBLIC_OR_PRIVATE --zone ZONE --version TRAEFIK_VERSION

  1. VPCクラスターについては、テスト用に LoadBalancer サービスを別途手動でデプロイしてください。 spec.selector を設定し、 app.kubernetes.io/vpcComponent: public-cr<cluster_id>-traefik （プライベート ALB の場合は private-cr<cluster_id>-traefik ）を含めるようにします。 Classicクラスターでは、新しいロードバランサーが自動的にプロビジョニングされるため、追加の設定は不要です。

  2. 新しい Traefik ALB の IP アドレス（従来型）またはホスト名（VPC）を取得します。

    ibmcloud ks ingress alb ls --cluster CLUSTER_NAME

  3. テスト環境でスプリットDNSを設定してください。

    • テスト用マシンやネットワークでは、本番環境のドメインがTraefik ALBのIPアドレスまたはホスト名に解決されるよう、DNSを設定してください
    • 本番環境のユーザーは、引き続き Ingress（ NGINX ）ALB にリダイレクトされています
    • これは、ローカルの /etc/hosts ファイル、内部DNSサーバー、またはVPN固有のDNS設定を通じて行うことができます

  4. 本番環境のドメインを使用して、TraefikのIngressクラスを使って新しいIngressリソースを作成します。 ステップ 3: Ingress リソースを作成する にアクセスし、「 host 」および「 tls.hosts 」の各フィールドに、 ingressClassName: public-iks-traefik （プライベートALBの場合は private-iks-traefik ）と本番環境のドメインを指定してください。

  5. スプリットDNS環境からテストを行い、本番環境のドメインと設定でTraefikが正常に動作することを確認してください。

  6. 検証が完了したら、「 切り替え 」に進み、本番環境のDNS設定をTraefikを指すように更新してください。

戦略4：直接移行

Ingress（ NGINX ）からTraefikへ、設定の変更やリソース管理を最小限に抑えて直接移行できます。

この戦略では、移行中にサービスが中断されます。 作業を開始する前に、メンテナンスの時間を確保しておいてください。

次のような場合にこの戦略を活用してください：

  • 処理量が少ない場合や、重要度の低いアプリケーションがある場合。
  • 移行中は、短時間のサービス停止であれば許容できます。
  • 管理すべきリソースの数を最小限に抑えたいと考えています。
  • 別の環境で、Traefikとの互換性はすでに確認済みです。
  • Classic では、クライアントが DNS ドメインではなく IP アドレスを使用して接続するため、ALB の IP アドレスを変更しないようにする必要があります。

ALB を無効にしてから再度有効にしても、その間に他のサービスがその IP アドレスを取得していない限り、元の IP アドレスは維持されます。 詳細については、「 ALB の有効化または無効化 」を参照してください。

ステップ

  1. 現在使用中の Ingress- NGINX ALB の ID を取得してください。

    ibmcloud ks ingress alb ls --cluster CLUSTER_NAME

  2. Ingress- NGINX ALB を無効にします。

    ibmcloud ks ingress alb disable --alb ALB_ID --cluster CLUSTER_NAME

    VPC クラスター ：最後のパブリックまたはプライベート ALB を無効にした場合は、ALB のデプロイおよび対応するロードバランサー・サービス・リソースが削除されるのを待ってから、Traefik ALB を有効にしてください。

  3. Traefikのバージョンを指定してALBを有効にします。

定番のクラスター sh {: pre} ibmcloud ks ingress alb enable classic --alb ALB_ID --version TRAEFIK_VERSION --cluster CLUSTER_NAME Classic 環境の ALB で特定の IP アドレスを使用するには、 --ip フラグを使用してください。 詳細については、「 ALB の有効化または無効化 」を参照してください。

[VPCクラスター]{: tag-vpc}
```sh {: pre}
ibmcloud ks ingress alb enable vpc-gen2 --alb ALB_ID --version TRAEFIK_VERSION --cluster CLUSTER_NAME
```
  1. VPCクラスターの場合、ロードバランサーのバックエンドをTraefikに設定してください。

VPCクラスター sh {: pre} ibmcloud ks ingress load-balancer backend set --cluster CLUSTER-ID --public-backend traefik [--private-backend traefik]

  1. Ingress リソースを更新し、Traefik の Ingress クラスを使用するようにしてください。 リソースで Ingress クラスが明示的に設定されている場合は、 spec.ingressClassName を public-iks-k8s-nginx から public-iks-traefik に変更してください（プライベート ALB の場合は、 private-iks-k8s-nginx から private-iks-traefik に変更してください）。

  2. 更新されたIngressリソースを適用してください。

    kubectl apply -f ingress.yaml

  3. Traefik コントローラー経由でアプリケーションにアクセスできることを確認してください。

    curl https://<domain>/<app_path>

Traefikへの移行

テスト終了後、本番トラフィックをTraefikコントローラー経由に切り替えてください。 手順は、クラシック・クラスターとVPCクラスターで異なります。 お使いのクラスタの種類や構成に合ったオプションを選択してください。

クラシック・クラスター

従来のクラスターについては、本番環境のドメイン設定を更新し、Ingress ではなく Traefik を公開しているロードバランサーを指すようにしてください — NGINX。

オプション 1：ドメインのマッピングを更新する

  1. Traefik ALBのIPアドレスを取得してください。
    ibmcloud ks ingress alb ls --cluster CLUSTER_NAME
  2. ドメインの設定を更新し、Traefik ALB を指すようにしてください。
    ibmcloud ks ingress domain update --cluster CLUSTER_NAME --domain DOMAIN_NAME --ip TRAEFIK_ALB_IP
  3. ドメインの更新を確認してください。
    ibmcloud ks ingress domain ls --cluster CLUSTER_NAME
  4. 本番環境のドメインを通じてアプリケーションをテストし、Traefik によって正常に提供されていることを確認してください。

オプション 2: Ingress の無効化 - NGINX ALB

あるいは、Ingress- NGINX に基づくすべての ALB を無効にすることも可能です。これにより、ドメインのマッピングが自動的に更新されます。

  1. すべてのALBを一覧表示し、Ingress- NGINX に基づくものを特定してください。
    ibmcloud ks ingress alb ls --cluster CLUSTER_NAME
  2. 各Ingress（ NGINX ）ALBを無効化します。
    ibmcloud ks ingress alb disable --alb NGINX_ALB_ID --cluster CLUSTER_NAME
  3. ドメインがTraefik ALBを指すようになっていることを確認してください。
    ibmcloud ks ingress domain ls --cluster CLUSTER_NAME

オプション 3: ALB の IP アドレスを維持する

クライアントがDNS名ではなくALBのIPアドレスに直接接続している場合、移行の際にもそれらのIPアドレスを維持することができます。 IPアドレスを保持するには、ALBを一時的に無効にする必要があり、これによりサービスが一時的に中断されます。

ALB を無効にしてから再度有効にしても、その IP アドレスが他のサービスによって使用されていない限り、元の IP アドレスは維持されます。

  1. すべてのALBを一覧表示し、Ingress（ NGINX ）ベースのものを特定して、それらのIDとIPアドレスを取得します。

    ibmcloud ks ingress alb ls --cluster CLUSTER_NAME

  2. Ingress- NGINX ALB を無効にします。 これにより、そのIPアドレスへのトラフィックにおいて、一時的なサービス停止が発生します。

    ibmcloud ks ingress alb disable --alb ALB_ID --cluster CLUSTER_NAME

  3. 同じIPアドレスを再利用するために、Traefikのバージョンを指定してALBを再度有効にしてください。

    ibmcloud ks ingress alb enable classic --alb ALB_ID --version TRAEFIK_VERSION --cluster CLUSTER_NAME

    あるいは、新しいALBを作成し、 --ip フラグを使用して元のIPアドレスを再利用することもできます。

  4. Ingress リソースを更新し、Traefik の Ingress クラスを使用するようにしてください。 リソースで Ingress クラスが明示的に設定されている場合は、 spec.ingressClassName を public-iks-k8s-nginx から public-iks-traefik に変更してください（プライベート ALB の場合は、 private-iks-k8s-nginx から private-iks-traefik に変更してください）。

  5. 更新されたIngressリソースを適用してください。

    kubectl apply -f ingress.yaml

  6. Traefik コントローラー経由でアプリケーションにアクセスできることを確認してください。

    curl https://<domain>/<app_path>

VPC クラスター

VPC クラスターの場合は、Ingress の代わりに Traefik を公開するように、ロードバランサーのバックエンドを更新してください — NGINX。

オプション 1：ロードバランサーのバックエンドを更新する

  1. ロードバランサーを更新し、Traefikのバックエンドを使用するように設定します。
    ibmcloud ks ingress load-balancer backend set --cluster CLUSTER_NAME --public-backend traefik [--private-backend traefik]
  2. ロードバランサーの設定を確認してください。
    ibmcloud ks ingress load-balancer get --cluster CLUSTER_NAME
  3. アプリケーションがTraefikによって提供されていることを確認するために、テストを行ってください。

オプション 2: Ingress の無効化 - NGINX ALB

あるいは、Ingress- NGINX に基づくすべての ALB を無効にすることもできます。

  1. すべてのALBを一覧表示し、Ingress- NGINX に基づくものを特定してください。
    ibmcloud ks ingress alb ls --cluster CLUSTER_NAME
  2. 各Ingress（ NGINX ）ALBを無効化します。
    ibmcloud ks ingress alb disable --alb NGINX_ALB_ID --cluster CLUSTER_NAME
  3. ロードバランサーがTraefik ALBを使用していることを確認してください。
    ibmcloud ks ingress load-balancer get --cluster CLUSTER_NAME

マイグレーション後のタスク

Traefik への移行後、以下のタスクを完了してください：

  1. 移行後は、アプリケーションに予期せぬ動作やエラーがないか監視してください。

  2. Traefik を使用した新しい Ingress の設定を反映させるため、内部ドキュメントを更新する。

  3. 不要になったテスト用のALB、ドメイン、またはIngressリソースをすべて削除してください。

  4. Traefikが期待通りに動作することを確認した後、残りのIngress- NGINX ALBを無効にしてください。

    ibmcloud ks ingress alb disable --alb NGINX_ALB_ID --cluster CLUSTER_NAME

トラブルシューティング

移行中または移行後に問題が発生した場合は、以下の手順に従って原因を特定し、解決してください。

イングレスクラスを確認する

Ingress リソースが正しい Traefik クラス（public-iks-traefik または private-iks-traefik ）を使用していることを確認してください。

ALBのステータスを確認する

Traefik ALB が正常な状態にあることを確認してください。

ibmcloud ks ingress alb ls --cluster CLUSTER_NAME
Ingressのステータスを確認する

Ingressのリソースの状態を確認してください。

kubectl get ingress -A
ログの確認

Traefik コントローラーのログにエラーがないか確認してください。

kubectl logs -n kube-system -l alb-image-type=traefik
診断の実行

Ingressのステータスレポートを使用して、問題を特定してください。

ibmcloud ks ingress status-report get --cluster CLUSTER_NAME
必要に応じて元に戻す

NGINX 重大な問題が発生した場合は、Traefik ALB を無効にし、元のバージョンの Ingress- NGINX ALB を再度有効にして、Ingress- に戻してください。 問題を解決し、再度移行を行う計画を立てる。

さらにサポートが必要な場合は、「 Ingressのトラブルシューティング 」を参照するか、 IBM Cloud サポートまでお問い合わせください。