如何在集群的负载均衡过程保留请求源IP

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,118元/月
云原生网关 MSE Higress,422元/月
简介: 本文探讨了在Kubernetes (k8s)集群中如何确保服务获取到请求的源IP。通常,源IP可能会因网络地址转换(NAT)和代理服务器而丢失。为保留源IP,文章建议在代理服务器层添加HTTP头`X-REAL-IP`字段。在K8s中,通过设置`externalTrafficPolicy: Local`可保留源IP,但这会牺牲负载均衡。使用Ingress时,可通过配置Ingress Controller的`use-forwarded-headers`并调整ConfigMap来同时保留源IP和实现负载均衡。文章适用于对网络和K8s感兴趣的读者。

引言

应用部署不一定总是简单的安装运行, 有时候还需要考虑网络的问题. 本文将介绍如何在k8s集群中使服务能获取到请求的源IP.

应用提供服务一般依赖输入信息, 输入信息如果不依赖五元组(源 IP, 源端口, 目的 IP, 目的端口, 协议), 那么该服务和网络耦合性低, 不需要关心网络细节.

因此, 对多数人来说都没有阅读本文的必要, 如果你对网络感兴趣, 或者希望拓宽一点视野, 可以继续阅读下文, 了解更多的服务场景.

本文基于 k8s v1.29.4, 文中部分叙述混用了 pod 和 endpoint, 本文场景下可以视为等价.

如果有错误, 欢迎指正, 我会及时更正.

为什么源 IP 信息会丢失?

我们首先明确源 IP 是什么, 当 A 向 B 发送请求, B 将请求转发给 C, 虽然 C 看到的 IP 协议的源 IP 是 B 的 IP, 但本文把A的IP看作源 IP.

主要有两类行为会导致源信息丢失:

  1. 网络地址转换(NAT), 目的是节省公网 IPv4, 负载均衡等. 将导致服务端看到的源 IP 是 NAT 设备的 IP, 而不是真实的源 IP.
  2. 代理(Proxy), 反向代理(RP, Reverse Proxy)和负载均衡(LB, Load Balancer)都属于这一类, 下文统称代理服务器. 这类代理服务会将请求转发给后端服务, 但是会将源 IP 替换为自己的 IP.
  • NAT 简单来说是以端口空间换IP空间, IPv4 地址有限, 一个 IP 地址可以映射 65535 个端口, 绝大多数时候这些端口没有用完, 因而可以多个子网 IP 共用一个公网 IP, 在端口上区分不同的服务. 其使用形式是: public IP:public port -> private IP_1:private port, 更多内容请自行参阅网络地址转换
  • 代理服务是为了隐藏或暴露, 代理服务会将请求转发给后端服务, 同时将源 IP 替换为自己的 IP, 以此来隐藏后端服务的真实 IP, 保护后端服务的安全. 代理服务的使用形式是: client IP -> proxy IP -> server IP, 更多内容请自行参阅代理

NAT代理服务器都非常常见, 多数服务都无法获得请求的源 IP.

这是常见的两类修改源 IP 的途径, 如有其它欢迎补充.

如何保留源 IP?

以下是一个 HTTP 请求的例子:

字段 长度(字节) 位偏移 描述
IP 首部
源 IP 4 0-31 发送方的 IP 地址
目的 IP 4 32-63 接收方的 IP 地址
TCP 首部
源端口 2 0-15 发送端口号
目的端口 2 16-31 接收端口号
序列号 4 32-63 用于标识发送方发送的数据的字节流
确认号 4 64-95 如果设置了 ACK 标志,则为下一个期望收到的序列号
数据偏移 4 96-103 数据起始位置相对于 TCP 首部的字节数
保留 4 104-111 保留字段,未使用,设置为 0
标志位 2 112-127 各种控制标志,如 SYN、ACK、FIN 等
窗口大小 2 128-143 接收方可以接收的数据量
检验和 2 144-159 用于检测数据是否在传输过程中发生了错误
紧急指针 2 160-175 发送方希望接收方尽快处理的紧急数据的位置
选项 可变 176-... 可能包括时间戳、最大报文段长度等
HTTP 首部
请求行 可变 ...-... 包括请求方法、URI 和 HTTP 版本
头部字段 可变 ...-... 包含各种头部字段,如 Host、User-Agent 等
空行 2 ...-... 用于分隔头部和主体部分
主体 可变 ...-... 可选的请求或响应正文

