Service是什么
Service类型
- Service特性
代理模型
- 1 userspace 代理模型（用户空间模型）
- 2 iptables代理模型
3 ipvs模型
路由转发
Service 的定义
Service参数
Service的基本用法
Headless Service
从集群外部访问Pod或者Service
- 将容器应用的端口号映射到物理机
- 将Service的端口号映射到物理机

Service是什么

假如有以下这种场景：

ginx Pod作为客户端访问tomcat Pod中的应用，当tomcat Pod中的应用因工作节点故障或者被手动删除后重启，它的IP会发生变化，这样会导致nginx通过原先IP访问tomcat中的应用会出错。另外，当Pod应用进行规模缩减时，一部分Pod会下线，如果客户端继续访问也会出错。而当Pod应用进行规模扩容时，新增的Pod将无法被有效访问。
除此以外，Pod对象的IP地址都仅在集群内部可达，无法接入外部请求的流量。
Service资源就是用于解决以上问题的。

原因	实现方案
由于POD的动态随机调度，所以没法通过POD的IP地址对其访问，需要更上一层的结构。	Service通过tag selector实现pod的筛选。Service主要包含两个属性：ports和tag selector

Service类型

ClusterIP（默认），分配一个集群内部可以访问的虚拟IP
NodePort在每个Node上分配一个端口作为外部访问入口LoadBalancer工作在特定的Cloud Provider上，例如Google
Cloud，AWS，OpenStack
ExternalName表示把集群外部的服务引入到集群内部中来，即实现了
集群内部pod和集群外部的服务进行通

Service特性

问题	解决方案
使用endpoint解耦	service没有和pod直接关联，而是在两者中间加了一层endpoint。这样的好处在于endpoint既可以关联集群内Pod；又可以绑定到集群外地址。当pod地址变化时，会动态更新etcd内的pod地址。
集群内访问service	在集群内部通过环境变量或者DNS地址可以直接获取pod的IP和端口，该IP是clusterIP、端口是serice端口。实现对service的访问。Service转发流量有轮询或者将同一个源IP路由到同一个Pod的策略。
使用nodePort模式从集群外访问Service	通过在每个node上开一个端口，进入该端口的流量被转发到对应的Service。
使用loadBalancer模式从集群外访问Service	借助云服务商的虚拟ip服务来实现

代理模型

1 userspace 代理模型（用户空间模型）

userspace 是Linux操作系统的用户空间，这种模型中，kube-proxy 负责跟踪API server 上的endpoints对象的变动，并根据其进行相关的调整策略。对于每个service对象，其都会随机打开一个本地端口，任何到达此端口的请求都会被代理到当前service资源的后端各个POD对象上，其默认使用RR调度策略。其代理的过程是：请求到达service后，其被转发到内核，经由套接字送往用户空间的kube-proxy，而后经由kube-proxy送回内核空间，并调度至后端POD，其传输方式效率太低。在1.1 版本之前，其是默认的转发策略。

2 iptables代理模型

kube-proxy 负责跟踪API server上 service和 endpoints对象的变动，并据此作出service资源定义的变动，对于每个service，都会创建iptabls规则直接捕获到达clusterIP 和PORT 的流量，并将其重定向到当前的service后端，默认算法是随机调度算法，POD 直接请求service IP 地址通过其直接访问对应的POD服务，在1.2开始成为默认类型，其使用的是iptables的目标地址转换至后端的POD对象，相对而言，其不用在内核和用户空间之间切换，因此更加高效，但其不能再被挑中的POD资源无响应时进行重定向，但用户空间(userspace)模型可以。

3 ipvs模型

此模型跟踪API service上的service和endpoints对象的变动，据此来调用netlink接口创建IPVS规则，并确保API server中的变动保持同步，其流量调度策略在IPVS中实现，其余的在iptables中实现。 ipvs 支持众多调度算法，如rr、lc、dh、sh、sed和nq 等。

路由转发

iptable
🌲K8s Service - 图8

ipvs
** 🌲K8s Service - 图9

