使用源 IP

在 Kubernetes 集群中运行的应用程序通过 Service 抽象来查找和相互通信，以及与外部世界通信。本文档解释了发送到不同类型 Service 的数据包的源 IP 地址发生了什么，以及如何根据您的需求切换此行为。

开始之前

术语

本文档使用以下术语

NAT: 网络地址转换
源 NAT: 替换数据包的源 IP 地址；在本页中，这通常意味着用节点的 IP 地址替换。
目标 NAT: 替换数据包的目标 IP 地址；在本页中，这通常意味着用 Pod 的 IP 地址替换。
VIP: 虚拟 IP 地址，例如分配给 Kubernetes 中每个 Service 的地址。
kube-proxy: 一个网络守护进程，它在每个节点上协调 Service VIP 管理。

先决条件

您需要有一个 Kubernetes 集群，并且 kubectl 命令行工具必须配置为与您的集群通信。建议在至少有两个节点（不充当控制平面主机）的集群上运行本教程。如果您还没有集群，可以使用 minikube 创建一个，或者可以使用以下 Kubernetes 游乐场之一。

这些示例使用一个小的 nginx webserver，它通过 HTTP 标头回显它接收到的请求的源 IP 地址。您可以按如下方式创建它。

注意

以下命令中的镜像仅在 AMD64 架构上运行。

kubectl create deployment source-ip-app --image=registry.k8s.io/echoserver:1.4

输出是

deployment.apps/source-ip-app created

目标

通过各种类型的 Service 公开一个简单的应用程序。
了解每种 Service 类型如何处理源 IP NAT。
了解保留源 IP 地址所涉及的权衡。

具有 `Type=ClusterIP` 的 Service 的源 IP 地址

如果 kube-proxy 在 iptables 模式下运行（默认值），则从集群内部发送到 ClusterIP 的数据包永远不会进行源 NAT。您可以通过在运行 kube-proxy 的节点上获取 http://localhost:10249/proxyMode 来查询 kube-proxy 模式。

kubectl get nodes

输出类似于以下内容

NAME                           STATUS     ROLES    AGE     VERSION
kubernetes-node-6jst   Ready      <none>   2h      v1.13.0
kubernetes-node-cx31   Ready      <none>   2h      v1.13.0
kubernetes-node-jj1t   Ready      <none>   2h      v1.13.0

获取其中一个节点上的代理模式（kube-proxy 监听端口 10249）

# Run this in a shell on the node you want to query.
curl http://localhost:10249/proxyMode

输出是

iptables

您可以通过在源 IP 应用程序上创建一个 Service 来测试源 IP 地址保留。

kubectl expose deployment source-ip-app --name=clusterip --port=80 --target-port=8080

输出是

service/clusterip exposed

kubectl get svc clusterip

输出类似于

NAME         TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
clusterip    ClusterIP   10.0.170.92   <none>        80/TCP    51s

并从同一集群中的 Pod 访问 ClusterIP。

kubectl run busybox -it --image=busybox:1.28 --restart=Never --rm

输出类似于以下内容

Waiting for pod default/busybox to be running, status is Pending, pod ready: false
If you don't see a command prompt, try pressing enter.

然后，您可以在该 Pod 中运行一个命令。

# Run this inside the terminal from "kubectl run"
ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue
    link/ether 0a:58:0a:f4:03:08 brd ff:ff:ff:ff:ff:ff
    inet 10.244.3.8/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::188a:84ff:feb0:26a5/64 scope link
       valid_lft forever preferred_lft forever

…然后使用 wget 查询本地 webserver。

# Replace "10.0.170.92" with the IPv4 address of the Service named "clusterip"
wget -qO - 10.0.170.92

CLIENT VALUES:
client_address=10.244.3.8
command=GET
...

无论客户端 Pod 和服务器 Pod 是否在同一节点或不同节点上，client_address 始终是客户端 Pod 的 IP 地址。

具有 `Type=NodePort` 的 Service 的源 IP 地址

默认情况下，发送到具有 Type=NodePort 的 Service 的数据包会进行源 NAT。您可以通过创建一个 NodePort Service 来测试这一点。

kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort

输出是

service/nodeport exposed

NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport)
NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="InternalIP")].address }')

如果您在云提供商上运行，您可能需要为上面报告的 nodes:nodeport 打开一个防火墙规则。现在，您可以尝试通过分配的节点端口从集群外部访问 Service。

for node in $NODES; do curl -s $node:$NODEPORT | grep -i client_address; done

输出类似于

client_address=10.180.1.1
client_address=10.240.0.5
client_address=10.240.0.3

请注意，这些不是正确的客户端 IP 地址，它们是集群内部 IP 地址。这就是发生的事情。

客户端将数据包发送到 node2:nodePort。
node2 用自己的 IP 地址替换数据包中的源 IP 地址（SNAT）。
node2 用 Pod IP 地址替换数据包中的目标 IP 地址。
数据包被路由到节点 1，然后路由到端点。
Pod 的回复被路由回节点 2。
Pod 的回复被发送回客户端。

直观地

source IP nodeport figure 01 — 图。使用 SNAT 的源 IP Type=NodePort

为了避免这种情况，Kubernetes 具有保留客户端源 IP 地址的功能。如果您将 service.spec.externalTrafficPolicy 设置为值 Local，kube-proxy 仅将代理请求代理到本地端点，并且不会将流量转发到其他节点。这种方法保留了原始源 IP 地址。如果没有本地端点，发送到节点的数据包将被丢弃，因此您可以在任何数据包处理规则中依赖正确的数据包源 IP 地址，这些规则可能允许数据包通过到端点。

