Container Service for Kubernetes:ALB IngressについてのFAQ, ALB IngressについてのFAQ

目次

• ALB Ingressルールが有効にならないのはなぜですか?

• ALB IngressとNGINX Ingressの違いは何ですか?

• ALB Ingressは、デフォルトでkube-system-fake-svc-80サーバーグループに送信されたリクエストをリッスンします。 サーバーグループの目的は何ですか?

• ALB Ingressの内部アクセスと外部アクセスを同時に有効にできますか?

• クラスターでALB Ingressコントローラポッドを表示できないのはなぜですか。

• ALB Ingressによって使用されるALBドメイン名が変更されないようにするにはどうすればよいですか。

• ACK管理クラスターを作成するときにALB Ingressを使用すると、ALBインスタンスが自動的に作成されますか。

• ALBコンソールで行ったALB設定の変更が失われ、追加したルールが削除され、アクセスログが無効になるのはなぜですか。

• 転送ルールを作成した直後にALB Ingressの転送ルールを削除したときにHTTPステータスコード503が返された場合はどうすればよいですか?

• ALB Ingressでエラーが発生しないが、変更が有効にならない場合はどうすればよいですか?

• コンソールでALBインスタンスを作成し、kubectl applyコマンドを実行してAlbConfigのネットワークACL設定を更新した後、一部のリスナーが削除されるのはなぜですか。

• ポッドが1つ以上のサービスに対してスケーリングされている場合、サーバーの調整を高速化するにはどうすればよいですか。

• クラスターがFlannelネットワークプラグインを使用し、サービスに対してローカルモードが有効になっている場合に、システムがノードに自動的に重みを割り当てるようにするにはどうすればよいですか。

ALB Ingressルールが有効にならないのはなぜですか?

ALB Ingressはインラインモードでルーティングルールを維持します。 複数のALB Ingressが同じALBインスタンスを使用し、いずれかのALB Ingressの設定でエラーが発生した場合、他のALB Ingressは有効になりません。

作成したALB Ingressが有効にならない場合、現在のALB Ingressを作成する前に作成したALB Ingressでエラーが発生する可能性があります。 この場合、新しく作成されたALB Ingressが有効になるように、ALB Ingressを見つけてエラーを修正する必要があります。

ALB IngressとNGINX Ingressの違いは何ですか?

ALB Ingressの使用を推奨します。 手動でNGINX Ingressを維持する必要があります。 NGINX Ingressとは異なり、ALB Ingressは、フルマネージドのメンテナンス不要のクラウドサービスであるALBに基づいて開発されています。 ALB Ingressは、高性能ゲートウェイとして機能し、強力なIngressトラフィック管理機能を提供できます。 NGINX IngressとALB Ingressの比較の詳細については、「NGINX Ingress、ALB Ingress、およびMSE Ingressの比較」をご参照ください。

ALB Ingressは、デフォルトでkube-system-fake-svc-80サーバーグループに送信されたリクエストをリッスンします。 サーバーグループの目的は何ですか?

リスナーを作成する前に、デフォルトの転送ルールを作成する必要があります。 各転送ルールは、1つのサーバーグループにのみ関連付けることができます。 kube-system-fake-svc-80サーバーグループは偽物で、デフォルトの転送ルールで使用されます。 偽のサーバーグループはリクエストを処理しないため、削除できません。

ALB Ingressの内部アクセスと外部アクセスを同時に有効にできますか?

はい。ALB Ingressの内部アクセスと外部アクセスを同時に有効にできます。 これを行うには、インターネット向けALBインスタンスを作成する必要があります。 ALBインスタンスは、各ゾーンにelastic IPアドレス (EIP) を自動的に作成し、そのEIPを使用してインターネットと通信します。 ALBインスタンスには、プライベート仮想IPアドレス (VIP) も割り当てられます。 VIPを使用して、内部ネットワーク経由でALBインスタンスにアクセスできます。 ALB Ingressの内部アクセスのみを有効にする場合は、内部対応のALBインスタンスを作成できます。

クラスターでALB Ingressコントローラポッドを表示できないのはなぜですか。

クラスターがContainer Service for Kubernetes (ACK) 専用クラスターである場合にのみ、kube-system名前空間でALB Ingressコントローラポッドを表示できます。 ACK Basic、ACK Pro、およびACK Serverlessクラスターでは、ALB Ingressコントローラーポッドを表示できません。これは、ALB Ingressコントローラーがこれらのクラスターの完全管理コンポーネントであるためです。 ACK専用クラスターをACK Proクラスターにアップグレードする方法の詳細については、「ACK専用クラスターからACK Proクラスターへのホット移行」をご参照ください。

ALB Ingressによって使用されるALBドメイン名が変更されないようにするにはどうすればよいですか。

AlbConfigオブジェクトを使用してALBインスタンスを作成した後、ALB IngressはIngressClassを使用してAlbConfigオブジェクトを参照します。 これにより、ALB IngressはALBインスタンスのドメイン名を使用できます。 ALB IngressまたはAlbConfigオブジェクトに関連付けられているIngressClassを変更しない場合、ドメイン名は変更されません。

