一、认识Service
Service是Kubernetes的核心资源之一,通常可看做是微服务的一种实现。事实上它是一种抽象:通过规则定义出由多个Pod对象组合而成的逻辑集合,以及访问这组Pod的策略;Service关联Pod资源的规则要借助Selector标签选择器来完成。
由Deployment等控制器管理的Pod对象中断后由新建的资源对象所取代,而扩缩容后的应用则会带来Pod对象群体的变动,随之变化的还有Pod的IP地址访问接口等等,这也是编排系统之上的应用程序必然要面临的问题,为了解决Kubernetes资源访问的难题,为此,Kubernetes特地的设计了Service资源来解决此类问题。
Service资源基于标签选择器将一组Pod定义成一个逻辑的访问组合接口,并通过自己的IP地址和端口调度代理请求至组内的Pod对象之上,它向客户端隐藏了真实的、处理用户请求的Pod资源,使得客户端的请求看上去就像是由Service直接处理并进行响应的一样。
Service对象的IP地址称为Cluster IP,它位于Kubernetes集群配置指定专用IP地址的范围之内,而且是一种虚拟IP地址,它在Service对象创建后即保持不变,并且能够被同一集群中的Pod资源所访问。Service端口用于接收客户端请求并将其转发至后端的Pod中应用的相应端口之上,因此,这种代理机制也称为"端口代理"(port proxy)或四层代理,它工作于TCP/IP协议栈的传输层。
通过其标签选择器匹配到的后端Pod资源不止一个时,Service资源能够以负载均衡的方式进行流量调度,实现了请求流量的分发机制。Service与Pod对象之间的关联关系是通过标签选择器松耦合的方式建立的,它可以先于Pod对象创建而不会发生错误,于是,创建Service与Pod资源的任务可由不同的用户分别完成,例如,服务架构的设计和创建由运维工程师进行,而填充其实现的Pod资源的任务则可交由开发者进行。
Service资源会通过API Service持续监视着(watch)标签选择器匹配到的后端Pod对象,并实时跟踪各对象的变动,例如,IP地址的变动、对象增加或减少等等。不过,需要特别说明的是,Service并不直接链接至Pod对象,它们之间还有一个中间层–Endpoints资源对象,它是一个由IP地址和端口组成的列表,这些IP地址和端口则来自于由Service的标签选择器匹配到的Pod资源。这也是很多场景会使用"Service的后端端点"(Endpoint)这一术语的原因。默认情况下,创建Service资源对象时,其关联的Endpoints对象会自动创建。
二、Service代理模型
Kubernetes自1.9-alpha版本引入了ipvs代理模型,且自1.11版本起成为了默认的设置。这种模型中,kube-proxy跟踪API Server上Service和Endpoints对象的变化,据此来调用netlink接口创建ipvs规则,并确保与API Server中的变动保持同步。它与iptables规则的不同之处在于其请求流量的调度功能由ipvs实现,其余的功能仍由iptables完成。
类似于iptables模型,ipvs构建于netfilter的钩子函数之上,但它使用hash表作为底层数据结构并工作于内核空间,因此具有流量转发速度快、规则同步性能好的特性。另外,ipvs支持众多的调度算法,例如rr、lc、dh、sh、sed和nq等等。
三、创建Service资源
1)编写service的yaml文件
]# cat service.yaml
apiVersion: v1
kind: Service
metadata:
name: myapp-svc
spec:
selector:
app: myapp
ports:
- protocol: TCP
port: 80
targetPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 2
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: svc-pod
image: ikubernetes/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80