Kubernetes-Service资源详解
2021-04-24 20:27
标签：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 #10.96.0.1是apiserver的地址。千万不能删除。 #这个千万不能删除，集群所有的pod需要10.96.0.1和集群的apiserver联系，这个地址是集群内的。 #apiserver有两个地址。一个面向集群外部，一个内部。 myapp NodePort 10.111.150.166 #删除之前创建的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 myapp NodePort 10.111.150.166 redis ClusterIP 10.97.97.97 #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: 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: TargetPort: 6379/TCP Endpoints: 10.244.1.73:6379 #service后端提供真正pods地址是这个。 小知识：为什么没有直接到显示pods？因为service到pod之间是有个中间层的。service不会直接到pod。先到Endpoints，再有Endpoints关联到pod。endpoints其实也可以手动创建，我们可以忽略这一层面。 Session Affinity: None Events: 小知识：服务添加完成，会自动动态在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 myapp-zf2c6 1/1 Running 0 17s 10.244.1.89 node-002 #创建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 myapp NodePort 10.99.99.99 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: Annotations: Selector: app=myapp,role=canary Type: NodePort IP: 10.99.99.99 Port: TargetPort: 80/TCP NodePort: Endpoints: Session Affinity: None External Traffic Policy: Cluster Events: [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 myapp NodePort 10.99.99.99 redis ClusterIP 10.97.97.97 [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: 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: TargetPort: 80/TCP NodePort: Endpoints: Session Affinity: ClientIP #这边已经显示pod会话保持设置为ClientIP External Traffic Policy: Cluster Events: [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 myapp NodePort 10.99.99.99 myapp-svc ClusterIP None redis ClusterIP 10.97.97.97 #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 [root@mater01 ~]# kubectl get svc -n kube-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kube-dns ClusterIP 10.96.0.10 [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，将外部流量引入到内部。 ------------恢复内容结束------------ Kubernetes-Service资源详解 标签：esc 内核空间 server 恢复 cto client 标签 激活 init 原文地址：https://www.cnblogs.com/yangtian/p/12232934.html
文章标题：Kubernetes-Service资源详解
文章链接：http://soscw.com/index.php/essay/79091.html