소스 IP 주소 유지

소스 IP 주소를 유지하기 위해 VPC 클러스터에 대해 PROXY 프로토콜을 사용으로 설정할 수 있습니다. 이 옵션은 버전 4.13 이상을 실행하는 클러스터에 사용할 수 있습니다.

프록시 프로토콜은 여러 계층의 NAT 또는 TCP 프록시를 통해 클라이언트 주소와 같은 연결 정보를 편리하게 전송할 수 있는 방법을 제공합니다. 프록시 프로토콜에 대한 자세한 내용은 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 제어기 또는 리소스에 대해 지원되지 않습니다.

액세스 로깅 사용

HTTP 접근 로그에는 들어오는 HTTP 요청에 대한 정보가 포함됩니다. 접근 로그를 확보하는 것은 복잡한 문제 해결 시 유용하지만, OpenShift 라우터는 기본적으로 접근 로깅을 지원하지 않습니다. 클러스터의 OpenShift 경우 라우터에 대한 액세스 로깅을 구성할 수 있으며, 이로 인해 라우터 포드 내에 사이드카 컨테이너가 생성됩니다. 이 컨테이너는 서버를 syslog stdout 실행하고 액세스 로그를 해당 컨테이너의 /var/log/access.log 파일에 기록합니다.

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"}'
   

   편집 명령

   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
   

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 매개 변수는 클라이언트, 인그레스 컨트롤러, 백엔드 서버 간에 연결이 활성 상태로 유지되는 시간을 결정하는 중요한 구성입니다. 이러한 시간 초과 기능은 특히 오래 지속되는 클라이언트 연결, 백엔드 서버의 지연된 응답을 처리하고 귀중한 리소스가 불필요하게 사용되지 않도록 보호할 때 요청 처리를 최적화하는 데 중요한 역할을 합니다.

클라이언트가 더 오랜 시간 동안 연결을 열어 둘 것으로 예상되는 경우 이러한 시나리오에 맞게 clientTimeout 설정을 늘리는 것이 좋습니다. 반대로 트래픽이 많거나 처리 부하로 인해 백엔드 서버의 지연 시간이 긴 경우 serverTimeout 을 조정하면 인그레스 컨트롤러가 연결을 종료하기 전에 서버가 요청 처리를 완료하는 데 필요한 허용 시간을 제공할 수 있습니다.

IngressController 리소스에서 위의 매개 변수를 변경할 수 있습니다:

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

튜닝 옵션에 대한 자세한 내용은 문 서를 OpenShift 참조하십시오.