ACK管理クラスターを作成するときにALB Ingressを使用すると、ALBインスタンスが自動的に作成されますか。

ALBインスタンスは作成されません。 ACK管理クラスターの作成時にALB Ingressを使用すると、システムは自動的にALB Ingressコントローラーをインストールしますが、ALBインスタンスは作成しません。

ALBコンソールで行ったALB設定の変更が失われ、追加したルールが削除され、アクセスログが無効になるのはなぜですか。

ALB Ingressの設定を変更するには、クラスターのAPIサーバー上のALB IngressまたはAlbConfigオブジェクトに保存されている設定を変更する必要があります。 ALBコンソールでALB設定を変更した場合、変更はAPIサーバーに同期されません。 その結果、変更は有効になりません。 さらに、内部呼び出しまたはクラスタ操作は、ALB IngressまたはAlbConfigオブジェクトに保存された構成でALBコンソールのALB構成を上書きするACKをトリガーします。 したがって、ALB IngressオブジェクトまたはAlbConfigオブジェクトに保存されている設定を変更することを推奨します。

転送ルールを作成した直後にALB Ingressの転送ルールを削除したときにHTTPステータスコード503が返された場合はどうすればよいですか?

転送ルールに対応するALB Ingressにcanary:trueアノテーションが含まれているかどうかを確認します。 カナリアリリースを実行するには、古いサービスバージョンからカナリアバージョンにトラフィックをリダイレクトする必要があります。 したがって、古いサービスバージョンのALB Ingressにcanary:trueアノテーションを追加する必要はありません。 ALB Ingressを使用してカナリアリリースを実装する方法の詳細については、「ALB Ingressを使用してカナリアリリースを実行する」をご参照ください。

Canaryリリースは、2つのIngressと限られた数の転送条件のみをサポートします。 カスタム転送ルールを使用して、より柔軟な方法でトラフィックをルーティングすることを推奨します。 詳細については、「ALB Ingressのルーティングルールのカスタマイズ」をご参照ください。

ALB Ingressでエラーが発生しないが、変更が有効にならない場合はどうすればよいですか?

AlbConfigオブジェクトに関連する調整が実行されない場合、または構成変更イベントが処理されない場合、ALB IngressのIngressClassが間違ったAlbConfigオブジェクトに関連付けられる可能性があります。 ユーザーガイドに基づいて、IngressClassのparameters設定が正しく設定されているかどうかを確認します。 詳細については、「ALBインスタンスを構成するためにAlbConfigを使用する」トピックの「IngressClassを使用してAlbConfigオブジェクトをIngressに関連付ける」を参照してください。

コンソールでALBインスタンスを作成し、kubectl applyコマンドを実行してAlbConfigのネットワークACL設定を更新した後、一部のリスナーが削除されるのはなぜですか。

kubectl applyコマンドは、AlbConfigを上書きしてAlbConfigを更新します。したがって、kubectl applyコマンドを実行してAlbConfigのネットワークACL設定を更新するときは、YAMLファイルにAlbConfigで指定されたすべてのリスナーの設定が含まれていることを確認してください。それ以外の場合、一部のリスナーは削除されます。

kubectl applyコマンドの実行後にリスナーが削除された場合は、次の方法を使用してリスナーを復元することを推奨します。

1. YAMLファイルにすべてのリスナーの設定が含まれているかどうかを確認します。

   一部のリスナーが見つからない場合は、次のステップに進みます。 すべてのリスナーが含まれている場合、操作は必要ありません。

2. 次のコマンドを実行して、不足しているリスナーの設定をAlbConfigに追加します。

   kubectl -n <namespace> edit AlbConfig <albconfig-name> # Replace <namespace> with the name of the namespace to which the AlbConfig object belongs and <albconfig-name> with the name of the AlbConfig object.

ポッドが1つ以上のサービスに対してスケーリングされている場合、サーバーの調整を高速化するにはどうすればよいですか。

ポッドがACKクラスター内の1つ以上のサービスに対してスケーリングされる場合、サーバーの調整に消費される時間は、サービスに関連付けられているIngressの数によって異なります。 次の方法を使用して、サーバーの調整を高速化できます。

• Ingressの数を制限する: 各サービスに関連付けられているIngressが30個以下であることを確認します。

• Ingressルールのマージ: 使用するIngressの数が多すぎる場合は、複数のサービスを同じIngressに関連付け、IngressでIngressルールを作成して、サーバーの調整効率を向上させることができます。

クラスターがFlannelネットワークプラグインを使用し、サービスに対してローカルモードが有効になっている場合に、システムがノードに自動的に重みを割り当てるようにするにはどうすればよいですか??

この例では、Flannelネットワークプラグインがクラスターにインストールされ、ローカルモードが有効になっているため、ノードの重みを計算する方法が表示されます。 次の図は、app=nginxという名前のビジネスポッドが3つのECS (Elastic Compute Service) インスタンスにデプロイされ、サービスAに基づいて外部サービスを提供していることを示しています。