:ALB Ingressに関するFAQ

目次

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

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

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

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

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

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

• ACK マネージドクラスターを作成するときに ALB Ingress を使用すると、ALB インスタンスが自動的に作成されますか？

• SLB コンソールで行った ALB 構成の変更が失われたり、追加したルールが削除されたり、アクセスログが無効になったりする理由は何ですか？

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

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

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

• Service が Pod のスケーリングを実行するときに、サーバーの調整時間を短縮するにはどうすればよいですか？

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

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 トラフィック管理機能を提供できます。

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 コントローラー Pod を表示できないのはなぜですか？

クラスターが Container Service for Kubernetes (ACK) 専用クラスターの場合にのみ、kube-system ネームスペースで ALB Ingress コントローラー Pod を表示できます。ACK ベーシック、ACK プロ、および Alibaba Cloud Container Compute Service (ACS) クラスターでは、ALB Ingress コントローラーはフルマネージドコンポーネントであるため、ALB Ingress コントローラー Pod を表示できません。

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

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

ACK マネージドクラスターを作成するときに ALB Ingress を使用すると、ALB インスタンスが自動的に作成されますか？

いいえ、ALB インスタンスは作成されません。ACK マネージドクラスターを作成するときに ALB Ingress を使用することを選択した場合、システムは ALB Ingress コントローラーを自動的にインストールしますが、ALB インスタンスは作成しません。

SLB コンソールで行った ALB 構成の変更が失われたり、追加したルールが削除されたり、アクセスログが無効になったりする理由は何ですか？

ALB Ingress の構成を変更するには、クラスターの API サーバーに保存されている ALB Ingress または AlbConfig に保存されている構成を変更する必要があります。ALB コンソールで ALB 構成を変更した場合、変更は API サーバーに同期されません。その結果、変更は有効になりません。また、内部呼び出しまたはクラスター操作によって、ACS が ALB コンソールの ALB 構成を ALB Ingress または AlbConfig に保存されている構成で上書きします。ALB Ingress または AlbConfig に保存されている構成を変更することをお勧めします。

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

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

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

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

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

コンソールで 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> # <namespace> と <albconfig-name> を AlbConfig のネームスペースと AlbConfig の名前に置き換えます。

Service が Pod のスケーリングを実行するときに、サーバーの調整時間を短縮するにはどうすればよいですか？

ACK クラスター内の Service が Pod のスケーリングを実行する場合、サーバーの調整時間は Service に関連付けられている Ingress の数によって異なります。サーバーの調整時間を短縮するには、次の方法を使用できます。

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

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

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

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