Kubernetes, nginx ingress controller, Azure AD i upstream sent too big header
Pisane i publikowane na szybko. Za gramatykę i język nie odpowiadam, do czasu korekty ;-)
Chwilę po godzinie 16 na fb Piotrek z FinAI(jak szukacie kredytu warto zajrzeć do ich aplikacji) przywitał mnie taką o to wiadomością.
W ich przypadku to aplikacja .NET Core, która używa do uwierzytelniania (nie ma słowa autentykacja!!!) Azure AD. Równie dobrze, może to być inny oidc jak IdenityServer, DEX czy ADFS. Sama aplikacja stoi na Kubernetes i jest wystawiona poprzez tytułowy ingress controller. W logu ingress controller opartego o nginx pojawił się radosny wpis upstream sent too big header while reading response header from upstream, …
, a strona raczyła klasycznym 502 Bad Gateway z nginx.
W czystym nginx leczy się to taki wpisem w konfiguracji.
proxy_buffer_size 16k;
W Kubernetes i ingress sprawę załatwia prosty ConfigMap. Jeśli ingress był wrzucony kubectl apply -f <link do oficjalnego yaml z gita>
, to trzeba w ConfigMap nginx-configuration
dodać proxy-buffer-size
jak w przykładzie poniżej. Cała zabawa polega na tym, że używamy –
zamiast _
, które są w konfiguracji normalnie nginx.
kind: ConfigMap
apiVersion: v1
metadata:
name: nginx-configuration
namespace: kube-system
labels:
k8s-app: nginx-ingress-controller
data:
proxy-buffer-size: "16k"
Jeśli zas Twój ingress jest robiony poprzez helm. To trzeba przygotować plik z własnymi parametrami.
Zawartość do tego wygląda tak:
controller:
config:
proxy-buffer-size: 16k
Resztę konfiguracji nginx dla ingress, można sobie wyszukać w dokumentacji – RTFM <3.
Przy okazji ekipa z FinAI szuka Senior Devów oraz kogoś do czuwania jako Ops nad Devami aka Cloud Admin. Polecam, bo faktycznie atmosfera jest fajna, a produkt, który budują jest naprawdę ciekawy. No i CTO częstuje dobrą whisky pod koniec pracy ;-)