IBM Cloud Docs
Ingress konfigurieren

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

  1. Bearbeiten Sie die Ingress-Controllerressource.

    oc -n openshift-ingress-operator edit ingresscontroller/default
    
  2. Suchen Sie in der Ingress-Controllerressource den Abschnitt spec.endpointPublishingStrategy.loadBalancer und definieren Sie die folgenden providerParameters-Werte.

    endpointPublishingStrategy:
      loadBalancer:
        providerParameters:
          type: IBM
          ibm:
            protocol: PROXY
        scope: External
      type: LoadBalancerService
    
  3. Speichern Sie die Ressource und wenden Sie sie an.

PROXY-Protokoll inaktivieren

  1. Bearbeiten Sie die Ingress-Controllerressource.

    oc -n openshift-ingress-operator edit ingresscontroller/default
    
  2. Suchen Sie in der Ingress-Controllerressource den Abschnitt spec.endpointPublishingStrategy.loadBalancer und definieren Sie die folgenden providerParameters-Werte.

    endpointPublishingStrategy:
      loadBalancer:
        providerParameters:
          type: IBM
          ibm:
            protocol: TCP
        scope: External
      type: LoadBalancerService
    
  3. 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.

  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 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.

  1. 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
    
  2. Aktualisieren Sie die Timeout-Parameter: Um die Parameter clientTimeout und serverTimeout für ein bestimmtes IngressController zu ändern, können Sie einen Patch-Befehl ausführen. Der folgende Befehl aktualisiert beispielsweise die Timeout-Einstellung für die default Ingress Controller auf 905 Sekunden:

    oc patch ingresscontrollers default --patch '{"spec": {"tuningOptions":{"clientTimeout": "905s", "serverTimeout": "905s"}}}' --type=merge -n openshift-ingress-operator
    
  3. 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