一文搞懂什么是kubernetes Service

1.什么是Service？

在kubernets中，Pod是应用程序的载体，Pod你可以想象成就是容器，为动态的一组Pod提供一个固定的访问入口，它是以一种叫ClusterIP地址来进行标识，而ClusterIP就位于我们集群网络(Cluster Network)当中，我们可以通过Pod的IP地址来进行访问，但是会遇到问题:

动态Pod的IP地址不是固定的，一旦Pod异常退出、节点故障，则会发生Pod重建，一旦发生重建客户端则会访问失败；
Pod如果扩容多个，会造成客户端无法有效使用新增的Pod，如果Pod进行缩容则会造成客户端访问错误；
官方文档: https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/

1.2 Service能干什么？

为了解决这个问题，K8s提供了Service资源，Service为动态的一组Pod提供一个固定的访问入口；这个固定的访问入口可以理解为是一组应用的前端的负载均衡器；就像LVS或Nginx为一组ReadyServer做负载均衡器是一样的，你是看不见的，可以理解为Service就是负载均衡器，但是这种负载均衡器比传统的负载均衡器要强大；Service资源通过"标签选择器Label Selector"把筛选出来的符合条件的一组Pod对象定义成一个逻辑集合，而后Service对外提供自己的IP和端口。
当客户端请求Service的IP和端口时，Service将请求调度给标签匹配的所有的Pod，Service向客户端隐藏了真实处理请求的Pod资源，使得客户端的请求看上去是由Service直接处理并进行响应。
Service对象的IP地址(Cluster IP或Service IP)是虚拟IP地址，由kubernetes系统在Service对象创建时在专有网络(Service Network)地址中自动分配或由用户手动指定，其次Service是基于端口过滤，并根据事先定义好的规则将请求转发至其后端Pod对应的端口上，因此这种代理机制也称为"端口代理"或"四层代理"工作在TCP/IP协议栈的传输层；

1.3 Service的作用？

暴露流量，让用户可以通过ServiceIP+ServicePort访问后端的Pod应用；
负载均衡: 提供基于4层的TCP/IP负载均衡，并不提供HTTP/HTTPS等负载均衡；
服务发现: 当发现新增Pod则自动加入至Service的后端，如发现Pod异常则会踢出Service后端；

1.4 Service的工作逻辑；

Service持续监视API-Server，监视Service标签选择器所匹配的后端的Pod，并实时跟踪这些Pod对象的变动情况，例如IP地址的变化、Pod对象增加或减少；
Service并不直接与Pod建立关联关系，他们之间还有一个中间层Endpoints，Endpoints对象是一个由IP地址和端口组成的列表，这些IP地址和端口来自于Service标签选择器所匹配到的Pod，默认情况下，创建Service资源时，关联的Endpoints对象会被自动创建；

1.5 Endpoint资源

创建一个Service的时候会自动创建一个与Service同名的Endpoints，事实上，Service不但能够把标签选择器选中的Pod识别为自己的后端端点，还能够对后端端口做就绪状态检测。如果后端Pod是就绪的就把它加入到后端可用端点列表中，反之踢出；
这个功能不是Service来做的，而是Service借助一个中间组件，Endpoints也是kubernetes一个标准的资源类型；
Service会自动去管理Endpoints，Endpoints真正能发挥作用的是Endpoint控制器。一旦创建一个Service，需要为Service指定的基本属性是"Label Selector"随后Service控制器会根据这个标签选择器创建一个同名的Endpoints资源，是由Sercice控制器请求创建一个同名的Endpoints资源，随后Endpoints控制器就会介入，因为有一个自己的资源需要被创建。Endpoints控制器就会使用Endpoints的标签选择器与Service一模一样，继承Service的，Endpoints控制器会根据"标签选择器"去查找多少个符合筛选的Pod。最重要的是还会检查Pod的就绪状态，真正去绑定的不是由Service做的，而是由Endpoints做的。Service只负责调度，如果关联到了。Service只是把Endpoint帮查找到的所有处于就绪状态的后端Pod告诉Service，于是成了Service的后端端点；

1.6 Servcie的实现；

