すべてのプロダクト
Search

このプロダクト

    Container Service for Kubernetes:NGINX Ingress コントローラーのベストプラクティス

    ドキュメントセンター

    Container Service for Kubernetes:NGINX Ingress コントローラーのベストプラクティス

    最終更新日:Apr 04, 2026

    このトピックでは、さまざまなシナリオで最適なパフォーマンスを実現するために NGINX Ingress コントローラーを設定する際のベストプラクティスについて説明します。

    このトピックの内容

    NGINX Ingress コントローラーのパフォーマンスと安定性

    適切なレプリカ数とリソース制限

    デフォルトでは、クラスター作成時または [アドオン] ページからインストールされた NGINX Ingress コントローラーには 2 つのレプリカがあります。ビジネス要件に応じて、この数を調整できます。リソース競合と単一障害点を防ぐために、NGINX Ingress コントローラーの Pod が異なるノードに分散されるようにしてください。パフォーマンスと安定性を保証するために、専用ノードを割り当てることもできます。詳細については、「専用ノードを使用した NGINX Ingress のパフォーマンスと安定性の向上」をご参照ください。メモリ不足 (OOM) イベントによるトラフィックの中断を避けるため、NGINX Ingress コントローラーにリソース制限を設定しないでください。制限を設定する必要がある場合は、CPU 制限を 1,000 ミリコア以上、メモリ制限を 2 GiB 以上に設定してください。

    専用ノードの使用

    NGINX Ingress のパフォーマンス最適化

    NGINX Ingress コントローラーのパフォーマンスチューニングには、システムパラメーターチューニングと NGINX パラメーターチューニングの 2 つの主要な領域があります。

    • システムパラメーターチューニング：Alibaba Cloud のオペレーティングシステムには、共通パラメーターに対するデフォルトの最適化が含まれています。チューニングが必要になる可能性のある他のシステムパラメーターには、システムの最大バックログや使用可能なポートの範囲などがあります。システムパラメーターをチューニングすることで、NGINX が高い同時実行性を処理できるようになり、ポート枯渇によるバックエンドへの接続障害を防ぐことができます。

    • NGINX パラメーターチューニング：

      • ワーカープロセスあたりの最大接続数を調整することで、NGINX Ingress コントローラーが高い同時実行性を処理できるようになります。

      • 接続タイムアウトの増加：デフォルトの NGINX の動作とは異なり、NGINX Ingress コントローラーはキープアライブ接続を使用してバックエンド Pod にリクエストを送信します。したがって、接続タイムアウトを長くして、単一の接続でより多くのリクエストを処理できるようにし、新しい接続を作成するオーバーヘッドを削減してください。

      • キープアライブタイムアウトの設定：バックエンドサービスのキープアライブタイムアウトは、NGINX Ingress コントローラーの接続タイムアウトと同じかそれ以上に設定してください。ACK クラスターでは、デフォルトで 900 秒です。

    NGINX Ingress コンポーネントには、ほとんどのシナリオで最適なパフォーマンスを提供するデフォルトのチューニングパラメーターが含まれています。特定の要件がある場合は、ConfigMap の関連フィールドを使用して、システムおよび NGINX のパラメーターをさらに最適化できます。ConfigMap の詳細については、「ConfigMaps」をご参照ください。

    HPA によるオートスケーリング

    ほとんどの場合、NGINX Ingress コントローラーは突然のトラフィックスパイクに対応できます。デフォルトのキャパシティが高負荷シナリオに対して不十分な場合は、Horizontal Pod Autoscaler (HPA) を設定して、NGINX Ingress コントローラーを自動的にスケーリングしてください。詳細については、「Horizontal Pod Autoscaler (HPA) の使用」をご参照ください。

    重要

    Pod のスケーリングイベントにより、既存の接続が一時的に中断される可能性があります。この機能は注意して設定してください。

    以下は YAML 設定のサンプルです：

    apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-ingress-controller-hpa
  namespace: kube-system
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-ingress-controller
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

    preStop フックの設定

    バックエンドサービスのローリングアップデート中、NGINX Ingress コントローラーは、処理中のリクエストの接続を維持しながら、終了中の Pod のエンドポイントを削除します。バックエンドサービスの Pod が終了シグナルを受け取った直後に終了すると、処理中のリクエストが失敗する可能性があります。タイミングの問題により、一部の新しいトラフィックが終了した Pod にルーティングされ続け、トラフィック損失が発生することがあります。

    ローリングアップデート中のトラフィック損失を防ぐには、バックエンドサービスの Pod に preStop フックを設定してください。このフックにより、Pod はエンドポイントが削除された後も処理中のリクエストを処理し続けることができ、サービスの中断を防ぎます。

    Pod テンプレートのコンテナ設定に次のコードを追加します：

    apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: app
        lifecycle:
          # 終了前に 30 秒待機するように preStop フックを設定します。
          # sleep コマンドがコンテナ内で利用可能である必要があります。
          preStop:
            exec:
              command:
              - sleep
              - "30"

    NGINX Ingress コントローラーの可観測性

    Log Service と Managed Service for Prometheus

    NGINX Ingress コントローラーは、Log Service (SLS) のログと Prometheus に基づくモニタリングダッシュボードを提供し、サービストラフィックの理解を深めるのに役立ちます。

    • Log Service (SLS) のログ：

      • クラスターを作成する際に [Log Service の有効化] と [Ingress ダッシュボードの作成] を選択した場合、ACK コンソールに移動し、ネットワーク > Ingressを選択すると、Nginx Ingress の概要 ページで Log Service ベースのダッシュボードを表示できます。 また、操作 > ログセンターに移動して、NGINX Ingress コントローラーによって生成されたログを表示することもできます。 詳細については、「NGINX Ingress アクセスログの収集と分析」をご参照ください。

      • クラスター作成時にこれらのオプションを有効にしなかった場合は、ログ収集コンポーネントとルールを手動で設定できます。詳細については、「NGINX Ingress アクセスログの収集と分析」をご参照ください。モニタリングの詳細については、「Ingress ダッシュボードモニタリング」をご参照ください。

    • Managed Service for Prometheus モニタリング：クラスター作成時に Managed Service for Prometheus モニタリングをインストールすることを選択できます。または、クラスター作成後に 操作 > Prometheus 監視 を選択してインストールまたは表示できます。詳細については、「Managed Service for Prometheus の接続と設定」をご参照ください。

      説明

      Managed Service for Prometheus を使用する場合、クラスター内の Ingress リソースに host フィールドを追加してください。そうしないと、デフォルトで Ingress の一部のメトリックが欠落します。または、NGINX Ingress コントローラーの Deployment の controller に --metrics-per-host=false 起動引数を追加することもできます。

    NGINX Ingress コントローラーの高度な機能

    複数の NGINX Ingress コントローラーの使用

    クラスター内に複数の NGINX Ingress コントローラーをデプロイする必要がある場合があります。たとえば、内部トラフィックと外部トラフィックを隔離するためです。詳細については、「トラフィック隔離のための複数の Ingress コントローラーのデプロイ」をご参照ください。

    クラスター内アクセス

    クラスター内では、LoadBalancer サービスの外部エンドポイント (NGINX Ingress コントローラーのパブリック IP アドレス) へのトラフィックは、通常 iptables または IPVS によってインターセプトされ、転送されます。externalTrafficPolicy が Local に設定されていて、ノード上で NGINX Ingress Pod が実行されていない場合、ネットワーク接続の問題が発生します。デフォルトでは、ACK クラスターの NGINX Ingress コントローラーは Local モードの LoadBalancer サービスを使用します。その結果、クラスター内から関連するクラシックロードバランサー (CLB) アドレスにアクセスする際に接続性の問題が発生する可能性があります。したがって、クラスター内アクセスには、サービスの ClusterIP または内部ドメイン名 (nginx-ingress-lb.kube-system) を使用してください。また、NGINX Ingress コントローラーが自身にアクセスしようとするシナリオは避けてください。これはヘアピン問題によるネットワーク障害につながる可能性があります。この問題の解決方法の詳細については、「Kubernetes クラスター内から LoadBalancer サービスの SLB インスタンスにアクセスできない」をご参照ください。

    WAF の使用

    攻撃リクエストをブロックするために、クラスターの NGINX Ingress コントローラーが使用するクラシックロードバランサー (CLB) に対して Web Application Firewall (WAF) を有効にすることができます。HTTPS ポートで WAF を有効にする場合、WAF コンソールで必要な証明書も設定する必要があります。これにより、次の問題が発生する可能性があります：

    • TLS リクエストは WAF レイヤーで終端されます。そのため、Kubernetes Secret で設定された証明書はパブリックエンドポイントでは使用されません。

    • クラスター内から CLB の IP アドレスまたはサービスの ClusterIP を使用してポート 443 にアクセスすると、トラフィックが WAF を通過しない可能性があり、証明書エラーが発生します。

    • WAF を有効にすると、NGINX Ingress コントローラーはデフォルトで実際のクライアント IP アドレスを取得できません。ConfigMap (コンポーネント管理を通じてインストールされた NGINX Ingress コントローラーの場合、デフォルトでは kube-system 名前空間の nginx-configuration) に以下の内容を追加して、NGINX の Realip モジュールを有効にし、X-Forwarded-For ヘッダーを使用して実際のクライアント IP アドレスを取得します。

      use-forwarded-headers: "true" # NGINX Ingress コントローラーバージョン 0.30.0 以前ではこのオプションを使用します。
