Insbesondere bei der Migration einer Quarkus 2 Anwendung auf Quarkus 3 stößt man beim Testen der Anwendung im K8s-Cluster eventuell auf das Problem, dass die Anwendung über den konfigurierten Ingress nicht erreichbar ist und uns nur eine Fehlerseite mit dem HTTP Statuscode 502 Bad Gateway vom nginx Ingress erwartet. Dabei hat man doch in der Konfiguration des Ingress gar nichts verändert!
Das Problem wird klarer, wenn man sich den Log des Ingress Controllers anschaut. Hier findet sich folgender Abschnitt:
[...] upstream sent too big header while reading response header from upstream [...]Die Authentifizierung unserer Anwendung läuft in diesem Fall über OIDC und im K8s-Cluster läuft zu diesem Zweck ein Keycloak. Quarkus 3 speichert anders als Quarkus 2 die notwendigen Tokens in den Browser Cookies nun standardmäßig verschlüsselt. Das führt dazu, dass die Cookies größer werden und auch der “Set-Cookie” HTTP-Header, mit dem die Anwendung den Browser anweist die Tokens in einem Cookie zu speichern, an Größe zunimmt. Standardmäßig hat der häufig eingesetzte nginx als Ingress Controller eine proxy-buffer-size von 4k eingestellt, leider reißt unsere HTTP-Response nun dieses Limit und der Ingress antwortet stattdessen mit einem Fehler. Die Lösung für dieses Problem ist allerdings relativ einfach umsetzbar, denn eine Vergrößerung dieser Einstellung lässt das Problem verschwinden. Im Falle des nginx Ingress Controllers kann die Konfiguration z.B. direkt an der spezifischen K8s-Ingress Beschreibung vorgenommen werden.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/proxy-buffer-size: "16k"
Hier kann dann die proxy-buffer-size erhöht werden und die Anwendung sollte nun auch in der Quarkus 3 Version erreichbar sein.
