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.
定义Pod访问策略[负载均衡]
页面前端的Pod访问到后端Pod,中间会通过Service一层,而Service在这里还能做负载均衡.负载均衡的实现策略:
- 随机
- 轮询
- 响应比
Pod和Service的关系
这里的 Pod 和 service之间是根据 label 和 selector建立关联的[和controller类似]
我们在访问 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 | apiVersion: v1 |
默认第一种方式 ClusterIp,也就是只能在集群内部使用.可以添加一个type字段,来设置service类型.
1 | apiVersion: v1 |
修改完命令后,我们使用创建一个pod
1 | kubectl apply -f service.yaml |
修改为 NodePort
类型
还有一种方式LoadBalanced
对外访问应用使用公有云.
node
一般在内网部署,外网进行访问需要
- 一台可以访问外网的服务器,安装nginx,反向代理.
- 手动把可以访问的节点添加到nginx中.
如果我们使用 LoadBalanced
,就会有负载均衡控制器,类似于nginx的功能.就不需要自己添加到nginx上.