标签：esc 内核空间 server 恢复 cto client 标签 激活 init
service的三种工作模式：(userstats(效率低)、iptables、ipvs)
service可以自动实现负载均衡。service自动实现了负载均衡，service通过selector标签选择器匹配了后面多个pod！后端多个pod提供底层服务。
Service版本介绍
userspace: 1.1之前版本
iptabls: 1.10之前版本
ipvs: 1.11之后版本
service依赖core-dns
四种service类型:
ExternalName(把外部集群服务引入到集群内部使用)、ClusterIP(默认这个。仅仅用于集群内部通信）、NodePort(和集群外部通信)、LoadBalance(把k8s部署在云环境上面，云环境支持LBAS(负载均衡即服务一键调用)，创建软负载均衡器使用。自动外部触发创建一个负载均衡，例如阿里LB-service)。
资源记录
SVC_NAME.NS_NAME.DOMAIN.LTD. #提供service服务域名格式
svc.clusqter.local #集群的默认名字域名
redis.default.svc.clustel.local. #每一个服务生产的域名格式，默认格式
Service用标签selector和后端pod建立关系,所以pod要先跑起来。
0、kube-proxy时刻watch监控着api-server，只要service发生变化，转换为当前节点实现调度的资源规则(有可能是iptables或者ipvs，取决于service的实现方式(userspace、iptables、ipvs))
1、service依赖dns服务，较新版本默认用的coredns，1.11之前版本用的kube-dns。service的名称解析强依赖于dns附件。所有dns必须部署。
2、k8s向客户提供网络功能，依赖第三方方案，可以用cni容器网络插件标准接口，另外还有flanael、calico插件也支持。
3、k8s有三类ip地址，节点ip网络、pod网络、集群地址cluster network(virtual ip虚拟ip)。
service工作。每个节点至少，node节点工作有一个组件kube-proxy，通过master上的api-server始终监视着有关service的变动信息。这种行为方式成为watch，一旦有service变化，kube-proxy转换为当前节点之上，能够实现service资源调度的规则，这种规则有可能是iptables，或者ipVS。规则取决于service的实现方式。
service三种工作代理模式(userstats(效率低)、iptables、ipvs)
第一种方式userstats：下面是用户空间模型解析。内部客户端用户请求clientPod，请求某个服务时，到达当前节点的内核空间iptables规则(其实就是service的规则)。service的工作方式是请求到达service以后，由service转换为本地监听在某个套接字的用户空间的kuber-proxy，kube-proxy处理完成再转给serviceip。最终代理这个这个service相关联的各个pod。最终实现调度。这个效率很低下。
第二种方式 iptables：客户端ip直接请求service ip。这个请求报文在本地内核空间的service的规则所截取。进而直接调度，service相关联的pod。区别是：直接工作在内核空间。由iptables规则直接负责调度。而第一种是由工作在内核空间的kube-proxy负责调度，所有第一种叫userstats。第二种叫iptabls。
第三种方式 ipvs。 client的请求到达内核空间以后，直接由ipvs规则来调度，直接调度给pod网络访问的相关资源。
总结：所以设定service工作在什么模型，就运行在什么模式。1.1及之前用iptables。1.11默认用的ipvsq。ipvs没有被激活，自动降级为iptables。
实战(pod删除增加原理过程)：#例子：假设Service的lable适配版本多了一个pod。这个pod立刻反馈到apiserver(因为pod的信息要保存在apiserver的etcd里面)。而后kuber-proxy检查watch到这种变化。将其转换为iptables规则。所以转换是动态的而且是实时的。删除也是同样的逻辑。
总结：pod变化会存储到apiserver的etcd里面。kube-proxy负责watch。watch信息会转为iptables规则
例子1-ClusterIP集群(使用yaml文件创建基于ClusterIP集群的service)
#查看当前service服务
[root@node-001 manifests]# kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 18d
#10.96.0.1是apiserver的地址。千万不能删除。
#这个千万不能删除，集群所有的pod需要10.96.0.1和集群的apiserver联系，这个地址是集群内的。
#apiserver有两个地址。一个面向集群外部，一个内部。
myapp NodePort 10.111.150.166 <none> 80:32489/TCP 16d
#删除之前创建的redis服务
[root@node-001 manifests]# kubectl delete svc redis
service "redis" deleted
#查看service的帮助文档
[root@node-001 manifests]# kubectl explain svc.spec
ports #把哪个端口和后端容器建立关系
selector #关联哪些pod资源
clusterIP #动态分配属于192端，假设使用固定，需要这个字段。创建没法改变。
#创建service的yaml文件
[root@node-001 manifests]# vim redis-service.yaml
apiVersion: v1
kind: Service
metadata:
name: redis
namespace: default #注意service和pod最好同一名称空间！
spec:
selector: #关联到哪些后端pod资源上面，只要pod打标签了，就会自动关联！
app: redis
role: logstor #打的标签是role，角色定义是logstorsdad
clusterIP: 10.97.97.97 #可以动态分配,不指定。建议不自己定义。或者自己定义。只要在10.96.0.0/12网段就可以。
type: ClusterIP #service集群类型
ports
- port: 6379 #service提供服务暴露的端口、service端口。
targetPort: 6379 #service后端容器的端口 NodePort 外网访问端口、容器端口
#生成service服务
[root@node-001 manifests]# kubectl apply -f redis-service.yaml
service/redis created
[root@node-001 manifests]# kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 18d
myapp NodePort 10.111.150.166 <none> 80:32489/TCP 17d
redis ClusterIP 10.97.97.97 <none> 6379/TCP 8m18s
#6379就是service提供的端口
#service创建好了，会在的core-dns自动生成记录svc、a等记录
资源记录格式：
SVC_NAME.NS_NAME.DOMAIN.LTD. #提供service服务域名格式
svc.clusqter.local #集群的默认名字域名
redis.default.svc.clustel.local. #例如redis在dns的记录格式显示。
#查看redis的service服务详细信息。
[root@node-001 manifests]# kubectl describe service redis
Name: redis
Namespace: default
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"redis","namespace":"default"},"spec":{"clusterIP":"10.97.97.97","...
Selector: app=redis,role=logstor #被selector匹配到的pod资源的地址。
Type: ClusterIP
IP: 10.97.97.97
Port: <unset> 6379/TCP
TargetPort: 6379/TCP
Endpoints: 10.244.1.73:6379 #service后端提供真正pods地址是这个。
小知识：为什么没有直接到显示pods？因为service到pod之间是有个中间层的。service不会直接到pod。先到Endpoints，再有Endpoints关联到pod。endpoints其实也可以手动创建，我们可以忽略这一层面。
Session Affinity: None
Events: <none>
小知识：服务添加完成，会自动动态在dns添加记录，不止一个，保护svc，A记录等，此时可以解析记录格式。
例子2-service---NodePort集群(使用yaml文件创建基于NodePort集群的service)
#通过访问集群端口NodePort集群来定义。nodeport类型的service。集群外部可以直接访问！！！
#先创建pods，打标签，然后创建service关联这个标签的后端pod。
#创建pods、打标签
[root@node-001 manifests]# cat rs-demo.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: myapp
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: myapp
release: canary
template:
metadata:
name: myapp-pod
labels:
app: myapp
release: canary
environment: qa
spec:
containers:
- name: myapp-container
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
[root@node-001 manifests]# kubectl apply -f rs-demo.yaml
[root@node-001 manifests]# kubectl get pods -o wide --show-labels
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES LABELS
myapp-bv2ff 1/1 Running 0 17s 10.244.1.90 node-002 <none> <none> app=myapp,environment=qa,release=canary
myapp-zf2c6 1/1 Running 0 17s 10.244.1.89 node-002 <none> <none> app=myapp,environment=qa,release=canary
#创建service、创建基于NodePort-service集群的yaml文件
[root@node-001 manifests]# vim myapp-nodeport-service.yaml
apiVersion: v1
kind: Service
metadata:
name: myapp
namespace: default
spec:
selector:
app: myapp
role: canary #打的标签是role，角色定义是logstorsdad
clusterIP: 10.99.99.99 #可以动态分配,不指定。建议不自己定义。或者自己定义。只要在10.96.0.0/12网段就可以。
type: NodePort #service类型为nodeport类型！！
ports:
- port: 80 #service端口
targetPort: 80 #pod端口 NodePort 外网访问端口
nodePort: 30080 #节点端口，这样外部直接访问宿主机ip:30080就可以访问了，注意这个30080在所有的node都会启动！端口在30000~32767范围内！不指定也可以，随机分配.
#每一个节点nodePort端口，不能被占用，不指定随机分配。！一旦被占用！！！错误设置会导致节点这个端口服务不能访问！！！因为相当于在iptables设置重定向。做成了dnat了。
#端口从30000 到32767之间随机分配。
#创建NortPort的service集群
[root@node-001 manifests]# kubectl create -f myapp-nodeport-service.yaml
service/myapp created
#查看service服务
[root@node-001 manifests]# kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 19d
myapp NodePort 10.99.99.99 <none> 80:30080/TCP 3m59s
service名字是myapp 集群类型是nodeport service集群ip serviceip端口是80 映射为node主机的端口30080
[root@node-001 manifests]#
#查看service详细信息
[root@node-001 manifests]# kubectl describe service myapp
Name: myapp
Namespace: default
Labels: <none>
Annotations: <none>
Selector: app=myapp,role=canary
Type: NodePort
IP: 10.99.99.99
Port: <unset> 80/TCP
TargetPort: 80/TCP
NodePort: <unset> 30080/TCP #这边好像有点问题，应该前面pod关停的原因导致的。
Endpoints: <none>
Session Affinity: None
External Traffic Policy: Cluster
Events: <none>
[root@node-001 manifests]#
#在每一个node宿主机查看端口
[root@node-001 manifests]# netstat -tunlp|grep 32489
tcp6 0 0 :::30080 :::* LISTEN 3313/kube-proxy
#每一个node节点都开启了30080端口
#从集群外机器访问myapp的service的nodeport集群的应用
[root@k8s-master mainfests]# while true;do curl http://192.168.100.181:30080/hostname.html;sleep 1;done
#自动实现负载均衡。因为service自动实现了负载均衡，爽快。因为selector后面匹配了多个pod！多个pod提供服务。
#原理：经过好几层转换，先访问nodeport先转为service port，再转换为pod port。
#此时前面可以再加个nginx，或者lvs hapoxcy做反向代理。
#下面做下回滚，或者更新(前面有做实验)，利用命令set 或者 patch 打补丁方式！
例子3-LoadBalance集群(使用yaml文件创建基于LoadBalance集群的service)
#LoadBalance这边没法做，假设购买阿里云6台ecs主机，又购买LBAS服务。ecs虚拟机部署了k8s，k8s可以与共有云交互IAAS的api，纯软件方式。请求创建一个外部的负载均衡器(0:31:00)。但是需要两级调度，先调度代理给nodeport服务，再由nodeport代码内部的servcie‘，service代理到真正的pod port。
例子4-LoadBalance集群
#ExternalName(把外部集群服务引入到集群内部使用)
#核心知识点：用于实现假设访问的服务在集群外，我们希望集群内可以访问到集群外服务。从而让集群内部服务访问外部服务像访问内部服务一样简单。
#建立一个service。这个service关联到外部服务。当内部的service服务访问时候，外部服务先转给node，node转给service。service转给port。
#查看帮助文档：[root@node-001 manifests]# kubectl explain svc.spec.externalName
Service调度机制(默认随机调度)
Pod会话保持(Session affinity)
核心知识：支持两种: ClientIP、None(默认)，所以默认随机调度。配置为clientip，把来自同一ip客户端，始终调度到统一个pod里面。可通过patch打补丁方式修改# kubectl patch svc myapp -p ‘{"spec":{"sessionAffinity":"ClientIP"}}‘，改好不用重启pod，立即生效，强大到没有朋友！
Service资源还支持Session affinity（粘性会话）机制，可以将来自同一个客户端的请求始终转发至同一个后端的Pod对象，这意味着它会影响调度算法的流量分发功用，进而降低其负载均衡的效果。因此，当客户端访问Pod中的应用程序时，如果有基于客户端身份保存某些私有信息，并基于这些私有信息追踪用户的活动等一类的需求时，那么应该启用session affinity机制。
Service affinity的效果仅仅在一段时间内生效，默认值为10800秒，超出时长，客户端再次访问会重新调度。该机制仅能基于客户端IP地址识别客户端身份，它会将经由同一个NAT服务器进行原地址转换的所有客户端识别为同一个客户端，由此可知，其调度的效果并不理想。Service 资源 通过. spec. sessionAffinity 和. spec. sessionAffinityConfig 两个字段配置粘性会话。 spec. sessionAffinity 字段用于定义要使用的粘性会话的类型，它仅支持使用“ None” 和“ ClientIP” 两种属性值。如下：
例子(配置pod会话保持)
#用Session affinity配置调度的时候调度后端的同一个pod。
#通过patch打补丁方式对之前myapp这个service设置会话保持,格式为ClientIP.
[root@node-001 manifests]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 19d
myapp NodePort 10.99.99.99 <none> 80:30080/TCP 57m
redis ClusterIP 10.97.97.97 <none> 6379/TCP 36m
[root@node-001 manifests]# kubectl patch svc myapp -p ‘{"spec":{"sessionAffinity":"ClientIP"}}‘
service/myapp patched
#查看service是否pod会话保持是否设置为ClientIP。
[root@node-001 manifests]# kubectl describe svc myapp
Name: myapp
Namespace: default
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"myapp","namespace":"default"},"spec":{"clusterIP":"10.99.99.99","...
Selector: app=myapp,role=canary
Type: NodePort
IP: 10.99.99.99
Port: <unset> 80/TCP
TargetPort: 80/TCP
NodePort: <unset> 30080/TCP
Endpoints: <none>
Session Affinity: ClientIP #这边已经显示pod会话保持设置为ClientIP
External Traffic Policy: Cluster
Events: <none>
[root@node-001 manifests]#
#查看pod会话保持情况。改完是动态生效的!不用重启！从集群外机器访问myapp的service的nodeport集群的应用
[root@k8s-master mainfests]# while true;do curl http://192.168.100.181:30080/hostname.html;sleep 1;done
Headless Service(没有cluster ip):
#headless service表示没有service没有cluster ip。访问直达pod。kubcetl get svc的之后clueter ip没有数值
#有时不需要或不想要负载均衡，以及单独的 Service IP。 遇到这种情况，可以通过指定 Cluster IP（spec.clusterIP）的值为 "None " 来创建 Headless Service。
#无头service，每一个service应该名字。并且这个service名字可以解析成对应的cluster ip。通常cluster ip只有一个,由cluster ip调度到后端的多个pod。假设解析service名字的时候。没有cluster ip，#去掉service ip，这样解析service名字因为不能解析到clusterip，从而解析到pod ip。pod ip可能多个.没有cluster ip的就是无头service，而是直接达到pod。
配置Headless Service:只要定义字段clusterIP的值为：None
例子(定义hedless service)
#创建yaml文件。注意不能定义nodeport。
[root@node-001 manifests]# vim myapp-service-headless.yaml
apiVersion: v1
kind: Service
metadata:
name: myapp-svc
namespace: default
spec:
selector:
app: myapp #挑选后端有myapp的标签的pod
release: canary #打的标签是role，角色定义是logstorsdad
clusterIP: "None" #定义service类型为无头service。定义None。没有clusterip。只有service。访问的时候直接访问后端pod。
ports:
- port: 80 #service暴露的端口
targetPort: 80 #service后端提供的pod端口
#创建headless-service服务
[root@node-001 manifests]# kubectl apply -f myapp-service-headless.yaml
service/myapp-svc created
#查看clusterip没有数值！
[root@node-001 manifests]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 19d
myapp NodePort 10.99.99.99 <none> 80:30080/TCP 96m
myapp-svc ClusterIP None <none> 80/TCP 2s #none表示无头service
redis ClusterIP 10.97.97.97 <none> 6379/TCP 74m
#service创建完成，会自动在core-dns添加记录！
#用dig进行名称解析。查看服务解析情况！非常实用！！
[root@node-001 manifests]# kubectl get svc -n kube-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
myapp-svc ClusterIP None <none> 80/TCP 2s #none表示无头service
[root@mater01 ~]# kubectl get svc -n kube-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 4d4h
[root@node-001 manifests]# dig -t A myapp-svc.defautl.svc.cluster.local. @10.96.0.10
# @表示不使用本地配置的dns解析，而是使用指向目标dns服务器去进行解析！目标dns是k8s集群内部的dns地址。
;; ANSWER SECTION:
. 30 IN A 10.244.1.27
. 30 IN A 10.244.1.27
#dig总结：这边会显示所有A记录。后面直接显示pod的地址，由这些pod地址提供服务！但是如果是有头的service。dig出来的后面的ip显示的是service-ip地址！
总结(有头service和无头service区别)：
#无头service：这边可以看到，无头service，解析的直接就是pod的ip地址
#有头service：解析的就是自己service的cluster ip地址。
service缺点
#service无法解决https访问问题。定义service以后，尤其是nodeport集群访问，需要经过2级转换调度，而且是4层调度，无论是iptables还是ipvs。4调度自身无法实现卸载https会话。
#ingress----k8s还有一种引入集群外部流量的方式，叫ingress。基于7层调度器。利用7层pod，将外部流量引入到内部。
------------恢复内容结束------------
标签：esc 内核空间 server 恢复 cto client 标签 激活 init
原文地址：https://www.cnblogs.com/yangtian/p/12232934.html
