虽然可以通过Pod的IP来访问应用程序,但是Pod的IP地址不是固定的。而Service会对提供同一个服务的多个Pod进行聚合,并且提供一个统一的访问入口地址
每个Node节点上都运行了一个kube-proxy的服务进程。当创建Service的时候会通过API Server向etcd写入创建的Service的信息,而kube-proxy会基于监听的机制发现Service的变化,然后它会将最新的Service信息转换为对应的访问规则
[root@k8s-master ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
......省略部分......
TCP 10.96.0.10:53 rr
-> 10.244.235.203:53 Masq 1 0 0
-> 10.244.235.204:53 Masq 1 0 0
TCP 10.96.0.10:9153 rr
-> 10.244.235.203:9153 Masq 1 0 0
-> 10.244.235.204:9153 Masq 1 0 0
......省略部分......
UDP 10.96.0.10:53 rr
-> 10.244.235.203:53 Masq 1 0 0
-> 10.244.235.204:53 Masq 1 0 0
[root@k8s-master ~]#
当以TCP方式访问10.96.0.10:53这个service提供的访问入口。会基于rr(轮询)的策略,将请求转发到后面的两个Pod中的一个。真正提供服务的是10.244.235.203:53或10.244.235.204:53
Service的访问规则会同时在集群内的所有节点上都生成,所以在任何一个节点上访问都可以
[root@k8s-master ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
[root@k8s-master ~]#
mode: ""
修改成mode: "ipvs"
[root@k8s-master ~]# kubectl edit cm kube-proxy -n kube-system
configmap/kube-proxy edited
[root@k8s-master ~]#
[root@k8s-master ~]# kubectl delete pod -l k8s-app=kube-proxy -n kube-system
pod "kube-proxy-9gc7d" deleted
pod "kube-proxy-f9w7h" deleted
pod "kube-proxy-s8rwk" deleted
[root@k8s-master ~]#
[root@k8s-master ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
......省略部分......
TCP 10.96.0.10:53 rr
-> 10.244.235.203:53 Masq 1 0 0
-> 10.244.235.204:53 Masq 1 0 0
TCP 10.96.0.10:9153 rr
-> 10.244.235.203:9153 Masq 1 0 0
-> 10.244.235.204:9153 Masq 1 0 0
......省略部分......
UDP 10.96.0.10:53 rr
-> 10.244.235.203:53 Masq 1 0 0
-> 10.244.235.204:53 Masq 1 0 0
[root@k8s-master ~]#
kube-proxy会为每一个Service创建一个监听端口,发向Cluster IP的请求被iptables规则重定向到kube-proxy监听的端口上,kube-proxy根据LB算法(负载均衡算法)选择一个提供服务的Pod并和其建立连接,以便将请求转发到Pod上
该模式下,kube-proxy充当了一个四层负载均衡器的角色。由于kube-proxy运行在userspace中,在进行转发处理的时候会增加内核和用户空间之间的数据拷贝,虽然比较稳定,但是效率非常低下
kube-proxy为Service后端的每个Pod创建对应的iptables规则,直接将发向Cluster IP的请求重定向到一个Pod的IP上
该模式下kube-proxy不承担四层负载均衡器的角色,只负责创建iptables规则。该模式的优点在于较userspace模式效率更高,但是不能提供灵活的LB策略,而且当后端Pod不可用的时候无法进行重试
ipvs模式和iptables类似,kube-proxy监控Pod的变化并创建相应的ipvs规则。ipvs相对iptables转发效率更高,除此之外,ipvs支持更多的LB算法
Service的资源清单模板
apiVersion: v1
kind: Service
metadata:
name: service # Service名称
namespace: dev # Serivce所属的命名空间
spec:
selector: # 标签选择器,用于确定当前Service代理哪些Pod
app: nginx-pod
type: NodePort # Service的类型,指定Service的访问方式
clusterIP: 10.96.68.68 # cluster虚拟服务的IP地址
sessionAffinity: ClientIP # session亲和性,支持ClientIP、None(默认)两个选项
ports: # 端口信息
- protocol: TCP # 协议,支持TCP(默认)和UDP
port: 8080 # cluster虚拟服务版本的端口,即Service端口
targetPort: 8080 # Pod端口
nodePort: 30080 # 主机端口。用于NodePort和LoadBalancer的Service类型。默认只能在端口范围(30000~32767)中指定。如果不指定,会自动分配一个
spec.type的说明: