Container Service for Kubernetes:ALB Ingress のよくある質問

問題

実際のシナリオでは、パブリックネットワークとプライベートネットワークの両方から ALB Ingress にアクセスする必要があります。しかし、ALB Ingress が両方を同時にサポートしているかどうかが不明です。

解決策

はい、サポートしています。パブリックネットワークとプライベートネットワークの両方のアクセスを使用するには、パブリック ALB インスタンスを作成します。インスタンスは各ゾーンに Elastic IP アドレス (EIP) を作成します。ALB はこれらの EIP をパブリックネットワーク通信に使用します。インスタンスはプライベート仮想 IP アドレス (VIP) も提供します。このプライベート VIP を使用して、プライベートネットワーク経由で ALB にアクセスします。プライベートネットワークアクセスのみが必要な場合は、プライベート ALB インスタンスを作成します。

問題

クラスター内で ALB Ingress Controller の Pod を検索しても、kube-system 名前空間に関連する Pod が見つかりません。標準的な方法では ALB Ingress Controller コンポーネントを表示できません。

解決策

kube-system 名前空間で ALB Ingress Controller の Pod が表示されるのは、ACK 専用クラスターのみです。ACK Basic Edition、ACK Pro Edition、および ACK Serverless は ALB Ingress Controller コンポーネントを完全に管理しているため、これらのクラスターでは Pod は表示されません。ACK 専用クラスターを ACK マネージドクラスター Pro 版にアップグレードする手順については、「ACK 専用クラスターから ACK マネージドクラスター Pro 版へのホットマイグレーション」をご参照ください。

問題

バックエンド Pod を IP アドレスで ALB にアタッチしたいと考えています。しかし、デフォルトでは、Service は IP ベースのサーバーグループを自動的に作成しません。これにより、バックエンドサービスへのトラフィック分散が制限されます。

解決策

Service にアノテーション alb.ingress.kubernetes.io/server-group-type: Ip を追加します。これにより、Service 用に IP ベースのサーバーグループが作成されます。その後、バックエンド Pod を IP アドレスで ALB に登録できます。

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

原因

WAF コンソールで ALB インスタンスの WAF 保護を手動で有効にした後、ALB Ingress Controller はリコンサイル中に、ALB インスタンスの実際のエディションが AlbConfig で宣言されたエディションフィールドと一致しないことを検出します。AlbConfig が明示的に edition: StandardWithWaf を指定していない場合、Controller はインスタンスをデフォルトの Standard Edition に戻します。これにより、WAF が Standard Edition にダウングレードされます。

解決策

WAF Enhanced Edition を維持するには、新しい ALB インスタンスを作成するか、既存のインスタンスの設定を変更する際に、AlbConfig のエディションフィールドを明示的に StandardWithWaf に設定します。

原因

• 503 (Service Temporarily Unavailable) エラー

  • 一致するルーティングルールがない： リクエストパスが Ingress で設定されたルーティングルールと一致しません。

  • 正常なバックエンド Pod がない： サービスに関連付けられたすべての Pod が準備完了でないか、存在しません。これにより、エンドポイントオブジェクトが空になります。

• 502 (Bad Gateway) エラー

  HTTP または HTTPS リスナーがクライアント接続リクエストを受信します。ALB インスタンスがリクエストを Pod に転送できないか、Pod から応答を受信できない場合、インスタンスはクライアントに HTTP 502 Bad Gateway ステータスコードを送信します。

• 404 (Not Found) エラー

  これは通常、リクエストが Ingress で定義されたルーティングルールに一致したが、Pod 内のアプリケーションが提供する実際のサービス URL とは一致しないことを意味します。

• 400 (Bad Request) エラー

  これは、HTTPS リスナーに HTTP リクエストが送信されるなど、さまざまな理由で発生する可能性があります。

その他の HTTP エラーコードについては、「ALB ステータスコード」をご参照ください。

解決策

1. Ingress のステータスを確認します。kubectl describe ingress <ingress-name> -n <namespace> コマンドを実行し、Events セクションでエラーメッセージを調べます。例えば、listener does not exist in alb のようなイベントが表示された場合は、AlbConfig で Ingress リソースに必要なリスナーを作成する必要があります。

   ...
   Events:
     Type     Reason                  Age     From     Message
     ----     ------                  ----    ----     -------
     Warning  FailedBuildModel        ****    ingress  listener is not exist in alb, port: 443, protocol: HTTPS
     Warning  FailedBuildModel        ****    ingress  listener not found for (443/HTTPS), with ingresses 1
   ...

2. バックエンドエンドポイントを確認します。kubectl get endpoints <service-name> -n <namespace> コマンドを実行して、ENDPOINTS フィールドに少なくとも 1 つの正常な Pod の IP アドレスとポートが含まれていることを確認します。フィールドが空の場合は、サービスの selector が Pod の labels と一致していることを確認し、Pod が Running 状態であることを確認します。

