Kubernetes(三)

Kubernetes(三)

Service

Deployment只是保证支撑服务的Pod微服务数量,但是没有解决如何访问这些服务的问题.

一个Pod只是一个运行服务的实例.随时可能在一个节点上停止,在另一个节点上用新的ip启动一个新的pod.不能以确定的IP和端口号提供服务.

要稳定地提供服务,需要 服务发现负载均衡 .服务发现完成工作,是针对客户端访问的服务,找到对应的后端服务实例.在K8S集群中,客户端需要访问的服务Service对象.每个Service都会对应一个集群内部有效的虚拟ip,集群内部通过虚拟ip访问一个服务.

在K8S集群中,微服务的负载均衡是由kube-proxy实现的.kube-proxy是K8S集群内部的负载均衡器.它是一个分布式代理服务器,在K8S的每个节点上都有一个.这一设计体现了它的弹性伸缩的优势.需要访问服务的节点越多,提供负载均衡能力的kube-proxy就越多.高可用的节点也随之增多.与之相比,我们平时在服务端使用反向代理作为负载均衡,还要进一步解决方向代理的高可用问题.

Service存在的意义

防止Pod失联[服务发现]

因为Pod每次创建都对应一个IP地址,而这个IP地址是短暂的,每次随着Pod的更新都会变化.假设当我们前端页面有多个Pod的时候.同时后端也有多个Pod.这个时候,他们之间互相访问,就需要通过注册中心,拿到Pod的ip地址,然后去访问对应的Pod.

image-20210205100554814

定义Pod访问策略[负载均衡]

页面前端的Pod访问到后端Pod,中间会通过Service一层,而Service在这里还能做负载均衡.负载均衡的实现策略:

  • 随机
  • 轮询
  • 响应比

image-20210205101411033

Pod和Service的关系

这里的 Pod 和 service之间是根据 label 和 selector建立关联的[和controller类似]

image-20210205101530316

我们在访问 service 的时候,其实也是需要一个ip地址,这个ip不是Pod的ip地址.而是虚拟ip vip

Service常用类型

  • Service常用类型有三种:
  • ClusterIp: 集群内部访问
  • NodePort: 对外访问应用使用
  • LoadBalancer: 对外访问应用使用.公有云.

导出配置文件,包含service的配置信息

1
kubectl expose deployment web --port=80 --target-port=80 --dry-run -o yaml > service.yaml

service.yaml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
apiVersion: v1
kind: Service
metadata:
creationTimestamp: null
labels:
app: web
name: web
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: web
status:
loadBalancer: {}

默认第一种方式 ClusterIp,也就是只能在集群内部使用.可以添加一个type字段,来设置service类型.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
apiVersion: v1
kind: Service
metadata:
creationTimestamp: null
labels:
app: web
name: web
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: web
# 设置service类型
type: NodePort
status:
loadBalancer: {}

修改完命令后,我们使用创建一个pod

1
kubectl apply -f service.yaml

修改为 NodePort类型

还有一种方式LoadBalanced对外访问应用使用公有云.

node一般在内网部署,外网进行访问需要

  • 一台可以访问外网的服务器,安装nginx,反向代理.
  • 手动把可以访问的节点添加到nginx中.

如果我们使用 LoadBalanced,就会有负载均衡控制器,类似于nginx的功能.就不需要自己添加到nginx上.