浏览以上 HTTP 请求结构, 可以发现, 有TCP选项,请求行, 头部字段,主体是可变的, 其中TCP选项空间有限, 一般不会用来传递源 IP, 请求行携带信息固定不能扩展, HTTP主体加密后不能修改, 只有HTTP 头部字段适合扩展传递源 IP.

HTTP header 中可以增加X-REAL-IP字段, 用来传递源 IP, 这个操作通常放在代理服务器上, 然后代理服务器会将请求发送给后端服务, 后端服务就可以通过这个字段获取到源 IP 信息.

注意, 需要保证代理服务器NAT设备之前, 这样才能获取到真实的请求的源 whoami. 我们可以在阿里云的产品中看到负载均衡器这个商品单独品类, 它在网络中的位置不同于普通的应用服务器.

K8S 操作指导

whoami项目为例进行部署.

创建 Deployment

首先创建服务:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: whoami
  template:
    metadata:
      labels:
        app: whoami
    spec:
      containers:
        - name: whoami
          image: docker.io/traefik/whoami:latest
          ports:
            - containerPort: 8080

这步会创建一个Deployment, 里面包含 3 个Pod, 每个 pod 包含一个容器, 该容器会运行whoami服务.

创建 Service

可以创建NodePort或者LoadBalancer类型的服务, 支持外部访问, 或者创建ClusterIP类型的服务, 仅支持集群内部访问, 再增加Ingress服务, 通过Ingress服务暴露外部访问.

NodePort既可以通过NodeIP:NodePort访问, 也可以通过Ingess服务访问, 方便测试, 本节使用NodePort服务.

apiVersion: v1
kind: Service
metadata:
  name: whoami-service
spec:
  type: NodePort
  selector:
    app: whoami
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
      nodePort: 30002

创建服务后, 以curl whoami.example.com:30002访问, 可以看到返回的 IP 是NodeIP, 而不是请求的源 whoami.

请注意,这并不是正确的客户端 IP,它们是集群的内部 IP。这是所发生的事情:

  • 客户端发送数据包到 node2:nodePort
  • node2 使用它自己的 IP 地址替换数据包的源 IP 地址(SNAT)
  • node2 将数据包上的目标 IP 替换为 Pod IP
  • 数据包被路由到 node1,然后到端点
  • Pod 的回复被路由回 node2
  • Pod 的回复被发送回给客户端

用图表示:

配置 externalTrafficPolicy: Local

为避免这种情况,Kubernetes 有一个特性可以保留客户端源 IP。 如果将 service.spec.externalTrafficPolicy 设置为 Local, kube-proxy 只会将代理请求代理到本地端点,而不会将流量转发到其他节点。
apiVersion: v1
kind: Service
metadata:
  name: whoami-service
spec:
  type: NodePort
  externalTrafficPolicy: Local
  selector:
    app: whoami
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
      nodePort: 30002

使用curl whoami.example.com:30002进行测试, 当whoami.example.com映射到集群多个 node 的 IP 时, 有一定比例的几率无法访问. 需要确认域名记录只含有 endpoint(pod)所在 node(节点)的 ip.

这个配置有其代价, 那就是失去了集群内的负载均衡能力, 客户端只有访问部署了 endpoint 的 node 才会得到响应.

访问路径限制

当客户端访问 Node 2 时, 不会有响应.

创建 Ingress

多数服务提供给用户时使用 http/https, https: //ip:port的形式可能让用户感到陌生. 一般会使用Ingress将上文创建的NodePort服务负载到一个域名的 80/443 端口下.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: whoami-ingress
  namespace: default
