- 1. Service介绍
- 2. Service访问规则转发说明
- 3. ipvs的开启
- 4. kube-proxy支持的三种工作模式
- 4.1 userspace模式
- 4.2 iptables模式
- 4.3 ipvs模式
- 5. Service的类型和资源清单模板
虽然可以通过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的访问规则会同时在集群内的所有节点上都生成,所以在任何一个节点上访问都可以
3. ipvs的开启- 验证是否安装ipvs。如下已经安装了IPVS
[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 ~]#
- 修改kube-proxy配置,将
mode: ""
修改成mode: "ipvs"
[root@k8s-master ~]# kubectl edit cm kube-proxy -n kube-system
configmap/kube-proxy edited
[root@k8s-master ~]#
- 删除所有节点的kube-proxy pod。然后DaemonSet会自动进行重建kube-proxy pod
[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 ~]#
- 测试ipvs模块是否开启成功
[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 ~]#
4. kube-proxy支持的三种工作模式
4.1 userspace模式
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的说明:
- ClusterIP:默认值,kubernetes系统自动分配虚拟IP(也可通过clusterIP手动指定),只能在集群内部访问
- NodePort:将Service通过指定的Node上的端口暴露给外部,可以在集群外部访问服务。
- LoadBalancer:使用外接负载均衡器完成服务的负载分发,此模式需要外部云环境的支持
- ExternalName:把集群外部的服务引入集群内部,直接使用