494 Request header too large

Kubernetes
#1

Hello,

I installed kong in AKS private mode:
Modified the service in all-in-one-dbless.yaml to match:
service.beta.kubernetes.io/azure-load-balancer-internal: “true”
and with loadBalancerIP:xxxx in the spec.

1/ kubectl apply -f all-in-one-dbless.yaml
2/ Try to expose kong-proxy via SSL:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    kubernetes.io/ingress.class: kong
  name: kong-ingress
  namespace: kong
spec:
  rules:
  - host: api.domain.com
    http:
      paths:
      - backend:
          serviceName: kong-proxy
          servicePort: 80
        path: /
  tls:
  - hosts:
    - api.domain.com
    secretName: kong-ingress-tls-secret

I am getting the following error in my browser:
Request header or cookie too large

Locally it works as expected:
curl http://localhost:8000 {"message":"no Route matched with those values"}

Thank you,
merou

#2

I also tried all suggested recommendations but it did not work:
e.g increase KONG_NGINX_HTTP_CLIENT_BODY_BUFFER_SIZE, change port…

The weird thing is that if I just use the self signed certificate from Kong it works (so basically i do not apply the ingress above).

So my question is how can i apply let’s encrypt certificate on kong-proxy service?

#3

Your second message mentions the body size setting, not the header size setting. Header size is controlled by
client_header_buffer_size and large_client_header_buffers, which you’d set via the KONG_NGINX_HTTP_CLIENT_HEADER_BUFFER_SIZE and KONG_NGINX_HTTP_LARGE_CLIENT_HEADER_BUFFERS environment variables.

That example curl request isn’t passing any cookies (the most likely reason the headers are large), whereas your browser normally will send any cookies it has set, which is why you’re seeing different results there. The certificate configuration looks fine (you’d see a different error in your browser request otherwise).

#4

Hello @traines thank you for your answer.

I ended up using the nginx ingress controller from Kubernetes and use Kong as an API gateway only.

For user adoption I think the Kong ingress controller should just work out the box, as it is the case for the nginx one.