Kubernetes资源对象之Service
2017-01-15
Kubernetes Service #
当应用由单体架构转向微服务架构时，应用被拆成很多小的互相协作的微服务，每个服务会以多个副本运行，副本数量会随着系统所需的处理能力进行变化，这就是微服务的伸缩性。 微服务的负载均衡器对实现伸缩性起了十分重要的作用。
Service是Kubernetes最重要的资源对象。Kubernetes中的Service对象可以对应微服务架构中的微服务。Service定义了服务的访问入口，服务的调用者Pod通过这个地址访问Service后端的Pod副本实例。 Service通过Label Selector同后端的Pod副本建立关系，Replication Controller保证后端Pod副本的数量，也就是保证服务的伸缩性。
服务发现与负载均衡 #
Kubernetes1.5中，对于使用kubeadm init初始化的集群，Kubernetes通过DaemonSet的形式，保证在每个Node上都启动一个kube-proxy Pod实例。
kube-proxy实际上就是一个智能的负载均衡器。
发送到Service的请求由kube-proxy转发到后端的某个Pod实例上，同时支持不同的负载均衡策略和会话保持机制。
Kubernetes为每个Service分配一个全局唯一的虚拟IP，叫做ClusterIP，这样在整个集群中，服务的调用者都通过ClusterIP和服务进行通信。
Service创建完毕后，在Service的整个生命周期内Service的名称和ClusterIP保持不变，因此通过引入域名服务将Service的名称和ClusterIP建立DNS域名映射，服务的调用者可以通过使用服务的名称来访问服务。服务发现机制完美支持。
创建Service #
创建如下的nginx RC
1apiVersion: v1
2kind: ReplicationController
3metadata:
4 name: nginx
5spec:
6 replicas: 2
7 template:
8 metadata:
9 labels:
10 app: nginx
11 spec:
12 containers:
13 - name: nginx
14 image: nginx
15 ports:
16 - containerPort: 80
17 resources:
18 requests:
19 memory: "64Mi"
20 cpu: "200m"
21 limits:
22 memory: "128Mi"
23 cpu: "500m"
1kubectl get pod -l app=nginx -o wide
2NAME READY STATUS RESTARTS AGE IP NODE
3nginx-62404 1/1 Running 0 28s 10.244.3.27 cent1
4nginx-z0dnx 1/1 Running 0 28s 10.244.1.2 cent2
可以使用kubectl expose命令快速为RC管理的Pod创建Service：
1kubectl expose rc nginx
2service "nginx" exposed
3
4kubectl get svc nginx
5NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
6nginx 10.96.108.15 <none> 80/TCP 18s
此时可以使用Service的ClusterIP和Port访问服务，请求会被负载均衡到后端的Pod上。
1curl 10.96.108.15
2<!DOCTYPE html>
3<html>
4<head>
5<title>Welcome to nginx!</title>
6......
还可使用配置文件定义Service，使用kubectl create命令由配置文件创建Service：
1apiVersion: v1
2kind: Service
3metadata:
4 name: nginx
5spec:
6 ports:
7 - port: 80
8 targetPort: 80
9 selector:
10 app: nginx
当前Kubernetes支持两种负载均衡策略：
- RoundRobin： 默认策略，请求被轮询转发到后端的Pod实例副本上
- SessionAffinity: 基于客户端的IP进行会话保持的模式，实现粘性Session，客户端请求第一次被转发到某个Pod上后，后边所有的请求都固定转发到这个Pod上，SessionAffinity通过服务的定义service.spec.sessionAffinity设置。