在kubernetes中，Service只是一个抽象的概念，真正起作用实现负载均衡规则的其实是kube-proxy这个进程，它在每一个节点都需要运行一个kube-proxy，用来完成负载均衡规则的创建；

1.7 Kube-Proxy代理模式

1.7.1UserSpace

UserSpace模式下，kube-proxy为ServiceIP创建一个监听端口，当用户向ServiceIP发起请求；首先按请求会被Iptables规则拦截，然后重定向到kube-proxy对应的端口上，然后kube-proxy根据调度算法挑选一个Pod，将请求调度到该Pod上；
该模式流量经过内核空间后，会送往用户空间Kube-Proxy进程，而后又被送回内核空间，发往调度分配的目标后端Pod；效率太差。报文先到内核空间再回到用户空间，因为报文在用户空间来回切换两次以上，
1.7.2iptables
iptables模式下，kube-proxy为Service后端的所有Pod创建对应的iptables规则，当用户向ServiceIP发起请求；首先iptables会拦截用户请求，然后直接将请求调度给后端的Pod；问题是一个Service会创建大量的Iptables规则，且不支持更高级的调度算法；
1.7.3IPVS
ipvs模式和iptables类似，kube-proxy为Service后端所有的Pod创建对应的IPVS规则，一个Service只生成一条规则，所以规模较大的场景应使用IPVS。其次IPVS支持更多的高级算法；

2.Service的类型

2.1 Service资源规范

apiVersion: v1       # API的版本
kind: Service        # 资源类型定义为Service
metadata:           
  name: ...          # Serivce的名称
  namespace: ...     # 默认的default
  labels:
     key1: value1   # 标签 key:value格式；
     key2: value2
spec:
  type <string>      # Service类型，默认为ClusterIP；
  selector <map[string]string> #  标签选择器
  ports:                       #  ClusterIP:ServicePort
  targetPort: <string>  #后端目标进程的端口号或名称。
  nodePort: <integer>  # 节点端口号，仅适用于NodePort和loadbalancer类型。  "建议动态选择30000-32767" 
 clusterIP <string> # Service的集群IP，建议由系统自动分配
 externalTrafficPolicy <string> # 外部流量策略处理方式，local表示由当前节点处理，cluster表示向集群范围调度
 loadBalancerIP <string> # 外部负载均衡器使用的IP地址，仅适用于loadbalancer,前提是你的公有云得支持你自己指定;
 externalName <string> # 外部服务名称，该名称作为Service的DNS CNAME值

2.2 ClusterIP

ClusterIP: 通过集群内部IP暴露服务，选择ServiceIP只能够在集群内部访问，这也是默认的Service类型；该地址仅在集群内部可见、可达。无法被集群外部客户端访问；而且是默认类型，创建的任何Service默认就是ClusterIP类型，而且只能接受集群内部客户端的访问。

2.2.1 ClusterIP示例；

root@kubernetes-master01:~# cat services-clusterip-nginx.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-clusterip
  namespace: default
  labels:
     app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:alpine
    imagePullPolicy: IfNotPresent
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
  namespace: default
spec:
  clusterIP:
  selector:     # 标签选择器 
    app: nginx   
  ports:
  - name: http  # 端口名称
    protocol: TCP   # 协议类型，目前支持TCP、UDP、SCTP默认为TCP
    port: 80   # Service的端口号
    targetPort: 80  # 后端目标进程的端口号
root@kubernetes-master01:~# kubectl apply -f services-clusterip-nginx.yaml 
pod/nginx-clusterip created
service/nginx-svc created

2.2.1.1查看Service；

root@kubernetes-master01:~# kubectl get svc
nginx-svc    ClusterIP   10.106.70.164    <none>        80/TCP    3m

2.2.1.2 可以看到后端就一个Pod；

root@kubernetes-master01:~# kubectl get pods --show-labels -l app=nginx -o wide
NAME              READY   STATUS    RESTARTS   AGE     IP            NODE                NOMINATED NODE   READINESS GATES   LABELS
nginx-clusterip   1/1     Running   0          8m58s   10.244.4.49   kubernetes-node01   <none>           <none>            app=nginx

2.2.1.3查看Endpoint资源，Endpoints可以简写为ep；

