为什么需要Service
我们知道k8s的pod在死掉以后,重启的时候ip是会变化的。这就引起了一个问题,如果一些Pods提供一些功能供其他的Pod使用,那么在k8s中如何实现让这些pod能够持续的请求到依赖的这些Pod呢。另外,在这一组对外提供服务的pods之间如何保持负载均衡呢,而Service就是解决这个问题的。
k8s的Service是一个定义了一组Pod的策略的抽象,我们有时候也叫做宏观服务,这些被服务标记的Pod一般都是通过label selector选择的。
如何定义一个Service
我们可以通过如下yaml格式定义一个Service
apiVersion: v1
kind: Service
metadata:
name: hostnames
spec:
selector:
app: hostnames
ports:
- name: default
protocol: TCP
port: 80
targetPort: 9376
我们是用selector字段来声明了这个Service代理的是app为hostnames的pod。并且这个Service的80端口代理的是Pod的9376端口。
三种主要的Service
每一个Service都会有一个字段定义了该服务如何被调用,这个字段的值可以分成三种
-
ClusterIP: 仅仅使用一个集群内部的IP地址 - 这是默认值。选择这个值意味着你只想这个服务在集群内部才可以被访问到。
-
NodePort: 在集群内部IP的基础上,在集群的每一个节点的端口上开放这个服务。你可以在任意
:NodePort地址上访问到这个服务。例如,我们可以设计一个如下的Service的yaml文件: apiVersion: v1 kind: Service metadata: name: my-nginx labels: run: my-nginx spec: type: NodePort ports: - nodePort: 8080 targetPort: 80 protocol: TCP name: http - nodePort: 443 protocol: TCP name: https selector: run: my-nginx
在这个Service中我们制定了type=NodePort,然后我们声明了使用8080端口代理Pod的80端口,使用Service的443端口代理Pod的443端口。当然如果我们不显示的制动nodePort,系统就会在30000-32767之间随机为我们分配一个端口。这样以后,我们就可以通过< 任何一台宿主机的 IP 地址 >:8080 访问这个Service了。
-
LoadBalancer: 在使用一个集群内部IP地址和在NodePort上开放一个服务之外,向云提供商申请一个负载均衡器,会让流量转发到这个在每个节点上以
:NodePort的形式开放的服务上。