ソース 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 のドキュメントを 参照してください。