IBM Cloud Docs
Ingress の構成

Ingress の構成

ワークロードのニーズを満たすように Ingress セットアップを構成する方法について説明します。

ソース IP アドレスの保持

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

PROXY プロトコルは、クライアントのアドレスなどの接続情報を、NAT または TCP プロキシーの複数の層にまたがって転送するための便利な方法を提供します。 PROXY プロトコルについて詳しくは、 HAProxy 仕様を参照してください。

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

PROXY プロトコルの使用可能化

  1. Ingress コントローラー・リソースを編集します。

    oc -n openshift-ingress-operator edit ingresscontroller/default
    
  2. Ingress コントローラー・リソースで、 spec.endpointPublishingStrategy.loadBalancer セクションを見つけ、以下の providerParameters 値を定義します。

    endpointPublishingStrategy:
      loadBalancer:
        providerParameters:
          type: IBM
          ibm:
            protocol: PROXY
        scope: External
      type: LoadBalancerService
    
  3. リソースを保存して適用する。

PROXY プロトコルの無効化

  1. Ingress コントローラー・リソースを編集します。

    oc -n openshift-ingress-operator edit ingresscontroller/default
    
  2. Ingress コントローラー・リソースで、 spec.endpointPublishingStrategy.loadBalancer セクションを見つけ、以下の providerParameters 値を定義します。

    endpointPublishingStrategy:
      loadBalancer:
        providerParameters:
          type: IBM
          ibm:
            protocol: TCP
        scope: External
      type: LoadBalancerService
    
  3. リソースを保存して適用する。

アノテーションを使用した 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":"--"}
    ...
    

接続処理の微調整

clientTimeoutserverTimeout パラメーターは、クライアント、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)またはグローバルロードバランシングを使用している場合は、接続の早期終了を防ぐために、 clientTimeoutserverTimeout を900秒を超える値に設定する必要があります。 詳細については、 Cloudflareのドキュメントを 参照してください。

  1. Ingressコントローラを特定するIngressController リソースをリストアップすることから始める。 これはコマンドで実現できる:

    oc get ingresscontrollers -n openshift-ingress-operator
    
  2. タイムアウトパラメータを更新する :特定の IngressControllerclientTimeoutserverTimeout パラメータを変更するには、patch コマンドを実行する。 たとえば、次のコマンドは、 default Ingress Controllerのタイムアウト設定を905秒に更新します:

    oc patch ingresscontrollers default --patch '{"spec": {"tuningOptions":{"clientTimeout": "905s", "serverTimeout": "905s"}}}' --type=merge -n openshift-ingress-operator
    
  3. 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