enable-real-ip: "true" # NGINX Ingress コントローラーバージョン 0.44.0 以降ではこのオプションを使用します。
proxy-real-ip-cidr: <WAF から取得したバックツーオリジン CIDR ブロック>

    ブルーグリーンデプロイメントまたはカナリアリリース

    ACK コンソールの機能を使用するか、手動でアノテーションを追加することで、NGINX Ingress コントローラーを使用してカナリアリリースを実装できます。詳細については、「NGINX Ingress を使用したカナリアリリースとブルーグリーンデプロイメントの実装」をご参照ください。

    重要

    オリジナルサービスとカナリアサービスは、カナリア Ingress からのみ参照されるようにしてください。そうしないと、カナリア ルールが競合し、トラフィックルーティングエラーが発生する可能性があります。

    非 HTTP リクエストのプロキシ

    デフォルトでは、NGINX Ingress コントローラーは HTTP プロトコルを使用してバックエンドサービスに接続します。ただし、WebSocket、HTTPS、gRPC が最も一般的ないくつかのバックエンドプロトコルもサポートしています。サポートされているバックエンドプロトコルの完全なリストについては、「バックエンドプロトコル」をご参照ください。

    • WebSocket：NGINX Ingress コントローラーは WebSocket をネイティブにサポートしています。WebSocket 接続を転送するために追加の設定は必要ありません。長時間持続する WebSocket 接続がある場合は、アノテーションを使用してバックエンド接続タイムアウトを調整し、タイムアウトによる切断を防ぐことができます。調整方法の詳細については、「カスタムタイムアウト」をご参照ください。

    • HTTPS：HTTPS を使用するバックエンドサービスの場合、Ingress に nginx.ingress.kubernetes.io/backend-protocol:"HTTPS" アノテーションを追加して、HTTPS 接続に切り替えることができます。

    • gRPC：gRPC は TLS ポート経由でのみアクセスできます。したがって、アプリケーションが NGINX Ingress コントローラーを介して gRPC サービスにアクセスする際は、暗号化された TLS ポートを使用するようにしてください。gRPC の設定方法の詳細については、「NGINX Ingress の gRPC サービスの設定」をご参照ください。