spec:
  ingressClassName: external-lb-default
  rules:
    - host: whoami.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: whoami-service
                port:
                  number: 80

应用后, 使用curl whoami.example.com访问测试, 可以看到 ClientIP 总是 endpoint 所在节点上的Ingress Controller的 Pod IP.

root@client:~# curl whoami.example.com
...
RemoteAddr: 10.42.1.10:56482
...

root@worker:~# kubectl get -n ingress-nginx pod -o wide
NAME                                       READY   STATUS    RESTARTS   AGE    IP           NODE          NOMINATED NODE   READINESS GATES
ingress-nginx-controller-c8f499cfc-xdrg7   1/1     Running   0          3d2h   10.42.1.10   k3s-agent-1   <none>           <none>

使用Ingress反向代理NodePort服务, 也就是在 endpoint 前套了两层 service, 下图展示了二者区别.

graph LR
    A[Client] -->|whoami.example.com:80| B(Ingress)
    B -->|10.43.38.129:32123| C[Service]
    C -->|10.42.1.1:8080| D[Endpoint]
graph LR
    A[Client] -->|whoami.example.com:30001| B(Service)
    B -->|10.42.1.1:8080| C[Endpoint]

在路径 1 中, 外部访问 Ingress 时, 流量先到达的 endpoint 是Ingress Controller, 然后再到达 endpoint whoami.
Ingress Controller实质是一个LoadBalancer的服务,

kubectl -n ingress-nginx get svc

NAMESPACE   NAME             CLASS   HOSTS                       ADDRESS                                              PORTS   AGE
default     echoip-ingress   nginx   ip.example.com       172.16.0.57,2408:4005:3de:8500:4da1:169e:dc47:1707   80      18h
default     whoami-ingress   nginx   whoami.example.com   172.16.0.57,2408:4005:3de:8500:4da1:169e:dc47:1707   80      16h

因此, 可以通过将前文提到的externalTrafficPolicy设置到 Ingress Controller 中来保留源 IP.

同时还需要设置ingress-nginx-controllerconfigmap中的use-forwarded-headerstrue, 以便Ingress Controller能够识别X-Forwarded-ForX-REAL-IP字段.

apiVersion: v1
data:
  allow-snippet-annotations: "false"
  compute-full-forwarded-for: "true"
  use-forwarded-headers: "true"
  enable-real-ip: "true"
  forwarded-for-header: "X-Real-IP" # X-Real-IP or X-Forwarded-For
kind: ConfigMap
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.10.1
  name: ingress-nginx-controller
  namespace: ingress-nginx

NodePort服务与ingress-nginx-controller服务的区别主要在于, NodePort的后端通常不部署在每台 node 上, 而ingress-nginx-controller的后端通常部署在每台对外暴露的 node 上.

NodePort服务中设置externalTrafficPolicy会导致跨 node 的请求无响应不同, Ingress可以将请求先设置 HEADER 之后再进行代理转发, 实现了保留源 IP负载均衡的两种能力.

总结

  • 地址转换(NAT), 代理(Proxy),反向代理(Reverse Proxy), 负载均衡(Load Balance)会导致源 IP 丢失.
  • 为防止源 IP 丢失, 可以代理服务器转发时将真实 IP 设置在 HTTP 头部字段X-REAL-IP中, 通过代理服务传递. 如果使用多层代理, 则可以使用X-Forwarded-For字段, 该字段以的形式记录了源 IP 及代理路径的 IP list.
  • 集群NodePort服务设置externalTrafficPolicy: Local可以保留源 IP, 但会失去负载均衡能力.
  • ingress-nginx-controllerdaemonset形式部署在所有loadbalancer角色 node 上的前提下, 设置externalTrafficPolicy: Local可以保留源 IP, 且保留负载均衡能力.

