Ingress の構成
ワークロードのニーズを満たすように Ingress セットアップを構成する方法について説明します。
ソース IP アドレスの保持
ソース IP アドレスを保持するために、VPC クラスターの PROXY プロトコルを有効にすることができます。 このオプションは、バージョン 4.13 以降を実行するクラスターで使用可能です。
PROXY プロトコルは、クライアントのアドレスなどの接続情報を、NAT または TCP プロキシーの複数の層にまたがって転送するための便利な方法を提供します。 PROXY プロトコルについて詳しくは、 HAProxy 仕様を参照してください。
デフォルトでは、Ingress コントローラーは、ロード・バランサーに関連付けられたソース・アドレスのみを含む接続を受信します。 VPC クラスターで PROXY プロトコルを有効にして、Ingress コントローラーが受信する接続の元のクライアント・アドレスを保持するようにロード・バランサーを構成できます。
PROXY プロトコルの使用可能化
-
Ingress コントローラー・リソースを編集します。
oc -n openshift-ingress-operator edit ingresscontroller/default
-
Ingress コントローラー・リソースで、
spec.endpointPublishingStrategy.loadBalancer
セクションを見つけ、以下のproviderParameters
値を定義します。endpointPublishingStrategy: loadBalancer: providerParameters: type: IBM ibm: protocol: PROXY scope: External type: LoadBalancerService
-
リソースを保存して適用する。
PROXY プロトコルの無効化
-
Ingress コントローラー・リソースを編集します。
oc -n openshift-ingress-operator edit ingresscontroller/default
-
Ingress コントローラー・リソースで、
spec.endpointPublishingStrategy.loadBalancer
セクションを見つけ、以下のproviderParameters
値を定義します。endpointPublishingStrategy: loadBalancer: providerParameters: type: IBM ibm: protocol: TCP scope: External type: LoadBalancerService
-
リソースを保存して適用する。
アノテーションを使用した 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
に書き込まれます。
-
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つのコンテナを実行しているかどうかを確認します。
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
-
アクセスログを確認する。
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 のドキュメントを 参照してください。
タイムアウトの調整
クラスタが IBM Cloud Cloud Internet Services (CIS) / Cloudflareで公開され、Webアプリケーションファイアウォール(WAF)またはグローバルロードバランシングを使用している場合は、接続の早期終了を防ぐために、 clientTimeout
と serverTimeout
を900秒を超える値に設定する必要があります。 詳細については、 Cloudflareのドキュメントを 参照してください。
-
Ingressコントローラを特定する :
IngressController
リソースをリストアップすることから始める。 これはコマンドで実現できる:oc get ingresscontrollers -n openshift-ingress-operator
-
タイムアウトパラメータを更新する :特定の
IngressController
のclientTimeout
とserverTimeout
パラメータを変更するには、patch コマンドを実行する。 たとえば、次のコマンドは、default
Ingress Controllerのタイムアウト設定を905秒に更新します:oc patch ingresscontrollers default --patch '{"spec": {"tuningOptions":{"clientTimeout": "905s", "serverTimeout": "905s"}}}' --type=merge -n openshift-ingress-operator
-
VPCクラスタのみ :Virtual Private Cloud(VPC)内で運用する場合、Ingress Controllerの設定と合わせて、VPCロードバランサーのアイドル接続タイムアウトを調整する必要があります。 Ingressコントローラーのタイムアウト設定よりも大きなアイドル接続タイムアウトを選択することをお勧めします。 以下のコマンドは、
router-default
LoadBalancer サービスのアイドル接続タイムアウトを 910 秒に更新する方法を示している:oc annotate svc -n openshift-ingress service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout="910" router-default