网站首页 > 技术文章 正文
在Kubernetes平台上，Pod是有生命周期，为了可以给客户端一个固定的访问端点，因此需要在客户端和Pod之间添加一个中间层，这个中间层称之为Service
Service是什么？
在Kubernetes中，每个节点都安装了kube-proxy，kube-proxy通过kubernetes中固有的watch请求方法持续监听apiserver。一旦有service资源发生变动(增删改查)kube-proxy可以及时转化为能够调度到后端Pod节点上的规则，这个规则可以是iptables也可以是ipvs，取决于service实现方式
Kubernetes 三大IP
- Node Network 节点网络 节点网络地址是配置在节点网络之上
- Pod Network Pod网络 Pod网络地址是配置在Pod网络之上节点网络和Pod网络都是配置在某个设备之上，可以是硬件也可以是虚拟网络
- Cluster Network(svc network) virtual IP svc ip没有配置在某个网络接口上，它只是存在service的规则当中
Service 工作原理
k8s在创建Service时，会根据标签选择器selector(lable selector)来查找Pod，据此创建与Service同名的endpoint对象，当Pod 地址发生变化时，endpoint也会随之发生变化，service接收前端client请求的时候，就会通过endpoint，找到转发到那个Pod进行访问的地址。(至于转发到哪个节点的Pod，由负载均衡kube-proxy期初就决定好的)
#查看endpoint可以通过下面的命令
[root@k8s-01 ~]# kubectl get ep
NAME ENDPOINTS AGE
fuseim.pri-ifs <none> 31d
kubernetes 192.168.0.10:6443,192.168.0.11:6443,192.168.0.12:6443 33d
myapp 172.30.168.6:80,172.30.192.7:80,172.30.216.7:80 7m56s
myapp-svc 172.30.168.4:80,172.30.192.5:80,172.30.216.6:80 18m1.endpoint是k8s集群中的一个资源对象，存储在etcd中，用来记录一个service对应的所有pod的访问地址2.只有当service配置selector(选择器)，endpoint controller才会自动创建对应的endpoint对象，否则，不会生成endpoint对象3.在k8s集群中创建webapp的service，就会生成一个同名的endpoint对象，endpoint就是service关联的Pod的ip地址和端口
Service 工作模式
userpace在这种模式下，kube-proxy监视Kubernetes主服务器以添加和删除Service和Endpoint对象。对于每个服务，它都会在本地节点上打开一个端口(随机选择)。与此代理端口的任何连接都代理到服务的后端Pod。SessionAffinity在决定使用哪个后端Pod时，kube-proxy会考虑服务的设置。最后，用户控件代理安装iptables规则，以获取服务clusterIP和流量port。规则将流量重定向到代理后端Pod的端口。
简单点来说Service的请求先从用户空间进入内核iptables转发到这个端口，然后再回到用户空间，由kube-proxy完成后端endpoint的选择和代理，这样流量会有从用户空间进入内核的过程，效率低，有明显的性能瓶颈
image_1e2i15977imggfddjb1dgsfbem.png-155.2kB
iptables
目前默认的方案，完全以内核iptables的nat方式实现service负载均衡。该方式在大规模情况下存在一些性能问题；首先，iptables没有增量更新的功能，更新一条规则需要整体flush，更新时间长，这段时间之内流量会有不同程度的影响；此外，iptables规则串行匹配，没有预料到Kubernetes这种在一个机器上会有很多规则的情况，流量需要经过所有规则的匹配后在进行转发，对时间和内存都是极大的小号，尤其在大规模情况下对性能的影响十分明显
image_1e2i1b3cf1fja1kkrmravbtcms13.png-148.8kB
ipvs
与iptables、userspace 模式一样，kube-proxy 依然监听Service以及Endpoints对象的变化, 不过它并不创建反向代理, 也不创建大量的 iptables 规则, 而是通过netlink 创建ipvs规则，并使用k8s Service与Endpoints信息，对所在节点的ipvs规则进行定期同步; netlink 与 iptables 底层都是基于 netfilter 钩子，但是 netlink 由于采用了 hash table 而且直接工作在内核态，在性能上比 iptables 更优
同时，ipvs负载均衡除了简单rr规则还有很多选择，适合在大型集群中使用，而缺点是带来了额外的配置维护操作
image_1e2i1j2661kavs7d13bg119g1hvm1g.png-113.3kB
简单说一下kube-proxy和service之间的关系
访问Service的请求，不论是Cluster IP还是TargerPort方式；还是NodePort方式，都被Node节点的Iptables规则重定向到kube-proxy监听Service服务代理端口。kube-proxy接受Service的访问请求后，根据负载策略转发到后端的Pod
-> kube-proxy其实就是管理service的访问入口，包括集群内Pod到Service的访问和集群外访问service。
-> kube-proxy管理sevice的Endpoints，该service对外暴露一个Virtual IP，也成为Cluster IP, 集群内通过访问这个Cluster IP:Port就能访问到集群内对应的serivce下的Pod。
-> service是通过Selector选择的一组Pods的服务抽象，其实就是一个微服务，提供了服务的LB和反向代理的能力，而kube-proxy的主要作用就是负责service的实现。
-> service另外一个重要作用是，一个服务后端的Pods可能会随着生存灭亡而发生IP的改变，service的出现，给服务提供了一个固定的IP，而无视后端Endpoint的变化。kube-proxy负责为Service提供cluster内部的服务发现和负载均衡，它运行在每个Node计算节点上，负责Pod网络代理, 它会定时从etcd服务获取到service信息来做相应的策略，维护网络规则和四层负载均衡工作。在K8s集群中微服务的负载均衡是由Kube-proxy实现的，它是K8s集群内部的负载均衡器，也是一个分布式代理服务器，在K8s的每个节点上都有一个，这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的Kube-proxy就越多，高可用节点也随之增多。
Service 服务发现
https://i4t.com/4478.html
Service 集群服务暴露
服务发现解决了集群内部访问Pod问题，但很多时候，Pod提供的服务也要对集群外部来暴露访问。
ExternalName
简单的来说ExternalName代理外部的请求，让Pod访问svc实际上访问的就是集群外部的服务，让Pod访问集群外部的服务像集群内部服务一样方便
apiVersion: v1
kind: Service
metadata:
name: my-service
namespace: default
spec:
type: ExternalName
externalName: my.database.example.com这里externalName实际上就是cname的域名，前提需要节点可以访问到，或者映射到公网上
集群内部可以通过my-service.default.svc.cluster.local访问，请求会被cname映射到my.database.example.com
ClusterIP
clusterIP又可以分为普通Service和Headless Service两类
- 普通Service 通过Kubernetes的Service分配一个集群内部可访问的固定虚拟IP(Cluster IP)，也可以自己指定clusterIP，从而实现集群内部的访问
- Headless Service 无头服务 该服务不会分配ClusterIP，也不会通过kube-proxy做反向代理和负载均衡。而是通过DNS提供稳定的网络ID来访问，DNS会将headless service的后端直接解析为PodIP列表，主要提供StatefulSet使用
普通Cluster IP演示
这里我们创建一个svc和deployment，具体参数不在解释，如有不懂可以参考 Kubernetes Service
apiVersion: apps/v1beta2
kind: Deployment
metadata:
name: myapp-svc
spec:
replicas: 3
selector:
matchLabels:
app: myapp-svc
template:
metadata:
labels:
app: myapp-svc
spec:
containers:
- name: myapp-svc
image: ikubernetes/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: myapp-svc
namespace: default
spec:
selector:
app: myapp-svc
type: ClusterIP
ports:
- port: 80
targetPort: 80创建完毕后,service会随机代理pod。 普通service也是比较常见的svc
[root@k8s-01 ~]# kubectl get pod,svc
NAME READY STATUS RESTARTS AGE
pod/myapp-svc-5f8fc8545f-6svln 1/1 Running 0 79s
pod/myapp-svc-5f8fc8545f-kwc7x 1/1 Running 0 79s
pod/myapp-svc-5f8fc8545f-rp8vg 1/1 Running 0 79s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.254.0.1 <none> 443/TCP 33d
service/myapp-svc ClusterIP 10.254.223.73 <none> 80/TCP 81s
[root@k8s-01 ~]#
[root@k8s-01 ~]# curl 10.254.223.73/hostname.html
myapp-svc-5f8fc8545f-kwc7xHeadkess Service演示
如果我们上面创建了clusterIP模式，需要修改svc模式，需要将之前svc删除从新创建，如果使用apply是无法刷新svc配置的
[root@k8s-01 ~]# cat k8s-svc.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
name: myapp-svc
spec:
replicas: 3
selector:
matchLabels:
app: myapp-svc
template:
metadata:
labels:
app: myapp-svc
spec:
containers:
- name: myapp-svc
image: ikubernetes/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: myapp-svc
namespace: default
spec:
clusterIP: "None"
selector:
app: myapp-svc
ports:
- port: 80
targetPort: 80在无头模式中，clusterip为none，因为不需要clusterip所以这里是没有cluster ip
[root@k8s-01 ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.254.0.1 <none> 443/TCP 33d
myapp-svc ClusterIP None <none> 80/TCP 4m33s这里通过dig命令进行查看
参数需要说明，myapp-svc为svc的名称，default为命名空间， 后面@10.254.0.2我这里使用的是coredns，同样也是coredns svc ip
## 查看svc及Pod名称，一会需要对比
[root@k8s-01 ~]# kubectl get pod,svc -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod/myapp-svc-5f8fc8545f-26c8x 1/1 Running 0 7m22s 172.30.168.4 k8s-03 <none> <none>
pod/myapp-svc-5f8fc8545f-hd7pp 1/1 Running 0 7m22s 172.30.216.6 k8s-01 <none> <none>
pod/myapp-svc-5f8fc8545f-kd6xl 1/1 Running 0 7m22s 172.30.192.5 k8s-02 <none> <none>
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service/kubernetes ClusterIP 10.254.0.1 <none> 443/TCP 33d <none>
service/myapp-svc ClusterIP None <none> 80/TCP 7m22s app=myapp-svc
## 查看dns svc ip
[root@k8s-01 ~]# kubectl get svc -n kube-system|grep dns
kube-dns ClusterIP 10.254.0.2 <none> 53/UDP,53/TCP,9153/TCP 33d
##查看dns解析是否为3个pod，以及对应的IP
[root@k8s-01 ~]# dig -t A myapp-svc.default.svc.cluster.local. @10.254.0.2
...
;; ANSWER SECTION:
myapp-svc.default.svc.cluster.local. 5 IN A 172.30.168.4
myapp-svc.default.svc.cluster.local. 5 IN A 172.30.216.6
myapp-svc.default.svc.cluster.local. 5 IN A 172.30.192.5
...如果我们使用普通service，这里dig只会出现一个pod名称
NodePort
除了cluster ip之外，还可以通过service的port映射到集群内每个节点的相同端口，实现通过nodeIP:nodePort 从集群外访问服务
在NodePort中，client请求先到达NodeIP+NodePort-->ClusterIP:ServicePort-->PodIP:ContainerPort
这里我们继续创建webapp
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
name: myapp
labels:
addonmanager.kubernetes.io/mode: Reconcile
spec:
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: my-nginx
image: ikubernetes/myapp:v1
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: myapp
namespace: default
spec:
selector:
app: myapp
type: NodePort
ports:
- port: 80
targetPort: 80
nodePort: 30080我们映射nodeport端口30080，type类型为Nodeport，也是我们之前常用的
[root@k8s-01 ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.254.0.1 <none> 443/TCP 33d
myapp NodePort 10.254.233.67 <none> 80:30080/TCP 33s接下来我们就可以在任意节点访问Pod
[root@k8s-01 ~]# while true;do curl http://192.168.0.10:30080/hostname.html; sleep 1; done
myapp-xr9m2
myapp-gbcvh
myapp-6gwh9
myapp-xr9m2
myapp-gbcvhLoadBalancer
和nodeport类似，不过除了使用一个Clusterip和nodeport之外，还会向所使用的公有云申请一个负载均衡器，实现从集群外通过LB访问服务
更多参数可以参考官方文档https://kubernetes.io/docs/concepts/services-networking/service/#externalname
Service Session会话保持
session affinity会话保持，又称为会话亲和性，常用于Web Service的微服务部署中。就和我们nginx中的会话保持一样
可以将来自同一个客户端的请求始终转发至同一个后端的Pod对象，这意味着它会影响调度算法的流量分发功用，进而降低其负载均衡的效果。因此，当客户端访问Pod中的应用程序时，如果有基于客户端身份保存某些私有信息，并基于这些私有信息追踪用户的活动等一类的需求时，那么应该启用session affinity机制。
Service affinity的效果仅仅在一段时间内生效，默认值为10800秒，超出时长，客户端再次访问会重新调度。该机制仅能基于客户端IP地址识别客户端身份，它会将经由同一个NAT服务器进行原地址转换的所有客户端识别为同一个客户端，由此可知，其调度的效果并不理想。Service 资源 通过. spec. sessionAffinity 和. spec. sessionAffinityConfig 两个字段配置粘性会话。 spec. sessionAffinity 字段用于定义要使用的粘性会话的类型，它仅支持使用“ None” 和“ ClientIP” 两种属性值。如下：
[root@k8s-01 ~]# kubectl explain svc.spec.sessionAffinity
KIND: Service
VERSION: v1
FIELD: sessionAffinity <string>
DESCRIPTION:
Supports "ClientIP" and "None". Used to maintain session affinity. Enable
client IP based session affinity. Must be ClientIP or None. Defaults to
None. More info:
https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies
[root@k8s-01 ~]#sessionAffinity支持ClientIP和None 两种方式，默认是None（随机调度） ClientIP是来自于同一个客户端的请求调度到同一个pod中
[root@k8s-01 ~]# cat webapp.yml
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
name: myapp
labels:
addonmanager.kubernetes.io/mode: Reconcile
spec:
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: my-nginx
image: ikubernetes/myapp:v1
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: myapp
namespace: default
spec:
selector:
app: myapp
type: NodePort
sessionAffinity: ClientIP ##参数位置
ports:
- port: 80
targetPort: 80
nodePort: 30080此时我们通过curl请求svc时，只会返回一个节点的pod
[root@k8s-01 ~]# while true;do curl http://192.168.0.10:30080/hostname.html;sleep 1;done
myapp-cg4lq
myapp-cg4lq
myapp-cg4lq
myapp-cg4lq
myapp-cg4lq也可以使用打补丁的方式进行修改yaml内的内容，如下：
kubectl patch svc myapp -p '{"spec":{"sessionAffinity":"ClusterIP"}}' #session保持，同一ip访问同一个pod
kubectl patch svc myapp -p '{"spec":{"sessionAffinity":"None"}}' #取消session 如果我们取消session配置，那么请求svc时会随机调度给pod相当于sessionAffinity=None
[root@k8s-01 ~]# while true;do curl http://192.168.0.10:30080/hostname.html;sleep 1;done
myapp-pplfn
myapp-wkfqz
myapp-cg4lq
myapp-pplfn
myapp-wkfqz说明一点Service属于四层调度，无论是iptables还是ipvs都是无法实现https请求或者7层的操作
原文:https://i4t.com/4567.html
猜你喜欢
- 2024-10-12 Kong 优雅实现微服务网关鉴权，登录场景落地实战篇
- 2024-10-12 k8s安装与使用入门（k8s安装步骤）
- 2024-10-12 应用无损上下线（应用无损上下线怎么关闭）
- 2024-10-12 另一个Kubernetes(k8s)指南（kubernetesk8s怎么使用）
- 2024-10-12 Kubernetes 安全专家(CKS)必过心得
- 2024-10-12 深入理解K8S网络原理上（k8s网络解决方案）
- 2024-10-12 一次客户需求引发的K8S网络探究（基于客户需求）
- 2024-10-12 今天讲讲k8s的pod控制器及无状态和有状态
- 2024-10-12 k8s如何滚动升级应用（k8s升级组件方法）
- 2024-10-12 k8s基础知识之service类型（k8s的service类型）
- 02-21走进git时代， 你该怎么玩?_gits
- 02-21GitHub是什么?它可不仅仅是云中的Git版本控制器
- 02-21Git常用操作总结_git基本用法
- 02-21为什么互联网巨头使用Git而放弃SVN?(含核心命令与原理)
- 02-21Git 高级用法，喜欢就拿去用_git基本用法
- 02-21Git常用命令和Git团队使用规范指南
- 02-21总结几个常用的Git命令的使用方法
- 02-21Git工作原理和常用指令_git原理详解
- 最近发表
- 标签列表
-
- cmd/c (57)
- c++中::是什么意思 (57)
- sqlset (59)
- ps可以打开pdf格式吗 (58)
- phprequire_once (61)
- localstorage.removeitem (74)
- routermode (59)
- vector线程安全吗 (70)
- & (66)
- java (73)
- org.redisson (64)
- log.warn (60)
- cannotinstantiatethetype (62)
- js数组插入 (83)
- resttemplateokhttp (59)
- gormwherein (64)
- linux删除一个文件夹 (65)
- mac安装java (72)
- reader.onload (61)
- outofmemoryerror是什么意思 (64)
- flask文件上传 (63)
- eacces (67)
- 查看mysql是否启动 (70)
- java是值传递还是引用传递 (58)
- 无效的列索引 (74)