K8s Ingress Controller多副本环境下SSL会话票据复用功能失效问题求助

Let's break down your problem and walk through actionable steps to fix the SSL session reuse issue when scaling your ingress controller beyond one replica.

First, Recap the Context #

You've configured SSL session caching and tickets in your ingress controller's ConfigMap, with identical tickets.key and nginx configs across all replicas. Single-replica works perfectly, but multi-replica setups force full TLS handshakes on cross-replica requests even when valid session tickets are sent.

Key Troubleshooting Steps to Validate First #

Let's start with the simplest (yet most critical) checks:

1. Verify tickets.key Consistency & Permissions Across All Replicas

Even if you think the key is the same, confirm it with a hash check in each pod:

# Exec into each ingress pod and run this
cat /etc/nginx/tickets.key | md5sum

All outputs must match exactly. Additionally, check the file permissions:

ls -l /etc/nginx/tickets.key

The key should have permissions 600 and be owned by the nginx user. If not, nginx will fall back to generating a temporary, unique key per pod—this would explain why cross-replica ticket reuse fails.

2. Check Nginx Error Logs for Ticket Key Issues

Look for any errors related to SSL session tickets in each pod's error log:

cat /var/log/nginx/error.log | grep -i ticket

If you see messages like invalid key length or failed to load session ticket key, your key generation might have been corrupted, or the file isn't accessible to nginx.

3. Test Session Reuse Directly with openssl s_client

Bypass your frontend load balancer to test directly against individual ingress pod IPs:

# 1. First handshake with pod 1, save the session ticket
openssl s_client -connect <pod-1-ip>:443 -servername your-domain.com -sess_out ticket.bin

# 2. Reuse the ticket with pod 2
openssl s_client -connect <pod-2-ip>:443 -servername your-domain.com -sess_in ticket.bin

Look for the line Reused, TLSv1.2 in the second output—if this doesn't appear, the ticket isn't being recognized by pod 2, confirming the key or config issue.

Potential Fixes #

Fix 1: Ensure Proper Key Mounting & Permissions

If your tickets.key is mounted via a ConfigMap or secret, make sure the mount sets the correct permissions. For RKE2's ingress controller, you can adjust the pod security context or use an init container to set permissions:

# Example init container to set ticket key permissions
initContainers:
- name: set-key-perms
  image: busybox:1.36
  command: ["chmod", "600", "/etc/nginx/tickets.key"]
  volumeMounts:
  - name: ticket-key
    mountPath: /etc/nginx/tickets.key

Fix 2: Rule Out Load Balancer Interference

If your frontend LB is terminating SSL (instead of doing 4-layer TCP pass-through), the session reuse happens at the LB level, not the ingress controller. Confirm your LB is configured to pass SSL traffic directly to the ingress pods.

Fix 3: Upgrade the Ingress Controller Version

Your version rke2-ingress-nginx:1.36.301 corresponds to an older ingress-nginx controller release. There have been fixes related to SSL session ticket handling in newer versions—consider upgrading to a more recent release (match the RKE2-compatible version, e.g., rke2-ingress-nginx:1.10.x for newer RKE2 versions).

Fix 4: Switch to Redis-Shared Session Cache

If session tickets continue to fail, you can use a shared Redis cache for SSL sessions (this works across all replicas):

1. Deploy a Redis service in your cluster.
2. Update your ingress ConfigMap to use the Redis cache:

   ssl-session-cache: "redis:redis://redis-service:6379/0"
   ssl-session-cache-size: "100m" # Adjust based on your needs
   

This lets all ingress replicas share the same session cache pool, enabling cross-replica session reuse without relying on tickets.

内容的提问来源于stack exchange，提问作者Alexander Kolin