我的开源
kubernetes中暴露服务的方式比较
背景
应用(Application)是通过服务(Services)来暴露出去的。
Services有不同的类型，对于IP处理会有不同。
- NAT: network address translation
- Source NAT: 替换包中的source IP
- Destination NAT: 替换包中的destination IP
- VIP: a virtual IP
- Kube-proxy: network daemon
准备活动
# kubectl run source-ip-app --image=gcr.azk8s.cn/google-containers/echoserver:1.4
ClusterIP
确认一下现在的环境
# kubectl get nodes NAME STATUS ROLES AGE VERSION 172-19-120-198 Ready master 34h v1.15.2 172-19-120-201 Ready <none> 34h v1.15.2 172-19-120-202 Ready <none> 34h v1.15.2 172-19-120-203 Ready <none> 34h v1.15.2
节点代理类型
# curl localhost:10249/proxyMode iptables
通过 clusterip 方式来暴露服务
kubectl expose deployment source-ip-app --name=clusterip --port=80 --target-port=8080
看一下暴露出来的clusterip
# kubectl get svc clusterip NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE clusterip ClusterIP 10.109.59.94 <none> 80/TCP 8m56s
在容器中，请求一下这个ip，看看源ip是什么？
先起一下临时的应用busybox
kubectl run busybox -it --image=busybox --restart=Never --rm
/ # ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1 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 3: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue link/ether 52:fc:bb:9a:e3:a5 brd ff:ff:ff:ff:ff:ff inet 10.244.3.8/24 scope global eth0 valid_lft forever preferred_lft forever / # wget -qO - 10.109.59.94 CLIENT VALUES: client_address=10.244.3.8 command=GET
NodePort
部署
kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort
查看端口号
# kubectl get services nodeport NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nodeport NodePort 10.108.37.3 <none> 80:31113/TCP 48s
请求服务
# curl -s 172.19.120.198:31113 | grep client_address client_address=10.244.0.0 # curl -s 172.19.120.201:31113 | grep client_address client_address=10.244.1.0 # curl -s 172.19.120.202:31113 | grep client_address client_address=10.244.2.1 # curl -s 172.19.120.203:31113 | grep client_address client_address=10.244.3.0
这里的IP不是真实的客户端IP，而是集群内部的IP。其中的过程是：
client \ ^ \ \ v \ node 1 <------ node 2 | ^ SNAT | | ------> v | endpoint
- 客户端client发包给node 2:nodePort
- node 2做了SNAT，将包的来源IP替换为了node 2的IP
- node 2做了DNAT，将包的目的IP替换为了pod的IP
- 包被路由到了node 1, 然后由endpoint进行处理
- pod的响应，被路由到了node 2
- pod的响应，被送回到了客户端client
为了让pod能够得到真实的客户端IP，kubernetes有一个feature来禁止转发请求。这样所有的请求都会由本节点上的应用来处理，不会再进行转发，同时保留了客户端的IP地址。如果本节点上没有对应的应用时，这个包就会被丢弃。测试如下：
# kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}' service/nodeport patched
再进行请求来测试
# curl -s 172.19.120.198:31113 | grep client_address client_address=10.244.0.0 # curl -s 172.19.120.201:31113 | grep client_address 无响应 # curl -s 172.19.120.202:31113 | grep client_address client_address=172.19.120.198 # curl -s 172.19.120.203:31113 | grep client_address 无响应
过程示意图如下：
client ^ / \ / / \ / v X node 1 node 2 ^ | | | | v endpoint
发到node1的请求会被处理，发到node2的请求会被丢弃。
LoadBalancer
LoadBalancer模式下，所有的处于Ready状态的节点，都可以进行流量的load balance。当一个包到达一个没有endpoint的node时，会代理到一个有endpoint的node上，同时进行SNAT转换。
kubectl expose deployment source-ip-app --name=loadbalancer --port=80 --target-port=8080 --type=LoadBalancer
看下IP地址
# kubectl get svc loadbalancer NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE loadbalancer LoadBalancer 10.98.41.150 <pending> 80:32070/TCP 5m21s
请求
# curl "10.98.41.150" CLIENT VALUES: client_address=10.244.0.0
其中流量示意图为
client | lb VIP / ^ v / health check ---> node 1 node 2 <--- health check 200 <--- ^ | ---> 500 | V endpoint
还原状态
删除 services
kubectl delete svc -l run=source-ip-app
删除 deployment, replicaset和pod
kubectl delete deployment source-ip-app