登录/注册
小张
1699
占位
2
占位
0
浏览量
占位
粉丝
占位
关注
一文搞懂什么是kubernetes Service
小张
2022-11-24 15:40:00 2022-11-24
14
0

1.什么是Service?

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

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

1.2 Service能干什么?

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

1.3 Service的作用?

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

1.4 Service的工作逻辑;

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

1.5 Endpoint资源

  1. 创建一个Service的时候会自动创建一个与Service同名的Endpoints,事实上,Service不但能够把标签选择器选中的Pod识别为自己的后端端点,还能够对后端端口做就绪状态检测。如果后端Pod是就绪的就把它加入到后端可用端点列表中,反之踢出;
  2. 这个功能不是Service来做的,而是Service借助一个中间组件,Endpoints也是kubernetes一个标准的资源类型;
  3. 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的实现;

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

1.7 Kube-Proxy代理模式

1.7.1UserSpace

  1. UserSpace模式下,kube-proxy为ServiceIP创建一个监听端口,当用户向ServiceIP发起请求;首先按请求会被Iptables规则拦截,然后重定向到kube-proxy对应的端口上,然后kube-proxy根据调度算法挑选一个Pod,将请求调度到该Pod上;
  2. 该模式流量经过内核空间后,会送往用户空间Kube-Proxy进程,而后又被送回内核空间,发往调度分配的目标后端Pod;效率太差。报文先到内核空间再回到用户空间,因为报文在用户空间来回切换两次以上,
  3. 7.2iptables
  4. iptables模式下,kube-proxy为Service后端的所有Pod创建对应的iptables规则,当用户向ServiceIP发起请求;首先iptables会拦截用户请求,然后直接将请求调度给后端的Pod;问题是一个Service会创建大量的Iptables规则,且不支持更高级的调度算法;
  5. 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资源能够访问外部服务的一种实现方式。

暂无评论