3. Pod のステータスとログを確認します。まず、kubectl get pod -l <app=your-app> -n <namespace> コマンドを実行して、アプリケーション Pod のステータスを確認します。次に、kubectl logs <pod-name> -n <namespace> を実行して、特定の Pod のログを調べ、起動の失敗やリクエスト処理のエラーがないか確認します。

4. ネットワーク接続をテストします。別の Pod 内から、またはノードから直接 curl を使用して、バックエンドサービスの ClusterIP または直接 Pod IP にアクセスします。これにより、サービスがクラスター内から到達可能であることが確認されます。

原因

• ALB インスタンスがポート 443 をリッスンしていない。Ingress に TLS 暗号化を設定しましたが、対応する HTTPS:443 リスナーが作成されていません。

• 証明書の設定が正しくない。Secret のタイプが kubernetes.io/tls または IngressTLS ではない、または data フィールドの tls.crt と tls.key の内容が正しくないか、一致していません。

• 証明書の更新が反映されていない。Alibaba Cloud Certificate Management Service で証明書を更新しましたが、AlbConfig で指定された証明書 ID を更新していないか、自動証明書検出のリコンサイルがトリガーされませんでした。その結果、ALB インスタンスはまだ古い証明書を参照しています。

解決策

1. リスナーポートを確認します。kubectl describe albconfig <alb-name> -n <namespace> コマンドを実行して、spec.listeners.port: 443 と spec.listeners.protocol: HTTPS の設定が欠落していないか確認します。

2. Ingress の設定を確認します。Ingress の設定に alb.ingress.kubernetes.io/listen-ports: [{"HTTP": 80}, {"HTTPS": 443}] アノテーションが欠落していないか確認します。このアノテーションは、Ingress を HTTP および HTTPS リスナーに関連付けます。

3. Secret の設定を確認します。Ingress 設定の spec.tls の secretName フィールドを確認し、正しい Secret が参照されていることを確認します。kubectl get secret <secret-name> -n <namespace> -o yaml コマンドを実行して、Secret のタイプとデータ整合性を確認します。

問題

新しい ALB Ingress ルールを作成した後、期待どおりに有効になりません。トラフィックが意図したバックエンドサービスに転送されません。

原因

ALB インスタンスはルーティングルールをシリアル順に維持します。複数の ALB Ingress リソースが同じ ALB インスタンスを使用している場合、1 つの ALB Ingress の設定ミスが、他のすべての ALB Ingress の変更が有効になるのを妨げます。

解決策

ALB Ingress が有効にならない場合、以前の ALB Ingress に設定ミスがある可能性があります。まず、設定ミスのある ALB Ingress を修正してください。そうすれば、新しい ALB Ingress が有効になります。

問題

ALB Ingress の設定を変更したり、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 のリスナーを設定しました。しかし、どちらのポートにもアクセスできません。トラフィックがリッスンまたは転送されていません。

解決策

Ingress リソースに alb.ingress.kubernetes.io/listen-ports アノテーションを追加したことを確認してください。このアノテーションは、ALB Ingress に HTTP (ポート 80) と HTTPS (ポート 443) の両方でリッスンするように指示します。例：

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 コンソールでの手動設定変更が失われる理由 (ルール削除、アクセスログ無効化)

チューニングプロセス中に「Specified parameter array contains too many items, up to 15 items, Certificates is not valid」というエラーメッセージが表示される理由

ALB インスタンスをコンソールで設定後、kubectl apply を実行して AlbConfig の ACL 設定を更新すると一部のリスナーが削除される理由

問題

Kubernetes では、サービスにアタッチされた Pod がスケーリングする際に、サーバー調整に時間がかかりすぎることがあります。これはリアルタイム弾力性に影響を与えます。調査によると、調整時間は関連する Ingress リソースの数に比例して増加します。

ソリューション

サーバーチューニングの効率を改善するには、以下の最適化策を適用できます。

• Ingress 数を制限する: 1 つのサービスにアタッチする Ingress リソースは 30 個以下に制限します。

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

問題

Flannel プラグインをローカルモードサービスと組み合わせて使用する場合、ノード間のトラフィック分散が不均一になることがあります。一部のノードは他のノードよりも高い負荷を処理します。ノードごとの Pod 数に基づいてノードの重みを自動割り当てし、バランスの取れたトラフィック分散を実現するにはどうすればよいですか？

ソリューション

Flannel クラスターでは、サービスがローカルモードの場合、ノードの重みは下図のように計算されます。この例では、アプリケーション Pod (app=nginx) が 3 つの ECS インスタンスで実行されています。サービス A はそれらを外部に公開します。