root@kubernetes-master01:~# kubectl get endpoints
nginx-svc    10.244.4.49:80                                10m

2.2.1.4测试访问；只能在集群内部访问，外部无法访问；

root@kubernetes-master01:~# curl -I  10.106.70.164
HTTP/1.1 200 OK
Server: nginx/1.21.5
Content-Type: text/html
Content-Length: 615
Connection: keep-alive
ETag: "61cb5be0-267"
Accept-Ranges: bytes

2.3 NodePort

NodePort即是节点Port，通常在安装集群系统会预留一个端口范围用于NodePort,默认是3000-32767之间，与ClusterIP类型的可省略.spec.type属性所不同的是，定义NodePort类似的Service资源时，需要通过此属性明确指定其类型名称，示例如下:

2.3.1 NodePort示例；

root@kubernetes-master01:~# cat services-nodeport-nginx.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-nodeport-svc
  namespace: default
spec:
  type: NodePort
  clusterIP:
  selector:
    app: nginx
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80   # 后端Pod监听什么端口就写什么端口。要不然到达Service的请求转发给Pod，Pod没有那个端口也没用。一定真正转发到后端程序监听的端口。如果没有特殊情况的话，ServicePort和TargetPort保持一致。NodePort可以不用指定。
    nodePort:        # 正常情况下应由系统自己分配，除非事先能够明确知道它不会与某个现存的Service资源产生冲突，没有特别需求，留给系统自动配置总是好的选择。
root@kubernetes-master01:~# kubectl apply -f services-nodeport-nginx.yaml 
service/nginx-nodeport-svc created

2.3.1.1查看Service，意味着访问宿主机任一节点的IP+NodePort端口就可以访问服务；对于集群内的Pod客户端来说，依然可以通过ClusterIP对其进行访问；

root@kubernetes-master01:~# kubectl get svc
NAME                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
kubernetes           ClusterIP   10.96.0.1        <none>        443/TCP        36d
nginx-nodeport-svc   NodePort    10.111.124.121   <none>        80:32049/TCP   5s
nginx-svc            ClusterIP   10.106.70.164    <none>        80/TCP         34m

2.3.1.2 测试，这是windows的命令行，也是没有问题；

C:\Users\海棠>curl -I  10.0.0.1xx:30824
HTTP/1.1 200 OK
Server: nginx/1.21.5
Content-Type: text/html
Content-Length: 615
Connection: keep-alive
ETag: "61cb5be0-267"
Accept-Ranges: bytes

2.4 LoadBalancer

loadBalancer: 这类Service依赖云厂商，需要通过云厂商调用API接口创建软件负载均衡将服务暴露到集群外部，当创建LoadBalancer类型的Service对象时，它会在集群上自动创建一个NodePort类型的Service，集群外部的请求流量会先路由至该负载均衡，并由该负载均衡调度至各个节点的NodePort；

2.4.1 LoadBalancer示例；

root@kubernetes-master01:~# cat  services-loadbalancer-nginx.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-loadbalancer-svc
  namespace: default
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80
  loadBalancerIP: 1.2.3.4

2.4.1.2测试访问；

# 我们还是只能是通过NodePort来访问，因为没有LoadBalancer的IP；
# LoadBalancer其实就是一个增强的NodePort。而LoadBalancer没有限制流量调度策略的。外部流量策略对loadbalancer依然使用，因为LoadBalancer首先是一个NodePort的Service。
C:\Users\冷雨夜>curl -I 10.0.0.1XX:31943
HTTP/1.1 200 OK
Server: nginx/1.21.5
Content-Type: text/html
Content-Length: 615
Connection: kep-alive
ETag: "61cb5be0-267"
Accept-Ranges: bytes

2.5 ExternalName

此类型不是用来定义如何访问集群内服务的，而是把集群外部的某些服务以DNS CANME方式映射到集群内，从而让集群内的Pod资源能够访问外部服务的一种实现方式。

posted @ 2022-08-06 11:00 梨花海棠阅读(653) 评论(0) 编辑收藏举报

刷新页面返回顶部

Loading

海棠

后续内容会更新在个人站点: https.malusspectabilis.top