参考

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
1月前
|
负载均衡 网络协议 算法
【揭秘】IP负载均衡背后的神秘力量:如何让网站永不宕机?揭秘四大核心技术,解锁高可用性的秘密通道!
【8月更文挑战第19天】负载均衡技术保障互联网服务的高可用性和可扩展性。它像交通指挥官般按策略分配用户请求至服务器集群,提高响应速度与系统稳定性。本文轻松介绍IP负载均衡的工作原理、算法(如轮询、最少连接数)及实现方法,通过示例展示基于四层负载均衡的设置步骤,并讨论健康检查和会话保持的重要性。负载均衡是构建高效系统的关键。
31 2
|
23天前
|
负载均衡 算法 应用服务中间件
负载均衡技术在Web服务器集群中的应用
【8月更文第28天】随着互联网的发展和用户对Web服务需求的增长,单台服务器很难满足大规模访问的需求。为了提高系统的稳定性和扩展性,通常会采用Web服务器集群的方式。在这种架构中,负载均衡器扮演着至关重要的角色,它能够合理地分配客户端请求到不同的后端服务器上,从而实现资源的最优利用。
53 2
|
1月前
|
负载均衡 算法 关系型数据库
MySQL集群如何实现负载均衡?
【8月更文挑战第16天】MySQL集群如何实现负载均衡?
65 6
|
1月前
|
负载均衡 网络协议 中间件
IP负载均衡技术
【8月更文挑战第17天】IP负载均衡技术
35 4
|
1月前
|
负载均衡 网络协议
使用LVS搭建集群实现负载均衡(二)安装使用
【8月更文挑战第8天】使用LVS搭建集群实现负载均衡(二)安装使用
40 4
|
1月前
|
存储 负载均衡 算法
使用LVS搭建集群实现负载均衡(一)
【8月更文挑战第8天】使用LVS搭建集群实现负载均衡
51 4
|
2月前
|
缓存 负载均衡 算法
(四)网络编程之请求分发篇:负载均衡静态调度算法、平滑轮询加权、一致性哈希、最小活跃数算法实践!
先如今所有的技术栈中,只要一谈关于高可用、高并发处理相关的实现,必然会牵扯到集群这个话题,也就是部署多台服务器共同对外提供服务,从而做到提升系统吞吐量,优化系统的整体性能以及稳定性等目的。
|
2月前
|
运维 负载均衡 Serverless
Serverless 应用引擎使用问题之如何将应用部署到多个实例中,并利用SLB来分发请求负载
阿里云Serverless 应用引擎(SAE)提供了完整的微服务应用生命周期管理能力,包括应用部署、服务治理、开发运维、资源管理等功能,并通过扩展功能支持多环境管理、API Gateway、事件驱动等高级应用场景,帮助企业快速构建、部署、运维和扩展微服务架构,实现Serverless化的应用部署与运维模式。以下是对SAE产品使用合集的概述,包括应用管理、服务治理、开发运维、资源管理等方面。
|
1月前
|
负载均衡 前端开发 数据处理
"揭秘!ALB负载均衡器如何赋能Airflow,让数据处理命令请求在云端翩翩起舞,挑战性能极限,你不可不知的秘密!"
【8月更文挑战第20天】在现代云计算环境中,负载均衡ALB作为七层HTTP/HTTPS流量分发器,能显著提升系统的可用性和扩展性。结合Airflow这一开源工作流管理平台,ALB可以有效分发其REST API命令请求。通过配置ALB实例监听HTTP/S请求,并将多个Airflow实例加入目标组,再配合健康检查确保实例稳定,即可实现对Airflow命令的高效负载均衡,进而增强数据处理任务的可靠性和性能。
21 0
|
2月前
|
消息中间件 负载均衡 算法
【RocketMQ系列十二】RocketMQ集群核心概念之主从复制&生产者负载均衡策略&消费者负载均衡策略
【RocketMQ系列十二】RocketMQ集群核心概念之主从复制&生产者负载均衡策略&消费者负载均衡策略
73 2