Service 是 k8s 的核心概念，通过创建Service，可以为一组具有相同功能的容器应用提供一个统一的入口地址，并且将请求负载分发到后端的各个容器应用上。

Service 的定义

Service YAML格式的定义文件如下：

apiVersion: v1      // Required
kind: Service       // Required
metadata:           // Required
  name: string      // Required
  namespace: string // Required
  labels:
    - name: string
  annotations:
    - name: string
  spec:             // Required
    selectors: []   // Required
    type: string    // Required
    clusterIP: string
    sessionAffinity: string
    ports:
      - name: string
        protocol: string
        port: int
        targetPort: int
        nodePort: int
    status:
      loadBalancer:
        ingress:
          ip: string
          hostname: string

各属性的说明：

🌲K8s Service - 图10
🌲K8s Service - 图11
🌲K8s Service - 图12
🌲K8s Service - 图13

Service参数

port 访问service使用的端口targetPort Pod中容器端口NodePort 通过Node实现外网用户访问k8s集群内service
(30000-32767)

Service的基本用法

一般k8s的Pod都会以RC或者Deployment对外进行发布，并使用TCP/IP+Port的方式使得外部可以访问内部得服务。例如一个提供Web服务RC，由两个tomcat容器组成，每个容器都通过containerPort设置服务得端口号为8080。

# webapp-rc.yaml
apiVersion: v1
kind: ReplicationController
metadata:
  name: webapp
spec:
  replicas: 2
  template:
    metadata:
      name: webapp
      labels:
        app: webapp
    spec:
      containers:
      - name: webapp
        image: tomcat
        ports:
          - containerPort: 8080  ## containerPort 要和 镜像暴露得端口要一直。

创建该RC:

kubectl apply -f webapp-rc.yaml

创建成功之后：

NAME           READY   STATUS    RESTARTS   AGE   IP            NODE         NOMINATED NODE   READINESS GATES
webapp-nfrzq   1/1     Running   0          96s   10.244.1.44   k8s-node1    <none>           <none>
webapp-sxlmk   1/1     Running   0          96s   10.244.0.73   k8s-master   <none>           <none>

这样就可以使用Pod得IP+Port得方式访问Tomcat服务了：

# curl 10.244.1.44:8080
# curl 10.244.0.73:8080

但是以这种方式访问服务是有问题得，首先我们需要知道每个Pod得地址，如果该Pod故障，就需要切换使用另一个Pod得IP。所以k8s中Service组件就是用于解决这些问题的。

Service的简单使用

创建Service有两种方法，使用命令kubectl export或者根据定义文件创建。

先来使用命令创建Service，例如为之前的RC提供一个Service，使用命令如下：

[root@k8s-master service]# kubectl expose rc webap
[root@k8s-master service]# kubectl get svc webapp
NAME     TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
webapp   ClusterIP   10.107.38.14   <none>        8080/TCP   27s

创建Service后就可以直接使用Service的IP:Port的格式访问服务，请求会被自动负载分发到后端的Pod上。

我们还可以使用yaml定义文件创建Service，定义文件如下：

apiVersion: v1
kind: Service
metadata:
  name: webapp
spec:
  ports:
    - port: 8081
      targetPort: 8080
  selector:
    app: webapp

创建该Service:

[root@k8s-master service]# kubectl create -f webapp-svc.yaml  
service/webapp created
[root@k8s-master service]# kubectl get svc webapp
NAME     TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
webapp   ClusterIP   10.109.63.40   <none>        8081/TCP   7s

目前k8s提供了两种负载分发策略：

RoundRobin：轮询模式，即轮询将请求转发到后端的各个Pod上。
SessionAffinity：基于客户端IP地址进行会话保持的模式，即第1次将某个客户端发起的请求转发到后端的某个Pod上，之后从相同的客户端发起的请求都将被转发到后端相同的Pod上。

默认情况下，k8s采用RoundRobin模式，通过设置参数service.spec.sessionAffinity=ClientIP来启用SessionAffinity策略。

