Service介绍
Kubernetes 之所以需要 Service,一方面是因为 Pod的IP不是固定的,另一方面则是因为一组 Pod 实例之间总会有负载均衡的需求
Service是由Kube-proxy组件加上iptables来共同实现的
Service vip(vip 是k8s自动为Service分配的)到Pod的转发
iptables 对流入的IP包还设置了一个“标志”(–set-xmark)
只有处于Running状态,且readinessProbe检查通过的Pod,才会出现在Service的Endpoints 列表里.并且,当某一个 Pod 出现问题时,Kubernetes会自动把它从Service里摘除掉
Service基本原理
当用户把一个service yaml文件提交给k8s后,kube-proxy组件通过Service的Informer感知到一个Service对象的添加,作为对这个事件的响应它就会在宿主机上创建一条iptables规则 可以通过iptables-save命令来查看
Service的VIP地址只是一条iptables规则上的配置 并没有真正的网络设备 所以ping这个地址 是不会有任何响应的
DNAT的作用,就是在PREROUTING检查点之前,也就是在路由之前,将流入IP包的目的地址和端口,改成–to-destination指定的新目的地址和端口
访问Service VIP的IP包经过上述 iptables 处理之后,就已经变成了访问具体某一个后端Pod的IP包了.
不难理解,这些 Endpoints 对应的iptables规则,正是kube-proxy通过监听Pod的变化事件,在宿主机上生成并维护的
iptables模式和ipvs模式
kube-proxy通过iptables处理Service 的过程,其实需要在宿主机上设置相当多的 iptables 规则 当你的宿主机上有大量Pod的时候,成百上千条iptables规则不断地被刷新,会大量占用该宿主机的CPU资源 IPVS 模式 IPVS 模式的工作原理,其实跟iptables模式类似.当我们创建了前面的 Service 之后,kube-proxy首先会在宿主机上创建一个虚拟网卡(叫作:kube-ipvs0)并为它分配 Service VIP作为 IP 地址kube-proxy就会通过Linux的IPVS 模块,为这个IP地址设置三个IPVS 虚拟主机,并设置这三个虚拟主机之间使用轮询模式 (rr) 来作为负载均衡策略
Service和DNS的关系
在kubernetes中,所有的Service和Pod都会被分配一条对应的DNS A记录( 通过域名解析到IP地址的记录 )
clusterIP Service的分配方式
ClusterIP模式的Service 来说,它的 A 记录的格式是:myservicename.mynamespace.svc.cluster.local 当你访问这条 A 记录的时候,它解析到的就是该Service的VIP 地址Headliness Service的分配方式
ClusterIP=None 的 Headless Service 来说,它的 A 记录的格式也是:myservicename.mynamespace.svc.cluster.local 当你访问这条A记录的时候,它返回的是所有被代理的Pod的IP地址的集合.当然,如果你的客户端没办法解析这个集合的话,它可能会只会拿到第一个Pod的IP地址
clusterIP Service被代理Pod的分配方式
对于ClusterIP模式的Service来说,它代理的Pod被自动分配的A记录的格式是:PodIP.mynamespace.pod.cluster.local 这条记录指向Pod的IP地址
Headliness Service被代理Pod的分配方式
1.对Headless Service 来说,它代理的Pod被自动分配的A记录的格式是:mypodname.myservicename.mynamespace.svc.cluster.local 这条记录也指向Pod的IP地址 2. 如果Pod本身声明了hostname和subdomain字段,那么这时候Pod的A记录就会变成: podhostname.mysubdomain.mynamespace.svc.cluster.local
在上面这个Service和Pod被创建之后,你就可以通过busybox-1.default-subdomain.default.svc.cluster.local 解析到这个Pod的IP地址了
在 Kubernetes 里,/etc/hosts 文件是单独挂载的,这也是为什么kubelet能够对hostname进行修改并且Pod 重建后依然有效的原因这跟 Docke的Init层是一个原理
用途
ClusterIP模式的Service为你提供的,就是一个Pod的稳定的IP地址,即 VIP. 并且,这里Pod和Service 的关系是可以通过 Label 确定的 Headless Service 为你提供的,则是一个 Pod 的稳定的 DNS 名字,并且,这个名字是可以通过Pod名字和Service名字拼接出来 服务发现: 即当我的一个服务(Pod)的IP地址是不固定的且没办法提前获知时,该如何通过一个固定的方式访问到这个Pod