Conservazione dell'indirizzo IP di origine

Per conservare gli indirizzi IP di origine, è possibile abilitare il protocollo PROXY per cluster VPC. Questa opzione è disponibile per i cluster che eseguono la versione 4.13 o successiva.

Il protocollo PROXY fornisce un modo conveniente per trasportare informazioni sulla connessione, come l'indirizzo di un client, attraverso più livelli di NAT o proxy TCP. Per ulteriori informazioni sul protocollo PROXY, consultare la specifica HAProxy.

Per impostazione predefinita, il programma di controllo Ingress riceve le connessioni che contengono solo l'indirizzo di origine associato al programma di bilanciamento del carico. Puoi abilitare il protocollo PROXY nei cluster VPC per configurare il programma di bilanciamento del carico per conservare l'indirizzo client originale delle connessioni ricevute dal controller Ingress.

Personalizzazione dell'instradamento Ingress con annotazioni

Se vuoi personalizzare le regole di instradamento per la tua applicazione, puoi utilizzare le annotazioni HAProxy specifiche per l'instradamento nelle risorse Ingress che definisci.

Queste annotazioni supportate hanno il formato haproxy.router.openshift.io/<annotation> o router.openshift.io/<annotation>. Le annotazioni IBM Cloud Kubernetes Service (ingress.bluemix.net/<annotation>) e NGINX (nginx.ingress.kubernetes.io/<annotation>) non sono supportate per il controller Ingress né per la risorsa Ingress nella versione 4 di Red Hat OpenShift.

Abilitazione della registrazione degli accessi

HTTP I log di accesso contengono informazioni sulle richieste in HTTP entrata. Avere i log di accesso è utile quando si risolvono problemi complessi, ma il OpenShift router non supporta la registrazione degli accessi di default. Per OpenShift i cluster, è possibile configurare la registrazione degli accessi per i router, il che comporta la presenza di un contenitore sidecar nel pod del router che esegue un syslog server e scrive i log di accesso nel suo stdout.

1. Modificare la configurazione di IngressController e aggiungere la seguente configurazione 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"}'
   

   Comando di modifica

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

2. Verificare se i pod del router stanno eseguendo due container.

   kubectl get pod -n openshift-ingress -w
   

   Output di esempio

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

3. Controllare i registri di accesso.

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

   Output di esempio

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

Gestione fine delle connessioni

I parametri clientTimeout e serverTimeout sono configurazioni cruciali che dettano il tempo in cui le connessioni rimangono attive tra i client, il controller Ingress e i server backend. Questi timeout svolgono un ruolo importante nell'ottimizzazione della gestione delle richieste, in particolare quando si tratta di connessioni client di lunga durata, di risposte ritardate dai server di backend e di salvaguardare risorse preziose dall'essere occupate inutilmente.

Se si prevede che i clienti mantengano le connessioni aperte per un periodo di tempo più lungo, è consigliabile aumentare l'impostazione di clientTimeout per soddisfare questi scenari. Al contrario, se i server di backend hanno una latenza elevata a causa di alti volumi di traffico o di carichi di elaborazione, la regolazione di serverTimeout può fornire il margine necessario ai server per completare l'elaborazione delle richieste prima che il controller Ingress termini la connessione.

È possibile modificare i parametri di cui sopra nella risorsa IngressController:

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

Per ulteriori informazioni sulle opzioni di ottimizzazione, consultare la OpenShift documentazione.