目录
一、Service介绍
在kubernetes
中,
pod
是应用程序的载体,我们可以通过
pod
的
ip
来访问应用程序,但是
pod
的
ip
地址不是固定的,这也就意味着不方便直接采用pod
的
ip
对服务进行访问。
为了解决这个问题,kubernetes
提供了
Service
资源,
Service
会对提供同一个服务的多个
pod
进行聚合,并且提供一个统一的入口地址。通过访问Service
的入口地址就能访问到后面的
pod
服务。
Service在很多情况下只是一个概念,真正起作用的其实是
kube-proxy
服务进程,每个
Node
节点上都运行着一个kube-proxy
服务进程。当创建
Service
的时候会通过
api-server
向
etcd
写入创建的
service
的信息,而kube-proxy
会基于监听的机制发现这种
Service
的变动,然后
它会将最新的
Service
信息转换成对
应的访问规则
。
# 10.96.0.10:53 是service 提供的访问入口# 当访问这个入口的时候,可以发现后面有两个 pod 的服务在等待调用,# kube-proxy 会基于 rr (轮询)的策略,将请求分发到其中一个 pod 上去# 这个规则会同时在集群内的所有节点上都生成,所以在任何一个节点上访问都可以。[root @node1 ~ ] # ipvsadm -LnIP Virtual Server version 1.2.1 (size = 4096 )Prot LocalAddress : Port Scheduler Flags-> RemoteAddress : Port Forward Weight ActiveConn InActConnTCP 10.96.0.10:53 rr
-> 10.244.58.196:53 Masq 1 0 0
-> 10.244.58.197:53 Masq 1 0 0
kube-proxy目前支持三种工作模式:
userspace 模式
userspace模式下,
kube-proxy
会为每一个
Service
创建一个监听端口,发向
Cluster IP
的请求被
Iptables
规则重定向到
kube-proxy
监听的端口上,
kube-proxy
根据
LB
算法选择一个提供服务的
Pod
并和其建立链接,以将请求转发到Pod
上。
该模式下,kube-proxy
充当了一个四层负责均衡器的角色。由于
kube-proxy
运行在
userspace
中,在进行转发处理时会增加内核和用户空间之间的数据拷贝,虽然比较稳定,但是效率比较低。
iptables
模式
iptables模式下,
kube-proxy
为
service
后端的每个
Pod
创建对应的
iptables
规则,直接将发向
ClusterIP的请求重定向到一个
Pod IP
。
该模式下kube-proxy
不承担四层负责均衡器的角色,只负责创建
iptables
规则。该模式的优点是较userspace模式效率更高,但不能提供灵活的
LB
策略,当后端
Pod
不可用时也无法进行重试。
ipvs
模式
ipvs模式和
iptables
类似,
kube-proxy
监控
Pod
的变化并创建相应的
ipvs
规则。
ipvs
相对
iptables
转发效率更高。除此以外,ipvs
支持更多的
LB
算法。
# 此模式必须安装ipvs内核模块,否则会降级为iptables
# 开启 ipvs[root@k8s-master01 ~]# kubectl edit cm kube-proxy -n kube-system
Edit cancelled, no changes made.
修改: mode : "ipvs"[root@k8s-master01 ~]# kubectl delete pod -l k8s-app=kube-proxy -n kube-system
pod "kube-proxy-65vrr" deleted
pod "kube-proxy-fl8f8" deleted
pod "kube-proxy-xwkjp" deleted[root@k8s-node01 ~]# ipvsadm -Ln
TCP 10.96.0.10:53 rr
-> 10.244.58.196:53 Masq 1 0 0
-> 10.244.58.197:53 Masq 1 0 0
二、Service类型
Service的资源清单文件:
kind : Service # 资源类型apiVersion : v1 # 资源版本