このトピックでは、NGINXの基本、NGINX Ingressコントローラーの動作、および関連するO&M機能について説明します。
NGINXの基本
NGINX Ingressコントローラ
制御ポリシー機能の動作
NGINX Ingressコントローラは、制御プレーンとデータプレーンの両方を統合する実装です。 各ポッドには、コントローラプロセスと関連するNGINXプロセスがあります。
NGINX Ingressデータプレーンのコアモジュール
サードパーティ制モジュール:
Container Service for Kubernetes (ACK) のNGINX Ingressは、このモジュールと統合されています。 このモジュールは、リアルタイム監視サービス (ARMS) のトレース機能との統合を実装します。 詳細については、「NGINX Ingress Controllerのトレースの有効化」をご参照ください。
ConfigMapを使用して、NGINX Ingressに対してこのモジュールを有効にできます。
data: enable-opentelemetry: "true" otlp-collector-host: "otel-coll-collector.otel.svc" ## OpenTelemetry endpoint
詳細については、「NGINX公式ドキュメント」をご参照ください。
構成同期の実装
次の図は、構成同期の実装方法を示しています。 これは、構成のリロードの頻度を減らす方法と、構成のリロードを実行する必要があるときを理解するのに役立ちます。
NGINX Ingressコントローラーは、Ingress、サービス、ポッド、エンドポイントなどのリソースを監視して、nginx.confファイルまたはLuaテーブルの設定を更新します。 Luaテーブルには、主にアップストリームサーバーのエンドポイント、カナリアリリース、証明書の設定が含まれています。 それらはNGINXのいくつかの関連変数に対応します。 これらの設定を変更すると、nginx.confファイルの更新もトリガーされ、リロードがトリガーされます。 詳細については、NGINX Ingressコミュニティドキュメントの「リロードが必要な場合」をご参照ください。
NGINX Ingressコントロールプレーンの設定
スタートアップ引数
詳細については、「コマンドライン引数」をご参照ください。
次のコードに示すように、NGINX IngressのDeployment SpecまたはPod Specからコンテナー起動引数を表示できます。
containers:
- args:
- /nginx-ingress-controller
- --election-id=ingress-controller-leader-nginx
- --ingress-class=nginx
- --watch-ingress-without-class
- --controller-class=k8s.io/ingress-nginx
- --configmap=$(POD_NAMESPACE)/nginx-configuration
- --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
- --udp-services-configmap=$(POD_NAMESPACE)/udp-services
- --annotations-prefix=nginx.ingress.kubernetes.io
- --publish-service=$(POD_NAMESPACE)/nginx-ingress-lb
- --enable-annotation-validation
- --validating-webhook=:8443
- --validating-webhook-certificate=/usr/local/certificates/cert
- --validating-webhook-key=/usr/local/certificates/key
- --v=2-vはログレベルを指定します。
-- v=2: NGINXの設定変更に関する詳細情報を表示します。-- v=3: サービス、Ingressルール、エンドポイントの変更に関する詳細情報を表示し、NGINX設定をJSON形式でダンプします。-- v=5: デバッグモードを有効にします。
負荷分散
NGINX Ingressでは、グローバルデフォルトの負荷分散アルゴリズムを指定できます。 Round_robinおよびEwmaアルゴリズムがサポートされています。 デフォルトでは、Round_robinが使用されます。 Round_robinアルゴリズムは、要求をバックエンドワークロード間で周期的に分散し、均等な分散を実現します。 ただし、バックエンドワークロードのパフォーマンスが大きく変化すると、不均一な負荷分散が発生する可能性があります。 Ewmaアルゴリズムは、加重平均負荷が最も低いバックエンドワークロードにリクエストを送信します。 重み付き負荷指数は、要求が到着するにつれて徐々に変化する。 これにより、よりバランスの取れた負荷分散が保証される。
IPアドレスなどの変数を使用してコンシステントハッシュに基づく負荷分散を行うには、nginx.ingress.kubernetes.io/upstream-hash-byアノテーションの使用を検討してください。 セッションcookieベースの負荷分散については、nginx.ingress.kubernetes.io/affinityアノテーションの使用を検討してください。
関連する実装:
関連するタイムアウト設定
グローバルタイムアウトの設定
次の設定オプションを使用して、NGINX Ingressのグローバルタイムアウト設定を指定できます。
設定オプション | 説明 | デフォルト値 |
| プロキシサーバーとの接続を確立するためのタイムアウト時間を設定します。 一般に、この値は75sを超えることはできない。 | 5s |
| プロキシサーバーから応答を読み取るためのタイムアウト時間を設定します。 このタイムアウト期間は、応答全体の送信ではなく、2つの連続する読み出し動作の間に適用される。 | 60s |
| プロキシサーバーにリクエストを送信するためのタイムアウト時間を設定します。 このタイムアウト期間は、要求全体の送信ではなく、2つの連続する書き込み動作の間に適用される。 | 60s |
| 次のサーバーに接続を渡すために許可される時間を制限します。 値を0に設定した場合、制限は課されません。 | 600s |
| クライアントまたはプロキシサーバー接続での2つの連続した読み取りまたは書き込み操作間のタイムアウト期間を設定します。 その期間内にデータが送信されない場合、接続は閉じられる。 | 600s |
| 上流サーバーとのアイドル接続を開いたままにするためのタイムアウト期間を設定します。 |
|
| グレースフルシャットダウンのタイムアウト期間を設定します。 | 240s |
| プロキシプロトコルヘッダーを受信するためのタイムアウト期間を設定します。 デフォルト値は、トランスポート層セキュリティ (TLS) パススルーハンドラが接続の切断を無期限に待機するのを防ぎます。 | 5s |
| セッションキャッシュのSSLセッションパラメーターの有効期間を設定します。 有効期限は作成時刻に左右されます。 各セッションキャッシュは約0.25 MBのスペースを占有します。 | 10m |
| クライアント要求本文を読み取るためのタイムアウト期間を設定します。 | 60s |
| クライアント要求ヘッダーを読み取るためのタイムアウト期間を設定します。 | 60s |
リソース固有のカスタムタイムアウト設定
次の表に、リソース固有のカスタムタイムアウト設定のオプションを示します。
設定オプション | 説明 |
| プロキシサーバーとの接続を確立するためのタイムアウト時間を設定します。 |
| プロキシサーバーにデータを送信するためのタイムアウト期間を設定します。 |
| プロキシサーバーからデータを読み取るためのタイムアウト時間を設定します。 |
| 再試行ポリシーまたは再試行条件を設定します。 複数のアイテムをスペースで区切ります。 たとえば、
|
| リトライ条件を満たした場合のリトライ回数を設定します。 |
| リクエストバッファリング機能を有効にするかどうかを指定します。 有効な値:
|
グローバルConfigMapの一般的な設定
詳細については、「ConfigMaps」をご参照ください。
その他の注釈
詳細については、「注釈」をご参照ください。
カスタムスニペット設定
nginx.ingress.kubernetes.io/configuration-snippet: 設定はLocationブロックに適用されます。nginx.ingress.kubernetes.io/server-snippet: 設定はServerブロックに適用されます。nginx.ingress.kubernetes.io/stream-snippet: 設定はStreamブロックに適用されます。
NGINX Ingressデータプレーンの設定
NGINX Ingressのデータプレーンは、NGINXとngx_luaモジュール (OpenResty) を組み合わせることによって実装されます。 NGINXは、HTTPリクエスト処理を複数のフェーズに分割するマルチモジュラー設計を使用しています。 この設計により、複数のモジュールが連携し、各モジュールが独立したシンプルな機能を処理できます。 これは、要求処理をより効率的かつ信頼できるものにし、システムのスケーラビリティを改善する。
OpenRestyは、カスタムハンドラを挿入して、書き換え /アクセスフェーズ、コンテンツフェーズ、ログフェーズなど、NGINXのさまざまな処理フェーズでリクエストを処理できます。 OpenRestyは、マスターフェーズであるシステム起動の初期化フェーズとともに、合計11フェーズを提供します。 これらのフェーズにより、LuaスクリプトがHTTPリクエスト処理に介入できます。 次の図は、OpenRestyの主な使用可能なフェーズを示しています。
HTTPブロック
http {
lua_package_path "/etc/nginx/lua/?.lua;;";
lua_shared_dict balancer_ewma 10M;
lua_shared_dict balancer_ewma_last_touched_at 10M;
lua_shared_dict balancer_ewma_locks 1M;
lua_shared_dict certificate_data 20M;
lua_shared_dict certificate_servers 5M;
lua_shared_dict configuration_data 20M;
lua_shared_dict global_throttle_cache 10M;
lua_shared_dict ocsp_response_cache 5M;
...
}init_by_lua_block
初期化中に次のLua関連モジュールがロードされます。
設定balancerモニター証明書プラグイン
init_worker_by_lua_block
init_worker_by_lua_block {
lua_ingress.init_worker()
balancer.init_worker()
monitor.init_worker(10000)
plugins.run()
}上流とbalancer_by_lua_block
upstream upstream_balancer {
### Attention!!!
#
# We no longer create "upstream" section for every backend.
# Backends are handled dynamically using Lua. If you would like to debug
# and see what backends ingress-nginx has in its memory you can
# install our kubectl plugin https://kubernetes.github.io/ingress-nginx/kubectl-plugin.
# Once you have the plugin you can use "kubectl ingress-nginx backends" command to
# inspect current backends.
#
###
server 0.0.0.1; # placeholder
balancer_by_lua_block {
balancer.balance()
}
keepalive 8000;
keepalive_time 1h;
keepalive_timeout 60s;
keepalive_requests 10000;
}ストリームブロック
ログ
access_log off;
error_log /var/log/nginx/error.log notice;この例では、
access_logは無効です。エラーログレベルは
noticeに設定されています。debug(debug_core、debug_alloc、debug_event、debug_http、...) 、info、warn、error、crit、alert、およびemergのレベルがサポートされています。 レベルが高いほど、記録される情報は少なくなります。
次のコマンドを実行して、NGINX Ingressのポッドログに記録されたエラーを確認します。
kubectl logs -f <nginx-ingress-pod-name> -n kube-system |grep -E '^[WE]'関連ドキュメント
NGINX Ingress設定の詳細については、「NGINX設定」をご参照ください。
NGINX Ingressのトラブルシューティングの詳細については、「NGINX Ingressコントローラーのトラブルシューティング」トピックの一般的に使用される診断方法をご参照ください。
NGINX Ingressの高度な使用方法の詳細については、「高度なNGINX Ingress設定」をご参照ください。