一文搞懂什么是kubernetes 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.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 created2.2.1.1查看Service；
root@kubernetes-master01:~# kubectl get svc
nginx-svc ClusterIP 10.106.70.164 <none> 80/TCP 3m2.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=nginx2.2.1.3查看Endpoint资源，Endpoints可以简写为ep；
root@kubernetes-master01:~# kubectl get endpoints
nginx-svc 10.244.4.49:80 10m2.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: bytes2.3 NodePort
NodePort：首先是一种ClusterIP类型，也就是说，NodePort是ClusterIP的扩展类型。NodePort类型的Service不仅仅能够被集群内部的客户端可见，还能对外部客户端可见。怎么可见呢？它会与ClusterIP的功能之外在每个节点上使用一个相同的端口号"注意是在每个节点上使用一个相同的端口号"将外部流量引入到该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: # 正常情况下应由系统自己分配，默认是3000~32767
root@kubernetes-master01:~# kubectl apply -f services-nodeport-nginx.yaml
service/nginx-nodeport-svc created2.3.1.1查看Service，意味着访问宿主机IP+nodeport端口就可以访问服务；
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 34m2.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: bytes2.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.42.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: bytes2.5 ExternalName
此类型不是用来定义如何访问集群内服务的，而是把集群外部的某些服务以DNS CANME方式映射到集群内，从而让集群内的Pod资源能够访问外部服务的一种实现方式。
手机扫一扫
移动阅读更方便
你可能感兴趣的文章