Ingress konfigurieren
Hier erfahren Sie, wie Sie Ihre Ingress-Konfiguration entsprechend Ihren Workloadanforderungen konfigurieren können.
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 die Adresse eines Clients, über mehrere Ebenen von NAT-oder TCP-Proxys zu transportieren. Weitere Informationen zum Protokoll PROXY 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.
PROXY-Protokoll aktivieren
-
Bearbeiten Sie die Ingress-Controllerressource.
oc -n openshift-ingress-operator edit ingresscontroller/default
-
Suchen Sie in der Ingress-Controllerressource den Abschnitt
spec.endpointPublishingStrategy.loadBalancer
und definieren Sie die folgendenproviderParameters
-Werte.endpointPublishingStrategy: loadBalancer: providerParameters: type: IBM ibm: protocol: PROXY scope: External type: LoadBalancerService
-
Speichern Sie die Ressource und wenden Sie sie an.
PROXY-Protokoll inaktivieren
-
Bearbeiten Sie die Ingress-Controllerressource.
oc -n openshift-ingress-operator edit ingresscontroller/default
-
Suchen Sie in der Ingress-Controllerressource den Abschnitt
spec.endpointPublishingStrategy.loadBalancer
und definieren Sie die folgendenproviderParameters
-Werte.endpointPublishingStrategy: loadBalancer: providerParameters: type: IBM ibm: protocol: TCP scope: External type: LoadBalancerService
-
Speichern Sie die Ressource und wenden Sie sie an.
Ingress-Routing mit Annotationen anpassen
Wenn Sie die Routing-Regeln für Ihre Anwendung anpassen möchten, können Sie routenspezifische HAProxy Anmerkungen in den von Ihnen definierten Ingress-Ressourcen 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 nützlich, wenn es darum geht, komplexe Probleme zu beheben, aber der Router OpenShift unterstützt standardmäßig keine Zugriffsprotokollierung.
Für OpenShift-Cluster können Sie die Zugriffsprotokollierung für Router konfigurieren, was dazu führt, dass im Router-Pod ein Sidecar-Container vorhanden ist, der einen syslog
-Server ausführt und Zugriffsprotokolle in seinen stdout
schreibt.
-
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
-
Ü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
-
Ü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 Dokumentation OpenShift.
Anpassen von Zeitüberschreitungen
Wenn Ihre Cluster mit IBM Cloud Cloud Internet Services (CIS) / Cloudflare exponiert sind und eine Web Application Firewall (WAF) oder einen globalen Lastausgleich verwenden, sollten Sie clientTimeout
und serverTimeout
auf Werte von über 900 Sekunden einstellen, um vorzeitige Verbindungsabbrüche zu verhindern. Weitere Informationen finden Sie in der Cloudflare-Dokumentation.
-
Identifizieren Sie Ihren Ingress Controller: Beginnen Sie mit der Auflistung Ihrer
IngressController
Ressourcen. Dies kann mit dem Befehl erreicht werden:oc get ingresscontrollers -n openshift-ingress-operator
-
Aktualisieren Sie die Timeout-Parameter: Um die Parameter
clientTimeout
undserverTimeout
für ein bestimmtesIngressController
zu ändern, können Sie einen Patch-Befehl ausführen. Der folgende Befehl aktualisiert beispielsweise die Timeout-Einstellung für diedefault
Ingress Controller auf 905 Sekunden:oc patch ingresscontrollers default --patch '{"spec": {"tuningOptions":{"clientTimeout": "905s", "serverTimeout": "905s"}}}' --type=merge -n openshift-ingress-operator
-
Nur VPC-Cluster: In Fällen, in denen Sie innerhalb einer Virtual Private Cloud (VPC) arbeiten, ist es notwendig, die Leerlaufzeit der Verbindung des VPC-Load Balancers zusammen mit den Einstellungen des Ingress Controllers einzustellen. Es wird empfohlen, eine größere Leerlaufzeit für die Verbindung zu wählen als die Timeout-Einstellungen Ihres Ingress Controllers. Der folgende Befehl veranschaulicht, wie die Zeitüberschreitung für inaktive Verbindungen für den Dienst
router-default
LoadBalancer auf 910 Sekunden aktualisiert werden kann:oc annotate svc -n openshift-ingress service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout="910" router-default