如何在Keepalived负载均衡器与K8s容器中调大请求头上限
Got it, let's tackle this step by step since you're running a K8s 1.8 HA cluster with Keepalived + Nginx as your load balancer, and need to bump the max request header size to 64MB.
First, a quick note: Keepalived operates at the TCP layer (L4) as a VIP failover mechanism—it doesn't handle HTTP request headers at all. So your existing Keepalived configuration doesn't need any changes here. All the adjustments will happen in two places: your Nginx proxy layer and your Dockerized containers/backend applications. Here's how to do it:
1. Nginx Proxy Layer Configuration
You'll need to modify your Nginx config (either the main nginx.conf or site-specific config under /etc/nginx/sites-available/) to increase header buffer limits. Add or update these directives in the http, server, or location block (applying at the http level affects all your proxied services):
# Buffer size for standard request headers client_header_buffer_size 64M; # Buffers for larger-than-normal request headers # Format: [number_of_buffers] [buffer_size_per_buffer] # We set each buffer to 64MB to fit your max header size, with 4 buffers as a safe default large_client_header_buffers 4 64M; # Optional: Uncomment if you also need to support large request bodies # client_max_body_size 64M;
What do these directives do?
client_header_buffer_size: Ensures regular-sized request headers don't get truncated by setting a matching 64MB buffer.large_client_header_buffers: Catches oversized headers (like long auth tokens or custom metadata) by providing enough buffer space to accommodate your 64MB limit.
After making changes, validate the Nginx config to avoid syntax errors:
nginx -t
If the test passes, restart Nginx to apply the changes:
systemctl restart nginx # Use this for older distros if needed # service nginx restart
2. Docker Container Layer Adjustments
This depends on what's running inside your backend containers (the real servers behind Nginx). Here are common scenarios:
Scenario A: Container runs Nginx (internal proxy for the app)
If your container uses Nginx to proxy traffic to an internal application, add the same header buffer directives to the container's Nginx config. For better manageability in K8s, use a ConfigMap to mount a custom config:
# Example K8s ConfigMap for container-side Nginx apiVersion: v1 kind: ConfigMap metadata: name: app-nginx-config data: nginx.conf: | http { client_header_buffer_size 64M; large_client_header_buffers 4 64M; # Rest of your container Nginx config (server blocks, location rules, etc.) }
Mount this ConfigMap into your Pod's Nginx container at the appropriate path (e.g., /etc/nginx/nginx.conf) via your Pod or Deployment manifest.
Scenario B: Container runs a custom application
Adjust your app's built-in web server settings to accept larger headers:
- Spring Boot (Java): Add to
application.properties:server.max-http-header-size=67108864 # 64MB in bytes - Express (Node.js): Update your app setup:
const express = require('express'); const app = express(); // Handle JSON and URL-encoded data with 64MB limit app.use(express.json({ limit: '64mb' })); app.use(express.urlencoded({ extended: true, limit: '64mb' })); - Django (Python): Modify
settings.py:DATA_UPLOAD_MAX_MEMORY_SIZE = 67108864 # 64MB
Scenario C: K8s Control Plane Components (e.g., kube-apiserver)
If your LB is proxying to the kube-apiserver (unlikely given your port setup, but just in case), adjust the apiserver's --max-request-bytes flag (headers count toward the total request size). Add this to your kube-apiserver manifest or systemd service file:
--max-request-bytes=67108864 # 64MB in bytes
Then restart the kube-apiserver service.
3. Verify the Changes
Test with a request containing a large header to confirm everything works:
# Send a request with a 64MB test header curl -H "X-Large-Test-Header: $(printf 'x%.0s' {1..67108864})" http://<your-vip-ip>:9081
If you don't get a 414 Request-URI Too Large or 400 Bad Request error, your adjustments are working as expected.
内容的提问来源于stack exchange,提问作者manoj kumar

