Quellen-IP-Adresse beibehalten

Um Quellen-IP-Adressen beizubehalten, können Sie das Protokoll PROXY für VPC-Cluster aktivieren. Diese Option ist für Cluster verfügbar, auf denen Version 4.13 oder höher ausgeführt wird.

Das PROXY-Protokoll bietet eine bequeme Möglichkeit, Verbindungsinformationen, wie z. B. die Adresse eines Clients, über mehrere Schichten von NAT oder TCP Proxies zu transportieren. Weitere Informationen über das PROXY-Protokoll finden Sie in der Spezifikation HAProxy.

Der Ingress-Controller empfängt standardmäßig Verbindungen, die nur die Quellenadresse enthalten, die der Lastausgleichsfunktion zugeordnet ist. Sie können das Protokoll PROXY in VPC-Clustern aktivieren, um die Lastausgleichsfunktion so zu konfigurieren, dass die ursprüngliche Clientadresse für Verbindungen beibehalten wird, die der Ingress-Controller empfängt.

Ingress-Routing mit Annotationen anpassen

Wenn Sie die Routing-Regeln für Ihre App anpassen möchten, können Sie in den von Ihnen definierten Ingress-Ressourcen routenspezifische Annotationen vom Typ „ HAProxy “ verwenden.

Diese unterstützten Annotationen haben das Format haproxy.router.openshift.io/<annotation> oder router.openshift.io/<annotation>.IBM Cloud Kubernetes Service-Annotationen (ingress.bluemix.net/<annotation>) und NGINX-Annotationen (nginx.ingress.kubernetes.io/<annotation>) werden für den Ingress-Controller oder die Ingress-Ressource in Red Hat OpenShift Version 4 nicht unterstützt.

Zugriffsprotokollierung aktivieren

HTTP Zugriffsprotokolle enthalten Informationen zu eingehenden HTTP Anfragen. Zugriffsprotokolle sind bei der Fehlerbehebung komplexer Probleme hilfreich, aber der OpenShift Router unterstützt standardmäßig keine Zugriffsprotokollierung. Für OpenShift Cluster können Sie die Zugriffsprotokollierung für Router konfigurieren, was dazu führt, dass ein Sidecar-Container im Router-Pod vorhanden ist, der einen syslog Server ausführt und Zugriffsprotokolle in seine schreibt stdout.

1. Bearbeiten Sie die IngressController-Konfiguration und fügen Sie die folgende Konfiguration zu .spec hinzu.

   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 (Befehl)

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

2. Überprüfen Sie, ob die Router-Pods zwei Container ausführen.

   kubectl get pod -n openshift-ingress -w
   

   Beispielausgabe

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

3. Überprüfen Sie die Zugriffsprotokolle.

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

   Beispielausgabe

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

Feinabstimmung der Verbindungsbehandlung

Die Parameter clientTimeout und serverTimeout sind wichtige Konfigurationen, die festlegen, wie lange Verbindungen zwischen Clients, dem Ingress-Controller und den Backend-Servern aktiv bleiben. Diese Timeouts spielen eine wichtige Rolle bei der Optimierung der Anfragebearbeitung, insbesondere wenn es um lang andauernde Client-Verbindungen und verzögerte Antworten von Backend-Servern geht, und verhindern, dass wertvolle Ressourcen unnötig belegt werden.

Wenn Sie davon ausgehen, dass die Kunden die Verbindungen länger offen halten, ist es ratsam, die Einstellung clientTimeout zu erhöhen, um diesen Szenarien Rechnung zu tragen. Wenn umgekehrt Ihre Backend-Server aufgrund eines hohen Verkehrsaufkommens oder einer hohen Verarbeitungslast eine hohe Latenz aufweisen, kann die Anpassung von serverTimeout den Servern die nötige Zeit geben, um die Verarbeitung ihrer Anfragen abzuschließen, bevor der Ingress-Controller die Verbindung beendet.

Sie können die oben genannten Parameter in Ihrer IngressController Ressource ändern:

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

Weitere Informationen zu den Tuning-Optionen finden Sie in der OpenShift Dokumentation.