将 service.spec.externalTrafficPolicy 字段设置为如下所示。

kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}'

输出是

service/nodeport patched

现在，重新运行测试。

for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done

输出类似于

client_address=198.51.100.79

请注意，您只收到一个回复，其中包含正确的客户端 IP 地址，来自运行端点 Pod 的一个节点。

这就是发生的事情。

客户端将数据包发送到 node2:nodePort，该节点没有任何端点。
数据包被丢弃。
客户端将数据包发送到 node1:nodePort，该节点有端点。
节点 1 使用正确的源 IP 地址将数据包路由到端点。

直观地

source IP nodeport figure 02 — 图。源 IP Type=NodePort 保留客户端源 IP 地址

具有 `Type=LoadBalancer` 的 Service 的源 IP 地址

默认情况下，发送到具有 Type=LoadBalancer 的 Service 的数据包会进行源 NAT，因为 Ready 状态下的所有可调度 Kubernetes 节点都有资格接收负载均衡流量。因此，如果数据包到达没有端点的节点，系统会将其代理到有端点的节点，并将数据包中的源 IP 地址替换为节点的 IP 地址（如上一节所述）。

您可以通过通过负载均衡器公开源 IP 应用程序来测试这一点。

kubectl expose deployment source-ip-app --name=loadbalancer --port=80 --target-port=8080 --type=LoadBalancer

输出是

service/loadbalancer exposed

打印出 Service 的 IP 地址。

kubectl get svc loadbalancer

输出类似于以下内容

NAME           TYPE           CLUSTER-IP    EXTERNAL-IP       PORT(S)   AGE
loadbalancer   LoadBalancer   10.0.65.118   203.0.113.140     80/TCP    5m

接下来，向此 Service 的外部 IP 地址发送请求。

curl 203.0.113.140

输出类似于以下内容

CLIENT VALUES:
client_address=10.240.0.5
...

但是，如果您在 Google Kubernetes Engine/GCE 上运行，将相同的 service.spec.externalTrafficPolicy 字段设置为 Local 会强制没有 Service 端点的节点通过故意失败健康检查来从负载均衡流量的节点列表中删除自己。

直观地

Source IP with externalTrafficPolicy

您可以通过设置以下注释来测试这一点。

kubectl patch svc loadbalancer -p '{"spec":{"externalTrafficPolicy":"Local"}}'

您应该立即看到 Kubernetes 分配的 service.spec.healthCheckNodePort 字段。

kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort

输出类似于以下内容

  healthCheckNodePort: 32122

service.spec.healthCheckNodePort 字段指向每个节点上的端口/路径 /healthz，用于提供健康检查。您可以测试这一点。

kubectl get pod -o wide -l app=source-ip-app

输出类似于以下内容

NAME                            READY     STATUS    RESTARTS   AGE       IP             NODE
source-ip-app-826191075-qehz4   1/1       Running   0          20h       10.180.1.136   kubernetes-node-6jst

使用 curl 获取不同节点上的 /healthz 端点。

# Run this locally on a node you choose
curl localhost:32122/healthz

1 Service Endpoints found

在另一个节点上，您可能会得到不同的结果。

# Run this locally on a node you choose
curl localhost:32122/healthz

No Service Endpoints Found

在控制平面上运行的控制器负责分配云负载均衡器。相同的控制器还分配指向每个节点上此端口/路径的 HTTP 健康检查。等待大约 10 秒钟，让 2 个没有端点的节点失败健康检查，然后使用 curl 查询负载均衡器的 IPv4 地址。

curl 203.0.113.140

输出类似于以下内容

CLIENT VALUES:
client_address=198.51.100.79
...

跨平台支持

只有某些云提供商提供通过具有 Type=LoadBalancer 的 Service 保留源 IP 地址的支持。您正在运行的云提供商可能会通过以下几种方式来满足负载均衡器的请求。

使用代理来终止客户端连接并打开一个到您的节点/端点的新的连接。在这种情况下，源 IP 地址始终是云 LB 的 IP 地址，而不是客户端的 IP 地址。
使用数据包转发器，以便从客户端发送到负载均衡器 VIP 的请求最终到达节点，源 IP 地址是客户端的 IP 地址，而不是中间代理的 IP 地址。

第一类负载均衡器必须使用负载均衡器和后端之间商定的协议来通信真实的客户端 IP 地址，例如 HTTP Forwarded 或 X-FORWARDED-FOR 标头，或代理协议。第二类负载均衡器可以通过创建指向 Service 上 service.spec.healthCheckNodePort 字段中存储的端口的 HTTP 健康检查来利用上述功能。

清理

删除 Service。

kubectl delete svc -l app=source-ip-app

删除 Deployment、ReplicaSet 和 Pod。

kubectl delete deployment source-ip-app

下一步

了解有关通过 Service 连接应用程序的更多信息。
阅读如何创建外部负载均衡器。

最后修改时间：2023 年 12 月 20 日下午 8:22 PST：更新说明 (f55c69129a)

使用源 IP

开始之前

术语

先决条件

注意

目标

具有 Type=ClusterIP 的 Service 的源 IP 地址

具有 Type=NodePort 的 Service 的源 IP 地址

具有 Type=LoadBalancer 的 Service 的源 IP 地址

跨平台支持

清理

下一步

反馈

具有 `Type=ClusterIP` 的 Service 的源 IP 地址

具有 `Type=NodePort` 的 Service 的源 IP 地址

具有 `Type=LoadBalancer` 的 Service 的源 IP 地址