☰

502-Fehler mit Nginx-Ingress in Kubernetes zum benutzerdefinierten Endpunkt

tag-icon • tag-icon nginx kubernetes nginx-ingress
502-Fehler mit Nginx-Ingress in Kubernetes zum benutzerdefinierten Endpunkt

Ich habe einen Eingang, der zu einem benutzerdefinierten Endpunkt außerhalb des Kubernetes-Clusters weiterleitet. Der Dienst hört nur auf HTTPS auf Port 8006.

apiVersion: v1
kind: Service
metadata:
  name: pve
spec:
  ports:
    - protocol: TCP
      port: 8006
---
apiVersion: v1
kind: Endpoints
metadata:
  name: pve
subsets:
  - addresses:
      - ip: 10.0.1.2
    ports:
      - port: 8006
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: pve

  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "off"
    nginx.ingress.kubernetes.io/whitelist-source-range: "10.0.0.0/16"

spec:
  tls:
    - hosts:
        - pve.example.com
      secretName: pve-tls
  rules:
    - host: pve.example.com
      http:
        paths:
          - backend:
              serviceName: pve
              servicePort: 8006
            path: /

Gibt den Fehler im Nginx-Pod aus:

10.0.0.25 - - [28/Aug/2020:01:17:58 +0000] "GET / HTTP/1.1" 502 157 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0" "-"

28.08.2020 01:17:58 [Fehler] 2609#2609: *569 Upstream hat die Verbindung vorzeitig geschlossen, während der Antwortheader vom Upstream gelesen wurde, Client: 10.0.0.25, Server: pve.example.com, Anfrage: „GET / HTTP/1.1“, Upstream: „http://10.0.1.2:8006/“, Host: „pve.example.com“

Bearbeiten

Nach dem Entfernen des Proxy-Protokolls erhalte ich den Fehler

10.0.10.1 - - [28/Aug/2020:02:19:18 +0000] "GET / HTTP/1.1" 400 59 "-" "curl/7.58.0" "-"

28.08.2020 02:19:26 [Fehler] 2504#2504: *521 Upstream hat die Verbindung vorzeitig geschlossen, während der Antwortheader vom Upstream gelesen wurde, Client: 10.0.10.1, Server: pve.example.com, Anfrage: „GET / HTTP/1.1“, Upstream: „http://10.0.1.2:8006/“, Host: „pve.example.com“

10.0.10.1 - - [28/Aug/2020:02:19:26 +0000] "GET / HTTP/1.1" 502 157 "-" "curl/7.58.0" "-"

 

Und falls es relevant ist, meine Nginx-Konfiguration, bereitgestellt über den Helm-Charnginx-stable/nginx-ingress

  ## nginx configuration
  ## Ref: https://github.com/kubernetes/ingress/blob/master/controllers/nginx/configuration.md
  ##
  controller:
    config:
      entries:
        hsts-include-subdomains: "false"
        ssl-ciphers: "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"
        ssl-protocols: "TLSv1.1 TLSv1.2"
    ingressClass: nginx
    service:
      externalTrafficPolicy: Local
      annotations:
        metallb.universe.tf/address-pool: default
  defaultBackend:
    enabled: true
  tcp:
    22: "gitlab/gitlab-gitlab-shell:22"

Antwort1

Diese Anmerkung ist wahrscheinlich die Ursache des Problems.

    nginx.ingress.kubernetes.io/use-proxy-protocol: "true"

DerDokumenteZustand:

Aktiviert oder deaktiviert das PROXY-Protokoll, um Client-Verbindungsinformationen (echte IP-Adresse) zu empfangen, die über Proxy-Server und Load Balancer wie HAProxy und Amazon Elastic Load Balancer (ELB) übermittelt werden.

Wenn Sie vor Ihrem Ingress keinen Load Balancer haben, der Verbindungen mithilfe des PROXY-Protokolls weiterleitet, dann ist dies nicht das, was Sie wollen, und diese Annotation sollte nicht vorhanden sein (oder sollte vorhanden sein "false").

Antwort2

Dies ist eine Community-Wiki-Antwort. Sie können sie gerne erweitern.

Der angezeigte Fehler upstream prematurely closed connection while reading response header from upstreamkommt von Nginx und bedeutet, dass die Verbindung von Ihrem „Upstream“ geschlossen wurde.

Es ist schwer zu sagen, was die genaue Ursache dieses Problems sein könnte, ohne die notwendigen Details, aber was Sie trotzdem tun können, ist zu versuchen, den Timeout-Wert entsprechend zu erhöhendiese Dokumentation, und zwar:

  • proxy_read_timeout

  • proxy_connect_timeout

Sie können den Code/die Konfiguration auch in Ihrem „Upstream“ anpassen, was auch immer es in Ihrem Anwendungsfall ist.

verwandte Informationen