このトピックでは、Application Load Balancer (ALB) Ingressに関するよくある質問に対する回答を提供します。
目次
ALB Ingressは、デフォルトでkube-system-fake-svc-80サーバーグループに送信されたリクエストをリッスンします。 サーバーグループの目的は何ですか?
ACKマネージドクラスターを作成するときにALB Ingressを使用することを選択した場合、ALBインスタンスは自動的に作成されますか?
転送ルールを作成した直後にALB Ingressの転送ルールを削除したときにHTTP 503ステータスコードが返された場合はどうすればよいですか?
コンソールでALBインスタンスを作成し、kubectl applyコマンドを実行してAlbConfigのネットワークACL設定を更新した後、一部のリスナーが削除されるのはなぜですか。
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 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設定が適切に設定されているかどうかを確認します。 詳細については、「IngressClassを使用してAlbConfigオブジェクトをIngressに関連付ける」をご参照ください。
コンソールでALBインスタンスを作成し、kubectl applyコマンドを実行してAlbConfigのネットワークACL設定を更新した後、一部のリスナーが削除されるのはなぜですか。
kubectl editコマンドを実行してリソースを更新することを推奨します。 kubectl applyコマンドを使用してリソースを更新するには、kubectl diffコマンドを実行して変更をプレビューし、変更が要件を満たしていることを確認してから、kubectl applyコマンドを実行します。 次に、kubectl applyコマンドを実行して、クラスター内のリソースに変更を適用できます。
kubectl applyコマンドは、AlbConfigを上書きして更新します。 したがって、kubectl applyコマンドを実行してAlbConfigのネットワークACL設定を更新するときは、YAMLファイルにAlbConfigで指定されたすべてのリスナーの設定が含まれていることを確認してください。それ以外の場合、一部のリスナーは削除されます。
kubectl applyコマンドの実行後にリスナーが削除された場合は、次の方法を使用してリスナーを復元することを推奨します。
YAMLファイルにすべてのリスナーの設定が含まれているかどうかを確認します。
一部のリスナーが見つからない場合は、次のステップに進みます。 すべてのリスナーが含まれている場合、操作は必要ありません。
次のコマンドを実行して、不足しているリスナーの設定をAlbConfigに追加します。
kubectl -n <namespace> edit AlbConfig <albconfig-name> # Replace <namespace> and <albconfig-name> with the namespace of the AlbConfig object and the name of the AlbConfig object.
1つ以上のサービスがポッドのスケーリングを実行するときにサーバーの調整時間を短縮するにはどうすればよいですか。
ACKクラスター内のサービスがポッドのスケーリングを実行する場合、サーバーの調整時間は、サービスに関連付けられているIngressの数によって異なります。 次の方法を使用して、サーバーの調整時間を短縮できます。
Ingressの数を制限する: 各サービスに関連付けられているIngressが30個以下であることを確認します。
Ingressルールのマージ: 使用するIngressの数が多すぎる場合は、複数のサービスを同じIngressに関連付け、IngressでIngressルールを作成して、サーバーの調整効率を向上させることができます。