Container Service for Kubernetes:ALB Ingress に関するよくある質問

ALB Ingress はパブリックネットワークアクセスと内部ネットワークアクセスの両方をサポートしていますか？

ALB Ingress が固定 ALB ドメイン名を使用するようにするにはどうすればよいですか？

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

症状

クラスタ内で ALB Ingress Controller ポッドを検索しても、kube-system 名前空間に関連するポッドが見つかりません。

解決策

ACK 専用クラスターでのみ、kube-system 名前空間で ALB Ingress Controller ポッドを見つけることができます。ACK 標準クラスター、ACK Pro マネージドクラスター、および Serverless Kubernetes クラスターの場合、ALB Ingress Controller コンポーネントは Alibaba Cloud によって管理されます。したがって、クラスタ内でポッドを見つけることはできません。ACK 専用クラスターを ACK Pro マネージドクラスターにアップグレードする方法の詳細については、「ACK 専用クラスターを ACK Pro クラスターにホットマイグレーションする」をご参照ください。

IP ベースのサーバーをマウントするにはどうすればよいですか？

apiVersion: v1
kind: Service
metadata:
  annotations:
    alb.ingress.kubernetes.io/server-group-type: Ip
  name: tea-svc
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    app: tea
  type: ClusterIP

症状

ALB Ingress ルールを作成した後、ルーティングルールが期待どおりに有効になりません。リクエストは対応するバックエンドサービスに転送されません。

原因

ALB インスタンスは、ルーティングルールをシリアル方式で維持します。これは、複数の ALB Ingress が同じ ALB インスタンスを使用する場合、1 つの ALB Ingress の構成エラーにより、他の ALB Ingress への変更が有効にならないことを意味します。

解決策

作成した ALB Ingress が有効にならない場合は、以前に作成した ALB Ingress にエラーがある可能性があります。新しい ALB Ingress を有効にする前に、障害のある ALB Ingress を修正する必要があります。

症状

ALB Ingress の構成を変更したり、AlbConfig に関連付けたりした後、変更が有効になりませんが、異常なアクティビティは報告されません。

解決策

AlbConfig に関連する調整イベントが実行されないか、変更イベントが処理されない場合、IngressClass と AlbConfig の間のバインディングが正しくない可能性があります。IngressClass で指定された parameters パラメータが正しいかどうかを確認してください。詳細については、「IngressClass を使用して AlbConfig を Ingress に関連付ける」をご参照ください。

症状

ALB Ingress 転送ルールは、作成直後に削除されます。その結果、サービスへのリクエストは 503 状態コードを返し、トラフィックは配信されません。

解決策

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

カナリアリリース方式は 2 つの Ingress のみをサポートしており、制限があります。カスタム転送ルールを使用することで、より柔軟なトラフィックルーティングソリューションを実現できます。詳細については、「ALB Ingress の転送ルールをカスタマイズする」をご参照ください。

症状

ポート 80 以外のポートにアクセスしようとすると、リクエストが接続に失敗します。AlbConfig リソースが「listener is not exist in alb, port: xxx」エラーを報告します。このエラーは、関連するポートがリッスンされておらず、トラフィックが転送されていないことを示しています。

解決策

デフォルトでは、AlbConfig にはポート 80 のリスナーのみが含まれています。他のポートをリッスンするには、それらのポートのリスナー構成を AlbConfig に追加する必要があります。詳細については、「リスナーを作成する」をご参照ください。

症状

AlbConfig で HTTP リスナーポートと HTTPS リスナーポートを構成しました。しかし、サービスにアクセスしようとすると、HTTP ポートも HTTPS ポートもトラフィックを listen または転送していません。これらのポートを介してサービスにアクセスできません。

解決策

Ingress リソースのアノテーションに alb.ingress.kubernetes.io/listen-ports アノテーションを追加したことを確認します。このアノテーションは、ALB Ingress が HTTP（80）ポートと HTTPS（443）ポートの両方で listen することを指定します。次に例を示します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: https-ingress
  annotations:
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS": 443}]' # 複数のリスナーを使用する場合に ALB Ingress が正しく機能するように、このアノテーションを追加します。
spec:
  #...

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

調整中に「指定されたパラメータ配列に含まれるアイテムが多すぎます。最大 15 アイテムです。証明書が無効です」というエラーが表示されるのはなぜですか。

コンソールで ALB インスタンスを構成した後、kubectl apply コマンドを実行して AlbConfig のアクセス制御リスト（ACL）構成を更新すると、一部のリスナーが削除されるのはなぜですか。

問題

Kubernetes 環境では、サービスに関連付けられたポッドがスケールインまたはスケールアウトすると、サーバーの調整プロセスに時間がかかる場合があります。この遅延は、弾性スケーリングのリアルタイムパフォーマンスに影響します。調整時間は、関連付けられた Ingress の数が増えるにつれて大幅に増加します。

解決策

サーバー調整の効率を向上させるには、次の最適化を適用できます。

• Ingress の数を制限する: 1 つのサービスに 30 を超える Ingress をアタッチしないでください。

• Ingress ルールをマージする: Ingress が多数ある場合は、複数のサービスを 1 つの Ingress にアタッチできます。次に、その Ingress リソース内で複数の転送ルールを定義して、サーバー調整のパフォーマンスを向上させることができます。

問題

Flannel ネットワークプラグインを使用し、ローカルモードでサービスを構成すると、トラフィックはノード間で均等に分散されません。この不均衡は、一部のノードで高負荷を引き起こし、トラフィックのバランスの取れた分散を妨げます。目標は、より効果的なトラフィック分散のために、各ノードのポッド数に基づいてノードに重みを自動的に割り当てることです。

解決策

Flannel プラグインを使用するクラスタでは、サービスがローカルモードに設定されている場合、ノードの重みは次のように計算されます。次の図は、アプリケーションポッド (app=nginx) が 3 つの ECS インスタンスにデプロイされ、サービス A を介して公開されている例を示しています。