Conservación de la dirección IP de origen

Para conservar las direcciones IP de origen, puede habilitar el protocolo PROXY para clústeres de VPC. Esta opción está disponible para clústeres que ejecutan la versión 4.13 o posterior.

El protocolo PROXY ofrece una forma cómoda de transportar información de conexión, como la dirección de un cliente, a través de varias capas de NAT o proxies TCP. Para más información sobre el protocolo PROXY, consulte la especificación HAProxy.

De forma predeterminada, el controlador de Ingress recibe conexiones que contienen sólo la dirección de origen asociada con el equilibrador de carga. Puede habilitar el protocolo PROXY en clústeres de VPC para configurar el equilibrador de carga para conservar la dirección de cliente original para las conexiones que recibe el controlador de Ingress.

Personalización del direccionamiento de Ingress con anotaciones

Si quieres personalizar las reglas de enrutamiento de tu aplicación, puedes utilizar anotaciones « HAProxy » específicas para cada ruta en los recursos de Ingress que definas.

Estas anotaciones soportadas tienen el formato haproxy.router.openshift.io/<annotation> o router.openshift.io/<annotation>. Las anotaciones de IBM Cloud Kubernetes Service (ingress.bluemix.net/<annotation>) y las anotaciones de NGINX (nginx.ingress.kubernetes.io/<annotation>) no están soportadas para el controlador de Ingress o el recurso de Ingress en Red Hat OpenShift versión 4.

Habilitación del registro de accesos

HTTP Los registros de acceso contienen información sobre las HTTP solicitudes entrantes. Disponer de registros de acceso resulta útil a la hora de depurar problemas complejos, pero el OpenShift router no admite el registro de acceso de forma predeterminada. Para OpenShift los clústeres, puede configurar el registro de acceso para los enrutadores, lo que da como resultado tener un contenedor sidecar en el pod del enrutador que ejecuta un syslog servidor y escribe registros de acceso en su stdout.

1. Edite la configuración de IngressController y añada la siguiente configuración a .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, mandato

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

2. Compruebe si los pods del router están ejecutando dos contenedores.

   kubectl get pod -n openshift-ingress -w
   

   Salida de ejemplo

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

3. Compruebe los registros de acceso.

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

   Salida de ejemplo

   ...
   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":"--"}
   ...
   

Ajuste de la gestión de las conexiones

Los parámetros clientTimeout y serverTimeout son configuraciones cruciales que dictan cuánto tiempo permanecen activas las conexiones entre los clientes, el controlador Ingress y los servidores backend. Estos tiempos de espera desempeñan un papel importante en la optimización de la gestión de las solicitudes, sobre todo cuando se trata de conexiones de clientes de larga duración, respuestas retrasadas de los servidores backend y la salvaguarda de recursos valiosos de ser ocupados innecesariamente.

Si prevés que los clientes mantendrán las conexiones abiertas durante más tiempo, es aconsejable aumentar la configuración de clientTimeout para hacer frente a estas situaciones. Por el contrario, si sus servidores backend tienen una alta latencia debido a grandes volúmenes de tráfico o cargas de procesamiento, el ajuste de serverTimeout puede proporcionar el margen necesario para que los servidores completen el procesamiento de sus solicitudes antes de que el controlador Ingress finalice la conexión.

Puede modificar los parámetros anteriores en su recurso IngressController:

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

Para obtener más información sobre las opciones de ajuste, consulte la OpenShift documentación.