ソース IP アドレスの保持

ソース IP アドレスを保持するために、VPC クラスターの PROXY プロトコルを有効にすることができます。 このオプションは、バージョン 4.13 以降を実行するクラスターで使用可能です。

PROXYプロトコルは、クライアントのアドレスなどの接続情報を、複数のレイヤーのNATや TCP プロキシを越えて転送する便利な方法を提供する。 PROXYプロトコルの詳細については、 HAProxy 仕様を参照のこと。

デフォルトでは、Ingress コントローラーは、ロード・バランサーに関連付けられたソース・アドレスのみを含む接続を受信します。 VPC クラスターで PROXY プロトコルを有効にして、Ingress コントローラーが受信する接続の元のクライアント・アドレスを保持するようにロード・バランサーを構成できます。

アノテーションを使用した Ingress ルーティングのカスタマイズ

アプリのルーティングルールをカスタマイズしたい場合は、定義するIngressリソース内で、 ルート固有の HAProxy アノテーションを使用できます。

サポートされるアノテーションは、haproxy.router.openshift.io/<annotation> または router.openshift.io/<annotation> の形式です。IBM Cloud Kubernetes Service アノテーション (ingress.bluemix.net/<annotation>) および NGINX アノテーション (nginx.ingress.kubernetes.io/<annotation>) は、Red Hat OpenShift バージョン 4 の Ingress コントローラーまたは Ingress リソースではサポートされません。

アクセス・ロギングの有効化

HTTP アクセスログには、受信した HTTP リクエストの情報が含まれています。 アクセスログは複雑な問題のデバッグ時に有用ですが、ルーター OpenShift はデフォルトでアクセスログ記録をサポートしていません。 クラスタ OpenShift では、ルーターのアクセスログ設定が可能です。これにより、ルーターポッド内にサイドカーコンテナが配置され、サーバー syslog を実行してアクセスログをそのコンテナのログファイル stdout に書き込みます。

1. IngressController の設定を編集し、 .spec に以下の設定を追加します。

   logging:
     access:
       destination:
         type: Container
       httpCaptureHeaders:
         request:
         - maxLength: 256
           name: Host
       httpLogFormat: '{"time_date":"%t","client":"%ci","host":"%[capture.req.hdr(0)]","ssl_version":"%sslv","request_method":"%HM",
                      "request_uri":"%HU","status":%ST,"upstream_addr":"%si:%sp","request_time":%Tt,"upstream_connect_time":%Tc,
                      "upstream_header_time":%Tr,"termination_state":"%ts"}'
   

   edit コマンド

   kubectl edit ingresscontroller -n openshift-ingress-operator default
   ingresscontroller.operator.openshift.io/default edited
   

2. ルーターポッドが2つのコンテナを実行しているかどうかを確認します。

   kubectl get pod -n openshift-ingress -w
   

   出力例

   NAME                              READY   STATUS    RESTARTS   AGE
   router-default-66945cc7c4-4xlnh   2/2     Running   0          36s
   router-default-66945cc7c4-5cxpn   2/2     Running   0          36s
   

3. アクセスログを確認する。

   kubectl logs -n openshift-ingress router-default-66945cc7c4-4xlnh -c logs
   

   出力例

   ...
   2025-01-28T12:29:07.038592+00:00 router-default-7fc484bbb8-qfm5d router-default-7fc484bbb8-qfm5d haproxy[41]:{"time_date":
   "28/Jan/2025:12:29:06.879","client":"10.5.207.79","host":"alb-autoscale-example-service-default.pvg-classic-z9g5zltmgb1ir
   -1e7743ca80a399c9cff4eaf617434c72-0000.us-south.stg.kube.appdomain.cloud","ssl_version":"TLSv1.3","request_method":
   "GET","request_uri":"/","status":200,"upstream_addr":"172.30.210.252:8080","request_time":159,"upstream_connect_time":1,
   "upstream_header_time":2,"termination_state":"--"}
   2025-01-28T12:29:09.572129+00:00 router-default-7fc484bbb8-qfm5d router-default-7fc484bbb8-qfm5d haproxy[41]: {"time_date":
   "28/Jan/2025:12:29:09.405","client":"10.5.207.79","host":"alb-autoscale-example-service-default.pvg-classic-z9g5zltmgb1ir
   -1e7743ca80a399c9cff4eaf617434c72-0000.us-south.stg.kube.appdomain.cloud","ssl_version":"TLSv1.3","request_method":"GET",
   "request_uri":"/","status":200,"upstream_addr":"172.30.210.252:8080","request_time":166,"upstream_connect_time":0,
   "upstream_header_time":3,"termination_state":"--"}
   ...
   

接続処理の微調整

clientTimeout 、 serverTimeout パラメーターは、クライアント、Ingressコントローラー、バックエンドサーバー間の接続がアクティブな状態を維持する時間を決定する重要な設定である。 これらのタイムアウトは、リクエスト処理を最適化する上で重要な役割を果たす。特に、長く続くクライアント接続、バックエンドサーバーからの応答の遅れ、貴重なリソースが不必要に占有されないようにすることなどに対処する。

クライアントが長時間接続を維持することが予想される場合は、このようなシナリオに対応できるよう、 clientTimeout の設定を大きくすることをお勧めします。 逆に、バックエンドサーバーのトラフィック量や処理負荷が高いために遅延が大きい場合は、 serverTimeout を調整することで、Ingress コントローラーが接続を終了する前に、サーバーがリクエスト処理を完了するために必要な余裕を与えることができます。

上記のパラメータは、 IngressController リソースで変更できます：

apiVersion: operator.openshift.io/v1
kind: IngressController
 ...
spec:
  tuningOptions:
    clientTimeout: 5s
    serverTimeout: 5s

チューニングオプションの詳細については 、ドキュメント OpenShift を参照してください。