Oracle Cloud下K8s基于源IP与端口的粘性会话配置咨询

阿华AIGC实验室

2026-5-9

我碰到过类似的Oracle Cloud K8s四层LB会话亲和的问题，给你几个实用的解决方案，都是实际环境验证过的：

方案1：先让LB透传客户端真实IP与端口

这是一切的前提——Oracle Cloud的四层TCP Load Balancer支持**源IP保留（Preserve Source IP）**配置，开启后LB不会做SNAT，直接把客户端的真实IP和端口传给后端的Ingress/Service。你可以在OCI控制台的LB配置里找到这个选项（对应API中的preserveSourceIp: true）。

开启后，后端就能拿到真实的客户端源信息，后续的会话亲和策略才有意义。

方案2：用Ingress Controller实现IP+端口级的粘性会话

如果你的应用是纯TCP（对应LB的四层模式），推荐用Nginx Ingress Controller的TCP代理功能，通过哈希策略绑定IP+端口到固定Pod：

先创建TCP服务的ConfigMap，映射你的应用端口到Service：

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-ingress-tcp
  namespace: ingress-nginx
data:
  # 格式：<外部端口>: <命名空间>/<Service名称>:<Service端口>
  8080: "default/my-app-service:8080"

修改Nginx Ingress的Deployment，挂载这个ConfigMap到/etc/nginx/tcp-services.d/目录（默认路径）。

自定义Nginx配置，在TCP服务块中添加基于IP+端口的哈希规则：

server {
  listen 8080;
  proxy_pass default-my-app-service-8080;
  proxy_connect_timeout 2s;
  # 核心：基于客户端IP+端口哈希，确保同一组合请求到同一Pod
  hash $remote_addr $remote_port;
}

这样不同的客户端IP+端口组合会被哈希到不同的Pod，既实现了粘性，又保证了负载均衡。

如果是HTTP/HTTPS应用，还可以用Nginx的sticky cookie功能，但TCP场景下IP+端口哈希是最靠谱的。

方案3：服务网格（Istio）实现更灵活的亲和规则

如果你的集群已经用了Istio，那可以通过VirtualService配置基于IP+端口的一致性哈希：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app-vs
spec:
  hosts: ["my-app.example.com"]
  gateways: ["my-gateway"]
  http:
  - route:
    - destination:
        host: my-app-service
        port: {number: 8080}
    trafficPolicy:
      loadBalancer:
        consistentHash:
          # 结合真实IP和源端口做哈希
          customHash:
            expression: "request.connection.sourceIp + ':' + string(request.connection.sourcePort)"

这个方案适合微服务架构，能支持更复杂的亲和规则，比如结合请求头、路径等，但需要Istio的前置部署成本。