使用源 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 Web 服务器,该服务器通过 HTTP 头部回显其接收到的请求的源 IP。你可以按如下方式创建它:
注意
以下命令中的镜像仅在 AMD64 架构上运行。kubectl create deployment source-ip-app --image=registry.k8s.io/echoserver:1.10
输出为:
deployment.apps/source-ip-app created
目标
- 通过各种类型的 Service 暴露一个简单的应用程序。
- 了解每种 Service 类型如何处理源 IP NAT。
- 了解保留源 IP 的权衡。
Type=ClusterIP
的 Service 的源 IP
如果 kube-proxy 在 iptables 模式下运行(默认),则从集群内部发送到 ClusterIP 的数据包永远不会进行源 NAT。你可以通过在 kube-proxy 运行的节点上获取 https://: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 https://: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
查询本地 Web 服务器。
# 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 地址(SNAT)替换为自己的 IP 地址。node2
将数据包中的目标 IP 替换为 Pod IP。- 数据包被路由到节点 1,然后路由到端点。
- Pod 的回复被路由回 node2。
- Pod 的回复被发送回客户端。
可视化:
图。使用 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
,该端口确实有端点。 - node1 将数据包路由到具有正确源 IP 的端点。
可视化:
图。源 IP Type=NodePort 保留客户端源 IP 地址。
Type=LoadBalancer
的 Service 的源 IP
发送到 Type=LoadBalancer
服务的包默认进行源 NAT,因为所有处于 Ready
状态的可调度 Kubernetes 节点都有资格进行负载均衡流量。因此,如果包到达没有端点的节点,系统会将其代理到有端点的节点,将包的源 IP 替换为节点的 IP(如上一节所述)。
你可以通过负载均衡器暴露 source-ip-app 来测试这一点。
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 端点的节点通过故意使健康检查失败来从有资格进行负载均衡流量的节点列表中移除自己。
可视化:
你可以通过设置注释来测试这一点:
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
的服务保留源 IP。你所运行的云提供商可能会以几种不同的方式满足负载均衡器的请求:
使用代理,该代理终止客户端连接并打开与你的节点/端点的新连接。在这种情况下,源 IP 始终是云 LB 的 IP,而不是客户端的 IP。
使用数据包转发器,使从客户端发送到负载均衡器 VIP 的请求到达具有客户端源 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
下一步
- 了解更多关于通过服务连接应用程序的信息。
- 阅读如何创建外部负载均衡器。