多端口Service

Service 支持设置多个端口对应到多个应用服务，配置文件如下：

apiVersion: v1
kind: Service
metadata:
  name: webapp
spec:
  ports:
    - port: 8080
      targetPort: 8080
      name: web
    - port: 8005
      targetPort: 8005
      name: management
  selector:
    app: webapp

也可以指定协议：

...
spec:
  ports:
    - port: 53
      procotol: UDP
      name: dns
    - port: 53
      procotol: TCP
      name: dns-tcp
...

外部服务service

外部服务Service可以将k8s集群外的应用纳入到集群服务，可以通过创建一个无Label Selector的Service实现：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
    - port: 8080
      procotol: TCP
      targetPort: 80

同时还需要创建一个和该Service同名的Endpoint资源，用于指向实际的后端访问地址，配置文件如下：

apiVersion: v1
kind: Endpoint
metadata:
  name: my-service
subsets:
- address:
  - IP: 1.2.3.4
  ports:
    - port: 80

Headless Service

k8s支持用户自定义负载均衡的策略，k8s提供了Headless Service来实现这种功能，即不为Service设置ClusterIP（入口IP地址），仅通过Label Selector将后端的Pod列表返回给调用的客户端。例如：

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
    - port: 80
    clusterIP: None
  selector:
    app: nginx

这样，Service就不再具有一个特定的clusterIP，对其访问将获得包含Label “app=nginx”的全部Pod列表，然后客户端程序自行决定如何处理这个Pod列表。StatefulSet就是使用Headless Service为客户端返回多个服务地址的，而且Headless Service十分适用于“去中心化”类的应用集群。

从集群外部访问Pod或者Service

由于Pod和Service都是k8s集群范围内的虚拟概念，所以集群外的客户端无法通过Pod的IP地址或者Service的虚拟IP地址访问。因此可以将Pod或者Service的端口号映射到宿主机，让容器外部的客户端也可以访问。

将容器应用的端口号映射到物理机

1.设置容器级别的hostPort

# pod-hostport.yaml
apiVersion: v1
kind: Pod
metadata:
  name: webapp
  labels:
    app: webapp
spec:
  containers:
  - name: webapp
    image: tomcat
    ports:
    - containerPort: 8080
      hostPort: 9000

创建Pod

kubectl create -f pod-hostport.yaml

创建完成后就可以访问k8s node的IP:Port。

2.设置Pod级别的hostNetwork=true

该Pod中所有容器的端口号都将被直接映射到物理机上。在设置hostNetwork=true时需要注意，在容器的ports定义部分如果不指定hostPort，则默认hostPort等于containerPort，如果指定了hostPort，则hostPort必须等于containerPort的值：

## pod-hostnetwork.yaml
apiVersion: v1
kind: Pod
metadata:
  name: webapp
  labels:
    app: webapp
spec:
  hostNetwork: true
  containers:
  - name: webapp
    image: tomcat
    imagePullPolicy: Never
    ports:
    - containerPort: 8080

将Service的端口号映射到物理机

1.设置nodePort映射到物理机

apiVersion: v1
kind: Service
metadata:
  name: webapp
spec:
  type: NodePort
  ports:
    - port: 8080
      targetPort: 8080
      nodePort: 31080 # 默认有效值 30000 - 32767
  selector:
    app: webapp

对该Service的访问也将被负载分发到后端的多个Pod上。

2.设置LoadBalancer映射到云平台

这种用法仅用于在公有云服务提供商的云平台上设置Service的场景。在下面的例子中， status.loadBalancer.ingress.ip设置的146.148.47.155为云服务商提供的负载均衡器的IP地址。对该Service的访问请求将会通过LoadBalancer转发到后端Pod上，负载分发的实现方式则依赖于云服务商提供的LoadBalancer的实现机制：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
      nodePort: 30061
    clusterIP: 10.0.171.239
    loadBalancerIP: 78.11.24.19
    type: LoadBalancer
  status:
    loadBalancer:
      ingress:
      - ip: 146.148.47.155